Re: [arch-d] Fiddling with IP packets in the network, IPv6-style (Fwd: Question about SRv6 Insert function)

[Alexandre Petrescu <[e-mail]>]

Le 05/09/2019 à 02:47, Fernando Gont a écrit :
> Folks,
> 
> There seems to be ongoing working group item in the spring wg
> (https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01)
> that essentially proposes the insertion of IPv6 Extension Headers by
> middle boxes in the middle of the network, which goes against a very
> explicit requirement in the IPv6 spec (RFC8200) -- that notes that EHs
> cannot be inserted in the middle of the network.
> 
> This begs a number of questions (e.g., how come that one wg is working
> on something that goes against a spec that is not under its charter).
> 
> But given this is an architecture list, I wonder if anybody has a say on
> the topic? (including the IAB). Is that the way IPv6 is expected to
> work? What can we expect from IPv6?

Can we expect IP at large to touch headers of end user packets?  No. 
Can we expect it in a 'limited-domain'?  Yes, and I'd say INFORMATIONALly.

Alex

> 
> 
> 
> -------- Forwarded Message --------
> Subject: Re: Question about SRv6 Insert function
> Date: Thu, 5 Sep 2019 03:34:09 +0300
> From: Fernando Gont <[e-mail]>
> To: Ole Troan <[e-mail]>, Fernando Gont <[e-mail]>
> CC: Ron Bonica <rbonica=[e-mail]>, [e-mail]
> <[e-mail]>, [e-mail] <[e-mail]>, Suresh Krishnan
> <[e-mail]>, draft-voyer-6man-extension-header-insertion
> <[e-mail]>,
> draft-ietf-spring-srv6-network-programming
> <[e-mail]>
> 
> On 4/9/19 09:58, Ole Troan wrote:
>> Fernando,
>>
>>>>> Since there have been plenty of attempts to do EH insertion or
>>>>> leave the IPv6 standard ambiguous in this respect, and the IETF has
>>>>> had consensus that EH insertion is not allowed, I think it would be
>>>>> bad, wastefull, tricky, and even dangerous to let a document go
>>>>> through the whole publication process, and just rely on the AD to
>>>>> keep the "DISCUSS" button pressed.
>>>>>
>>>>> Put another way: what'd be the rationale for having a draft-ietf
>>>>> and have the corresponding wg ship the document with something that
>>>>> clearly goes against IETF consensus, and that the relevant AD has
>>>>> declared that wouldn't let pass?
>>>>
>>>> In short, this is not the case. I am *not* the relevant AD for the
>>>> SRv6 Network Programming draft. If this document was in 6man I would
>>>> have flagged it much earlier like I did for the SRH draft.
>>>
>>> Sorry, what I meant by "relevant AD" is: "one of the responsible ADs for
>>> the spec that's being violated".
>>>
>>> i.e., isn't there in the IETF process -- whether formal or informal --
>>> for this sort of thing to be flagged before documents get too far in the
>>> publication process?  ("Hey, this document in your area is actually
>>> breaking a spec of one of my wgs" sort of thing...)
>>
>> I would prefer that we calmed down a bit on the protocol policing.
> 
> Sorry, but this has nothing to do with protocol policing. It has to do
> with respecting the consensus this wg and the ietf as a whole had on the
> topic. i.e., that EHs must not be inserted in the network.
> 
> We'd go into an interesting path to insanity if we publish specs, and
> subsequently publish conflicting specs that simply ignore previous ietf
> consensus.
> 
> If folks want to do EH insertion, the #1 step is to publish a document
> that updates RFC8200 such that the "EHs must not be inserted..." is
> replaced with something else or eliminated.
> 
> 
> 
>> We know that header insertion breaks unsuspecting source hosts if done by the network.
>> It breaks (at least) PMTUD, ICMP errors and AH.
>>
>> What we have said in the past is; explain how those issues are dealt with or do not apply to your proposal.
> 
> That's what you and others may have said or thought. But the consensus
> is what's in the standard (RFC8200). And the standard says that EHs
> cannot be inserted in the network. If you want to do it, the first step
> is to update RFC8200.
> 
> 
> 
>> And some form of "doing on behalf of" is not necessarily problematic.
> 
> It is rightaway problematic specs-wise when it violates a crystal-clear
> requirement in RFC8200, that we arrived to after a very heated debate,
> and lots of enegery and time from all the involved people.
> 
> The fact that after all the long story behind publication of rfc8200 as
> standard (and the ongoing srv6 document we're doing here, which was
> adopted on the condition that it wouldn't do eh-insertion), we can live
> with other wgs violating specs that we produced here with so much effort
> and time, is kind of amusing.
> 
> If folks want to allow EH-insertion (i.e., formally allowing middleboxes
> to fiddle with packets), RFC8200 should be updated, and the work should
> be done in 6man.
> 
> I don't think it's SPRING's call how the IPv6 protocol works.
> 
> 
> 
>> It's the "blind" "Thou shalt not do" that I object to. As opposed to arguing on technical grounds.
>>
>> Ensuring interoperability is our purpose. Not protect 8200 as if it's a religious text.
> 
> My #1 concern (not that I don't have others) is one related to fairness
> of the standardization process. I don't think we should simply
> rubberstamp anything a big vendor wants to sell, no matter how big the
> vendor is, or how much money may be involved.
> 
> And if this working group (and the IETF as a whole) published a spec on
> which there was consensus, ignoring the spec and doing whatever one
> pleases is not the way to go. Firstly, make e the case for updating
> RFC8200. Then come up with the proposal to fiddle with packets in the
> network.
> 
> P.S.: I've never been into the camp of protecting X (whether rfc8200 or
> any other document) as if it was religious text. Quite ironically, I
> have experienced such religious opposition in 6man itself (for instance,
> your argument of "don't fix slaac-renumbering because ipv6 has not been
> designed to support flash renumbering" seems pretty much a religious
> argument against work that would not result in any major modifications
> to any of the protocols involved -- as opposed to EH insertion).
>