Subject: Re: Subject: Confirming consensus on adopting draft-carpenter-6man-why64

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 11:49:33 -0400

On Thursday, March 13th 2014, at 09:15:25 -0500, David Farmer wrote:
> While prefix lengths between /65 and /126 are currently 
> operationally invalid, not currently specified, 
> they are architecturally valid. 

I completely disagree.  

That NEVER has been true for unicast addresses, and is an
example of confusion rather than a fact.  

As some here will recall, I've been involved with IPv6 even before 
it was called IPv6.  I also led the team with the world's first IPv6 
packet working on the wire (we made a good guess about the decision 
and had it working the week before) in our open-source 4.4 BSD 
implementation.  So I've been involved with IPv6 for a couple of 
decades now.

ONLY the unicast *routing-prefix* is VLSM, and that does NOT 
include the fixed-length 64-bit IID.  

The IID is just an IID and has NEVER been VLSM.   Prefix lengths 
longer than /64 NEVER have been valid, EXCEPTING the relatively recent 
special-case for point-to-point links.  This was added ONLY to resolve 
an operational-security bug in certain deployed routers' IPv6 
point-to-point code.

> So,it needs to be reinforce that VLSM 

ONLY true for the routing-prefix, not for the whole 128-bit object.

> and a variable a length IID are fundamental to the IPv6 architecture, 

This has NEVER been true.

> and all IPv6 stacks must be able to deal with these prefix lengths 
> if/when they are specified as operationally valid.  If this weren't 
> the case then it would have been operationally impossible to implement 
> RFC6164 without major stack rewrites.

I completely disagree, both with your desires and with your 
mis-representation of what happened historically.

At least some major stack rewrites occurred.  Multiple router 
implementations that I'm aware of had to be quickly updated,
and their operators had to deploy new images quickly also.

Multiple currently deployed router implementations treat the /126 prefix 
VERY MUCH as a "special case" -- and added that code after the bug in 
one router's point-to-point implementation became an operational problem.

Instead, this document needs to be very clear that IIDs are
fixed length (both architecturally and for engineering), 
always have been fixed length, and that IIDs are NOT VLSM.

Yours,

Ran Atkinson

---

From: David Farmer <[email-masked]>
Date: Thu, 13 Mar 2014 13:41:28 -0500

> This has NEVER been true.

I have to disagree back, RFC 4291 "IP Version 6 Addressing 
Architecture", section 2.5 "Unicast Addresses", makes it clear that the 
Interface Identifier is architecturally a variable length field.

https://tools.ietf.org/html/rfc4291#section-2.5

Further, in section 2.5.1 " Interface Identifiers", specifies IIDs of 64 
with the following exception.

    For all unicast addresses, except those that start with the binary
    value 000, Interface IDs are required to be 64 bits long and to be
    constructed in Modified EUI-64 format.

I'll admit I don't fully understand the intent, implications, or nuances 
of this exception.  If the draft could clarify the intent, nuances, and 
usages of this exception maybe there would be less controversy on the 
subject.

In any case I think the clear intent of section 2.5 is to leave open 
future specification other IID lengths than /64.

> always have been fixed length, and that IIDs are NOT VLSM.

Then modify section 2.5 of RFC 4291, either taking "n" out of that 
section or clearly specify "n = 64 only" in that section and I'll 
happily shut up.  Most people I know feel it leaves the door open to 
other IID sizes.  Or, at least clarify the intent of the exception text 
in section 2.5.1.

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

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: [email-masked]
Date: Thu, 13 Mar 2014 21:35:38 +0100 (CET)

> include the fixed-length 64-bit IID.  

If that had been the case, I would have expected this fact to be
spelled out in BIG BOLD LETTERS in the IPv6 specifications.

But I haven't seen this. On the contrary, I've seen plenty of claims
that we have 128-bit addresses and longest prefix match applies to
the whole address. This is also the observed behavior for the vendors
I'm most familiar with.

> an operational-security bug in certain deployed routers' IPv6 

In practice, prefix lengths longer than /64 have been configurable on
equipment from major vendors - for many years.

I think it'll be difficult to change that now.

Steinar Haug, AS 2116

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 16:55:36 -0400

On 13  Mar 2014, at 16:35 , [email-masked] wrote:
> In practice, prefix lengths longer than /64 have been configurable
> on equipment from major vendors - for many years.

For limited use in point-to-point router links, sure,
but please also see the notes earlier today from Lorenzo Colitti, 
Steve Blake, and others about the significant limitations
in the deployed IPv6 routers.

Ran

---

From: joel jaeggli <[email-masked]>
Date: Thu, 13 Mar 2014 14:04:15 -0700

>> an operational-security bug in certain deployed routers' IPv6 

rfc 3513 / 4291 disagre.

        inet6 ::1 prefixlen 128

1884 is ambigious with respect to the/a loopback bitmask.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 13 Mar 2014 21:42:27 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of RJ Atkinson

> in the deployed IPv6 routers.

Very interesting exchange. No doubt this is a question of perceptions and interpretation. From my perspective, however, as long as addresses with 000 leading bits can use prefix lengths >64, the point is almost moot. Any box that can't handle variable length prefixes, including >64, is non-compliant. Is this meant only for point to point links? Beats me. I never thought it was.

Perhaps instead it was meant to deliberately PREVENT any sort of hard-coding of 64 bits as IID, for all time. Or if that wasn't its intent, it should have been. I've been going by RFC 3513 on this, from back when. Check out the graphic on p. 7. Not only does it say that IID length is 128-n, it also shows the prefix to be considerably wider than the IID.

---------------------------
   IPv6 nodes may have considerable or little knowledge of the internal
   structure of the IPv6 address, depending on the role the node plays
   (for instance, host versus router).  At a minimum, a node may
   consider that unicast addresses (including its own) have no internal
   structure:

   |                           128 bits                              |
   +-----------------------------------------------------------------+
   |                          node address                           |
   +-----------------------------------------------------------------+

   A slightly sophisticated host (but still rather simple) may
   additionally be aware of subnet prefix(es) for the link(s) it is
   attached to, where different addresses may have different values for
   n:

   |                         n bits                 |   128-n bits   |
   +------------------------------------------------+----------------+
   |                   subnet prefix                | interface ID   |
   +------------------------------------------------+----------------+

   Though a very simple router may have no knowledge of the internal
   structure of IPv6 unicast addresses, routers will more generally have
   knowledge of one or more of the hierarchical boundaries for the
   operation of routing protocols.  The known boundaries will differ
   from router to router, depending on what positions the router holds
   in the routing hierarchy.
----------------------------

Then it discusses EUI-64s, which I always took as being a possible way to configure IIDs, and one that I'd probably not use (because it would tie me to the hardware address).

A long-winded way of saying, my own perception was certainly not one of 64-bit IIDs being practically hard-coded.

Bert

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 18:54:48 -0400

On 13  Mar 2014, at 17:42 , Manfredi, Albert E wrote:
> From my perspective, however, as long as addresses with 000 leading bits
> can use prefix lengths >64, the point is almost moot.

Well as of RFC-3513, Section 4, as updated by RFC-4291, 
all addresses starting with 000 fall into one of these 
possible categories:

- "Loopback" which is a special-case IPv6 address,
  just as it was for IPv4.  This NEVER appears on-the-wire
  according to RFC-3513 and RFC-4291.

- "Unspecified", which is another special-case and again
   this NEVER appears on-the-wire according to RFC-3513 
   and RFC-4291.

- "Embedded IPv4 address" and "Mapped IPv4 address" which 
   for routing/path consistency ought have been looked up 
   using the IPv4 routing table (RIB/FIB) if encountered.  
   RFC-4291, Section 4, formally deprecated the "IPv4-
   compatible IPv6 address", while the IPv4 Mapped IPv6
   address" is still defined for use as per [RFC-4038]
   which is not an on-the-wire use.

- Reserved for (ISO) NSAP Allocation
  As far as I am aware, this hasn't been supported or used ever.
  If they had been, they ought to have been looked up in 
  an ISO NSAP routing table (RIB/FIB).  I haven't run into
  any mention of CLNP deployments since I left Cisco in 1997.
  RFC-4291, Section 4, formally deprecated these.

- Unassigned
  This part of '000' block hasn't been specified, supported, or used.

All of the above are special cases of one sort or another.
RFC-3513, Section 2.5 explicitly uses the phrase 
"special-purpose subtypes of global unicast, such as IPv6
addresses with embedded IPv4 addresses or encoded NSAP
addresses".

RFC-4291, Section 4, says that 0000:/8 is "Reserved by
IETF", which is different from "Unassigned", and indicates
that the 0000 block is for IETF special uses (e.g. loopback).
The 0001 block is marked as "Unassigned", but IANA has been
told (RFC-3513, Section 4, Note 2) to only assign IPv6
unicast addresses from 001.  

***

So there are NO valid IPv6 addresses that appear 
on the wire that begin with 000.

***

If the IETF ever revises RFC-4291, perhaps it would be helpful
to explicitly say that addresses beginning with "000" all are 
special-use (or special-case) addresses, as different from 
ordinary global unicast addresses, to reduce confusion.

***

Embedded IPv4 addresses were originally thought of
as part of a transition strategy.  I don't recall ever
seeing one in a production network.  I do recall a 
conversation with the UUNET CTO back in 1996 about those.  
He was very clear that he did not want to have 2 
possibly-different sources of truth for handling IPv4 
addresses (and sources of truth for associated IPv4 routes).

So there isn't actually a clear requirement for existing IPv6
routers to support prefix-lengths between /64 and /127,
and there historically hasn't been either, EXCEPT for
the additional special-case of point-to-point router links.  

RFC-6164, Section 1 repeats that interface IDs are 64-bits
long (with the 000 carve-out for the special-use address block)
and then says there is an additional special exception for
router-to-router point-to-point links to use /127.  The
specific requirement for routers from RFC-6164 says:

	"Routers MUST support the assignment of /127 prefixes 
	on point-to-point inter-router links.  Routers MUST 
	disable Subnet-Router any cast for the prefix when 
	/127 prefixes are used."

The words "variable", "variable-length", and "mask" do
not appear in RFC-6164.  The draft also does not require
routers to support prefix lengths between /64 and /127,
hence the related comments recently from Steve Blake and 
Lorenzo Colitti.

Yours,

Ran

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Mar 2014 16:29:17 -0700

Ran,

I agree with your overall conclusion.

>     this NEVER appears on-the-wire according to RFC-3513

Unspecified is never a destination (which is what matters from a 
forwarding perspective).
I can be used as a source address before the host has learned its own 
address. (DAD is an example use.)

    Erik

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 14 Mar 2014 02:06:28 +0000

> all addresses starting with 000 fall into one of these

But I still see this as a matter of interpretation or perspective. I never understood those examples to be all encompassing for all time. Because for one thing, RFCs 3513 and 4291 state:

   2.5.  Unicast Addresses

   IPv6 unicast addresses are aggregatable with prefixes of arbitrary
   bit-length, similar to IPv4 addresses under Classless Inter-Domain
   Routing.

   There are several types of unicast addresses in IPv6, in particular,
   Global Unicast, site-local unicast (deprecated, see Section 2.5.7),
   and Link-Local unicast.  There are also some special-purpose subtypes
   of Global Unicast, such as IPv6 addresses with embedded IPv4
   addresses.  **Additional address types or subtypes can be defined in
   the future.**

And more importantly, Section 4 on IANA assignments similarly says:

   2. For now, IANA should limit its allocation of IPv6 unicast address
      space to the range of addresses that start with binary value 001.
      **The rest of the global unicast address space (approximately 85% of
      the IPv6 address space) is reserved for future definition and use,
      and is not to be assigned by IANA at this time.**

And not to forget, both of these RFCs mandate use of EUI-64 for IIDs, and we know how far that's gone. Everyone seems to agree it's not a good idea.

RFC 6164 is only about inter-router /127 links. I don't see where it forbids use of longer than 64 bit prefixes.

My interpretation has always been, the majority of the IPv6 global access address space is being held aside unused for the time being, and in particular, the stipulation that the IID must be 64 bits wide. That's why I'm surprised by the hardening of this 64-bit prefix position. It seems like a bad idea, at this early stage. It's too early to be creating major obstacles for future expansion of these options, especially given the track record with IPv4 on this score.

Bert

---

From: Steven Blake <[email-masked]>
Date: Thu, 13 Mar 2014 23:00:11 -0400

On Fri, 2014-03-14 at 02:06 +0000, Manfredi, Albert E wrote:
> But I still see this as a matter of interpretation or perspective. I
> never understood those examples to be all encompassing for all time.
> Because for one thing, RFCs 3513 and 4291 state:
> 
>    2.5.  Unicast Addresses
> 

You missed Sec. 2.5.1, which states explicitly:

   For all unicast addresses, except those that start with binary value
   000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

The same unambiguous text is repeated verbatim in Sec. 2.5.1 of RFC
4291, which obsoletes RFC 3513.

The latter clause has been relaxed (e.g., RFC 4941).  That RFC muddies
the water with the following text in Sec. 1 (see last sentence):

   Stateless address autoconfiguration [ADDRCONF] defines how an IPv6
   node generates addresses without the need for a Dynamic Host
   Configuration Protocol for IPv6 (DHCPv6) server.  Some types of
   network interfaces come with an embedded IEEE Identifier (i.e., a
   link-layer MAC address), and in those cases, stateless address
   autoconfiguration uses the IEEE identifier to generate a 64-bit
   interface identifier [ADDRARCH].  By design, the interface identifier
   is likely to be globally unique when generated in this fashion.  The
   interface identifier is in turn appended to a prefix to form a
   128-bit IPv6 address.  Note that an IPv6 identifier does not
   necessarily have to be 64 bits in length, but the algorithm specified
   in this document is targeted towards 64-bit interface identifiers.

As promised, the algorithms suggested for generating randomized IIDs
assume that they are 64 bits.  And RFC 4941 does not update or obsolete
RFC 4291, so the first clause from the quoted text from RFCs 3513/4291
is still in effect.

Aside 1: RFC 4291 is updated by RFC 5952 and RFC 6052.  RFC 5952 does
not modify the address format.  I don't claim to understand RFC 6052,
but I perhaps could be persuaded that it necessitates some generalized
HW dataplane support for > 64 bit prefixes.

> And not to forget, both of these RFCs mandate use of EUI-64 for IIDs,
> and we know how far that's gone. Everyone seems to agree it's not a
> good idea.
> 
> RFC 6164 is only about inter-router /127 links. I don't see where it
> forbids use of longer than 64 bit prefixes.
> 
> My interpretation has always been, the majority of the IPv6 global
> access address space is being held aside unused for the time being,
> and in particular, the stipulation that the IID must be 64 bits wide.
> That's why I'm surprised by the hardening of this 64-bit prefix
> position. It seems like a bad idea, at this early stage. It's too
> early to be creating major obstacles for future expansion of these
> options, especially given the track record with IPv4 on this score.

RFC 4291 is still standards track, and hence valid and definitive
guidance for implementors (with the specific exception for /127 prefixes
in RFC 6164, and maybe RFC 6052 ).  I suggest that those who wish to
permit < 64 bit IIDs for unicast addresses (outside of those beginning
with binary 000) write a draft and try to advance it towards standards
track.

Aside 2: /127 prefixes do not require specialized HW support as they can
easily be deaggregated into two /128s.

Regards,

// Steve

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 14 Mar 2014 17:22:24 +0900

On Fri, Mar 14, 2014 at 3:41 AM, David Farmer <[email-masked]> wrote:

> I have to disagree back, RFC 4291 "IP Version 6 Addressing Architecture",
> section 2.5 "Unicast Addresses", makes it clear that the Interface
> Identifier is architecturally a variable length field.
>

What is there to not understand? If a global unicast address does not start
with three zero bits (i.e., if it starts with anything between 2 and F),
then the interface ID is required to be 64 bits long. If the IPv6 address
starts with 0 or 1, it's unspecified.

Then modify section 2.5 of RFC 4291, either taking "n" out of that section
> or clearly specify "n = 64 only" in that section and I'll happily shut up.

It already says "n = 64 only", for global unicast addresses that don't
start with 0 or 1. This is further clarified in RFC 3587.

I don't think the reason for controversy is that the specs are unclear. I
think the reason is that there are people don't agree that "n = 64 only" is
a good idea. Clarifying the specs won't help with that.

---

From: Ray Hunter <[email-masked]>
Date: Fri, 14 Mar 2014 09:35:19 +0100

Steven Blake wrote:
>>>> can use prefix lengths>64, the point is almost moot.

Me neither. There's no text that states "the following are the only 
address types that will ever be created for IPv6, and we'll never extend 
the protocol. Ever."

>     constructed in Modified EUI-64 format.

Yes. And we know how much "Modified EUI-64 format" has been universally 
adhered to. 6man has just been handling 
draft-ietf-6man-stable-privacy-addresses-17

>     in this document is targeted towards 64-bit interface identifiers.

SLAAC in one way a node can obtain an IPv6 address.

When did SLAAC become the *only* way a node could obtain an IPv6 address?

When did Ethernet or other IEEE EUI-64 based IPv6-over-foo documents 
become the *only* media types supported by IPv6?

> HW dataplane support for>  64 bit prefixes.
>

I agree. I think it's an extremely bad idea to say that /64 is the 
*only* supported solution, and that this is cast in stone at the 
architecture level.

I can understand a desire to simplify router to host interactions: 
especially in the determination off on and off link addresses. But that 
could be largely fixed with an extension to PIO for SLAAC and DHCPv6 to 
include an explicit informational prefix length.

I read the arguments about limitations in silicon and CAM, but those 
will go away during the lifetime of IPv6, in the same way we've gone 
from 8 bit to 64 bit generic / cheap processors in the lifetime of IPv4.

As I read 4291: Link local is assigned FE80::/10. not 
FE80:0000:0000:0000::/64 and unicast is "everything else".

I don't see any particular problem with link local being /10, as long as 
all the routers on any particular link agree which link-local packets 
not to forward.
After all, how does any node know that one particular /64 link local 
address is on link and another /64 link local address is off link?
Only by virtue of the fact that these packets are not forwarded by the 
local router.

The fact that a common LAN protocol is based on IEEE media and /64 
provides a convenient admin boundary is a completely separate 
discussion. And that some networks are point to point is also clear.

But those who run networks know there is a massive plethora of 
'IPv6-over-foo' out there, many of which are NBMA networks, and that use 
protocols for address assignment and neighbour discovery other than 
SLAAC and ND. e.g. static config + NHRP.

IMHO setting NMBA links to /64 is naive from a security perspective: 
it's asking for abuse e.g. ping pong traffic and neighbour table overflow.

There are also significant numbers of router to router isolation LANs, 
at AS/management boundaries, that require special treatment.
Today they're largely statically configured + HSRP(v6). Configuring 
these as /64 is equally unnecessary and risky IMHO.
No one in their right mind is going to have a static route pointing to a 
next hop controlled by a 3rd party that changes when the hardware changes.

> permit<  64 bit IIDs for unicast addresses (outside of those beginning

I don't see why that's necessary. My reading of the current valid 
standards documents say that it is implicitly supported already. SLAAC 
is not mandatory. YMMV without it.

> easily be deaggregated into two /128s.

As an aside on the aside: why can't NMBA, loopbacks, and other 
"special-purpose" networks also be degraded into multiple /128's?
Yes there will be more FIB and routing table entries, but your CAM 
lookups will be faster/easier.

-- 
Regards,
RayH

---

From: [email-masked]
Date: Fri, 14 Mar 2014 09:37:47 +0100 (CET)

> a good idea. Clarifying the specs won't help with that.

I think it may be both.

For myself, I had never even dreamed of VLSM and longest prefix match
being limited to 64 bits until this discussion. As I mentioned in
another message I would expect such a limitation to be spelled out
extremely clearly - and I don't think the current RFCs do so.

It would seem that there are quite a few others as well in this group.

Steinar Haug, AS 2116

---

From: joel jaeggli <[email-masked]>
Date: Fri, 14 Mar 2014 01:52:13 -0700

> draft-ietf-6man-stable-privacy-addresses-17

the addressing architecture has not alway assumed the existence of
eui-64 sized host masks either. in 1884 2.4.x has one example has a 48
bit interface id.  it goes on to suppose that longer ones might be
necessary.

That's a long time and many iterations ago.

---

From: Tim Chown <[email-masked]>
Date: Fri, 14 Mar 2014 09:00:25 +0000

Hi,

So is this discussion about what the why64 draft should say, or a separate discussion that may lead to some other document?

On 14 Mar 2014, at 08:35, Ray Hunter <[email-masked]> wrote:
> 
> Me neither. There's no text that states "the following are the only address types that will ever be created for IPv6, and we'll never extend the protocol. Ever.”

I don’t think why64 disagrees with that. why64 is documenting examples of use of non-/64, and cataloguing considerations if you choose to not use /64. It’s not precluding that, or (as Brian would say in upper case) making any protocol changes.

> Yes. And we know how much "Modified EUI-64 format" has been universally adhered to. 6man has just been handling draft-ietf-6man-stable-privacy-addresses-17

I think Fenrnado’s draft is good. I think it also doesn’t preclude use on non /64 links.

> I can understand a desire to simplify router to host interactions: especially in the determination off on and off link addresses. But that could be largely fixed with an extension to PIO for SLAAC and DHCPv6 to include an explicit informational prefix length.

Well, we tried a PIO option draft for DHCPv6 before, and that was pushed back as it was alongside a default gateway option, as one of the two missing pieces for 'DHCPv6-only’ operation.  I recall Ralph Droms was the author, if you’re interested in finding it.

> IMHO setting NMBA links to /64 is naive from a security perspective: it's asking for abuse e.g. ping pong traffic and neighbour table overflow.

The why64 text captures this as a reason for using longer prefixes. But as you said yourself on the IID length, impleentations/hardware may catch up.

> There are also significant numbers of router to router isolation LANs, at AS/management boundaries, that require special treatment.
> Today they're largely statically configured + HSRP(v6). Configuring these as /64 is equally unnecessary and risky IMHO.

And I think why64 captures that.

> I don't see why that's necessary. My reading of the current valid standards documents say that it is implicitly supported already. SLAAC is not mandatory. YMMV without it.

Indeed, and it seems anyone not doing /64 is generally either using DHCPv6 (for host links) or 'manual' configuration (router p2p).

It’s an interesting and useful discussion - but to fcous on the draft at hand which sparked it, any specific comments on why64, and improving that, are very welcome. 

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Mar 2014 22:22:01 +1300

> It would seem that there are quite a few others as well in this group.

Maybe my brain is twisted, but I have no problem holding the following
thoughts simultaneously:

1. The routing architecture is VLSM
2. The addressing architecture includes a parameter which is the
   size of an IID.
3. That parameter is set to 64 for all unicast prefixes not starting 000.
4. Some routers are less efficient for prefixes longer than 64.

    Brian

---

From: [email-masked]
Date: Fri, 14 Mar 2014 10:32:57 +0100 (CET)

> 4. Some routers are less efficient for prefixes longer than 64.

Regarding the last point - it is my impression that some people in
this discussion are really stating a stronger version: Prefixes longer
than 64 (with the possible exception of 127 and 128) *are not expected
to work* with VLSM / longest prefix match.

If my impression is correct, the distinction between your point 4 and
this stronger version is important.

Steinar Haug, AS 2116

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Mar 2014 22:36:09 +1300

Important clarification included:

>>     constructed in Modified EUI-64 format.

Please note that RFC 7136 has formally replaced that sentence by

      For all unicast addresses, except those that start with the binary
      value 000, Interface IDs are required to be 64 bits long.  If
      derived from an IEEE MAC-layer address, they must be constructed
      in Modified EUI-64 format.

  - Brian

> When did SLAAC become the *only* way a node could obtain an IPv6 address?

That's beside the point. As noted above, the addressing architecture
itself requires 64 bit IIDs.

> become the *only* media types supported by IPv6?

Also beside the point.

> *only* supported solution, and that this is cast in stone at the

But it is cast in stone in the addressing architecture, and the updated
text I quoted above is the result of a very recent WG consensus call
and IESG approval.

> it's asking for abuse e.g. ping pong traffic and neighbour table overflow.

This is discussed in the draft. Do you have any suggested changes
to the text?

> next hop controlled by a 3rd party that changes when the hardware changes.

What has that to do with the IID length?

> is not mandatory. YMMV without it.

Doesn't matter. The addressing architecture says 64 bits, whether using
SLAAC, DHCPv6 or anything else. If you ignore that, YMMV indeed.

   Brian

---

From: joel jaeggli <[email-masked]>
Date: Fri, 14 Mar 2014 02:46:50 -0700

> to work* with VLSM / longest prefix match.

I have several times implemented

https://tools.ietf.org/html/rfc6583#section-6.2

out of necessity

and have yet to encounter a network equipment platform on which it
didn't work adequately. I view that ultimately as not desirable (it is a
mitigation not a recommendation after all) as the implementation
specific improvements in section 7, which I and others have gotten
several router vendors to implement.

