Re: IPv6 header insertion in a controlled domain

["[e-mail]" <[e-mail]>]

Thank you Warren.  That seems an appropriate and useful addition.Yours,JoelSent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------From: Warren Kumari <[e-mail]> Date: 12/8/19  16:14  (GMT-05:00) To: "Joel M. Halpern" <[e-mail]> Cc: Ole Troan <[e-mail]>, 6man WG <[e-mail]> Subject: Re: IPv6 header insertion in a controlled domain [no-hats]On Sun, Dec 8, 2019 at 11:10 AM Joel M. Halpern <[e-mail]> wrote:>> Ole, as far as I can tell, to answer the apparently simple quesiton you> propose "is there a s safe way to do header insertion?" we would need> o a clear definition of the domain in which it is to be doneJoel, can I make a small addition to this?o a clear definition of the domain in which it is to be done, and howthe domain boundary is enforced (I'm not sure if you would have viewedthis as 2 bullets or just one).Defining the domain might be (somewhat) easy, but it's also importantthat the boundary is enforceable - requiring the operator take actionto *block* traffic leaving the boundary is a very different thing tohaving the operator intentionally opt devices into the boundary.W> o a clear definition of the participants> o and a full re-examination of the discussion which led to the> prohibition against doing so in RFC 8200>> We do not have in front of us a document which achieves either of the> first two bullets. Without that, it is very hard for us to perform the> third bullet.>> I note for example that the presentation in Sngapore did not disucss the> implications or behaviors of hosts inside the Segment Routing v6 domain.>   But the rfc-to-be explicitly includes hosts inserting the information> in the original header.> the presentation in Singapore did not discuss how SR header creators> will deal with errors caused by in=-path header insertion, when the> errors arrive at places that did not perform the insertion.>> But there is a more important issue.  The usual IETF practice (not the> rule, but a practice we have found to be good) is to ask what problem is> being solved BEFORE we evaluate solutions.  There are many good reasons> why we have found this helpful.  You seem to be asking for the opposite.>> I find myself forced to repeat my question:  what benefit is header> insertion bringing to justify working group consideration.> I understand your earlier request not to repeat points.  But for me at> least, it is very hard to answer your question without that.>> Yours,> Joel>> On 12/8/2019 4:24 AM, [e-mail] wrote:> > Mark,> >> > [...]> > [renamed thread]> >> >> Take an example of 3 routers A, B and C that is under the same control.> >> Traffic travels from left to right.> >>> >> A -- B -- C> >>> >> A has a tunnel to C using ULA source and destination.> >> A packet ingresses on A, is encapsulated and forwarded towards C.> >> A has for reasons unknown to us outsourced a function to B. Where B insert an extension header in the packet originated by A.> >> C is also in on the game, being a tunnel end-point, removing the encapsulating header and extension header.> >>> >> If you can leave the nuances of SR and the whatever they propose on the shelf for a minute.> >>> >> Do you agree in principle that this approach of "header insertion in a controlled domain" can be made to work,> >> and should be indiscernible from A inserting the extension header itself?> >> > Yes, there are obviously many ways of skinning this cat.> > In this thread I don't want to try solve whatever problem the EH insertion camp wants solved. I don't think I understand it well enough.> > And I'm unconvinced the 6man group in general understands the underlaying routing problems leading to the proposed solution.> > What I was interested in exploring in this thread was if we could reach agreement that there in principle is a safe way of doing header insertion.> >> > In my simple example above.> > Do you agree that in a controlled distributed system there is no perceivable difference between node A inserting the header or node B doing it?> > Conceptually you could think of it as a tunnel with muliple endpoints (although that's a bit hard to visualize ;-)).> >> > Can we agree that inserting headers and changing the packet size among participating nodes in a distributed system is not inherently unsafe?> > As far as I can think of the only complication to be considered is that node A must be aware of packet size changes when doing PMTU estimation.> > (typically though in these types of networks, one simply declares that "MTU must be well managed. i.e. large enough".> >> > Cheers,> > Ole> >> >>> --------------------------------------------------------------------> IETF IPv6 working group mailing list> [e-mail]> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6> ---------------------------------------------------------------------- I don't think the execution is relevant when it was obviously a badidea in the first place.This is like putting rabid weasels in your pants, and later expressingregret at having chosen those particular rabid weasels and that pairof pants.   ---maf