Subject: Comment on draft-carpenter-6man-why64

From: Philip Matthews <[email-masked]>
Date: Thu, 6 Mar 2014 12:02:36 +0000

Brian:

Just to restate what I said at the mic.

I suggest that this document might be retitled to just "Why /64?" (nice catchy title) and the main thrust of the document changed be explaining why we feel that the /64 decision was the right one.  That is:
1) The advantages one gets from having a 64-bit IID, and
2) Why having a 64-bit IID does not lead to the end of life as we know it.

In my experience, this is often the single hardest thing for people to understand about IPv6. When first exposed to this, many people say "What a huge waste of address space!!!".

When I address the latter issue ("the huge waste of addresses"), I often note:
* We are currently allocating GUAs out of the 2000::/4 and 3000::/4 space, which is only 1/8th of the entire space. In fact, IANA has not yet touched the 3000::/4 space and could likely satisfy all the initial IPv6 allocations from just 2000::/4.
* Thus it seems likely to me that 2000::/4 and 3000::/4 will be sufficient for at least the next 20 years.  (Perhaps it would be good to do some more detailed modeling to confirm this).
* IPv6 will NOT last forever. It is unrealistic to think that we can design a protocol that will last forever. But I think that IPv6 will likely last 100 years, which is a lot better than the 30-odd years that IPv4 lasted.

- Philip

---

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

Hi Philip,

I personally am very happy to make the tone more positive.
As I mentioned in the meeting, we tried to start out in a
more neutral way.

I do know, though, that we will get some pushback. I was told
by several IPAM vendors that they've had to add support for
longer prefixes to meet customer RFPs. Clearly those are customers
who intend to avoid SLAAC.

Regards
   Brian

---

From: Philip Matthews <[email-masked]>
Date: Thu, 6 Mar 2014 13:35:51 +0000

Hi Brian:

I am aware that a number of people are chopping up a /64 into smaller subnets to use on point-to-point links.
I am hoping that this document might help educate people.

I cannot remember if you already discuss this, but I feel you should discuss the fairly common practice of:
    Allocate a /64, but configure as a /127 or /126.
so as to avoid ND attacks. 

- Philip

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Mar 2014 02:46:36 +1300

> so as to avoid ND attacks.

We mention RFC6164, but maybe we should say a bit more. However,
isn't that motivated by avoiding ping-pongs? People talk about
using /120 to mitigate the ND attack. We do discuss that.

   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 6 Mar 2014 15:37:06 -0800 (PST)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Philip Matthews <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Sent: Thursday, 6 March 2014 11:59 PM
> Subject: Re: Comment on draft-carpenter-6man-why64
> 
> Hi Philip,
> 

I'm not even sure most or all of those customers would know even what SLAAC is. That sounds to me a bit like those customers have asked for it from their IPAM vendors, just because they do variable length subnetting over the whole IPv4 address, and assume that they'll need or want to do it in IPv6. I wouldn't be surprised if these customers haven't run IPv6 at all yet, let alone tested if their SLAAC and/or DHCPv6 implementations support > /64 prefix lengths.

Regards,
Mark.

>>  I suggest that this document might be retitled to just "Why /64?" 
> (nice catchy title) and the main thrust of the document changed be explaining 
> why we feel that the /64 decision was the right one.  That is:
>>  In my experience, this is often the single hardest thing for people to 
> understand about IPv6. When first exposed to this, many people say "What a 
> huge waste of address space!!!".
>> 
>>  * We are currently allocating GUAs out of the 2000::/4 and 3000::/4 space, 
> which is only 1/8th of the entire space. In fact, IANA has not yet touched the 
> 3000::/4 space and could likely satisfy all the initial IPv6 allocations from 
> just 2000::/4.
>>  * Thus it seems likely to me that 2000::/4 and 3000::/4 will be sufficient 
> for at least the next 20 years.  (Perhaps it would be good to do some more 
> detailed modeling to confirm this).
>>  * IPv6 will NOT last forever. It is unrealistic to think that we can design 
> a protocol that will last forever. But I think that IPv6 will likely last 100 
> years, which is a lot better than the 30-odd years that IPv4 lasted.
>> 
>>  - Philip
>> 
>> 
>> 
>> 
>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 6 Mar 2014 16:17:23 -0800 (PST)

----- Original Message -----
> Sent: Friday, 7 March 2014 12:46 AM

Actually, I don't think /127s completely avoid ping-pongs. 

