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