Subject: Review of draft-ietf-6man-rfc4291bis-06

From: Brian Haberman <[email-masked]>
Date: Tue, 10 Jan 2017 08:32:10 -0800

Reviewer: Brian Haberman
Review result: Ready with Nits

I just have a few comments/questions on this draft. Overall, it is in
pretty good shape...

1. Section 2.2.3 looks like a complete re-production of RFC 5952, but
I don't see a reference to 5952. Is the intent to deprecate 5952 since
its content is now contained within 4291bis?

2. Section 2.6.1 captures some information about reserved IPv6
multicast addresses, but not all of them. I think it would be
beneficial to point to the IPv6 Multicast Address Allocation registry
maintained by IANA, much like the way Section 2.3 points to the IANA
registries.

3. Also in Section 2.6.1, the names of reserved addresses, like "All
Nodes Addresses", were made all lowercase. Was that intentional? Given
that IANA refers to them with capitalization, it would seem that we
need to be consistent. So, I would either retain the capitalization in
this document or ensure that Section 3 directs IANA to update the
names in the registries.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 10 Jan 2017 16:48:15 -0800

Brian,

Thanks for the review!

> On Jan 10, 2017, at 8:32 AM, Brian Haberman <[email-masked]> wrote:
> 
> Reviewer: Brian Haberman

I didn’t include a direct reference in the Section as incorporates the changes, but it is included in Appendix B describing the changes.

No current intent to deprecate RFC5952 as it updates RFC4291.  I don’t see very much value in deprecating (Historic?) the updating RFCs.

> maintained by IANA, much like the way Section 2.3 points to the IANA

That makes sense.  Something like a new paragraph at the end of the section like:

Additional defined multicast address can be found in the IANA IPv6 Multicast Address Allocation registry [XXX]

XXX: http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml.

> this document or ensure that Section 3 directs IANA to update the

It was capitalized in RFC4291.  It looks like the change was introduced in draft-hinden-6man-rfc4291bis-01.   I think may have been accidentally part of changing the text addresses to lower case as part of the RFC5952 update.  I agree it should be the way it was in RFC4291.  Will change.

Thanks,
Bob

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Jan 2017 10:52:48 +0900

> its content is now contained within 4291bis?

5952 has much more very useful detail for those of us who write software
to parse, compare, ... textual representations of ipv6 addresses, see
section 4 of 5952.  so i suggest the replacement of 2.2 with a reference
to 5952.

it is very cheering to see section 2.4.0, "96 more bits no magic"
[credit gaurab].

but i am having a hard time reconciling 2.4.4's insistence on a
mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc
6141, widespread operational practice, ...  clue bat please.

randy

---

From: Punana Lebo <[email-masked]>
Date: Wed, 11 Jan 2017 14:24:34 +0000 (UTC)

Hello I am new to this and I hope my comment is appropriate The examples in recommendation 7 and 8 in section 2.2.3 have been swapped. In other words, an example given for recommendation 7 (0:0:0:0:0:ffff:192.0.2.1 should be shown as ::ffff:192.0.2.1) must be  for recommendation 8 (2001:0db8:0000:cd30:0000:0000:0000:0000/60 should be shown as 2001:0db8:0:cd30::/60) and vise versa. Regards Keolebogile   

    On Tuesday, January 10, 2017 6:32 PM, Brian Haberman <[email-masked]> wrote:

 Reviewer: Brian Haberman

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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 11 Jan 2017 10:32:22 -0500

Hi Bob,

On 1/10/17 7:48 PM, Bob Hinden wrote:
>> Reviewer: Brian Haberman Review result: Ready with Nits
>> 
>> I just have a few comments/questions on this draft. Overall, it is
>> in pretty good shape...
>> 
>> 1. Section 2.2.3 looks like a complete re-production of RFC 5952,
>> but I don't see a reference to 5952. Is the intent to deprecate
>> 5952 since its content is now contained within 4291bis?
> 
> I didn’t include a direct reference in the Section as incorporates
> the changes, but it is included in Appendix B describing the
> changes.
> 
> No current intent to deprecate RFC5952 as it updates RFC4291.  I
> don’t see very much value in deprecating (Historic?) the updating
> RFCs.

I will agree with Randy that there is useful info in 5952 that people
need to see. Adding a reference to 5952 here would point people in the
right direction.

Regards,
Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Jan 2017 12:51:57 -0800

Keolebogile,

You are correct.  I will fix in the next version.

Thanks,
Bob

> On Jan 11, 2017, at 6:24 AM, Punana Lebo <[email-masked]> wrote:
> 
> Hello
>  
> I am new to this and I hope my comment is appropriate
>  
> The examples in recommendation 7 and 8 in section 2.2.3 have been swapped. In other words, an example given for recommendation 7 (0:0:0:0:0:ffff:192.0.2.1 should be shown as ::ffff:192.0.2.1) must be  for recommendation 8 (2001:0db8:0000:cd30:0000:0000:0000:0000/60 should be shown as 2001:0db8:0:cd30::/60) and vise versa.
>  
> Regards
>  
> Keolebogile
>  
>  
> 
>

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Jan 2017 13:22:55 -0800

Randy,

> On Jan 10, 2017, at 5:52 PM, Randy Bush <[email-masked]> wrote:
> 

Per your comment and Brian’s suggestion, I will add a reference to RFC5952.  RFC5952 doesn’t replace the definitions in RFC4291, it make a recommendation on outputting IPv6 text representation, so I don’t think it’s appropriate to replace 2.2 with just a reference.

> it is very cheering to see section 2.4.0, "96 more bits no magic"

Good

> 6141, widespread operational practice, ...  clue bat please.

This was discussed extensively in 6MAN and resulted in RFC7421 "Analysis of the 64-bit Boundary in IPv6 Addressing”.  The text in rfc4291bis is:

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long.  Background
   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].

Thanks,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Jan 2017 13:23:01 -0800

Brian,

> On Jan 11, 2017, at 7:32 AM, Brian Haberman <[email-masked]> wrote:
> 
> Hi Bob,
> 

Makes sense, I will add a reference to RFC5952 in the next version of the draft.

Thanks,
Bob

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jan 2017 08:26:00 +0900

> This was discussed extensively in 6MAN and resulted in RFC7421
> "Analysis of the 64-bit Boundary in IPv6 Addressing”.  The text in
> rfc4291bis is:
> 
>    value 000, Interface IDs are required to be 64 bits long.
>    Background on the 64 bit boundary in IPv6 addresses can be found in
>    [RFC7421].

thanks for the review that the wg came to this decision in conflict with
operational practice and its own statement in 2.4.0.  i did read the
documents.

since it is incorrect, ietf last call seems to be the time to fix it.

to be clear, i have no problem with iids being 64-bit.  my issue is with
unicast globals being classful in 2.4.4.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Jan 2017 13:29:21 +1300

> unicast globals being classful in 2.4.4.

RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception.
To be precise it says:

   The de facto length of almost all IPv6 interface identifiers is
   therefore 64 bits.  The only documented exception is in [RFC6164],
   which standardizes 127-bit prefixes for point-to-point links between
   routers, among other things, to avoid a loop condition known as the
   ping-pong problem.

I would suggest adding a similar exception statement in 4291bis.

     Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 12 Jan 2017 18:41:23 -0600

> unicast globals being classful in 2.4.4.
Randy I take your point, but this supposed conflict isn't new, it's not
introduced in 4291bis, it goes back to RFC3513.  Do you have a suggestion
how to change this within the context of advancing this to Internet
Standard?

-- 
===============================================
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: Randy Bush <[email-masked]>
Date: Fri, 13 Jan 2017 09:49:07 +0900

> introduced in 4291bis, it goes back to RFC3513.

i know; and i have pushed back every cm of the way.  it took years to
get the other classful insanity, tls/nla, removed.  the old cidr war
continues.  this last bit of classfulness (excuse the word) too will
pass.

> Do you have a suggestion how to change this within the context of
> advancing this to Internet Standard?

yes.  simply remove the mandatory requirement for classful global
unicast addresses.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jan 2017 09:50:36 +0900

> I would suggest adding a similar exception statement in 4291bis.

and then next year we will go through another draft and have another
exception.  just get rid of classful addressing.  we went through this
in the '90s.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Jan 2017 14:55:59 +1300

> exception.  just get rid of classful addressing.  we went through this

The problem is (and why we wrote 7421) is that stuff breaks with subnet
prefixes longer than 64, *except* for the point-to-point case covered
by 6164. Yes, I see the problem in enshrining this but I think we face
signifcant issues if we do otherwise.

What we could conceivably say is that /64 is mandatory except for
links where SLAAC will never be used. (SLAAC itself is designed
to work with any reasonable length of IID, but again in practice it
only works with /64, because we need mix-and-match capability. So
although IID length is a parameter in the SLAAC design, it's a
parameter whose value needs to be fixed globally.)

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Jan 2017 11:31:10 +0900

> signifcant issues if we do otherwise.

Also, RFC7934 says that networks that provide service to general-purpose
hosts should be assigned /64 prefixes to avoid address scarcity. Networks
that provide service to general purpose hosts make up a lot of the Internet.

> parameter whose value needs to be fixed globally.)

I don't think that's a good idea.

I strongly believe that unlike most areas of the IPv6 protocol where it is
a good idea to automatically apply the lessons we learned in IPv4, in the
specific field of IP subnet sizing, we should *not* automatically translate
IPv4 practices to IPv6. This is because the difference between 32 bits and
128 bits is large enough that the semantics are fundamentally different. We
may be lured by the fact that 128 is just 4 times larger than 32, but the
difference is huge - remember that even just the first 64 bits are 4
billion times larger than the whole of the current Internet.

So while Randy may well be right that we will move away from classful
eventually (we certainly never had it in the top 64 bite of the address), I
don't think it's necessarily a good idea to do that now. Let's have that
conversation when IPv6 deployment has reached 90% and we have experience
running the whole Internet with IPv6.

For now, I'd much prefer to just add a similar exception to the one we have
in 7421.

---

From: heasley <[email-masked]>
Date: Fri, 13 Jan 2017 03:22:08 +0000

> yes.  simply remove the mandatory requirement for classful global

yes, please.

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 12 Jan 2017 22:55:59 -0500

Hi Randy,

> yes.  simply remove the mandatory requirement for classful global

I do see your point but I do not feel it is equivalent to classful
addressing in IPv4. i.e. Looking at the leading X bits does not
directly determine the IID length.

That said, I would like to understand better your exact concern with
the text in 2.4.4. What exactly would you like to change (is it the
m-bit verbiage)? Can you come up with a text change proposal so that
we can discuss it in the 6man WG?

Thanks
Suresh

P.S.: The document is not in IETF Last Call yet. It has completed WGLC
and is in AD evaluation. Brian did his INT Dir review for the INT ADs.
The IETF Last Call will start soon.

---

From: Karsten Thomann <[email-masked]>
Date: Fri, 13 Jan 2017 06:09:47 +0100

Originalnachricht  
Von: Randy Bush
Gesendet: Freitag, 13. Januar 2017 01:51
An: Brian E Carpenter
Cc: IPv6 List; [email-masked]; Bob Hinden; [email-masked]; IETF
Betreff: Re: Review of draft-ietf-6man-rfc4291bis-06

> I would suggest adding a similar exception statement in 4291bis.

 just get rid of classful addressing. we went through this
in the '90s.

‎I can only support this, while /127 is a good exception for ptp links, it's still useless for small nets with 4-5 IPs like a network between routers and a Firewall cluster.

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jan 2017 16:03:05 +0900

>> exception.  just get rid of classful addressing.  we went through
>> this in the '90s.
> 
> The problem is (and why we wrote 7421) is that stuff breaks with
> subnet prefixes longer than 64, *except* for the point-to-point case
> covered by 6164. Yes, I see the problem in enshrining this but I think
> we face signifcant issues if we do otherwise.
> 
> links where SLAAC will never be used.

i have no problem with this.  i use slaac in environments where ip
assignment is unimportant and there is only one exit, such as my home
networks.  fwiw, in racks, i use static addressing for ipv6 because
dhcpv6 is broken.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jan 2017 16:08:55 +0900

> eventually

that is the line i was fed 15+ years ago.  i did not accept it then and
i see no good reason to accept it now.

> we certainly never had it in the top 64 bite of the address

bzzt!  you may want to look at rfc 2450.

