Subject: [Fwd: I-D Action: draft-ietf-6man-why64-00.txt]

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Apr 2014 07:52:09 +1200

Hi,

This is a substantial update compared to draft-carpenter-6man-why64-01.
As requested by the meeting in London, it has been reorganized with
a more positive tone (including a proposed consensus statement).
There are now three major sections: advantages of the fixed length IID,
arguments for shorter lengths, and expected effects of varying the
length. There are also quite a few technical clarifications.

We hope that all the comments received have been dealt with, but
in some cases we've obviously had to make a choice between differing
views. Please review and comment further.

Regards
   Brian + co-authors

-------- Original Message --------
Subject: I-D Action: draft-ietf-6man-why64-00.txt
Date: Fri, 11 Apr 2014 07:49:16 -0700
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

        Title           : Analysis of the 64-bit Boundary in IPv6 Addressing
        Authors         : Brian Carpenter
                          Tim Chown
                          Fernando Gont
                          Sheng Jiang
                          Alexandru Petrescu
                          Andrew Yourtchenko
	Filename        : draft-ietf-6man-why64-00.txt
	Pages           : 23
	Date            : 2014-04-10

Abstract:
   The IPv6 unicast addressing format includes a separation between the
   prefix used to route packets to a subnet and the interface identifier
   used to specify a given interface connected to that subnet.
   Currently the interface identifier is defined as 64 bits long for
   almost every case, leaving 64 bits for the routing prefix.  This
   document describes the advantages of this fixed boundary and analyses
   the issues that would be involved in treating it as a variable
   boundary.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-why64/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-why64-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: David Farmer <[email-masked]>
Date: Sat, 12 Apr 2014 16:30:58 -0500

> views. Please review and comment further.

I believe my comments have been dealt with and I am satisfied with how 
the draft balances the issues involved. The draft makes it clear that 
IID length is a parameter, currently set to 64 by the standards. 
However, the draft also makes clear, other IID lengths are possible when 
using DHCPv6 and manual configuration, even though NOT compliant to the 
overall IPv6 standards defining the IID length as 64.

An editorial suggestion; In the second paragraph of section 3.1 the 
phrase "using either manually configured addressing or DHCPv6" is used 
and similar language is used in the third paragraph of section 3.4. 
However, in the second paragraph of section 4.4, the phrase "require 
either statically configured addresses or DHCPv6" is used. I suggest 
using the same terminology in all three instances, and would prefer 
"manually configured" over "statically configured."

Finally, I like the addition of section 2, describing the advantages of 
a fixed IID length, and along with introduction, together these sections 
provide actual answers to "why 64?"

Thanks.

-- 
================================================
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: George Michaelson <[email-masked]>
Date: Mon, 14 Apr 2014 08:48:12 +1000

I think its a well written document. Overall I think it 'does what it says
on the box' which is to both advocate for /64 and explore the issues, and I
believe it reflects an honest assessment of the plus and minus
considerations.

I am somewhat unsure about a circularity which is in effect "because we
said so" regarding other standards and prior standards statements regarding
/64. I think the cost inside standards process of coping with change is the
least technically satisfying reason to exclude a change in standards
behaviour: on the same criteria we might as well stick with IPv4 since
every standard which mistakenly bound a 32 bit quantity into a field has
had to be re-considered. Basically, I think this is a true cost, and a true
reason, but the sheer volume of references inside this document rather
overloaded the case. Yes: /64 is bound into a lot of places.

the 2000::/3 point is good, but I am still left somewhat aghast that an
initial world view of "128 will never run out" has now irrevocably (if this
document is taken as read) burned 2^64 bits for purely local consideration,
on the basis that we're only in 1/512 of the upper space, and 64 will be
"enough". -A lot of upper layer richness has indeed gone out of the system
with large flat networks being the current architecture. Who is to say that
will remain true in 20, 30 years time? Much as we cycle through a
Bell/Mudge/Macnamara wheel-of-life in computer systems design, we cycle
through wheels in networks of hub-and-spoke, ring and flat-mesh. We may
find we need more H/D ratio bits in future than we thought.

