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

[Mark Smith <[e-mail]>]

Hi  Vízdal,


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

<snip>

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

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

>>  1. Introduction
>>  ~~~~~~~~~~~~
>> 
  
<snip>

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

ok

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

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.
 

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

That would be fine.

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

>> <snip>

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

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

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

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.