Re: IPv6 delivery model to end customers

[Jack Bates <jbates () brightok net>]

If you didn't see it in last thread, 
http://geekmerc.livejournal.com/699.html may provide some information 
for you, but I can tell from your concerns that your current choice of 
edge layouts is different than mine. As such, more below.

Mikael Abrahamsson wrote:
> 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.

Unnumbered vlans and RBE support on cisco, I guess could be considered 
forced forwarding in layer 2. It definitely makes for beautifully long 
configurations and severely limits dslams to support enough vlans for 1 
vlan per port, preferably with q-in-q. It also had the benefit of 
separation of responsibility, as telco could play with dslams (atm or 
vlans) and networking played with routers where tracking/policing was 
implemented.

Of course, moving away from ATM terminated systems seems to be the big 
deal, and not all systems support massive vlan terminations. I believe 
the vendors said, "Why on earth would you want to do that! It's like 
replicating pvc's!" Those vendors do cute things in their dslams such as 
dhcp snooping and limiting broadcast domains. IPv6 changes this from 
broadcast domains to multicast. Luckily, thanks to triple play, most of 
these same dslams also understand multicast and do igmp snooping. Adding 
support for multicast RA snooping is considered trivial by most, which 
is why they haven't bothered with it yet.

> 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.
Why not? They "sniff" igmp. What's the difference? Multicast is already 
commonly supported by most dslam manufacturers using flat topology.

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

I suggest heavy testing of this. I'm not sure that CPE's will be happy 
about doing PD requests without having received a prefix/IP for the 
interface. It'll also create create problems for traceroutes. ;)

The other option that is extremely simple is statically assign /64 to 
each port and then if they do PD, insert the route and do anti-spoofing. 
This is, btw, what RBE sorta does with IPv6 in atm world.

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

I'll agree that I haven't seen the necessary support by vendors for what 
should be trivial to change as mentioned above. One reason I took the 
headache of treating vlans like pvcs is lack of uniform support at layer 
2 for security policies. Vlans, though. Simple. They either support the 
required number, or they don't.

> 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.
Depends on the L2 device and how it's configured to deal with multicast. 
If you didn't think about multicast when deploying, then IPv6 is doing a 
service by reminding people that it exists. ;)

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

Vendors are the ones who are behind. Talk to yours. Multicast is simpler 
to manage in L2 than broadcast. As to the support by vendors, that's 
another question. I can't say I've been impressed with the overall 
vendor support. On the other hand, I'm the first to order equipment I 
didn't like to begin with into the trash due to no IPv6 support. ;)

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

Hate Teredo, and 6to4 rarely works due to the billions of home routers. 
The best one can hope for is securing down to the edge and customers 
eventually will have to buy a new home router to get their IPv6. (Most 
cheapy routers on the market now have 2MB flash. The current images for 
download are ususally about 1.8MB in size. I don't see 2MB flash routers 
supporting the additional overhead of IPv6 support.)


Jack