Re: IPv6: numbering of point-to-point-links
Thank you all for your comments - it appears that there is no consensus on how this should be done. Thank you for the reference to this draft, Marco - and to Ron as well. Both RFC3627 and this draft appears to be stating that these issues a implementation-specific. E.g. whether an implementation will perform subnet-router-anycast on a small subnet, whether Neighbor-Discovery-messages are rate-limited etc. Does anyone have any information on how different vendors handle this - even in older software? /126 appears to be the middle path - which is reserving the subnet-router-anycast address while keeping the subnet as small as possible. This appears to address both issues - at least for Ethernet links. (one free address will hardly constitute a potential Neighbor Cache Exhaustion issue). Best regards, /Lasse -----Oprindelig meddelelse----- Fra: Marco Hogewoning [mailto:mch-nanog@xs4all.nl] Sendt: 24. januar 2011 14:11 Til: Lasse Jarlskov Cc: nanog@nanog.org Emne: Re: IPv6: numbering of point-to-point-links
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 https://datatracker.ietf.org/doc/draft-ietf-6man-prefixlen-p2p/
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
On Tue, Jan 25, 2011 at 9:44 AM, Lasse Jarlskov <laja@telenor.dk> wrote:
Thank you all for your comments - it appears that there is no consensus on how this should be done.
The best piece of advice I received when asking similar questions in the past is to allocate a /64 for every network regardless of it's potential size. Loopbacks, point-to-point, hosting VLANs etc. Then assign whatever size you are currently comfortable with. We've used /128s for loopbacks, safe in the knowledge that we can expand them all to /64s without renumbering (in case someone comes up with a good idea why /64s on loopbacks are necessary.) We've gone unnumbered on point-to-points, as a way of deferring that particular decision. Admittedly this reduces useful diagnostics available from traceroutes, although I quite like seeing loopbacks in traceroutes anyway. Unnumbered does reduce control-plane address space surface, which might be seen as a useful benefit (I'm sure someone will tell me why that's a bad idea.) My point is, if you do your number plan right, you should have some flexibility to make changes in the future without pain. -- Tim:>
participants (2)
-
Lasse Jarlskov -
Tim Durack