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

From: David Farmer <[email-masked]>
Date: Fri, 3 Mar 2017 07:54:44 -0600

Modified the goals a bit based on feedback;

1. IPv6 unicast routing is 128 bits in length [BCP198], AKA not classful!
2. Subnet Prefixes and IIDs are usually 64 bits
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
4. Sites should get more than a /64 [BCP157]
5. Explicitly allow prefix lengths other than 64 bits for manually config
and DHCPv6, most code does this now and has since the beginning
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
   prefix and interface ID of 64 bits in length. The rationale for the
   64 bit boundary in IPv6 addresses can be found in [RFC7421].

   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
   128 bit quantity, and may be associated with a subnet prefix of any
   length.

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
   <link>" specifications. The rationale for the 64 bit boundary in
   IPv6 addresses can be found in [RFC7421].

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
   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 great than or equal to 1 (i.e., m >= 1), with typical
   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.

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.

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:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 3 Mar 2017 15:21:24 +0100

> 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

> 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
                                                       ^ in some places
>    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!"

>    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

I agree.

>    to be 64 bits in length unless overridden in an "IPv6 over

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

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

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

>    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
>    global routing prefix lengths of 60, 56, 52, and 48 bits

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

>    they attach to a link, describes the benefits of and the options

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

> <mailto:[email-masked]>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>