Subject: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 4 Aug 2014 21:00:28 -0700

Hi,

I was asked to do a detailed review of the 'why64' draft. Here are my thoughts and comments. Sorry for the delay, I've been a bit ill over the last day or so.

General
~~~~~~

I think it covers the topic well, and answers the fundamental questions of why IIDs are 64 bits and why their 64 bit size should be preserved. I could not think of any areas of related discussion that were missed.

Suggested Changes
~~~~~~~~~~~~~~~~

My suggested changes are limited to what I think might be some better wordings or grammar (sometimes trivial), additional references and some reordering of sections of text.

Below is in draft top-to-bottom order.

1.  Introduction

- additional comma

"IPv6 addresses were originally chosen to be 128 bits long to provide
   flexibility and new possibilities, rather than simply relieving the
   IPv4 address shortage*,* by doubling the address size to 64 bits."

- change 'done' to 'completed' (or 'complete' - both sound right, so I'm not sure which is better)

"The notion of a /64 boundary in the address was introduced after the
   initial design of IPv6 was done, following a period when it was
   expected to be at /80."

to

"The notion of a /64 boundary in the address was introduced after the
   initial design of IPv6 was *completed*, following a period when it was
   expected to be at /80."

- additional commas

"The addressing architecture*,* as modified by [RFC7136]*,*
   states that "For all unicast addresses, except those that start with
   the binary value 000, Interface IDs are required to be 64 bits long."

2.  Advantages of a fixed identifier length

- change 'wide-area' to 'aggregate'

"An immediate effect of fixing the IID length at 64
   bits is, of course, that it fixes the subnet prefix length also at 64
   bits, regardless of the wide-area prefix assigned to the site
   concerned, ..."

to

"An immediate effect of fixing the IID length at 64
   bits is, of course, that it fixes the subnet prefix length also at 64
   bits, regardless of the *aggregate* prefix assigned to the site
   concerned, ..."

- add 'simpler and'

"Network design is therefore much
      more straightforward."

to 

"Network design is therefore much *simpler and*
      more straightforward."

- change 'the next /64' to 'another /64 from the pool'

"Adding a subnet is easy - just take the next /64."

to

"Adding a subnet is easy - just take *another /64 from the pool*."

3.  Arguments for shorter identifier lengths

- roughly express the magnitude of space not used to make it clearer there is both plenty available for /56s & /48s and also plenty left for other schemes

"With only
   2000::/3 currently committed for unicast addressing, we still have
   most of the address space in reserve."

to

"With only
   2000::/3 currently committed for unicast addressing, we still have *close to 7/8ths* 
   of the address space in reserve."

3.4.  Concerns over ND cache exhaustion

- add ref to RFC3756, "IPv6 Neighbor Discovery (ND) Trust Models and Threats"
- split long sentence

"A site may be concerned that it is open to neighbour discovery (ND)
   cache exhaustion attacks, whereby an attacker sends a large number of
   messages in rapid succession to a series of (most likely inactive)
   host addresses within a specific subnet, in an attempt to fill a
   router's ND cache with ND requests pending completion, in so doing
   denying correct operation to active devices on the network."

to

"A site may be concerned that it is open to neighbour discovery (ND)
   cache exhaustion attacks [RFC3756], whereby an attacker sends a large number of
   messages in rapid succession to a series of (most likely inactive)
   host addresses within a specific subnet*. This is an* attempt to fill a
   router's ND cache with ND requests pending completion, in so doing
   denying correct operation to active devices on the network."

- remove or better place the 'hosts likely use DHCPv6' text is it seems out of context by itself, or isn't really relevant

"Hosts would likely use DHCPv6, or be manually configured with
   addresses."

4.1.  Interaction with IPv6 specifications

- make it clearer that there would be considerable time effort involved in updating RFCs

"Regardless of implementation issues, the RFCs themselves
   would all need to be updated if the 64-bit rule was changed, even if
   the updates were small."

to

"Regardless of implementation issues, the RFCs themselves
   would all need to be updated if the 64-bit rule was changed, even if
   the updates were small*, which would involve considerable time and effort*."

- add a ref to RFC6177, "IPv6 Address Assignment to End Sites"

"First and foremost, the RFCs describing the architectural aspects of
   IPv6 addressing explicitly state, refer and repeat this apparently
   immutable value: Addressing Architecture [RFC4291], Reserved
   Interface Identifiers [RFC5453], ILNP [RFC6741]."

to

"First and foremost, the RFCs describing the architectural aspects of
   IPv6 addressing explicitly state, refer and repeat this apparently
   immutable value: Addressing Architecture [RFC4291], *IPv6 Address Assignment to End Sites [RFC6177]*, Reserved
   Interface Identifiers [RFC5453], ILNP [RFC6741]."

- It seems the only difference between MLDv1 and MLDv2 is that the MLDv2 RFC explicitly stated the fe80::/64 prefix and how the lower 64 bits of the LL address are to be used to select a querier - MLDv1 has the same link-local address use rules, just not in as much detail. So perhaps make the MLDv2 text better focus on the explicit statement of the fe80::/64 prefix (the current text made me wonder if MLDv1 messages might not be required to come from LL addresses.)
- Delete duplicate 'length' - "prefix length of length /64"

" The MLDv2 protocol [RFC3810] mandates all queries be sent with the
   fe80::/64 link-local source address prefix and subsequently bases the
   querier election algorithm on the link-local subnet prefix length of
   length /64."

to something like

"MLDv1 [RFC2710] and MLDv2 [RFC3810] protocols mandate that all queries are sent with a link-local source address, with exception to MLD messages sent using the unspecified address, when the link-local address is tentative [RFC3590]. At the the time of publication of [RFC2710], [RFC2373] specified link-local addresses with 64-bit interface identifiers. MLDv2 [RFC3810] explicitly stated the use of the fe80::/64 link-local prefix, and based the querier election algorithm on the link-local subnet prefix of length /64."

- Highlight that support for 'on-link' anycast is a basic IPv6 neighbor discovery capability, and therefore applications would expect it to be availale.

"This could of course be fixed in the way
   described for /127 in [RFC6164], i.e., avoiding the use of anycast
   within a /120 subnet."

to

"This could of course be fixed in the way
   described for /127 in [RFC6164], i.e., avoiding the use of anycast
   within a /120 subnet. Note that support for "on-link anycast" is a standard IPv6 neighbor discovery capability [RFC4861][RFC7094], and therefore applications and their developers would expect it to be available."

4.2.  Possible areas of breakage

- Possibly change 'breakage' to 'failure' throughout this section.

(The informality of 'breakage' appeals to me, however it is probably a bit too informal for this sort of document. I thought it might not be a real word, however apparently it is, and is referring to unused and therefore highly profitable service(s), such as unused calling card credit. )   

- make the following read a bit better

"[RFC3972] has defined a detailed algorithm how to generate 64-bit
      interface identifier from a public key and a 64-bit subnet prefix."

changed to

"[RFC3972] has defined a detailed algorithm *describing* how to generate *a* 64-bit
      interface identifier from a public key and a 64-bit subnet prefix."

- change 'Breaking' to 'Changing' to make it read a bit better

"Breaking the /64 boundary would certainly break the current CGA
      definition."

to

"*Changing* the /64 boundary would certainly break the current CGA
      definition.

- I think the follow link-local text in the last paragraph of the section should instead be another bullet point in the previous list, reworded appropriately.
- While I certainly agree all hosts should use same length LL prefixes/IIDs, I'm not sure I understand why it would be a problem if they didn't. As far as I can tell, other than the formation of the LL address, prefix lengths and therefore IID lengths are never used in LL related operations. The egress interface has to be supplied when using an LL address, rather than a longest match route table lookup determining it, so the link-local prefix length/IID length doesn't matter for that, and other related operations such as NS/NA don't seem to use prefix length for any validation, including of LL addresses. So I think more or clearer explanation of the problem would would be useful. 

"There is however the rather special case of the link-
   local prefix.  While RFC 4862 is careful not to define any specific
   length of link-local prefix within fe80::/10, [RFC4291] does define
   the link-local IID length to be 64 bits.  Operationally there could
   be a problem unless all hosts on a link use IIDs of the same length
   to configure a link-local address during reboot.  Typically today the
   choice of 64 bits for the link-local IID length is hard-coded per
   interface, and systems behave as if the link local prefix was
   actually fe80::/64.  There might be no way to change this except
   conceivably by manual configuration, which will be impossible if the
   host concerned has no local user interface."

4.3.2.  Other Observations

- The first paragraph is referring to forwarding, the second paragraph seems to be referring to packet filtering, and then the third paragraph is again referring to forwarding. I think it would be better if the second and third paragraphs were swapped, so that the two paragraphs discussing forwarding were next to each other.

- The ordering of the paragraphs made me a little confused about what type of 'filtering' was being discussed on the second paragraph. I presume it is packet filtering, so perhaps making it clearer would be better after the paragraph has been moved:

"It has been reported that at least one type of switch has a content-
   addressable memory limited to 144 bits, which is indeed a typical
   value for commodity components [TCAM].  This means that filters
   cannot be defined based on 128-bit addresses and two 16-bit port
   numbers; the longest prefix that could be used in such a filter is a
   /112."

changed to

"It has been reported that at least one type of switch has a content-
   addressable memory limited to 144 bits, which is indeed a typical
   value for commodity components [TCAM].  This means that *packet* filters or *access control lists*
   cannot be defined based on 128-bit addresses and two 16-bit port
   numbers; the longest prefix that could be used in such a *packet* filter is a
   /112."

4.4.  Implementation and deployment issues

- Reference to RFC5942, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes"

"It does this (even if
   technically it violates the protocol) because if there is no router
   on the link, the hosts effectively would fail to communicate each
   other with the configured addresses because the "on-link assumption"
   was removed in [RFC4861]."