> For now, I'd much prefer to just add a similar exception to the one we
> have in 7421.

you'll need to start an iana registry.  for p2p some use /127, some
/126, and i have seen /120 on a multipoint mesh, worked fine.

we have had to fight massively with vendors to make it classless.
please do not give them excuses to break things.

randy

---

From: [email-masked]
Date: Fri, 13 Jan 2017 08:16:54 +0100 (CET)

> /126, and i have seen /120 on a multipoint mesh, worked fine.

/124 is also used, works fine.

> please do not give them excuses to break things.

Agreed. IPv6 is classless. End of story.

Steinar Haug, AS2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Jan 2017 16:31:07 +0900

> i see no good reason to accept it now.

You might in another 15 years :)

> bzzt!  you may want to look at rfc 2450.

Oh wow. Yes, I had forgotten. But that was not just classful addressing,
that would have been a much bigger change, with business implications as
well.

> /126, and i have seen /120 on a multipoint mesh, worked fine.

I'm sure they worked fine. I don't know if there will be consensus to
change the documents to say that those lengths are in spec.

> please do not give them excuses to break things.

On a lot of hardware /65 - /126 is not very well-supported.

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jan 2017 16:34:09 +0900

> On a lot of hardware /65 - /126 is not very well-supported.

guess the business reason why.  the classful spec gave them a good
excuse to do a tcam rinse repeat.  i pay to feed the darned  chickens,
it's time to break the egg.

randy

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Jan 2017 16:40:19 +0900

> it's time to break the egg.

But it's true that supporting /65-/126 increases the cost of the device.
The extra bits have to go somewhere. I think I've seen hardware that just
converted all prefixes to 128 bit if there was at least one /65 - /126
prefix in the FIB. That costs money for RAM. Obviously that's silly if
those prefixes are frequent, and you can save that money using better
software engineering - but software engineering costs money too. Prefixes
don't cost money, and if we know that we won't run out of them, what's the
problem?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Jan 2017 08:34:07 +1300

> ‎I can only support this, while /127 is a good exception for ptp links, it's still useless for small nets with 4-5 IPs like a network between routers and a Firewall cluster.

Please read RFC 7421. For example

   From an early stage, implementations and deployments of IPv6 assumed
   the /64 subnet length, even though routing was based on prefixes of
   any length.
   ...
   The main practical consequence of the existing specifications is that
   deployments in which longer subnet prefixes are used cannot make use
   of SLAAC-configured addresses and require either manually configured
   addresses or DHCPv6.

Nobody is trying to un-CIDRise IPv6. But the price of not applying the
/64 subnet size is that you lose automatic addressing. The 4291bis text
doesn't yet explain this clearly enough.

     Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Jan 2017 16:44:23 -0300

> parameter whose value needs to be fixed globally.)

Well, yes and no. With the traditional slaac (embed the mac address) it
only works with 64-bit IIDs. With something like RFC7217 (grab as many
bits as needed to for an IID), it could work.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Jan 2017 16:45:49 -0300

> directly determine the IID length.

Isn't that the case for the address block we're currently employing? -
the IID is defined to be 64 bits.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Jan 2017 08:58:15 +1300

Regards
   Brian Carpenter

> bits as needed to for an IID), it could work.

Technically that's true, but you can't mix IID sizes on a given link
and expect it to work, so any legacy system will force the whole link
to use /64.

    Brian

---

From: heasley <[email-masked]>
Date: Fri, 13 Jan 2017 20:03:34 +0000

Fri, Jan 13, 2017 at 04:40:19PM +0900, Lorenzo Colitti:
> software engineering - but software engineering costs money too.

do such limited devices really need complex ribs/fibs?  address, router,
neighbors.  all of which are needed regardless of the prefix length.

> Prefixes
> don't cost money,

but, they do: https://www.arin.net/fees/fee_schedule.html

> and if we know that we won't run out of them

do we know this?  and 640k RAM is plenty.  i'm not convinced.

> the problem?

rfc6164 s5.1, s5.2.  s5.2 applies to your ram-limited devices.  end users
that want to subnet can't w/o additional /64s.

---

From: Mark Smith <[email-masked]>
Date: Sat, 14 Jan 2017 07:54:48 +1100

> yes.  simply remove the mandatory requirement for classful global

I think people are combining together in this thread two separate things:

- the addressing structure

- how addresses are processed by routers when the router is forwarding a packet.

In IPv6 they're separate things, in classful IPv4 they weren't (if I
recall correctly).

I think unicast IPv6 could only be described as classful if the
structure of the address dictated how processing of addresses for
forwarding occurred. (You could describe the difference between IPv6
unicast and multicast forwarding to be classful as forwarding is
different for those two types of addresses.)

BCP198/RFC7608, "IPv6 Prefix Length Recommendation for Forwarding"
makes it very clear that forwarding is to occur based on the longest
match rule of an IPv6 address, with no consideration of what the
structure of the address happens to be for the purposes of device
configuration or anything else.

"Abstract

   IPv6 prefix length, as in IPv4, is a parameter conveyed and used in
   IPv6 routing and forwarding processes in accordance with the
   Classless Inter-domain Routing (CIDR) architecture.  The length of an
   IPv6 prefix may be any number from zero to 128, although subnets
   using stateless address autoconfiguration (SLAAC) for address
   allocation conventionally use a /64 prefix.  Hardware and software
   implementations of routing and forwarding should therefore impose no
   rules on prefix length, but implement longest-match-first on prefixes
   of any valid length."

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Jan 2017 17:59:45 -0300

> and expect it to work, so any legacy system will force the whole link

Well, you could say that you don't need to mix IID sizes on the same
link: the IID size is whatever the local router happens to advertise
(i.e., 128-Prefix_Length). And, if you do manual configuration, you're
supposed to know the prefix length...

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Jan 2017 22:06:54 -0500

--On Friday, January 13, 2017 16:40 +0900 Lorenzo Colitti
<[email-masked]> wrote:

> But it's true that supporting /65-/126 increases the cost of
> the device. The extra bits have to go somewhere. I think I've
> seen hardware that just converted all prefixes to 128 bit if
> there was at least one /65 - /126 prefix in the FIB. That
> costs money for RAM. Obviously that's silly if those prefixes
> are frequent, and you can save that money using better
> software engineering - but software engineering costs money
> too. Prefixes don't cost money, and if we know that we won't
> run out of them, what's the problem?

Because you can pick the scenario -- lots of "things", an
interplanetary network, both, or something else-- but we have
been here before.   Every time someone has said "there is so
much address space that we will never run out no matter how
inefficiently we use them", they have eventually been proven
wrong.  That history is obviously not just with the
ARPANET/Internet or even computer networks: "if we know we won't
ever run out of them" has a nasty tendency to prove that we
didn't know and didn't get it right.

     john

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Jan 2017 16:28:10 +1300

> didn't know and didn't get it right.

Which is exactly why we have so far only delegated 1/8 of the
IPv6 address space for global unicast allocation, leaving a *lot*
of space for fixing our mistakes. Moving away from /64 as the
recommended subnet size might, or might not, prove to be necessary in
the long term future. That's why the point about routing being
classless is fundamental. I do think we need to be a bit more
precise on this point in 4291bis.

    Brian

---

From: David Farmer <[email-masked]>
Date: Fri, 13 Jan 2017 22:35:27 -0600

On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter <
[email-masked]> wrote:

> ....

Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and
I'm fine with that, but that's not what the following says.

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long.  Background
   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421
<https://tools.ietf.org/html/rfc7421>].

It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an
Imperative as discussed in section 6 of RFC2119.

I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support
that and believe it to be the consensus of the IETF. Maybe even explicitly
noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support
by SLACC.  But it is not correct to say the /64 is REQUIRED.

I also believe RFC7608 supports this conclusion.

Thanks.

---

From: Mark Smith <[email-masked]>
Date: Sat, 14 Jan 2017 17:37:23 +1100

On 14 Jan. 2017 15:36, "David Farmer" <[email-masked]> wrote:

I don't think /127s should really be recommended either.

They don't guarantee that the ping pong problem is solved, because it
depends on both ends being configured with the /127 prefix length by the
operator or operators at each end if the link. There is no protocol
requirement that both ends of a link have the same prefix and prefix
length, nor is there any protocol checking of that condition.

For example, if an ISP configures a /127 on their end of the customer's
link, but the customer just configures a default route on their end over
the link, it is a legitimate configuration by the protocols, Internet
access will work (so the customer might assume the link is configured
correctly), and yet the link is vulnerable to a ping pong attach despite it
"having" a /127 prefix.

So it is a mitigation, however it relies on the operator or operators being
disciplined about the configuration, and comes at the cost of other things
that may be useful if a 64 bit IID was available e.g. protect against
discovery of link addresses via unsolicited inbound probing if the IIDs are
random (which may include static configuration of an offline generated
random 64 bit IID).

Regards,
Mark.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 15 Jan 2017 08:20:27 +1300

Mark,

I think this thread has shown convincingly that there is a problem with
the current wording of 4291bis about the 64 bit IID length.

I suggest that we wordsmith it on the 6man list and come back to this
broader CC list when we have a proposal.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 15 Jan 2017 08:49:37 +1300

A modest suggestion:

OLD

NEW
   IPv6 routing is based on prefixes of any valid length up to 128 [BCP198].
   For example, [RFC6164] standardises 127 bit  prefixes on point-to-point
   links. However, consistent use of Stateless Address Autoconfiguration
   (SLAAC)[RFC4862] requires that all interfaces on a link use the same length
   of Interface ID. In practice, this means that to guarantee interoperability
   of SLAAC, a fixed length of Interface ID is necessary. For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length is 64 bits. Note that this value is an arbitrary
   choice and might be changed for some future allocation of unicast address
   space. Background on the 64 bit boundary in IPv6 addresses can be found
   in [RFC7421].

Regards
   Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 15 Jan 2017 10:41:45 +1100

Hi,

On 15 Jan. 2017 06:49, "Brian E Carpenter" <[email-masked]>
wrote:

A modest suggestion:

OLD

NEW
   (SLAAC)[RFC4862] requires that all interfaces on a link use the same
length
   of Interface ID. In practice, this means that to guarantee
interoperability

I think that new text is good.

Perhaps a small addition, just to be obvious we have room to change if
necessary.

"Note that this value is an arbitrary
   choice and might be changed for some future allocation of unicast address
   space, outside of the current 1/8th allocation for unicast addresses."

Regards,
Mark.

Regards
   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Jan 2017 00:54:31 +0900

> neighbors.  all of which are needed regardless of the prefix length.

The "/65 - /126 challenged" devices I'm talking about were very big iron
routers.

> > Prefixes don't cost money,
>

No, they don't. The link you provide says you get a /32 for $1000, which
puts the cost of a /64 at $1000 / 2^32 or $0.0000002.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Jan 2017 18:36:50 +0900

Brian,

what's the specific rationale for this change? Is it a bug in 4291 which
you're proposing that we resolve in 4291 bis? If so, what is the bug?

The "interface identifiers are 64 bits" long text in RFC 4291 goes back all
the way to 1998 and the text below would be a major change to text that has
likely been baked into implementations for almost two decades years. I
don't see why we would change that now.

BTW: if the reason for the text is a perceived contradiction between the
fact that "IIDs are 64 bits" and "IPv6 addresses are aggregatable on all
bit lengths" - I don't see a contradiction. In general, IPv6 addresses are
aggregatable on all bit lengths. But global unicast addresses (other than
::/3) have a 64-bit IID, so links in that space are assigned 64-bit prefix
lengths. These two properties can coexist even in global unicast space. For
example, you could load-balance traffic to a given global unicast /64 by
announcing it to the backbone as two /65s. The "addresses are aggregatable
on all bit lengths" text means that the /65 are valid prefixes that can be
routed by routers.

Cheers,
Lorenzo

---

From: Erik Kline <[email-masked]>
Date: Mon, 16 Jan 2017 18:44:42 +0900

It would definitely be very good to see specific text.

Since this is (IIRC) being done for Standards Track purposes, the
primary goal crudely phrased is to collapse the diffs between the base
document and all those that modify it.  Or so I have thought.

Text that illuminates surely seems fine, but text that alters stuff at
this stage doesn't seem like too good an idea to me.

---

From: Randy Bush <[email-masked]>
Date: Mon, 16 Jan 2017 19:59:59 +0900

