Posts by ZeroSum 85 publicly visible posts • joined 4 Oct 2010
Cameron Byrne in T-Mobile US even wrote the RFC on 464XLAT.
The individual or group theory of IPv6 adoption is undoubtedly the correct one. Until IPv6 is sufficiently ubiquitous or solves a problem (CGN bypass and in future 5G low latency) you will always find an individual or group that pushed it through their organisation
China's IPv4 address problem is a lot less acute than India's. China has about 330 million IPv4 addresses compared to India's 30 million. China has been able to get away so far with not too much CGN except in mobile.
To keep growing without needing massive CGNs they need to deploy IPv6.
> And can you change the /64 prefix like most ISPs allow you to do with the single IPV4 address?
> It's a bloody hard question to get a straight answer to.
The /64 for the LAN comes from the DHCPv6 delegated prefix assigned by the ISP. Most ISPs assign the delegated prefix dynamically from a pool instead of assigning it statically. Unless the ISP has configured dynamic leases to be sticky the DHCP server will forget the lease when the lease period expires or immediately if the DHCPv6 client sends a RELEASE.
> FWIW... HE doesn't need a static IPv4 address, works fine with dynamic, including a REST API to update your endpoint address.
Good thing too. If tunnel services required a static IPv4 to set-up an IPv6 tunnel it would be partially counter productive to the goal of increasing IPv6 deployment. Many ISPs get revenue for charging for static IPv4 addresses so they have an incentive to thwart the deployment of IPv6 as it will eventually remove the need for IPv4. Since IPv6 is in plentiful supply it will be harder for ISPs to justify charging for static IPv6.
> One publicly visible IP per device seems to me to be leaking private information. Anyone care to tell me why I'm wrong?
The devices now assign themselves temporary randomly generated addresses from the /64 prefix announced by the router which remains the same. That /64 prefix is analogous to the single public IPv4 address most ISPs assign which the CPE uses to NAT.
> Curious, if they adopt ipv6 will that be nat or would all the devices on my network get unique ipv6 addresses and bypass the firewall?
All devices on your network can assign themselves an IPv6 address from the /64 prefix announced by the router. The ISP router is likely to have an IPv6 stateful firewall that is on by default.
Four years ago the number of smartphones in the US was essentially zero. Now over 50% of them have IPv6. In another 4 years almost all of them will have IPv6. The public surface of the Internet is adopting IPv6 and it is going quite well.
Too much progress has been made deploying IPv6 to start again from scratch. A huge amount of work got us to this point. It is also impossible to be fully backwards compatible with IPv4 because 128 bits into 32 bits will not go. An IPv4 end-point will never be able to connect to an arbitrary IPv6 end-point without an external lookup.
> My understanding is that part of your IPv6 address is fixed from your MAC, so if I travel around with my laptop, Google could tell it is the same device connecting via IPv6 from anywhere in the world? Is that not the case?
That is not the case. Privacy addresses are used now to avoid the above situation.
https://tools.ietf.org/html/rfc4941
https://tools.ietf.org/html/rfc7217
A useful way of thinking about IPv6 addressing is that the /64 prefix used by autoconfiguration (SLAAC) is the basic unit of addressing rather than an individual IPv6 128 bit address. Every 3GPP smartphone connected using IPv6 gets a /64. This allows it to tether devices behind it. It also allows any IPv6 address in /64 be used so it can't be found by IP address range scanning because 64 bits is so vast.
https://tools.ietf.org/html/rfc7934
https://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-unique-ipv6-prefix-per-host/
> ...we'll know EXACTLY where you are and what devices you are using, without annoying things like DHCP and NAT getting in the way.
This is false.
With 3GPP mobile they'll know what PGW you came in on instead of what CGNAT you used. The PGWs can be serving users from a very wide area, even an entire country. The /64 prefixes are dynamic.
With fixed broadband they'll only be able to identify you down to the residential gateway's WAN link. If the IPv6 prefix is coming from a dynamic pool on the BNG or CMTS it can change.
IPv6 host devices don't embed their MAC addresses in their SLAAC addresses.
Based on IPv6 address information for them to know exactly where you are you would have to configure a static IPv6 address.
>An upgrade of my router should be a must
ISPs are not making any money off the transition to IPv6.
That is why they have been so slow to adopt it.
When you get new equipment from your ISP it will be because you changed provider, bought a new service, or the modem broke. IPv6 is a technical nice to have as far as the business case for deployment goes.
> They can't even tell me if the IPv6 prefix will be static on a business-type connection. I'm waiting for them to find out. (The IPv4 address would definitely be static).
Of course they could do static IPv6 delegated prefixes, they just don't want to do it yet.
It will be easier to implement static IPv6 than static IPv4 because they'll have mountains for virgin IPv6 address space to assign from.
Agreed that the big US ISPs have helped drive an improvement in CPE but that much of the CPE is still very poor.
> Auto-config puts your MAC address in the IP address, then another auto-config tool warns you that your MAC address is visible.
It is the host not the router that forms the host bits of the IPv6 address with SLAAC. Modern OSs no longer by default use EUI-64 addresses for communication beyond the router. They use privacy addresses.
> Even if someday you are forced by your ISP to use an IPv6 address on your router it doesn't mean you have to go and enable IPv6 on everything you own.
As IPv6 becomes more established any problems that make people want to turn if off will be ironed out.
As Metcalfe's law kicks in for IPv6 there will be an increasing incentive to use it.
> Your toaster is going to talk back to LG corporate headquarters and you are going to pay for the inet access
Your toaster would be able to make an outward call home through an IPv4 NAPT in the residential home gateway, so the corporate overlords will know about it either way.
IPv6 eliminates the need for the NAPT and allows for transparent end-to-end connectivity. That will allow applications that don't require centralised control.
> Note that several years ago, France Telecom got assigned a /19 block of IPv6 addresses. That is 1/65,536 of the *total* unicast IPv6 address space (the first three bits are fixed at 001).
That is only the currently delegated by IANA 2000::/3 prefix.
There's nothing to stop 4000::/3, 6000::/3 being delegated in future.
I will admit that France Telecom should not have been assigned a prefix as large as a /19. That is ridiculously big.
> The Virgin one, especially, pisses me off.
Badger them to do it dual-stack instead of using DS-Lite. If necessary they should buy more IPv4 from poor countries. Most of Liberty Global have deployed IPv6 using DS-Lite and it is terrible for power users that are still dependent on having a public IPv4 address on their WAN link so they can port forward.
> Meanwhile Plusnet ran a couple of trials back around 2009 and seem to have given up. Oh well.
Whoever did that at Plusnet is probably long gone.
There's a long tail of small ISPs. Some technically competent like AAISP and majority that are controlled by the bean counters.
> Your toaster is going to talk back to LG corporate headquarters
For there to be more than 3.5 billion internet connections in the world that don't sit behind a NAT the larger address space of IPv6 is needed.
The important scaling with IPv6 is not the number of devices sitting on a customer home LAN. It is the number of possible customer LANs that don't have the restrictions of NAT.
IPv6 isn't faster, unless it has a lower RTT path than IPv4. As ISPs make their IPv4 & IPv6 peerings congruent and dual-stack CDNs the relative performance of IPv6 will continue to improve. Eventually ISPs and CDNs will put less effort into maintaining the IPv4 peerings and distribution of IPv4 enabled CDNs. Then the performance benefit that IPv4 enjoyed up until a few years ago will change in IPv6's favour. It is already happening from some operators to sites like Facebook.
Time to stop beating that drum.
We're going to need a lot more than 3.5 billion independent Internet connections. Every IPv4 connection that isn't behind a NAPT needs a public IPv4 address. The only way the IPv4 Internet scales is ever more NAT and middleware.
IPv6 is being allocated in a sensible way. There are 18 billion billion /64s and only a small amount of that is being allocated from.
http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
What's the story with BT's deployment? Troubles with the IPv6 support in their home hubs perhaps. They were supposed to be at 50% deployment by now with it completed by the end of the year. LOL. That was never believable given their past performance. In fairness it should not be difficult for them to fix if they just put a little resource into it.
Meanwhile Sky Broadband are at 70% deployment.
Apple have implemented bump-in-the-wire support in iOS for working with IPv6-only networks that provide DNS64/NAT64 access to the IPv4 Internet in addition to the direct IPv6 Internet access. The use of central provider NAT44 is ubiquitous in mobile networks. Handsets in IPv6-only networks just use IPv6 instead of IPv4 to get to the NAT.
Apple have not given a solution to providing the IPv4 part of dual-stack access for devices tethered off an IPv6-only 3GPP connected iOS device. Android (and Windows Phone) can do this using a 464XLAT clat in the handset. The only available solution with iOS is for the handset to bring up a separate tethering APN using a separate 3GPP bearer with IPv4. But this defeats many of the advantages of moving to IPv6 in the packet core. If the operator also doesn't support dual-stack bearers (which is normal in the case of operators using IPv6-only 464XLAT) then IPv6 cannot be given on the tethering LAN (as RFC 7278 requires IPv6) via the separate tethering APN.
If iOS supported RFC 6877 and RFC 7278 in the cases of: 1) shared handset & tethering APN and 2) separate handset APN and tethering APN then they would be removing a major hurdle to simplifying IPv6 deployment in Mobile Packet Cores.
To get 32% users with IPv6 worldwide they've conservatively assumed quadratic growth continues instead of a more typical S-curve technology adoption. Using the same quadratic assumption for the US projects IPv6 end-user adoption there will be about 85% by the start of 2019. That is probably an underestimate for US mobile operators as VZW is already over 70% and T-Mobile US is over 50%.
Apple have done nothing with IPv6 for the last 4 years. In that time user adoption has got up to over 21% in the US. So it is very welcome that someone in there is finally working on IPv6 again. The recent changes they announced to better support IPv6-only PDP/PDN connections in iOS are also welcome. They still have a critical gap in their IPv6-only support in iOS. They don't yet support IPv4 hotspot when the PDP/PDN connection is IPv6-only.
On the one hand they're saying IPv6-only is critical but on the other they aren't supporting it to a level that can be deployed. Android, Windows Phone and Jolla solve the IPv4 tethering problem using 464xlat.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
