3 ms·

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 tha

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

by agwa 14y ago

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.