> document and all those that modify it.

i am not a fan of incorporating the content from A into B.  if you get
it wrongly, we chase the confusion caused by the conflict(s) forever.
and if you get it correctly, then why the heck not just refer to it?

ymmv, of course.

my impression is that the 6man chair and document author (beep) is
trying to produce a stone tablet to be carried down the mountain.  which
is partially why i am being such a bleep about getting it correct.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jan 2017 08:57:51 +1300

> you're proposing that we resolve in 4291 bis? If so, what is the bug?

The bug is that in SLAAC, the IID length is a parameter, not a constant,
and that in routing protocols, the prefix length is a parameter, not
a constant. The addressing architecture needs to recognise that.

> don't see why we would change that now.

Any SLAAC implementation that has 64 baked into it is already non-conformant.
But I very much doubt if anyone will need to change their code as a result
(except for any non-conformant routers such as you mentioned recently).

> bit lengths" - I don't see a contradiction. 

I suggest discussing that with Randy Bush.

> In general, IPv6 addresses are

Sure. And this text doesn't aim to change anything in any current (and
non-broken) implememtations. It aims to respond to the objections that have
been discussed on the IETF list recently.

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 16 Jan 2017 21:27:15 +0100

>    space. Background on the 64 bit boundary in IPv6 addresses can be found

I agree with the change suggestion.  The new text and references are 
enough motivation to clarify that that 64bit limit is an arbitrary 
choice and might change in the future.

Alex

---

From: Fernando Gont <[email-masked]>
Date: Mon, 16 Jan 2017 16:59:30 -0300

On 01/14/2017 04:49 PM, Brian E Carpenter wrote:
>    of SLAAC, a fixed length of Interface ID is necessary.

fixed as "all nodes on the link use the same IID length" or as in "a
hardcoded IID length, as the current 64 value"?

If the former, I agree. If the later, I don't.  The 64-bit length seems
to have a lot to do with embedding MAC addresses (IIRC, the IID length
was something like 48, but then changed to 64 in response to EUI-64).
Certainly, if you generate IIDs by embedding some number which has
constraints (as a MAC address), you need a fixed length. OTOH, if you
select the IIDs from a stream of bits (as RFC7217 does), then you don't
care about the length (other than "as many bits as necessary such that
the host density is low, and hence collisions of IIDs are reduced).

Thanks!

Cheers,

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 16 Jan 2017 14:42:30 -0600

On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu
<[email-masked]> wrote:
> I agree with the change suggestion.  The new text and references are enough
> motivation to clarify that that 64bit limit is an arbitrary choice and might
> change in the future.
>

3GPP assigns 64 bit prefixes to each UE.
Extended Unique Identifiers defined are EUI-48 and EUI-64.
I don't think 64 bit limit is that arbitrary?

Behcet

---

From: Fernando Gont <[email-masked]>
Date: Mon, 16 Jan 2017 17:45:04 -0300

> a constant. The addressing architecture needs to recognise that.

+1

> (except for any non-conformant routers such as you mentioned recently).

+1

> been discussed on the IETF list recently.

Agreed.

(Thanks for proposing text, btw!)

---

From: Fernando Gont <[email-masked]>
Date: Mon, 16 Jan 2017 17:46:29 -0300

> Extended Unique Identifiers defined are EUI-48 and EUI-64.

What does a layer-2 EUI have to do with a layer-3 address?

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 16 Jan 2017 15:22:09 -0600

> What does a layer-2 EUI have to do with a layer-3 address?

I don't know, you tell me :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jan 2017 11:04:01 +1300

In line...
On 17/01/2017 08:59, Fernando Gont wrote:
> If the former, I agree. If the later, I don't. 

You're right, that choice of word could be contradictory.
I suggest s/fixed/consistent/.

    Brian

> The 64-bit length seems

---

From: Fernando Gont <[email-masked]>
Date: Mon, 16 Jan 2017 19:09:52 -0300

> I don't know, you tell me :-)

Answer: Nothing. The fact that we've been embedding layer-2 "addresses"
into layer-3 addresses should not be taken as a reason for the two of
them of having to do anything with each other. So, yes, the 64-bit IID
length is, in reality, arbitrary. They could have been e.g. 32-bits or
48-bits (yes, multiples or 64 or 32 tend to be nicer)

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jan 2017 11:23:47 +1300

> I don't think 64 bit limit is that arbitrary?

It's a parameter, which we happened to set initially to 48
and then changed to 64 because of FireWire. I don't know
why 3GPP chose the same value. But indeed we (the IETF) chose
it because of our now old-fashioned decision to copy Novell
Netware by embedding layer 2 addresses in layer 3. A bad
choice, as it turned out.

The first two definitions of "arbitrary" in Merriam-Webster seem
to fit, especially the second.

"existing or coming about seemingly at random or by chance
or as a capricious and unreasonable act of will"
"based on or determined by individual preference or convenience
rather than by necessity or the intrinsic nature of something"

Regards
    Brian

> .

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Jan 2017 10:08:24 +0900

> a constant. The addressing architecture needs to recognise that.

There is no bug here.

What that text in 4291 says is that if you run SLAAC on a Global Unicast
address not starting with ::/3, then the length of the IID is 64. But when
running SLAAC on non-Global Unicast addresses, or Global Unicast addresses
in ::/3, then the length of the IID is not specified in RFC 4291 (and
presumably left up to the IPv6-over-foo documents).

That is why, for example, RFC 2464 has to say that on Ethernet, the
link-local address "is formed by appending the Interface Identifier [...]
to the prefix FE80::/64". It also says that the IID length is always 64
bits and SLAAC prefixes must be /64. If IPv6 all addresses were classful
and the IID length were always 64 bits there would be no need to say that.

Also, I'd argue that SLAAC exists to generate IPv6 addresses that conform
to the addressing architecture, not the other way around. But that is not
in any way necessary to resolve a conflict between the two documents,
because there is no conflict.

> I suggest discussing that with Randy Bush.

While Randy's "I want to use smaller subnets than /64 because classful
addressing is stupid" is a valid position, that does not mean that there is
a contradiction between the two specifications.

So again - what is the text trying to accomplish? I don't see a bug in the
specs. Therefore, it seems to me that the proposed text is changing the
IPv6 architecture in a pretty fundamental way, and I don't think it's
reasonable to do that at the same time that we elevate it to full standard.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Jan 2017 10:10:03 +0900

Yep. It's an arbitrary choice, just like the choice to make IPv6 addresses
128 bits long, or the choice to make the header 40 bytes long. That doesn't
mean we should change it.

On Tue, Jan 17, 2017 at 7:23 AM, Brian E Carpenter <
[email-masked]> wrote:

> Background
> enough

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jan 2017 14:36:19 +1300

Nobody is saying we should change it in the foreseeable future.
As for the unforeseeable future, I don't know ;-)

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Jan 2017 10:44:00 +0900

But your text does change this arbitrary choice, by removing it.

---

From: Erik Kline <[email-masked]>
Date: Tue, 17 Jan 2017 11:18:40 +0900

On 17 January 2017 at 10:08, Lorenzo Colitti <[email-masked]> wrote:
> On Tue, Jan 17, 2017 at 4:57 AM, Brian E Carpenter
> link-local address "is formed by appending the Interface Identifier [...] to
> the prefix FE80::/64". It also says that the IID length is always 64 bits
> and SLAAC prefixes must be /64. If IPv6 all addresses were classful and the
> IID length were always 64 bits there would be no need to say that.
>
> Also, I'd argue that SLAAC exists to generate IPv6 addresses that conform to
> the addressing architecture, not the other way around. But that is not in
> any way necessary to resolve a conflict between the two documents, because
> there is no conflict.
>
> specs. Therefore, it seems to me that the proposed text is changing the IPv6
> architecture in a pretty fundamental way, and I don't think it's reasonable
> to do that at the same time that we elevate it to full standard.

I would tend to agree.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jan 2017 15:33:06 +1300

> But your text does change this arbitrary choice, by removing it.

Huh? It replaces the lower case required by "that length is 64 bits"
and states that it *might* be changed in the future. And yes, if that
makes designers a bit leery about embedding the constant 64 deep in their
implementations, that is entirely intentional.

   Brian

---

From: Erik Kline <[email-masked]>
Date: Tue, 17 Jan 2017 11:36:54 +0900

>> to do that at the same time that we elevate it to full standard.

Actually, I think the NEW text is pretty reasonable if we could
restore the word "required" for the currently allocated unicast status
quo:

From:

   ... For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length is 64 bits.

To:

   ...  For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length is required to be 64 bits.

We can always produce a document that updates 4291bis for 4::/3 or
whatever we want, and the new text states so explicitly.

But I'm not convinced we should change to text that could be read to
weaken the current situation.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jan 2017 16:39:32 +1300

Erik,

>    value 000, that length is required to be 64 bits.

I could live with that. The "currently allocated" is the point.

    Brian

---

From: David Farmer <[email-masked]>
Date: Mon, 16 Jan 2017 22:32:43 -0600

> weaken the current situation.

The new text correctly states that 64 bit IIDs are required for SLACC,
reinserting "required" back in the phrase above just brings back the
conflict with section 2.4 and RFC6164, BCP198/RFC7608, because the
statement isn't scoped to SLACC.  64 bit IIDs are clearly the consensus
RECOMMENDATION, other than for point-to-point links, but saying they are
REQUIRED for other than SLACC is plainly false.  Manual configuration and
DHCPv6 with other than 64 bit IIDs or /64 subnets, are in operational use
in many places, this is clearly NOT RECOMMENDED, but it is completely
consistent with all the rest of specifications of IPv6.  Furthermore, if
the old text was correctly understood we would not have needed RFC5942 and
BCP198/RFC7608, therefore the old text is clearly faulty.

I support the new text with the minor tweaks begin discussed,
 s/fixed/consistent/.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 Jan 2017 13:52:06 +0900

On Tue, Jan 17, 2017 at 1:32 PM, David Farmer <[email-masked]> wrote:

> REQUIRED for other than SLACC is plainly false.
>

Required for what purpose? For things to work on a particular
implementation? Or required by the standards? As far as the current
standards are concerned, with the exception of /127, IIDs for global
unicast addresses outside ::/0 are required to be 64 bits long, period. If
we change that, we're making a substantive change to the standard.

As for what is required for things to work on your favourite
implementation, the list of of things that will work depends solely on your
definition of work. For some people, things work "work" might "client
applications can reach external servers", and the list of things that will
work (even though it violates various standards) include numbering a
10000-person office with ULA and putting it behind a full-cone NAT66 that
translates everything to one IPv6 address.

> Manual configuration and DHCPv6 with other than 64 bit IIDs or /64
> subnets, are in operational use in many places, this is clearly NOT
> RECOMMENDED, but it is completely consistent with all the rest of
> specifications of IPv6.
>

Citing the "rest of the specifications" here is not germane to the
discussion. Using non-/64 IIDs conflicts with precisely the RFC that is
authoritative on that topic, which is RFC 4291. Saying that it doesn't
conflict with any other RFCs is a bit like saying that tax evasion is not
prohibited by any other law than tax law: (in first approximation) true,
but not really relevant.

>   Furthermore, if the old text was correctly understood we would not have
> needed RFC5942 and BCP198/RFC7608, therefore the old text is clearly faulty.
>

"Not clear" != "faulty". As explained before, there is no conflict between
RFC 4291 and RFC 7608. RFC 7608 applies to forwarding, RFC 4291 applies to
link addressing. I don't see a conflict between RFC 5942 and RFC 4291. Can
you clarify what you mean?

---

From: David Farmer <[email-masked]>
Date: Mon, 16 Jan 2017 22:55:39 -0600

> I suggest s/fixed/consistent/.

With that change I think the use of "consistent" in the previous sentence
is somewhat redundant.  How about;

   However, use of Stateless Address Autoconfiguration (SLAAC)[RFC4862]
   requires that all interfaces on a link use the same length of Interface
ID.
   In practice, this means that to guarantee interoperability of SLAAC, a
   consistent length of Interface ID is necessary.

---

From: David Farmer <[email-masked]>
Date: Mon, 16 Jan 2017 23:35:19 -0600

> we change that, we're making a substantive change to the standard.

What happens if they are not 64 bits long, do the proverbial Internet
police write a ticket?  Do I have to return my addresses to ARIN?  This
seems to be a false imperative to me.  If 64 bit IIDs are really required,
I'd like to see better motivation for this as a requirement.  I only see
motivation for this to be a recommendation, and I'm not the only one.

