(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 <[email protected]> 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 <[email protected]> > 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. > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
