Subject: Re: Subject: Confirming consensus on adopting draft-carpenter-6man-why64

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 09:58:04 -0400

On Weds 12 March 2014 at 20:23:33 +0900, Lorenzo Colitti wrote:
> For example, I happen to think it's acceptable and perhaps even desirable 
> to not allow IPv6 addresses to have prefix lengths between /65 and /126.

Yes.  

We need to allow lengths of /126 and longer BUT ONLY as a real-world
work-around to defects in the point-to-point link implementation
of IPv6 in certain vendors deployed IPv6 routers.

(ASIDE:  One hopes those defects now are fixed in newer code, but 
once operational practices like this happen they almost never go away.)

As I said last week, I am aware of deployed IPv6 routers that DO NOT
handle prefix lengths between /64 and /126 as some here might wish,
because those routers are following the actual IETF IPv6 specifications.
They have special-case code to handle point-to-point links (e.g. using
/126) but otherwise only handle routing prefixes of /64 or smaller.
In at least some cases, the origin for this has to do with the width 
of available commodity TCAM parts (and indirectly with the high cost
of such parts).  See also Steve Blake's note from Weds March 12th 2014
at 16:52:19 -0400.

> If others agree with me, then it's possible we won't be able to get
> consensus on that problem statement, and therefore we should just
> maintain the current content of this draft as "this is the current
> state of affairs, and here's why it was designed this way".

At the IPv6 WG in-person meeting last week, most of the room seemed
to agree with you.  Certainly I do.  

Below are some of the reasons that people at the microphone last
week cited for not changing things, and for editing the I-D so that 
it is less defensive in tone and more affirmative (i.e., saying that
"we have an IPv6 64-bit boundary, it was a deliberate design
choice, and it has these benefits"):

	- installed base of equipment that doesn't handle
	  prefix lengths between /64 and /126 as some might expect.

	- huge installed base of trained system admins who
	  understand how the IPv6 specifications are today
	  and do NOT expect major architectural shifts 2 decades
	  after IPv6 was specified and initially deployed.

	- huge installed base of manuals, books, training courses
	  that are teaching new users, students, and system admins
	  on the IPv6 specifications as they are today (and expect
	  those specifications to remain stable).

	- large and growing installed base of middleboxen (for 
          security, load-balancing, or otherwise) that comply with 
          the existing IPv6 specifications that mandate a 64-bit
          boundary.  

        - As others have noted, the IPv6 specifications are "super
          clear" about the 64-bit boundary and most widely used
          implementations DO COMPLY with the IPv6 specifications
          (See quoted text in this earlier note to the IETF IPv6 list:  
          http://www.ietf.org/mail-archive/web/ipv6/current/msg20417.html)

> Note: I happen to think that there are good reasons for this split, 
> and I would love to see the draft say "we believe /64 is the right way
> to go because...", 

A lot of the room agreed with the quote above at last week's IETF
IPv6 WG Meeting.  Indeed, I had thought that this was PRECISELY
the direction that Brian had agreed to take the I-D -- based on 
what he and others said during last week's meeting.

I'd still like to see that direction taken, and I fully agree with
Lorenzo about the preferred direction for this I-D -- if the I-D
is taken up by the IETF IPv6 WG.

(I seem to be agreeing with Lorenzo a lot lately, although we've
been known to disagree a bit about some other things from time
to time in the past. :-)

I do NOT support adopting draft-carpenter-6man-why64 as an IETF
work item UNLESS it is edited to be positive and affirmative
about the 64-bit boundary AND the 64-bit boundary is NOT re-cast 
by that document as a "problem" or "issue" to be solved/changed.

We need to quit changing the IPv6 specifications, whether the
IPv6 base spec, ND specs, ICMPv6 specs, or other specs.  See
my separate note earlier today about the need for stability.

Yours,

Ran

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Mar 2014 05:59:09 +1300

fwiw I believe that Ran's characterisation of the face to
face discussion is correct. I haven't seen any really new
arguments in the discussion (i.e., new compared to ones the
authors had already seen when compiling the draft).

My understanding of the changes requested in the meeting
is similar to Ran's. The authors are of course awaiting a
consensus confirmation from the WG Chairs before starting work
on an updated draft.

Regards
   Brian

On 14/03/2014 02:58, RJ Atkinson wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Mar 2014 19:22:24 +0000

> consensus confirmation from the WG Chairs before starting work

I would agree with that (as a co-author).

Tim

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Mar 2014 13:40:45 -0700

> consensus confirmation from the WG Chairs before starting work
My comments at the mike are consistent with what Ran is asking for; the 
document needs to be positive and affirmative in explaining why /64 
whereas the current draft version is quite defensive.

    Erik