IPv6 delivery model to end customers

Sat Feb 7 17:30:41 UTC 2009

Michael,

>From my work in access networks they are:

IPv6 native support for:

Routed Access - Ethernet or Wireless, global prefix under the main or dot1Q isl encapsulated sub-interfaces. 
For DSL and ATM PVCs routed RFC 2684 encapsulation with a different IPv6 prefix for each one of the PVCs.

Bridged Access - RFC 2684 where the user traffic reaches the access router over a bridged PVC.

PPP-Encapsulated IPv6 - PPPoA/IPv4 access was my favorite in the early days and finally moving in about 2004 or so to PPPoE (RFC 2516). Most DSL and Layer 2 providers that I used had PPPoA in their access network and then handed off to me as an ATM PVC with L2TP encapsulated user streams. PPPoE/PPPoA support both IPv4 and IPv6 packets natively.

SP can leverage their existing IPv4 access infrastructure by utilizing IPv6 over L2TPv2 or in deploying IPv6 natively to the CPE by utilizing L2TPv3.

My IPv4 only deployment in 2001 used DSLAMs that had limited number of active CPEs and DS3/T3 upstreams to the network. We used front end Fore/Marconi ATM switches in front of Redback aggregation switches connecting to Cisco 6509s and then GSR 12012s as the backbone routers. The Redback authenticated with RADIUS servers using CHAP.

The DSLAMs were upgrade over the next two to three years for larger number of CPE tributaries and optical (OC-3c and OC-12c) network uplinks. In my advancing years if memory serves in 2005/2006 timeframe (in the US) the CPE, DSLAMS, aggregation and other switches and routers supported IPv6.

Now you have both second and third generation support for IPv6 in these devices (Cisco, Juniper, et al) and rumor has it that Linksys and Netgear have IPv6 plans in their roadmaps or devices in their labs.

For PD and DHCPv6 there are other tools that allow much more control over IP address assignment and lifecycle control that I will not discuss here.

I am not slighting Cable here, I do not have the first hand experience with cable supporting IPv6.

IMHO rolling out IPv6 to the customer is a business decision now not a technical one.

John (ISDN) Lee

________________________________________
From: Mikael Abrahamsson [swmike at swm.pp.se]
Sent: Saturday, February 07, 2009 2:45 AM
To: nanog at nanog.org
Subject: IPv6 delivery model to end customers

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.

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.

Now, take for instance the residential LAN case. There are several models
on how to do this, but they all (that I know of) reside around the fact
that each customer gets one or more globally routed IP address via DHCP,
and security against spoofing and "man in the middle"-attacks is either
done via forced-forwarding in the L2 device the customer connects to, or
it's done via setting L3 accesslists learnt via DHCP snooping that inspect
L2-packets in that same device. Often both is done, and also things like
"ARP inspection", rogue dhcp server protection, MAC-rewrite etc is used.
These are essential security mechanisms because customers should be
protected from each other when it comes to these types of L2 attacks.
Tracability (who had what IP at what time) is done via DHCP option82 and
logging of this information. So, the L2 devices closest to the customer
does a lot of "magic". All of these mechanisms were developed in the first
half of the last decade.

Now, with IPv6 this model changes drastically. The proposed mechanisms for
IP number handout etc, is RA and DHCPv6. How does that fit into the model
above? It doesn't, and the L2 devices surely won't "sniff" it and enforce
security measures mentioned above.

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

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

So, how can we fit current IPv6 into the IPv4 security model? We can't.
Current L2 devices won't do any of the IPv6 security stuff needed, and
just turning on RA/DHCPv6 would make it work from a "let's move
packets"-aspect, but it wouldn't be secure (perhaps in some
forced-forwarding cases there might be a possibility of doing it securely,
but what devices will log what customer had what IP at what time when it's
done via RA?).

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.

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.

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

--
Mikael Abrahamsson    email: swmike at swm.pp.se