Integrating NAT [was Re: Celebrating NAT Was: Tolerance]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20-Jul-19 04:26, Phillip Hallam-Baker wrote:
....

> * Each residence gets an IPv6/104 (or better)
> * Every device is assigned an address in 10.x.x.x
> * Devices speak IPv4 to each other inside the network.
> * Dual stack devices can contact any Internet server without restriction.
> * Single stack IPv4 devices can only contact devices inside the network unless they have help.
> * Devise mechanisms that reduce the amount of state that an IPv4 device needs to contact Internet devices to the bare minimum and allow the NAT to transport these on IPv6 rather than IPv4 to limit the need for IPv4 addressing at the residence.
> 
> My proposal may not look pretty to some but it is essentially the strategy the industry is adopting regardless of IETF opinion. So why didn't it happen this way?

Not exactly, but if you look at the *current* state of IETF documents you get:

* Each residence gets an IPv6/56 (or better), so that addressing and routing
within the home are possible
* Every device is assigned an address in 10.x.x.x or another RFC1918 prefix
* Devices speak IPv4 or IPv6 to each other inside the network.
* Dual stack devices can contact any Internet server without restriction.
* Single stack IPv4 devices can only contact devices inside the network unless they have help.
* Provide WAN IPv4 as a service over IPv6 (which integrates NAT44, of course)

That's pretty much where we are today, apart from the ISPs who decided years ago to avoid the last bullet with:

* Provide WAN IPv4 and IPv6 in parallel (which integrates NAT44, of course)

NAT44 works surprisingly well, compared to how badly it worked in the PDP-11 era.

    Brian




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux