Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

[Lorenzo Colitti <[e-mail]>]

I think it's worth thinking about how this solution came about, given that
folks probably don't know the history.

IIRC one of the main reasons why this work became an RFC was that the NTT
wireline deployment of IPv6 had made the (ill-advised) choice to provide
users with IPv6 walled garden addresses that could not reach the global
IPv6 internet. This was done for regulatory reasons: NTT East/West were not
and still are not allowed by law to provide Internet access to users. At
that time that was one of the largest deployments of IPv6 worldwide, with
tens of millions of usersWhen IPv6 on the Internet became a real thing in
the late 2000s, NTT needed a solution that would allow them to provide
Internet access to their users that would not result in turning down their
commercial services, and due to policy they could not deploy a solution
that did not have an RFC number. This put a lot of pressure on v6ops and
the IETF to standardize this.

Fortunately for their users this solution is essentially no longer in use.
NTT also designed a *different* solution that uses source routing and
global IPv6 addresses everywhere. That solution is now the dominant form of
Internet access on the NTT network in Japan.

Before we decide to take this forward, we should bear in mind that this
solution was designed to solve a completely different problem and was not a
very successful solution to that problem. I'd argue that if we reclassify
it, we should actually be reclassifying it from experimental to historic.

On Fri, Mar 15, 2024 at 5:50 AM Ole Trøan <otroan=
[e-mail]> wrote:

> Brian,
>
> I don’t think we should say that.
> IETF standards aren’t an effective tool to enforce policy to restrict the
> use of a particular technology.
>
> I acknowledge that NPTv6 (and NAT66, NAPT66) exposes gaps in the IPv6
> architecture that we have failed to solve well.
>
> If the IETF recommends against something it standardizes, which seems
> contradictory, there should be an alternative solution available. Today,
> there isn’t. And we’re 30 years in…
>
> I would be very happy to see us work on mechanisms that solves the set of
> problems locator rewrite solves in better ways. Realistically though, those
> are real problems and we need a working solution today.
>
> Not to say the working group can’t wordsmith text like that if it so
> desires if the document gets adopted.
>
> Cheers,
> Ole (whose message is already sent through a NAPT66 in the hypervisor and
> a NPTv6 before leaving my home and probably a few other L3, L4 and L7
> proxies before reaching you.)
>
>
>
> > On 14 Mar 2024, at 20:06, Brian E Carpenter <[e-mail]>
> wrote:
> >
> > Eric,
> >
> >> Standard track is the right one IMHO: it is implemented and deployed.
> >
> > Yes, it is implemented and deployed, but that doesn't mean it's
> recommended.
> >
> > Updating this to reflect experience and reality is undoubtedly a good
> idea,
> > but that doesn't imply that it's a recommended deployment model, which is
> > what the standards track would mean.
> >
> > If it was to be on the standards track (or even if it's Informational),
> > I'd want the opening statement to be something like:
> >
> > The mechanism described in this document SHOULD NOT be deployed except
> for
> > special cases as described in section TBD. Operators should first
> consider all
> > the disadvantages and side effects described in section TBD.
> >
> > That should be summarised in the Abstract too.
> >
> > Regards
> >   Brian Carpenter
> >
> >> On 14-Mar-24 22:39, Eric Vyncke (evyncke) wrote:
> >> Without any special hat (except for the 128-bit one), I strongly
> support the adoption.
> >> Like written by others, let's face it: 'address translation' does
> happen and let's do it while keeping end-to-end connectivity with a 1:1
> mapping. I am also afraid that in the absence of src-dst routing some
> 'address translation' is required for multi-homing :-(
> >> Standard track is the right one IMHO: it is implemented and deployed.
> >> -éric
> >> On 13/03/2024, 23:12, "ipv6 on behalf of Bob Hinden" <
> [e-mail] <mailto:[e-mail]> on behalf of
> [e-mail] <mailto:[e-mail]>> wrote:
> >> This email starts an adoption call for the following document:
> >> Title: RFC 6296bis IPv6-to-IPv6 Network Prefix Translation
> >> Draft name: draft-bctb-6man-rfc6296-bis
> >> Link: https://datatracker.ietf.org/doc/draft-bctb-6man-rfc6296-bis/ <
> https://datatracker.ietf.org/doc/draft-bctb-6man-rfc6296-bis/>
> >> Substantive comments and statements of support for adopting this
> >> document should be sent to the mailing list. Editorial suggestions can
> >> be sent to the authors.
> >> The adoption call ends on Monday, 13 March 2024, 23:59 UTC.
> >> Bob and Jen
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <
> https://www.ietf.org/mailman/listinfo/ipv6>
> >> --------------------------------------------------------------------
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>