So having had my whinge on the other document, and noting nothing much new
here commenting on this one, I think its a good, useful document. Thanks
for writing it.

-George

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Apr 2014 21:14:10 -0300

Hi, David,

> "manually configured" over "statically configured."

+1.

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: Mon, 14 Apr 2014 21:19:36 -0300

On 04/13/2014 07:48 PM, George Michaelson wrote:
> said so" regarding other standards and prior standards statements
> regarding /64. I think the cost inside standards process of coping with
> change is the least technically satisfying reason to exclude a change in
> standards behaviour: on the same criteria we might as well stick with
> IPv4 since every standard which mistakenly bound a 32 bit quantity into
> a field has had to be re-considered. Basically, I think this is a true
> cost, and a true reason, but the sheer volume of references inside this
> document rather overloaded the case. 

FWIW, I agree. Any suggestion to address this?

> initial world view of "128 will never run out" has now irrevocably (if
> this document is taken as read) burned 2^64 bits for purely local
> consideration, on the basis that we're only in 1/512 of the upper space,
> and 64 will be "enough". -A lot of upper layer richness has indeed gone
> out of the system with large flat networks being the current
> architecture. Who is to say that will remain true in 20, 30 years time?
> Much as we cycle through a Bell/Mudge/Macnamara wheel-of-life in
> computer systems design, we cycle through wheels in networks of
> hub-and-spoke, ring and flat-mesh. We may find we need more H/D ratio
> bits in future than we thought.

Just as a clarification: Do you mean we might need mre than 64 bits for
the subnet, or that we might prefer to have fewer bits for it in the future?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 15 Apr 2014 20:08:03 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont

> the subnet, or that we might prefer to have fewer bits for it in the future?

I happen to fully agree with George, as I've indicated in the past, and what he means has to be that prefixes longer than 64 should not be summarily dismissed! Here's why HE means that. Quoting:

"... but I am still left somewhat aghast that an initial world view of '128 will never run out' has now irrevocably (if this document is taken as read) burned 2^64 bits for purely local consideration, ..."

I read that to say, we have grabbed a full 64 of 128 bits for use in purely local subnets. So this "128 bits will never run out" would only be true if we assume huge individual subnets are actually, realistically, in the cards.

Do we believe the future consists of huge individual subnets? Or do we instead believe that we should dedicate a huge and vastly underused address space to each local subnet, just so it becomes more difficult to randomly guess a real host's address? If the latter (which sounds more plausible), doesn't this narrative about how 128-bit addresses "will never run out" start sounding awfully simplistic and overstated?

Bert

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Apr 2014 10:15:44 +1200

> FWIW, I agree. Any suggestion to address this?

I think it's entirely appropriate that we discuss the affected
documents. We should certainly add text pointing out that IETF
work is not as expensive as updating all the software in the world.

> the subnet, or that we might prefer to have fewer bits for it in the future?

In any case, I don't think it's the job of this document to
discuss this in depth. I agree that it is entirely conceivable
that when we release a second /3 for unicast allocations (after
using up those 35 trillion /48s) we could also decide to change
the addressing architecture for that new /3.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Apr 2014 19:40:19 -0300

On 04/15/2014 05:08 PM, Manfredi, Albert E wrote:
> I read that to say, we have grabbed a full 64 of 128 bits for use in
> purely local subnets. So this "128 bits will never run out" would
> only be true if we assume huge individual subnets are actually,
> realistically, in the cards.
> 
> Do we believe the future consists of huge individual subnets? Or do
> we instead believe that we should dedicate a huge and vastly
> underused address space to each local subnet, just so it becomes more
> difficult to randomly guess a real host's address? If the latter
> (which sounds more plausible), doesn't this narrative about how
> 128-bit addresses "will never run out" start sounding awfully
> simplistic and overstated?

I've never done the math myself, although I'm aware that attempts at
predicting this sort of stuff ("640K ought to be enough...") have failed.

Thinking out loud, I wonder if one could apply the Robustness Principle
here, without actually advocating any change on the sending side. (That
is, prepare implementations to gracefully handle non-64 prefixes, but,
say, still mandate that non-64 prefixes MUST NOT be sent). This would
not break anything nowadays, but would lead to more robust
implementations that eventually could handle non-64 prefixes if we
realize they are of use).

