ietf
[Top] [All Lists]

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

2017-02-04 03:10:50
On 02/04/2017 05:32 AM, otroan(_at_)employees(_dot_)org wrote:
Thank you Pete! You are of course right.

Let me try to provide some background of the issue.

The contentious text is the following paragraph from 2460:

With one exception, extension headers are not examined or processed 
by any node along a packet's delivery path, until the packet reaches 
the node (or each of the set of nodes, in the case of multicast) 
identified in the Destination Address field of the IPv6 header.

Essentially the question is: - Does the IPv6 architecture permit
insertion of extension headers and/or header options by a node along
the packet's delivery path?

This question came up triggered by discussions around some recent
proposals: - draft-ietf-conex-destopt, - RFC4782 (does header
deletion) - draft-ietf-6man-segment-routing-header -
draft-brockners-inband-oam-transport

The IP architecture (IPv4 and IPv6) supports _modifying_ IP options
in flight, but it is unclear if it could permit changing the IP
datagram's size. 

The only case that can be made for that is that the spec doesn't say
"insertion of EHs is forbidden" -- but then, if you were to have to
write a spec explicitly noting everything that is forbidden, you
wouldn't be able to achive that in your lifetime.

Everyone has agreed (including the authors of RFC2460) that EH insertion
has never been allowed.



Increasing a packets size in flight would break
PMTUD (RFC1981), AH, and might results in other ICMP error messages
being sent to an unsuspecting source.

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.

Permitting header insertion in the sense of specifying how header
insertion could possibly work is of course outside the scope of
advancing RFC2460.

Explicitly allowing EH insertion would most likely be out of scope, too:
It completely changes a very basic aspect of IPv6.

FWIW, I think that publishing a spec with what some have considered to
be ambiguous text (subsequently leading to 600+ messages on the very
group that specifies the protocol) would be a lousy job on our side.
Either explicitly ban extension header insertion, or explicitly allow it.

Whether EH insertion is allowed (or not) seems to me like a very basic
question that the protocol spec should be able to answer -- particularly
since we're moving it to Standard.

Given that the question has been "raised", it deserves an answer in the
spec. Otherwise, when asked "Are intermediate systems allowed to mangle
with IPv6 packets as they please?", I guess we'd have to answer "We
don't know... but neither did the group that wrote the spec".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




<Prev in Thread] Current Thread [Next in Thread>