A /127 on a local interface asserts that the other address within the /127 is configured on the other end of the link, but does not test for it, and therefore cannot be assured of it. Only probing the remote address presence using neighbor discovery, or observing if unsolicited traffic comes from that remote /127 address can do that. There seems to be a belief that for point to point links where layer 3 to layer 2 address resolution isn't necessary (e.g., PPP, or SONET as mentioned in RFC6164), neighbor discovery isn't necessary because a /127 prefix length makes up for it.
 
If a link between a two routers has a /127 configured on one end, but not the other, and the other end router has a summary route covering the /127 prefix (such as a default route), sending traffic towards the non-existent /127 address will cause that traffic to ping-poing back and forth between the two routers. So a /127 by itself does not prevent a ping-pong attack - something else has to be in place or be done to ensure that both addresses within the /127 are present.

(I think neighbor presence discovery might be a better name than address resolution for the initial ND neighbor solicitiation, because it is doing more than just resolving a layer 3 address into a layer 2 address, and that means even for links that don't have layer 2 addresses, neighbor presence discovery still needs to take place.)

Regards,
Mark.

>>>>  I suggest that this document might be retitled to just "Why 
> /64?" (nice catchy title) and the main thrust of the document changed be 
> explaining why we feel that the /64 decision was the right one.  That is:
>>>>  In my experience, this is often the single hardest thing for people 
> to understand about IPv6. When first exposed to this, many people say "What 
> a huge waste of address space!!!".
>>>> 
>>>>  * We are currently allocating GUAs out of the 2000::/4 and 3000::/4 
> space, which is only 1/8th of the entire space. In fact, IANA has not yet 
> touched the 3000::/4 space and could likely satisfy all the initial IPv6 
> allocations from just 2000::/4.
>>>>  * Thus it seems likely to me that 2000::/4 and 3000::/4 will be 
> sufficient for at least the next 20 years.  (Perhaps it would be good to do some 
> more detailed modeling to confirm this).
>>>>  * IPv6 will NOT last forever. It is unrealistic to think that we 
> can design a protocol that will last forever. But I think that IPv6 will likely 
> last 100 years, which is a lot better than the 30-odd years that IPv4 lasted.
>>>> 
>>>>  - Philip
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Mar 2014 09:36:13 +0000

On Fri, Mar 7, 2014 at 12:17 AM, Mark ZZZ Smith
<[email-masked]>wrote:

> If a link between a two routers has a /127 configured on one end, but not
> the other, and the other end router has a summary route covering the /127
> prefix
>

Ok, but that's a configuration error, right?

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 8 Mar 2014 01:11:26 -0800 (PST)

>________________________________
> From: Lorenzo Colitti <[email-masked]>
>To: Mark ZZZ Smith <[email-masked]> 
>Cc: Brian E Carpenter <[email-masked]>; Philip Matthews <[email-masked]>; 6man WG <[email-masked]> 
>Sent: Friday, 7 March 2014 8:36 PM
>On Fri, Mar 7, 2014 at 12:17 AM, Mark ZZZ Smith <[email-masked]> wrote:
>
>If a link between a two routers has a /127 configured on one end, but not the other, and the other end router has a summary route covering the /127 prefix
>
>

Debatably. It isn't a requirement that all interfaces attached to a link are configured with addresses from all of the prefixes present on a link. IPv6's ability to issue ICMPv6 redirects "across on-link prefixes" in particular supports that scenario efficiently.

I could imagine a scenario where one of the routers is an ISPs, and the other router is a customers. The ISP assigns a global /127 prefix to the link, and asks the customer to configure other /127 address on their end. However, as the customer and ISP may use link-local addresses as the next hop for prefixes behind the respective routers (perhaps because the routing protocol they're using uses LLs), then there isn't an essential need for the customer to configure their /127 address, and therefore they may forget to.

A local IPv6 address's prefix length does not assure any existence of any of the other remote addresses in the prefix existing on the link, including when the prefix length would only allow one other address. This has also been true of IPv4. I think the only way to be sure of the existence of a remote address is to hear something from it.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Wed, 19 Mar 2014 16:19:27 -0500

> I suggest that this document might be retitled to just "Why /64?" (nice catchy title) and the main thrust of the document changed be explaining why we feel that the /64 decision was the right one.…

I'll note there is little real "why" in the draft so far.  What there 
mostly is the specs, which boils down to "because we told you so".  We 
need as much reasoning as to "why /64" was selected, as we have the fact 
that /64 is what was selected.

- Maybe start with the advantages of selecting a single IID size,
   compared disadvantages of having multiple IID sizes.

  -- I think this is the crux of the argument.

  -- There is no doubt in my mind that multiple IID sizes, especially
     for Link Local and Autoconfig would be far more difficult and
     complicated.

  -- Maybe, discuss the complexity involved in allowing for multiple
     IID sizes for Link Local and Autoconfig.  The point is to discuss
     the fact that cure is worse than the disease.

- They Why /64 was selected over other potential options

  -- Some of this is in the draft, the need of relatively long IIDs to
     allow for security and privacy.

  -- Allows for OID-64 to be used, when appropriate.

  -- /64 subnet size allows for plenty of networks overall.

I'll additionally note that, the issue some routers have problems with 
/65 to /126 prefix sizes is important, but since it is an optimization 
based on the fact that /64 was chosen, it is more a consequence of 
selecting /64 than a real reason as to why /64.  Conversely, one IID 
size allow this optimization, and that is a good thing.

> 1) The advantages one gets from having a 64-bit IID, and

There are some advantages specific to 64, but I think the primary 
advantages actually bind to "having one IID size" rather then the 
specific 64 bit IID size.

> 2) Why having a 64-bit IID does not lead to the end of life as we know it.

