Hi, all,
I suppose I'm in the group below.
IMO:
- the IPv6 base header and HBH EHs are the only ones that
intermediate nodes should even *look* at
- everything else should be prohibited
- there's little point in talking about middlebox behavior at all
until we have compliance verification in place
One other observation:
- frag processing doesn't say what to do with an exact overlap that
isn't a exact duplicate (e.g., when the content differs). AFAICT, that
should be treated the same as an overlapping fragment - i.e., only
*exact* duplicates should be (optional, as already noted) silent
discards (but this does then create a potential DOS vector because of
the additional processing for dup frags - and that should be noted).
AFAICT, the only way a "middlebox" can legitimately get away doing more
than above is when it can claim it is doing so on behalf of an endpoint,
i.e., to claim that the endpoint services are distributed upstream. IMO,
that argument is OK for devices under the same control as the endpoint,
but not otherwise. However, that's all just a philosophical argument
without compliance verification anyway.
Joe
On 2/4/2017 4:48 AM, tom p. wrote:
I do not know how to make it happen but I would like to see considered
opinions on this rather important issue from those I see active on lists
such as tcpm, arch-d and intarea whom I do not see active on v6(ops).
Tom Petch
----- Original Message -----
From: <otroan(_at_)employees(_dot_)org>
To: "Pete Resnick" <presnick(_at_)qti(_dot_)qualcomm(_dot_)com>
Cc: "tom p." <daedulus(_at_)btconnect(_dot_)com>;
<6man-chairs(_at_)ietf(_dot_)org>;
<draft-ietf-6man-rfc2460bis(_at_)tools(_dot_)ietf(_dot_)org>; "Stefano
Previdi"
<sprevidi(_at_)cisco(_dot_)com>; <ietf(_at_)ietf(_dot_)org>
Sent: Saturday, February 04, 2017 8:32 AM
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet
Protocol, Version 6 (IPv6) Specification) to Internet Standard
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.
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.
The chairs tried various approaches to find a consensus without luck.
The approach finally chosen was a poll between the three options. And
the (rough) consensus was based on the data from the poll.
Excerpt from the shepherds writeup:
A working group last call for moving this and the other two documents to
Internet Standard was started on 30 May 2016. Reviews were also
requested. Issues found during the last call and reviews were entered
into the 6MAN ticket system. These are now closed. The biggest issue
raised was how to handle the issue of Extension Header insertion in this
document. After many discussion on the mailing list and face to face
meeting, there wasn’t a clear consensus. The chairs conducted an online
survey that provided three choices: Ban header insertion, describe the
problems with header insertion, or say nothing. The result of the survey
was to describe the solution. The results and methodology used to
evaluate the results can be seen at:
https://mailarchive.ietf.org/arch/msg/ipv6/_gG2foiugk5B7w3TpnPvBbjHDzs
This was discussed at the 6MAN session at IETF97 and on the mailing list
after the meeting. The chairs believe there is a consensus to go forward
with the text that is in draft-ietf-6man-rfc2460bis-08.
The summary given to the working group calling for the poll:
https://mailarchive.ietf.org/arch/msg/ipv6/AtY92TpJ3vvmiidzcPkJdXKZQIA/?
qid=84de5e109c8f8f255d03c4c98ff3e50c
Best regards,
Ole, 6man co-chair