On 2018-12-05 14:17, Joe Touch wrote:
> It’s difficult to reconcile the text from other RFCs below with the fact that 8200 kept the 01, 10, and 11 option types.
>
> Joe
>
>> On Dec 4, 2018, at 2:56 PM, C. M. Heard <heard@xxxxxxxxx> wrote:
>>
>> On Tue, 4 Dec 2018 15:17:33 -0500 Christopher Morrow wrote:
>>> A solution might be to have a mode where a router may just ignore all
>>> headers except the src/dst-ip and simply forward all packets, trusting
>>> that the conversing adults will sort out problems with unknown/new/
>>> experimental headers or with a tortured ordering of headers (for
>>> instance).
>>
>> Glad to hear you say that, because that's exactly what RFC 7045
>> envisions as the default forwarding behavior:
>>
>> Any forwarding node along an IPv6 packet's path, which forwards the
>> packet for any reason, SHOULD do so regardless of any extension
>> headers that are present […]r
>
> This text is in direct contradiction to RFC2460 as per above.
Of course. RFC 7045 updated RFC2460.
>
>>
>> Recognizing that processing of Hop-by-Hop Options in the fast path is
>> costly, RFC 8200 formally dropped the requirement for every router to
>> process them by default:
>>
>> NOTE: While [RFC2460] required that all nodes must examine and
>> process the Hop-by-Hop Options header, it is now expected that nodes
>> along a packet's delivery path only examine and process the
>> Hop-by-Hop Options header if explicitly configured to do so.
>
> That is an expectation of the inadequacy of others. It does not clearly drop the requirement.
If so, that was a drafting error. RFC 7045 already formally changed
it to a SHOULD.
And IMHO it's entirely correct. For example, making the open Internet completely transparent to HbH means that a HbH-using application has a chance of crossing the open Internet successfully. By contrast, expecting line-speed routers on multi-Gbit
intercontinental links to process HbH condemns such an application to failure.
This was all thrashed out when we drafted RFC 7045 and again when we
drafted RFC 8200.
What's new here is that OPSEC wants to legitimise filtering for reasons
other than performance, and that's contentious.
Brian
>
>>
>> What some of us would like to see is a statement in the draft that it's
>> just fine to operate this way (Christian Huitema made that suggestion
>> earlier in this thread, and so did I in my detailed last-call comments).
>>
>> Mike Heard
>>
>> _______________________________________________
>> Tsv-art mailing list
>> Tsv-art@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/tsv-art
>
>
