V6 still not supported

Ryland Kremeier rkremeier at barryelectric.com
Mon Mar 28 18:03:43 UTC 2022

[cid:image001.png at 01D842A4.69CBE6F0]


-----Original Message-----
From: NANOG <nanog-bounces+rkremeier=barryelectric.com at nanog.org> On Behalf Of Pascal Thubert (pthubert) via NANOG
Sent: Monday, March 28, 2022 11:55 AM
To: Philip Homburg <pch-nanog-2 at u-1.phicoh.com>; nanog at nanog.org; 'jordi.palet' (jordi.palet at consulintel.es) <jordi.palet at consulintel.es>
Subject: RE: V6 still not supported

Seems that we lost sync.

I would not rephrase so I made it a draft to make it easy to socialize: https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-00.html

The goal is NOT to allow any IPv4 host to talk to any IPv6 host. For that I agree you need the traditional transition mechanisms, CG-NATs etc.

The plan has 2 phases:

- The first phase called YADA extends the reach of IPv4 using a common IPv4 space that is like an elevator shaft.


        /                                                     /

       /          |------------|                    realm 1  /

      /          /.           /.                            /

     /          / . shaft    / .  (current IPv4 Internet)  /

    /          |------------|  .                          /

   /           .  .         .  .                         /


               |  .         |  |


        /      |  .         |  |                              /

       /       |  |---------|--|                    realm 2  /

      /        | /.         | /.                            /

     /         |/ . shaft   |/ .                           /

    /          |------------|  .                          /

   /           .  .         .  .                         /


               |  .         |  |

               |  .         |  |

               |            |  .

               |            |  .

               .            .  |

               .            .  |

               |  .         |  |


        /      |  .         |  |                              /

       /       |  |---------|--|                    realm N  /

      /        | /          | /                             /

     /         |/   shaft   |/                             /

    /          |------------|                             /

   /                                                     /


There's more in the draft as to how forwarding happens. But only a few routers serving the shaft have to do anything and it's dead simple.

In that phase, we can now have many realms that are parallel to the IPv4 Internet of today. IPv4 acts as normal in each realm.

The phase upgrades IPv4 host to understand an IP in IP format that allows to traverse the shaft. At that time, scale is no more the issue for  IPv4.

- The second phase called YATT does a stateless translation between a v4 in v4 and a v6 address. No CG-NAT.


|YATT |     Realm     |     IPv4     |         Well-Known          |

|Space|    Address    |    Address   |              IID            |

+-----+- -------------+--------------+-----------------------------+

       <- YADA

        Prefix ->

<--------   YATT Prefix ---------->

What it does is allow any node that needs to talk to a legacy device, to 1) obtain a YADA address (IPv4 pair), 2) form a YATT address (YADA derived IPv6 address), and talk to the YADA node, across any of v4 or v6 networks. A stateful bump in the stack can NAT the IP pairs into single Ips and back. A bump in the stack on the legacy host can NAT the IP pairs into single Ips as well.

In that phase, IPv6 can be seen as the sphere that that encompasses the planes above, and a lot more. Every node that has a YADA address owns a full IPv6 prefix automatically. Nodes and networks can migrate to IPv6 only but the nodes that need to talk to IPv4 nodes need an YATT address for that.

There will be corner cases, like well-known IPv4 coded in legacy application payload. For those arguably we'll need a stateful CG-NAT that knows the mapping in advance. But maybe those are not many, and will mostly stay within their realm.

Am I being any clearer now?

Keep safe;


> -----Original Message-----

> From: NANOG <nanog-bounces+pthubert=cisco.com at nanog.org<mailto:nanog-bounces+pthubert=cisco.com at nanog.org>> On Behalf Of

> Philip Homburg

> Sent: samedi 26 mars 2022 12:24

> To: nanog at nanog.org<mailto:nanog at nanog.org>

> Subject: Re: V6 still not supported


> >The only far ressemblance with 6to4 is the thing that was actually

> >nice in the  design, the automatic word in automatic tunnel. Which

> >for the rest of us mean s stateless. Compared to CGNATs that is huge.


> Any form of communication with the current IPv4 internet requires some

> sort of CGNAT. We no longer have enough IPv4 addresses to give each

> customer an unique one. So some ISPs are forced to map multiple

> customers to a single IPv4 address. Which results in CGNAT.

> Technically,

> A+P (address plus port) mapping is a bit different, but for the

> A+customer

> that doesn't make a lot of difference. And A+P has serious scalability

> problems.


> >Beyond that the proposal is not a tunnel and more akin to a nat64

> >since it all ows v6 nodes to talk to v4 nodes. The network can be

> >pure v4 or pure v6 if the  method is implemented as a bump in the

> >stack at the

> wrong end.


> You mostly ignored the routing problems I brought up. With NAT64 each

> ISP is in full control over all routing. Your problem has routing

> aspects that are not under control of the ISP.


> >Your response is also missing the capability to extend the IPv4

> >network a mill ion times. Or drop it completely while maintaining

> >IPv4

> applications.


> Extending IPv4 is fine (except for the installed base of IPv6). It is

> not fine if the extension leads to problem in other areas, like routing.


> There are other problems to consider. For example, IPv6 can be added

> transparently to a network with legacy IPv4-only hosts. Hosts can get

> a public IPv6 address and a RFC 1918 IPv4 address. I wonder how in

> your approach such a mix of legacy and new hosts will work out.


> >6to4 was meant for early v6 to interconnect islands. A solution for a

> >problem that never really existed. Solutions without a problem aren?t

> usually popular.


> We seem to have a different recall of history. 6to4 was extremely

> popular.

> Popular enough that major content providers did not turn on IPv6 until

> host stacks were modified to essentially kill 6to4. (in case we are

> talking about different 6to4 protocols. I meant the one that

> interconnects with the

> non-6to4 IPv6 internet. So more than just islands)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220328/c38de174/attachment.html>

More information about the NANOG mailing list