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

[David Farmer <[e-mail]>]

On 3/13/14, 10:49 , RJ Atkinson wrote:
> On Thursday, March 13th 2014, at 09:15:25 -0500, David Farmer wrote:
>> While prefix lengths between /65 and /126 are currently
>> operationally invalid, not currently specified,
>> they are architecturally valid.
>
> I completely disagree.
>
> That NEVER has been true for unicast addresses, and is an
> example of confusion rather than a fact.
>
> As some here will recall, I've been involved with IPv6 even before
> it was called IPv6.  I also led the team with the world's first IPv6
> packet working on the wire (we made a good guess about the decision
> and had it working the week before) in our open-source 4.4 BSD
> implementation.  So I've been involved with IPv6 for a couple of
> decades now.
>
> ONLY the unicast *routing-prefix* is VLSM, and that does NOT
> include the fixed-length 64-bit IID.
>
> The IID is just an IID and has NEVER been VLSM.   Prefix lengths
> longer than /64 NEVER have been valid, EXCEPTING the relatively recent
> special-case for point-to-point links.  This was added ONLY to resolve
> an operational-security bug in certain deployed routers' IPv6
> point-to-point code.
>
>> So,it needs to be reinforce that VLSM
>
>
> ONLY true for the routing-prefix, not for the whole 128-bit object.
>
>> and a variable a length IID are fundamental to the IPv6 architecture,
>
>
> This has NEVER been true.

I have to disagree back, RFC 4291 "IP Version 6 Addressing 
Architecture", section 2.5 "Unicast Addresses", makes it clear that the 
Interface Identifier is architecturally a variable length field.

https://tools.ietf.org/html/rfc4291#section-2.5

Further, in section 2.5.1 " Interface Identifiers", specifies IIDs of 64 
with the following exception.

    For all unicast addresses, except those that start with the binary
    value 000, Interface IDs are required to be 64 bits long and to be
    constructed in Modified EUI-64 format.

I'll admit I don't fully understand the intent, implications, or nuances 
of this exception.  If the draft could clarify the intent, nuances, and 
usages of this exception maybe there would be less controversy on the 
subject.

In any case I think the clear intent of section 2.5 is to leave open 
future specification other IID lengths than /64.

>> and all IPv6 stacks must be able to deal with these prefix lengths
>> if/when they are specified as operationally valid.  If this weren't
>> the case then it would have been operationally impossible to implement
>> RFC6164 without major stack rewrites.
>
> I completely disagree, both with your desires and with your
> mis-representation of what happened historically.
>
> At least some major stack rewrites occurred.  Multiple router
> implementations that I'm aware of had to be quickly updated,
> and their operators had to deploy new images quickly also.
>
> Multiple currently deployed router implementations treat the /126 prefix
> VERY MUCH as a "special case" -- and added that code after the bug in
> one router's point-to-point implementation became an operational problem.
>
> Instead, this document needs to be very clear that IIDs are
> fixed length (both architecturally and for engineering),
> always have been fixed length, and that IIDs are NOT VLSM.

Then modify section 2.5 of RFC 4291, either taking "n" out of that 
section or clearly specify "n = 64 only" in that section and I'll 
happily shut up.  Most people I know feel it leaves the door open to 
other IID sizes.  Or, at least clarify the intent of the exception text 
in section 2.5.1.

> Yours,
>
> Ran Atkinson
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


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