Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

[[e-mail]]

Pete,

> After reading the replies, I wonder if you could amend your summary with one point in particular:
> 
> On 4 Feb 2017, at 2:32, [e-mail] wrote:
> 
> There were three main positions argued in the working group.
> 
> 1) Ban header insertion outright.
> 2) Describe the problems with header insertion.
> 3) No changes to RFC2460 text.
> 
> What did you see as the objections to going with (1) (which I presume to be the equivalent of Brian's proposed text)? Why was it that people thought the protocol could not be clarified to say that? And was your assessment that those arguments were correct, or that they simply were not addressed by the WG? I've seen several people argue on this list that (1) was always the intent of the protocol, and that damage occurs if you don't follow that directive. I haven't seen anyone here argue otherwise. Could you summarize?

I can try. It has been difficult to distill the essence out of all the mailing list discussions.
This is _my_ take of the discussion and arguments as I understood them. Please chime in with corrections.

The arguments of what would break are correct. The counter-arguments given would be that this is done within a controlled domain and the potential for damage could be controlled.

The discussion went something like (paraphrasing):

 - Inserting headers will break Path MTU discovery, AH and may result in unsuspecting hosts receiving ICMP error messages.
 - We will do this in a controlled domain only.
 - Even if you can guarantee it will not leak, it is not appropriate to specify that in the core IPv6 specification
 - We don't need that, we just need 2460 not to ban it. IPv6 is used in many networks not only the capital I Internet.

There was also quite a bit of discussion on the intent of the original authors. I don't know how much value it is correct to give that argument. "This is what I intended, but not what I wrote...". Given that this is in any case the output of the IETF and not two individual authors.

1) Ban header insertion outright.

Objections:
a)  There are proposals wanting to insert headers:
   - draft-ietf-6man-segment-routing-header
   - draft-brockners-inband-oam-transport
   - Just now: draft-francois-dots-ipv6-signal-option-01

i) Out of scope: Argue the point of header insertion or alternatives in the context of those proposals, not in the context of the core IPv6 specification. Do not try to make a preemptive strike in the core specification.

ii) Use encapsulation alternative has problems. In e.g. inband-oam some meta-data is attached to a packet on ingress into a domain and removed at egress of the domain. The ingress doesn't necessarily know the egress, normal destination routing is supposed to happen. That is hard to achieve with a encapsulation solution.

iii) Use encapsulation alternative has problems 2. A packet with extension headers would be processed normally by an unmodified end host,
while an encapsulated packet would not.

b) RFC2460 is already clear and no clarification is needed. No interoperability issue has been shown caused by this perceived ambiguity.

2) Describe the problems with header insertion.

Objections:
a) The list of problems with header insertion can never be complete. It might be misconstrued as the only set of problems required to be solved to allow header insertion.

b) Speculating about something we don't know how to do (header insertion) is not appropriate when bringing the specification to internet standard.

c) Leaves the ambiguity in place.

3) No changes to RFC2460 text.

Objections:
a) Leaves the ambiguity in place.

There was hard to find consensus on either of the alternatives. As the poll shows there was a clear preference (if people couldn't get their first choice) to describe the problem, over banning it, or over saying nothing.

Best regards,
Ole