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

Mark,

On 15/03/2014 13:54, Mark ZZZ Smith wrote:
> 
> 
> 
> ----- Original Message -----
>> From: RJ Atkinson <rja.lists@gmail.com>
>> To: ipv6@ietf.org
>> Cc: 
>> Sent: Friday, 14 March 2014 2:49 AM
>> Subject: Re: Subject: Confirming consensus on adopting draft-carpenter-6man-why64
>>
>> 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.
> 
> So what about ::1/128? What is the history of loopback being /128 rather than /64?

I suspect that it was given a /128 without much thought, since the loopback
address for IPv4 was a /32. I can't be bothered to search the old
documents before breakfast, but I expect this was done before the IID
length changed from 48 to 64.

    Brian

> (And I really think it would have been better to be at least a /64 -
> 
> https://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix-04)
> 
> 
>>  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.
>>
>>>  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.
>>
>> Yours,
>>
>> Ran Atkinson
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 