> prohibited by any other law than tax law: (in first approximation) true,

What breaks if all IIDs in global unicast are not 64 bits?  Especially
other than SLACC?  I would hope such a REQUIREMENT has a better motivation
that "we said so".  Citing the "rest of the specifications" was simply my
shorthand for I don't see what else breaks.

> you clarify what you mean?

I never said there was a conflict between conflict between RFC5942 and
RFC4291, I was very careful about that.  I said there was a "conflict with
section 2.4 and RFC6164, BCP198/RFC7608".

I was saying that the need for RFC5942 and BCP198/RFC7608 are evidence that
the text in question is faulty[1], I think you would prefer misunderstood,
but in my opinion its more that, so I went with faulty.

[1} fault·y - adjective - working badly or unreliably because of
imperfections.

---

From: [email-masked]
Date: Tue, 17 Jan 2017 11:00:49 +0100

> What breaks if all IIDs in global unicast are not 64 bits?  Especially other than SLACC?  I would hope such a REQUIREMENT has a better motivation that "we said so".  Citing the "rest of the specifications" was simply my shorthand for I don't see what else breaks.

RFC7421, section 4.2.

There's also a set of political considerations, where one tries to achieve balance between the provider's desire to have effective aggregation and the end-users desire to have enough address space. We specifically want to avoid provider's charging by the address.

O.

---

From: David Farmer <[email-masked]>
Date: Tue, 17 Jan 2017 08:30:03 -0600

On Tue, Jan 17, 2017 at 4:00 AM, <[email-masked]> wrote:

> There's also a set of political considerations, where one tries to achieve
> balance between the provider's desire to have effective aggregation and the
> end-users desire to have enough address space. We specifically want to
> avoid provider's charging by the address.
>
> O.
>

Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits," but it does
not say to me "IIDs MUST be 64 bits", this is a subtle but important
difference.  Furthermore, RFC7421, section 4.3.2, also say there is
operational use of IID other than 64 bits, which to me disproves the
statement "IIDs MUST be 64 bits" and shifts things to "IIDs SHOULD be 64
bits."

So lets be clear, I'm not saying that we should RECOMMEND other than 64 bit
IIDs, I'm simply differentiating between section 1 and section 3 of RFC
2119.

So, I'm asking what breaks if we change from "IIDs MUST be 64 bits" to the
in my opinion the more proper "IIDs SHOULD be 64 bits".

So, I would prefer:

  ...  For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length should be 64 bits.

But, I'm willing to live with what Brian proposed:

   ... For all currently

But, I can not accept what Eric proposed:

   ...  For all currently

Thanks.

---

From: Tim Chown <[email-masked]>
Date: Tue, 17 Jan 2017 14:57:54 +0000

Hi,

On 17 Jan 2017, at 14:30, David Farmer <[email-masked]<mailto:[email-masked]>> wrote:

RFC7421, section 4.2.

O.

Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits," but it does not say to me "IIDs MUST be 64 bits", this is a subtle but important difference.  Furthermore, RFC7421, section 4.3.2, also say there is operational use of IID other than 64 bits, which to me disproves the statement "IIDs MUST be 64 bits" and shifts things to "IIDs SHOULD be 64 bits.”

Well, when we wrote that document, the aim was to highlight the problems you may encounter if you did go off piste in terms of IID length.  It’s just an informational document, so those “SHOULDs” are purely implicit.

Section 4.3.2 is purely noting comments made on the 6man list during discussion of the Why /64 draft about some rather rare deployments in the wild.  We specifically asked, iirc, about known non /64 host-based subnetting, and this section reports on the responses.

So lets be clear, I'm not saying that we should RECOMMEND other than 64 bit IIDs, I'm simply differentiating between section 1 and section 3 of RFC 2119.

So, I'm asking what breaks if we change from "IIDs MUST be 64 bits" to the in my opinion the more proper "IIDs SHOULD be 64 bits".

So, I would prefer:

  ...  For all currently

   ... For all currently

This seems fine.

Tim

   ...  For all currently

Thanks.
David Farmer               Email:[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 17 Jan 2017 11:39:49 -0600

> 48-bits (yes, multiples or 64 or 32 tend to be nicer)

I don't think you know much about MAC addresses and its history.

Behcet

---

From: Fred Baker <[email-masked]>
Date: Tue, 17 Jan 2017 12:10:18 -0800

On Jan 16, 2017, at 9:35 PM, David Farmer <[email-masked]> wrote:
> What breaks if all IIDs in global unicast are not 64 bits?  Especially other than SLACC?

To my knowledge, the only device that cares about the length of the IID is the device that inspects it, uses it, or supplies it. That would be, in most cases, functionality on the actual host and (perhaps) the router in front of it. There are additional services such as 802.1X or DHCP. Each of those cares about a 128 bit address, not an IID. Everything that doesn't care about a 128 bit address per se cares about a prefix, and the prefix [RFC7608] may have any length from 0 to 128 bits.

The one thing I can think of that cares about an IID separately from an address is SLAAC.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Jan 2017 17:55:52 -0300

Hello, Behcet,

>>>>>> Le 14/01/2017 à 20:49, Brian E Carpenter a écrit :
[....]
> I don't think you know much about MAC addresses and its history.

I don't know much about elephants, either. Whatever the history (which
you imply I don't know), it is irrelevant, because it doesn't change the
fact that you don't need to screw your layer-3 protocol with your
layer-2 IDs/"addresses".

Thanks,

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 17 Jan 2017 15:31:01 -0600

> fact that you don't need to screw your layer-3 protocol with your

Good luck then running SLAAC or ARP :-)

Regards,

Behcet

---

From: [email-masked]
Date: Tue, 17 Jan 2017 22:32:32 +0100

I would argue that we should not make any changes to this text (apart from the eui-64 part).

Cheers,
Ole

> Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits," but it does not say to me "IIDs MUST be 64 bits", this is a subtle but important difference.  Furthermore, RFC7421, section 4.3.2, also say there is operational use of IID other than 64 bits, which to me disproves the statement "IIDs MUST be 64 bits" and shifts things to "IIDs SHOULD be 64 bits."
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jan 2017 11:28:55 +1300

On 17/01/2017 17:52, Lorenzo Colitti wrote:
...
> "Not clear" != "faulty". 

On the contrary, in a standards document, "Not clear" == "faulty"

Really. If we publish text that is logically correct but can easily
be misread (or, of course, text that is ambiguous) then it's faulty text.

(On a personal note, I have always tried to discipline myself thus:
if *anybody* misinterprets some text that I wrote, however clear
I believe it to be, then it's the text that needs fixing, not the
reader.)

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jan 2017 11:37:36 +1300

> I would argue that we should not make any changes to this text (apart from the eui-64 part).

I think that the discussion on the IETF list has already shown that there is no
consensus for the current text. I don't agree with it any more, either. It hides
the tension between CIDR and the consistent length needed for SLAAC.

Hence I'm still proposing that we change it. I think the median view at the moment
is for the version that runs

  ...  For all currently

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 18 Jan 2017 00:16:28 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter

>    value 000, that length should be 64 bits.

I think that as things are today, for unicast addresses allocated that may use SLAAC, the "should" might not be strong enough. We have no other implementation of SLAAC, other than one that uses 64-bit IIDs. But I agree with you, when you said that future implementations may not require 64-bit IIDs for SLAAC.

But I completely concur with your point about tension with CIDR. In fact, one thing that has always bothered me about the wording "all currently allocated unicast addresses, except those that start with the binary value 000," is that it sounds like the 64-bit IID rule holds for the majority of the unicast address space. But that's not true. Only 1/8 of the total address space is "currently assigned to unicast," and a subset of that 1/8th has the stipulation that the IIDs can be of any length.

But the majority of the unicast address space is unconstrained, as it should be. Somehow, it always ends up sounding the 64-bit IID is a fixture, in most IPv6 unicast.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Jan 2017 19:08:37 -0300

> Good luck then running SLAAC or ARP :-)

SLAAC: Yes, mac addresses used to be embedded in the IID, That's an
artifact of history, not a design principle. And we're heading towards
replacing that with RFC7217 (which, for many implementations, is already
the case) -- and has always been the case for, e.g., RFC4941.

Neighbor Discovery: NS/NA messages employ link-layer address options,
which essentially convey the link-layer address as an opaque value.
That's used for learning the layer-2 address when sending a packet on a
link, which is a totally different thing from exposing such layer-2
address at layer-3.

There's no reason or requirement that I communicate my layer-2 address
in my layer-3 protocol when, e.g., I connect with a web server. That has
been an artifact of history (which may have happened as such for
multiple (possibly valid) reasons), but please don't confuse that with a
design principle or some sort of law from nature.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Jan 2017 23:00:02 -0300

> I believe it to be, then it's the text that needs fixing, not the

+1 (and applause ;-) )

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 17 Jan 2017 23:04:08 -0300

On 01/17/2017 09:16 PM, Manfredi, Albert E wrote:
>> -----Original Message----- From: ipv6
>> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> 
>> I think that the discussion on the IETF list has already shown that
>> there is no consensus for the current text. I don't agree with it
>> any more, either. It hides the tension between CIDR and the
>> consistent length needed for SLAAC.
>> 
>> Hence I'm still proposing that we change it. I think the median
>> view at the moment is for the version that runs
>> 
>> ...  For all currently allocated unicast addresses, except those
>> that start with the binary value 000, that length should be 64
>> bits.
> 
> I think that as things are today, for unicast addresses allocated
> that may use SLAAC, the "should" might not be strong enough. We have
> no other implementation of SLAAC, other than one that uses 64-bit
> IIDs. But I agree with you, when you said that future implementations
> may not require 64-bit IIDs for SLAAC.
> 
> But I completely concur with your point about tension with CIDR. In
> fact, one thing that has always bothered me about the wording "all
> currently allocated unicast addresses, except those that start with
> the binary value 000," is that it sounds like the 64-bit IID rule
> holds for the majority of the unicast address space. But that's not
> true. Only 1/8 of the total address space is "currently assigned to
> unicast," and a subset of that 1/8th has the stipulation that the
> IIDs can be of any length.
> 
> But the majority of the unicast address space is unconstrained, as it
> should be. Somehow, it always ends up sounding the 64-bit IID is a
> fixture, in most IPv6 unicast.

Has anyone tred what happens if a prefix from::/3 is advertised for slaac?

I wouldn't be surprised if, if we happen to want to use non-64 IIDS for
::/3, we find that we cannot because this 64-bit value is hardcoded
everywhere.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 Jan 2017 16:36:48 +0900

+1

I don't think we should change this text in a reclassification. The fact
that there are such strong opinions about the fixed boundary suggests that
people think that it's an important property of the standard.

That text has been the standard for almost 20 years. If we want to change
it, then let's do it the right way: write a draft of a document that
updates 4291 (or updates whatever number 4291bis ends up being, if we can
somehow resolve the current point and publish it), and see if we can reach
consensus. I doubt that will be easy.

On Wed, Jan 18, 2017 at 6:32 AM, <[email-masked]> wrote:

> > There's also a set of political considerations, where one tries to
> achieve balance between the provider's desire to have effective aggregation
> and the end-users desire to have enough address space. We specifically want
> to avoid provider's charging by the address.
> >
> > O.
> >
> > Exactly, and to me RFC7421 say to me "IIDs SHOULD be 64 bits," but it
> does not say to me "IIDs MUST be 64 bits", this is a subtle but important
> > So lets be clear, I'm not saying that we should RECOMMEND other than 64
> bit IIDs, I'm simply differentiating between section 1 and section 3 of RFC
> 2119.
> >
> > So, I'm asking what breaks if we change from "IIDs MUST be 64 bits" to
> the in my opinion the more proper "IIDs SHOULD be 64 bits".
> >
> > So, I would prefer:
> >
> >   ...  For all currently

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 Jan 2017 16:42:19 +0900

On what link type? On Ethernet, RFC 2464 clearly defines the IID length to
be 64 bits, period. So /64 is correct.

If there's an IPv6-over-foo document that does not specify the IID length,
then the IID length is unspecified. Because it's unspecified, whatever they
pick is fine. "Do nothing" or "use /64 for consistency with global
addresses" would be the most obvious choices.

---

From: Timothy Winters <[email-masked]>
Date: Wed, 18 Jan 2017 07:57:40 -0500

Hi Fernando,

IPv6 Ready Logo have a test that advertises a prefix length of /96 for
SLAAC, with the a flag set and we check that it's used for on-link
determination as per 4862.

"In fact, the advertised length has non-trivial meaning for on-link
      determination in [RFC4861] where the sum of the prefix length and
      the interface identifier length may not be equal to 128.

If you read 5.5.3 of 4862 it has some text about prefix length and
interface-id having to add up to 128.

"If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored."

We haven't tried /3 but I'd be happy to try it on implementations to see
what they do if it's interesting to the working group.   My guess is they
will ignore it for SLAAC but use it for on-link.

~Tim

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR

---

From: [email-masked]
Date: Wed, 18 Jan 2017 14:08:19 +0100

Brian,

>   value 000, that length should be 64 bits.

The 64-bit boundary is hard to defend technically. It is for example trivial to make SLAAC deal with variable length prefixes.
Our strongest argument is probably 8+8 aka ILNP.

The other side "the CIDR argument" has no technical argument foot to stand on either. There is no technical argument why the network / routing side would require more than 64 bits.

Given that what we are left with is policy, I think it is quite harsh of you to declare that there is no consensus on the current text on the IETF list.
There are good technical arguments for why each host needs more than a single address, and if we end up in a situation similar to IPv4 where each address used has to be justified, then we have lost. There is a justified fear that allowing the 64 bit boundary to slide, we will end up in a situation similar to IPv4 addressing. E.g. charging per address.

This is where the IETF has to perform a fine balancing act. On one side ensure that the 64 bit boundary stands, at the other side ensure that all implementors do not enshrine a hard-coded boundary in their implementations.

O.

---

From: [email-masked]
Date: Wed, 18 Jan 2017 14:34:37 +0100

Brian,

> I believe it to be, then it's the text that needs fixing, not the

In the parts of a document describing the exact protocol specification and where it affects interoperability I do agree with you.
In other parts of a document I think ambiguity  and leaving leeway up to future readers is perfectly fine.
Being very strict about this, might lead us into being prescriptive where we have no business being prescriptive.

O.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 18 Jan 2017 11:21:12 -0600

> design principle or some sort of law from nature.

My friend Fernando, here is a quote from RFC 4941:

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.

 I believe you will always need to send a packet on a link, even when
connecting with a web server.

I think you should read a basic telecom book such as from Jim Kurose.
Also I think you and I are in agreement. No worries.

Regards,

Behcet

---

From: David Farmer <[email-masked]>
Date: Wed, 18 Jan 2017 12:09:29 -0600

For such a supposedly "fixed boundary" it's awfully schizophrenic. We
supposedly want the option to change it in the future if necessary.  So,
then it's not so fixed that it's intended to be immutable, which is why we
needed RFC 5942 and RFC 7608. It's not so fixed that we don't have
exceptions, we have standardized /127 subnets and 127 IIDs for
point-to-points links, with RFC 6164. It doesn't sound so fixed to me, and
it seems intellectually dishonest as a standards body to keep saying it's a
fixed boundary when their is so much evidence to the contrary.  If fact, I
believe it is down right dangerous and counter productive to our intent to
keep saying it's a fixed boundary.

If we are simply start calling it a "recommended subnet size" then the
issues that make a "fixed boundary" schizophrenic are no longer much of an
issue. Recommendations frequently have exceptions and they are allowed to
change as things evolve, "fixed boundaries" aren't suppose to do either of
those.  /64 subnets are properly a recommendation, all be it, a very
important recommendation, maybe even a fundamental.  But, just because a
recommendation is important doesn't turn it in to a requirement.  That is
intellectually dishonest and section 6 of RFC 2119 warns against it.

If we want/need to enshrine /64 subnets and 64 bit IIDs for SLACC I'm
willing to live with that.  But to enshrining /64 subnets and 64 bit IIDs
for all of IPv6 is a mistake. And, it's a mistake that I feel needs
correcting before this document is promoted to full Internet Standard.

So, how about;

   ... For all currently
   allocated unicast addresses, except those that start with the binary
   value 000, that length should be 64 bits and for SLACC [RFC 4862]
   that length is required to be 64 bits.

On Wed, Jan 18, 2017 at 1:36 AM, Lorenzo Colitti <[email-masked]> wrote:

>> > > What breaks if all IIDs in global unicast are not 64 bits?
>> Especially other than SLACC?  I would hope such a REQUIREMENT has a better
>> motivation that "we said so".  Citing the "rest of the specifications" was
>> simply my shorthand for I don't see what else breaks.
>> >
>> > RFC7421, section 4.2.
>> >

---

From: james woodyatt <[email-masked]>
Date: Wed, 18 Jan 2017 10:50:51 -0800

> weaken the current situation.

I fully agree.

My apologies if I’m coming into the discussion with a point everyone has already dismissed, but it seems to me there is a procedural matter regarding the fact that RFC 4941 doesn’t actually describe how to generate temporary addresses with IID length other than 64 bits.

In the first paragraph of Section 1, RFC 4941 says "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.” And nothing else about it appears elsewhere in the text. It doesn’t seem like a host receiving a RA Message containing a PIO option with A=1 is permitted to generate temporary addresses by SLAAC unless the prefix length is 64 bits.

This seems important to me because the text Erik proposes here provides a guarantee to sub-IPv6 link protocol developers that RFC 4941 is an available as a standard for generating temporary addresses using SLAAC for every currently allocated globally-unique prefix. If that requirement disappears in RFC 4291bis, then those of us involved in the development of new sub-IPv6 link layers will not have that guarantee, which may force some of us to develop link-layer alternatives (possibly involving address translation) in order to provide comparable address privacy properties on subnets with globally-unique prefixes longer than 64 bits.

I don’t want to see 6MAN place this possible new requirement on link-layer developers by removing it from IPv6.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 18 Jan 2017 11:29:35 -0800

At Tue, 17 Jan 2017 23:04:08 -0300,

> Has anyone tred what happens if a prefix from::/3 is advertised for slaac?

I didn't, but I'm quite sure about BSD variants (perhaps including
iOS) that they don't check the prefix (as long as they are global) for
the purpose of SLAAC.  This is based on the interpretation of RFC4862
that for the purpose of SLAAC the IID length is solely a parameter of
the underlying link:

   interface identifier -  a link-dependent identifier for an interface
      that is (at least) unique per link [RFC4291].  Stateless address
      autoconfiguration combines an interface identifier with a prefix
      to form an address.  From address autoconfiguration's perspective,
      an interface identifier is a bit string of known length.  The
      exact length of an interface identifier and the way it is created
      is defined in a separate link-type specific document that covers
      issues related to the transmission of IP over a particular link
      type (e.g., [RFC2464]).  Note that the address architecture
      [RFC4291] also defines the length of the interface identifiers for
      some set of addresses, but the two sets of definitions must be
      consistent.  In many cases, the identifier will be derived from
      the interface's link-layer address.

So, for example, if the advertised prefix length on an Ethernet link
is not 64, that prefix is simply ignored for SLAAC according to
Section 5.5.3 d) of RFC4862:

      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored.

That's the same regardless of what prefix it is, whether it's in or
outside of ::/3.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jan 2017 13:37:57 +1300

OK, after all that discussion, here is a revised proposal. There is
nothing new here at all, IMHO; just clarification:

OLD

NEW
   IPv6 routing is based on prefixes of any valid length up to 128 [BCP198].
   For example, [RFC6164] standardises 127 bit prefixes on point-to-point
   links. However, consistent use of Stateless Address Autoconfiguration
   (SLAAC)[RFC4862] requires that all interfaces on a link use the same length
   of Interface ID. To guarantee interoperability of SLAAC, a fixed length of
   Interface ID is necessary. For all currently allocated unicast addresses,
   except those that start with the binary value 000, Interface IDs are
   required to be 64 bits long.  Background on the 64 bit boundary in IPv6
   addresses can be found in [RFC7421].

Regards
   Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 19 Jan 2017 02:46:00 +0000

>    addresses can be found in [RFC7421].

Just some minor edits, to tie together the ideas.

NEW
   IPv6 routing is based on prefixes of any valid length up to 128 [BCP198].
   For example, [RFC6164] standardises 127 bit prefixes on point-to-point
   links. However, consistent use of Stateless Address Autoconfiguration
   (SLAAC)[RFC4862] requires all interfaces on a link to use the same length
   of Interface ID. Furthermore, to guarantee robust interoperability of SLAAC,
   a standard, fixed length of Interface ID is necessary. For this reason, the
   Interface ID of all currently allocated unicast addresses, except those that
   start with the binary value 000, are required to be 64 bits long.
   Background on the 64 bit boundary in IPv6 addresses can be found in
   [RFC7421].

I don't think that SLAAC *must* require a single standard IID length, so that's why I added the word "robust." Now that we have moved away from using the MAC address for SLAAC, it's not clear to me why a host cannot wait for a RA, and then decide on how many IID bits to use, based on the prefix length(s) advertised by the router.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 19 Jan 2017 02:55:27 +0000

Shoot. Grammar alert. Subject must agree with predicate.

NEW
   IPv6 routing is based on prefixes of any valid length up to 128 [BCP198].
   For example, [RFC6164] standardises 127 bit prefixes on point-to-point
   links. However, consistent use of Stateless Address Autoconfiguration
   (SLAAC)[RFC4862] requires all interfaces on a link to use the same length
   of Interface ID. Furthermore, to guarantee robust interoperability of SLAAC,
   a standard, fixed length of Interface ID is desirable. For this reason, the
   Interface ID of all currently allocated unicast addresses, except those that
   start with the binary value 000, is required to be 64 bits long. Background
   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].

Bert

> From: ipv6 [mailto:[email-masked]] On Behalf Of Manfredi, Albert E
> Sent: Wednesday, January 18, 2017 21:46
> To: Brian E Carpenter <[email-masked]>; 6man <[email-masked]>
> Subject: RE: Updated IID length text
> 
> I don't think that SLAAC *must* require a single standard IID length, so
> that's why I added the word "robust." Now that we have moved away from using
> the MAC address for SLAAC, it's not clear to me why a host cannot wait for a
> RA, and then decide on how many IID bits to use, based on the prefix
> length(s) advertised by the router.
> 
> Bert
> 
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Jan 2017 12:00:54 +0900

On Thu, Jan 19, 2017 at 9:37 AM, Brian E Carpenter <
[email-masked]> wrote:

> However, consistent use of Stateless Address Autoconfiguration
>    Interface ID is necessary.

I'm not a fan of this text, because it's a weak argument. A possible
(uninformed) response to it might be "why do we need this SLAAC thing
anyway? I want to use /120 prefixes and DHCPv6, just like I do in IPv4".
And really, SLAAC is only one of the reasons why we have a 64-bit IID.
There are lots of good arguments for this in RFC7421 - solid arguments,
about address scarcity and future flexibility, and so on. We should let
those provide the rationale since they can give a much more complete
picture than we can in two lines here. Since you cite RFC7421 just a couple
of lines down, I would just strike this text entirely, since it looks like
the text is only there to justify the following normative text.

I think I'm fine with the text that precedes it ("   IPv6 routing is based
on prefixes of any valid length up to 128 [BCP198]. For example, [RFC6164]
...)" and the text that follows it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Jan 2017 12:04:09 +0900

On Thu, Jan 19, 2017 at 11:46 AM, Manfredi, Albert E <
[email-masked]> wrote:

> Now that we have moved away from using the MAC address for SLAAC, it's not
> clear to me why a host cannot wait for a RA, and then decide on how many
> IID bits to use, based on the prefix length(s) advertised by the router.
>

The reason it can't do that is that in practice SLAAC only works well if
the probability of collision is negligible. Even reducing that from 64 bits
to 48 bits impacts that substantially.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jan 2017 16:23:55 +1300

On 19/01/2017 15:55, Manfredi, Albert E wrote:
...
>> length(s) advertised by the router.

