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

[Ole Troan <[e-mail]>]

Ted,

Sorry Ted, I’m not going to let you off the hook this time.

Are you making a claim that the current specifications of MPMH, SAS/DAS and HE, transport protocols support robust multi-homing and that is deployable today?
If the answer to that is no, what is your solution?

And we aren’t talking about “rushing to deploy”. NPTv6 (and NAT66, NAPT66 for that matter) are widely deployed.
It’s a matter of whom should have change control. Do we want it in the IETF?

I noticed you also made the claim above that RFC6296 did not need an update. Handling of ICMPv6 error message proxying was missing, something I think is quite important to incorporate.

O.


> On 20 Mar 2024, at 06:08, Ted Lemon <[e-mail]> wrote:
> 
> 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
>> --------------------------------------------------------------------