Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt

[Brian E Carpenter <[e-mail]>]

On 28-Nov-19 07:11, Tom Herbert wrote:
> On Tue, Nov 26, 2019 at 6:53 PM Brian E Carpenter
> <[e-mail]> wrote:
>>
>> Hi Tom,
>> On 27-Nov-19 15:01, Tom Herbert wrote:
>>> On Tue, Nov 26, 2019 at 5:19 PM Brian E Carpenter
>>> <[e-mail]> wrote:
>>>>
>>>> On 27-Nov-19 14:00, Gyan Mishra wrote:
>>>> ....
>>>>>
>>>>> I am in agreement with individual submission.
>>>>
>>>> Nobody has suggested an "individual submission" RFC, which means direct submission to the IESG for the IETF stream, sponsored by an AD.
>>>>
>>>> The alternatives that have been suggested are
>>>> 1) WG Informational submission to the IETF stream.
>>>> 2) Independent Submission (https://www.rfc-editor.org/about/independent/). Also see RFC 4846 and RFC 5744 if you are not familiar with the Independent Submission process.
>>>>
>>>> Personally, I'm in favour of documenting reality, as this draft does, and as long as it's Informational I really don't care which RFC Stream is used.
>>>
>>> Brian,
>>>
>>> To me, this "reality" would be akin to acknowledging a serious bug but
>>> simply marking it "will not fix" instead of actually fixing it. Both
>>> the detrimental consequences of EH insertion and conformant
>>> alternatives to it have been articulated several times on this list,
>>> but we've seen little effort from the extension header insertion
>>> proponents to take those into account or to work with WG to resolve
>>> the issues.
>>
>> I don't think that's fair. The current version of the draft is utterly
>> different from the original, and the tone of the discussion at IETF 106
>> was constructive (http://ietf106.conf.meetecho.com/index.php/Recordings#6MAN_II).
>>
> 
> Brian,
> 
> That's fine that it was a productive meeting and yes the draft has
> improved, but as others have already pointed out real work and
> decisions only happens on the list. We really need productive
> discussion here.
> 
>> The proposal by the WG chairs seems very balanced to me. Work on documenting
>> why header insertion that escapes a limited domain is harmful (Mark's draft)
> 
> I believe that mischaracterizes Mark's draft (I am also an author of
> the draft). 

Ah, sorry, yes!

> The message of that draft is that IPv6 extension header
> insertion is harmful without qualification.

But... what happens in a limited domain stays in the limited domain.
Basically neither the IETF nor anybody else can even know about
strange things that occur entirely within a domain. The message I
get from your draft is that there can only be harm to third parties
if a munged packet escapes.

> Neither does RFC8200 have
> any provisions or exceptions that would change the behavior or
> requirements on the basis of the environment the protocol is run. For
> instance, the loss of attribution of packet contents to the source,
> which is fundamental to IP protocols, is not resolved by restricting
> use to a limited domain.

Correct. But maybe the operator doesn't care if an ICMP error is
reported to the originator of the packet without any ability to
identify the header-inserting node. (That's an issue I'd expect
draft-voyer to discuss, which it doesn't at the moment.)

> 
>> and work on documenting existing practice in real products and real
>> networks.
> 
> Okay, but if the WG is going to work on this, doesn't that mean it
> needs to be Working Group item? Will there be a call working group
> adoption on the list?

Suresh answered that.
 
>> We often document existing practice, on the grounds that it's
>> better than ignoring it. That's what draft-voyer--08 does.
> 
> We definitely have not been ignoring this! There has been substantial
> feedback already on various versions of the draft.

Indeed, and I didn't conceal my dislike of the early versions. I'm also
strongly in favour of draft-smith. My concern is more that we shouldn't
repeat the IETF's mistake over NAT44 (pretending it wasn't there for years,
and finally producing RFCs in catch-up mode).

On a broader note, extension headers should be one of IPv6's main selling
points. We need to figure out how to make them more usable than they
currently are.

Regards
    Brian