[ipv6-wg] IPv6 on P2P links

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 at 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 at marcoh.net]
Sent: Thursday, May 26, 2011 11:13 AM
To: Gunter Van de Velde
Cc: Pierre-Yves Maunier; Jasper Jans; ipv6-wg at 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