Re: [v6ops] FW: New Version Notification for draft-thubert-v6ops-yada-yatt-03.txt

On Thu, Apr 7, 2022 at 2:08 AM Pascal Thubert (pthubert) <pthubert=
40cisco.com@dmarc.ietf.org> wrote:

> Dear all (and welcoming XiPeng in his new role)
>
> There was yet another long thread on NANOG with tenants of v4 and v6
> fighting and complaining about how the IETF provided a mission impossible
> migration plan with too large a chasm between IPv4 and IPv6, and using that
> as the argument of still stalling after all those years.

I saw it

Nothing new here.

>
> At some point, someone indicated that if no strategy had been found in 20
> years, there was none to be found. To which I felt compelled to reply that
> effectively things were proposed 20 years ago, and that the fact that the
> war still rages today is an indication that there was neither a smashing
> victory nor enough sufferance on either side to accept a compromise.
>

There is no war.  You cannot write an I-D and expect some flame war of
micro-network operators and hobbyist to subside

> But there was sufferance indeed, and as deep entrenchment. Dual stack and
> CG NATs mean ever growing OPEX and CAPEXs. Do we have to live with that?
>
> So I dug through ideas which were on the table 20 years (close to 30 years
> ago see a ref to Brian's work) and gave the broad lines of what a
> compromise could be. After a few discussions and one thing leading to
> another, I turned that into a draft.
>
> There it is. Baby steps and opposed to a leap that too many refused. A
> chance for the IPv4 tenants not to remain behind like England after the
> first industrial revolution. An effort from both the IPv4 and the IPv6
> side, with suggested benefits beyond connectivity for each side. And a
> reduced chasm between those who made at least a step, and an incentive to
> make more.
>
> It's still rough but I hope you'll like it. At least, please read the
> intro / motivation piece, and comments are more than ever welcome.

I do not think this I-D should be adopted or otherwise moved forward.
Speaking from my own experience in the usa, ipv6 is pervasive.  All the
mobile operators ship ipv6 default on, major content is on v6, ipv6 is
common in home broadband.

Ipv6 economics work for anyone with a growing edge. Ipv4 will remain
prominent for folks who are not growing or are otherwise resistant to
change. That is fine.

There is no problem. Multiprotocol networks have always been the norm.

>
> Keep safe;
>
> Pascal
>
> -----Original Message-----
> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: jeudi 7 avril 2022 10:28
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Subject: New Version Notification for draft-thubert-v6ops-yada-yatt-03.txt
>
>
> A new version of I-D, draft-thubert-v6ops-yada-yatt-03.txt
> has been successfully submitted by Pascal Thubert and posted to the IETF
> repository.
>
> Name:           draft-thubert-v6ops-yada-yatt
> Revision:       03
> Title:          Yet Another Double Address and Translation Technique
> Document date:  2022-04-07
> Group:          Individual Submission
> Pages:          18
> URL:
> https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-thubert-v6ops-yada-yatt/
> Html:
> https://www.ietf.org/archive/id/draft-thubert-v6ops-yada-yatt-03.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-thubert-v6ops-yada-yatt
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-thubert-v6ops-yada-yatt-03
>
> Abstract:
>    This document provides a stepwise migration between IPv4 and IPv6
>    with baby steps from an IPv4-only stack/gateway/ISP to an IPv6-only
>    version, that allows portions of the nodes and of the networks to
>    remain IPv4, and reduces the need for dual stack and CG NATs between
>    participating nodes.  A first mechanism named YADA to augment the
>    capacity of the current IPv4 Internet by interconnecting IPv4 realms
>    via a common footprint called the shaft.  YADA extends RFC 1122 with
>    the support of an IP-in-IP format used to forward the packet between
>    parallel IPv4 realms.  This document also provides a stateless
>    address and IP header translation between YADA and IPv6 called YATT
>    and extends RFC 4291 for the YATT format.  The YADA and YATT formats
>    are interchangeable, and the stateless translation can take place as
>    a bump in the stack at either end, or within the network at any
>    router.  This enables an IPv6-only stack to dialog with an IPv4-only
>    stack across a network that can be IPv6, IPv4, or mixed.  YATT
>    requires that the IPv6 stack owns a prefix that derives from a YADA
>    address and that the IPv4 stack in a different realm is capable of
>    YADA, so it does not replace a generic 4 to 6 translation mechanism
>    for any v6 to any v4.
>
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>