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

["Fred Baker (fred)" <[e-mail]>]

Thanks for a very detailed review.

On May 9, 2013, at 4:04 AM, Mark Smith <[e-mail]>
 wrote:

> 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.