---

From: David Farmer <[email-masked]>
Date: Fri, 14 Mar 2014 05:05:01 -0500

On 3/14/14, 03:22 , Lorenzo Colitti wrote:
> On Fri, Mar 14, 2014 at 3:41 AM, David Farmer <[email-masked]
> <mailto:[email-masked]>> wrote:
...
>     happily shut up.
> I don't think the reason for controversy is that the specs are unclear.
> I think the reason is that there are people don't agree that "n = 64
> only" is a good idea. Clarifying the specs won't help with that.

Where do you see anything about n=64 in 2.5?

2.5.  Unicast Addresses

    addresses.  Additional address types or subtypes can be defined in
    the future.

    |                           128 bits                              |

    |          n bits               |           128-n bits            |
    +-------------------------------+---------------------------------+
    |       subnet prefix           |           interface ID          |
    +-------------------------------+---------------------------------+

    Except for the knowledge of the subnet boundary discussed in the
    previous paragraphs, nodes should not make any assumptions about the
    structure of an IPv6 address.

I believe section 2.5 is intended to provide a consistent generic 
definition for Unicast IPv6 across all version of the IPv6 Architecture, 
past, current and future.  This text has changed very little between 
[RFC4291], [RFC3513], [RFC2373], and [RFC1884] section 2.4 (the 
equivalent section in that document).

The specification of the interface ID as n=64 is in 2.5.1 of [RFC4291]. 
Where as [RFC1884] section 2.4.1 (the equivalent section in that 
document) has a radically different specification of the interface ID, n 
= 48 or smaller.  But the generic definition for Unicast IPv6 is 
virtually identical.  This is why I've been saying that IPv6 
architecturally is VLSM with a variable interface ID length.  The 
interface ID is currently specified as n=64 for global unicast, but has 
not always been that and does not always have to be that, please compare 
[RFC4291] section 2.5.4 to [RFC1884] section 2.4.7.

I'm working on some text that clarifies my issues.

Thanks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 14 Mar 2014 19:31:57 +0900

> Where do you see anything about n=64 in 2.5?

Wow. Of all the dubious arguments I've heard...

You're saying that the meaning of the text is unclear because the statement
that "n = 64" is not in 2.5, but immediately after it in 2.5.1 (which, as a
subsection, I consider to be a part of 2.5, but obviously you disagree)?

You're saying that if the RFC was clarified by moving the n = 64 text from
2.5.1 to 2.5 (which could be achieved by the simple removal of the section
header!) you'd "happily shut up", but since it's in 2.5.1 and not 2.5 the
text is ambiguous? Really?

I think the meaning is very clear. The text defines the addressing format
split as n / 128-n, where 128-n is the interface ID. *Immediately after
that* it defines the Interface ID, and among other things, says that for
addresses that don't start with 0 or 1, the Interface ID is 64 bits long.
Saying this is ambiguous because there's a subsection header in between the
two statements is... well, I'm not sure what it is, but I'm pretty sure
it's incorrect :-)

> [RFC4291], [RFC3513], [RFC2373], and [RFC1884] section 2.4 (the equivalent
> section in that document).
>
> Where as [RFC1884] section 2.4.1 (the equivalent section in that document)
> has a radically different specification of the interface ID, n = 48 or
> smaller.  But the generic definition for Unicast IPv6 is virtually
> identical.  This is why I've been saying that IPv6 architecturally is VLSM
> with a variable interface ID length.

Ok, but if you're trying to determine architecture from implementation,
then that's not the only interpretation that fits the text. You could also
interpret it the other way around, i.e., that IPv6 is fundamentally a fixed
64-bit interface ID except for a few special cases that are different, and
say that 2.5 was made a more general (128-n / n) in order to cover both the
special cases and the majority use case.

>  The interface ID is currently specified as n=64 for global unicast, but
> has not always been that and does not always have to be that, please
> compare [RFC4291] section 2.5.4 to [RFC1884] section 2.4.7.
>

The fact that it was not 64 in the past is irrelevant, since obsolete RFCs
are, well, obsolete. As for the future - you're right, it doesn't always
have to be 64. But until the WG could decides to obsolete or update RFC4291
with another document that says that all IID lengths are permitted, then 64
is what it is.

---

From: Ray Hunter <[email-masked]>
Date: Fri, 14 Mar 2014 11:48:35 +0100

> Brian E Carpenter <mailto:[email-masked]>
> 14 March 2014 10:36
I'm not arguing against your draft in my note. I'm arguing against those 
who write that /64 + SLAAC is the only game in town, and for all media 
types.

IMHO The 000 prefix allows for future expansion to >> /64 prefix 
lengths. And 4291 defined unicast as "everything else"

And I'd even prefer the /64 to be media dependent at the very least.

So a router should forward packets respecting all bits even >> 64. That 
is in line with http://tools.ietf.org/html/draft-carpenter-6man-why64-01 
Section 5.2

> itself requires 64 bit IIDs.
Only for those unicast addresses not starting with 000. There are those 
on this thread who have argued that that door is also closed (or indeed 
was never open).
>> become the *only* media types supported by IPv6?
Not IMHO. Shoehorning 10Base5/10Base2 Ethernet like behaviour (like 
multicast) onto NBMA and other new link technologies e.g. by hard coding 
/64 into the standards is a source of pain, security risks, and stifles 
innovation.
Ethernet itself has moved on since IPv6 was conceived, and is pretty 
much a point to point protocol at the higher speeds nowadays.

Just because the IEEE settled on 64 bits does not mean the IETF should.

I recall the outcry when manufacturers broke the official IEEE store and 
forward bridging model with the first 'cut through' bridges (to increase 
forwarding performance)

Two potential areas of innovation that I would definitely not want to 
see closed off by this draft.

1) The use of individually routed /128 addresses on a LAN containing a 
single host and a single router (next hop being the link local on the 
router)

i.e. a wired or wireless network with all ports L3 switched, and all 
packets forwarded by the router. Hosts register their addresses in use 
with the router. Routers advertise individual /128 routes as appropriate 
for each host. Addresses are portable as individual hosts move.

This is within reach in terms of technology and costs, and would 
potentially save a lot of headaches with mobility. I've also seen this 
model proposed as a solution for Homenet.

2) Aligning the network topology with the forwarding mechanism

Partricia trees are a good way of representing sparsely populated 
address spaces e.g. in address management systems.

I'd also like to leave open the possibility that the network topology 
was also structured on a Patricia tree based forwarding model, where 
each router only has to examine one word of the address space (rather 
than a fixed split of network prefix/iid)

That gets around CAM limitations not being able to handle either the 
full 64 bits or more than 64 bits, and other processing limits imposed 
by a hard coded /64 boundary. It would also open up the possibility of 
'cut through routing', where a device could begin forwarding a packet 
even before the entire IPv6 destination address had been clocked in, 
with forwarding ceasing when the device detects that the packet does not 
need to be forwarded down this path. If the IID is fixed at /64 that 
only leave /29 or /32 - /64 open for tree forwarding, which will limit 
tree depth. Before you deride this idea, remember that the initial 
reaction against cut through bridging / Ethernet switching was equally 
strong.

Can you assure me that your draft will not stop this innovation?
> This is discussed in the draft. Do you have any suggested changes
Perhaps we should be suggesting to the address registration authorities 
that there is an operational case for assigning space for static 
assignments with prefix lengths >> 64?
This is anyway reality when using router to router links with VRRP.

The stuff that breaks (Section 4) does not seem to negatively impact the 
use case scenarios of >>64 (Section 2) or vice versa.

Is there not room for both?

(Section 2 should be expanded where necessary by the operators who have 
come up with schemes other than /64).
> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 14 Mar 2014 08:20:46 -0400

Earlier, someone wrote, in part:
% And we know how much "Modified EUI-64 format" has been universally 
% adhered to. 6man has just been handling draft-ietf-6man-stable-privacy-addresses-17

The text in RFC-4291, Section 2.5.1 includes text describing multiple
ways that a "Modified EUI-64 format" identifier can be generated,
for example using the "Privacy" identifier schema.  We are still using
Modified EUI-64 format, even with the I-D above.  As the RFC says, 
it isn't pure IEEE EUI-64 format, but instead *modified* EUI-64,
and it can be generated in several different ways.  Fernando's draft,
which I support, defines an additional way to generate that
modified EUI-64.

