Re: A 3rd try at a proposal for draft-ietf-6man-rfc4291bis-07

[Lorenzo Colitti <[e-mail]>]

Wow. That's a lot of for what started off as a reclassification. I don't
think it's a good idea to attempt to wordsmith RFC4291 hoping that one of
the formulations we end up with will somehow reach consensus. Instead, I
would suggest another approach: see what the problems with 4291 are, *write
them down*, and only then write a document explaining what should be
changed and why.

In other words: start with a problem statement.

As for the suggestions themselves: I think allowing non-/64 prefix lengths
on any network that provides service to general purpose hosts is a bad
idea, regardless of whether it uses SLAAC, DHCPv6, or any other address
assignment protocol (no objection to manual configuration). I think it will
lead to some networks will shooting themselves in the foot, or, worse,
impairing their users' connectivity by creating subnets that are too small.

Before everyone rushes to tell me "nobody will do something that silly",
"it's not the IETF's place to prevent people from doing something stupid",
or even "I will recommend that to my competitors" - please think a little
bit bigger. The reality is that there are lots of networks out there, and
lots of administrators that have never read an RFC and will just copy over
whatever configuration they have from IPv4.  (I have a /24 today? Ok, so I
need to use a /120. I have DHCPv4, so I should use DHCPv6 and everything
will work. Easy!) There are also lots of host developers who are similarly
uninformed, and will just try stuff until it works, or just port whatever
code they have in IPv4 to IPv6. If we allow the boundary to change, there
is a near certainty that too-small subnets *will* be configured in some
places, and over time, host software will adapt to the lowest common
denominator. There is a very real risk end up with solutions that "mostly
work most of the time" - things like NAT traversal, and NAT keepalives -
over more robust solutions that rely on strong guarantees from the network
layer. The risk is that the IPv6 Internet will be constrained by IPv4
address scarcity even after IPv4 is gone.

It's up to us to avoid that risk. I continue to be amazed by the people on
this thread who are advocating that we run it.

On Tue, Mar 7, 2017 at 3:06 AM, David Farmer <[e-mail]> wrote:

> A few more tweaks, corrections and other changes some based on feed back;
>
> 1. IPv6 unicast routing is 128 bits in length [BCP198]/[RFC7608], AKA not
> classful!
> 2. SLAAC is commonly used to generate unicast addresses, therefore subnet
> prefixes and IIDs are 64 bits for most address.
> 3. Explicitly allow subnet prefix lengths other than 64 bits for manually
> config and DHCPv6 while still recommending 64 bits (most code does this now
> and has since the beginning)
> 4. IIDs of 64 bit are REQUIRED for SLAAC, except when overridden by an
> IPv6-over-foo doc  (we really can't change 64 bit IIDs for SLAAC, it would
> break running code, at least not right now, maybe in the future)
> 5. Sites should get more than a single /64 [BCP157]/[RFC6177], and sites
> include mobile
> 6. Avoid other explicit exceptions or recommendations for longer prefixes,
> like RFC6164
> 7. include references to [BCP204]/[RFC7934] and [RFC6052] in the right
> places
>
> In the current draft, remove the 2nd paragraph of 2.4, then add the
> following sentence to the end of the first paragraph of 2.4;
>
>    Furthermore, IPv6 unicast routing is based on prefixes of any length up
> to 128 bits
>    [BCP198].
>
> Then add the following two paragraphs at the end of section 2.4;
>
>    Stateless Address Autoconfiguration(SLAAC)[RFC4862] is commonly used
>    to automatically create unicast addresses, therefore most unicast
>    addresses have 64-bit subnet prefixes and 64-bit interface IDs. The
>    rationale for the 64-bit boundary in IPv6 addresses can be found in
>    [RFC7421].
>
>    Nevertheless, unicast addresses may also be provided from a node's
>    internal configuration (AKA manual or static configuration) or via
>    Dynamic Host Configuration Protocol version 6(DHCPv6)[RFC3315]. Such
>    addresses are assumed to be opaque 128-bit strings without any
>    internal structure. These addresses may be associated with subnet
>    prefixes of any length, while 64-bit subnet prefixes are recommended.
>
> Then replace the 4th paragraph of 2.4.1 with;
>
>    When unicast addresses are automatically created from a subnet prefix
>    and a interface ID (e.g. Stateless Address Autoconfiguration(SLAAC)
>    [RFC4862]), a 64-bit interface ID length is required. An "IPv6 over
>    <link>" specification may modify this requirement for a specific link
>    type. The rationale for the 64-bit boundary in IPv6 addresses can be
>    found in [RFC7421].
>
> And replace 2.4.4 with;
>
>    The general format for IPv6 Global Unicast addresses is as follows:
>
>    |         n bits         |   m bits  |       128-n-m bits         |
>    +------------------------+-----------+----------------------------+
>    | global routing prefix  | subnet ID |       interface ID         |
>    +------------------------+-----------+----------------------------+
>
>    where the global routing prefix is a (typically hierarchically-
>    structured) value assigned to a site (a cluster of subnets/links in
>    a location or mobile), the subnet ID is an identifier of a link
>    within the site, and the interface ID is as defined in Section 2.4.1.
>
>    As noted in Section 2.4, most unicast addresses, including Global
>    Unicast addresses, have 64-bit interface IDs (i.e., n + m = 64).
>
>    As discussed in [BCP 157], "it should be easy for an end site to
>    obtain address space to number multiple subnets (i.e., a block larger
>    than a single /64)" or in other words the subnet ID length should be
>    greater than or equal to 1 (i.e., m >= 1). Subnet ID lengths of 4, 8,
>    12, and 16 bits, and therefore global routing prefix lengths of 60,
>    56, 52, and 48 bits respectively, are in common use and recommended.
>
>    Dynamic Host Configuration Protocol version 6 - Prefix Delegation
>    (DHCPv6-PD)[RFC3633] is commonly used to automate the distribution of
>    global routing prefixes to sites.
>
>    Global Unicast addresses, and their format, are discussed further in
>    [RFC3587].
>
> A couple other quickies;
>
> Insert new paragraph at the end of 2.1
>
>    [BCP 204] recommends that networks provide general-purpose nodes with
>    multiple global IPv6 addresses per interface when they attach to a
>    link, it also describes the benefits of and the options for doing so.
>
> Insert new sentence at the end of 2.4.5
>
>    Additional IPv6 address that carry an IPv4 address are defined in IPv6
>    Addressing of IPv4/IPv6 Translators [RFC6052].
>
> Thanks
>
> --
> ===============================================
> 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>
> ===============================================
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>