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

[Ole Trøan <[e-mail]>]

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
> --------------------------------------------------------------------