to

"It does this (even if
   technically it violates the protocol) because if there is no router
   on the link, the hosts effectively would fail to communicate each
   other with the configured addresses because the "on-link assumption"
   was removed in [RFC4861]*[RFC5942]*."

- I think 'deployed at' reads a bit better

"Finally, IPv6 is already installed on many sites, with a large number
   of staff trained on the basis of the existing standards, supported by
   documentation and tools based on those standards."

changed to

"Finally, IPv6 is already *deployed at* many sites, with a large number
   of staff trained on the basis of the existing standards, supported by
   documentation and tools based on those standards."

4.5.  Privacy issues

- I'm not really sure the following text is relevant, as it discussing how a level of privacy could be achieved with much shorter IIDs, which is venturing down the path of assuming IID lenghts will be changed, contrary to what this draft is saying and justifying shouldn't happen, and therefore solutions need to be developed to how to get what we've already got with 64-bit IIDs.
- Alternatively, if this text is to remain, then I think it is necessary to point out that there is not any currently defined automated recovery procedure from DAD failure. Currently the failed address is not to be used and a system message is to be logged, or in the case of a link-local addr DAD failure, IPv6 is to be completely disabled on the interface according to RFC4862. (If anybody wants to automate DAD recovery, Appletalk would be an example of how to deal with it.)

