Re: V6 still not supported

[Ryland Kremeier <rkremeier () barryelectric com>]

I had no idea that actually went through. That makes my morning much better knowing someone saw it hahaha. I'm all in 
on v6.

Thank you,
-- Ryland
________________________________
From: Pascal Thubert (pthubert) <pthubert () cisco com>
Sent: Friday, April 1, 2022 6:59:19 AM
To: Owen DeLong <owen () delong com>; Ryland Kremeier <rkremeier () barryelectric com>
Cc: Philip Homburg <pch-nanog-2 () u-1 phicoh com>; nanog () nanog org <nanog () nanog org>; 'jordi.palet' (jordi.palet 
() consulintel es) <jordi.palet () consulintel es>
Subject: RE: V6 still not supported


Actually, Owen, now the day has come, I can say I love it.



No one likes tradeoffs. No one wants to compromise.



Ryland just told us we have a near perfect title for a spec that is bound to be hated.



Keep safe;



Pascal







From: Owen DeLong <owen () delong com>
Sent: mercredi 30 mars 2022 22:33
To: Ryland Kremeier <rkremeier () barryelectric com>
Cc: Pascal Thubert (pthubert) <pthubert () cisco com>; Philip Homburg <pch-nanog-2 () u-1 phicoh com>; nanog () nanog 
org; 'jordi.palet' (jordi.palet () consulintel es) <jordi.palet () consulintel es>
Subject: Re: V6 still not supported



I think this message is 4 days early.



Owen





On Mar 28, 2022, at 11:03 , Ryland Kremeier <rkremeier () barryelectric com<mailto:rkremeier () barryelectric com>> 
wrote:



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



Hmm.



-----Original Message-----
From: NANOG <nanog-bounces+rkremeier=barryelectric.com () nanog org<mailto:nanog-bounces+rkremeier=barryelectric.com () 
nanog org>> On Behalf Of Pascal Thubert (pthubert) via NANOG
Sent: Monday, March 28, 2022 11:55 AM
To: Philip Homburg <pch-nanog-2 () u-1 phicoh com<mailto:pch-nanog-2 () u-1 phicoh com>>; nanog () nanog 
org<mailto:nanog () nanog org>; 'jordi.palet' (jordi.palet () consulintel es<mailto:jordi.palet () consulintel es>) 
<jordi.palet () consulintel es<mailto:jordi.palet () 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;



Pascal





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

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

> Philip Homburg

> Sent: samedi 26 mars 2022 12:24

> To: nanog () nanog org<mailto:nanog () 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)

>