So I'd say that "modified EUI-64" is very widely used today,
although the bits often don't contain a direct IEEE MAC address 
(e.g. for privacy reasons).

Yours,

Ran

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 14 Mar 2014 15:49:29 +0000

Hi Ray,

> it's asking for abuse e.g. ping pong traffic and neighbour table overflow.

I don't understand these statements. ISATAP is NBMA and uses /64 SLAAC
on the ISATAP interface, but does not maintain a neighbor cache so there
no neighbor table overflow. AERO is also NBMA and uses /64 link-local-only
on the AERO interface, so it does not use SLAAC but it does maintain a
neighbor cache. With AERO, neighbor table overflow is not an issue because
neighbor cache entries are only established based on ND messages from
trust anchors.

Thanks - Fred
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Mar 2014 09:27:18 -0700

On 3/14/14 1:35 AM, Ray Hunter wrote:
> especially in the determination off on and off link addresses. But 
> that could be largely fixed with an extension to PIO for SLAAC and 
> DHCPv6 to include an explicit informational prefix length. 
Ray,
what do you see as missing?

RFC 4861 allows for PIO with L=1 for any prefix length.
Thus the on-link determination is orthogonal to whether DHCPv6 or SLAAC 
is used for address assignment.

Thanks,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Mar 2014 09:42:20 -0700

> 4. Some routers are less efficient for prefixes longer than 64.
Brian,
I don't see any conflicts between those thoughts.

Furthermore I haven't seen any documents which state that the IPv6 
routing architecture is limited to prefixes of length 0-64, 128.
In fact section 2.5 in RFC 4291 hints at the more general statement 
(even though it doesn't explicitly say that this is for the purposes of 
routing) with:
    IPv6 unicast addresses are aggregatable with prefixes of arbitrary
    bit-length, similar to IPv4 addresses under Classless Inter-Domain
    Routing.

So while /64 IIDs are tremendously useful, that doesn't mean that 
routing on /127, /112 or any other length has been banned by existing 
specifications.

It might be useful to attempt to clarify the relationship between the 
addressing architecture and routing architecture in the why64 draft, 
since I'm sure there might be people not participating in this 
discussion that might want to see that clarified.

Regards,
    Erik

---

From: Steven Blake <[email-masked]>
Date: Fri, 14 Mar 2014 13:58:35 -0400

> lookups will be faster/easier.

Deaggregating /126 or /127 prefixes to /128s is relatively painless.
Deaggregating /120 or /112 or what have you, not so much.

Regards,
 
// Steve

---

From: Steven Blake <[email-masked]>
Date: Fri, 14 Mar 2014 14:23:36 -0400

> Important clarification included:

[snip]

>       in Modified EUI-64 format.

Thank you Brian.  I think that statement is perfectly clear and unambiguous.
I suggest that you reference this text in draft-carpenter-6man-why64
(say Sec. 1?).  Also, I suggest you mention in Sec. 4 "Possible areas of
breakage" that implementors may legitimately interpret IETF
standards-track RFCs (6164, 7136) to indicate that routing prefixes
between /65 and /126 inclusive for unicast packets on-the-wire are
invalid, and operational practices that utilize prefix lengths in this
range may break on some devices.  If you would like specific text, I
would be happy to provide it.

Also, if you would like to include text regarding the additional HW
expense incurred to support /65 - /126 bit prefixes, I would also be
happy to provide that.

Regards,

// Steve

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 14 Mar 2014 20:05:09 +0000

> From: Steven Blake [mailto:[email-masked]]

> >    2.5.  Unicast Addresses

. . .

> >    **Additional address types or subtypes can be defined in
> >    the future.**
> 

I didn't miss that. People seem to be reading this clause backwards.

I'm saying that "those that start with binary value 000" are the vast majority of potential IPv6 global unicast addresses. So this 64-bit IID rule is only mean to apply to an initial small allocation, that's all. We're making it sound like we should limit IPv6 routers now, to prevent easy adoption of more flexible address allocation in the future.

The way to read this is implied in RFC 3513 Section 4: "For now, IANA should limit its allocation of IPv6 unicast address space to the range of addresses that start with binary value 001. The rest of the global unicast address space (approximately 85% of the IPv6 address space) is reserved for future definition and use, and is not to be assigned by IANA at this time."

> I suggest that those who wish to

There should be no reason to do so, is my point. The important thing is, instead, to follow the intent, as shown graphically in the examples which show the prefix wider than the IID, and not limit ourselves.

Bert

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 14 Mar 2014 17:54:39 -0700 (PDT)

----- Original Message -----
> From: RJ Atkinson <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Friday, 14 March 2014 2:49 AM
> Subject: Re: Subject: Confirming consensus on adopting draft-carpenter-6man-why64
> 
> special-case for point-to-point links.

So what about ::1/128? What is the history of loopback being /128 rather than /64?

(And I really think it would have been better to be at least a /64 -

https://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-04)

>  This was added ONLY to resolve

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 14 Mar 2014 18:39:58 -0700 (PDT)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Sent: Friday, 14 March 2014 8:22 PM

Seems my brain is just as twisted :-)

Forwarding flexibility for future proofing if necessary, while having addressing structure simplicity to reduce operational costs by avoiding configuration errors, avoiding configured prefix "resizing" to allow for more hosts, and having to track prefix length variation, that have all been inherent in and unavoidable in CIDR IPv4.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Mar 2014 20:38:36 +1300

Mark,

> So what about ::1/128? What is the history of loopback being /128 rather than /64?

I suspect that it was given a /128 without much thought, since the loopback
address for IPv4 was a /32. I can't be bothered to search the old
documents before breakfast, but I expect this was done before the IID
length changed from 48 to 64.

    Brian

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Sat, 15 Mar 2014 18:31:55 +0000

> length changed from 48 to 64.

Huh?

I thought loopback was 127.1/8 and a quick check on a few different OSes shows that this is the way they implement (configure) it by default.

— 
Bjoern A. Zeeb                             ????????? ??? ??????? ??????:
'??? ??? ???? ??????  ??????? ?? ?? ??????? ??????? ??? ????? ????? ????
?????? ?? ????? ????',  ????????? ?????????, "??? ????? ?? ?????", ?.???

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Mar 2014 21:04:28 +1300

> I thought loopback was 127.1/8 and a quick check on a few different OSes shows that this is the way they implement (configure) it by default.

My oops. However, IANA shows 127.0.0.0/8 as loopback.

The /128 choice for IPv6 goes right back to RFC 1884 (July 1998).

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Sun, 16 Mar 2014 13:05:50 +0100

> Erik Nordmark <mailto:[email-masked]>
> 14 March 2014 17:27
>
> Ray,
> Thus the on-link determination is orthogonal to whether DHCPv6 or 
> SLAAC is used for address assignment.
>
> Thanks,
>    Erik
There are those who would like to be able to ensure proper DHCP 
operation without RA. e.g. 
http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00

But it ain't going to happen.

-- 
Regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Sun, 16 Mar 2014 13:34:07 +0100

> Templin, Fred L <mailto:[email-masked]>
> 14 March 2014 16:49
> Hi Ray,
>
>
> I don't understand these statements.

> ISATAP is NBMA and uses /64 SLAAC
> no neighbor table overflow.
Absolutely, I agree there's no issue because there's an algorithmic 
mapping between IPv6 address and next hop. There is no cache to overflow.
> AERO is also NBMA and uses /64 link-local-only
Agreed. So you have model including trust anchors in the NBMA neighbour 
resolution protocol, which is also fine. Again, no issue if your trust 
anchor system works as designed.

> [email-masked]
Personally I'm a fan of brute force approaches i.e. a cache can never 
overflow and adversely affect other processes on the router, because it 
is limited to n entries (where n is in the config) and the memory can be 
statically allocated in advance. You only have to glance at the list of 
the top 25 most dangerous software errors to see that we still haven't 
learned these and similar lessons after decades of programming. It's 
also easy to explain to an auditor.  On a related note, I've personally 
seen NID boxes and firewalls from respected manufacturers fall over 
completely and stop forwarding, causing a complete loss of service for 
all users, simply because they hit a session table limit, rather than 
failing gracefully and maintaining current sessions. Testing software to 
destruction is expensive and difficult.

-- 
Regards,
RayH

---

