Hi all.
While reading up on IPv6, I've seen numerous places that subnets are now
all /64.
I have even read that subnets defined as /127 are considered harmful.
However while implementing IPv6 in our network, I've encountered several
of our peering partners using /127 or /126 for point-to-point links.
What is the Best Current Practice for this - if there is any?
Would you recommend me to use /64, /126 or /127?
What are the pros and cons?
Hi Lasse,
We use /64s.
::1 for one end, ::2 for the second end.
Using /126s or /127s (or even /120s) is a result of going with the v4 mindset of conservation.
With a /32 you have 65536 /48s, and then 65536 /64s.
Guess you only need 1 /48 for all the p-to-p links, no?
Regards,
Carlos
(portuguese NREN, 6deploy.eu project partner)
While reading up on IPv6, I've seen numerous places that subnets are now
all /64.I have even read that subnets defined as /127 are considered harmful.
RFC3627, with a lot of discussion in the IETF on this. See also RFC 6164 - Using 127-Bit IPv6 Prefixes on Inter-Router Links
However while implementing IPv6 in our network, I've encountered several
of our peering partners using /127 or /126 for point-to-point links.
I personally don't any benefit in using /126 subnets.
What is the Best Current Practice for this - if there is any?
Would you recommend me to use /64, /126 or /127?
What are the pros and cons?
From an operational point of view there is a risk that be using /64 somebody can eat away a lot of memory by either scanning or even changing addresses. This is also described in the draft above...
I would personally recommend to at least always assign the /64, even if you would decide to configure the /127. RFC 3627 has been around long enough that you will keep running into equipment or software that won't like the /127. In which case you can always revert back to /64.
This will also allow you to use easy to remember addresses like ::1 and ::2, saving you the headache of a lot of binary counting.
Grtx,
Marco
Not only, there are some other advantages of using /126's, like reducing
number of ND requests on the link and the size of neighbor tables.
this results in -very- sparse matrix allocation - which is fine, as long as you believe that
you'll never run out/make mistakes. personally, i've use /126 for the past 12 years w/o any
problems.
there was never supposed to be a hard split at /64 - it was done as a means to simplify autoconfig.
--bill
Lasse,
draft-ietf-6man-prefixlen-p2p-01 provides some insights.
Ron
Lasse,
We use /112's – last chazwazza being 65k addresses… Requires little effort in remembering the ranges…. With one end being :1 and the other :F
This leaves more than enough addresses for HSRP/VRRP and all the other things like it. Also means we can introduce addressing on the link for diagnostics quite easily.
We actually use the /96 of 1C (to mean 1nterConnect) - makes it recognisable to engineering staff.
There is the issue of the pingpong affect, but I'm hoping vendors (if they haven't already) will introduce features to protect against it when (if) they implement RFC4443.
...Skeeve
There isn't an increased mistake risk factor using /126 out of a /64 assigned and your mistake factor probably slightly increases just assigning a bunch of /126 out of a single /64. We use /126 internal links, /128 loopbacks (these we do streamline), and customer links are generally /64, as currently we have no choice but use SLAAC + DHCPv6 (thanks Cisco!).
That being said, while renumbering my network, I noted several link address mistakes. Had nothing to do with the /126 or /64 boundaries. I just left out one of the nibblet sets, and :: notation gladly makes that into a valid address. This leads me to believe that using short hand is likely to lead to more mistakes.
Jack
The only advantage of a 126-bit prefix is if you're using it to take
advantage of the short address, and keep all your point-to-point
networks in the same address space so that you can easily identify
them.
This is really only personal preference for network engineers who may
not want to be dependent on DNS and like to have key link addresses
committed to memory (we're only human, after all).
Example:
Prefix: 2001:DB8::/32
2001:DB8::4/126 (or 2001:DB8::5 and 2001:DB8::6)
2001:DB8::8/126
2001:DB8::B/126
etc.
Though, you could accomplish almost the same thing with using a 64-bit
prefix length:
2001:DB8:1::/64 (or 2001:DB8:1::1 and 2001:DB8:1::2
2001:DB8:2::/64
2001:DB8:3::/64
That said. By not using the 64-bit boundary you may be sacrificing
performance optimizations with today's processors that lack operations
for values larger than 64-bits.
Either way is acceptable and is simply a matter of personal
preference. Link networks do not contain a dynamic number of hosts,
so logically there is no reason to accommodate more addresses than
they originally call for.
RFC 3627 recommends against using a 127-bit prefix-length due to
potential (implementation specific) problems with DAD, and that is
enough reason to avoid it for most people.
Nobody is right. Nobody is wrong. It's just preference.
We have a lot of link networks and opted early on to make use of
126-bit prefixes for them because that worked nicely for our
allocation schema.
Doh,
I meant the /80 of 1C for interconnects.
xxxx:xxxx:zz::1C:YYYY:1 and :F in a /112
...Skeeve
All of the (mostly religious) arguments about /64 versus any
smaller subnets aside, I'm curious about why one would choose
/126 over /127 for P-to-P links? Is this some kind of IPv4-think
where the all-zeros and all-ones addresses are not usable
unicast addresses? This isn't true in IPv6 (of course, it's not
strictly true in IPv4 either). Is there another reason?
Actually makes it pretty clear.
It's IPv6 think where the subnet-router anycast address is the prefix
followed by all zeros.
So, while IPv6 does not reserve the all-ones address, the all-zeroes
address is still reserved.
Owen
RFC 6164 - Using 127-Bit IPv6 Prefixes on Inter-Router Links
All of the (mostly religious) arguments about /64 versus any
smaller subnets aside, I'm curious about why one would choose
/126 over /127 for P-to-P links?
see above
randy
Is this an issue for any known vendors today?
All of the (mostly religious) arguments about /64 versus any
smaller subnets aside, I'm curious about why one would choose
/126 over /127 for P-to-P links? Is this some kind of IPv4-think
where the all-zeros and all-ones addresses are not usable
unicast addresses? This isn't true in IPv6 (of course, it's not
strictly true in IPv4 either). Is there another reason?
I setup a p2p /127 link and found that BGP would not peer over the link;
Changing to /126 resolved the problem. I never looked into it further
because I had intended to use /126 from the start. My guess is that
while BGP should be a unicast IP, Cisco's implementation uses an anycast
in some cases, disregarding the configured unicast address.
Just one practical example...
I setup a p2p /127 link and found that BGP would not peer over the
link;
on whose equipment and image?
randy
This was with a cisco 7200 - IOS 12.4 over a HE tunnel. Debugging BGP
showed no activity until the interface mask was changed, as if BGP was
not active and was not attempting to peer. The remote peer's state would
only display as IDLE. After changing the interface mask to /126 peering
came up instantly and I did notice some BGP logging that related to the
0 address on the network.
....
I setup a p2p /127 link and found that BGP would not peer over the link;
Changing to /126 resolved the problem. I never looked into it further
because I had intended to use /126 from the start. My guess is that
while BGP should be a unicast IP, Cisco's implementation uses an anycast
in some cases, disregarding the configured unicast address.Just one practical example...
I suspect this is very platform/version specific, as I have run BGP
on a Cisco 6500 (SXI<mumble>) to a Juniper MX and we had no
trouble with a /127 (although prepared to move to a /126 or whatever
if needed). As always, your environment will vary. I would open
a TAC case on the principal that it should work.
I setup a p2p /127 link and found that BGP would not peer over the
link;on whose equipment and image?
This was with a cisco 7200 - IOS 12.4 over a HE tunnel.
/me suspects tunnel
Sprint runs a /127 for my dual stack circuit with BGP; I know their side
is Cisco as is mine.
~Seth