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

[Alexandre Petrescu <[e-mail]>]

DAvid,

I think we talk past each other.  But I will duly continue to complain
about this :-)

Le 06/03/2017 à 19:06, David Farmer a écrit :
> 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.

This is a wrong assumption.  Because of this assumption there are very
bad consequences in the 3GPP networks.

> 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)

Also allow them explicitely for SLAAC as well.

Allow it for LL prefixes as well.

> 4. IIDs of 64 bit are REQUIRED for SLAAC, except when overridden by
> an IPv6-over-foo doc

Really vice-versa: they are variable by default when considered by SLAAC.

I think you dont want to accept it, but it's in the RFC.

> (we really can't change 64 bit IIDs for SLAAC, it would break running
> code, at least not right now, maybe in the future)

That is what you think.

Sending a RA /65 wont break an existing linux kernel, and new kernels
may use 48bit IIDs out of 48bit MAC addresses, pad some 0s, and make a
128 address.

I dont undersrtand what you mean by "changing 64bit IIDs for SLAAC would
break running code."

The person complaining about non-64bit IIDs, as I understand it,
complains about non-64bit IIDs *for 464xlat*, not for SLAAC.

> 5. Sites should get more than a single /64 [BCP157]/[RFC6177], and
> sites include mobile

Yes, that is a requirement.  Mobile entities including 3GPP UEs MUST get
more than a single /64.  And that conflicts headfront with some 3GPP
spec.  That conflict should be solved, not attenuated.

Until then we are not in a good position to safely assume that nodes get 
more than a single /64 per node.

> 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.

This is wrong, again.

SLAAC does not require 64bit IIDs.  It is Ethernet who does.

SLAAC works with 48bit IIDs.


> An "IPv6 over <link>" specification may modify this requirement for a
> specific link type.

This is a good requirement.

But, most IPv6-over-foo documents _immitate_ Ethernet.  I.e. 64+64. 
Continue this way and no IP-over-foo will ever dare to not immitate 
Ethernet.

> 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).

This is so wrong, please remove it.
There are many GUAs there that dont have 64bit IIDs.  Sometimes the IID 
is just 1.

> As discussed in [BCP 157], "it should be easy for an end site to

And how about a mobile?

Actually it is not that easy, as you can see.  As such dont make the 
assumption.

> 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.

Because your assumption for sites does not hold true for mobiles these 
latter find themselves in the impossibility to actually exist.

Were it easy for mobiles to obtain multiple /64s then I would agree with 
you to continue with this 64.  But it is not.

>
> Dynamic Host Configuration Protocol version 6 - Prefix Delegation
> (DHCPv6-PD)[RFC3633] is commonly used to automate the distribution
> of global routing prefixes to sites.

So one would expect that to Mobiles as well, but no.

Alex

>
> 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] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>