Jordi Palet Martinez

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