Saturday, December 28, 2013
Practical IPv6 for Windows Administrators is available!
My book Practical IPv6 for Windows Administrators from Apress is officially published and available to order. You can order a printed copy from Amazon, or a Kindle version and Barnes and Noble has the printed version available now too (a Nook version should be available shortly.)
A thank you to Richard Hicks and Jason Jones who did the technical review for the book. They were critical in so many ways and their feedback and honest opinions about things in the book were really valuable to me. The end result is much improved due to their hard work.
I also want to thank Jonathan Gennick my Lead Editor and Ana Panchoo my Coordinating Editor, both with Apress, for helping make the book writing process easy (as easy as you can make writing a book.) They really were fantastic to work with and considering this book was produced in 5 months they really had to work hard to make it all happen. If you are a technical author or want to become one I would recommend Apress. You can review through their materials on their Write For Us section of their website.
Finally, please don't be shy and let me know if the book was on target. I worked on trying to solve some of the design, operational and practical issues that come up with figuring out how to get started with IPv6 and Windows. There is always room for improvement so let me know!
- Ed
Wednesday, December 18, 2013
IPv6 is like global warming
I recently was on twitter going back and forth with some colleagues on the topic of IPv6 (shocking, I know) and I said the following:
"IPv6 is like global warming, sea level rise is easy to ignore (or deny) but it will impacts a crazy number of people"
This resonates with me. The fact that regardless of how you feel about global warming (man made, natural fluctuation, curse from a $deity) the effects are what matters. There is sea level rise (it is measurable, we are measuring it, it is going up) and given the fact that a very high percentage of the world populations live close or on the edges of the oceans they are going to be impacted.
There are practical ways to deal with this. Most agree the sea level change isn't going to jump up 3+ feet overnight (outside of storm surges, etc.) so it is possible to plan and take corrective action. There are cities and governments in the world where this is happening today. They are being proactive and realize it will take a long time to get everyone to adjust to this new change (building codes, zoning, etc.) There are also those that are not taking these actions. Finally there are those unfortunate few who can't address it even if they wanted to, like some small remote islands.
We won't know the final outcome and impact until years later. Who did the right strategic move and planned, implemented and were ready for the eventual sea level rise? It is analogous to those who plan, implement and deploy IPv6. In both situations you can wait. But eventually you must deal with the issue. Will you be ready when the sea level rise happens? Will you able to execute on IPv6 when your company needs you to?
So perhaps the global warming community can say:
"Global warming is like IPv6, IPv4 depletion is easy to ignore (or deny) but it will impact a crazy number of people"
How is that for turning it back around!
- Ed
"IPv6 is like global warming, sea level rise is easy to ignore (or deny) but it will impacts a crazy number of people"
This resonates with me. The fact that regardless of how you feel about global warming (man made, natural fluctuation, curse from a $deity) the effects are what matters. There is sea level rise (it is measurable, we are measuring it, it is going up) and given the fact that a very high percentage of the world populations live close or on the edges of the oceans they are going to be impacted.
There are practical ways to deal with this. Most agree the sea level change isn't going to jump up 3+ feet overnight (outside of storm surges, etc.) so it is possible to plan and take corrective action. There are cities and governments in the world where this is happening today. They are being proactive and realize it will take a long time to get everyone to adjust to this new change (building codes, zoning, etc.) There are also those that are not taking these actions. Finally there are those unfortunate few who can't address it even if they wanted to, like some small remote islands.
We won't know the final outcome and impact until years later. Who did the right strategic move and planned, implemented and were ready for the eventual sea level rise? It is analogous to those who plan, implement and deploy IPv6. In both situations you can wait. But eventually you must deal with the issue. Will you be ready when the sea level rise happens? Will you able to execute on IPv6 when your company needs you to?
So perhaps the global warming community can say:
"Global warming is like IPv6, IPv4 depletion is easy to ignore (or deny) but it will impact a crazy number of people"
How is that for turning it back around!
- Ed
Tuesday, December 10, 2013
IPv6 NAT66 and NPTv6 - it seems there is still a lot of confusion
I've written previous posts on NPTv6 but it seems I didn't do a particularly good job explaining the different between NPTv6 and NAT66 and there is still a lot of confusion understanding what the actual difference is between the two. While both are doing network translation they are doing it differently.
The difference is pretty simple. NAT66 performs the same function we have with NAT44. It is a stateful network address translation on a router or firewall. It will take an IPv6 address on one network interface and translate it to a new IPv6 address on the other network interface and forward the packet. It may perform some sort of application fix up to keep certain protocols and applications from having problems. It requires resources (CPU and memory) on the router or firewall to do this and the returning traffic will have to come through the same device because it is keeping a state table of all the translations it is performing.
NPTv6 is different then NAT66 in that only the leftmost prefix portions of the address are translated. This means that the device doing this translation do not need to keep state at all. So NPTv6 is stateless and therefore in theory can scale better and also be distributed across many devices doing the same function (regardless of forwarding changes and asymmetrical routing). The internal prefix and the external prefix sizes must match so if you want to use NPTv6 you need to do some work to make sure things match up. In other words, your internal network may have a /64 ULA prefix that you want to use NPTv6 to give it access to the IPv6 Internet. You will need a /64 of global unicast address space to allow the router or firewall to do the NPTv6 function with. If you have a /48 internally that you want to use NPTv6 with then you will require a /48 for that externally.
There are some minor variations of these two. NAT66 can, in theory also provide PAT functions allowing the overload of a single IPv6 address by multiple IPv6 addresses behind it. This really is not needed with IPv6 at all as there are more than enough IPv6 addresses to go around. In theory SLB64 looks like NAT66 because it is providing a shared VIP to access a resource and translating traffic appropriately.
As a general rule of thumb, those in the IPv6 community see NPTv6 as a potential tool to solve some corner case issues and they see NAT66 as not desirable. There really is no reason to run NAT66 and if you do require any sort of NAT function then you should be using NPTv6. Unless we want to repeat all the mistakes we have made with NAT44 over the years (and now NAT444 with CGN solutions) then adopting NAT66 is a poor choice.
Obviously this debate is ongoing and it could end up that NAT66 ends up winning but I am hopeful that won't be the case.
- Ed
The difference is pretty simple. NAT66 performs the same function we have with NAT44. It is a stateful network address translation on a router or firewall. It will take an IPv6 address on one network interface and translate it to a new IPv6 address on the other network interface and forward the packet. It may perform some sort of application fix up to keep certain protocols and applications from having problems. It requires resources (CPU and memory) on the router or firewall to do this and the returning traffic will have to come through the same device because it is keeping a state table of all the translations it is performing.
NPTv6 is different then NAT66 in that only the leftmost prefix portions of the address are translated. This means that the device doing this translation do not need to keep state at all. So NPTv6 is stateless and therefore in theory can scale better and also be distributed across many devices doing the same function (regardless of forwarding changes and asymmetrical routing). The internal prefix and the external prefix sizes must match so if you want to use NPTv6 you need to do some work to make sure things match up. In other words, your internal network may have a /64 ULA prefix that you want to use NPTv6 to give it access to the IPv6 Internet. You will need a /64 of global unicast address space to allow the router or firewall to do the NPTv6 function with. If you have a /48 internally that you want to use NPTv6 with then you will require a /48 for that externally.
There are some minor variations of these two. NAT66 can, in theory also provide PAT functions allowing the overload of a single IPv6 address by multiple IPv6 addresses behind it. This really is not needed with IPv6 at all as there are more than enough IPv6 addresses to go around. In theory SLB64 looks like NAT66 because it is providing a shared VIP to access a resource and translating traffic appropriately.
As a general rule of thumb, those in the IPv6 community see NPTv6 as a potential tool to solve some corner case issues and they see NAT66 as not desirable. There really is no reason to run NAT66 and if you do require any sort of NAT function then you should be using NPTv6. Unless we want to repeat all the mistakes we have made with NAT44 over the years (and now NAT444 with CGN solutions) then adopting NAT66 is a poor choice.
Obviously this debate is ongoing and it could end up that NAT66 ends up winning but I am hopeful that won't be the case.
- Ed
Sunday, December 08, 2013
Follow up to my IPv6 and ULA post plus some thoughts on design and IPv6 behavior
I've gotten some interesting comments and questions in regards to my IPv6 ULA (Unique Local Address) post and I wanted to outline the questions and then follow up with my thoughts and some high level design discussion.
The first question is around the situation of multiple ISP connections without using BGP and Provider Independent (PI) addresses or alternately switching from one ISP to another. The argument is pretty straightforward, you don't want to have to renumber your servers, network links and other infrastructure when changing ISP's because the IPv6 address space you have is allocated from that ISP. That IPv6 address space will no longer be yours when you change from ISP A to ISP B. So, alternately you can use ULA for your network, server and even client devices and only use that ISP IPv6 address space at the edge, similar to how you implement IPv4 today. This requires the use of some sort of NAT translation at the edge.
The second question is a bit of a refinement of the above that argues you should use ULA for all internal hosts and your LAN and WAN resources so you don't have to renumber if you change ISP's but also so you have a consistent address prefix preference for internal traffic to register with DNS.
I think those really are the main pro ULA arguments I have heard so far. Let's tackle the first part which is really all about flexibility in choosing and changing your ISP and reducing the IPv6 renumbering costs to a fractional degree. The second one I will cover in a different post.
The following diagrams shows the multiple ISP connection configuration which is no different than migrating from one ISP to another. We start with ISP A on the left and will be moving to ISP B on the right. Our initial network configuration will use ISP A's IPv6 Provider Assigned (PA) address block and our goal is the move to ISP B's IPv6 Provider Assigned (PA) address block. For a duration of time you will have both ISP A's and ISP B's IPv6 address blocks active on your network. The next diagrams (Figure 2 and 3) are what everyone thinks they want to deploy. It utilizes some sort of NAT technology at the Internet edge and assumes you will only use ULA for the "internal" network.
Figure 1. Dual connections while migrating service providers
Figure 2. ISP 1 with NAT66
Figure 3. ISP 2 with NAT66
The primary problem with the ULA solution people want is that there are no good production quality NPTv6 implementations out there to run on a firewall or edge Internet device today. This limits your ability to actually deploy that solution so you are left with NAT66 (not a good option in my opinion). Furthermore, NPTv6 still breaks many end to end features for applications relying on the underlying networking protocol not doing NAT. Application developers will still have to build NAT traversal mechanisms into their apps even though we were not supposed to need them with IPv6 at all. The only advantage you will gain is that with NPTv6 you have a stateless solution for NAT as only the prefix is actually changed. This reduces the amount of resources required on that Internet edge device greatly compared to the same solution with IPv4. An additional option is to go with NAT66 (which is available from some network manufactures) but which make IPv6 even more brittle and introduces every one of the NAT/PAT problems we have with IPv4 only on a much larger scale. I consider this solution a huge mistake and using it roles back all the progress and design work that the architects of IPv6 put into the protocol.
The slightly more difficult dual ISP PA migration (Figure 1) solution will actually work just fine without ULA. You will have to do some planning to do renumbering however depending on your design this could potentially be relatively easy. The most difficult resources to renumber would be your LAN and WAN infrastructure and your servers. Client devices should be dynamically obtaining their IP addresses (IPv4 or IPv6) and should not care greatly if their network address prefix changes over a weekend or even within the day. IPv6 has no issue with running both PA IPv6 prefixes at the same time nor does it require ULA to do this function. You might gain some time back on larger LAN and WAN networks on not having to renumber and this could be true for servers also however you will have to write additional firewall rules and you will still have to give them global unicast addresses if they need to talk to the public IPv6 Internet at all (remember, limited or no NPTv6 support today). This means you still have to touch the device to change it over from one IPv6 prefix to another. If it does not have the requirement for being able to get to the public Internet at all then there is a use case for using ULA. I see this as a secure network and I argued in the previous blog post that a secure network would be a legitimate use case for ULA.
ULA may buy you a small amount of stability in avoiding some address renumbering but I would argue that a proper DDI solution solves almost all the issues using DDNS and name to IP address resolution. What you gain from ULA to avoid renumbering you will likely have to pay back 10 fold in NAT traversal issues and pain.
A quick question, how often are people changing ISP's for small to medium sized businesses? I think some of the renumbering argument assumes this happens far more often than it does. For many medium to larger enterprise customers they will likely get Provider Independent IPv6 address space and utilize BGP to advertise to multiple ISP's at once (Figure 4). They do not require NPTv6 and even if they need local Internet hop off at a branch location they would simply deploy both PI and PA IPv6 prefixes at that site and let RFC 6724 solve the source/destination matching (Figure 5). They can gain more granular control of the routing behavior if they modify the prefix policy tables.
Figure 4. Dual homed IPv6 BGP peering
Figure 5. IPv6 PI and PA with local Internet hop off
As for those that are dual homing but not running BGP they do not require ULA or a NAT solution, simply run both IPv6 PA address space on the network (Figure 1) and let RFC 6724 solve the source/destination matching. If you want more control you can manage the prefix policy tables on your hosts or do some routing policy work within your network. Even so, if you are doing dual homed but no BGP you likely don't have a large enough network to care or bother with those efforts. Either way, I believe it is still simpler to use both service providers IPv6 PA space than to deal with ULA and NAT.
Thoughts? What other ways to you see ULA being an advantage over global unicast IPv6 addresses in your network?
- Ed
My book is available for pre-order on Amazon or you can order directly from the publisher Apress
The first question is around the situation of multiple ISP connections without using BGP and Provider Independent (PI) addresses or alternately switching from one ISP to another. The argument is pretty straightforward, you don't want to have to renumber your servers, network links and other infrastructure when changing ISP's because the IPv6 address space you have is allocated from that ISP. That IPv6 address space will no longer be yours when you change from ISP A to ISP B. So, alternately you can use ULA for your network, server and even client devices and only use that ISP IPv6 address space at the edge, similar to how you implement IPv4 today. This requires the use of some sort of NAT translation at the edge.
The second question is a bit of a refinement of the above that argues you should use ULA for all internal hosts and your LAN and WAN resources so you don't have to renumber if you change ISP's but also so you have a consistent address prefix preference for internal traffic to register with DNS.
I think those really are the main pro ULA arguments I have heard so far. Let's tackle the first part which is really all about flexibility in choosing and changing your ISP and reducing the IPv6 renumbering costs to a fractional degree. The second one I will cover in a different post.
The following diagrams shows the multiple ISP connection configuration which is no different than migrating from one ISP to another. We start with ISP A on the left and will be moving to ISP B on the right. Our initial network configuration will use ISP A's IPv6 Provider Assigned (PA) address block and our goal is the move to ISP B's IPv6 Provider Assigned (PA) address block. For a duration of time you will have both ISP A's and ISP B's IPv6 address blocks active on your network. The next diagrams (Figure 2 and 3) are what everyone thinks they want to deploy. It utilizes some sort of NAT technology at the Internet edge and assumes you will only use ULA for the "internal" network.
Figure 3. ISP 2 with NAT66
The primary problem with the ULA solution people want is that there are no good production quality NPTv6 implementations out there to run on a firewall or edge Internet device today. This limits your ability to actually deploy that solution so you are left with NAT66 (not a good option in my opinion). Furthermore, NPTv6 still breaks many end to end features for applications relying on the underlying networking protocol not doing NAT. Application developers will still have to build NAT traversal mechanisms into their apps even though we were not supposed to need them with IPv6 at all. The only advantage you will gain is that with NPTv6 you have a stateless solution for NAT as only the prefix is actually changed. This reduces the amount of resources required on that Internet edge device greatly compared to the same solution with IPv4. An additional option is to go with NAT66 (which is available from some network manufactures) but which make IPv6 even more brittle and introduces every one of the NAT/PAT problems we have with IPv4 only on a much larger scale. I consider this solution a huge mistake and using it roles back all the progress and design work that the architects of IPv6 put into the protocol.
The slightly more difficult dual ISP PA migration (Figure 1) solution will actually work just fine without ULA. You will have to do some planning to do renumbering however depending on your design this could potentially be relatively easy. The most difficult resources to renumber would be your LAN and WAN infrastructure and your servers. Client devices should be dynamically obtaining their IP addresses (IPv4 or IPv6) and should not care greatly if their network address prefix changes over a weekend or even within the day. IPv6 has no issue with running both PA IPv6 prefixes at the same time nor does it require ULA to do this function. You might gain some time back on larger LAN and WAN networks on not having to renumber and this could be true for servers also however you will have to write additional firewall rules and you will still have to give them global unicast addresses if they need to talk to the public IPv6 Internet at all (remember, limited or no NPTv6 support today). This means you still have to touch the device to change it over from one IPv6 prefix to another. If it does not have the requirement for being able to get to the public Internet at all then there is a use case for using ULA. I see this as a secure network and I argued in the previous blog post that a secure network would be a legitimate use case for ULA.
ULA may buy you a small amount of stability in avoiding some address renumbering but I would argue that a proper DDI solution solves almost all the issues using DDNS and name to IP address resolution. What you gain from ULA to avoid renumbering you will likely have to pay back 10 fold in NAT traversal issues and pain.
A quick question, how often are people changing ISP's for small to medium sized businesses? I think some of the renumbering argument assumes this happens far more often than it does. For many medium to larger enterprise customers they will likely get Provider Independent IPv6 address space and utilize BGP to advertise to multiple ISP's at once (Figure 4). They do not require NPTv6 and even if they need local Internet hop off at a branch location they would simply deploy both PI and PA IPv6 prefixes at that site and let RFC 6724 solve the source/destination matching (Figure 5). They can gain more granular control of the routing behavior if they modify the prefix policy tables.
Figure 4. Dual homed IPv6 BGP peering
Figure 5. IPv6 PI and PA with local Internet hop off
As for those that are dual homing but not running BGP they do not require ULA or a NAT solution, simply run both IPv6 PA address space on the network (Figure 1) and let RFC 6724 solve the source/destination matching. If you want more control you can manage the prefix policy tables on your hosts or do some routing policy work within your network. Even so, if you are doing dual homed but no BGP you likely don't have a large enough network to care or bother with those efforts. Either way, I believe it is still simpler to use both service providers IPv6 PA space than to deal with ULA and NAT.
Thoughts? What other ways to you see ULA being an advantage over global unicast IPv6 addresses in your network?
- Ed
My book is available for pre-order on Amazon or you can order directly from the publisher Apress
Monday, October 21, 2013
I am speaking at the IT Roadmap event in San Jose Oct 24
I will be doing a presentation on IPv6 at the Network World IT Roadmap event at the San Jose Convention Center on Thursday, Oct 24. If you are interested there is still time and room to registered for the event. My presentation is "IPv6, Now is the Time" and my long time friend and colleague John Hoffman from Oracle will be presenting with me talking about how Oracle is doing their IPv6 deployment and some of the challenges and issues they have run into over time.
If you are in the area I encourage you to come attend the event. There is a wonderful line up of topics and presenters so it will be worth your time to come and attend.
- Ed
If you are in the area I encourage you to come attend the event. There is a wonderful line up of topics and presenters so it will be worth your time to come and attend.
- Ed
Thursday, October 17, 2013
Network Field Day 6 - Post Mortem
It has been close to a month since I participated in Network Field Day 6 and I am finally getting a chance to write up my thoughts and feelings about the experience overall but also the companies that participated and hosted all the delegates to show us what they are doing.
First, a quick perspective on what Stephen Foskett is doing with Tech Field Day (and all the related events he is involved with) - simply amazing. I can't say enough about how impressed I was with the event. The engagement and quality of the delegates was fantastic and the overall experience of interacting and meeting folks of that caliber was really special. For that alone I give a tip of the hat to Stephen, Tom and Claire for all their hard work in pulling together such a unique opportunity and event.
Second, I have a slightly different perspective of things being a first time delegate and perhaps not as prolific a blogger as some of the other delegates. I thought since I have had some time to think about who I saw at NFD6 I would give you my impressions of the companies who presented and which has had a lasting impact of still being top of mind for me.
With that, I would say the lasting impact company has to be ThousandEyes. Thousand Eyes has an IT performance management platform that I can see a ton of different customers using to solve all sorts of unique problems that until now are relatively difficult to do.
First of all, the easiest way to see how their product works is to check out their videos that gives the overview. What struck me right away with what they were doing is how obvious it was and then wondering why no one had done that before! To me, that is the sign of a great product, when it just clicks and makes sense.
So what is unique about what they are doing? It is the marriage of good graphical monitoring solution with public and private agents but designed for monitoring SaaS applications. They aggregate information from both private agents (that you can run from any location you control) and public agent sites that they maintain. In addition, their service and design works so well that major SaaS providers are using it themselves to measure their performance. If you are responsible for measuring and reporting on SaaS SLA's at all than you should be seriously looking at what they are doing. That really is how they are unique. There are lots of performance monitoring tools out in the market but this is the first that marry together these functions and in an elegant way that is very intuitive.
To be fair, I was impressed with many of the other manufactures that participated in NFD6 and I will likely take a moment to put a blog article together on them also but of all the companies Thousand Eyes really stood out. So there you have it, a company you should really go check out what they are doing.
- Ed
Disclosure and Disclaimer:
Thousand Eyes (and other manufactures) participated in the Networking Field Day 6 event, thus indirectly covering some of my travel expenses. At no time did they ask for, nor where they promised any kind of consideration in the writing of this review. The opinions and analysis provided within are my own and any errors or omissions are mine and mine alone unless I specifically blame someone else for my mistakes, which is uncool but might happen.
First, a quick perspective on what Stephen Foskett is doing with Tech Field Day (and all the related events he is involved with) - simply amazing. I can't say enough about how impressed I was with the event. The engagement and quality of the delegates was fantastic and the overall experience of interacting and meeting folks of that caliber was really special. For that alone I give a tip of the hat to Stephen, Tom and Claire for all their hard work in pulling together such a unique opportunity and event.
Second, I have a slightly different perspective of things being a first time delegate and perhaps not as prolific a blogger as some of the other delegates. I thought since I have had some time to think about who I saw at NFD6 I would give you my impressions of the companies who presented and which has had a lasting impact of still being top of mind for me.
With that, I would say the lasting impact company has to be ThousandEyes. Thousand Eyes has an IT performance management platform that I can see a ton of different customers using to solve all sorts of unique problems that until now are relatively difficult to do.
First of all, the easiest way to see how their product works is to check out their videos that gives the overview. What struck me right away with what they were doing is how obvious it was and then wondering why no one had done that before! To me, that is the sign of a great product, when it just clicks and makes sense.
So what is unique about what they are doing? It is the marriage of good graphical monitoring solution with public and private agents but designed for monitoring SaaS applications. They aggregate information from both private agents (that you can run from any location you control) and public agent sites that they maintain. In addition, their service and design works so well that major SaaS providers are using it themselves to measure their performance. If you are responsible for measuring and reporting on SaaS SLA's at all than you should be seriously looking at what they are doing. That really is how they are unique. There are lots of performance monitoring tools out in the market but this is the first that marry together these functions and in an elegant way that is very intuitive.
To be fair, I was impressed with many of the other manufactures that participated in NFD6 and I will likely take a moment to put a blog article together on them also but of all the companies Thousand Eyes really stood out. So there you have it, a company you should really go check out what they are doing.
- Ed
Disclosure and Disclaimer:
Thousand Eyes (and other manufactures) participated in the Networking Field Day 6 event, thus indirectly covering some of my travel expenses. At no time did they ask for, nor where they promised any kind of consideration in the writing of this review. The opinions and analysis provided within are my own and any errors or omissions are mine and mine alone unless I specifically blame someone else for my mistakes, which is uncool but might happen.
Wednesday, September 25, 2013
I am speaking at TechMentor in Las Vegas Sept. 30 - Oct. 4 on IPv6
For those of you who are Windows admins and interested in learning about IPv6 I am doing a 3 hour session at TechMentor in Las Vegas next week, September 30th through October 4th. You can still sign up for the event. The conference over all is an excellent chance to learn from some of the best in the community, Greg Shields, Don Jones, Mark Minasi and many others. The exciting part is the change that TechMentor has put in place for their format, it is all hands on labs and deep dive sessions so you really get to learn a lot. The presenters aren't trying to sprint through content and can take the time to explain things and have much more engaging discussions about topics of interest.
My session is Mastering IPv6 for the Inspiring Windows Sever Administrator and I will be taking you from the basics of IPv6 through to some practical advise and a demo or two. So please join me in Las Vegas, perhaps we can chat all about IPv6 and what is happening with it. If not, we can always talk PowerShell, Hyper-V, System Center and Azure!
My session description:
Have you been scratching your head wondering what this IPv6 thing is all about and how it might impact you? Have you seen an IPv6 address and wondered how in the world do I subnet that? The first part of the session is focused on explaining the basics of IPv6 and how it is both different and similar to IPv4. The second part is how to set up a basic working configuration, best practices and common problems you may run into in deploying IPv6. We also cover the default assumptions Microsoft has in place for IPv6 and how that impacts your decisions and how you should manage your environment.
Hope to see you in Vegas!
- Ed
Friday, September 20, 2013
IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them
I am often asked interesting questions by fellow IT professionals about IPv6. Some are worthy of a blog post or two so here it is. The subject of IPv6 Unique Local Address or ULA (which is one of the unicast IPv6 address types) seems to be getting more attention now that IT professionals are actually looking at how to deploy IPv6. I thought I would share some brief information about ULA and follow up with my thoughts about it.
ULA is a unicast address type and is limited to the fc00::/7 prefix. This means the prefix has a fixed binary value of 1111 110x with ULA having the concept of a local flag bit (x) which is the 8th bit. This means the prefix is divided into fc00::/8 and fd00::/8. The local flag value of 0 hasn't been defined and therefore should not be used at all which eliminates the fc00:/8 prefix from being used. The local flag value of 1 indicates that the prefix is locally assigned. That means the only valid ULA addresses to use today are from the fd00::/8 prefix.
There have been a few interesting efforts to coordinate ULA prefix allocations. I have no idea why you would do this but you can check it out at SixXS's site. The reality is, fd00::/8 by definition is locally assigned and there is an algorithm defined in RFC 4193 that helps in generating a unique prefix out of that range to help avoid collisions or you can put your MAC address into the SixXS site and it will generate a prefix for you. You can find how the algorithm works in Section 3.2.2 if you want more details.
So what has sparked all this interest in ULA? I think it is happening because many IT organization think deploying IPv6 should be done in the same manner as IPv4. If you spend any time around IPv6 professionals you will quickly learn that IPv4 thinking doesn't apply when designing IPv6 networks. As an example, the role of NAT and address conservation are entirely thrown out the window. I think there is still a lot of confusion around the role of NAT and many IT professionals still consider NAT a security feature. NAT never was intended to be (and never functionally was) a security solution. All NAT provides is a way to conserve the use of public IPv4 addresses. If you disagree, I'm sorry, you are wrong.
Getting back on track, the analogy is often given that ULA is like IPv4 RFC 1918 address space. I believe this triggers people to think they should use ULA in the same way they are using RFC 1918 today. In other words, assign ULA everywhere on their internal network and run a NAT solution at their edge via a firewall or router. This looks exactly like what they do in IPv4. It also turns out that this is completely WRONG for IPv6.
It actually isn't accurate to say that ULA is like RFC 1918 address space. RFC 1918 address space was specifically set aside for the purpose of running NAT because of the shortage of public IPv4 addresses. There is no shortage of IPv6 address space and there will not be any within your lifetime, your children's lifetime or your grandchildren's lifetime or, well, you get the picture. So how is ULA like RFC 1918? The design of ULA was to have an IPv6 address space that would not route on the public IPv6 Internet - ever. In that capacity, ULA and RFC 1918 addresses are the same, neither was intended to be used on the public Internet at all. ULA was designed for labs or other resources (think secure military uses or maybe internal networks at power plants for example) that NEVER need to (or should ever) talk to the global Internet.
Let me repeat that, you use ULA when you never want to talk to anything on the Internet. I have seen many IT professionals say there should be NAT solutions in IPv6. There are some limited corner cases where solutions like NPTv6 (which is network prefix translation for IPv6) might solve some problems however I am not aware of any production ready implementations of NPTv6. In fact, the NPTv6 RFC is still in experimental status, see RFC 6296 and the former solution of NAT-PT has been moved to historical status, see RFC 4966 so really you have no robust NAT solution to date outside of server load balancing solutions like SLB66.
So what do you do? Simple, you reject your IPv4 ways of thinking and adopt the IPv6 way of thinking. You deploy global unicast IPv6 addresses throughout your network and use a stateful packet inspection firewall to control traffic and enforce security rules. You build good routing policies and leverage host based firewalls to enhance your security posture. In fact, you do all the same security measures you do for IPv4, you just happen to be using global unicast IPv6 address. Why? Because we have enough IPv6 addresses that we don't need NAT anymore.
What advantage do you gain by doing this? First, you don't break protocols that tend to embed address information in their session process. NPTv6 will still break protocols requiring firewalls and other network devices to try and do "fixups" or intelligent repairs on the fly to sessions. Why are we wasting time on that when if you simply use global unicast addresses with no network address translation then the protocol doesn't require any special handling.
Finally, it is easier to manage, complies with every design recommendation you will find out there on deploying IPv6 and reduces the chance you will have breakage for a service later (assuming your firewalls aren’t blowing it up – but at least you only have to look in one place for that issue).
So there you have it. In summary, ULA is appropriate for a lab, a proof of concept, a super secure network and maybe an out-of-band control network. Even then, I would still argue you could do all of those functions with global unicast addresses and simply put the correct routing and firewalls rules in place. ULA is designed to never be routed on the public IPv6 Internet and as a result you should not be assigning ULA to hosts in your network unless you have the correct use case. Otherwise, stick with global unicast IPv6 addresses. Do IPv6 right the first time so you don't have to go back and do it again. As a final thought I give you Andrew Yourtchenko's fun NAT YouTube video.
- Ed
ULA is a unicast address type and is limited to the fc00::/7 prefix. This means the prefix has a fixed binary value of 1111 110x with ULA having the concept of a local flag bit (x) which is the 8th bit. This means the prefix is divided into fc00::/8 and fd00::/8. The local flag value of 0 hasn't been defined and therefore should not be used at all which eliminates the fc00:/8 prefix from being used. The local flag value of 1 indicates that the prefix is locally assigned. That means the only valid ULA addresses to use today are from the fd00::/8 prefix.
There have been a few interesting efforts to coordinate ULA prefix allocations. I have no idea why you would do this but you can check it out at SixXS's site. The reality is, fd00::/8 by definition is locally assigned and there is an algorithm defined in RFC 4193 that helps in generating a unique prefix out of that range to help avoid collisions or you can put your MAC address into the SixXS site and it will generate a prefix for you. You can find how the algorithm works in Section 3.2.2 if you want more details.
So what has sparked all this interest in ULA? I think it is happening because many IT organization think deploying IPv6 should be done in the same manner as IPv4. If you spend any time around IPv6 professionals you will quickly learn that IPv4 thinking doesn't apply when designing IPv6 networks. As an example, the role of NAT and address conservation are entirely thrown out the window. I think there is still a lot of confusion around the role of NAT and many IT professionals still consider NAT a security feature. NAT never was intended to be (and never functionally was) a security solution. All NAT provides is a way to conserve the use of public IPv4 addresses. If you disagree, I'm sorry, you are wrong.
Getting back on track, the analogy is often given that ULA is like IPv4 RFC 1918 address space. I believe this triggers people to think they should use ULA in the same way they are using RFC 1918 today. In other words, assign ULA everywhere on their internal network and run a NAT solution at their edge via a firewall or router. This looks exactly like what they do in IPv4. It also turns out that this is completely WRONG for IPv6.
It actually isn't accurate to say that ULA is like RFC 1918 address space. RFC 1918 address space was specifically set aside for the purpose of running NAT because of the shortage of public IPv4 addresses. There is no shortage of IPv6 address space and there will not be any within your lifetime, your children's lifetime or your grandchildren's lifetime or, well, you get the picture. So how is ULA like RFC 1918? The design of ULA was to have an IPv6 address space that would not route on the public IPv6 Internet - ever. In that capacity, ULA and RFC 1918 addresses are the same, neither was intended to be used on the public Internet at all. ULA was designed for labs or other resources (think secure military uses or maybe internal networks at power plants for example) that NEVER need to (or should ever) talk to the global Internet.
Let me repeat that, you use ULA when you never want to talk to anything on the Internet. I have seen many IT professionals say there should be NAT solutions in IPv6. There are some limited corner cases where solutions like NPTv6 (which is network prefix translation for IPv6) might solve some problems however I am not aware of any production ready implementations of NPTv6. In fact, the NPTv6 RFC is still in experimental status, see RFC 6296 and the former solution of NAT-PT has been moved to historical status, see RFC 4966 so really you have no robust NAT solution to date outside of server load balancing solutions like SLB66.
So what do you do? Simple, you reject your IPv4 ways of thinking and adopt the IPv6 way of thinking. You deploy global unicast IPv6 addresses throughout your network and use a stateful packet inspection firewall to control traffic and enforce security rules. You build good routing policies and leverage host based firewalls to enhance your security posture. In fact, you do all the same security measures you do for IPv4, you just happen to be using global unicast IPv6 address. Why? Because we have enough IPv6 addresses that we don't need NAT anymore.
What advantage do you gain by doing this? First, you don't break protocols that tend to embed address information in their session process. NPTv6 will still break protocols requiring firewalls and other network devices to try and do "fixups" or intelligent repairs on the fly to sessions. Why are we wasting time on that when if you simply use global unicast addresses with no network address translation then the protocol doesn't require any special handling.
Finally, it is easier to manage, complies with every design recommendation you will find out there on deploying IPv6 and reduces the chance you will have breakage for a service later (assuming your firewalls aren’t blowing it up – but at least you only have to look in one place for that issue).
So there you have it. In summary, ULA is appropriate for a lab, a proof of concept, a super secure network and maybe an out-of-band control network. Even then, I would still argue you could do all of those functions with global unicast addresses and simply put the correct routing and firewalls rules in place. ULA is designed to never be routed on the public IPv6 Internet and as a result you should not be assigning ULA to hosts in your network unless you have the correct use case. Otherwise, stick with global unicast IPv6 addresses. Do IPv6 right the first time so you don't have to go back and do it again. As a final thought I give you Andrew Yourtchenko's fun NAT YouTube video.
- Ed
Tuesday, September 17, 2013
Cricket Liu presenting on IPv6 at Dyn Geek Summer Camp
Cricket Liu who is the VP of Technology and Architecture at Infoblox recently gave a wonderful IPv6 presentation at Dyn's Geek Summer Camp that I encourage you to watch. I have embedded it in this post for your viewing pleasure. He has some great points about the issues with IPv4 depletion and what will be happening long term with IPv6 adoption.
- Ed
- Ed
Tuesday, September 03, 2013
Network Field Day 6 - I am a delegate - look out
I've been pretty fortunate to get to know some wonderful people in the IT field over my career. Between Microsoft MVP's, IPv6 Task Force members, colleagues from the VAR/Integrator/Partner community and the tons of folks I have meet at IT conferences as both a speaker and a participant. Every one of them has expanded my horizons of what is happening in the IT field through their own lens of opinion.
With that said, some folks definitely stand out in terms of influence in the community and Stephen Foskett is one of them. It turns out his lens of influence and reach is more expansive then the vast majority I meet in IT. At the same time he is able to be laser focused on the important topics of the day. Really a remarkable feat IMHO. As a result, Stephen has attracted an army of individuals around him both socially and professionally that are doing interesting and exciting things. They have opinions worth listening too, blogs worth reading and ideas worth considering.
Stephen runs Gestalt IT and puts together the Tech Field Day events. His team reaches out to the community of "influencers" and if you are lucky enough you get invited to be a delegate for one of the Tech Field Day events. I consider myself lucky because I will be participating in Network Field Day 6 as a delegate happening the week of September 11-13, 2013 in Silicon Valley. I am excited to hear from the line up of sponsors for the event. They are:
As an engineer I find these sort of engagement opportunities to be of very high value. I like hearing what other bright and articulate individuals have to say about companies, products and markets and have those companies in the room participating interactively. I have learned a lot and had many interesting discussions from watching other Tech Field Day events that are available on the website. In addition, you can watch a live video stream of many of the presentations while they are happening. I encourage you to engage with all the delegates on Twitter, so feel free to bug me (@ehorley) while the Network Field Day 6 sponsors are presenting. I'm happy to ask questions or make comments on your behalf if one of the other delegates doesn't ask the question first! I believe we will be using the hashtag #NFD6 so please reach out and participate.
Also keep an eye out here on my blog as I will likely take some time to put down some thoughts about what I found interesting from the event. It might take me a bit of time since I am still writing my book (yes, I know, nothing but excuses!)
- Ed
With that said, some folks definitely stand out in terms of influence in the community and Stephen Foskett is one of them. It turns out his lens of influence and reach is more expansive then the vast majority I meet in IT. At the same time he is able to be laser focused on the important topics of the day. Really a remarkable feat IMHO. As a result, Stephen has attracted an army of individuals around him both socially and professionally that are doing interesting and exciting things. They have opinions worth listening too, blogs worth reading and ideas worth considering.
Stephen runs Gestalt IT and puts together the Tech Field Day events. His team reaches out to the community of "influencers" and if you are lucky enough you get invited to be a delegate for one of the Tech Field Day events. I consider myself lucky because I will be participating in Network Field Day 6 as a delegate happening the week of September 11-13, 2013 in Silicon Valley. I am excited to hear from the line up of sponsors for the event. They are:
As an engineer I find these sort of engagement opportunities to be of very high value. I like hearing what other bright and articulate individuals have to say about companies, products and markets and have those companies in the room participating interactively. I have learned a lot and had many interesting discussions from watching other Tech Field Day events that are available on the website. In addition, you can watch a live video stream of many of the presentations while they are happening. I encourage you to engage with all the delegates on Twitter, so feel free to bug me (@ehorley) while the Network Field Day 6 sponsors are presenting. I'm happy to ask questions or make comments on your behalf if one of the other delegates doesn't ask the question first! I believe we will be using the hashtag #NFD6 so please reach out and participate.
Also keep an eye out here on my blog as I will likely take some time to put down some thoughts about what I found interesting from the event. It might take me a bit of time since I am still writing my book (yes, I know, nothing but excuses!)
- Ed
Thursday, August 15, 2013
Practical IPv6 for Windows Administrators - yes, I am writing a book
After hearing many time at conferences, trade shows, user groups and even by customers "All I need is a fast primer to get me up and going with IPv6 plus some best practices" I decided to do something about it. I wrote a book proposal and submitted it to some colleagues at Apress and they decided it would actually be worth doing, which I still find kind of amazing.
So, I have been rather busy working on the book content and not blog posting as much as I like but I hope everyone understands why.
The book covers what Windows Administrators need to know to get up and operational with IPv6. I know, why Microsoft Windows and not something that covers all OS's? First off, there are other good books out there that help with the other OS platforms (with the exception of Apple - who know what is happening there?) and there was a gap in good content for the Windows platform IMHO. Second, I am a Microsoft MVP and a Networking Engineer by trade so it was a natural fit. I have been presenting at events like Microsoft TechEd, TechMentor and IPv6 conferences for several years and all my presentations revolve around IPv6 and Microsoft Windows it seems.
The book will have 10 chapters and the goal is about 250 pages at this point. The chapters are:
So, I have been rather busy working on the book content and not blog posting as much as I like but I hope everyone understands why.
The book covers what Windows Administrators need to know to get up and operational with IPv6. I know, why Microsoft Windows and not something that covers all OS's? First off, there are other good books out there that help with the other OS platforms (with the exception of Apple - who know what is happening there?) and there was a gap in good content for the Windows platform IMHO. Second, I am a Microsoft MVP and a Networking Engineer by trade so it was a natural fit. I have been presenting at events like Microsoft TechEd, TechMentor and IPv6 conferences for several years and all my presentations revolve around IPv6 and Microsoft Windows it seems.
The book will have 10 chapters and the goal is about 250 pages at this point. The chapters are:
- IPv6: The Big Picture
- IPv6 Support in Windows
- IPv6 Addressing
- IPv6 Best Practices in Windows
- IPv6 and PowerShell
- IPv6 and Advanced Firewall
- IPv6 in Hyper-V and Virtual Networking
- IPv6 and DNS
- IPv6 and DHCP
- Miscellaneous IPv6 Item
Practical IPv6 for
Windows Administrators is designed to be a handy guide on implementing IPv6
in a Microsoft Windows environment. If you are a Microsoft Windows
Administrator who suddenly finds themselves having to deal with IPv6 and in need
of a quick resource to get up and going this book is for you. It is meant to be
the fast reference you pull out to get something done. I hope it will have
sticky notes with scribbled comments and highlighted sections and coffee stains
because it is something you find that useful.
The book covers the current state of IPv6 and its support in
Microsoft Windows and then provides an explanation of IPv6 Addressing, Best
Practices and how to implement. From managing IPv6 with PowerShell, to the
Advanced Firewall to what is supported in Hyper-V and Virtual Networking it
provides practical examples of IPv6. It also addresses how IPv6 integrates with
all the standard tools you use for IPv4 today like DNS, DHCP and concludes with
a summary of insider knowledge on IPv6 that could be stumbling points on the
road to deployment.
You can read Practical
IPv6 for Windows Administrators from end to end but I envisioned it to be
treated as a handbook. Each chapter stands on its own so if, for example, you
just need to know how to get DNS working you can read Chapter 8 and be good to
go. Now let’s go implement IPv6 in your Windows environment!
So this book:
That is it in a nutshell. I'm excited to be putting the content together and hopefully it will be out in the beginning of 2014. In the meantime, go check out the other great titles from Apress.
- Ed
So this book:
- Allows Windows Administrators who already know IPv4 a quick way to learn IPv6
- Provides Windows specific best practices in dealing with IPv6 and Dual Stack networks
- Has practical examples to help manage IPv6 in Windows
That is it in a nutshell. I'm excited to be putting the content together and hopefully it will be out in the beginning of 2014. In the meantime, go check out the other great titles from Apress.
- Ed
Monday, August 12, 2013
Software-Defined Data Center Symposium is September 10, 2013 in Santa Clara, CA
Seems that Tech Field Day and SDN Central are planning a Software-Defined Datacenter Symposium that will September 10th at the Network Meeting Center at Techmart in Santa Clara, CA.
The event should be appropriate for anyone interested in OpenFlow, software-defined networking (SDN), software-defined storage, convergence, and private/public/hybrid cloud.
So if you are into OpenStack, CloudStack, VMware, Microsoft Private Cloud, AWS, or any of the other major cloud and platform players you will likely find something useful at the event. The nice part is that Stephen Foskett slipped me a discount code for getting a bit off from the list price for the event (because he is nice guy and a fellow Microsoft MVP!)
I will be attending myself so I hope to see some of my colleagues who are actively involved with OpenStack and the Microsoft Cloud arena attending. We can banter back and forth about what might happen in the future for our industry. The event is being sponsored by Embrane, NEC, NuageNetworks, Nutanix and Plexxi. I would not be surprised to see more jump on board as Stephen hosts top notch events and the topic is timely and relevant to what is happening in the industry.
- Ed
Wednesday, July 24, 2013
Enterprise IPv6 Video with Jeff Doyle and Shannon McFarland
Seems that the video shoot I did with Jeff Doyle and Shannon McFarland over 6 months ago might finally come out. They have a preview available on YouTube so go take a look and please leave feedback and comments.
It is a huge honor to be able to talk IPv6 with such legends as Jeff and Shannon. I even managed to sneak in Joseph Davies' Understanding IPv6, Third Edition into the video shoot, it is on top of Shannon's Cisco Press title he co-authored, IPv6 for Enterprise Networks on the table in front of me.
- Ed
It is a huge honor to be able to talk IPv6 with such legends as Jeff and Shannon. I even managed to sneak in Joseph Davies' Understanding IPv6, Third Edition into the video shoot, it is on top of Shannon's Cisco Press title he co-authored, IPv6 for Enterprise Networks on the table in front of me.
- Ed
Thursday, July 11, 2013
Another year as a Microsoft MVP
I'm a little late getting the news out but I am happy to say I was renewed as a Microsoft MVP for another year. Many thanks to all those in the Microsoft MVP program for continuing to recognize my community contributions, I hope I can continue to live up to the award standards in the years to come. Eventually someone will get tired of hearing me go on and on about IPv6 but for now it seems there is some value in preaching the IPv6 message.
It also turns out this year is my 10th award. I find it hard to believe it has been 10 years since I was first an MVP and I am not sure how I feel about crossing that milestone. I'll let you know later after I have thought about it some more - or I will just avoid it altogether.
Congratulations to all the other renewing MVP's and a huge tip of the hat to brand new MVP's. It takes awhile to understand what just happened to you, enjoy it and make the effort to attend the MVP Summit, it really is worth your time.
- Ed
It also turns out this year is my 10th award. I find it hard to believe it has been 10 years since I was first an MVP and I am not sure how I feel about crossing that milestone. I'll let you know later after I have thought about it some more - or I will just avoid it altogether.
Congratulations to all the other renewing MVP's and a huge tip of the hat to brand new MVP's. It takes awhile to understand what just happened to you, enjoy it and make the effort to attend the MVP Summit, it really is worth your time.
- Ed
Wednesday, July 03, 2013
IPv6 only networks
After having a fun twitter exchange with Andrew Yourtchenko on some post Cisco Live! IPv6 presentations that Andrew gave on MAP we ended up chatting about IPv6 only networks and some of the challenges we will face in the next phase of the IPv6 transition. While many of those in IT haven't even gotten their arms around deploying IPv6 there are folks looking ahead to address what to do when you run an IPv6 only network.
It turns out that many client OS behavior is NOT what you want. Particularly in the mobile device space which is ironic since mobile is driving many of the needs for IPv6. There are dependencies on IPv4 or some deployments simply lack functional support to operate when in an IPv6 only network. Android will wait on RFC 6106 for RDNSS support but most networks do not provide that however it does NOT support DHCPv6 via wifi soooo, the device will get an IPv6 address but then do nothing because it has no DNS information at all.
Andrew gave a nice presentation at RIPE earlier this year that is worth watching to understand what the core problem currently is with running an IPv6 only network. His presentation is at https://ripe66.ripe.net/archives/video/1196/
Just for fun, set up an IPv6 only network and see if you can get your environment working. You should be able to hit an IPv6 dual stacked site to determine what is and is not working. If you need some IPv6 sites to try here is a short list to get you started:
http://www.cav6tf.org/
http://www.nav6tf.org/
http://test-ipv6.com/
- Ed
It turns out that many client OS behavior is NOT what you want. Particularly in the mobile device space which is ironic since mobile is driving many of the needs for IPv6. There are dependencies on IPv4 or some deployments simply lack functional support to operate when in an IPv6 only network. Android will wait on RFC 6106 for RDNSS support but most networks do not provide that however it does NOT support DHCPv6 via wifi soooo, the device will get an IPv6 address but then do nothing because it has no DNS information at all.
Andrew gave a nice presentation at RIPE earlier this year that is worth watching to understand what the core problem currently is with running an IPv6 only network. His presentation is at https://ripe66.ripe.net/archives/video/1196/
Just for fun, set up an IPv6 only network and see if you can get your environment working. You should be able to hit an IPv6 dual stacked site to determine what is and is not working. If you need some IPv6 sites to try here is a short list to get you started:
http://www.cav6tf.org/
http://www.nav6tf.org/
http://test-ipv6.com/
- Ed
Monday, July 01, 2013
Some additional IPv6 RFC's
I have been going through some IPv6 book chapters and doing IPv6 RFC review and there are a few that I think are of interest to add to your short list - if you keep one for IPv6. If not, there is a pretty comprehensive list at http://www.ipv6now.com.au/RFC.php
First up is RFC 6540 which is titled "IPv6 Support Required for All IP-Capable Nodes" and can be found at http://tools.ietf.org/html/rfc6540
Second up is RFC 6877 which is titled "464XLAT: Combination of Stateful and Stateless Translation" http://tools.ietf.org/html/rfc6877
Third is RFC 6866 which is titled "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Network" http://tools.ietf.org/html/rfc6866
Fourth is RFC 6853 which is titled "DHCPv6 Redundancy Deployment Considerations" http://tools.ietf.org/html/rfc6853
Finally, you really need to keep RFC 6724 handy to understand how your OS is selecting a default IPv6 address to use, it is titled "Default Address Selection for Internet Protocol Version 6 (IPv6)" http://tools.ietf.org/html/rfc6724
Hope these are useful. There are a lot more IPv6 RFC's that have been published recently, mainly around mobile operators and their need requirements but it is nice seeing a lot of work happening to keep the IPv6 bandwagon moving forward.
- Ed
First up is RFC 6540 which is titled "IPv6 Support Required for All IP-Capable Nodes" and can be found at http://tools.ietf.org/html/rfc6540
Second up is RFC 6877 which is titled "464XLAT: Combination of Stateful and Stateless Translation" http://tools.ietf.org/html/rfc6877
Third is RFC 6866 which is titled "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Network" http://tools.ietf.org/html/rfc6866
Fourth is RFC 6853 which is titled "DHCPv6 Redundancy Deployment Considerations" http://tools.ietf.org/html/rfc6853
Finally, you really need to keep RFC 6724 handy to understand how your OS is selecting a default IPv6 address to use, it is titled "Default Address Selection for Internet Protocol Version 6 (IPv6)" http://tools.ietf.org/html/rfc6724
Hope these are useful. There are a lot more IPv6 RFC's that have been published recently, mainly around mobile operators and their need requirements but it is nice seeing a lot of work happening to keep the IPv6 bandwagon moving forward.
- Ed
Friday, June 28, 2013
Microsoft blog - Ask Premier Field Engineering (PFE) Platforms
The Ask Premier Field Engineering (PFE) Platforms Blog has been doing some posts on IPv6 recently and they are worth checking out. They cover a lot more then just IPv6 but it nice to see that the Microsoft Premier Field Engineers understand how important IPv6 is to Windows. So kudos to the team and thanks for the posts.
Specifically, the did a post titled:
IPv6 for the Windows Administrator: Why you need to care about IPv6
and also:
IPv6 for the Windows Administrator: IPv6 Fundamentals
Both are worth the time to read and both were written by Mark Morowczynski.
- Ed
Specifically, the did a post titled:
IPv6 for the Windows Administrator: Why you need to care about IPv6
and also:
IPv6 for the Windows Administrator: IPv6 Fundamentals
Both are worth the time to read and both were written by Mark Morowczynski.
- Ed
Monday, June 24, 2013
Cisco's TechWise TV - IPv6: Is it time?
Alain Fiocco and Kumar Reddy do a great IPv6 show with TechWise TV that you should check out. It is Cisco specific but it is still a great resource to watch and learn about what Cisco is doing around IPv6.
Both Alain and Kumar presented at the North American IPv6 Summit in Denver, CO in May 2013. You can check out their presentations at:
http://rmv6tf.org/wp-content/uploads/2013/04/4-2013-04-11-NA-IPv6-Summit-afiocco.pdf
http://rmv6tf.org/wp-content/uploads/2013/04/5-2013-04-17-RMv6TF-kreddy-02.pdf
Alain has some great information around global IPv6 adoption and you can get more information at Cisco IPv6 Lab Stats page at:
http://6lab.cisco.com/stats/
Kumar gives so awesome insights into what Cisco has done to tune their wireless solutions to work well with IPv6 clients.
It turns out they are both on Twitter too so follow them:
@alainfiocco
@kumarreddy
Also, Cisco's IPv6 Lab is providing the stats via a wiget plugin too which looks like:
You can get the widget code at:
http://6lab-stats.com/index.php
Enjoy!
- Ed
Both Alain and Kumar presented at the North American IPv6 Summit in Denver, CO in May 2013. You can check out their presentations at:
http://rmv6tf.org/wp-content/uploads/2013/04/4-2013-04-11-NA-IPv6-Summit-afiocco.pdf
http://rmv6tf.org/wp-content/uploads/2013/04/5-2013-04-17-RMv6TF-kreddy-02.pdf
Alain has some great information around global IPv6 adoption and you can get more information at Cisco IPv6 Lab Stats page at:
http://6lab.cisco.com/stats/
Kumar gives so awesome insights into what Cisco has done to tune their wireless solutions to work well with IPv6 clients.
It turns out they are both on Twitter too so follow them:
@alainfiocco
@kumarreddy
Also, Cisco's IPv6 Lab is providing the stats via a wiget plugin too which looks like:
You can get the widget code at:
http://6lab-stats.com/index.php
Enjoy!
- Ed
Wednesday, June 19, 2013
Update on Google IPv6 geo location issues
Turns out Google seems to turn around fixing the geo location issue pretty quickly. I tested again and it appears they have fixed it. And on an unrelated note, apparently attempting to log into your gmail via IPv6 can set off security alerts too. I got (filtered a bit of the message, so no quotes):
Someone recently tried to use an application to sign in to your Google Account - <filtered>@gmail.com.
We prevented the sign-in attempt in case this was a hijacker trying to access your account. Please review the details of the sign-in attempt:
If you do not recognize this sign-in attempt, someone else might be trying to access your account. You should sign in to your account and reset your password immediately
If you need to submit a request to fix your IP geo location info with Google use this link:
https://support.google.com/websearch/contact/ip
- Ed
Someone recently tried to use an application to sign in to your Google Account - <filtered>@gmail.com.
We prevented the sign-in attempt in case this was a hijacker trying to access your account. Please review the details of the sign-in attempt:
Wednesday, June 19, 2013 2:09:31 PM UTC
IP Address: 2001:470:<filtered>:<filtered>:<filtered>:<filtered>: Location: United States |
|
If you do not recognize this sign-in attempt, someone else might be trying to access your account. You should sign in to your account and reset your password immediately
If you need to submit a request to fix your IP geo location info with Google use this link:
https://support.google.com/websearch/contact/ip
- Ed
Tuesday, June 18, 2013
Some odd Google IPv6 geo location issue
It seems that Google's IPv6 geo location database isn't as clean as it needs to be and this has caused my family some grief over the last few weeks. I run dual stack at home and I run both my wired and wireless networks at home with IPv4 and IPv6. My older daughter just returned home from college and fired up her laptop and when she attempts to go to http://www.google.com she is redirected to http://www.google.com.tw which she found rather alarming. In addition, all her searches and links were coming back with Chinese characters and links obviously due to this. This seems to affect YouTube and all other Google services also.
Turns out the IPv6 tunnel broker I use from Hurricane Electric has assigned me out an IPv6 prefix from their Fremont 2 facility and for some odd reason the prefix is being tagged by Google as being located in Taiwan. This is the reason that the web request is being redirected to the .tw domain instead of the regular .com domain.
This isn't a huge deal for me as I can make tweaks to my daughter's laptop and fix the issue. For many others who may start to be provided IPv6 addresses as part of a nationwide rollout for their ISP this could be a HUGE problem. Granted, you would hope that Google would work with local service providers to keep that database relatively accurate but it seems Google hasn't yet responded to Hurricane's requests to fix it even though Hurricane has provided them with a full accounting of their IPv6 prefix locations (or it is my understanding that they have provided it.)
If you have problems with your IPv6 prefix not being properly geo located with Google you can submit your information at this link and see if it is fixed. A quick warning, the form doesn't take the /64 prefix portion, just the address so leave the prefix off. As a side note, this submission form works for IPv4 too.
- Ed
Turns out the IPv6 tunnel broker I use from Hurricane Electric has assigned me out an IPv6 prefix from their Fremont 2 facility and for some odd reason the prefix is being tagged by Google as being located in Taiwan. This is the reason that the web request is being redirected to the .tw domain instead of the regular .com domain.
This isn't a huge deal for me as I can make tweaks to my daughter's laptop and fix the issue. For many others who may start to be provided IPv6 addresses as part of a nationwide rollout for their ISP this could be a HUGE problem. Granted, you would hope that Google would work with local service providers to keep that database relatively accurate but it seems Google hasn't yet responded to Hurricane's requests to fix it even though Hurricane has provided them with a full accounting of their IPv6 prefix locations (or it is my understanding that they have provided it.)
If you have problems with your IPv6 prefix not being properly geo located with Google you can submit your information at this link and see if it is fixed. A quick warning, the form doesn't take the /64 prefix portion, just the address so leave the prefix off. As a side note, this submission form works for IPv4 too.
- Ed
Thursday, May 30, 2013
Microsoft Office 365 and IPv6 Support
It is pretty cool to see Microsoft turning up more services on IPv6. If you are a user of Office 365 like my company is then you too can use IPv6 to access O365 resources.
Microsoft has an Office 365 IPv6 Wiki Page that outlines the IPv6 addresses they are using for the service. They are using a lot of /64 subnets but what I find odd is that they have not summarized them to specific prefixes to make filtering (for those that do it) easier. It would also be nice if they published it as an xml or Excel file to allow folks to use wget or PowerShell to remotely get the file for updates and be able to parse it and run a script against it to allow everyone to keep their filters current. I guess the other option is the use dig and a recursive DNS AAAA lookup to get all the same information potentially.
Microsoft also has a portal for getting the URL and IP address information they are using for Office 365 in general and that is here. It is useful because it breaks down by address each of the services so if you are really detailed (perhaps a bit too much?) you can limit based off that too.
There have been some reported outages on the IPv6 side for Office 365 and Mark Minasi and I have traded some jokes back and forth about his experience using his Verizon mifi that provides IPv6 but which often breaks his Office 365 access or at least it appears too - I think we need to troubleshoot it a bit more.
If you are wondering what products from Microsoft are at in terms of IPv6 support then look no further - you can find that information here.
- Ed
Microsoft has an Office 365 IPv6 Wiki Page that outlines the IPv6 addresses they are using for the service. They are using a lot of /64 subnets but what I find odd is that they have not summarized them to specific prefixes to make filtering (for those that do it) easier. It would also be nice if they published it as an xml or Excel file to allow folks to use wget or PowerShell to remotely get the file for updates and be able to parse it and run a script against it to allow everyone to keep their filters current. I guess the other option is the use dig and a recursive DNS AAAA lookup to get all the same information potentially.
Microsoft also has a portal for getting the URL and IP address information they are using for Office 365 in general and that is here. It is useful because it breaks down by address each of the services so if you are really detailed (perhaps a bit too much?) you can limit based off that too.
There have been some reported outages on the IPv6 side for Office 365 and Mark Minasi and I have traded some jokes back and forth about his experience using his Verizon mifi that provides IPv6 but which often breaks his Office 365 access or at least it appears too - I think we need to troubleshoot it a bit more.
If you are wondering what products from Microsoft are at in terms of IPv6 support then look no further - you can find that information here.
- Ed
Thursday, April 25, 2013
Some thoughts from the 2013 North American IPv6 Summit
After spending the last few days in Denver, CO participating in the largest IPv6 event in North America (and freezing due to a cold front moving through and dumping snow - in April no less!) I have come up with some take aways.
First, there are several dilemmas in the industry affecting adoption of IPv6. Specifically, the lack of content providers having their content available via IPv6. The disparate performance differences on the public Internet for IPv6 vs. IPv4 and the fact that it is not being accurately measured or even being paid attention to by the majority of service providers. And finally the challenge that enterprises are having in deciding between DHCPv6 stateful vs. DHCPv6 stateless vs. wanting to use SLAAC w/ RFC 6106 (no thanks to Android for making that problem worse.)
Second, the lack of interest, press coverage and buzz around IPv6 is upsetting, even the home page of Network World did not have a single mention of the word IPv6 after the last day of the Summit (actually any day of the summit.) I was surprised this year by how many colleagues and friends felt it more important to attend OpenStack in Portland and ONS in San Jose rather than attend the IPv6 Summit. What is even more alarming is the fact that both those events are around technologies that MUST have robust IPv6 support or they will fail long term, in other words they will have no market if they don't have an IPv6 solution. Perhaps it was just unfortunate timing that all three events were the same week but there were some noticeable gaps in attendance and in some key luminaries who chose to attend some of the other events. Granted, the weather, American Airlines having issues which grounded its fleet and the horrible news from Boston and it's subsequent lock down likely had an impact on attendance. Even with that I still feel the messaging on how important IPv6 will be to those in the IT community can't be over emphasized and I find it alarming more people are not participating and learning about IPv6. This event is a rare opportunity to learn arguably one of the most important basic skills you will need in your career as an IT Professional regardless of role. As a side note, both OpenStack and ONS sold out but the NA IPv6 Summit still had room for more attendees. I am not sure why that is and would love to hear what others think about that.
Third, the slow realization that IPv6 is not accelerating but is actually slowing down in adoption. The application rate for Provider Independent (PI) space is slowing, the role outs of IPv6 to service provider customers is not happening at an impactful rate and because of the lack of content its use will languish until more Enterprises feel it is important to have as a transport option. There is serious case to wonder if IPv6 will make it or if everyone will decide to make horrible IPv4 NAT on NAT on NAT (NAT444) solutions and just deal with brokenness and performance problems indefinitely. Perhaps they are hoping that eventually it will be somebody else's problem to deal with.
So, in summary, while I am a huge IPv6 advocate I am getting tired of being ridiculed by manufactures, peers, industry pundits and customers whenever I bring up the topic of IPv6 and adoption and everyone's response is "isn't that dead" or "no one actually uses IPv6" or "I hope to retire before I have to learn that" as quips back to my inquiry. Honestly, I am to the point now where my response is going to be "be part of the solution or get the heck out of the way" with perhaps some expletives in the mix depending on the audience. As an anecdotal side note, I have had several long time IPv6 colleagues and industry leaders tell me they are not focusing as much on IPv6 due to the incredible frustration of it being ignored and the frightening thought that IPv6 might not actually make it as a legitimate technology solution due to the lack of interest and adoption. Apparently growth for the Internet just really isn't that important.
- Ed
Co-chair, CA IPv6 Task Force
Subscribe to:
Posts (Atom)