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

Wed Nov 30 17:10:21 UTC 2011

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 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.

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.

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

The future of IPv6 for most organizations will include:

DHCPv6 for stateful address assignment.

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).

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).

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.

Period.

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.

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.

On Wed, Nov 30, 2011 at 11:39 AM, Jeff Wheeler <jsw at inconcepts.biz> wrote:
> On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy <rps at maine.edu> wrote:
>> 1. Using a stateful firewall (not an ACL) outside the router
>> responsible for the 64-bit prefix.  This doesn't scale, and is not a
>> design many would find acceptable (it has almost all the problems of
>> an ISP running NAT)
>
> Owen has suggested "stateful firewall" as a solution to me in the
> past.  There is not currently any firewall with the necessary features
> to do this.  We sometimes knee-jerk and think "stateful firewall has
> gobs of memory and can spend more CPU time on each packet, so it is a
> more likely solution."  In this case that does not matter.  You can't
> have 2^64 bits of memory.
>
> You could make a firewall with the needed features (or a layer-3
> switch), but it would have to be the layer-3 gateway of the subnets
> you are protecting (not an upstream device) and it would need
> knowledge of all addresses in use on the subnet, which must fit within
> its ND table limits.  Only DHCP snooping can do this and customers are
> not exactly keen on receiving DHCP-assigned addresses in mixed
> datacenter environments, even if the addresses are static ones.  Once
> you do that, you need to limit the number of addresses that can be
> leased to each customer to far less than a /64 anyway.  All you gain
> by having all that complexity is the appearance of bigger subnets,
> when in reality, they are non-functional except for the limited number
> of addresses which are actively leased out.
>
> Again the arguments for /64 are not promising.  It is much less
> complicated to simply deploy a longer subnet.
>
> On Wed, Nov 30, 2011 at 11:13 AM, Jimmy Hess <mysidia at gmail.com> wrote:
>> On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy <rps at maine.edu> wrote:
>>> Saying you can mitigate neighbor table exhaustion with a "simple ACL"
>>> is misleading (and you're not the only one who has tried to make that
>>> claim).
>>
>> It's true, though, you can.
>>
>> From a network design POV, there may still be reasons to prefer the ACL method.
>> They better be good reasons, such as a requirement for SLAAC on a large LAN.
>
> No, Jimmy, you can't do that with SLAAC.  I do not think you
> understand the problem.
>
> --
> Jeff S Wheeler <jsw at inconcepts.biz>
> Sr Network Operator  /  Innovative Network Concepts
>

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/