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

From: Mark Smith <[email-masked]>
Date: Thu, 9 May 2013 04:04:39 -0700 (PDT)

Hi,

----- Original Message -----
> From: Fred Baker (fred) <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> 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.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 9 May 2013 14:03:19 +0000

Thanks for a very detailed review.

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 9 May 2013 16:52:14 +0200

Hi,

Many thanks for your points.

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

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

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

> 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

---

From: Mark Smith <[email-masked]>
Date: Sun, 12 May 2013 13:59:50 -0700 (PDT)

Hi  Vízdal,

----- Original Message -----
> From: Vízdal Aleš <[email-masked]>
> To: Mark Smith <[email-masked]>; Fred Baker (fred) <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: 
> Sent: Friday, 10 May 2013 12:52 AM
> Subject: RE: [v6ops] draft-ietf-v6ops-64share WGLC
> 

<snip>

> rather than

I think making that clearer and more explicit in each case would be very useful.

>>  1. Introduction
  
<snip>

> forwarding

ok

> shall be returned back to the originator.

For scenario 1, as the UE has no global addresses, I think it would be useful to make it clearer that a /64 'connected' route, pointing out the LAN interface needs to be configured when the UE goes from being a host to a router, and in contrast, it may be useful to mention that in the other scenarios, either static configuration of the global address on the LAN interface, or SLAAC configuration of an address via listening to it's own RA (with the On-Link bit switched on in the PIO), inherently create this /64 route.

> caching that requires global connectivity) and prevent proper Path MTU 

That would be fine.

>> <snip>

> model (packets

That's useful to know. It won't be performed by the kernel unless the rpfilter option has been enabled in the ip6tables firewall.

> Privacy

ok, in that case I think it would be useful to provide some text saying that if privacy addresses are enabled, the same address should be used on both interfaces, and their preferred and valid lifetimes are to decrement in parallel, such that they expire at the exact same moment.

Regards,
Mark.