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

[David Farmer <[e-mail]>]

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.

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
>

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone] <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================