Every time I see this question it' usually related to a fundamental misunderstanding of IPv6 and the attempt to apply v4 logic to v6. That said. Any size prefix will likely work and is even permitted by the RFC. You do run the risk of encountering applications that assume a 64-bit prefix length, though. And you're often crippling the advantages of IPv6. But in terms of the "best practice" it is indeed 64-bit for every network, with the option of 126-bit prefixes for link networks and 128-bit loopback addresses. You should think of IPv6 as a 64-bit address that happens to include a 64-bit host identifier. The entire point of IPv6 having a 128-bit address space was to facilitate this and put an end to having to determine the network prefix length based on an (often incorrect) estimation of the number of hosts the network will need to accommodate. Use of 126-bit prefixes for point-to-point connections (link networks) is acceptable. Use of 127-bit prefixes should be avoided as outlined in RFC 3627. So it really comes down to keeping it simple. Remember, we're dealing with exponentials here. A 64-bit address space isn't twice as large as a 32-bit address space; it's roughly 4.2 billion times larger. The 340 undecillion (that's 340 with 36 zeros after it) unique identifiers available with a 128-bit address space is blatantly excessive if you don't factor in that the host segment is always intended to be 64 of those bits. So if conservation of address space isn't the logic behind using a smaller prefix, then the question becomes what is? Most people tunnel-vision on the fact that Stateless Address Auto-Configuration requires that a 64-bit prefix be advertised to work and assume that the best way to disable it is to use a prefix-length other than 64. While you could do this, a far better way would be to simply not announce the prefix with the Autonomous bit set to true. Every IPv6 implementation respects the value of the "A" bit on a prefix advertisement and will not use Stateless configuration if it is not true, just as outlined in the RFC. Another thing to consider is that most processors today lack operations for values that are larger than 64-bit. By separating the host and network segment at the 64-bit boundary you may be able to take advantage of performance optimizations that make the distinction between the two (and significantly reduce the cost of routing decisions, contributing to lower latency). Many cite concerns of potential DoS attacks by doing sweeps of IPv6 networks. I don't think this will be a common or wide-spread problem. The general feeling is that there is simply too much address space for it to be done in any reasonable amount of time, and there is almost nothing to be gained from it. But yes. Basic NDP, routing, forwarding, etc. should work fine with anything shorter than 126. Just not really sure the logic behind doing so. On Mon, Jan 24, 2011 at 7:59 AM, Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> wrote:
The subject says it all... anyone with experience with a setup like this ?
I am particularly wondering about possible NDP breakage.
cheers!
Carlos
-- -- ========================= Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =========================
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/