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

[Naoki Matsuhira <[e-mail]>]

I don't support adoption.

When NAT was first introduced, I experienced a lot of trouble. There may be
fewer problems these days, but I think the reason is that applications are
built with NAT in mind. In other words, I think it limits the ability to
create applications.

I think it is undesirable that something works in an environment without
NAT but does not work in an environment with NAT. If this happens, should I
fix the application or the network?

I think it would be desirable to regain an environment where applications
can be created without restrictions, and I think that would make the
Internet better.

Even though IPv6 can eliminate this restriction, I do not agree with
restricting applications with NPTv6.


Naoki.

2024年3月19日(火) 8:47 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
>> --------------------------------------------------------------------
>>
>