Yes, there are plenty of networks with the 64 bit IID Size, we are not 
going to run out.  But, most people don't grasp the size of IPv6 anyway.

> In my experience, this is often the single hardest thing for people to understand about IPv6. When first exposed to this, many people say "What a huge waste of address space!!!".

Its hard to drop IPv4 thinking.

> * IPv6 will NOT last forever. It is unrealistic to think that we can design a protocol that will last forever. But I think that IPv6 will likely last 100 years, which is a lot better than the 30-od…

So /64 is the standard, BUT;

I'd like the draft to recognize that while technically non-standard from 
the perspective of [RFC4291, section 2.5.1], most hosts and routers 
allow manual configuration of IPv6 subnet prefixes longer than /64. 
Furthermore, [RFC4681 section 4.6.2] clearly defines prefix lengths as 0 
- 128, only noting that for autoconfiguration "there may be more 
restrictions on the prefix length."  And [RFC5942] seems even more 
specific about allowing prefixes longer than /64 as on-link.

So, what is happening in this situation?  A Link Local address with a 64 
bit IID is being used for ND and other Link Local communications, but 
all hosts have a manually configured Global Unicast IPv6 address and 
there is router with manually configured prefix information specifying a 
prefix longer that /64 seemingly in contravention of [RFC4291, section 
2.5.1], but allowed by [RFC4681 section 4.6.2] and [RFC5942]. 
Therefore, at least for manual configuration prefixes longer than /64 
are allowed, even if they are technically non-standard, and there are 
possible incompatibilities.

Does anyone dispute that manual configuration of longer than /64 
prefixes are and should be permitted, but are generally not recommended?

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

---

From: David Farmer <[email-masked]>
Date: Wed, 19 Mar 2014 18:43:36 -0500

On 3/19/14, 16:19 , David Farmer wrote:
>> (nice catchy title) and the main thrust of the document changed be
>> understand about IPv6. When first exposed to this, many people say
>> "What a huge waste of address space!!!".
>
>> space, which is only 1/8th of the entire space. In fact, IANA has not
>> yet touched the 3000::/4 space and could likely satisfy all the
>> initial IPv6 allocations from just 2000::/4.
>> sufficient for at least the next 20 years.  (Perhaps it would be good
>> to do some more detailed modeling to confirm this).
>> * IPv6 will NOT last forever. It is unrealistic to think that we can
>> design a protocol that will last forever. But I think that IPv6 will
>> likely last 100 years, which is a lot better than the 30-odd years
>> that IPv4 lasted.
>
> 2.5.1], but allowed by [RFC4681 section 4.6.2] and [RFC5942]. Therefore,
> at least for manual configuration prefixes longer than /64 are allowed,
> even if they are technically non-standard, and there are possible
> incompatibilities.
>

Also, it's not obvious to me why DHCPv6 can't do longer than /64 
prefixes either.  The on-link prefix and default router come from ND, 
just like manual configuration above and the DHCPv6 server sends a 128 
IPv6 address for the IA_NA or the IA_TA.  As long as the DHCPv6 server 
and the router agree on the on-link prefix length, then it should work.

