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

[Alexandre Petrescu <[e-mail]>]

agreed with some of the things that I cut but I have one question.

Le 06/03/2017 à 19:46, Lorenzo Colitti a écrit :
> If we allow the boundary to change, there is a near certainty that
> too-small subnets *will* be configured in some places,

and is IETF a place to make recommendations of making big or small
subnets?  Isnt it for the RIRs to make such recommendations?

I mean RIRs decide what to allocate, when there is shortage or not.

But with 64 you seem to be wanting to keep a limit there in order to be
able to unlimit later, or something like that, right?

Alex

> 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]
> <mailto:[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] <mailto:[e-mail]> Networking &
> Telecommunication Services Office of Information Technology
> University of Minnesota 2218 University Ave SE        Phone:
> 612-626-0815 <tel:(612)%20626-0815> Minneapolis, MN 55414-3029 Cell:
> 612-812-9952 <tel:(612)%20812-9952>
> ===============================================
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail]
> <mailto:[e-mail]> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> <https://www.ietf.org/mailman/listinfo/ipv6>
> --------------------------------------------------------------------
>
>
>
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>