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)