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

[Naoki Matsuhira <[e-mail]>]

I have a similar understanding.

I got some new ideas from listening to the previous NTPv6 discussion. The
draft is draft-matsuhira-oht. Included in 6man's agenda for this meeting.

Comments are appreciated!

Naoki.

2024年3月18日(月) 13:16 Lorenzo Colitti <lorenzo=[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
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>