For network engineers who spend their days designing IP network and running BGP the thought of running Provider Assigned (PA) IPv6 address space is often meet with a look of repulsion and disdain. Given the relative easy for most enterprise network engineers to run multi-homed BGP and to have redundant Internet Service Providers with a single IPv4 or IPv6 address block this might be a justified reaction. However, there are cases for smaller businesses and even smaller branch offices to run IPv6 PA address space that might make sense.
For instance, if you have a remote office that has limited service provider options and perhaps it is not cost effective to run BGP at the remote site you can utilize PA space to dual stack the site and simply put IPv6 ACL's in place to building corporate access policies. For small businesses it makes little sense to try and BGP multi-home due to the hardware and engineering talent required to maintain such arrangements. Considering how infrequent it is for a company to change ISP's for a given location it is not inconceivable that turning up a new service provider and migrating to a new PA block is a reasonable solution for many.
The biggest outcry I hear most often is from System Administrators who seem to think changing IP addresses will break all their server configurations, printer settings and other items. My calm reply is that they can continue to utilize IPv4 RFC 1918 space as they were and that if they are not using DNS for name resolution by now then they should likely not have that SA job anymore. DNS allows for an easy migration from one PA block to a new one with minimal impact. In addition, you can utilize DHCPv6 to manage resources and the lease times ensuring that the migration can be quick and relatively painless like most other maintenance windows for OS upgrades or WAN service provider transitions. In addition, hosts are designed to have multiple IPv6 addresses in use at the same time which theoretically means the host would control the timing of the cut-over from one PA space to a new one.
To top it off, it could be argued that for MPLS or other WAN services it might make sense to get PA space for those point to point links and allow for better summary aggregate routing for the Provider Independent (PI) space you do have as /48 sites without wasting a /48 for WAN or VPN links within your network. You could even put route filtering in place to prevent the propagation of the PA space out of your network which would control transit WAN/MPLS traffic loads. Just because the Global Unicast Address (GUA) space you get from your provider is available to route globally doesn't mean you have to advertise it or even have the service provider advertise it either.
With the recent introduction of RFC 6296 it is possible to migrate from one prefix to the other in one move but to do this requires some downtime while the prefix replacement happens. It also introduces the problem of what IPv6 address does the host actually have at any given moment (it won't have both like a migration.) Realistically it breaks the end to end transport by being yet another version of NAT. While it is a good tool to have I don't advocate utilizing it unless the use case truly dictates needing it. Just migrate to a new IPv6 address block and things will work as expected. Hopefully your business will grow enough that the migration will be to PI address space and you only have to do the migration once!
- Ed
Tuesday, November 29, 2011
When to consider using Provider Assigned IPv6 address space
Friday, November 11, 2011
Odd IPv6 ULA use cases
I have to be honest, I am not a huge fan of the idea of IPv6 ULA (unique local addressing) at all. I have seen several use cases presented and even some knowledge based articles written saying to use it such as this one by Apple. There are ULA address prefix generators like this one at SixXS which are useful if you want to do ULA, my question is WHY?
At the core of the question is what do you gain by doing ULA that you don't get with doing Global Unicast Addressing? I would argue you get no benefit of having to global register a /48 ULA then simply applying for a /48 or larger from ARIN or one of the other regional registries that provide public IPv6 address space with the exception of price (which could be a big deal for some small businesses but just get your IPv6 address space from your provider for free then.) Furthermore, ULA by definition in rfc4193 cannot be routed globally and must be filtered at the edge which very much limits your IPv6 deployment and ensures you have to either deploy Global Unicast Addressing at a later date or do prefix translation as described in rfc6296 which is a viable solution but seems to introduce yet another network translation component on the network when one is not needed if you simply used Global Unicast Addressing the first time around.
The other concern I have is some OS platforms not behaving as expected when getting ULA addresses. Ideally all OS behavior with ULA would know that you don't have global IPv6 access with a ULA at all but if you are using prefix translation is that still true? Also, since IPv6 is preferred do we run into a case where the network team is putting ULA in play and breaking some of the default OS behavior that is desired for transitioning to IPv6?
Given the fact that the effort is almost identical for deploying ULA and it is Global Unicast I am not convinced that ULA is something that is needed or should be recommended. I would love to hear feedback on this one. The few corner use cases I have heard still do not seem to overcome the argument of just using Global Unicast.
- Ed
At the core of the question is what do you gain by doing ULA that you don't get with doing Global Unicast Addressing? I would argue you get no benefit of having to global register a /48 ULA then simply applying for a /48 or larger from ARIN or one of the other regional registries that provide public IPv6 address space with the exception of price (which could be a big deal for some small businesses but just get your IPv6 address space from your provider for free then.) Furthermore, ULA by definition in rfc4193 cannot be routed globally and must be filtered at the edge which very much limits your IPv6 deployment and ensures you have to either deploy Global Unicast Addressing at a later date or do prefix translation as described in rfc6296 which is a viable solution but seems to introduce yet another network translation component on the network when one is not needed if you simply used Global Unicast Addressing the first time around.
The other concern I have is some OS platforms not behaving as expected when getting ULA addresses. Ideally all OS behavior with ULA would know that you don't have global IPv6 access with a ULA at all but if you are using prefix translation is that still true? Also, since IPv6 is preferred do we run into a case where the network team is putting ULA in play and breaking some of the default OS behavior that is desired for transitioning to IPv6?
Given the fact that the effort is almost identical for deploying ULA and it is Global Unicast I am not convinced that ULA is something that is needed or should be recommended. I would love to hear feedback on this one. The few corner use cases I have heard still do not seem to overcome the argument of just using Global Unicast.
- Ed
Wednesday, November 09, 2011
gogoNETLive! 2 IPv6 Conference wrap up
If you missed the gogoNETLive! 2 IPv6 Conference that happened at San Jose State University last week you can still get a chance to see the content from the conference. Almost all the sessions were recorded and the video and pdf's of the slides will be posted soon. I encourage you to check out last years content also, the majority of that is still applicable and a valuable baseline for understanding what is happening in IPv6.
The next big IPv6 events happening will be the IPv6 World Congress in Paris, France and then the re branded Rocky Mountain IPv6 Summit which is now being called the 2012 North American IPv6 Summit. The North American IPv6 Summit is by far the largest IPv6 event in the US and is expected to have over 500 folks attending and will likely sell out. If you have any interest at all in getting good practical IPv6 knowledge from real world experts both these events would be worth your time and effort.
- Ed
The next big IPv6 events happening will be the IPv6 World Congress in Paris, France and then the re branded Rocky Mountain IPv6 Summit which is now being called the 2012 North American IPv6 Summit. The North American IPv6 Summit is by far the largest IPv6 event in the US and is expected to have over 500 folks attending and will likely sell out. If you have any interest at all in getting good practical IPv6 knowledge from real world experts both these events would be worth your time and effort.
- Ed
Subscribe to:
Posts (Atom)