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@swm.pp.se
On 7/02/2009, at 8:45 PM, Mikael Abrahamsson wrote:
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.
It is worth noting that this problem does not require you to start sending RA messages - this is a problem as soon as one customer is listening to RA messages. The problem may very well exist right now. -- Nathan Ward
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
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@swm.pp.se] Sent: Saturday, February 07, 2009 2:45 AM To: nanog@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@swm.pp.se
On Sat, 7 Feb 2009, John Lee wrote:
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.
My ADSL2+ design I did in 2002-03 or so, used one vlan per customer in the DSLAM (first version was 1U 24 port ADSL L2 ethernet DSLAM, second generation was chassis based ADSL2+ DSLAM did 1024 vlans and had ~800 ADSL2+ ports), vlans aggregated with an L3 switch doing GigE with the DSLAM, and one IP address per vlan (L3 switch was RFC3069 capable), no DHCP just statically provisioned when doing customer delivery. Worked great. Quite cheap as well. DSLAM was basically a L2 PVC->VLAN and PHY media converter. But I wasn't talking (A)DSL. DSL is last century. I am talking VDSL2/ETTH. Security model there is to only have ethernet and IP, no PPP/ATM, no L2TPv3 or PPPoE. Let's skip the terms BRAS/LNS etc. Anything that terminates tunnels is expensive (apart from GRE/IPV6IP which the 7600 seems to do very well, but I don't like tunnels. I like native). Most of the ETTH ports are 10/10, 100/10 or 100/100 (or even higher speeds) and 100/10 costs ~30 USD a month. L2TPv3/PPPoE is not an option. So, we have ~500k ports in my 9 million inhabitants country which are done via L2 switches in basements with CAT5/6 or fiber to the home. They use the security model I talked about before which I didn't really see a mention of in the list of IPv6 supported access models you listed. There are probably many millions more in Asia with the same model.
IMHO rolling out IPv6 to the customer is a business decision now not a technical one.
Well, I want to be able to do IPv6 at close to the same cost and security as I do IPv4 today. In your BRAS/LNS world it might be easy, but that's not the world I live in. -- Mikael Abrahamsson email: swmike@swm.pp.se
Yes it was definitely last century. With your 30 USD per port and no tunnels poses some interesting challenges. Customer CPE tunnel access was the main method discussed in the different v6 meetings I attended. I appreciate you bringing up this set of requirements since it needs to be addressed for fuller deployment of IPv6 to residential customers. John ________________________________________ From: Mikael Abrahamsson [swmike@swm.pp.se] Sent: Saturday, February 07, 2009 1:12 PM To: John Lee Cc: nanog@nanog.org Subject: RE: IPv6 delivery model to end customers On Sat, 7 Feb 2009, John Lee wrote:
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.
My ADSL2+ design I did in 2002-03 or so, used one vlan per customer in the DSLAM (first version was 1U 24 port ADSL L2 ethernet DSLAM, second generation was chassis based ADSL2+ DSLAM did 1024 vlans and had ~800 ADSL2+ ports), vlans aggregated with an L3 switch doing GigE with the DSLAM, and one IP address per vlan (L3 switch was RFC3069 capable), no DHCP just statically provisioned when doing customer delivery. Worked great. Quite cheap as well. DSLAM was basically a L2 PVC->VLAN and PHY media converter. But I wasn't talking (A)DSL. DSL is last century. I am talking VDSL2/ETTH. Security model there is to only have ethernet and IP, no PPP/ATM, no L2TPv3 or PPPoE. Let's skip the terms BRAS/LNS etc. Anything that terminates tunnels is expensive (apart from GRE/IPV6IP which the 7600 seems to do very well, but I don't like tunnels. I like native). Most of the ETTH ports are 10/10, 100/10 or 100/100 (or even higher speeds) and 100/10 costs ~30 USD a month. L2TPv3/PPPoE is not an option. So, we have ~500k ports in my 9 million inhabitants country which are done via L2 switches in basements with CAT5/6 or fiber to the home. They use the security model I talked about before which I didn't really see a mention of in the list of IPv6 supported access models you listed. There are probably many millions more in Asia with the same model.
IMHO rolling out IPv6 to the customer is a business decision now not a technical one.
Well, I want to be able to do IPv6 at close to the same cost and security as I do IPv4 today. In your BRAS/LNS world it might be easy, but that's not the world I live in. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Sat, 7 Feb 2009, Mikael Abrahamsson wrote:
But I wasn't talking (A)DSL. DSL is last century. I am talking VDSL2/ETTH. Security model there is to only have ethernet and IP, no PPP/ATM, no L2TPv3 or PPPoE. Let's skip the terms BRAS/LNS etc. Anything that terminates tunnels is expensive (apart from GRE/IPV6IP which the 7600 seems to do very well, but I don't like tunnels. I like native). Most of the ETTH ports are 10/10, 100/10 or 100/100 (or even higher speeds) and 100/10 costs ~30 USD a month. L2TPv3/PPPoE is not an option.
I may be missing something. "only have ethernet and IP". Why is plain-ethernet with each subscriber provisioned in a separate router's vlan subinterface insufficient? There is no security issue because each subscriber only sees its own traffic. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Mon, 9 Feb 2009, Pekka Savola wrote:
I may be missing something. "only have ethernet and IP". Why is plain-ethernet with each subscriber provisioned in a separate router's vlan subinterface insufficient? There is no security issue because each subscriber only sees its own traffic.
It's rare that this is the way it's done. Most ETTH deployments I know use one of these deployment scenarios: 1. One vlan per customer (not so often) plus uRPF like behaviour. 2. Shared broadcast domain with L2 devices doing one or several of: 2.1 Forced forwarding towards router. 2.2 ARP inspection 2.3 DHCP server protection (stops customers from running DHCP server) 2.4 Spoofing filters by means of DHCP snooping (both L2 and L3) 2.5 STP root guard 2.6 MAC rewrite 2.7 Ethertype filtering Plus more I can't think of right now. It's scenario 2 I'm worried about, all those machanisms haven't been implemented for IPv6 as far as I know and if you're only doing 2.2-2.5 then you're open to the IPv6 security issue I described. -- Mikael Abrahamsson email: swmike@swm.pp.se
It's scenario 2 I'm worried about, all those machanisms haven't been implemented for IPv6 as far as I know and if you're only doing 2.2-2.5
then you're open to the IPv6 security issue I described.
We've been seeing problems with this for the last year or so (since Vista started showing up). Since we run an academic network, we don't have as much control over hosts as you would see in a corporate setting. We've started poking Cisco about some key IPv6 support that we really need to move forward. A big one is a solution to address the security concerns with IPv6 RA (Router Advertisement) and rogue DHCPv6. On IPv4 networks we have the option of using DHCP snooping to suppress unauthorized DHCP servers from handing out address information. With IPv6, any host can announce itself as a router (using RA) and make network traffic suddenly start making use of it as the router for a network. This makes it possible for hosts to inadvertently disrupt network service (Vista) or even be used maliciously to perform a man-in-the-middle attack to intercept your traffic. Similarly with DHCPv6 there is nothing stopping a host from trying to hand out stateful IPv6 address configuration. Even worse is that since modern hosts give traffic priority to IPv6, it becomes easy for a rogue host (Vista) to advertise itself as an IPv6 router on IPv4-only networks. So there are security concerns even for networks that do not run IPv6 here. I think it goes without saying that this needs to be addressed before IPv6 can be deployed on most campus networks where users manage their own PC's. So Cisco (and other vendors) needs to introduce two things for LAN switching. DHCPv6 snooping, and more importantly, RA suppression (or RA snooping). As far as IPv6 deployment to residential customers... I say most things these days are moving to Metro Ethernet. Give ea. customer a VLAN, that will save you a lot of headache and ultimately provide a better experience for the customer. Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
On Monday 09 February 2009 10:21:24 pm Soucy, Ray wrote:
So Cisco (and other vendors) needs to introduce two things for LAN switching. DHCPv6 snooping, and more importantly, RA suppression (or RA snooping).
For IOS, have you tried the command: int gi0/1 ipv6 nd ra suppress Cheers, Mark.
So Cisco (and other vendors) needs to introduce two things for LAN switching. DHCPv6 snooping, and more importantly, RA suppression (or RA snooping).
For IOS, have you tried the command:
int gi0/1 ipv6 nd ra suppress
That stops your router from sending any RAs. Does nothing to prevent someone else from sending them, and becoming the default gateway for every IPv6 capable host on that link ...
A big one is a solution to address the security concerns with IPv6 RA (Router Advertisement) and rogue DHCPv6. On IPv4 networks we have the option of using DHCP snooping to suppress unauthorized DHCP servers from handing out address information. With IPv6, any host can announce itself as a router (using RA) and make network traffic suddenly start making use of it as the router for a network. This makes it possible for hosts to inadvertently disrupt network service (Vista) or even be used maliciously to perform a man-in-the-middle attack to intercept your traffic. Similarly with DHCPv6 there is nothing stopping a host from trying to hand out stateful IPv6 address configuration.
Even worse is that since modern hosts give traffic priority to IPv6, it becomes easy for a rogue host (Vista) to advertise itself as an IPv6 router on IPv4-only networks. So there are security concerns even for networks that do not run IPv6 here.
I think it goes without saying that this needs to be addressed before IPv6 can be deployed on most campus networks where users manage their own PC's.
So Cisco (and other vendors) needs to introduce two things for LAN switching. DHCPv6 snooping, and more importantly, RA suppression (or RA snooping).
Indeed, this is a problem. RA Guard is a very straight-forward, hopefully soon-to-be-widely-supported, defense. http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 A "pure layer 3" solution is, of course, SEND/CGA ... where deployment concerns/problems abound ... http://tools.ietf.org/html/rfc3971 & http://tools.ietf.org/html/rfc3972 And as I may have said once or thrice already, YES - I agree these solutions should have been developed / made deployable long before now.
As far as IPv6 deployment to residential customers... I say most things these days are moving to Metro Ethernet. Give ea. customer a VLAN, that will save you a lot of headache and ultimately provide a better experience for the customer.
Amen to that ...
Indeed, this is a problem. RA Guard is a very straight-forward, hopefully soon-to-be-widely-supported, defense. http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01
Thanks for pointing us to this. It's encouraging to know that it is being worked on. Ray
http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-01 Thanks for pointing us to this. It's encouraging to know that it is being worked on.
My pleasure, now everyone - feel free to ring up your local sales/support rep and "encourage" their product to implement this ... please! /TJ
On Mon, 9 Feb 2009, TJ wrote:
My pleasure, now everyone - feel free to ring up your local sales/support rep and "encourage" their product to implement this ... please!
What about "DHCPv6 / DHCPV6-PD" sniffing (and using that info to create L3 filter rules in L2 devices), is a standard needed or is it obvious to vendors how to implement it? -- Mikael Abrahamsson email: swmike@swm.pp.se
My pleasure, now everyone - feel free to ring up your local sales/support rep and "encourage" their product to implement this ... please!
What about "DHCPv6 / DHCPV6-PD" sniffing (and using that info to create L3 filter rules in L2 devices), is a standard needed or is it obvious to vendors how to implement it?
An analogy to "DHCP Guard" - yes, please do encourage them to also do this. (And an RFC might not be a bad idea ... ) While we are at it - MLD Snooping should (IMHO) be a switch's default behavior as well!
On Feb 10, 2009, at 9:01 AM, TJ wrote:
My pleasure, now everyone - feel free to ring up your local sales/support rep and "encourage" their product to implement this ... please!
What about "DHCPv6 / DHCPV6-PD" sniffing (and using that info to create L3 filter rules in L2 devices), is a standard needed or is it obvious to vendors how to implement it?
An analogy to "DHCP Guard" - yes, please do encourage them to also do this. (And an RFC might not be a bad idea ... )
While we are at it - MLD Snooping should (IMHO) be a switch's default
s/MLD/MLD v2/ Marshall
behavior as well!
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!
participants (9)
-
Jack Bates -
John Lee -
Mark Tinka -
Marshall Eubanks -
Mikael Abrahamsson -
Nathan Ward -
Pekka Savola -
Soucy, Ray -
TJ