I think this message is 4 days early. Owen
> On Mar 28, 2022, at 11:03 , Ryland Kremeier <rkreme...@barryelectric.com> > wrote: > > > > Hmm. > > -----Original Message----- > From: NANOG <nanog-bounces+rkremeier=barryelectric....@nanog.org > <mailto:nanog-bounces+rkremeier=barryelectric....@nanog.org>> On Behalf Of > Pascal Thubert (pthubert) via NANOG > Sent: Monday, March 28, 2022 11:55 AM > To: Philip Homburg <pch-nano...@u-1.phicoh.com > <mailto:pch-nano...@u-1.phicoh.com>>; nanog@nanog.org > <mailto:nanog@nanog.org>; 'jordi.palet' (jordi.pa...@consulintel.es > <mailto:jordi.pa...@consulintel.es>) <jordi.pa...@consulintel.es > <mailto:jordi.pa...@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 > <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....@nanog.org > > <mailto:nanog-bounces+pthubert=cisco....@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) > >