Re: <draft-ietf-6man-rfc4291bis-08.txt>

[Brian E Carpenter <[e-mail]>]

On 21/06/2017 09:34, David Farmer wrote:
> I think this is getting really close.  However, there still seems to be an
> implication that a subnet must be /64 or 64 bits for both address
> generation and on-link determination.

Yes, that's what it says, except for documented exceptions. As far as I
understand the motivation of my co-authors on draft-bourbaki, their main
objection to the previous rfc4291bis was that it didn't allow for those
documented exceptions.

Since SLAAC has always assumed that the two lengths are equal, I don't
see any discrepancy between rfc4291bis-08 and reality, which is as it
should be for an Internet Standard.

    Brian

> 
> Subnetting (for IPv4) is discussed in a series of RFCs[1], culminating in
> the Internet Standard Subnetting Procedure [RFC950].  The closest thing to
> a definition for the term subnet comes in the overview for RFC950. Subnets
> "are logically visible sub-sections of a single Internet network." However,
> it seems clear that the term is equally important to two of the aspects we
> are talking about, it is about both address generation and on-link
> determination.
> 
> If RFC4291bis is going to use the term subnet, it's use should either be
> consistent with the meaning in RFC950, or it should be abundantly clear how
> the use of the term differs from it's use in RFC950.  There should be no
> ambiguity, unless clearly stated otherwise, the term subnet means what it
> means in RFC950. In fact let's be clear, the reason the term is being used
> here is because of the comfort level that comes from the decades of use of
> the term as derived from it's RFC950 meaning.
> 
> Because the current use of the term "subnet" in RFC4291bis-08 doesn't seem
> to distinguish between address generation and on-link determination, there
> still seems to be an implication that a subnet must be /64, or 64 bits, for
> both address generation and on-link determination.
> 
> One possible way to break this improper implication, would be to qualify
> the statement that Interface Identifiers are 64 bits long to address
> generation and add to the note that for on-link determination prefixes and
> IIDs can be any length.  How about something like this;
> 
>    When generating an address, Interface Identifiers are required to be
> 
>    64 bits long except if the first three bits of the address are 000,
> 
>    when addresses are manually configured, or by exceptions defined in
> 
>    standards track documents. The rationale for using 64 bit Interface
> 
>    Identifiers can be found in [RFC7421
> <https://tools.ietf.org/html/rfc7421>].  An example of a standards
> 
>    track exception is [RFC6164 <https://tools.ietf.org/html/rfc6164>]
> that standardizes 127 bit prefixes on
> 
>    inter-router point-to-point links.
> 
> 
>       Note: In the case of on-link determination and as a result when
> 
>       a prefix length is provide with a manually configured address, the
> 
>       Prefix and Interface Identifier can be any length as long as they
> 
>       add up to 128, but are recommended to be 64 bits.
> 
> 
> Also, based on the definition of subnet, in section 2.4.4 it seems critical
> that m>=1.  If it is not and m=0, then we can't be talking about /64
> subnets, we are talking about a /64 network.  Therefore, "m" must be
> greater than or equal to 1, for you to even be properly talking about the
> term subnet in IPv6 addressing. Besides adding that point to this section,
> a reference to RFC6177 seems appropriate too.
> 
> Thanks
> 
> David Farmer
> 
> [1] RFC917, RFC925, RFC932, RFC936, RFC940
> https://tools.ietf.org/html/rfc917
> https://tools.ietf.org/html/rfc925
> https://tools.ietf.org/html/rfc932
> https://tools.ietf.org/html/rfc936
> https://tools.ietf.org/html/rfc940
> https://tools.ietf.org/html/rfc950
> 
> On Tue, Jun 20, 2017 at 7:14 AM, Bob Hinden <[e-mail]> wrote:
> 
>> Hi,
>>
>> I published a new 6man w.g. version (-08) of the RFC4291bis draft.  See
>> links below.
>>
>> The summary of the changes are:
>>
>>         o  Added Note: to Section 2 that the term "prefix" is used in
>>            different contexts in IPv6: a prefix used by a routing
>>            protocol, a prefix used by a node to determine if another
>>            node is connected to the same link, and a prefix used to
>>            construct the complete address of a node.
>>
>>         o  Based on results of IETF last call and extensive w.g. list
>>            discussion, revised text to clarify that 64 bit Interface IDs
>>            are used except when the first three bits of the address are
>>            000, or addresses are manually configured, or when defined by
>>            a standard track document.  This text was moved from
>>            Section 2.4 and is now consolidated in Section 2.4.1. Also
>>            removed text in Section 2.4.4 relating to 64 bit Interface
>>            IDs.
>>
>>         o  Removed instruction to IANA fix error in Port Number
>>            assignment.  IANA fixed the error on 4 March 2017.
>>
>>         o  Editorial changes.
>>
>> A diff from the previous version is available at:
>>
>>   https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-rfc4291bis-08
>>
>> This is part of the project to move the core IPv6 specifications to
>> Internet Standard.
>>
>> Thanks,
>> Bob
>>
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>