Re: [v6ops] draft-ietf-v6ops-64share WGLC

[Mark Smith <[e-mail]>]

Hi,


----- Original Message -----
> From: Fred Baker (fred) <[e-mail]>
> To: "[e-mail]" <[e-mail]>
> Cc: 
> Sent: Monday, 29 April 2013 6:00 AM
> Subject: [v6ops] draft-ietf-v6ops-64share WGLC
> 
>T his is to initiate a two week working group last call of 
> http://tools.ietf.org/html/draft-ietf-v6ops-64share. Please read it now. If you 
> find nits (spelling errors, minor suggested wording changes, etc), comment to 
> the authors; if you find greater issues, such as disagreeing with a statement or 
> finding additional issues that need to be addressed, please post your comments 
> to the list.
> 
> We are looking specifically for comments on the importance of the document as 
> well as its content. If you have read the document and believe it to be of 
> operational utility, that is also an important comment to make.
> 
> 


Firstly, I I think this document is of value, as it facilitates IPv6
connectivity to hosts tethered to 3GPP devices which don't support DHCPv6-PD.

I think there are some areas where it needs to be improved.

General
~~~~~~

It isn't clear to me whether the document is describing what has been
implemented, what could be implemented or both.

The reason I wonder is specifically because of the first scenario,
"No Global Address on the UE". Assuming that the UE is a smart phone,
I'd think that the user would expect that if they enable tethering,
they could continue to use the phone itself to access the Internet, run
various Internet applications etc. For example, they may be lending or
sharing their Internet access to another person using a laptop, rather
than switching from using their smartphone to their tablet or laptop. In
other words, a multiuser scenario. I think the UE losing Internet access
while providing it to tethered devices is quite a significant and probably
unacceptable limitation, and would most likely confuse most UE end-users
when it occurs (resulting in many support phone calls to their carrier's
helpdesk, or worse, technical relatives or friends).

If the document is describing what has been implemented, then I think it is
reasonable to keep this method in there, however I think the significant
drawbacks should be described, and this method being recommended against
being implemented. On the other hand, if the document is only describing
what could be implemented, rather than what has been, then I think this
scenario should either be dropped or strongly recommended against, as the
I think the drawbacks are too significant.

1. Introduction
~~~~~~~~~~~~

o  UE definition - I think it would be useful to define what User Equipment
is, because I think the significance of some of the drawbacks of the
different methods may be influenced by what type of device the UE is. For
example, for a 3G Wifi hotspot device, the device's own loss of Internet
access in scenario 1 might be less significant than if the UE is a smart
phone (although, if the 3G Wifi hotspot device is acting as a DNS cache,
local NTP server or similar, then the significance is probably the same)

o  Multiple global prefixes - the text seems to suggest only one global
IPv6 prefix ever be announced over the 3GPP radio interface. I don't
know if the 3GPP documents specify that, however I think we should always
facilitate announcements of multiple IPv6 prefixes, so that IPv6's address
aging capability can be used to phase in a new IPv6 prefix and then phase
out an old one over a reasonable time period e.g. a month.

o  A separated numbered list in the second paragraph would make these
points clearer

o  It isn't clear whether the last sentence of the 2nd paragraph is
applying to all of the numbered list points, or just the last one.


3.0 General Behavior for All Scenarios
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

o  Regarding the gateway not consuming any addresses within the /64, and
forwarding all traffic to /64 destinations towards the UE, when the UE is
acting as a host, I assume it would drop traffic towards non-UE assigned
addresses, as per normal IPv6 host behaviour. However, when the UE becomes
a router in these scenarios, is a sink/null route for the /64 created,
so that the UE doesn't forward traffic towards non-known destinations back
towards the gateway via its default route? Neighbor discovery on the LAN
interface should give the UE knowledge of the hosts/nodes using addresses
within the /64, so that it only drops traffic for destinations within the
/64 that don't exist.

3.1 Scenario 1: No Global Address on the UE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In addition to my thoughts in General above.

o  In addition to the PMTUD issue, I think it would also be worth mentioning
that if the UE is providing other services e.g. DNS caching that require
global connectivity, they'll also be impacted.

o  "The 3GPP interface and LAN interface only maintain link-local addresses
while the UE uses RA to announce the /64 to the LAN." - It may be possible
for the UE to listen to it's own RAs on it's LAN interface, and therefore
use SLAAC to configure a LAN global address. For example, Linux provides
this option (sysctl accept_ra = 2).

3.2 Scenario 2: Global Address Only Assigned to LAN
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

o  "The movement of the IPv6 prefix from the 3GPP radio interface to the
LAN interface may result in long-lived data connections being terminated
during the transition from a host-only mode to router-and-host mode."

It may be worth expanding on this a bit further. In theory, I think an
application should be able to survive this as long as it isn't bound to a
specific interface, or is relying on the sin6_scope_id value (which usually
conveys ifindex, as per RFC4007) not changing. The host's/router's route
table decides the exit interface for packets, rather than always using the
interface the selected source address was assigned to. How the OS handles
moving the address may be disruptive, although I'd think it might be fairly
straight forward for the OS to be modified to prevent that disruption.

It isn't completely clear to me as to whether IPv6 uses the weak host
model (packets destined to one of the host's addresses can enter the
host via any interface), or the strong host model (packets must enter
the host on the interface assigned the address), or whether it is an
implementation decision. RFC4291 (IPv6 Addr. Arch) implies strong, by
saying that addresses are assigned to interfaces, while RFC6724 (Src. &
Dst. Selection) implies weak, by only recommending rather than requiring
that the source address is the one assigned to the interface that will
be used to reach the destination. If it is strong, as the UE is becoming
a router, I think a router by nature supports the weak host model, as it
will logically forward packets from the non-destination address assigned
ingress interface to its other interface assigned the address, and then
handle it locally at the higher layers.

o "The UE checks to make sure the 3GPP interface is active and has an IPv6
address." I suggest changing it to "The UE checks to make sure the 3GPP
interface is active and has at least one global IPv6 address."

3.3 Scenario 3: A Single Global Address Assigned to 3GPP Radio and LAN Interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

o  "This method also creates complications for ensuring uniqueness for
Privacy Extensions [RFC4941].  Privacy Extensions should be disabled on
the 3GPP radio interface while this method is enabled." What particular
complications? I can see there would be some if the privacy addresses were
created independently for the two interfaces, however if a single privacy
address was generated, and then assigned to both interfaces, would that
eliminate the complications? Are there others that I'm not seeing?


o  "2. The UE checks to make sure the 3GPP interfaces is active and has
an IPv6 address." - delete 's' on interfaces.


HTH,
Mark.