V6 still not supported

Wed Mar 30 20:32:52 UTC 2022

I think this message is 4 days early.

Owen

> On Mar 28, 2022, at 11:03 , Ryland Kremeier <rkremeier at barryelectric.com> wrote:
> 
> 
>  
> Hmm.
>  
> -----Original Message-----
> From: NANOG <nanog-bounces+rkremeier=barryelectric.com at nanog.org <mailto: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 <mailto:pch-nanog-2 at u-1.phicoh.com>>; nanog at nanog.org <mailto:nanog at nanog.org>; 'jordi.palet' (jordi.palet at consulintel.es <mailto:jordi.palet at consulintel.es>) <jordi.palet at consulintel.es <mailto: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 <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 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/20220330/d8a2c09c/attachment.html>