Not if you want to form a link-local address first. Which you always do,
because perhaps there *is* no router when you come up after a power cut.
(In the Anima WG, we are very interested in the behaviour of nodes
that have absolutely no external information when they come up, because
it's their job to bootstrap the network out of nowhere.)

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 19 Jan 2017 03:24:14 +0000

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

>> Now that we have moved away from using the MAC address for SLAAC, it's
>> not clear to me why a host cannot wait for a RA, and then decide on
>> how many IID bits to use, based on the prefix length(s) advertised by
>> the router.
>
> The reason it can't do that is that in practice SLAAC only works well
> if the probability of collision is negligible. Even reducing that from
> 64 bits to 48 bits impacts that substantially.

Perhaps, but SLAAC has been deemed to work adequately well with only the 48-bit MAC address (presumably) being unique. So nothing would change in this "negligible collision" regard, if we allowed for 80-bit prefixes with SLAAC. You'd want to do duplicate address detection regardless.

Back in the 1980s, it probably seemed that 32 bits, to identify research computers, was way more than adequate. Clearly, people had not anticipated how this Internet was going to be used. Same applies now.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 19 Jan 2017 03:30:27 +0000

-----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
 
> it's their job to bootstrap the network out of nowhere.)

Right, but you can differentiate that link local address from global addresses, so you can require it to have 64-bit IIDs. It's for the global addresses that I think we don't want to repeat the CIDR lessons of the past. Ditto for ULAs, for example.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 Jan 2017 00:51:24 -0300

On 01/19/2017 12:04 AM, Lorenzo Colitti wrote:
> On Thu, Jan 19, 2017 at 11:46 AM, Manfredi, Albert E
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Now that we have moved away from using the MAC address for SLAAC,
>     it's not clear to me why a host cannot wait for a RA, and then
>     decide on how many IID bits to use, based on the prefix length(s)
>     advertised by the router.
> 
> 
> the probability of collision is negligible. Even reducing that from 64
> bits to 48 bits impacts that substantially.

Oh, I love this. So you are a fan of still doing modified EUI-64 with
randomized MAC addresses (which wastes 18 bits, including the 16 bits
that are wasted with embedding 0xfffe), and now you say that using /48
would impact things substantially?

This can't possibly make sense.

If you do /48 + RFC7217, you get even two ore bits of entropy than if
you do Modified EUI-64 with random MAC addresses (a flowed scheme that
you've been fighting for for a while now)

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Jan 2017 13:07:50 +0900

On Thu, Jan 19, 2017 at 12:24 PM, Manfredi, Albert E <
[email-masked]> wrote:

> Perhaps, but SLAAC has been deemed to work adequately well with only the
> 48-bit MAC address (presumably) being unique. So nothing would change in
> this "negligible collision" regard, if we allowed for 80-bit prefixes with
> SLAAC. You'd want to do duplicate address detection regardless.
>

No, the situation with MAC addresses is different because they are intended
to be unique.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Jan 2017 13:12:36 +0900

> This can't possibly make sense.

It does make sense. /48 does impact things substantially. However, on like
like wifi, the MAC address is the endpoint identifier, so if there's a
duplicate MAC you can't get on the network.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 Jan 2017 01:03:10 -0300

Hi, Brian,

s/fixed/consistent/.

Thanks for your energy in this,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 Jan 2017 01:20:21 -0300

On 01/19/2017 01:12 AM, Lorenzo Colitti wrote:
> On Thu, Jan 19, 2017 at 12:51 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> It does make sense. /48 does impact things substantially. However, on
> like like wifi, the MAC address is the endpoint identifier, so if
> there's a duplicate MAC you can't get on the network.

Could you please explain how you do the math such that in these two
scenarios:

#1: SLAAC with 48-bit IIDs, where the IID is a random string of bits
    (e.g. as resulting from RFC7217)

#2: Traditional SLAAC with 64-bit IIDs, where the IID is generated from
    a randomized MAC address (and in which, based on how MOdified EUI64
    IIDs are generated, you have to embed the fixed 16-bit word 0xfffe
    in the IID)

..you get a reduced IID collision rate with #2?

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Jan 2017 13:25:39 +0900

>     IIDs are generated, you have to embed the fixed 16-bit word 0xfffe

You forgot the "where layer 2 ensures that there are no duplicate MAC
addresses on the network" part of this scenario.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 Jan 2017 02:38:36 -0300

On 01/19/2017 01:25 AM, Lorenzo Colitti wrote:
> On Thu, Jan 19, 2017 at 1:20 PM, Fernando Gont <[email-masked]

1) AP != Network -- you might be assuming the network is simpler than it
really is

2) How many nodes do you need in a 48-bit space for the probability of
collisions to become a concern?

3) If you are concerned about collisions in 48 bits as a result of
random numbers, I'm curious why layer-3 concerns you more --
particularly when, in layer-3 you do have a mechanism for detecting
them, and one for recovering from them (whereas in layer-2, you don't).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 19 Jan 2017 02:48:37 -0300

On 01/19/2017 12:00 AM, Lorenzo Colitti wrote:
> On Thu, Jan 19, 2017 at 9:37 AM, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 

Please enlighten me. The 64-bit length has to do with SLAAC, and the
fact that the IID had to be able to embed 64-bit link-layer addresses.

If you were to start with a clean slate, you wouldn't embed link-layer
addresses in the layer-3 address, and hence wouldn't need to do
fixed-length 64-bit IIDs. With manual configuration or DHCPv6, you would
support "any size that can fit all your systems and allow your network
to grow". And with SLAAC (+ something like RFC7217), it would be the
same, with the contraint that "the size results in low host density, so
that IID collisions are not a concern".

> about address scarcity and future flexibility, and so on. 

That translates well into "well... we have so many bits that... let's
burn them in any possible way" (fwiw, I don't think that's the argument
being made in RFC7421, though)

An artifact of history need not and does not automagically become a
design principle.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Jan 2017 15:21:10 +0900

> 1) AP != Network -- you might be assuming the network is simpler than it

In small networks, the probability of collision is low because there are
few devices. Large networks are usually built with a centralized control
plane, because otherwise roaming doesn't work, and in that sort of network,
MAC addresses have to be unique or devices don't get on the network.

> collisions to become a concern?

I never said the probability is unacceptable with 48 bits. That depends a
lot on the network circumstances. What I said that the increase in
probability when going down from 64 bits to 48 bits, which it is. If you
want 99.999% chance of no collisions, with 48 random bits I that puts you
between 10k and 100k devices. With 64 bits that's more like 10^35 devices.
That's an incredible difference. At 32 bits it's a joke - 1% chance of
collision at 10k devices.

> them, and one for recovering from them (whereas in layer-2, you don't).

Sigh. Consider 802.11 wifi. Dynamic MAC addresses are desirable for privacy
reasons. If there's a random MAC address collision, you don't get on the
network (most of the time; as discussed above). At that point you either
fail or you try again with a different random MAC address. That's your
retry mechanism. Once you've cleared that retry mechanism, L2 guarantees
that your EUI-64-based IPv6 address is unique.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Jan 2017 10:26:09 +0100

Le 19/01/2017 à 04:00, Lorenzo Colitti a écrit :
> length of Interface ID. To guarantee interoperability of SLAAC, a
> fixed length of Interface ID is necessary.
>
>
>  (uninformed) response to it might be "why do we need this SLAAC
> thing anyway? I want to use /120 prefixes and DHCPv6, just like I do
> in IPv4". And really, SLAAC is only one of the reasons why we have a
> 64-bit IID. There are lots of good arguments for this in RFC7421 -
> solid arguments, about address scarcity and future flexibility, and
> so on. We should let those provide the rationale since they can give
> a much more complete picture than we can in two lines here. Since
> you cite RFC7421 just a couple of lines down, I would just strike
> this text entirely, since it looks like the text is only there to
> justify the following normative text.
>
> I think I'm fine with the text that precedes it ("   IPv6 routing is
>  based on prefixes of any valid length up to 128 [BCP198]. For
> example, [RFC6164] ...)" and the text that follows it.

I am fine with that part too.

I do not agree with the part that says "IIDs are required be 64bit long".

If IIDs are required to be 64bit long (even if only in the 000-prefixed
space) then the network can not grow at the edges, at least not with
SLAAC.

The network can not grow at the edges with SLAAC because the operators
are already at this limit; they imagine no-one needs to grow beyond it.
  They also imagine that a 2^64 is enough for an end user, w/o
understanding that /64 is but one subnet (because of SLAAC).

We need the network to grow at the edge: cascading subnets at the edge.

I could agree though the RFC2464-10MbitsEthernet be IID-len 64.
Provided that document is used only on 10Mbps wired Ethernet only (not
on WiFi, etc.)  New documents for IPv6-over-WiFi,
IPv6-over-100GBEthernet, could use other that 64bit IID lengths.

Alex

Alex

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 19 Jan 2017 18:49:10 +0900

> understanding that /64 is but one subnet (because of SLAAC).

There are lots of things that you can do with one /64. For example, you can
bridge at layer 2 and connect as many devices as you want.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Jan 2017 10:58:23 +0100

Le 19/01/2017 à 10:49, Lorenzo Colitti a écrit :
> On Thu, Jan 19, 2017 at 6:26 PM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> There are lots of things that you can do with one /64. For example, you
> can bridge at layer 2 and connect as many devices as you want.

Yes there are, and there are not: bridging only scales that much (maybe 
1 or 2 PANs, but not to thousands of vehicles); bridging does not 
separate strongly enough between e.g. entertainment and safety.

Alex

---

From: Sander Steffann <[email-masked]>
Date: Thu, 19 Jan 2017 15:14:01 +0100

Hi Ole,

> There are good technical arguments for why each host needs more than a single address, and if we end up in a situation similar to IPv4 where each address used has to be justified, then we have lost…

Well said, this is exactly the same feeling I have about the 64 bit boundary. I don't think it's important what its exact history is, what the relation to layer-2 addresses is, etc. What is important is that we don't end up with situations where users and devices end up without enough addresses despite the abundance that IPv6 provides.

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2017 08:26:30 +1300

On 19/01/2017 22:26, Alexandre Petrescu wrote:
...
> I do not agree with the part that says "IIDs are required be 64bit long".

But they are, today. In the move to full Standard, we cannot actually
change that; we can only clarify the wording.

> space) then the network can not grow at the edges, at least not with

That would be true if /64 prefixes were scarce. They are not. But that's
why the proposed text is limited to currently allocated unicast space -
if we ever need to change this, it will be a new tranche of unicast space.
In any case, this is nothing to do with progressing to full Standard.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2017 08:28:32 +1300

Hi Fernando,
>>    Interface ID is necessary. 

That would use the word 'consistent' twice, which is slightly horrible English.
But I agree with the intention.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2017 08:41:25 +1300

> it's their job to bootstrap the network out of nowhere.)

I should have added that in the context of promoting the document to
full Standard, we can't introduce new behaviour. But I don't object to the word
'robust'.  I don't think it makes sense to use the word 'standard' inside a
standard, however. And using 'consistent' twice is ugly. So I get to

NEW NEW
   IPv6 routing is based on prefixes of any valid length up to 128 [BCP198].
   For example, [RFC6164] standardises 127 bit prefixes on point-to-point
   links. However, correct use of Stateless Address Autoconfiguration
   (SLAAC)[RFC4862] requires all interfaces on a link to use the same length
   of Interface ID. Furthermore, to guarantee robust interoperability of SLAAC,
   a consistent length of Interface ID is desirable. For this reason, the
   Interface ID of all currently allocated unicast addresses, except those that
   start with the binary value 000, is required to be 64 bits long. Background
   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].

Any speculation about deviations from /64 is out of scope, IMHO, for
a draft being proposed for full Standard, given that 4291 requires /64.

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 19 Jan 2017 20:30:34 +0000

Brian, I'm completely on board with your text below. I think that this should satisfy even the objections, by avoiding any "speculation."

Bert 

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Thursday, January 19, 2017 14:41
To: Manfredi, Albert E <[email-masked]>; 6man <[email-masked]>
Subject: Re: Updated IID length text

NEW NEW

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 19 Jan 2017 21:02:40 +0000

> From: [email-masked] [mailto:[email-masked]]
> 
> Brian,
> 
> [...]
> 
> > NEW NEW
> By changing "For all unicast addresses" to "all currently allocated unicast
> addresses",
> 
> Are you proposing to reverse the decision that was made back when RFC3513
> updated RFC2373?
> Change log:
> -  Revised sections 2.4 and 2.5.6
>  to simplify and clarify how
>       different address types  are identified.  This was done to insure
>       that implementations do not build in any knowledge about global
>       unicast format prefixes.  Changes include:
>          o  Removed Format Prefix (FP) terminology
>          o  Revised list of address types to only include exceptions to
>             global unicast and a singe entry that identifies everything
>             else as Global Unicast.

