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)