From: Ray Hunter <[email-masked]>
Date: Sun, 16 Mar 2014 18:16:13 +0100

Erik Nordmark wrote:
> (even though it doesn't explicitly say that this is for the purposes 
> of routing) with:
Yes.

>    Erik

Can I ask some basic questions?

If I read http://tools.ietf.org/html/rfc5942 it states " Any assigned 
address on an interface should initially be considered as having no 
internal structure as shown in [RFC4291]."

If host implementations can ignore the prefix length contained in RA PIO 
(because all IIDs except those staring with 000 contain 64 bit IIDs as 
defined in the addressing architecture), and routers ignore RA, what is 
the point of the prefix length option in RA?

Should the prefix length in a PIO be ignored if it does not contain 64 
on a ipv6-over-foo link that specifies 64 bit IIDs? Or should the whole 
option be ignored?

Does 5942 need to be updated to say that /64 can be assumed to be the 
default IID length (to match the IPv6 addressing architecture and 
IPv6-over-foo documents?)

If hosts can only determine whether a link local address is on link by 
virtue of the fact that a local router has not forwarded it, why does it 
matter if a link local address is /10 or /64?
Why do they need to be consistent. AFAICS anything starting with 
fe80::/10 is link-local by definition in the addressing architecture.
The only thing that matters in determining whether a link local address 
is actually on link is the physical interface it was received on: not 
how it was formed. Even if you encode some sort of interface identifier 
in there, that identifier is only local to the node, not the link.

Are nodes that assume that fe80:0000:0000:0000::/64 defines the link 
local range non compliant to IPv6 standards?

What is wrong with an operating model where hosts obtain /128 addresses 
via DHCPv6 (because address assignment via DHCPv6 does not include any 
prefix length at all) and a router publishes RA with M=1 O=1 + PIO L=0 
A=0? [or no PIO]
Why would that model break if the prefix length on the router was not /64?

So why does /64 really matter (apart for the fact that some hardware 
vendors currently want to save on forwarding engine complexity by 
limiting their CAM memory size), and some address assignment mechanisms 
(which not everyone uses) swallow exactly 64 bits when assigning an IPv6 
address?

I think the draft would be very useful if it could answer those questions.

Thanks.

-- 
Regards,
RayH

---

From: George Michaelson <[email-masked]>
Date: Mon, 17 Mar 2014 09:00:43 +1000

Not wanting to be too stupid, would it not make for POLA in the future, if
we defined the /64 rule to apply only to the specific current IANA
allocation spaces, plus the required others, and thus *not* define it for
the remaining vast majority of the address space? we're in 2000/3 right
now. We're in specific spaces like fc00/7. We have multicast. But the vast
mass of the space is unconstrained and I don't think that limits to just
'everything but 000'

Lorenzo stated 'if its not 000 in the top, then its /64' and I rather
suspect it should be 'if its 2000/3 in the top, plus the following defined
spaces its /64' and everything else is unconstrained...

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Mar 2014 11:12:17 +0900

> spaces its /64' and everything else is unconstrained...

Perhaps, but discussion of what the standards should say and how things
ought to be are irrelevant to this document, which is informational and
thus cannot change the standards.

If you want to change the standards, then you need a standards track RFC to
do so. Given that the length of this thread suggests that we can't even get
consensus on a draft that simply documents standards that *already exist*,
it seems unlikely to me that any attempt to change those standards will
gain consensus. So it doesn't seem like a particularly useful discussion to
have.

---

From: George Michaelson <[email-masked]>
Date: Mon, 17 Mar 2014 12:39:10 +1000

I think because in an RIR space, I'm exposed to the join over public policy
by consensus amongst operators, and public policy as enshrined in IETF
documents, I have a different sense of what an RFC "standard" is.

IETF Standards are immutable as text, true.

IETF Standards are not immutable, as word-of-law. If something in a
standard doesn't reflect where we want to be, we write a new standard.

Its only a sideline, and I understand what you're saying is that the /64
rule as you understand it, applies across the entire address space as we
understand it.

I just think its unwise to commit another document, which attempts to
proclaim control over the tides. What happens in the part of IPv6 which is
not in 2000/3 and the fc00/7 type specific spaces, is really not within our
powers to constrain right now. King Canute was acting to teach his court
that just because he's a king, he can't limit the tides. he didn't actually
think he could hold them back: it was an object lesson.

Do you think we can constrain the upper spaces of the IPv6 plan to /64, as
a binding forward act? I don't.

Why say something as final as /64 forever?

the *practical* impact of limiting a statement to 2000/3 is that it makes
it clear what *current* equipment expects. Future use, can go anywhere. I
can conceive of an EUI164(bis) which says its not limited to 64 bits...

-G

On Mon, Mar 17, 2014 at 12:12 PM, Lorenzo Colitti <[email-masked]>wrote:

> On Mon, Mar 17, 2014 at 8:00 AM, George Michaelson <[email-masked]>wrote:
>
> If you want to change the standards, then you need a standards track RFC
> to do so. Given that the length of this thread suggests that we can't even
> get consensus on a draft that simply documents standards that *already
> exist*, it seems unlikely to me that any attempt to change those standards
> will gain consensus. So it doesn't seem like a particularly useful
> discussion to have.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Mar 2014 12:01:56 +0900

> standard doesn't reflect where we want to be, we write a new standard.

Absolutely. All I'm saying is that IETF standards are based on rough
consensus, and if we can't even agree on what the standards *currently say*
on this particular point, I very doubt that we will reach rough consensus
on any attempt to change them.

> proclaim control over the tides.
>

This document is not proclaiming any control over anything, and as an
informational document, it *cannot* proclaim any control over anything. It
can only state what the standard already says.

> a binding forward act? I don't.

But we have. That is what the standard says: everything that does not start
with 0 or 1 has 64-bit IIDs, period.

You may argue that's unwise, and that's a perfectly valid point of view,
but the fact of the matter is that a) unless and until there is rough
consensus to change the standard, "64-bit IIDs" is what the standard says,
and b) if we do not expect to have rough consensus on a change to the
standard, then the standard will not change.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Mar 2014 20:56:17 +1300

George,

> spaces its /64' and everything else is unconstrained...

That would be a normative change. The draft under discussion is
informational, so can only reflect the current standards.

Everybody,

If you want to discuss possible normative changes, could you
kindly start a thread with a suitable subject header?

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Mar 2014 17:23:34 +0900

On Sat, Mar 15, 2014 at 5:05 AM, Manfredi, Albert E <
[email-masked]> wrote:

> I'm saying that "those that start with binary value 000" are the vast
> majority of potential IPv6 global unicast addresses. So this 64-bit IID
> rule is only mean to apply to an initial small allocation, that's all.
> We're making it sound like we should limit IPv6 routers now, to prevent
> easy adoption of more flexible address allocation in the future.
>
> The way to read this is implied in RFC 3513 Section 4: "For now, IANA
> should limit its allocation of IPv6 unicast address space to the range of
> addresses that start with binary value 001. The rest of the global unicast
> address space (approximately 85% of the IPv6 address space) is reserved for
> future definition and use, and is not to be assigned by IANA at this time."
>

No, the way to read it is exactly the way it's written: for *all* unicast
addresses, except those that start with 0 or 1, IIDs are 64 bits long,
period. That includes current global addresses, link-local, ULA, and future
global addresses, the lot.

> There should be no reason to do so, is my point. The important thing is,
> instead, to follow the intent, as shown graphically in the examples which
> show the prefix wider than the IID, and not limit ourselves.
>

I don't think you can claim that that's the intent when RFC 7136 explicitly
disagrees with you.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Mar 2014 08:40:31 -0400

I think it is reasonable that the IETF might define flavour of IPv6
where the /64 law was lifted.  It won't happen in 2000::/3, (nor in whatever
address we allocate to mars/Alphacenturi).

What will matter is that from a distsance (not on-link, not within the AS),
the new system will be compatible with the /64 law.  That's not happening
today, and I think it is important that we stick firm with /64 in ISP or
Enterprise space.
(I think we are regularly confused by assuming that the capital-I Internet is
the only customer for the internet protocol suite)

I support the document as is.   DHCv6-PD is possibly the most important
protocol innovation of IPv6, and we need to make sure that nobody screws
up end to end again.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 17 Mar 2014 17:45:44 +0000

From: Lorenzo Colitti [mailto:[email-masked]] 

>> majority of potential IPv6 global unicast addresses.

