That has already been invented. It is called address plus port (RFC 6346 or A+P): https://tools.ietf.org/html/rf...

But it will only be used for "compatibility" - to communicate with IPv4 hosts that have not yet been upgraded to IPv6. If you think about it, there are no reason to deploy devices that can understand "quints" as that is just as big an upgrade to the IP stack as switching to IPv6.

Your home router will run the A+P function. It will share an IP address with other customers at your ISP. You will be assigned a port range with that shared IP address. The router will simply do NAT, so your devices on the home network do not need to know anything about this.

At some point you will find that it sucks not to be able to run ssh on port 22 and http on port 80. Therefore your helpful ISP has also provided you with IPv6, where no such limitations apply.

Also the trick only works with UDP and TCP, as other IP protocols do not use ports.

Replying to the guys that said it is illegal to sell: not only is it legal, but several of the internet registries put up their own marketplace for trading IP address space.

Here is a list of RIPE approved brokers: https://www.ripe.net/manage-ip...

That is not what should happen if you have it configured proper.

Say your prefix is 2001:db8:1::/48

Your LAN is 2001:db8:1:1::/64
Your WIFI is 2001:db8:1:2::/64

Your laptop has 2001:db8:1:1::10 on the LAN and 2001:db8:1:2::20 on the WIFI.

Now if you type ping6 2001:db8:1:1::42 it will automatically prefer the LAN interface and use the 2001:db8:1:1::10 IP address. It will not use the WIFI address unless you force it.

On the other hand if you ping6 2001:db8:1:2::42 it will select the WIFI interface and use 2001:db8:1:2::20 as source address.

If you ping something on the internet or if you ping 2001:db8:1:3::99 (assuming the laptop is not connected directly to that), it will first select an outgoing interface (either LAN or WIFI) and then pick the source address from that interface. Again unless you force it to do something different. These are the default address selection rules.

Yes zero global addresses on the link (GUA). You will of course have the link local address, which will be used for routing.

Typically your firewall is also the device that is handling the DHCP-PD with upstream and assigning /64s to your downstream routers or to different ports on the device. It will just work. It will not think that the traffic is spoofed. It will also do connection tracking and know exactly what is spoofed and what is not.

Devices will pick the correct IP from the outgoing interface. If your laptop has a Wifi connection, it will use the Wifi address when initiating connections that way. And the LAN address when sending out traffic on the wired network.

Applications can override that behavior but then you are dealing with misconfiguration or broken applications.

Trouble with devices connected to two subnets (links in IPv6 terms) at the same time are basically the same with IPv4 and IPv6.

Android does not support DHCPv6 at all. Proposing that they should implement IA_PD but not IA_NA is silly. Doing that might very well break PD on networks where there is a requirement that the next hob for the PD is known and stable. Such as ours...

What you can't do? You can't do tethering except on 3G/4G networks. Why you would want to? Dunno, but I notice that not every Android device is a phone. There could be use cases for that.

Also there are universities and large companies that simply wont let you do SLAAC. I have no experience running such networks, so I can not tell if they are right in doing that. I imagine they could have some of the same issues that we have in our ISP network (ND cache exhaustion etc). A simple defense could be to use a /120 or /112 with DHCPv6.

I do not know about APNIC, but RIPE accepts /48 assignments to end users. All ISPs in my country, which are doing IPv6 (which few of them are), are handing out /48 to users. So that is kind of the standard here.

Even the smallest ISP can get a /29 allocation from RIPE. That is a half a million of /48 assignments to give on to end users.

The problem with the idea of a global hierarchy routing is that the internet is not a hierarchy. BGP simply does not work like that. Solving that (if it needs solving) requires something more. One proposal is LISP.

Try using tethering while you have that Android on Wifi (tethering using bluetooth to a laptop). That wont work because that requires DHCPv6. Why would you want to? I don't know, but that is what is broken here.

It works while using cellular internet because they effectively have an alternative to DHCP-PD to assign a /64 prefix to the phone. They new LTE standard is switching to DHCP-PD so I wonder what Google will do then.

Except for cellular carriers, almost all ISPs are assigning multiple /64. Most are doing either /56 or /48.

The way to structure your internal network with three subnets is very simple. You will use three /64 out of the /56 or /48 that you got from your ISP.

There are many reasons that ISPs will not be assigning /64 or smaller. That is simply very hard on the ISP equipment. So have no fear, that will not become common.

Privacy extensions is an extension to SLAAC. All major operating systems come with privacy extensions enabled by default, which means they will do a dosen of adresses per device. If you enable SLAAC in the provider network and do not use DHCPv6-PD, most CPEs will bridge IPv6. That means the ISP switch/router has to track every single device inside your household multiplied by number of addresses used for privacy extensions.

But it is a problem even with no device actually using the address. If someone starts mapping your address space (eg. using nmap) the ISP router has to start NDP discovery on every single address that someone sends a ICMP ping to. There is no way the ISP router can know that there is no device with that address. The only defense is to limit the number of active cache entries per customer, but then you just made it very simple to DoS the customer with trivial amount of ICMP traffic.

For this reason the sane way to implement IPv6 as to do DHCPv6-PD and assign either 0 or 1 IPv6 address on the link interface. Zero is possible because IPv6 can use link local addresses for routing, but it will screw up your traceroute and arguably it prevents the CPE from sending back mandatory ICMP packets such as MTU changes.

I work for a (smallish) ISP so let me tell you why you will simply not get any IPv6 service without DHCPv6 on our network.

It has nothing at all to do with being IPv4 old-timers. That is just you not understanding the complexity of the world out there. Our network was build from the start with the idea that IPv6 is the future.

We use DHCPv6 to provide every user with his own /48 prefix. Yes you said that DHCPv6 is a great solution for prefixes. But we also use it to deliver a /128 to go with that prefix. We need this to have a stable and predictable address that we can use as next hob for your shiny new prefix.

We had this very same debate on the NANOG mailing list. Some people there asked why does your routers not sniff the DHCPv6 packet and add the route dynamically? Two reasons. One, that is not in any standard, so our vendor did not implement it. Two, it does not work if you have router redundancy (how would the backup router know the route?).

There are more reasons an ISP would not want to use SLAAC. It exposes 2**64 addresses to the ISP network access routers. This can harm the network in many different ways and you simply do not want your ND caches to be full of that crap. You want to use as few slots in the shared ND cache per user. Therefore you are going to disable SLAAC on the customer edge and use some other mechanism. One guy suggested not using GUA on the customer links and only use link local addressing here. We choose to use /128 DHCPv6 assigned addresses. In either case, GUA-SLAAC is a fail in the provider network.

SLAAC is great inside the household of our customers. But we leave that decision to the customer and his choice of CPE-router.

The problem with Android is that it should really be able to act like a CPE for tethering purposes. Therefore is should be able to accept our CPE configuration. Android should also be able to ask for a prefix to be sub-delegated from the house CPE and it should accept that this might come with extra addresses that will be used for routing or for other purposes.

Where to start?

1) IPv4 vs IPv6 has nothing to do with ASN. If you do have an ASN you will be using the same ASN for both protocols. With 32 bit ASN now in wide use, there is nothing limiting you from applying for one. Get your own /48 prefix with it.

2) IPv6 has NAT.

3) Multihoming is perfectly possible using IPv6. There is no rule telling you not to do it exactly like you always did with IPv4.

4) There is no rule that say you can not split a /64. You can split it down to /128 if you want. The only thing that breaks is SLAAC but you can still use DHCPv6 or static/manual configuration.

5) All major ISPs are giving out /56 or more address space, so you have no need to split a /64.

6) All major operating systems use privacy extension enabled by default, so you MAC will not be exposed when you surf the net. Your device will be no more tracked than with IPv4-NAT since it changes address all the time.

All IPv6 gives you are options. There are now more ways to do the above things. But in no way did you lose the ability to keep doing things like yesterday.

::ffff:a.b.c.d is what is used inside programs that want to use just one socket type (IPv6) to handle both protocols. I believe your OS might very well refuse to configure that on an interface.

I admit to abuse fd00::/8 but not any more than what the IPv4 think brings you anyway. Using the very first network of fd00::/8 will bring you the pain of colliding with everyone else that did exactly the same, but you will not likely collide with someone who cared enough to generate a global unique ULA prefix. This is 100% equal to having the majority of home networks on the same /24 network (192.168.1.x). You lose the advantage that IPv6 was supposed to get you, but some people here seems to be dead set to lose all that if they can, just because they don't like hex.

In another livetime I made a fd00:: prefix generator: http://bitace.com/ipv6calc/

Oh I see. You did not get the fact that when I type ping6 2001:778:0:ffff:64:0:8.8.8.8 on my IPv6 only computer, then I am in fact pinging 8.8.8.8 which happens to be a real IPv4 only server out there. You said why didn't they embed the old number plan in the new one - and they did. Multiple times actually.

If I have a NAT64 device on my local network, then my IPv6 only machine can in fact communicate with IPv4 only devices. The packets will go through the NAT64 device, because there simply is no other way - and that is a technical problem, not administrative.

We have seen a zillion proposals for alternative "IPv7" plans including yours. None have explained how that scheme would allow an old IPv4 client to speak directly with an IPv7 client. Because there is no such scheme, it is impossible. IPv4 was not made to be extendable so it is not.

You point to phone numbers. The phone numbers were made from the start to be extendable. It was never type 8 digits exactly. Never type less and never type any more - but that is exactly how IPv4 is. It is a fixed binary structure and there is no add an extra digit possible.

But as far as the administrative problem goes, somebody did think it would be smart if humans could type IPv4 style addresses for old stuff. So you can. I can ping 8.8.8.8 without first converting that into hex.

You are not making sense here. Of course the boxes on the same link need to share a subnet - just as they do with IPv4. So instead of 192.168.1.x/24 you would configure fd00::x/120.

Your router would be fd00::1. Your PC would be fd00::2. The printer fd00::3, the TV fd00::4 and so on. And yes that would work perfectly well. Today. You can even use DHCPv6 to make this work exactly like you are used to with DHCPv4.

The only difference here is that you need to remember "fd00::" instead of "192.168.1.".

But since you wanted it to look more like IPv4, we could point out that you can also name your network fd00::192.168.1.x. Why you would want to I don't know - but you can.

If your router is doing NAT64 it could export the legacy IPv4 network as fd00::a.b.c.d. That would make you feel home. It would not be a wrapper - you would be able to type ping6 fd00::8.8.8.8 from your computer, which happens to have the IP fd00::192.168.1.2.

All of that is possible today, although the usual CPE device does not ship with NAT64 and would not provide that configuration by default (because it is lame). But if you were to configure your own Linux router, you could make such a setup right now. There is no limitation in the IPv6 protocol stopping you from doing that. If it was smart, I am sure Linksys, Asus et al would do so.