Also, I have to say that RFC5375 takes a fairly agnostic view of other 
than /64 prefixes.

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Mar 2014 18:09:38 -0700

> that /64 is what was selected.

do we really care why some strange function is classful.  it is welcome
to be, no problem.  the problem arises when folk think that is the norm.
it isn't.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Mar 2014 18:10:43 -0700

> prefixes either.

because the ipv6 gods hate dhcp.  all right thinking people will abjure
dhcp and use the proper ipv6 pixie dust.

randy

---

From: George Michaelson <[email-masked]>
Date: Thu, 20 Mar 2014 11:14:12 +1000

> to be, no problem.  the problem arises when folk think that is the norm.
Strangely enough, this is also where I find myself. I'm not expecting any
vendor to change ASICS or code, but I think attempting to rei-ify the 8+8
model across the entire footprint of address is .. frankly bizarre.

yes, a bunch of process docs say it. yes, some specific usages say it. But,
we're in 1/512th of the footprint, and I doubt very much the future wants
us to set this in stone.

"this is the pointer to prior RFC/STD which say /64" no problem. Good to
have a concordance.

"this is why its /64 forever amen" problem

-G

---

From: David Farmer <[email-masked]>
Date: Wed, 19 Mar 2014 20:50:30 -0500

> to be, no problem.  the problem arises when folk think that is the norm.

Let me restate what I think you are saying; IPv6 is intended to be VLSM 
with a variable IID length, as stated in [RFC4921 section 2.5], and that 
the architecturally significant part of the specification.  The 
specification of a 64 bit classful IID [RFC4921 section 2.5.1] is mostly 
just a temporary convince.

Or did I misinterpret you?

Thanks

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Mar 2014 19:36:03 -0700

> Let me restate what I think you are saying;

don't

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 19 Mar 2014 19:55:23 -0700 (PDT)

----- Original Message -----
> From: David Farmer <[email-masked]>
> To: Philip Matthews <[email-masked]>; Brian E Carpenter <[email-masked]>
> Sent: Thursday, 20 March 2014 8:19 AM

I think a lot of the reasons for having single values/sizes and no options are discussed in RFC5505, "Principles of Internet Host Configuration". 

In particular, "Anything that can be configured can be misconfigured."

So I think this ID should reference RFC5505, and perhaps suppliment its commentary with anything specific to the choice of 64 bit IIDs.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2014 20:45:31 +1300

> "this is why its /64 forever amen" problem

The draft is intended to be neutral. We were asked to make it
more positive in tone, and David has reasonably asked for it to
be more explicit about the "why" aspect, but it will not end in
"for ever and ever, amen".

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2014 20:50:30 +1300

>> Also, it's not obvious to me why DHCPv6 can't do longer than /64 

As far as I know, it can.

> dhcp and use the proper ipv6 pixie dust.

RA/SLAAC isn't pixie dust. Neither is DHCPv6. But could we have
that argument on a thread for the relevant drafts?

Speaking as document editor trying to figure out what to edit next...

   Brian

---

From: Brian Jones <[email-masked]>
Date: Wed, 19 Mar 2014 20:18:08 -0400

On Mar 19, 2014 5:19 PM, "David Farmer" <[email-masked]> wrote:
>> I suggest that this document might be retitled to just "Why /64?" (nice
catchy title) and the main thrust of the document changed be explaining why
> I'll note there is little real "why" in the draft so far.  What there
mostly is the specs, which boils down to "because we told you so".  We need
as much reasoning as to "why /64" was selected, as we have the fact that
/64 is what was selected.
/65 to /126 prefix sizes is important, but since it is an optimization
based on the fact that /64 was chosen, it is more a consequence of
selecting /64 than a real reason as to why /64.  Conversely, one IID size
allow this optimization, and that is a good thing.
> There are some advantages specific to 64, but I think the primary
advantages actually bind to "having one IID size" rather then the specific
64 bit IID size.
>> * Thus it seems likely to me that 2000::/4 and 3000::/4 will be
sufficient for at least the next 20 years.  (Perhaps it would be good to do
some more detailed modeling to confirm this).
>> * IPv6 will NOT last forever. It is unrealistic to think that we can
design a protocol that will last forever. But I think that IPv6 will likely
last 100 years, which is a lot better than the 30-odd years that IPv4
lasted.
> I'd like the draft to recognize that while technically non-standard from
the perspective of [RFC4291, section 2.5.1], most hosts and routers allow
manual configuration of IPv6 subnet prefixes longer than /64. Furthermore,
[RFC4681 section 4.6.2] clearly defines prefix lengths as 0 - 128, only
noting that for autoconfiguration "there may be more restrictions on the
prefix length."  And [RFC5942] seems even more specific about allowing
prefixes longer than /64 as on-link.
> So, what is happening in this situation?  A Link Local address with a 64
bit IID is being used for ND and other Link Local communications, but all
hosts have a manually configured Global Unicast IPv6 address and there is
router with manually configured prefix information specifying a prefix
longer that /64 seemingly in contravention of [RFC4291, section 2.5.1], but
allowed by [RFC4681 section 4.6.2] and [RFC5942]. Therefore, at least for
manual configuration prefixes longer than /64 are allowed, even if they are
technically non-standard, and there are possible incompatibilities.
>
> Does anyone dispute that manual configuration of longer than /64 prefixes
are and should be permitted, but are generally not recommended?