> No, the way to read it is exactly the way it's written: for *all*
> unicast addresses, except those that start with 0 or 1, IIDs are 64
> bits long, period.

Are you disagreeing that unicast addresses starting with 000 are the vast majority of potential future unicast addresses?

Bert

---

From: David Farmer <[email-masked]>
Date: Mon, 17 Mar 2014 14:17:38 -0500

> Are you disagreeing that unicast addresses starting with 000 are the vast majority of potential future unicast addresses?

The only currently defined IPv6 addresses that start with the binary 
value 000, are special-purpose addresses, all other addresses that meet 
this definition are reserved, and not currently available for 
allocation, though they are reserved for future unicast allocation.  I'm 
beginning to believe the purpose of the clause isn't to designate that 
they may have interface identifiers other than 64, but that they have no 
interface identifier at all, and that they are just 128 addresses with 
no structure at all.  They are;

    - The Unspecified Address [RFC4291]
    - The Loopback Address [RFC4291]
    - IPv4-Mapped IPv6 Address [RFC4291]
    - The Well-Known Prefix for IPv4/IPv6 Translators [RFC6052]

The last two are /96 prefixes followed with a 32 bit IPv4 address, which 
I don't think it is proper to technically call them interface 
identifiers, they are individual mapped addresses.  So, it could be 
argued that technically each of these are 4.2 Billion individual /128 
IPv6 addresses.  Additionally it should be noted, that there were a 
number of other historic special-purpose address ranges reserved to 
mapped IPv6 addresses for compatibility with other addressing 
architectures, these have all been deprecated and are no longer valid.

There has never been any general-purpose unicast addresses that start 
with the binary value 000, only the current and historic special-purpose 
addresses.

---

From: Peter Dordal <[email-masked]>
Date: Mon, 17 Mar 2014 14:54:55 -0500

On 03/17/2014 02:17 PM, David Farmer
wrote:

On
3/17/14, 12:45 , Manfredi, Albert E wrote:

From: Lorenzo Colitti
[mailto:[email-masked]]

I didn't miss that. People seem to be
reading this clause backwards.

I'm saying that "those that start with binary value 000" are
the vast

No, the way to read it is exactly the
way it's written: for *all*

unicast addresses, except those that start with 0 or 1, IIDs
are 64

bits long, period.

Are you disagreeing that unicast addresses starting with 000 are
the vast majority of potential future unicast addresses?

The only currently defined IPv6 addresses that start with the
binary value 000, are special-purpose addresses, all other
addresses that meet this definition are reserved, and not
currently available for allocation, though they are reserved for
future unicast allocation.

My understanding of the 0::/3 block has always been that it
represents a fallback

in case 64-bit prefixes don't work out for some reason. This address
block is "held in reserve".

That is, if we run out of /64 IPv6 address prefixes, we can always
divide up the 0::/3 block using, say, /96 prefixes.

(And then at that point figure out how to manage with 32-bit
interface IDs.)

...

There has never been any general-purpose unicast addresses that
start with the binary value 000, only the current and historic
special-purpose addresses.

But this could change in the future, though that would be
likely only if there were a problem with the 64/64 division.

Which is to say not very likely at all.

Peter Dordal

Loyola Univ Chicago CS Dept

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Mar 2014 09:50:52 +1300

Peter,

On 18/03/2014 08:54, Peter Dordal wrote:
> On 03/17/2014 02:17 PM, David Farmer wrote:
>>> Are you disagreeing that unicast addresses starting with 000 are the vast 
>>> majority of potential future unicast addresses?
>>
>> The only currently defined IPv6 addresses that start with the binary value 
>> 000, are special-purpose addresses, all other addresses that meet this 
>> definition are reserved, and not currently available for allocation, though 
>> they are reserved for future unicast allocation.
> 
> My understanding of the 0::/3 block has always been that it represents a fallback
> in case 64-bit prefixes don't work out for some reason. This address block is 
> "held in reserve".

No. It's partially used for special purpose addresses. The reserve is in the fact
that only 2000::/3 (1/8 of the total space) has been released to IANA for unicast
allocations.

   Brian

> That is, if we run out of /64 IPv6 address prefixes, we can always divide up the 
> 0::/3 block using, say, /96 prefixes.

> (And then at that point figure out how to manage with 32-bit interface IDs.)
> 
>> ...
>> There has never been any general-purpose unicast addresses that start with the 
>> binary value 000, only the current and historic special-purpose addresses.
>>
> But this /could/ change in the future, though that would be likely only if there 
> were a problem with the 64/64 division.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 17 Mar 2014 21:42:05 +0000

> From: David Farmer [mailto:[email-masked]]

>     - The Well-Known Prefix for IPv4/IPv6 Translators [RFC6052]

Well, it doesn't make a lot of sense to leave such a huge chunk of the address range for small stuff that was listed only as examples, or for uses that have been deprecated. Talk about waste of address space. And used merely as /128s is either going to mean only for local point to point use, or we're planning on creating a flat Internet in the future. Which seems unlikely.

Also, the suggestion of the use simply requesting more prefixes, if one's initial assignment was insufficient, is okay but not optimal, right? Because now your routes are going to be unaggregated.

> with the binary value 000, only the current and historic special-purpose

