Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, V

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, otroan(_at_)employees(_dot_)org 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

signature.asc
Description: Message signed with OpenPGP