nanog mailing list archives
Re: Using /126 for IPv6 router links
From: Igor Gashinsky <igor () gashinsky net>
Date: Wed, 27 Jan 2010 16:19:23 -0500 (EST)
:: > If a worst-case situation arises, and you have to peer with a device that :: > doesn't properly support /127's, you can always fall back to using /126's :: > or even /64's on those few links (this is why we reserved a /64 for every :: > link from the begining).. :: :: If this is the case, why not just use /64s from the beginning? Why :: bother with hacking it up if it's only going to be reserved anyway? :: :: I'm trying to understand how reserving-and-hacking a /64 makes :: administration any easier. :: :: Even if all ptp are coming out of a single /64 (as opposed to reserving :: a /64 for each), what benefits are there to that? It seems as though :: that this is v4 thinking. This really has nothing to do with wanting to use the space more efficiently, it has to do with overcoming potential operational issues. Reserving the whole /64 is what makes administration easier in face of different vendor capabilities, using only /127 is what's operationally safer on PtP links -- you face 2 major issues with not using /127 for PtP-type circuits: 1) ping-ponging of packets on Sonet/SDH links Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP interface, and somebody comes along and ping floods 2001:db8::2, those packets will bounce back and forth between the 2 sides of the link till TTL expires (since there is no address resolution mechanism in PtP, so it just forwards packets not destined for "him" on). 2) ping sweep of death Take the same assumption for addressing as above, and now ping sweep 2001:db8::/64... if the link is ethernet, well, hope you didn't have any important arp entries that the router actually needed to learn... (and, if an important entry times out, and now can't get re-learned, *really* bad shit happends, trust me on that one) Both of these can be mitigated by either *really* heavy-handed ACLs, or changes to SONET/SDH forwarding semantics, as well as ARP queue prioritization, but very few vendors support those right now. For most people, using /127's will be a lot operationaly easier then maintain those crazy ACLs, but, like I said before, YMMV.. -igor
Current thread:
- RE: Using /126 for IPv6 router links, (continued)
- RE: Using /126 for IPv6 router links Matt Addison (Jan 25)
- RE: Using /126 for IPv6 router links Igor Gashinsky (Jan 26)
- Re: Using /126 for IPv6 router links Steve Bertrand (Jan 26)
- Re: Using /126 for IPv6 router links Grzegorz Janoszka (Jan 27)
- RE: Using /126 for IPv6 router links TJ (Jan 27)
- RE: Using /126 for IPv6 router links Pekka Savola (Jan 26)
- Re: Using /126 for IPv6 router links Mark Smith (Jan 26)
- Re: Using /126 for IPv6 router links Jim Burwell (Jan 27)
- RE: Using /126 for IPv6 router links Igor Gashinsky (Jan 27)
- Re: Using /126 for IPv6 router links Steve Bertrand (Jan 27)
- Re: Using /126 for IPv6 router links Igor Gashinsky (Jan 27)
- Re: Using /126 for IPv6 router links Dale W. Carder (Jan 27)
- Re: Using /126 for IPv6 router links David Barak (Jan 28)
- Re: Using /126 for IPv6 router links Igor Gashinsky (Jan 28)
- Re: Using /126 for IPv6 router links Bill Stewart (Jan 29)
- Re: Using /126 for IPv6 router links Leo Bicknell (Jan 25)
- Re: Using /126 for IPv6 router links Owen DeLong (Jan 25)
- Re: Using /126 for IPv6 router links Christopher Morrow (Jan 25)
- Re: Using /126 for IPv6 router links Mark Smith (Jan 26)
- Re: Using /126 for IPv6 router links David Barak (Jan 26)
- Re: Using /126 for IPv6 router links Mark Smith (Jan 26)