IPv6 prefixes longer then /64: are they possible in DOCSIS networks?

Thu Dec 1 00:19:51 UTC 2011

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 at 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 at 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/