Thoughts?

Thanks!

Best regards,

---

From: George Michaelson <[email-masked]>
Date: Wed, 16 Apr 2014 08:50:32 +1000

On Tue, Apr 15, 2014 at 10:19 AM, Fernando Gont <[email-masked]>wrote:

> Basically, I think this is a true

A concordance. I'd start with a draft, collate in tabular or section form
the references, and if it gets past an 80:20 point work it through revising
the rest in nits time, and then small revisions in future. I think going to
registry is overkill. Its a documentation exercise in itself.

>
>
> > We may find we need more H/D ratio

More richness in topology bits the address space holder has, fewer bits per
local subnet.

And of course vice-versa: much larger spaces, which represent as flat
topologies on top of ?SDN? and so have huge bitfields for host in the
subnet, using weird markers in address bits for stuff I don't think I like
but others (DT?) seem to want to explore.

I think being proscriptive to 8+8 across the board (outside of INLP) is not
right. I think Operations people would ask that the IETF not over state its
remit. Yes, a huge amount of silicon is now optimized for /64. A pretty
large amount of silicon was optimized for 32 bit computing for a long time
too!

-G

---

From: Fernando Gont <[email-masked]>
Date: Tue, 15 Apr 2014 19:54:12 -0300

> the addressing architecture for that new /3.

FWIW, here I was just asking for help to parse George's response
("English as a second language" thing on my side).

Thanks!

Best regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Apr 2014 11:08:56 +1200

> registry is overkill. Its a documentation exercise in itself.

You seem to describe more work of an ongoing nature. I think it's
necessary *and* sufficient to identify a large enough set of soecifications
to show that it would be a big job. If you think it distracts the
reader, we could move the detailed list to an appendix.

> right. 

Well, that is a comment on the normative statement in the addressing
architecture. The current draft can't address that. If you want
to change it, that would need a standards track draft.

   Brian

> I think Operations people would ask that the IETF not over state its

---

From: 神明達哉 <[email-masked]>
Date: Wed, 16 Apr 2014 08:50:40 -0700

At Sat, 12 Apr 2014 07:52:09 +1200,

> This is a substantial update compared to draft-carpenter-6man-why64-01.
[...]
> views. Please review and comment further.

A small correction: In Section 4.3.1 it states

   o  the "A" bit in the Prefix Information Options is honored only if
      the prefix length is 64.  At least for the case of a prefix longer
      than /64, this is consistent with [RFC4862], which defines the
      case where the sum of the link-local prefix length and the IID
      length is larger than 128 as an error consition.

First off:
- s/consition/condition/
- I don't understand why the link-local prefix length is mentioned
  here.  I guess this is just a typo for "advertised (global) prefix".

On fixing these trivial points: [RFC4862] defines the case where the
sum of the link-local prefix length and the IID length does *not
equal* 128 bits, not just *larger than*.  The sentence also doesn't
make perfect sense since simply because the prefix length > 64 doesn't
necessarily mean the sum is larger than 128 (unless we assume a
specific value(s) of the size of IIDs, which is not clear from this
paragraph).

So I suggest revising this sentence as follows:

      [...]  At least for the case where the IID length is defined to
      be 64 bits in the corresponding link-type-specific document,
      which is the case for all currently published such documents,
      this is consistent with [RFC4862], which defines the case where
      the sum of the advertised prefix length and the IID length does
      not equal 128 as an error condition.

--
JINMEI, Tatuya

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Apr 2014 08:54:31 +1200

Hi,

Thanks for the careful reading.

>       length is larger than 128 as an error consition.

OK

>   here.  I guess this is just a typo for "advertised (global) prefix".

Direct quote from 4862 section 5.3.:
   If the sum of the link-local prefix length and N is larger than 128,
   autoconfiguration fails and manual configuration is required.

Direct quote from 4862 section 5.5.3:
      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored.

I think the current text mixes these two cases.

>       not equal 128 as an error condition.

That's fine.

Thanks
    Brian