Based in Spain
Articles
Likes on articles
Jordi Palet Martínez has been working with computers, networking and technology since he was 8 years old. The last 17 years, as CEO/CTO at "The IPv6 Company", devoted most of his time to IPv6 R&D, standardization, training and consultancy, having worked already with IPv6 customers in 110 countries in the world. He has co-authored a number of RFCs and books related to IPv6 and contributed to IPv6 training and policy making in all the RIRs.
• 10 min read
In the first part of this two-part series, I shared a recent IPv6 deployment case study I worked on for a government network in the LACNIC region, concentrating on the hereditary peculiarities in the network that we had to overcome, many of which are common among government and organisational netwo…
• 6 min read
In this article I will look at corporate networks, which include cases for governments, enterprises and other organisations.
• 6 min read
We are starting to hear “IPv6-only” more often. However, it doesn't seem to be clear what exactly this means. I will attempt to explain it in this article.
• 3 min read
Last year, I initiated a small survey to understand what approaches ISPs in Europe are taking to deploy IPv6, eventually expanding it to a global survey.
• 10 min read
One of the main issues when an ISP is planning to deliver IPv6 services is to decide how to address the customers. In this second part we describe choices for numbering the WAN and customer LANs.
• 7 min read
This document is not intended to be a comprehensive and detailed technical digest of how to deploy IPv6 in an ISP network that currently has IPv4. Instead it is an executive summary of the 12 fundamental steps, not including services (DNS, web, email, etc.), for native IPv6 support and the maintena…
• 12 min read
Over the past year, I have been conducting a public survey to better understand how ISPs deploy IPv6. In this post, I will summarise some of the key findings thus far.
• 4 min read
After 15 years conducting training on IPv6 in over 110 countries, I’ve been asked all sorts of questions. “How do I use my IPv6 addressing space?” “What prefix size should I provide to customers?” Although I have answers to these and many other best practice related questions, the one question, whi…
Showing 9 article(s)
You're right the right text should be: Let’s suppose a customer provisioned in the first stage with the prefix 2001:db8:1111::/48. Their devices are using, for our example, the first free /64 (2001:db8:1111:1::/64). Everything is fine until there is a power outage. The CPE boots up again when power is recovered, and because the ISP is using a non-persistent prefix, a new prefix is assigned (2001:db8:2222::/48), so now the CPE is announcing 2001:db8:2222:1::/64. However, the devices that have battery (laptops, tablets, smartphones) still have the previous prefix, so now they have two different prefixes (2001:db8:1111:1::/64 and 2001:db8:2222:1::/64). These devices will try to keep using the older one, and they will not work, as the ISP is no longer routing the first prefix to that customer. Just think: if another network failure or power outage were to happen now. Devices could then have three or even more prefixes. And the user will end up calling the ISP help-desk for troubleshooting because the network is not working. Regarding privacy, at the end the best way someone willing to track you has is apps fingerprinting and correlating data, not just addresses. Because the "tracker" can not be sure that it is the same "person" even if the address is the same, it may be several users in the same computer, it may be different computers using the same address at different times, etc.
“I'm curious off the implementation and performance differences between 464XLAT and DS-Lite. More information would be appreciated!”
There are several improvement factors. In DS-LITE you tunnel every IPv4 packet, and then you are doing NAT44 for each one of them as well. In 464XLAT you only do NAT46 (at the CLAT, so no overhead for the NAT64) for those packets that use literal IPv4 addresses, no tunneling. So there is more and more native IPv6 traffic, and only when the destination is IPv4-only then the NAT64 is used. So in general you have less overhead in at NAT64 than in a CGN as well. Finally, you're not restricting specific ports per user (CGN), you share IPs per flows (NAT64).
In my experience there are many failures due to CPE, and also wrongly configured DNS servers, but many more because PMTUD filtering (on purpose or by mistake, such as load balancers based in ECMP). Some ISPs, such as 1&1, even being aware of the problem, just ignore it, so anyone having a lower MTU can't access any of their customers web sites. Really bad and ugly, it took me almost 2 years to get a response from them and still waiting them for sorting it out ... Furthermore, happy eye-balls, in my opinion, is not doing a good job, so this means less IPv6 traffic that indeed we could have. Fortunately there is some ongoing work to update it (https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-01), even I think we should consider dropping it, as in IPv4 we don't have a similar thing, and this means when there are some issues in a network, the operators quickly realize about that, but unfortunately, happy eye-balls is hiding this in the majority of the cases.
“Good job, Jordi. I see that at the WAN level for point-to-point connections more than 60% of ISPs use a / 64. Some believe that a / 127 or / 124 is better for configuring the interfaces at each WAN end. ¿ What explanation will you find for this?. ¿ You recommend that each point-to-point WAN interface be configured with masks of / 127, / 124 or / 64 ?. Tks”
The point here is that in some situations, there is a need for other layer 3 devices to be in that link, so if you use a /127 you can't number them. Also, there are features that you may not use today, and require 64 bits, and if in the future you want to use, you will need to renumber. ¿What happens with technologies that today are point-to-point and later can become point-to-multipoint, or need addresses for redundancy, etc.?, again you will need to renumber. I think planning ahead and using /64 is not wasteful on IPv6 resources, but can save a lot of headaches and human resources later on. Last but not least, there are hardware architectures that if you use a /127 (or something else), is actually taking two slots, one for the /64, one for the /127, so this also means saving resources if you use /64. One possibility, that many ISPs are using, already mentioned in the article, simplifies many things, is using the /64 from the customer /48 for the point-to-point. So definitively I will encourage to use GUA /64, either from the same pool, a different pool, or the customer pool.
“Thanks for this Jordi, I just tweeted it out.”
Tks!
“Regarding monitoring, I've just recently have had a interessing experience. The just recently brought out Flow and Packet performance suite Steel Central from Riverbed is still lacking proper IPv6 support. I was very surprised that IPv6 isn't still not handled at the same priority as IPv4 in terms of development. So it's not always the engineers that may hesistate the extra or double effort when setting monitoring up, sometimes it's just the lack of IPv6 support in the monitoring tools. However, the post-sales guy from Riverbed promised improvement of IPv6 support on the road map.”
You're right, I should have mention that in most situations is not the engineer, are the tools. However, there are many "free" tools that may alleviate this, in case your vendor still didn't got it.
Showing 26 comment(s)