Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC

[Jouni Korhonen <[e-mail]>]

RAy,

On May 14, 2013, at 9:55 AM, Ray Hunter <[e-mail]> wrote:

> Quote draft-ietf-v6ops-rfc3316bis:
> "The Router Advertisement contains a maximum
>   of one prefix information option and the advertised prefix cannot
>   ever be used for on-link determination (see [RFC6459], Section 5.2)."
> 
> Quote RFC4862:
> Router Advertisements also contain zero or more Prefix Information
>   options that contain information used by stateless address
>   autoconfiguration to generate global addresses.
> 
> What breaks if an end device supports receiving more than one PIO in an RA?

Probably nothing. There just are no gateways that would put more than one
PIO in an RA.

The language is there just because 3GPP specs are explicit on stating it 
as a restriction to SLAAC.

> Advising implementers of cellular hosts to box themselves into a corner
> based on the current implementation of the network equipment would seem
> to me to be a bad idea if it isn't absolutely necessary.

Well.. I do not disagree here :)

> Section 2.6. "Consequently, sending MLD reports for link-local addresses
> in a 3GPP environment may not always be necessary"
> 
> What does this tell me as a developer? How do I discover this?
> Is it harmful to never send MLD? Is it harmful to always send MLD?
> That I need to try once and see if sending MLD is necessary (to avoid
> unnecessary 3gpp traffic)?

Right. I could say "Consequently, sending MLD reports for link-local
addresses in a 3GPP environment is not necessary" That would be more
explicit?

> Section 2.7
> What has RFC 4941 got to do with 3gpp link technology and corner cases?
> 
> 6459 says "RFC 4941 or other similar types of mechanisms."
> draft-ietf-v6ops-rfc3316bis says "Privacy Extensions for Stateless
> Address Autoconfiguration [RFC4941] should be supported."
> 
> What breaks if other privacy mechanisms are used, so that
> draft-ietf-v6ops-rfc3316bis has been sharpened to SHOULD support 4941?
> Or none?

Right. I can reword this similar to RFC6459. 

> Section 2.9 Is this kludge forever?

Dunno.

> What is fundamentally wrong in the long term with unnumbered links?

Nothing. It is just not an option with 3GPP link model (and do not refer
here to 64share that shows what one do with a host implementation).

> What is fundamentally wrong in the long term with the radio provider
> using their own IPv6 space for the radio link, and delegating an entire
> contiguous block to the user to allocate.

Nothing. 

Just to point out that "we tried we failed". I am actually happy that
we even got DHCPv6 PD into specs instead of something more "ingenious".

> (which is what the majority of other IP networks do AFAIK).
> 
> 
> Section 2,10
> 
> "The cellular host should implement the Default Router Preferences and
> More-Specific Routes extension to extension to Router Advertisement
>   messages [RFC4191]. These options me be useful for cellular hosts
> that also have additional interfaces on which IPv6 is used."
> 
> Wasn't this specifically declared out of scope in Section 1.1? "If a
> cellular host has additional interfaces on which IP is used, (such as
> Ethernet, WLAN, Bluetooth, etc.) then there may be additional
> requirements for the device, beyond what is discussed in this document."

Right. So you want that removed?

- JOuni