5.  Security Considerations

- Add example /120 prefix qualifier in, as the last sentence of the previous paragraph made me think the following paragraph was again talking about a /64.

"However, assume that an attacker finds one valid address A and then
   starts a scanning attack by scanning "outwards" from A, by trying
   A+1, A-1, A+2, A-2, etc."

changed to

"However, assume that an attacker finds one valid address A *in a /120* and then
   starts a scanning attack by scanning "outwards" from A, by trying
   A+1, A-1, A+2, A-2, etc."

That's it I think.

Best Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Aug 2014 16:37:16 +1200

Mark,

Wow, what a conscientious review. Thanks.

With the reviews now in hand, we will produce an updated draft
in the reasonably near future.

Regards
   Brian + co-authors

> I was asked to do a detailed review of the 'why64' draft. Here are my thoughts and comments. Sorry for the delay, I've been a bit ill over the last day or so.

<snip>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Aug 2014 16:46:51 +1200

>    of the address space in reserve."

I think we had something like that earlier, and we pulled it because
in practice ::/3 and f000::/3 have significant allocations (multicast
and other stuff). So is "close to" 7/8 accurate?

   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 4 Aug 2014 22:55:06 -0700

>________________________________
> From: Brian E Carpenter <[email-masked]>
>To: 6man <[email-masked]> 
>Cc: Mark ZZZ Smith <[email-masked]> 
>Sent: Tuesday, 5 August 2014 2:46 PM
>Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
> 
>

My thinking was that I think most people would have to calculate how much of the total IPv6 address space 2000::/3 represents, to then be able to evaluate how much remains, and I think a fair number of people won't go to that effort. So I think saying something like 'close to 7/8ths' or perhaps 'more than 3/4ths of the address space in reserve' helps make it more reader friendly, and hopefully helps reduce the fairly common fear that using /64s, /56s or /48s will make the IPv6 address space run out quickly.

Regards,
Mark.

---

From: David Farmer <[email-masked]>
Date: Tue, 05 Aug 2014 14:07:00 -0500

> My thinking was that I think most people would have to calculate how much of the total IPv6 address space 2000::/3 represents, to then be able to evaluate how much remains, and I think a fair numbe…

Yes, we should do the math for them. I like "more than 3/4ths of the 
address space in reserve", the important concept to communicate is the 
vast majority of IPv6 addresses space is reserved. Where the exact mark 
is located at is unimportant.

