IPv6 is no longer considered optional(blog.bt.com)
blog.bt.com
IPv6 is no longer considered optional
http://www.blog.bt.com/viewpoint/index.php/2012/04/23/ipv6ietf/
58 comments
Its not clear what level of 'hardware' you are talking about.
For most gadgets, the only hardware related to networking you will find is a chip that does ethernet and talks to the jack for you. Everything above (like IP) is done in software.
For most gadgets, the only hardware related to networking you will find is a chip that does ethernet and talks to the jack for you. Everything above (like IP) is done in software.
I'm talking about routers, from the big devices in your datacentre/telco down to your dsl or cable home gateway. There's only a limited amount I can say about this ( at least, without having to think hard about I am allowed to say) but there really is a lot of silicon out there that knows what the layout of an IP packet is.
A NIC that talks ethernet doesn't mean it's in the hardware. It's more about the ASICs on the ports to handle high traffic rates. The NIC can send the packet on the wire, but inserting the IPv6 headers is done in hardware with ASICs. This is the difference between millions of packets per second versus tens of thousands.
I think firmware is considered part of the hardware in this instance.
Part of the problem with software is that there's so much of it. You don't just have the stuff running on routers, you've got your customer management system, logging + auditing, DNS etc.
There's no point in an ISP offering IPv6 if its routers support it but their back office management software doesn't.
There's no point in an ISP offering IPv6 if its routers support it but their back office management software doesn't.
Support as in "can process ipv6 traffic?" Or support as it "can process a volume of ipv6 traffic with performance and practical feature characteristics on par with its handling of ipv4 traffic?"
If you mean the former then sure, but that's not the point. The latter is what hampers adoption and I assure you, most hardware produced in the last 10 years does not support ipv6 to the degree that it does ipv4.
If you mean the former then sure, but that's not the point. The latter is what hampers adoption and I assure you, most hardware produced in the last 10 years does not support ipv6 to the degree that it does ipv4.
I mean the latter, but I'm talking about just the silicon, not the complete product produced by (say) a switch vendor, which perhaps explains the difference.
It's disingenuous to refer to unshipped silicon. If it's not available in vendor hardware it's hardly a "software problem."
You appear now to be saying "Chips exist, but vendors aren't building them into switches" which is a far cry from your original claim.
You appear now to be saying "Chips exist, but vendors aren't building them into switches" which is a far cry from your original claim.
No, he's saying "the chips are in the switches, but networking vendors may not have mature support in the operating system". Think Cisco IOS as an example of the software that has to support the protocol in addition to what the silicon can do.
Then that is a categorically untrue statement.
Perhaps he is thinking of one vendor (or more likely one particular model supplied by one vendor) in particular?
In any event, it is absolutely false that "all of the silicon out there" has feature and performance parity with ipv4.
Perhaps he is thinking of one vendor (or more likely one particular model supplied by one vendor) in particular?
In any event, it is absolutely false that "all of the silicon out there" has feature and performance parity with ipv4.
No, that is not what I wrote.
I wonder if a declaration like this will have any practical impact...
So now they consider it not optional? I guess it took so long because they were thinking ipv4 would magically generate more ip numbers... The internet should be all ipv6 by now.
Why do I get the feeling that there will never be a pure IPv6 solution.
It does not seem possible to create a pure and complete IPv6 NAT solution. But NAT is way too useful and taken for granted to be removed. I honestly cannot believe they did not address this specifically during the standard's process! Why not learn from the past?
Are Teredo-like 6-within-4 solutions the only future?
It does not seem possible to create a pure and complete IPv6 NAT solution. But NAT is way too useful and taken for granted to be removed. I honestly cannot believe they did not address this specifically during the standard's process! Why not learn from the past?
Are Teredo-like 6-within-4 solutions the only future?
> But NAT is way too useful and taken for granted to be removed
NAT is not useful, firewalls are.
NAT merely swaps an address for another in the outgoing IP packet, recording the connection, and doing the inverse op on incoming packets matching the record. It's actually called IP masquerading, and it does not protect you of anything.
Without a firewall rule that drops incoming packets, outside can readily reach your internal network with the proper route (your router already knows how to route external/internal, since it's its very role), even with NAT. The exact same incoming packet drop rule can readily be used with IPv6. And you can punch holes in the firewall for your internal services the same way you always did, you just don't need address swapping part anymore, nor "port forwarding", since all machines have all ports to them. In fact, the firewall stack actually gets two rules added each time you define a "port forwarding": the firewall rule to not drop the packet, and the NAT rule to forward it. Guess what forwards natively packets to the correct IPs? Routing. And that's precisely the purpose of NAT: being able to route IPs not meant to be routed in the first place, virtually extending the IP address space by having LAN machines sharing one address. The thing is, every IPv6 address is routable†, hence NAT simply has no purpose in IPv6.
The only real problem is that people have been framed to think that NAT is how things work. The truth is, having no NAT anymore is a bliss. Everything is easier, from DMZ routing to authorization to abuse handling, mostly because many issues, limitations, and extra work vanish.
PS: and don't start me on "NAT is good at using a single IP to connect to your machines". That's what DNS is for.
† except local-scoped addresses, but those are constrained to the link, since they are automatically assigned by the machine itself, and made to provide automatic peer-to-peer link-local connectivity only. By design, having only a link-local address means you have no internet connectivity whatsoever.
NAT is not useful, firewalls are.
NAT merely swaps an address for another in the outgoing IP packet, recording the connection, and doing the inverse op on incoming packets matching the record. It's actually called IP masquerading, and it does not protect you of anything.
Without a firewall rule that drops incoming packets, outside can readily reach your internal network with the proper route (your router already knows how to route external/internal, since it's its very role), even with NAT. The exact same incoming packet drop rule can readily be used with IPv6. And you can punch holes in the firewall for your internal services the same way you always did, you just don't need address swapping part anymore, nor "port forwarding", since all machines have all ports to them. In fact, the firewall stack actually gets two rules added each time you define a "port forwarding": the firewall rule to not drop the packet, and the NAT rule to forward it. Guess what forwards natively packets to the correct IPs? Routing. And that's precisely the purpose of NAT: being able to route IPs not meant to be routed in the first place, virtually extending the IP address space by having LAN machines sharing one address. The thing is, every IPv6 address is routable†, hence NAT simply has no purpose in IPv6.
The only real problem is that people have been framed to think that NAT is how things work. The truth is, having no NAT anymore is a bliss. Everything is easier, from DMZ routing to authorization to abuse handling, mostly because many issues, limitations, and extra work vanish.
PS: and don't start me on "NAT is good at using a single IP to connect to your machines". That's what DNS is for.
† except local-scoped addresses, but those are constrained to the link, since they are automatically assigned by the machine itself, and made to provide automatic peer-to-peer link-local connectivity only. By design, having only a link-local address means you have no internet connectivity whatsoever.
It's actually called IP masquerading
No, it's not. This is a Linux-specific term that is used nowhere else.
No, it's not. This is a Linux-specific term that is used nowhere else.
Indeed, the correct phrase would have been It's actually called IP masquerading under Linux. Whatever, the point was NAT is just about proxying by forging packets with another identity and putting it back when packets comes back, and 'masquerading' conveys the idea quite nicely.
I insist on forging because it is so, which makes ipsec puke since the packet changed unless you pile up yet some more hacks on top.
I insist on forging because it is so, which makes ipsec puke since the packet changed unless you pile up yet some more hacks on top.
The problem is that firewalling is difficult for the same reason that NAT is difficult.
For example: my SIP hardware phone has a publicly addressable IP address. I'd like to firewall it such that it can only talk to my ISP's SIP server and other parties authorised by it. How do I do this? The firewall must deep-packet inspect SIP packets to work out what point-to-point RTP traffic should be allowed, and only allow this. This difficulty does not change even in an IPv6 world.
I wrote about this problem last year: http://www.synctus.com/blog/2011/04/why-ipv6-will-not-solve-...
For example: my SIP hardware phone has a publicly addressable IP address. I'd like to firewall it such that it can only talk to my ISP's SIP server and other parties authorised by it. How do I do this? The firewall must deep-packet inspect SIP packets to work out what point-to-point RTP traffic should be allowed, and only allow this. This difficulty does not change even in an IPv6 world.
I wrote about this problem last year: http://www.synctus.com/blog/2011/04/why-ipv6-will-not-solve-...
> The problem is that firewalling is difficult for the same reason that NAT is difficult.
The problems you exemplify are not ipv4 or ipv6 problems, they are purely firewall problems. As you state in the article, people conflate NAT and firewall, but I fear you are too slightly mixing them in a way in your article (at least that's how it reads). NAT-PMP and UPnP are tools that do two things:
EDIT: actually the NAT-PMP draft[0] makes mention of IPv6
EDIT: a quick search for UPnP IGD IPv6 leads to a presentation[1] about IGD:2, which includes IPv6 gateway firewall control.
[0] http://files.dns-sd.org/draft-cheshire-nat-pmp.txt
[1] http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d10032...
The problems you exemplify are not ipv4 or ipv6 problems, they are purely firewall problems. As you state in the article, people conflate NAT and firewall, but I fear you are too slightly mixing them in a way in your article (at least that's how it reads). NAT-PMP and UPnP are tools that do two things:
- setup port forwarding for knowing where to NAT incoming packets
- setup firewall not to drop incoming WAN packets on that port
- setup firewall not to drop incoming WAN packets on that port and for that destination
EDIT: actually the NAT-PMP draft[0] makes mention of IPv6
EDIT: a quick search for UPnP IGD IPv6 leads to a presentation[1] about IGD:2, which includes IPv6 gateway firewall control.
[0] http://files.dns-sd.org/draft-cheshire-nat-pmp.txt
[1] http://www.upnp.org/resources/documents/UPnPIGD2vsIGD1d10032...
Yes, stateful firewalls are almost as much of a blight on the Internet as NATs are. The way it's "supposed" to work is for security to be handled by the endpoints (e.g. the SIP hardware phone). But that's a totally unrealistic goal because it makes it very difficult to do centralized administration of security policies. It's also rather undesirable when mobile devices are involved (you would like to stop unauthorized traffic before it enters a wireless network where it wastes precious bandwidth and battery life). We're just going to have to live with the problem.
> Without a firewall rule that drops incoming packets, outside can readily reach your internal network with the proper route (your router already knows how to route external/internal, since it's its very role), even with NAT.
That's true if by 'outside' you mean 'directly on the external interface of my home router'. Because if it can indeed route my 10.something/192.168.something internal network, all the routers in between most likely can't. Maybe that's why because think NAT is safer: firewall holes are, in practice, much harder to exploit in IPv4.
(Well, that, plus the firewall rules are much simpler. A few fixed ranges to drop, and be done with it. In IPv6, all has to be dynamic, and potentially configurable)
That's true if by 'outside' you mean 'directly on the external interface of my home router'. Because if it can indeed route my 10.something/192.168.something internal network, all the routers in between most likely can't. Maybe that's why because think NAT is safer: firewall holes are, in practice, much harder to exploit in IPv4.
(Well, that, plus the firewall rules are much simpler. A few fixed ranges to drop, and be done with it. In IPv6, all has to be dynamic, and potentially configurable)
Then what's protecting you is routing, not NAT itself.
'directly on the external interface of my home router' is my ISP. Do I trust my ISP/government/whoever-bugged-in-at-the-curb enough not to add some wide route and scan 10/8,192.168/16, then jump into my LAN? In fact I've done precisely the inverse: on the outward side of a previous ISP of mine lies both a globally routable IP address and a bunch of networks of theirs on some 10/8 range, with... interesting properties. Notably that 10/8 can SSH/telnet/web-admin as root into my ISP-provided router/modem. Maybe even with some additional trick I could reach to other subscribers, hack their modem and break into their LAN.
Nothing prevents you to drop outward packets whose source don't match your fixed (or DHCPv6) IP layout (e.g 2a01:whatever/126), since auto-configuration has stuff like ff:fe in the middle. Or you could leverage autoconf and drop packets from IPs not matching your list of MAC addresses. Also you can not send router advertisements nor respond to router sollicitations, or even filter out RA/RS packets, so that no autoconfiguration take place.
'directly on the external interface of my home router' is my ISP. Do I trust my ISP/government/whoever-bugged-in-at-the-curb enough not to add some wide route and scan 10/8,192.168/16, then jump into my LAN? In fact I've done precisely the inverse: on the outward side of a previous ISP of mine lies both a globally routable IP address and a bunch of networks of theirs on some 10/8 range, with... interesting properties. Notably that 10/8 can SSH/telnet/web-admin as root into my ISP-provided router/modem. Maybe even with some additional trick I could reach to other subscribers, hack their modem and break into their LAN.
Nothing prevents you to drop outward packets whose source don't match your fixed (or DHCPv6) IP layout (e.g 2a01:whatever/126), since auto-configuration has stuff like ff:fe in the middle. Or you could leverage autoconf and drop packets from IPs not matching your list of MAC addresses. Also you can not send router advertisements nor respond to router sollicitations, or even filter out RA/RS packets, so that no autoconfiguration take place.
Nothing prevents you to drop outward packets whose source don't match your fixed IP layout (e.g 2a01:whatever/126)
In fact, you should do this to prevent spoofing attacks from being sourced from inside your network.
In fact, you should do this to prevent spoofing attacks from being sourced from inside your network.
There is one other one that you missed for IPv6. ULA addresses are unique local addresses that are not automatically assigned and are assigned by the administrator. They can be routed, but not on the public internet (only on your internal network (in an office, in multiple offices, datacenter, etc)).
Those are not just for automatic peer-to-peer they are for assigning addresses on your network that can stay the same no matter if you change ISP's and they hand out a new /64 prefix to your network...
Those are not just for automatic peer-to-peer they are for assigning addresses on your network that can stay the same no matter if you change ISP's and they hand out a new /64 prefix to your network...
NAT as a security requirement can be replaced with a firewall. If you don't trust the firewall for some reason put in a second firewall. People got this notion that NAT is the only way to really secure an internal network. NAT is just an easy way to do default-deny, a firewall can also do it.
Maybe this question is stupid, but why do you consider NATs useful? I've always found them pretty obstructive (just look at Skype and other p2p software, they have to try and break through NATs or even use a proxy server). Or do you have other use cases in mind?
Laziness, flexibility and cost.
Lazy network admins assume that a private network protects them against poor planning and decision-making.
Private networks give you more flexibility to do whatever crazy thing you want to do. For larger enterprise, this may mean building their own private internet.
For smaller users in particular, NATing saves time and money. You don't have to wrangle with ISPs who want to bill by IP, or get an IP block assigned.
Lazy network admins assume that a private network protects them against poor planning and decision-making.
Private networks give you more flexibility to do whatever crazy thing you want to do. For larger enterprise, this may mean building their own private internet.
For smaller users in particular, NATing saves time and money. You don't have to wrangle with ISPs who want to bill by IP, or get an IP block assigned.
For larger enterprise, this may mean building their own private internet.
How does IPv6 change this? Either way, you have to use IP addresses assigned to you (public IPv6 addresses, or private IPv4 addresses) if you want to interface it to the public internet. Your physical firewall and router setup isn't going to change much, if at all.
If your private network will never be connected to the internet, you can use any old addressees and routing schemes you want. Nobody will care what you do because there is no risk of collision with anyone else.
How does IPv6 change this? Either way, you have to use IP addresses assigned to you (public IPv6 addresses, or private IPv4 addresses) if you want to interface it to the public internet. Your physical firewall and router setup isn't going to change much, if at all.
If your private network will never be connected to the internet, you can use any old addressees and routing schemes you want. Nobody will care what you do because there is no risk of collision with anyone else.
ULA addresses in IPv6 allow unique local addresses that can be used by a large enterprise to build their own network, so that they have specific IPv6 endpoints always available, and then when their ISP hands them a different /64 or /56 they can continue to function as normal without renumbering.
Despite what many assumed from my original question, I was not in the least bit concerned about NAT's replacement as a pseudo access control at the IP layer.
My concern was the lack of control and independence from the global network when it is needed. This saves organisations and individuals a small fortune and provides maximum flexibility and convenience in internal networking.
However, I have been doing further research and while NAT discovery and traversal is an uncertain area, and (of course) firewalls are the design intention for IPv6 access control, the core ability to have access to private unicast addresses within IPv6 is covered by RFC 4193 (Unique Local IPv6 Unicast Addresses).
So, 6-within-4 protocols need only be around as long as 4 is the majority globally routable IP protocol, which may be for a LOT longer than people think, instead of being around because 6 lacks support for existing functions.
My concern was the lack of control and independence from the global network when it is needed. This saves organisations and individuals a small fortune and provides maximum flexibility and convenience in internal networking.
However, I have been doing further research and while NAT discovery and traversal is an uncertain area, and (of course) firewalls are the design intention for IPv6 access control, the core ability to have access to private unicast addresses within IPv6 is covered by RFC 4193 (Unique Local IPv6 Unicast Addresses).
So, 6-within-4 protocols need only be around as long as 4 is the majority globally routable IP protocol, which may be for a LOT longer than people think, instead of being around because 6 lacks support for existing functions.
Beyond a lack of public IP's, it's the obstructive nature of it that makes it (sort of) useful.
It's not really any safer than starting with a firewall where everything is denied by default and opening port by port of inbound traffic.
But NAT'ing every internal address forces you into a pattern where the external IP is not tied to where the service is hosted at all - you need to explicitly map that in your firewall -, and where if you were to, say, accidentally turn off all your filtering, you leave yourself isolated instead of exposed.
I don't think these are important enough to care about NAT once we switch to IPv6 - you can certainly be just as defensive through other means.
It's not really any safer than starting with a firewall where everything is denied by default and opening port by port of inbound traffic.
But NAT'ing every internal address forces you into a pattern where the external IP is not tied to where the service is hosted at all - you need to explicitly map that in your firewall -, and where if you were to, say, accidentally turn off all your filtering, you leave yourself isolated instead of exposed.
I don't think these are important enough to care about NAT once we switch to IPv6 - you can certainly be just as defensive through other means.
But NAT is way too useful and taken for granted to be removed.
Eh? NAT is a bloody miserable sodding hack that should be taken out back and shot. Getting rid of NAT and restoring the end-to-end principle is, IMO, one of the best reasons to support ipv6 adoption.
Eh? NAT is a bloody miserable sodding hack that should be taken out back and shot. Getting rid of NAT and restoring the end-to-end principle is, IMO, one of the best reasons to support ipv6 adoption.
NAT is a hack for getting more machines online without having more IPs available. Obviously, IPv6 makes that obsolete.
I think it's the opposite: NAT almost made IPv6 obsolete. I spent a large time trapped behind a NAT by my former ISP, getting "you are alredy downloading" errors. So I absolutely hate whoever invented that crap.
> NAT is a hack for getting more machines online without having more IPs available. Obviously, IPv6 makes that obsolete.
The problem is that the addresses might not be where you need them. Let's say you bring an OpenVPN-running Linksys router to a hotel room and plug your devices into them so they can be on their own firewalled subnet with VPN access (this is the ultimate road-warrior setup). Unless the hotel routes a subnet to you (and they won't be), you can't do this. The hotel's subnet might have plenty of public IPv6 addresses available, but you won't have any to make your own subnet. What should you do instead? Bridge the networks and use layer 2 firewalling? The VPN routing would be a nightmare. This question has been plaguing me.
To be clear, I do not think NAT should be used in most cases. But for rare or temporary cases it would be very useful to have available if you know what you're doing.
The problem is that the addresses might not be where you need them. Let's say you bring an OpenVPN-running Linksys router to a hotel room and plug your devices into them so they can be on their own firewalled subnet with VPN access (this is the ultimate road-warrior setup). Unless the hotel routes a subnet to you (and they won't be), you can't do this. The hotel's subnet might have plenty of public IPv6 addresses available, but you won't have any to make your own subnet. What should you do instead? Bridge the networks and use layer 2 firewalling? The VPN routing would be a nightmare. This question has been plaguing me.
To be clear, I do not think NAT should be used in most cases. But for rare or temporary cases it would be very useful to have available if you know what you're doing.
This is a problem only if you don't default-route everything from the Linksys LAN through the VPN, with the IPv6 LAN subnet being routed through the VPN. In fact the IPv6 LAN subnet might just as well be at the remote endpoint with a tap bridge (which is actually very close to my openvpn ipv4+ipv6 setup)
That's not a bad idea, especially since these days you often can't rely on someone else's network to be secure and free of shenanigans like this: http://news.ycombinator.com/item?id=3804608
On the other hand, this leads to suboptimal routing. If I'm in Australia and the VPN server is in the US, connections to Australian hosts would be routed across the Pacific and back.
On the other hand, this leads to suboptimal routing. If I'm in Australia and the VPN server is in the US, connections to Australian hosts would be routed across the Pacific and back.
Or you could carry your own IPv6 addresses around. In this world of mobile devices and networks this might soon become a requirement, actually.
A major goal of IPv6 was to provide enough addresses for every device. When there is no need for overlapping networks, there is no need for NAT.
Pure IPv6 will be used in places that run out of IPv4 addresses first. Probably Africa.
I doubt that; it's not reasonable to be on IPv6 only. ISP-level NAT for IPv4 will probably exist for a long time.
Let's hope device manufacturers add IPv6. Particularly for routers and phones.
Its still a poor standard that should have died decades ago
Since you didn't propose a better standard during these decades, IPv6 is likely to stay. Why it's poor btw?
What they really should have done is extend IPv4 addresses using an option header in packets, which (with a small amount of effort) provides a fall-back and is nowhere near as disruptive as trying to enable IPv6 everywhere.
In theory, perhaps. In reality this is not feasible because the hardware guys would never go for it. The mere existence of an IPv4 header extension causes a packet to be kicked out of the hardware fast path (or dropped entirely) by all the router implementations that I know.
Precisely the sort of thing I was getting at before I got modded down to oblivion.
It is not backwards compatible. Yeah I know that is HARD, but that is why we have smart people to write the standards.
well I was only a lowly MPG2 back then :-) and probaly all the stadards work BT where doing at that was more towards OSI and SS7 standards - where inetropablity and uptime was the holy grail.
Its peopel like Vint that took thier eye off the ball.
Its peopel like Vint that took thier eye off the ball.
NO Migration stratergy it was designed back when the internet was just some academic curiosity which ment you could do disruptive changes over the academic summer break.
Even in the 80's it was obvious that this would not work for ipv4 to ipv6.
IPv6 have been dropped 20+ years ago and a more fit for purporse stndard devloped.
Even in the 80's it was obvious that this would not work for ipv4 to ipv6.
IPv6 have been dropped 20+ years ago and a more fit for purporse stndard devloped.
It looks like they started work on IPv6 in 1994[1], so I doubt migration issues have been known about since the 80s.
[1] http://www.ipv6.com/articles/general/timeline-of-ipv6.htm
[1] http://www.ipv6.com/articles/general/timeline-of-ipv6.htm
er they started talking about a replacement for ipv4 in the 80's
Arguments?
This is because when you design a chip, you have to take into account what your customers will be using it for in a few years time, but for software, it's all about what your customers want yesterday. Since IPV6 has always been 'just around the corner', it gets into the hardware but not all the software.