Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks

[Usman Latif <[e-mail]>]

(Hopefully) my last email on this topic:

- Not only has RFC 6164 failed to properly update RFC 5375 with any reasoning provided for 5375 section(s) B.2.xx

- It has also defied and failed to update RFC 4291 which says (section 2.5.1) - "For all unicast addresses, except those that start with binary value 000, interface IDs are required to be 64 bits long"

- IMO 6164 seems to be justifying actions of those deployments where ppl have simply gone ahead and deployed /127s without properly doing their homework on v6 addressing

- This has put a constraint on greenfield deployments where we are in a position to implement /64s but are now having to deal with a compromise for existing deployments

- We are fine to follow 6164, but since RFCs come and go, if tomorrow the applications demand specific use of interface identifiers in the lower 64-bit space, and you folks send out a new RFC to override 6164, then we'll be required to re-address our network - then "I Will Come Back To Haunt You Guys - if I am alive" :)

Pls don't take me the wrong way, I have read many RFCs and think you have done a great job buy I was never confused the way I am now after successively going through 3627, 4291, 5375 and now 6164....

Regards,
Usman

Sent from my iPhone


On 28/09/2012, at 3:38 AM, Usman Latif <[e-mail]> wrote:

> I'll conclude on the following points:
> 
> i. The only guidance that's out there today for device loopbacks (whether informational or standards track) is 5375 -because 6164 (whether voluntarily or involuntarily) chose not to provide any considerations for /128 loopbacks
> 
> ii. A reader following considerations of /128 from 5375 is led to also consider B.2.4  B.2.6 and B.2.7 for any prefixes where the subnet length is longer than /64
> 
> iii. If 6164 overrides any previous RFCs, IMO it should provide some reasoning of why it no longer felt that the sections B.2.4. B.2.6 and B.2.7 of 5375 should be considered
> 
> 
> 
> Sent from my iPhone
> 
> On 27/09/2012, at 11:12 PM, Brian E Carpenter <[e-mail]> wrote:
> 
>> Usman,
>> 
>> On 27/09/2012 12:43, Usman Latif wrote:
>>> Hi Joel,
>>> 
>>> RFC 6164 overriding 3627 seems logical
>>> However, I am looking more from perspective of 5375
>> 
>> RFC 5375 is an Informational document. You are at liberty to read it or not,
>> and to make use of it or not.
>> 
>> RFC 6164 is a Standards track document. It is of course a voluntary standard
>> like all IETF standards, but if you claim to implement it, it clearly preempts
>> an older Informational document such as RFC 5375.
>> 
>> As SM reminded us, it was probably a mistake that RFC 6164 didn't formally
>> update RFC 5375, but so what? There are many minor inconsistencies between
>> RFCs. Please don't lose any sleep over it. As long as you aren't accidentally
>> running SLAAC on a pt2pt link, none of this matters, as far as I can see.
>> 
>> Brian
>> 
>> P.S. I am now adding this thread to my "ietf-silly-subj" filter.
>