I agree; Prefixes > /64 should be allowed. It doesn't have to be
recommended but also shouldn't be restricted.

-bej

---

From: Ray Hunter <[email-masked]>
Date: Thu, 20 Mar 2014 17:43:43 +0100

> Speaking as document editor trying to figure out what to edit next...
I think a check of standards being "prefix length !=64 proof" is a 
start. If something like a /64 boundary is partially pervasive, but not 
fully pervasive, it's going to be difficult to track down what breaks 
and what won't.

We seem to have two models: a number of RFC's based on /64 is the only 
way to go, and RFC's based on a variable length prefix "m + n" model.

I think it's useful to see which standard adopts which model, so 
developers can predict which code will break when.

Obviously code written to comply with standards based on /64 as being 
the only model will likely break horribly when this assumption no longer 
holds true.

So as a start:

RFC2464 "IPv6 Packets over Ethernet" defines a fixed /64 boundary in 
Section 4. But that text has anyway been made redundant over time, 
although 2464 itself has never been formally updated AFAICS.
A standards track draft that deprecates the text in Section 4 in it's 
entirety would do no harm IMHO, and would clean up the bundle of 
standards. As far as I can see RFC2464 would NOT break if prefix length 
!= 64.

RFC 6085 makes no assumptions about prefix length == 64 and would not 
break if prefix length != 64

On balance, the IPv6 over FOO documents is probably the correct place to 
define the prefix length of "link-local" addresses, whatever length it 
finally is.

RFC 4291 has extensive references to a fixed /64 boundary, but is not 
exactly self-consistent (section 2.5 states "IPv6 unicast addresses are 
aggregatable with prefixes of arbitrary bit-length, similar to IPv4 
addresses under Classless Inter-Domain Routing", but states that all 
unicast addresses except those staring with 000 have a fixed prefix 
length of 64 bits.)

Some say 7/8 of the address space is free for future use, as IANA may 
only allocate 2000::/3, whilst others say less than 1/8 of the address 
space is still free because of the clause about the binary 000 => /64.

I think it's fair to conclude that 4291 requires clarification.

RFC7136 Significance of IPv6 Interface Identifiers re-iterates the 
binary 000 prefix => /64 for unicast addresses. But it does not itself 
introduce any new breakages if the 000 prefix issue was clarified 
further. I reviewed this document, but with the benefit of hindsight, 
this ID should not have said anything about prefix length as it was 
dealing with the u/g issue and IID's, not the prefix portion of the 
address space.

RFC4861 Neighbor Discovery for IP version 6 (IPv6) makes no assumptions 
about prefix length == 64 and would not break if prefix length != 64.

RFC4862 IPv6 Stateless Address Autoconfiguration makes no assumptions 
about prefix length == 64 and would not break if prefix length != 64.

RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) makes no 
assumptions about prefix length == 64 and would not break if prefix 
length != 64.

draft-ietf-6man-stable-privacy-addresses-17 makes no assumptions about 
prefix length == 64 and would not break if prefix length != 64.

...... help me fill in the rest ......

My personal view would be that it would be incredibly useful for 
developers if there was a hierarchy of standards you could follow to see 
what standard inherited what parameter, and hopefully just one place to 
tweak prefix length.
If think it would useful advice to developers to NOT assume a fixed 
prefix length when writing IPv6 code, and to implement and m+n model 
wherever possible.

