I agree with pretty much everything Bill, Doug, and Nathan just said. Just remember "640K ought to be enough for anybody." ;-) It's usually unwise to make statements about "never needing more than" where technology is concerned. IPv6 is still in its "let's get people to use this" phase; I don't think any of us have a clue what kind of new innovation may or may not take place in a world where address space isn't a concern. I would say absolutely reserve 64-bit's per host network in your schema. Even though we talk about broadcast domains, IPv6 shifts the conversation to multicast (and can possibly do away with the need for L2 broadcasts at some point); eventually we might be able to scale these domains to much, much larger levels that previously imagined. 2^64 large? perhaps not, but several thousands or tens of thousands, probably. If we do see this kind of evolution; being able to easily bump your networks up to 64-bit will save you a lot of pain; in the meantime, if you don't need anything that a 64-bit prefix provides (e.g. SLAAC), then by all means, just use what you need. There is a lot of talk about "buggy" systems that are unable to handle prefixes longer than 64; but I've yet to encounter one. I imagine if I did it would be treated as a bug and fixed. So to the question of supporting different prefix lengths: Yes. You should support any valid IPv6 prefix length; it takes a few extra lines of code in the beginning; but will save you a lot of re-coding in the end. I think using DHCPv6 PD, and handing out 64-bit allocations for residential users, and even running SLAAC would work quite nicely. We have moved to a model where customers like having their own domain of control while keeping things simple, and this does that. At the same time; if an ISP wants to put all their customers in an area on a shared prefix, I'm not going to complain about that either. I'd rather have functional native IPv6 at my house than no IPv6 at this point (just let me have as many addresses as I need, please). The fear is that this will push consumers to continue the use of NAT instead of something more friendly like NPT; but if that's the way it is to be then so be it. Plenty of time for the different delivery models to compete and battle it out. I will say that people have gotten used to controlling their own security domain, and it might not be something they're OK with giving up, especially as the Home gets smarter (refrigerator, microwave, entertainment system, healing, lighting, etc. all with addresses). One thing I probably don't need to point out but will anyway, is that IPv6 as it is today is what we have to work with. It took 10 years to get mature OS support established, and likely another 10 to phase out the systems that don't support it. There are plenty of good debates to have on the number of bits for this and the number of nibblets for that; but you're not going to change the IPv6 implementation in any meaningful way at this point; so the debates over the fundamentals of the protocol aren't productive. We have a reasonable foundation to work with that should provide us with flexibility to grow over time, we just need to start implementing it (and developing the software systems to make it all easy). The tweaks will come over time; and vendors will be more inclined to care about them if it's actually being used. On a more productive note; now that we have the workings of IPv6 NAT, has anyone had a chance to play with it yet? I'm anxious to play with the NPT stuff, myself. I wonder how broken it is. ;-) On Wed, Nov 30, 2011 at 6:33 PM, Mark Blackman <mark@exonetric.com> wrote:
On 30 Nov 2011, at 23:02, Bill Stewart wrote:
On Wed, Nov 30, 2011 at 1:18 PM, Mark Blackman <mark@exonetric.com> wrote:
... and I'm not sure why SLAAC wanted more than 48 bits.
One reason IPv6 addresses are 128 bits long instead of 40, 48, 64 or 80 is because converting from IPv4 to IPv6 is really painful and we don't want to ever have to do it again in the future.
Sure, 128 bits I can see the point of. Rigid insistence on /64 subnets when no broadcast domain will ever have 2^64 devices on it seems like a less obvious choice.
- Mark
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/