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

[Vízdal Aleš <[e-mail]>]

Hi,

Many thanks for your points.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Mark
> Smith
> Sent: Thursday, May 09, 2013 1:05 PM
> To: Fred Baker (fred); [e-mail]
> Subject: Re: [v6ops] draft-ietf-v6ops-64share WGLC
> 
> 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.

The document is bit of both as some of the mentioned approaches have been implemented,
some are listed as an option. 
 
> 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)

UE is a 3GPP term, reference/explanation will be added.
 
> 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.

The current 3GPP architecture is limited to support a single IPv6 prefix only. It explicitly
states that if the mobile networks announces multiple IPv6 prefix in the RA only the first
one shall be used, the rest shall be ignored.
 
> o  A separated numbered list in the second paragraph would make these points clearer

Ack.

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

Once indented, it will be clear that it applies to the last point only.
 
> 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. 

As there is no link-layer addressing and the GW does not do NUD (it has been discussed
on the list before, there is no NUD-aware implementation known) it will be forwarding
all packets that belong to the /64 down to the UE.

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

It will have ::/0 pointing towards the mobile network and /64 towards the LAN. Non-known
destinations shall be routed to LAN, if the host is not known on the LAN ICMP error
shall be returned back to the originator.
 
> 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.

Fair point. 

How about?

Lack of global scope connectivity will limit network services running on the UE (e.g. DNS 
caching that requires global connectivity) and prevent proper Path MTU Discovery  [RFC1981] 
to occur on the UE.
 
> 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).

OK, that's making Scenario 1 & 2 very similar.

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

It looks like that Linux implements the weak host model as rp_filter has been added later
as a userspace function. (https://bugzilla.kernel.org/show_bug.cgi?id=6998)
 
> 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."

If it requires clarification, it shall be changed for all 3 options.

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

Yes, this is the concern where the temporary addresses can be created on both interfaces
independently resulting in a potential address collision. (low risk, but may happen)

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

Cheers,
Ales