nanog mailing list archives

RE: IPv6 delivery model to end customers


From: "TJ" <trejrco () gmail com>
Date: Sun, 8 Feb 2009 17:16:32 -0500

I didn't know where to jump in in the current discussion and what I wanted
to discuss was quite general, so I thought I'd create a new thread instead.

And the right move, IMHO! (FWIW)


So, anyone saying IPv6 is ready for prime-time whereever IPv4 is used, has
a
very simplified view of the world. Yes, IPv6 works in the classic routed
network model where everything is statically set up (often manually), for
example with an ISP run CPE and static/dynamic routing and a fixed /48
issued for that customer and SWIPed. Then it's easy to delegate reverse-DNS
etc to the customer DNS.

We would need to differentiate between the protocol being ready, and the
vendors' support of the protocol here.  
In other words, the ivory tower work is done - now it is up to the real
world.
Oh, and yes, in that "enterprise" deployment scenario we are almost ready!


<SNIP>
My ideal model would be to replace the above mentioned L2 device with a
small and simple L3 device (L3 switch) with very small TCAM (TCAM size 6-8
times port number should be enough), where this device uses link-local with
the CPEs (would require all customers to actually have a router at home),
hands out prefixes via DHCPv6-PD, inserts route towards customer link-local
address, provisions anti-spoofing ACLs on that port, logs what prefix was
given out to each port at what time, and off we go. (Rationale for link-
local only is to have only customer devices in "Customer IP space" and only
ISP infrastructure in that IP-space. This is equivalent to "ip unnumbered"
in IPv4 in my view.) I have pitched this idea in the IETF v6ops list and
it's now included in a draft that lists different models of
IPv6 delivery.

As far as I know, this IPv6 L3 device doesn't exist (in the pricerange
needed for massive residential roll-out anyhow).

While that sounds functional/useful, I would first ask - to the
residential-focused ISPs - how they currently plan (or how are they moving
towards) delivering IPv6 to their clients?


So, in the meantime, to get IPv6 to the end customers I see two ways
(because they need to fit into the IPv4 security model mentioned above).
We have either 6to4 tunneling (Cisco 7600 does this very well and code for
Linux CPEs exist already), or we try to fit IPv6 into the IPv4 security
model. Current recommendation from the swedish "city networks association"
(they consists mostly of entities running LANs to residential, I believe
there are approx 400-500k ports of that in Sweden at this time) is that if
you don't know if your network is secure against IPv6, block it at the
ethertype level (I'll come back to the security risks later).

6to4 works just fine, assuming you and your customers are OK with tunneling
and relays ... up until there are no more public IPs.  
Then you are talking about "A+P + 6to4" or somesuch.  *EVEN MORE FUN*


<SNIP>
So, what is the security problem with IPv6 in an IPv4 network? Well,
imagine
an IPv4 network where security is done via ARP inspection, DHCP snooping
and
L3 ACLs. Now, insert rogue customer who announces itself via
RA/DHCPv6 and says it's also DNS. Vista machines will get itself an IPv6
address via RA, ask for DNS-server via DHCPv6, so if the rogue customer can
do some NAT-PT like functionality, they are now man in the middle for all
the IPv4 traffic (because between the customers it's IPv6 and the L2 device
doesn't know anything about that). I don't know if this has actually been
done, but I see no theoretical problem with it, if someone can come up with
something, please do tell.

"RA Guard"; learn it, live it, love it.
At some point, maybe SEND/CGA as well ... but that isn't a "ready today"
thing.


So, my view on IPv6 is that I would love to roll it out to all residential
customers, but unfortunately all the development done for IPv4 security has
gone unnoticed by the people developing IPv6 and now it's behind and needs
to catch up, or pitch a different model and then get vendors to develop
products that do this.

I think that is a bit harsh - the work hasn't gone unnoticed.  
Rather, it has not been high enough on the list of priorities and is
therefore, yes, lagging. 


In the mean time, we do (and I encourage everybody else to do the same)
support 6to4 and Teredo, plus we do IPv6 native in the core and peering
where possible plus we give IPv6 to customers where we're able to securely
(mostly transit customers and corporate customers with IPv6 capable CPEs).

AMEN!



Current thread: