Re: Another try at a proposal for draft-ietf-6man-rfc4291bis-07

[Alexandre Petrescu <[e-mail]>]

Le 03/03/2017 à 14:54, David Farmer a écrit :
> Modified the goals a bit based on feedback;
>
> 1. IPv6 unicast routing is 128 bits in length [BCP198], AKA not classful!

Ok for me.

> 2. Subnet Prefixes and IIDs are usually 64 bits

s/usually/in some places

> 3. IIDs of 64 bit are REQUIRED for SLAAC, except when overridden by an
> IPv6-over-foo doc, and we can't change 64 bit IIDs for SLAAC, at least
> not now, it would break running code

We cant change but we MAY

> 4. Sites should get more than a /64 [BCP157]

Sites _and_ smaller devices like when they are mobile

> 5. Explicitly allow prefix lengths other than 64 bits for manually
> config and DHCPv6, most code does this now and has since the beginning

With bugs.

> 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 two paragraphs at the end of section 2.4
>
>    IPv6 unicast routing is based on prefixes of any length up to 128
>    bits [BCP198]. However, unicast addresses usually have a subnet
                                                       ^ in some places
>    prefix and interface ID of 64 bits in length. The rationale for the
>    64 bit boundary in IPv6 addresses can be found in [RFC7421].

I disagree with some parts of that RFC.  Why citing it in its entirety? 
The text reads as if we use that RFC to motivate cotninuing with the 
64bit split.

Why not citing just its par 3 of section 1: "The notion of a /64 
boundary in the address was introduced after the initial design of IPv6, 
following a period when it was expected to be at /80.  There were two 
motivations for setting it at /64.  One was the original "8+8" proposal 
[ODELL] that eventually led to the Identifier-Locator Network Protocol 
(ILNP) [RFC6741], which required a fixed point for the split between 
local and wide-area parts of the address.  The other was the expectation 
that 64-bit Extended Unique Identifier (EUI-64) Media Access Control 
(MAC) addresses would become widespread in place of 48-bit addresses, 
coupled with the plan at that time that auto-configured addresses would 
normally be based on interface identifiers derived from MAC addresses."

And add: since then we did this (quoting a poster to this list)
> RFC 3513 "only /64 is valid"
> RFC 3627 "don't use /127, use /126 if you must"
> RFC 4291 "reaffirming: only /64 is valid"
> RFC 6164 "a /127 is OK to use too"
> RFC 6583 "there are problems with /64"
> RFC 7421 "/64 is the best!"
> RFC 7608 "every prefix length must be forward-able"
> RFC 4291bis-07 "fine, /64 and /127 are valid, but nothing else!"

>    Nevertheless, a unicast address may also be provided from a node's
>    internal configuration or via DHCPv6[RFC3515], such addresses are
>    assumed to have no internal structure, are treated as a single
                      ^^^^^^^^^^^^^^^^^^^^^

That is 'opaque'.  I would like that to be stressed, especially in this 
context of this document where we set many bits and limits at many places.

>    128 bit quantity, and may be associated with a subnet prefix of any
>    length.

I agree.

> Then replace the 4th paragraph of 2.4.1 with;
>
>    When a unicast address is formed from a subnet prefix and an
>    automatically generated interface ID (e.g. Stateless Address
>    Autoconfiguration(SLAAC)[RFC4862]), the interface ID is required
>    to be 64 bits in length unless overridden in an "IPv6 over

'overriden' there sounds like somebody comes after.  How about saying 'MAY'?

>    <link>" specifications. The rationale for the 64 bit boundary in
>    IPv6 addresses can be found in [RFC7421].

Again citing that RFC, again as a 'rationale'.  Again how about citing 
just its par 3 of its section 1.

> And replace the second and third paragraphs of 2.4.5 with;
>
>    As noted in Section 2.4, Global Unicast addresses usually have
>    a 64-bit interface ID length (i.e., n + m = 64), and are
>    formatted as described in Section 2.4.1.
>
>    As discussed in [BCP 157], "it should be easy for an end site to

for an end site and for an end-user on computer that could route IP packets.

>    obtain address space to number multiple subnets (i.e., a block
>    larger than a single /64)" or in other words the subnet ID length

This use of word 'larger' when talking /plens is always ambiguous. 
Because larger value of plen means smaller number of IP addresses, and 
to others no.

It's clearer if we said: 'a unique block defined by a prefix length of 
value smaller than 64'.  And instead of i.e., we could say 'e.g.', 
because one is as happy if she gets two /64s as if she gets one /63. 
And that is impossible if the text says 'id est a block'.

>    should be great than or equal to 1 (i.e., m >= 1), with typical
                     ^er
>    subnet ID lengths of 4, 8, 12, and 16 bits and therefore typical
>    global routing prefix lengths of 60, 56, 52, and 48 bits
>    respectively.

Typical... when talking prefix lenghts I really wouldnt call one 
typical.  Not even 64.

> 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, describes the benefits of and the options
>    for doing so.

I agree.  Further: in addition to BCP204 recommendation, the networks 
MUST provide multiple /64s, or other-than-64-prefixed subnets to nodes, 
if so requested by the nodes.

Alex

> 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: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>