Hi again,
- should we drop a packet silently - without returning ICMPv6
parameter
problem (jabley's suggestion), or should we return ICMPv6 so that
innocent user of rthdr0 would be notified (kame's latest tree).
since there's no amplification and ICMPv6 errors are rate-limited,
returning ICMPv6 parameter problem would not harm that much (even
under DDoS condition - depending on how your implementation do
rate-limit).
If RH0 is deprecated, the processing of this extension falls back to
RFC 4443:
If an IPv6 node processing a packet finds a problem with a field in
the IPv6 header or extension headers such that it cannot complete
processing the packet, it MUST discard the packet and SHOULD
originate an ICMPv6 Parameter Problem message to the packet's
source,
indicating the type and location of the problem.
- packet filters MUST have filtering language/syntax/whatever that
supports rthdr0. openbsd guys are working on it - PF syntax
will be
annotated with new rule. see May 8 entry by [EMAIL PROTECTED] at
http://opengrok.creo.hu/openbsd/history/src/sys/net/. more to
come.
The wise choice is that packet filters must *support* RH2.
I am really scared that these discussions about RH0 also kill RH2 and
Mobile IPv6. That will probably lead to another endless discussions
to decide how the same feature as RH2 could be re-added to Mobile
IPv6 (i.e. a specific Home Address Extension that do not share the
same next header value as RH0). Shisa's people might be useful here.
A last comment on the two drafts, I think that they need to be merged
(and draft-jabley-ipv6-rh0-is-evil stopped). The discussion about
IPv4 should be removed. Some sentences in the introduction explaining
that SR processing is disable are enough.
Guillaume
--
Guillaume Valadon / ギョーム バラドン
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