Yes, but most of that /000 block has been unassigned. Dunno guys. Well, at least we can count on IPv6 NAT. :) (Plus ca change, plus c'est la meme chose.)

Bert

---

From: joel jaeggli <[email-masked]>
Date: Mon, 17 Mar 2014 22:22:10 -0700

On 3/17/14, 2:42 PM, Manfredi, Albert E wrote:
>> -----Original Message----- From: David Farmer
>> [mailto:[email-masked]]
> 
>> addresses that meet this definition are reserved, and not currently
>> available for allocation, though they are reserved for future
>> unicast allocation.  I'm beginning to believe the purpose of the
>> clause isn't to designate that they may have interface identifiers
>> other than 64, but that they have no interface identifier at all,
>> and that they are just 128 addresses with no structure at all.
>> They are;
>> 
>> - The Unspecified Address [RFC4291] - The Loopback Address
>> [RFC4291] - IPv4-Mapped IPv6 Address [RFC4291] - The Well-Known
>> Prefix for IPv4/IPv6 Translators [RFC6052]
> 
> Well, it doesn't make a lot of sense to leave such a huge chunk of
> the address range for small stuff that was listed only as examples,
> or for uses that have been deprecated. Talk about waste of address
> space. And used merely as /128s is either going to mean only for
> local point to point use, or we're planning on creating a flat
> Internet in the future. Which seems unlikely.

I bet there are some people who have 0100::/64 in their routing tables.
I did.

https://tools.ietf.org/html/rfc6666

> 
> Also, the suggestion of the use simply requesting more prefixes, if
> one's initial assignment was insufficient, is okay but not optimal,
> right? Because now your routes are going to be unaggregated.
> 
> Yes, but most of that /000 block has been unassigned. Dunno guys.
> Well, at least we can count on IPv6 NAT. :) (Plus ca change, plus
> c'est la meme chose.)
> 
> Bert
> 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 Mar 2014 16:22:52 -0700

> http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-default-router-00
Ray,
I can understand such a desire, but I was confused by your comment about 
"fixed with an extension to PIO for SLAAC"; if you don't have RAs you 
wouldn't have PIOs.

> But it ain't going to happen.
Agreed.

    Erik

---

From: Ray Hunter <[email-masked]>
Date: Wed, 19 Mar 2014 08:48:49 +0100

> 19 March 2014 00:22
> I can understand such a desire, but I was confused by your comment 
> about "fixed with an extension to PIO for SLAAC"; if you don't have 
> RAs you wouldn't have PIOs.
>
Well it isn't at all clear to me how to treat a prefix length in SLAAC 
PIO in all cases if all unicast prefixes except those starting with 
binary 000 really are /64.

If the address architecture [4291] takes precedence then there's no need 
at all for this prefix length information in ND PIO in the vast majority 
of cases.
On link determination isn't applicable to the special function ranges 
defined so far that start with binary 000, and routing is completely 
different as well, with the vast majority never appearing on the wire.

But on link detection [5942] contradicts assuming a /64 boundary, 
stating nodes must not assume that addresses contain structure.

What do you do if you receive an RA PIO with L=1 A=1 but prefix length /80?

I presume you cannot use SLAAC [4862] to generate a GUA from modified 
EUI64 with prefix length !=64, but SLAAC could work perfectly well 
without adaptions with other non EUI64 addresses as the source of global 
uniqueness e.g. EUI48 for /80 prefixes, and it wouldn't break AFAICS. 
But at the same time this is an architecture violation for the structure 
of GUA addresses, so should you install the /80 prefix in the prefix 
table used for on-link determination if PIO had a length of /80?

ND [4861] states very clearly in 4.6.2 that the prefix length can take 
values from the set [0 .. 128], and certainly not [0 .. 64 , 127] or [64].

On link determination [5942] which amends [4861] implies very clearly in 
Section 5 that NBMA may use some prefix length other than 64, and nodes 
must not assume any structure from assigned addresses (including a fixed 
/64 boundary).

If there are conflicting standards track RFC's, which one takes precedence?

I think it would be useful in the why-64 draft to have a simple table of 
all IPv6 standards track documents, with a tag "breaks when prefix 
length !=64", "continues working nominally with prefix length !=64", 
"not sufficiently specified as a stand alone document to determine if 
all implementations will break or fail with prefix length !=64", "not 
self consistent"

It seems to me that in most cases I've seen, the addressing architecture 
is the outlier that specifies fixed /64 prefix lengths. Plus a few 
oddball ways of generating addresses stand-alone.

I think it would be useful for implementers if that view were either 
confirmed or blown out of the water.

All IPv6 code I've every written can handle prefix length [0..128].

-- 
Regards,
RayH

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Mar 2014 09:44:30 -0700

> binary 000 really are /64.

RFC 4861/62 specifies how to advertise and receive prefixes in PIOs.

Those standards discuss neither /64 nor 000. And I think there is a good 
modularity argument that those standards and the resulting 
implementations should not. RFC 4291 specifies the addressing 
architecture, and in the case of /64 and 000 the impact on the 
implementations is indirect; /64 means that IP-over-foo specifications 
state how to form 64 bit IIDs, other specifications how to randomly 
allocate IIDs (and as stable-privacy is an example, such specifications 
don't have to assume exactly 64 bits).
My understanding of the 000 exception is that it says that the IETF can 
put various odd formats in that space, and we already have.

Note that the last few recommendations in the IAB statement that Ran 
forwarded to the list would violate the modularity by requiring hosts 
and routers to add code to check for /64 and 000. While other requests 
for clarifications in that IAB statement made sense to me, those two 
recommendations violate what I view as part of "be liberal in what you 
accept".

>
> If the address architecture [4291] takes precedence then there's no 
> need at all for this prefix length information in ND PIO in the vast 
> majority of cases.
That doesn't follow - the modularity argument leads to other IETF 
standards and their implementations should make the least assumptions 
necessary. Thus on a host the code which implements IPv6-over-Ethernet 
would know how to form a 64 bit IID. Any CGA code would also know how to 
form a 64 bit CGA IID. But all other code can operate in the n+m view of 
the addresses.

> stating nodes must not assume that addresses contain structure.
There is no contradiction between an addressing architecture and IID 
formation approach, and stating that nodes should make the minimal 
assumptions needed to get their work done.

> What do you do if you receive an RA PIO with L=1 A=1 but prefix length 

That is specified in RFC 4861/62. Assuming you use one of the existing 
IP-over-foo specifications which all have a 64 bit IID, then per those 
RFCs the /80 prefix will be treated as on-link, and since 80+64 != 128 
it will be silently ignored for SLAAC purposes.

> without adaptions with other non EUI64 addresses as the source of 
> global uniqueness e.g. EUI48 for /80 prefixes, and it wouldn't break 
> AFAICS. But at the same time this is an architecture violation for the 
> structure of GUA addresses, so should you install the /80 prefix in 
> the prefix table used for on-link determination if PIO had a length of 
> /80?
That is what our current standards say you should do.
> All IPv6 code I've every written can handle prefix length [0..128].

Ditto, but the IPv6 Ethernet code I wrote can only form a 64 bit IID, 
which is used by SLAAC. I think we later added code to allow the admin 
to manually set an IID of arbitrary length and value.

    Erik

---

From: Ray Hunter <[email-masked]>
Date: Fri, 21 Mar 2014 18:04:54 +0100

> 21 March 2014 17:44
>> Well it isn't at all clear to me how to treat a prefix length in 
>> SLAAC PIO in all cases if all unicast prefixes except those starting 
>> with binary 000 really are /64.
>
> Those standards discuss neither /64 nor 000. And I think there is a 
> good modularity argument that those standards and the resulting 
> allocate IIDs (and as stable-privacy is an example, such 
> specifications don't have to assume exactly 64 bits).
> My understanding of the 000 exception is that it says that the IETF 
> can put various odd formats in that space, and we already have.
>
> would know how to form a 64 bit IID. Any CGA code would also know how 
> to form a 64 bit CGA IID. But all other code can operate in the n+m 
> view of the addresses.
>
>> AFAICS. But at the same time this is an architecture violation for 
>> the structure of GUA addresses, so should you install the /80 prefix 
>> in the prefix table used for on-link determination if PIO had a 
>> length of /80?
If I take your thinking further, I would myself conclude that all 
implementations and standards should really handle IPv6 IID + prefix 
using the m + n model, and that /64 is just another parameter set 
somewhere higher up either in the standards stack or code.

That way we all make as few assumptions as necessary, you are liberal in 
what you accept, and conservative in what you send (the Internet way of 
working), and more importantly for me, we don't saddle future 
generations with an "omg what's gonna break if we have to drop the /64 
fixed length model?" quandary.

That seems a far more sensible approach to me than trying to stop the 
tide by repeating the "everything is fixed at /64" mantra.

-- 
Regards,
RayH

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 21 Mar 2014 18:16:35 +0000

> the whole address. This is also the observed behavior for the vendors

I can’t comment for all vendors. However, I can tell you that this is how Cisco views it. It’s a 128 bit CIDR prefix that has a convention (defined in each version of the architecture, originally 48 and now 64 bits) for the IID on a set of interface types.

A general comment. I frequently hear that “some equipment can’t handle a prefix longer than 64 bits”. It would be good to know what equipment is under discussion and exactly what the impact is. I suspect that there is at least as much FUD in that as fact.

I *can* tell you that a 64 or 128 bit number occupies more space than a 32 bit number, which impacts TCAM densities in equipment that uses TCAMs (“what, you can’t handle as many IPv6 prefixes as IPv4 prefixes?”). Depending on the TCAM organization, it may mean that when a prefix longer than <something> is used, we have to do multiple TCAM reads or access a separate TCAM for the “subsequent” part. 

By “organization”, I mean “did we make the memory 32, 64, or 128 bits wide?” A datum width of 32 bits makes sense for IPv4-only; dual stack means at least a double read for local and de-aggregated IPv6 prefixes. 64 bit widths are an interesting trade-off; if I have an IPv6 /32 route to a neighboring ISP, I am “wasting” 32 bits that are for its use. For routes in my own prefix, or de-aggregated routes, I’m going to use some subset of the next 32 bits. In most cases, I don’t need to go into bits 64..127, but it’s there if I need it for the price of a second read. If I go for a 128 bit wide TCAM, I will “waste” 64-80 bits of most entries, which costs in both capital expense (I’ll put all the memory into the thing that you want to pay for) and operational expense (power, heat, and heat management).

A TCAM read is on the order of 20 ns, at least with Cisco EARL 8, so that means that either the second read has to be pipelined or the speed of the card is reduced from 50 Mpps to 25 Mpps. In other words, using 1500 byte packets, the maximum speed of a card is 300 GBPS instead of 600 GBPS, or using 128 byte packets it is reduced from 51 GBPS to 25 GBPS.

A 64 bit width with an occasional extra read looks like a pretty good trade-off, from where I’m sitting. If I want to build a 10X100G Ethernet card similar to my present 10X10G cards, I can probably afford multiple TCAMs.

---

From: David Farmer <[email-masked]>
Date: Mon, 24 Mar 2014 10:55:55 -0500

> A 64 bit width with an occasional extra read looks like a pretty good trade-off, from where I’m sitting. If I want to build a 10X100G Ethernet card similar to my present 10X10G cards, I can probabl…

I read that as saying routers with fast-path hardware are frequently 
optimized for prefixes of /64 or shorter, and significant use of longer 
prefixes may result in performance degradation.  How many longer 
prefixes are actually significant and the details of the performance 
degradation depend on the particulars of the optimization technique 
used.