Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07

[james woodyatt <[e-mail]>]

On Mar 8, 2017, at 13:54, Timothy Winters <[e-mail]> wrote:
> 
> Since this was added in the update from RFC 2461 to 4861 I went to go look for why this was added and found the following thread.
> 
> Discussion:
> https://mailarchive.ietf.org/arch/search/?email_list=ipv6&q=Requirement+for+64bit+I%2FF+ID&so=date&gbt=1&index=rJtLf5Krh0X9vg3vYts_xO1oUCw <https://mailarchive.ietf.org/arch/search/?email_list=ipv6&q=Requirement+for+64bit+I/F+ID&so=date&gbt=1&index=rJtLf5Krh0X9vg3vYts_xO1oUCw>
> 
> Final Decision:
> https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4 <https://mailarchive.ietf.org/arch/msg/ipv6/IfWdv79U0k9PbwK6-lAIk4yeyK4>
> 
> This is clearly about the spirit of this clarification, the working group when adding this text wanted to allow prefix lengths much larger then 64 (80 is the example).

I think the most we can say there is that the working group wanted to reserve power in the future to define new link types (or revise existing link types) to allow for standard use of an IID length other than 64 bits (for example 48 bits).

There appears to be no evidence in that thread that the working group wanted to REQUIRE hosts to accept PIO elements for purposes of on-link determination even when their Prefix Length is invalid for address configuration on the link type in use.

I discussed this in detail in my long previous message reviewing this text.

 	<https://mailarchive.ietf.org/arch/msg/ipv6/oZ3dnjn3-tl8y1Gypgo3Eycco6g <https://mailarchive.ietf.org/arch/msg/ipv6/oZ3dnjn3-tl8y1Gypgo3Eycco6g>>

The relevant excerpt of my previous message follows:

>> But we’re not done. RFC 4862 continues:
>> 
>> >> It is the responsibility of the system administrator to ensure that the lengths of prefixes contained in Router Advertisements are consistent with the length of interface identifiers for that link type.
>> 
>> I do not read this as any requirement on the host implementer to accommodate system administrators who use Prefix Length values that are not consistent with the IID length defined for the link type in use.
>> 
>> >> It should be noted, however, that this does not mean the advertised prefix length is meaningless.
>> 
>> This is informative and helpful, and not normative text.
>> 
>> >> In fact, the advertised length has non-trivial meaning for on-link determination in [RFC4861] where the sum of the prefix length and the interface identifier length may not be equal to 128.
>> 
>> Indeed, as I read RFC 4861, this recognizes *explicitly* that hosts MAY use advertised prefixes with invalid Prefix Length for address configuration, for example, for the purpose of on-link determination.
>> 
>> >> Thus, it should be safe to validate the advertised prefix length here, in order to detect and avoid a configuration error specifying an invalid prefix length in the context of address autoconfiguration.
>> 
>> This is not in conflict with the observation of RFC 4861 that processing Prefix Lengths for on-link determination that are invalid for address configuration is not REQUIRED and merely OPTIONAL. 
>> 
>> >> Note that a future revision of the address architecture [RFC4291] and a future link-type-specific document, which will still be consistent with each other, could potentially allow for an interface identifier of length other than the value defined in the current documents.  Thus, an implementation should not assume a particular constant.  Rather, it should expect any lengths of interface identifiers.
>> 
>> As I read this excerpt, this is RFC 4862 expressly recognizing that future standards action could introduce new valid IID lengths for address configuration other than 64 bits. This hasn’t happened yet. (And there is still some controversy about whether RFC 4291 should not be revised unless it is changed to do so.)

In a forthcoming message, I will propose text for inclusion in I-D.ietf-6man-rfc4291bis with the hope that it may help clarify this matter further.


--james woodyatt <[e-mail] <mailto:[e-mail]>>