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

[Ted Lemon <[e-mail]>]

Ad hominem arguments ("ivory tower") don't get more convincing over time.

It's my understanding that a lot of work has been done on locator/identity
splitting. There's an active working group that works on that, and Brian's
SHIM6 work I think also addresses that use case, as does Mobile IPv6. Why
does 6man need to delve into this space?

IPv6 deployment is not a universal benison. It may be frustrating to those
of us who have been working on it all these years that it's not done yet,
but a lot of good work has been done, and I think one of the biggest
obstacles to deployment is actually just "we have always done it this way."
Rushing to deploy with a partial solution that won't stand the test of time
is something we've done a lot of. Do we really need to do it again?

On Wed, Mar 20, 2024 at 3:00 PM Ole Trøan <[e-mail]> wrote:

> Ted,
>
> You seem to make the assumption that MPMH, SAS/DAS selection and
> multi-homing policy distribution can actually be made to work.
>
> Across every application and every host stack in a network. Ivory tower?
>
> We should not ignore the other use cases for identity/locator split.
> Abstracting services for example. (Although those are sometimes done at L4
> or L7 as if that makes it better).
>
> I agree we should discuss solution based on merit. It has not been shown
> that your alternative proposal has merit (yet). There’s still hope perhaps,
> but we have hand-waved these solutions around for a few decades. Mostly to
> the detriment of IPv6 deployment unfortunately.
>
> O.
>
> On 20 Mar 2024, at 04:28, Ted Lemon <[e-mail]> wrote:
>
> 
> It will come as a shock to all, no doubt, but I read the document, and
> specifically those bits.
>
> The problem is not that this document doesn't solve that problem. It's
> that it is not an unsolved problem: we do not need this document to solve
> that problem.
>
> As Lorenzo pointed out, if you use ULAs for your internal servers, and
> also distribute whatever GUAs you get from the ISP through your network,
> you never need to renumber your infrastructure because your ISP changes
> your external GUA prefix. We don't even need to update source/dest address
> selection to deal with this: you just do not use addresses in the
> ISP-provided GUA in your configurations. So e.g. your internal DNS /only/
> publishes the ULA, never the GUA. If you give your routing infrastructure
> routable addresses, the addresses you configure are from your ULA.
> Basically precisely what you would do if you were using NPTv6—the only
> thing you change is that you also propagate the ISP-provided prefix for
> external connectivity.
>
> This should behave much better than NPTv6, because there isn't a weird
> transition point at the edges of your network where magic happens that is
> not seen internally.
>
>
> On Wed, Mar 20, 2024 at 1:19 PM Brian E Carpenter <
> [e-mail]> wrote:
>
>> On 20-Mar-24 15:08, Ted Lemon wrote:
>> > I would appreciate it if we could discuss the merits and not the
>> marketability of this proposal. When the IETF publishes a standards-track
>> or informational document, we are indeed recommending the documented
>> solution.
>> >
>> > It’s fine for you to disagree with me, but as a general principle IETF
>> consensus should be based on technical arguments, not marketing arguments.
>> Of course we want whatever we recommend to be something the market would
>> use, but we don’t need to solve a problem simply because the market would
>> buy the solution to the problem. There should be an actual problem to solve
>> that is not already solved by an existing standard. That’s not the case
>> here.
>>
>> Huh? While I don't think the applicability text in the draft is done yet,
>> the "Address Independence" and  "NPTv6 Applicability" sections already
>> describe use cases that are not otherwise satisfied.
>>
>> RFC 8678 is worth reading at this point, and the draft should certainly
>> reference it.
>>
>>     Brian
>>
>> >
>> > Op wo 20 mrt 2024 om 11:04 schreef IPv6 <[e-mail] <mailto:
>> [e-mail]>>
>> >
>> >     Ted,
>> >
>> >     I don't think standardization is necessarily the implicit (or
>> explicit?) endorsement that you're suggesting it is.
>> >
>> >     Some vendors already offer more or less the functionality in
>> question; some network operators will implement this whether or not there's
>> a Standards-track RFC outlining it (assuming they're not already). Not
>> having an official-ish RFC just means they might do it more poorly.
>> >
>> >     Or they'll just do N:1 NAT/PAT/"NAT overload."
>> >
>> >     Or they'll just announce provider-independent space from every site
>> (this would be a different kind of bad).
>> >
>> >     Or they'll just continue to not adopt IPv6, because it can't do the
>> things to which they're accustomed on IPv4.
>> >
>> >     Technical purity aside, I'd rather have the least-bad option for
>> the internet at large.
>> >
>> >     - Jima
>> >
>> >     ________________________________________
>> >     From: Ted Lemon <[e-mail] <mailto:[e-mail]>>
>> >     Sent: Tuesday, March 19, 2024 7:43 PM
>> >     To: IPv6 <[e-mail] <mailto:[e-mail]>>
>> >     Cc: Nick Buraglio <[e-mail] <mailto:
>> [e-mail]>>; IPv6 List <[e-mail] <mailto:
>> [e-mail]>>
>> >     Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
>> >
>> >     Is that a use case that the IETF would recommend in a
>> standards-track document, though? This is my point: it's not wrong to
>> document this. What I'm suggesting is that we shouldn't standardize it. We
>> should not, e.g., have 7084-bis recommending it. Or anything else.
>> >
>> >     On Wed, Mar 20, 2024 at 10:34 AM IPv6 <mailto:[e-mail] <mailto:
>> [e-mail]>> wrote:
>> >     Lack of imagination (or maybe cursed knowledge) doesn't mean it
>> only solves a single problem. ;-)
>> >
>> >     It also solves something of an edge case where a leaf site is
>> numbered off of a core site's static address space, but needs selective
>> local internet break-out for bandwidth-intensive workloads (which aren't
>> desired to be backhauled through the core site).
>> >
>> >     (Sorry if it sounds niche; I didn't invent this construct. -_- )
>> >
>> >     - Jima
>> >     ________________________________________
>> >     From: ipv6 <mailto:[e-mail] <mailto:
>> [e-mail]>> on behalf of Ted Lemon <mailto:[e-mail]
>> <mailto:[e-mail]>>
>> >     Sent: Tuesday, March 19, 2024 19:19
>> >     To: Nick Buraglio <mailto:[e-mail] <mailto:
>> [e-mail]>>
>> >     Cc: IPv6 List <mailto:[e-mail] <mailto:[e-mail]>>
>> >     Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
>> >
>> >     On Tue, Mar 19, 2024 at 11:32 PM Nick Buraglio <mailto:mailto
>> <mailto:mailto>:[e-mail] <mailto:
>> [e-mail]>> wrote:
>> >     Agreed, happiness should not determine success. From what I have
>> seen (which is admittedly limited) moving from experimental to a "higher
>> level" RFC is typically accompanied by something like a deployment status
>> document, e.g. the SRv6 deployment status doc here
>> https://datatracker.ietf.org/doc/html/draft-matsushima-spring-srv6-deployment-status
>> <
>> https://datatracker.ietf.org/doc/html/draft-matsushima-spring-srv6-deployment-status
>> >
>> >
>> >     I think it's really important  to distinguish between "this draft
>> solves a problem" and "this draft solves a problem that can't be solved
>> already" and "this experiment has succeed and we can promote the document
>> to informational or standards-track."
>> >
>> >     I think we can all agree that this draft solves a problem. I think
>> it solves exactly one problem: allowing sites to keep stable internal
>> addressing in the face of renumbering by ISPs and/or changing ISPs.
>> >
>> >     However, this problem can be addressed the way 7084 currently
>> solves it: by numbering the internal network with a stable ULA and hosting
>> services on addresses within that ULA rather than on a temporary GUA
>> provided by the ISP.
>> >
>> >     Problems NPTV6 does not solve:
>> >
>> >     * MHMP (although it solves some aspects)
>> >     * Internal address privacy
>> >
>> >     So I don't actually think this document does anything useful for
>> the Internet community. I don't mind that there is a document that
>> describes NPTv6, but I don't think it should be standards track or
>> informational, and I don't think IETF documents should normatively
>> reference it.
>> >
>> >     Regarding experiments, at least from a scientific perspective, an
>> experiment needs to have a control group. If we wanted to know whether
>> NPTv6 solved the problem in an easier way than dual ULA/GUA, we would want
>> to set up an experiment where some sites continued to use IPv4, some used
>> NPTv6, and some used ULA/GUA. As far as I know, no such experiment has been
>> done, and no such comparison has been documented.
>> >
>> >     I think the presentation Paulo has just done is the most
>> interesting, but what we are not seeing is an answer to the question "how's
>> it going, what problems do you have, etc."
>> >
>> >
>> > --------------------------------------------------------------------
>> > 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
> --------------------------------------------------------------------
>
>