Not speaking for Brian, my reaction to the RFC 3513 text would be that Brian's new text better responds to "This was done to insure that implementations do not build in any knowledge about global unicast format prefixes."

We have a pragmatic requirement of 64-bit IIDs, for the existing (minority) of assigned global unicast addresses. But we don't want to reverse the intention for CIDR, stated in RFC 3513. This is the "tension" with CIDR, which has existed for too many years.

Bert

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Jan 2017 22:57:13 +0100

Le 19/01/2017 à 20:26, Brian E Carpenter a écrit :
> On 19/01/2017 22:26, Alexandre Petrescu wrote: ...
>> If IIDs are required to be 64bit long (even if only in the
>> 000-prefixed space) then the network can not grow at the edges, at
>> least not with SLAAC.
>
> That would be true if /64 prefixes were scarce. They are not.

The mobile network operators today make it look as if the /64
prefixes were scarce.

Maybe they dont know these /64 are not scarce, or maybe they dont care
about scarcity (just as it's not IPv4 scarcity making them deploy IPv6).
  The end result is the same: end users get each a /64, i.e. one single
subnet.

Spec-wise the IID len cant change, the Ethernet IID len cant change, the
DHCPv6 PD is not deployed, the operators only give a /64 to end user...
one is free to pick the reason, and again the end result is the same: no
growth at the edge.

The archi document is free to recognize reality.  If so, it should
recognize it so in a paragraph: no growth at the edges.

Alex

> But that's why the proposed text is limited to currently allocated
> unicast space - if we ever need to change this, it will be a new
> tranche of unicast space. In any case, this is nothing to do with
> progressing to full Standard.
>
> Brian
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 19 Jan 2017 22:04:01 +0000

Hi Alex,

> From: ipv6 [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Thursday, January 19, 2017 1:57 PM
> To: [email-masked]

I have deployed DHCPv6 PD in my network, and use it all the time for
mobile devices.

Thanks - Fred

---

From: Mark Andrews <[email-masked]>
Date: Fri, 20 Jan 2017 09:58:58 +1100

In message <[email-masked]>, Alexandre Petrescu writes:
> 
> 
> Le 19/01/2017 =E0 20:26, Brian E Carpenter a =E9crit :

>From https://getipv6.info/display/IPv6/3GPP+Mobile+Networks

Release 10 introduced DHCPv6-PD to the standards.

If you operator doesn't support 3GPP Release 10 complain to them.

>From memory DHCP-PD and the early releases of 3GPP were happening
at about the same time and 3GPP decided not to wait for DHCP-PD.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Farmer <[email-masked]>
Date: Thu, 19 Jan 2017 17:31:16 -0600

On Wed, Jan 18, 2017 at 7:08 AM, <[email-masked]> wrote:
>
> Given that what we are left with is policy, I think it is quite harsh of
> you to declare that there is no consensus on the current text on the IETF
> list.
> There are good technical arguments for why each host needs more than a
> single address, and if we end up in a situation similar to IPv4 where each
> address used has to be justified, then we have lost. There is a justified
> fear that allowing the 64 bit boundary to slide, we will end up in a
> situation similar to IPv4 addressing. E.g. charging per address.
>

I'm a little worried that your fighting yesterday's battle.  To be honest,
I'm less worried about charing for more than one IP address. I'm much more
worried about charging for more than one subnet. In fact, I'm worried a
hard and inflexible boundary at /64 reinforces a model for charging for
more than one subnet.

If that happens would you prefer people use NTPv6 or NAT66?  I'd prefer a
more flexible subnet boundary, that allows the18 quadrillion addresses in a
/64 to be broken into smaller subnets.

Furthermore, we are talking about giving individual devices their own
subnets.  I like this model and with today's scale that will be fine.  But,
longer-term this has me worried, especially if we keep a inflexible /64
boundary.

This is where the IETF has to perform a fine balancing act. On one side
> ensure that the 64 bit boundary stands, at the other side ensure that all
> implementors do not enshrine a hard-coded boundary in their implementations.
>

Ok, are you willing to put that in the document?  The /64 requirement, is a
political consideration, not a technical one.  Because other than /64
subnets are clearly technically possible, we have evidence of it in RFC
7421.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2017 14:23:16 +1300

On 20/01/2017 10:43, Peter Dordal wrote:
> On 01/19/2017 02:30 PM, Manfredi, Albert E wrote:
> I intend no quarrel with this wording, and I think it is unfortunate 
> this 64 debate has come up again.
> Say whatever needs to be said, and ship it.
> 
> However, the text above states that SLAAC is *the* reason for 64-bit 
> IIDs. 

No, it says it's the reason for needing a *consistent* length of IID, that's
all. As others have pointed out, we wouldn't pick e.g. 8, for other reasons
including the ones you give.

   Brian

> This is only
> partly true: 64-bit IIDs also have security and privacy implications.
> 
> Security, because an attacker can't realistically probe a site that uses 
> randomized
> 64-bit IIDs. A site that uses /120 prefixes, on the other hand, is quite 
> exposed.
> 
> Privacy, because creating temporary IIDs becomes harder and harder as 
> the number
> of bits goes down. In the IPv4 world, privacy is one reason we have NAT.
> 
> Peter Dordal
> Loyola University Chicago CS Dept
> .
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2017 14:30:13 +1300

> We have a pragmatic requirement of 64-bit IIDs, for the existing (minority) of assigned global unicast addresses. But we don't want to reverse the intention for CIDR, stated in RFC 3513. This is th…

Indeed. I've taken out the explicit text that people objected to, but if another /3
is released to IANA and the RIRs, don't we want to keep our options open?

    Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 19 Jan 2017 19:47:28 -0600

I liked the following in the previous version;

   Note that this value is an arbitrary choice and might be changed for
   some future allocation of unicast address space.

What was the issue with it?

Thanks

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2017 15:40:55 +1300

> What was the issue with it?

I've lost track of who said what, but there was a lot of griping
at the word 'arbitrary' and FUD about the 'might be changed.'
Lif is compromise...

    Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 20 Jan 2017 03:23:51 +0000

Hi Randy,

> On Jan 16, 2017, at 5:59 AM, Randy Bush <[email-masked]> wrote:
> 

You know that I respect your opinion, but I think this characterization is inappropriate. Bob has not been involved in the decision making for this document as chair. The text in the document was the result of 6man WG consensus. I am perfectly fine if the WG revisits its consensus as a result of the points that came up during Brian H.’s INT directorate review but rest assured that there is no mountain and no stone tablets. 

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 20 Jan 2017 03:30:13 +0000

Hi Fernando,

On Jan 16, 2017, at 5:09 PM, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:

On 01/16/2017 06:22 PM, Behcet Sarikaya wrote:
On Mon, Jan 16, 2017 at 2:46 PM, Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:
On 01/16/2017 05:42 PM, Behcet Sarikaya wrote:
On Mon, Jan 16, 2017 at 2:27 PM, Alexandre Petrescu
<[email-masked]<mailto:[email-masked]>> wrote:
Le 14/01/2017 à 20:49, Brian E Carpenter a écrit :

A modest suggestion:

OLD

NEW
  IPv6 routing is based on prefixes of any valid length up to 128
[BCP198].
  For example, [RFC6164] standardises 127 bit  prefixes on point-to-point
  links. However, consistent use of Stateless Address Autoconfiguration
  (SLAAC)[RFC4862] requires that all interfaces on a link use the same
length
  of Interface ID. In practice, this means that to guarantee
interoperability
  of SLAAC, a fixed length of Interface ID is necessary. For all
currently
  allocated unicast addresses, except those that start with the binary
  value 000, that length is 64 bits. Note that this value is an arbitrary
  choice and might be changed for some future allocation of unicast
address
  space. Background on the 64 bit boundary in IPv6 addresses can be found
  in [RFC7421].

Kind of agree but not entirely. There are some protocols in the constrained space that depend on some form of relationship between an L2 address and the L3 IPv6 address to achieve compression.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 20 Jan 2017 04:08:17 +0000

Hi Brian,

> However, correct use of Stateless Address Autoconfiguration
>   of Interface ID.

I don’t think this is true. SLAAC only requires that the prefix length and IID length add up to 128. So, we can advertise different prefixes (with different lengths) on a link to support different IID lengths. We never did because both the prefix length and the IID length have been 64 bit long in the most prevalent cases.

Thanks
Suresh

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 Jan 2017 13:38:55 +0900

On Fri, Jan 20, 2017 at 4:41 AM, Brian E Carpenter <
[email-masked]> wrote:

>    a consistent length of Interface ID is desirable. For this reason,

I object to the text "for this reason", because SLAAC is not the only
reason. There are many reasons, many of which are written in 7421, and two
sentences in this paragraph are not sufficient to describe them. I propose
the following alternative, which I believe to be normatively identical:

   IPv6 routing is based on prefixes of any valid length up to 128 [BCP198].
   For example, [RFC6164] standardises 127 bit prefixes on point-to-point
   links. However, the Interface ID of all currently allocated unicast
addresses,
   except those that start with the binary value 000, is required to be 64
bits
   long. The rationale for the 64 bit boundary in IPv6 addresses can be
found in
   [RFC7421].

Cheers,
Lorenzo

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2017 17:42:52 +1300

> I don’t think this is true. SLAAC only requires that the prefix length and IID length add up to 128. So, we can advertise different prefixes (with different lengths) on a link to support different…

Technically, yes, but I doubt if much current code would work that way.
I agree that the sentence needs that addition.

Thanks
    Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 19 Jan 2017 23:25:39 -0600

>    long. The rationale for the 64 bit boundary in IPv6 addresses can be

How should that be interpreted? Do my Point-to-Point links need addresses
that begin with binary 000? How do I get an allocation of those?  Because
it says I must use a 64 bit IID with the Global Unicast Allocation that I
got from ARIN.

Here is another problem, RFC 6164 probably should have updated 4291 for
that reason.  And if there are any future exceptions should update 4291bis,
for similar reasons.

There are lots of good reasons to use 64 bit IIDs almost everywhere, but
there are exceptions.  However this text doesn't leave room for any
exceptions, even the one that it cites.

Again keeping "required" I believe is a false imperative.  If we can't fix
that by going to "should", can we at least make room for official standards
track exceptions, like the one cited and any future ones we agree on?

Thanks

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 Jan 2017 14:55:23 +0900

As Brian says, we can't change the normative effect in the context of
promoting the document to full standard.

As for making room for exceptions: isn't it a given that any standards
track document can update RFC 4291? (Assuming 6man has either reviewed and
gotten consensus on it, or not requested to review it)

On Fri, Jan 20, 2017 at 2:25 PM, David Farmer <[email-masked]> wrote:

>>    except those that start with the binary value 000, is required to be
>> 64 bits

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jan 2017 19:11:16 +1300

On 20/01/2017 17:38, Lorenzo Colitti wrote:
>    links. However, the Interface ID of all currently allocated unicast addresses,
>    except those that start with the binary value 000, is required to be 64 bits
>    long. The rationale for the 64 bit boundary in IPv6 addresses can be found in
>    [RFC7421].

Yes, I'll buy 'however'.

   Brian

---

From: David Farmer <[email-masked]>
Date: Fri, 20 Jan 2017 01:31:15 -0600

I think the reference to RFC6164 need to be included within the exception
to the 64 bit requirement, something like the following;

IPv6 routing is based on prefixes of any length up to 128 [BCP198]. However,
the Interface ID of all currently allocated unicast addresses, except those
that start with the binary value 000 or when use to address point-to-point
link [RFC6164], is required to be 64 bits long. The rationale for the 64
bit
boundary in IPv6 addresses can be found in [RFC7421].

This is still a false imperative, but at least it is consistent with the
intent of RFC6164.

On Thu, Jan 19, 2017 at 11:55 PM, Lorenzo Colitti <[email-masked]>
wrote:

>> Again keeping "required" I believe is a false imperative.  If we can't
>> fix that by going to "should", can we at least make room for official
>> standards track exceptions, like the one cited and any future ones we agree
>> on?
>>
>> Thanks
>>
>> --

---

From: [email-masked]
Date: Thu, 19 Jan 2017 21:48:05 +0100

Brian,

[...]

>   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].

By changing "For all unicast addresses" to "all currently allocated unicast addresses",

Are you proposing to reverse the decision that was made back when RFC3513 updated RFC2373?
Change log:

Best regards,
Ole

---

From: [email-masked]
Date: Fri, 20 Jan 2017 00:52:43 +0100

Dave,

> I'm a little worried that your fighting yesterday's battle.  To be honest, I'm less worried about charing for more than one IP address. I'm much more worried about charging for more than one subnet. In fact, I'm worried a hard and inflexible boundary at /64 reinforces a model for charging for more than one subnet.
> 
> If that happens would you prefer people use NTPv6 or NAT66?  I'd prefer a more flexible subnet boundary, that allows the18 quadrillion addresses in a /64 to be broken into smaller subnets. 

Therein lays the paradox. If the IETF were to standardise arbitrary prefix length > 64 you end up being charged per address. If implementations don't support arbitrary prefix lengths > 64 you end up having to do NAT66, ND proxy...
Which is why all implementations should support arbitrary prefix length, but not tell anyone. ;-)

