This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] IPv6 on P2P links
- Previous message (by thread): [ipv6-wg] IPv6 on P2P links
- Next message (by thread): [ipv6-wg] IPv6 on P2P links
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marco Hogewoning
marcoh at marcoh.net
Thu May 26 11:13:04 CEST 2011
> 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
- Previous message (by thread): [ipv6-wg] IPv6 on P2P links
- Next message (by thread): [ipv6-wg] IPv6 on P2P links
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]