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

[Nick Buraglio <[e-mail]>]

On Mon, Mar 18, 2024 at 1:22 AM Brian E Carpenter <
[e-mail]> wrote:

> On 18-Mar-24 19:04, Ted Lemon wrote:
> > On Mon, Mar 18, 2024 at 3:42 PM Brian E Carpenter <
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >      > whether indeed this is the right technical approach to solving
> the problem of renumbering sites (that is, don't renumber them)
> >
> >     That's only part of it. The other, equally important, point is
> multiprovider multihoming for sites too small to justify a PI prefix.
> >
> >
> > I think that was assumed in my comment—I was assuming that the problem
> is that the site is using the prefix assigned by the ISP.
>
> Yes. But in MHMP, there are two ISPs and two prefixes.
> >
> >     Another, debatable but real, is a user requirement to obfuscate
> internal addresses.
> >
> >
> > This feels like not our problem.
>
> But it is, because the absence of an IETF-recommended solution causes
> people to go away from IPv6 entirely. There's evidence of this in the
> archives of this list (or possibly v6ops).
>

Not only that, but in the absence of guidance, a potpourri of random,
almost certainly worse solutions will be created, deployed, and have no
discernable or common support model outside of vendor lock-in or an
otherwise inflexible proprietary solution. So the real question is "what is
worse?". In the quest for ideal, we have trended toward vilifying what is
tolerable even if it is imperfect.

>
> >     We have failed for a quarter of a century to solve all three of
> these problems. Is that OK?
>

I would argue that it is not.
See above about perfect being the enemy of the good (perhaps not good, but
less bad).

> >
> >
> > Yes, I think it's okay. We are trying produce something new that is
> actually better. IPv4 already solves these problems. If you want to
> obfuscate internal addresses, you can always use IPv4 internally and NAT64
> to the IPv6 Internet.
>

The requirement for obfuscation is, in my experience, not necessarily
rooted in anything other than a bit of a misguided understanding of what
middle box vendors and end user CPE touted as security - conflation of
SPI + NAT44 == "Firewall". Like it or not, that has 25 years of tradition
that has worked its way into compliance requirements (there are a myriad of
threads on this in v6ops dating back many years) and worse yet the
generations of engineers that were not around pre NAT44, which is most at
this point, don't often consider a world without it. I say this not to make
excuses or cases, but to simply illustrate that it is larger than "bad" or
"good". It is just "current state".



> If that's the answer, where's the BCP explaining how to do it? And why is
> NPTv6 worse?
>
> >
> > My point being, if we really are trying to produce something usefully
> different than what we already have with the NATted IPv4 Internet, we
> should make sure we are actually doing that. If IPv6 is just IPv4 with a
> wider address, we've already really done a lot of work we didn't need to do.
>

That has been done. This is simply an implementation detail.


> We agree on that. But we agreed on that 25 years ago *and we didn't solve
> it*.
>
> That's why I remain against NPTv6 going on the standards track, because it
> would still be nice to find a solution with no translation at all.
>

I will say this - even with the experimental label this technology has done
two things and this is largely because it is tolerable, well thought out,
and solves a problem. It has:

Made it into a very notable amount of both FOSS and high end commercial
hardware as a supported solution, and

Been deployed in very large, high visibility production roles.

If that does not illustrate something surpassing "experimental" then I
propose that those definitions are unclear to most folks that don't read
RFCs and drafts on a very regular basis and is counter to the definition: "The
"Experimental" designation typically denotes a specification that is part
of some research or development effort.".
The change in status simply recognizes that fairly indisputable fact. I
believe we have a "solution with no translation". Where the solution falls
down is in cases described as much, much larger issues that are seemingly
endemic - multihoming being an absolutely massive elephant in the room.
I would absolutely love for there to be a better way, and I will more than
happily move on when there is one. However, given what is available *now*,
leaving it as experimental will not slow the current support in vendor
implementations. It will also not prevent the deployment in the cases where
it does actually solve a problem. It's a pragmatic stop-gap until / unless
there becomes a more elegant answer.

Would I personally prefer an answer that is not NPTv6? Sure. But I also
have deployed it *in production* because it is useful and solved a problem
that there was not a better solution for.



>
>     Brian
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>