4 ms·

My company has been using IPv6 extensively since 2004, and we have about 13 million network elements under management, and all of our internal hosts / routers a

My company has been using IPv6 extensively since 2004, and we have about 13 million network elements under management, and all of our internal hosts / routers are 100% IPv6 addressed. But, I don't feel any pressure, or see any need whatsoever to move our Internet routes to IPv6 right now. NAT/PAT gets the job done just fine, and it will be many years, probably the better part of a decade, before we feel the need to start routing IPv6 onto the Internet. Internally, we're 100% deployed in RFC 4193 space, so when we do decide to route IPv6 to the internet, we'll need to NAT/PAT on our firewalls anyways - the same way we do with IPv4. Whenever we need to reach an IPv6 host over an IPv4 transit network, RFC 2893 does the job quickly and efficiently. IPv6 brings us some advantages, Stateless Address Assignment, Reduced chance of address conflict when we communicate with other companies via IPv6, intelligent use of multicast, elimination of CIDR - but none of these are relevant when communicating to the Internet. That, more than anything else, is why people are not moving off of IPv4 more quickly to IPv6 - After 8+ years of using/managing IPv6 every day - none of our network engineers/IT team really see any pressing motivation. [edit: I would be interested in hearing comments from other practitioners whose experience was different from mine. I'd also be interested in hearing if other major enterprises are deploying in RFC 4193 space, or, are considering exposing their internal address topology to the Big-I Internet - i.e. Not using NAT6/PAT6]

AndrewDucker 14y ago
Presumably the pressing motivation will be when there are sites that can only be hit via IPv6.
Dylan16807 14y ago
Why would you need NAT? Is it difficult to change the prefix that a network is on? Or would you have to reorganize the network if you were using external prefixes?
- ghshephard 14y ago
  We're using RFC 4193 space, which doesn't route globally, so we need to have a globally routable IP address if (and when) we decide to route onto the internet. NAT6/PAT6 does that for us. For numerous reasons, (see a prior comment by me) we don't have a lot of interest in putting globally routable addresses on internal hosts.
agwa 14y ago
Have you considered getting provider-independent address space and using that instead of ULA? (Or, if it's too difficult to switch now, would you have done that if you could go back and do it all over again?) You sound like a big organization that could easily justify the allocation. I understand small sites, who can't justify the allocation or just don't want to pay the fees, using ULA+NAT to avoid renumbering hassles, but if you're big enough for PI why not use it? It's just as convenient as ULA but is also globally routable so you get to take NAT out of the equation.
- akira2501 14y ago
  RFC6296 (NPTv6) makes a reasonable case for address independence and points out some issues with PI. http://tools.ietf.org/html/rfc6296#section-1.1 http://tools.ietf.org/html/rfc6296#section-1.1
- ghshephard 14y ago
  When we first started rolling out our addresses (2004) - it looked very much like any address space we requested, would be locked to the ISP that we were connected to. Many of our nodes we run for large utilities, and we wanted to have the flexibility to hand them over to the other organizations without any paperwork. RFC 4193 let's us carve out /48s at will, assigning a /48 per customer, that is in no-way connected to any ISP. Also, and I recognize this is a very unpopular perspective among some, so apologies in advance, we don't want anybody on the Internet to know what our internal addresses are. And we also want to eliminate any possibility of direct routing from the internet. Going with RFC 4193 (AKA ULA, AKA IPv6's answer to RFC 1918) allows us to carve out an address space that, even if it did somehow become known to the internet - wouldn't do them a lot of good, because they can't route to it. A lot of people think that renumbering is as simple as plugging in a new address to be advertised off the router - but what they forget is the huge number of places in which those IPv6 addresses (and networks) have been plumbed into other router configurations (RFC 2893 6in4 tunnel configurations) - not to mention all of the network diagrams, and databases. RFC4193 means that we don't have to worry about renumbering, and, if we chose to hand it off to a third party, their is a probabilistically insignificant chance that they are using that space, so merging is trivial.

AndrewDucker 14y ago

Presumably the pressing motivation will be when there are sites that can only be hit via IPv6.

Dylan16807 14y ago

Why would you need NAT? Is it difficult to change the prefix that a network is on? Or would you have to reorganize the network if you were using external prefixes?

ghshephard 14y ago
We're using RFC 4193 space, which doesn't route globally, so we need to have a globally routable IP address if (and when) we decide to route onto the internet. NAT6/PAT6 does that for us. For numerous reasons, (see a prior comment by me) we don't have a lot of interest in putting globally routable addresses on internal hosts.

agwa 14y ago

Have you considered getting provider-independent address space and using that instead of ULA? (Or, if it's too difficult to switch now, would you have done that if you could go back and do it all over again?) You sound like a big organization that could easily justify the allocation. I understand small sites, who can't justify the allocation or just don't want to pay the fees, using ULA+NAT to avoid renumbering hassles, but if you're big enough for PI why not use it? It's just as convenient as ULA but is also globally routable so you get to take NAT out of the equation.

akira2501 14y ago
RFC6296 (NPTv6) makes a reasonable case for address independence and points out some issues with PI. http://tools.ietf.org/html/rfc6296#section-1.1 http://tools.ietf.org/html/rfc6296#section-1.1
ghshephard 14y ago
When we first started rolling out our addresses (2004) - it looked very much like any address space we requested, would be locked to the ISP that we were connected to. Many of our nodes we run for large utilities, and we wanted to have the flexibility to hand them over to the other organizations without any paperwork. RFC 4193 let's us carve out /48s at will, assigning a /48 per customer, that is in no-way connected to any ISP. Also, and I recognize this is a very unpopular perspective among some, so apologies in advance, we don't want anybody on the Internet to know what our internal addresses are. And we also want to eliminate any possibility of direct routing from the internet. Going with RFC 4193 (AKA ULA, AKA IPv6's answer to RFC 1918) allows us to carve out an address space that, even if it did somehow become known to the internet - wouldn't do them a lot of good, because they can't route to it. A lot of people think that renumbering is as simple as plugging in a new address to be advertised off the router - but what they forget is the huge number of places in which those IPv6 addresses (and networks) have been plumbed into other router configurations (RFC 2893 6in4 tunnel configurations) - not to mention all of the network diagrams, and databases. RFC4193 means that we don't have to worry about renumbering, and, if we chose to hand it off to a third party, their is a probabilistically insignificant chance that they are using that space, so merging is trivial.