Marco, You have pretty much nailed it there. There is a million ways to do it - there is more (or less) reason and rhyme to pick your favorite flavour of the day. And yes we have the whole "let's do what they do" approach. It still leaves me facing several RFCs that says different things, vendors that might or might not support things and an all together bigger mess than I was hoping for. Anything that can be put forward as a clear cut proposal on how to handle these addressing cases would be appreciated from my point of view. It might even be something to whack your vendor over the head with - not much different from the IPv6 feature list that was put together that is now being used in tenders with regards to IPv6 feature parity. Met vriendelijke groet, Jasper Jans Team Leader Network Operations Sr. Network Engineer T: 088 - 00 68 152 F: 088 - 00 68 001 M: 06 - 218 26 380 E: jasper.jans@espritxb.nl EspritXB Monitorweg 1, 1322 BJ Almere Postbus 60043, 1320 AA Almere T: 088 00 68 000 KvK: 1717 7850 F: 088 00 68 001 W: http://www.espritxb.nl http://www.linkedin.com/companies/espritxb http://twitter.com/EspritXB EspritXB levert traditionele spraakdiensten en IP-gebaseerde diensten zoals VoIP, internettoegang, VPN, pinnen, alarm en managed hosting aan MKB Nederland. -----Original Message----- From: Marco Hogewoning [mailto:marcoh@marcoh.net] Sent: Thursday, May 26, 2011 11:13 AM To: Gunter Van de Velde Cc: Pierre-Yves Maunier; Jasper Jans; ipv6-wg@ripe.net Subject: Re: [ipv6-wg] IPv6 on P2P links
2001:db8:C15c:0::/127 has as two addresses on the link: 2001:db8:C15c:0::/127 (this one looks weird to start of with actually) and 2001:db8:C15c:0::1/127
While if it would have been a /126 2001:db8:C15c:0::1/126 and 2001:db8:C15c:0::2/126
Which matches much more the /30 stuff in v4: 192.168.1.1/30 and 192.168.1.2/30
I can tell you many people were very confused about this little change and as result many made mistakes configuring p2p's during the Interop event
Yes it looks confusing, but that is the case anyway and unfortunately the IETF didn't make things easier in this case :( We have rfc 4291stating that interface identifiers for all unicast addresses unless those starting with binary 000 must be 64 bits, that one is standards track. At the same time we have rfc 3627, informational, which states that /127 is considered harmful and finally rfc 6164 which is on standards track again contradicting that by describing the use of /127 for router point-to-point links. So far in the field it seems even more confusing, I've seen various lengths over the years. Mostly you see /126, /127 and also I come across /112 a lot and recently a /124 popped up on this list as well. I have a feeling we are heading for another disaster with this. No I'm not predicting the end of the world, the internet turns out to be resilient enough to survive these kind of things, but there is a serious risk of running into compatibility issues. Where do vendors stand on this ? I know some are really sticking to /64 pointing to rfc 3627. Now with rfc 6164 "overruling", you might be able to convince them to start supporting /127 as well. But what to do with those cases that require different length subnets. These all seem mostly arbitrary decisions made by somebody, which get copied by others based on the "let's not try invent the wheel ourselves". So it still seems reasonable to always assign the /64, no matter what you configure on the box. As anything else might come back and haunt you one day. And, putting on my co-chair hat, is there anything this WG might be able to do in providing some advice to the audience. Maybe issue a BCP on how to handle such cases ? Grtx, Marco Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer