A very long thread.

Face it: everyone is right, and even technically correct. There's no good and 
evil. We'd know, after 20 years. 

I live in France and my country has a famous 100-years war in its long history 
with England. Do we want to beat this here?

The plain truth:

- IPv4 is here to stay. Some v4-only nodes and functionalities are here to 
stay. Plenty of reasons for that in this thread.
- IPv6 is unavoidable. New devices like phones and IOT need it, many IPv6 only 
in that space, numbers only growing


The things everyone agrees upon:
- Dual stack everywhere and forever is the worst of both worlds as it doubles 
every cost, and that will remain long as the war rages
- Stateful NATs the size of the Internet not doable, which in my book says that 
isolation not only unavoidable but already there.

An the illusions:

- any-to-any is required. In particular, any IPv4-only to any-IPv6 only. I'm 
not talking security but plain functionality. And yes, exceptions if they are 
few can be handled by expensive stateful NATs when the cost is justified
- the Internet is a big homogenous thing. The more it expands, the more we see 
domains forming where specific capabilities are deployed, and because we fail 
to handle that at L3, we mask the functionalities above UDP. 

If we agree on the above then a compromise is possible. Ideally, the compromise 
would:
- maintain the current state of v4 affairs for those who want that
- scale v4 addresses for those who want that
- provide v4 to v6 stateless NATs for this who want that, and
- allow networks to be either of the 2 versions for those who want that. 

SciFi? There's a proposed starting point for that compromise in the yada-yatt 
draft published at IETF v6ops. The key is to use baby steps between locations 
(in the transition plan) where people can be at ease and stay as long as they 
want to, as opposed to enforcing a giant zero-to-hero illusionary step.

Are you ready for that, or should we wait another 80 years with dual stack and 
gigantic stateful NATs?

Pascal





Reply via email to