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)
“In general, I do think the article of Jordi Palet Martinez is a useful one. I did prior, as a program manager, most of the implementation of IPv6 within a large Dutch ISP. Most of the really important topics for a successful implementation, I think, are mentioned in this article. But in regards to this, I would like to emphasise the following: - When starting an implementation, both mindset and knowledge about IPv6 are really important. Off course, together with a lot of mission work towards all layers of management concerning the necessity to implement IPv6. - Do the IPv6 implementation with a bottom-up approach. Most complexity and functionality is in the CPE. It’s a service endpoint and is a point of vulnerability from security perspective. Test IPv6 on your CPE's first in a lab environment in conjunction with the supplier/vendor. Use it for the technicians to get acquainted with IPv6 and it’s behaviour. Like always: Start on cracking the hardest nut first! For projects with a commercial justification (Business Case) like IPv6, it’s important to keep up the pace. Always avoid losing priority over other projects! - Involve the security department from the beginning and have them co-test the IPv6 product in the lab environment on all possible security vulnerabilities. The way IPv6 is designed in regards to the CPE (e.g. No NAT anymore) creates new vulnerabilities. Use this input for a proper security plan. Important here: Implementing IPv6 is actually quite simple. Implementing IPv6 with respect to subscriber’s privacy and with sufficient level of security is a different ballgame. And the last one is what this implementation is all about (At least, I hope if I was the subscriber here). Also, don’t hesitate to do one or more security audits all over the project, it provided us surprising but very useful results! - In parallel, make sure there is a solid IPv6 plan. Allocating the right amount of address space to subscribers is very important off course but besides that, there is only one chance to design the network “first time right”. We did analyse our biggest operational challenges we had in relation to IP(v4) maintenance. We found out that we had spent over the years a huge amount of effort on shuffling, renumbering and migrating subscribers over different parts of the network, based on capacity growth, adding acquired networks and constantly balancing CMTS capacity in relation to segmentation and usage. Try to learn from the past and make smart choices towards the future. IP Address Management (IPAM) is mandatory to keep control of maintenance costs on the long term, although the importance of this is hardly never acknowledged at initial stage. - Once this is all in place or in good progress, certifying and implementing IPv6 on DNS services, within the Backbone and so on is relatively straight forward. - Implementing, like also suggested in the article needs a proper pilot. In our initial implementation, we faced several serious production issues. We couldn’t have handled those if we would have activated IPv6 over the entire footprint. I consider this a “no brainer”. Good luck with implementing, please don’t hesitate to share your findings here. Also, feel free to consult me if you feel the need to.”
Thanks a lot Vincent, totally agree with your inputs!
“It might not be as hard for ISP as at first evaluation. I've gone through this. For example in the case of an ISP where most or all of their CPE routers are managed. The ISP knows what size delegated prefix the managed CPE will request. By default, if the CPE doesn't specify the assignment size requested the server will send the default size. The vast majority of CPE will be non-managed and request a non-default assignment. Only a small percentage of CPE request a larger prefix. As the CPE base does not change rapidly there is time to expand pools if required. I've got a /29. If I gave a /48 by default with the same simple pool design to all subs I'd need a /22. So there's complexity on the other side of this too as I'd have to change the pool design.”
Agree, and if you have a number of customers that means that you need a /22 in order to be able to provide a /48 to each end-site, this is very easy to justify to RIPE NCC, and there should not be an issue. I've been in situations requesting a /24, so close to that.
“Another option for the customer delegated prefix assignment size policy is to accept requests for PDs between /64 and /48 inclusive and have a default PD size for when it isn't specified in the DHCPv6 client request.”
Agree, but this is not making easy for the ISPs to make the addressing plan ... unless they reserve by default, for example /48 to each customer.
“Between the options of dynamic and static there is also the possibility of dynamic but sticky DHCPv6 PD leases. With sticky leases the DHCP server remembers the client had a lease for a configurable longer period after the expiration of the valid-lifetime that is advertised to CPE DHCP server. Normally the sticky lease will be deleted if the DHCP client sends a release message. For even greater stickiness it can be possible to ignore these releases. If the PD changes the CPE needs to follow RFC 7084 L-13 for the old prefix.”
Yeah, I've actually indicated it using a different terminology ("lease time very long").
“I knew about the survey. The reason I asked about using the RIPE Database data is that the RIPE NCC now has over 10,000 members with IPv6 (https://labs.ripe.net/Members/nathalie_nathalie/10-000-lirs-with-ipv6-resources). This is a very large number and the 368 survey responses from the RIPE NCC service region might not be representative. I don't know what proportion of LIRs use the "assignment-size:" attribute. If it is widely used, it might be possible to get an even more representative measurement than the survey.”
Now I understood what you mean and indeed I agree, that will be very interesting. The question is that it will be necessary also to discriminate among those LIRs, which of them actually are doing IPv6 services, and other issues such as if they are really "ISPs" in the sense of provide connectivity to customer end-sites (instead for example big corporations being a LIR for their own infrastructure, or data centers, etc.).
“This pair of articles is interesting and informative. It would be interesting to know what proportion of ISPs have chosen to assign subscribers a prefix longer than /48. Is it practical to analyze the amount of space cut into /56s versus /48s (or other prefix lengths) using an analysis of "assignment-size:" attributes in inet6num objects in the RIPE Database?”
If you look at the figures of my survey (I will update it with more data I've got in the last months), 22% use /48, 35% /56, 33% /64 and 10% something else. Most of the /64 deployments are in LACNIC region and hopefully will move to /48. If you look at my presentation at the Madrid RIPE meeting, you will find how it correlates to countries/regions. Actual figures from the new survey responders in the latest months, show a higher trend towards /48, fortunately! https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-deployment-survey
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.
Showing 22 comment(s)