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

Owen DeLong owen at delong.com
Wed Nov 30 20:13:30 UTC 2011


On Nov 30, 2011, at 9:10 AM, Ray Soucy wrote:

> Owen and I have gone back and fourth over the year(s) as well.
> 
> I think it really comes down to Owen's adamant belief that _every_
> network should be a 64-bit prefix, and that SLAAC should be used for
> addressing, because it's simple and people will only adopt IPv6 if
> it's simple.  The whole neighbor table exhaustion problem undermines
> that case he's trying to make, so he tries to dismiss it as a
> non-issue.  It's nothing specific to Owen, it's basic human behavior.
> 

I've never said SLAAC should be used for addressing. I have said
that SLAAC is useful in many situations and can be a good tool.
I have consistently said that administrators should be free to
choose the addressing mechanism that work best for their 
environments.

I do believe that there is no benefit to longer prefixes than /64.
Nobody has provided any convincing evidence to the contrary.

There are better ways to mitigate ND than longer prefixes.

> I've always held the view that telling people IPv6 is simple is a lie
> and harmful to IPv6 adoption for a few reasons:
> 
> If people think IPv6 is simple, they don't bother investing time to
> plan out adoption and a phased deployment; they assume that when they
> need it they can just turn it on.
> 

I don't believe I've said IPv6 is simple. I've said that IPv6 is easier
than IPv4. It is. You don't have to worry about many of the common
difficulties with IPv4 (NAT, address conservation, subnet rightsizing,
etc.).

> If IPv6 isn't at least as flexible as IPv4, and can't fit in the same
> operational model used for IPv4 today; then it will never be adopted.

I would argue that IPv6 is more flexible than IPv4, but, it does require
changes to some IPv4 operational models. IP didn't fit the same operational
model as IPX, yet we made the transition from IPX to IPv4, so, I don't
buy into your idea that it won't be adopted if it doesn't fit the same
operational models.

Some operational models for IPv4 are obsoleted by IPv6. Such is the
nature of protocol change.

> Saying it's simple and "redesign your network" makes most people turn
> away from IPv6 and hope that something better will come along.
> 

I wouldn't say redesign your network so much as design your IPv6
network. In some cases, keeping in mind your IPv4 topology is useful.
In some cases, moving beyond the limitations under which your IPv4
topology was constructed is very beneficial in IPv6.

For example, common scenario in enterprise IPv4 is a single
link with half a dozen or so /28s on it as the server farm grew.
There's no reason not to make that a single IPv6 /64 while still
leaving all those different IPv4 networks in place. There's no
benefit whatsoever to allocating half a dozen IPv6 prefixes or
sizing them to some /120 or whatever.

> The future of IPv6 for most organizations will include:
> 
> DHCPv6 for stateful address assignment.

I've never argued against DHCP usage.

> NPT (Network Prefix Translation) and ULA address space internally (not
> NAT, but operationally identical); with load balancing between public
> allocations much like "dual WAN" SMB firewalls available for IPv4
> (after all, having every SMB in the BGP table is not something that
> any of us want to see).

I'm not as convinced as you are of this.

> Eventual use of NAT-PT and ALG for providing access to the legacy IPv4
> Internet without having to operate a dual-stack network internally
> (once there is enough IPv6-enabled content so that you're only
> breaking some things by doing so).

Remains to be seen whether it will be NAT-PT, NAT64, NAT444, IVI,
or something else for this. I'm not convinced that the enterprise will
be where IPv4 is deprecated first. In fact, I suspect it is likely to be
one of the last places to move from dual-stack to IPv6-only as you
describe.

> We won't see widespread adoption of IPv6 until we have a product
> people can buy in appliance form that can do these things, along with
> providing the typical functionality of an SMB firewall.

Time will tell. I suspect that if no such product is made available, it will
not prevent widespread deployment of IPv6.

> It seems a little silly that we're still having arguments about using
> 64-bit prefix lengths instead of focusing on how to move IPv6 to a
> position where it can be operationally identical to the way networks
> are run today and then promote adoption.

Some of us don't want to do that kind of damage to IPv6.

As such, I prefer to deploy IPv6 as it is today and resolve the bugs
and the security issues along the way (much like we did with IPv4).
IPv6 can be operationally similar, but, making it operationally
identical would take away many of its benefits.

> You just can't tell people to turn on IPv6, ignore the security
> concerns, ignore the operational differences, and suck it up and
> forklift their network.  It's not going to happen.

I've never said forklift your network or ignore the operational differences.

In fact, I've said embrace the operational differences and celebrate the
fact that you don't have to deal with NAT any more. Enjoy simplified
address planning with massive headroom.

I haven't said that security issues should be ignored, either. Just that
they should be viewed in a proper context and assessed with a realistic
evaluation of the magnitude of the risk and the difficulty of mitigation.
The magnitude of risk is defined in terms of the probability of an event
combined with the damage caused by such an event.

What has also been lost here is that my description of the various
mitigation tactics for ND exhaustion attacks depends on the type
of network being protected. Strategies that work for point-to-point
links (simple ACLs at the borders in most environments, for
example) are not the same as strategies that work to protect
client LANs (stateful firewalls with default deny inbound) or
strategies necessary to protect server LANs (slightly more complex
ACLs and other tactics).

Owen






More information about the NANOG mailing list