[147000] in North American Network Operators' Group
Re: IPv6 prefixes longer then /64: are they possible in DOCSIS
daemon@ATHENA.MIT.EDU (Ray Soucy)
Wed Nov 30 12:11:47 2011
In-Reply-To: <CAPWAtbJVXyg4xx77tvO5UASyLMhL8-OUkwA3dYawqDPx=0pO-Q@mail.gmail.com>
Date: Wed, 30 Nov 2011 12:10:21 -0500
From: Ray Soucy <rps@maine.edu>
To: Jeff Wheeler <jsw@inconcepts.biz>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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@inconcepts.biz> wrote:
> On Wed, Nov 30, 2011 at 9:48 AM, Ray Soucy <rps@maine.edu> wrote:
>> 1. Using a stateful firewall (not an ACL) outside the router
>> responsible for the 64-bit prefix. =A0This 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. =A0There is not currently any firewall with the necessary features
> to do this. =A0We 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." =A0In this case that does not matter. =A0You 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. =A0Only 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. =A0Once
> 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. =A0All 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. =A0It is much less
> complicated to simply deploy a longer subnet.
>
> On Wed, Nov 30, 2011 at 11:13 AM, Jimmy Hess <mysidia@gmail.com> wrote:
>> On Wed, Nov 30, 2011 at 8:48 AM, Ray Soucy <rps@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. =A0I do not think you
> understand the problem.
>
> --
> Jeff S Wheeler <jsw@inconcepts.biz>
> Sr Network Operator=A0 /=A0 Innovative Network Concepts
>
--=20
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/