-- 
================================================
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: Scott Schmit <[email-masked]>
Date: Tue, 5 Aug 2014 23:19:52 -0400

>    IPv4 address shortage*,* by doubling the address size to 64 bits."

This changes the meaning of the sentence and no longer reads correctly.
Before, it was saying that the IETF could have doubled the 32-bit IPv4
addresses in IPv6 to relieve the address shortage, but instead jumped to
128 bits to add flexibility.

Now it says that the IETF chose to make IPv6 addresses 128 bits long for
flexibility by doubling the address size from 32 bits to 64 bits--which
doesn't even make sense.

-- 
Scott Schmit

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Aug 2014 15:47:05 +1200

> flexibility by doubling the address size from 32 bits to 64 bits--which

I think Lynne Truss, would agree with you. I will tune the sentence
accordingly.

    Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 6 Aug 2014 02:37:29 -0700

I put the comma in there because I think it was, as my various teachers used to say, a bit of a "run-on-sentence". Commas serve as pauses in sentences, and it seemed to need one at that point.

I've forgotten too much English grammar to know exactly what the problem is, however perhaps the deeper problem is that the sentence is trying to saying two different but related things instead of one (IPv6 addresses are 128 bits for these additional reasons; we could have just doubled the IPv4's address size to solve the lack of addresses problem).

Perhaps something like this:

"IPv6 addresses were originally chosen to be 128 bits long to provide flexibility and new possibilities. This was instead of doubling the 32 bit IPv4 address size to 64 bits to solve the near term problem of the lack of Internet addresses."

----- Original Message -----
> To: [email-masked]
> Cc: [email-masked]
> Sent: Wednesday, 6 August 2014 1:47 PM
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tim Chown <[email-masked]>
Date: Wed, 6 Aug 2014 10:48:05 +0100

Hi,

> I put the comma in there because I think it was, as my various teachers used to say, a bit of a "run-on-sentence". Commas serve as pauses in sentences, and it seemed to need one at that point.

I think it’s fine to have no comma, and indeed necessary.

The sentence can be flipped to read more clearly:

“Rather than simply relieving the IPv4 address shortage by doubling the address length to 64 bits, IPv6 addresses were chosen to be 128 bits long to provide flexibility and new possibilities."

But this is a minor not in the bigger picture :)

Tim

---

From: Tim Chown <[email-masked]>
Date: Wed, 6 Aug 2014 12:17:10 +0100

Hi,

Some comments in-line, mostly on the bits I originally wrote...

On 5 Aug 2014, at 05:00, Mark ZZZ Smith <[email-masked]> wrote:

>    denying correct operation to active devices on the network.”

If you’re to break the sentence, I’d say “Such an attack attempts to fill…”

In the para below I’d change "An example would be to use a /120 prefix…” to “One potential way to mitigate this attack would be to consider using a /120 prefix…”

>    addresses.”

It is relevant, but I would change the line to:

Given SLAAC assumes a 64bit network boundary, in such an approach hosts would likely need to use DHCPv6, or be manually configured with addresses."

>    Interface Identifiers [RFC5453], ILNP [RFC6741].”

Seems reasonable.

> "MLDv1 [RFC2710] and MLDv2 [RFC3810] protocols mandate that all queries are sent with a link-local source address, with exception to MLD messages sent using the unspecified address, when the link-local address is tentative [RFC3590]. At the the time of publication of [RFC2710], [RFC2373] specified link-local addresses with 64-bit interface identifiers. MLDv2 [RFC3810] explicitly stated the use of the fe80::/64 link-local prefix, and based the querier election algorithm on the link-local subnet prefix of length /64.”

Seems good.

> (The informality of 'breakage' appeals to me, however it is probably a bit too informal for this sort of document. I thought it might not be a real word, however apparently it is, and is referring…

Agree, “breakage” is not the best word.

> - I'm not really sure the following text is relevant, as it discussing how a level of privacy could be achieved with much shorter IIDs, which is venturing down the path of assuming IID lenghts will…

I think it’s arguing that if the IID is shorter, 

> - Alternatively, if this text is to remain, then I think it is necessary to point out that there is not any currently defined automated recovery procedure from DAD failure. Currently the failed add…

I think this is a good point for short IIDs, but needs to be captured in a new section 4.6 “DAD implications” (or similar), as it’s not a privacy issue.  However, I would again assume in (say) a /120, that addresses would be assigned by DHCPv6, or manually, and there would be no RFC 7217 or RFC 4941 addresses used (I recall 7217 is agnostic to IID length but 4941 assumes /64).

>    A+1, A-1, A+2, A-2, etc.”

Yes.

Thanks!
Tim