> 
> Furthermore, we are talking about giving individual devices their own subnets.  I like this model and with today's scale that will be fine.  But, longer-term this has me worried, especially if we keep a inflexible /64 boundary. 

That would require extreme waste in the first 64 bits...
2^64 number of addresses is an awfully big number.

> Ok, are you willing to put that in the document?  The /64 requirement, is a political consideration, not a technical one.  Because other than /64 subnets are clearly technically possible, we have evidence of it in RFC 7421. 

But unless we also kept some technical limitations, would anyone accept the boundary if it was purely policy?
(And at this point there is surely a lot more technical reasons than just SLAAC.)

Best regards,
Ole

---

From: [email-masked]
Date: Thu, 19 Jan 2017 23:07:25 +0100

> We have a pragmatic requirement of 64-bit IIDs, for the existing (minority) of assigned global unicast addresses. But we don't want to reverse the intention for CIDR, stated in RFC 3513. This is th…

I asked the clarification because RFC2373 did use the format prefix, where only 2000::/3 was the Global Unicast prefix.
That was changed to making the whole remaining address global unicast; the worry was that this would make implementations treat different 1/8ths differently (and therefore classful).

I wanted to know if the intention of Brian's suggested text was to reverse that?

Ole

---

From: [email-masked]
Date: Fri, 20 Jan 2017 11:29:09 +0100

Brian,

> is released to IANA and the RIRs, don't we want to keep our options open?

This isn't the right place to change the consensus that has held since 3513.
Making this change would require a much deeper analysis of why the reasons outlined above don't apply anymore.
You are essentially proposing to redefine the meaning of "Global Unicast".

And please note that 4291 already has provisions for this:
Section 2.4:
   Future specifications may redefine one or more sub-ranges of the
   Global Unicast space for other purposes, but unless and until that
   happens, implementations must treat all addresses that do not start
   with any of the above-listed prefixes as Global Unicast addresses.

Cheers,
Ole

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 20 Jan 2017 19:59:32 +0000

> From: ipv6 [mailto:[email-masked]] On Behalf Of [email-masked]

> Therein lays the paradox. If the IETF were to standardise arbitrary prefix
> length > 64 you end up being charged per address. If implementations don't
> support arbitrary prefix lengths > 64 you end up having to do NAT66, ND
> proxy...

Yes, that is the problem. However, the threat of being given just one address is already the case, is it not? Individuals are not being handed out /48 or even /56. So I don't see a /64 mandate solving anything, in this one respect. It just pushes people to use the same work-arounds as had to be invented for IPv4. 

> 2^64 number of addresses is an awfully big number.

I keep seeing this stated, but I don't think this is necessarily true. This type of assumption can change drastically, depending how Internet appliances evolve over time. With IPv4, no one predicted that every single hand-help gadget might require its own IP address. And this time around, with developments such as the so-called IoT, there's likely to be zillions of devices that will require their own prefix, and will support multiple internal subnets.

I think that Brian's NEW NEW test is what should be used, because it does NOT imply that all global unicast addresses, minus one subset 000, must use /64 addresses for all time.

And too, the main reason for the specific 64 bit length mentioned, for currently assigned global unicast IIDs, *is indeed* SLAAC. There is no good reason to hide this reality.

RFC 7421:

   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.

I do agree with the one objection, that on any given link, the prefix length only needs to be consistent for that subnet. For instance, a globally unique /80 should be able to coexist with ULAs, or link locals, or other examples of /64s. I do not think we should go back to text that implies /64 is for all unicast addresses, for all time.

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Jan 2017 11:40:11 +1300

> This isn't the right place to change the consensus that has held since 3513.

I agree with that, and it isn't my intention.

> You are essentially proposing to redefine the meaning of "Global Unicast".

Well, I don't agree. I was just trying to confirm that the current rule applies
to the whole of 2000::/3, without closing off future options.

Actually it might have been better if this magic number had been left out
of the addressing architecture and included in the SLAAC specification, but
it's years too late to change that.

>    with any of the above-listed prefixes as Global Unicast addresses.

Right. So 4000::1234 is clearly a unicast address, but if not used for
SLAAC, it doesn't need a defined IID length. That's where we have muddled
things a bit between the addressing architecture and the SLAAC spec.

    Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 20 Jan 2017 15:53:00 -0800

Brian,

> On Jan 19, 2017, at 10:11 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Yes, I'll buy 'however’.

I am generally OK with the text above, but wanted to point out that Section 2.4. "Unicast Addresses” there is more than one place where 64 IIDs are mentioned.  This discusion has been about the forth paragraph in 2.4.1. "Interface Identifiers”.  It is also mentioned in the second paragraph of 2.4.4. "Global Unicast Addresses”.  I assume this would have to be modified if the w.g. decides to adopt this text.

As Ole pointed out there is text that discusses future changes:

2.3.  Address Type Identification

2.4.  Unicast Addresses
   There are several types of unicast addresses in IPv6, in particular,
   Global Unicast, Local unicast, 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.

I think that this makes it clear that things are allowed to change in the future.  I don’t think we have to capture this in the single paragraph in 2.4.1, and there could be other kind of changes as well.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Jan 2017 15:16:20 +1300

Bob,

Yes, I take your point. Maybe we can all close this thread now and you
can decide what to put in the next draft.

Regards
   Brian

---

From: [email-masked]
Date: Sat, 21 Jan 2017 15:25:21 +0100

Brian, et al,

> I agree with that, and it isn't my intention.

Ah, excellent that wasn't clear to me.

> it's years too late to change that.

 - There is no magic number in 4291 (The format prefix was removed in 2373 -> 3513.)
 - The global unicast address space is defined as everything else than (000, etc)
 - The 64-bit boundary applies to _all_ of the global unicast address space
 - SLAAC is _not_ restricted to only 2000::/3
 - IANA only assigns addresses out of 2000::/3

There was an explicit change to avoid implementations building in knowledge about global unicast format prefixes.
That means that today, all of the global unicast address space (the 7/8ths) has the 64-bit boundary and of course can be used by SLAAC.

If we got the addressing model (and the 64-bit boundary) wrong:
- the safety valve is that addresses are only currently assigned from 2000::/3.
- a new document replacing 4291 would be required
- implementations would have to be updated and a new format prefix would be used

Can the 64-bit boundary be changed within 2000::/3?
Possibly, but someone would have to write a draft on that.
This isn't a change that can be snuck in between working group last call and IETF last call.

> things a bit between the addressing architecture and the SLAAC spec.

As currently specified, if the IETF's action was only to make  e.g. 4000::/3 available for the IANA for assignment, it would be address space behaving exactly like 2000::/3.

Ole

---

From: [email-masked]
Date: Sat, 21 Jan 2017 15:29:30 +0100

> can decide what to put in the next draft.

A point of order. The document is now in AD Evaluation state.
(https://datatracker.ietf.org/help/state/draft/iesg)

Ole

---

From: Tore Anderson <[email-masked]>
Date: Mon, 23 Jan 2017 12:49:54 +0100

* Lorenzo Colitti <[email-masked]>

> As explained before, there is no conflict between RFC 4291 and RFC
> 7608. RFC 7608 applies to forwarding, RFC 4291 applies to link
> addressing. I don't see a conflict between RFC 5942 and RFC 4291. Can

Isn't there a conflict with RFC 6052, though?

E.g., if you're using an RFC 6052 NSP such as 2001:db8:6052::/96, the
IPv4-translatable representation of an IPv4 subnet such as 192.0.2.0/24
would be 2001:db8:6052::192.0.2.0/120 (2001:db8:6052::c000:200/120) and
nodes in this subnet/link would necessarily have 8 bit long IIDs. Right?

Tore

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 Jan 2017 22:37:27 +0900

> nodes in this subnet/link would necessarily have 8 bit long IIDs. Right?

I'm not sure it makes sense to draw that conclusion.

If you follow that reasoning, /96 might make sense, but all the other RFC
6052 prefix lengths don't really make sense. For example, if the NSP is 64
bits, how long would the IID be? If you say 8 bits, then that means there
are 2^40 addresses routed to the same host, which means that the prefix
length (88) plus the IID length (8) does not add up to 128. And if you say
48 bits, then that means that a host has 2^40 interface IDs for the same
interface, so the interface ID isn't really an ID any more.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 23 Jan 2017 15:07:43 +0100

* Lorenzo Colitti

> > E.g., if you're using an RFC 6052 NSP such as 2001:db8:6052::/96,
> > the IPv4-translatable representation of an IPv4 subnet such as
> > 192.0.2.0/24 would be 2001:db8:6052::192.0.2.0/120
> > (2001:db8:6052::c000:200/120) and nodes in this subnet/link would
> > necessarily have 8 bit long IIDs. Right?
> 
> If you follow that reasoning, /96 might make sense, but all the other
> RFC 6052 prefix lengths don't really make sense. For example, if the
> NSP is 64 bits, how long would the IID be? If you say 8 bits, then
> that means there are 2^40 addresses routed to the same host, which
> means that the prefix length (88) plus the IID length (8) does not
> add up to 128. And if you say 48 bits, then that means that a host
> has 2^40 interface IDs for the same interface

So with an NSP of 2001:db8:6052::/64, the IPv4 link subnet of
192.0.2.0/24 would be as I understand it be represented as
2001:db8:6052:0:c0:2::/96.

In the «vanilla» RFC7915 operational mode, the default gateway on that
link (a.k.a. 192.0.2.1 from the IPv4 point of view) would be configured
with 2001:db8:6052:0:c0:2:100:0/96, the node reachable at 192.0.2.10
would have 2001:db8:6052:0:c0:2:a00:0/96, 192.0.2.254 would be
2001:db8:6052:0:c0:2:fe00:0/96, and so on.

The IPv6 addresses you actually need to configure on the routers and
the nodes on this link will have an IPv6 prefix length of /96, so
wouldn't that mean that the IIDs in question are 32 bits long?

> the interface ID isn't really an ID any more.

I suppose you can look at it that way too...but wouldn't that then mean
that you're essentially saying that you can have whatever amount of
suffix/node/host bits in an IPv6 address you'd like, but you're only
allowed to call it an «IID» if it just so happens to be exactly 64 of
them? :-)

Tore

---

From: [email-masked]
Date: Mon, 23 Jan 2017 16:36:09 +0100 (CET)

> allowed to call it an «IID» if it just so happens to be exactly 64 of

Isn't that how IPv6 is sometimes used in the real world? E.g. transit
providers who insist on a non-64 bit mask on the transit links.

Anybody who believes that only /64 (and /127) is in use on interfaces
in the real world is seriously deluded.

Steinar Haug, AS2116

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jan 2017 08:33:37 +1300

> in the real world is seriously deluded.

Indeed. But I think the point has been hammered home and I expect that
the draft will be wordsmithed accordingly before we see a new version.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Mon, 23 Jan 2017 14:41:04 -0800

Brian,

I will work on some new text, but won’t submit anything till after I get a go ahead from Suresh.  Like the other changes from Brian Haberman’s review.

Bob

> On Jan 20, 2017, at 6:16 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Bob,
>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 24 Jan 2017 13:30:34 +0000

Hi Bob,

> On Jan 23, 2017, at 5:41 PM, Bob Hinden <[email-masked]> wrote:
> 
> Brian,
> 

Sounds good. Please go ahead and work on the new text and post it to the list when you are ready. 

Thanks
Suresh