-- 
Regards,
RayH

---

From: Philip Matthews <[email-masked]>
Date: Thu, 20 Mar 2014 21:24:10 -0400

On 2014-03-19, at 20:18 , Brian Jones wrote:
> >
> > Does anyone dispute that manual configuration of longer than /64 prefixes are and should be permitted, but are generally not recommended?
> >
> 
> I agree; Prefixes > /64 should be allowed. It doesn't have to be recommended but also shouldn't be restricted.
> 
For what it is worth, I also agree.
My personal opinion is: Implementations should do VLSM, but BCP is /64, and the draft should argue why /64 is BCP.  

But I think it is also useful for the draft to have a section listing the counter-arguments. This allows readers to view both sides of the debate.

- Philip

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Mar 2014 10:00:19 -0700

On 3/20/14 9:43 AM, Ray Hunter wrote:
> start. If something like a /64 boundary is partially pervasive, but 
> not fully pervasive, it's going to be difficult to track down what 
> breaks and what won't.
>
> the only model will likely break horribly when this assumption no 
> longer holds true.
I think this is out of scope for the why /64 document, but I appreciate 
the effort to determine where there are hard /64 boundaries (as opposed 
to a /64 boundary derived from the ease and benefit of an address 
allocation scheme and address autoconfiguration schemes leveraging 64 bits.)

> although 2464 itself has never been formally updated AFAICS.
RFC2464 specifies how to form a 64 bit IID (which is useful) and then says
    An IPv6 address prefix used for stateless autoconfiguration [ACONF]
    of an Ethernet interface must have a length of 64 bits.
which is correct given that the defined IID is exactly 64 bits (and n+m 
must be 128 per RFC 4862 etc).

However, RFC2464 doesn't forbid manual configuration of e.g. 
2002:x:y:z:a:b::1/120 as far as I can see from the document.

> standards. As far as I can see RFC2464 would NOT break if prefix 
> length != 64.
>
> On balance, the IPv6 over FOO documents is probably the correct place 
> to define the prefix length of "link-local" addresses, whatever length 
> it finally is.
I'm less sure about where and how to handle the link-local prefix length.
It would make sense to first check what current code does with addresses 
of the form fe80:1::/64 - whether they can be assigned to interfaces, 
how packets are forwarded with such addresses.
I'm guessing that based on such that we'd end up reserving fe80::/10 
while saying that the behavior for addresses outside of fe80::/64 is 
undefined.
> exactly self-consistent (section 2.5 states "IPv6 unicast addresses 
> are aggregatable with prefixes of arbitrary bit-length, similar to 
> IPv4 addresses under Classless Inter-Domain Routing", but states that 
> all unicast addresses except those staring with 000 have a fixed 
> prefix length of 64 bits.)
Part of that might be due to a specifying an element of the routing 
architecture/approach (as CIDR) and then specifying an approach for 
allocating addresses (which enable SLAAC) by picking /64. Those 
statements are not inherently in conflict, but as we can see from these 
emails things could be more clear.
> I think it's fair to conclude that 4291 requires clarification.
 From the email exchanges it isn't obvious to me what clarifications 
would be required.
Some folks seem to argue for a stronger statement about /64 while others 
want the option to manually assign prefixes and IIDs which do not follow 
the /64 boundary.
Unless/until we have rough consensus on the direction of the 
clarifications it is too early to say which document needs to be clarified.

Regards,
    Erik

> RFC4861 Neighbor Discovery for IP version 6 (IPv6) makes no 
> developers if there was a hierarchy of standards you could follow to 
> see what standard inherited what parameter, and hopefully just one 
> place to tweak prefix length.

---

From: Glen Turner <[email-masked]>
Date: Sun, 23 Mar 2014 22:54:09 +1030

> My personal opinion is: Implementations should do VLSM, but BCP is /64, and the draft should argue why /64 is BCP.  

This is also my view, as it allows for an evolving best common practice and prevents hardware vendors assuming /64 in the forwarding plane.

For example /124 is operationally attractive for statically-addressed router-router links. The textual representation is sane. But more importantly using something much smaller than a /64 allows all of an ISPs point-to-point infrastructure links to be covered in one statement in an access control list. *NIC aren't going to allocate further addressing if you have a massively under-utilised address space because a lot of space is reserved by the bits you are using to identify infrastructure so using /64 for router-router links leads to a mess of ACL entries because each *NIC allocation has an infrastructure range.

-glen