On 16 Nov 2010, at 19:45 , Hagen Paul Pfeifer wrote:
> Hing is absolute correct - this mechanism is necessary,
> there are no valuable alternatives.
As I've described in my response to him earlier today,
the I-D doesn't actually solve the problem that you all
describe, because some different IETF WG can create a new
protocol (e.g., some non-IPv6-specific protocol), with
a new Protocol number assignment, using any syntax that
WG desires to use.
The IETF IPv6 WG lacks authority over, for example, IETF WGs
in the RAI, Applications, or TSV Areas that might define
generic extensions that use Protocol number values and
whose extensions apply both to IPv4 and IPv6.
A simpler alternative -- and one that actually DOES solve the
concern you all seem to have -- is to require all future IPv6
extensions to use either the Destination Options or Hop-by-Hop
headers, which already have quite clearly defined syntax rules,
are already supported by deployed systems, and are already parsable
by deployed silicon.
> Or to quote the Linux Kernel:
>
> int ipv6_ext_hdr(u8 nexthdr)
> {
> /*
> * find out if nexthdr is an extension header or a protocol
> */
> return (nexthdr == NEXTHDR_HOP) ||
> (nexthdr == NEXTHDR_ROUTING) ||
> (nexthdr == NEXTHDR_FRAGMENT) ||
> (nexthdr == NEXTHDR_AUTH) ||
> (nexthdr == NEXTHDR_NONE) ||
> (nexthdr == NEXTHDR_DEST);
> }
>
>
> If the extension header is no well known extension header (see the code) the
> network stack must stop processing of the packet!
A complete fix for the issue you all express concern about is
to clarify that all IPv6-specific extensions MUST NOT create
a new extension header, and instead MUST use either the existing
Destination Options header or the Hop-by-Hop Options Header.
This restriction is consistent with and only slightly stronger
than the severe restrictions on new end-to-end extension header
creation that is already present in RFC-2460 Section 4.6
(see also my other reply of this morning).
If someone can come up with a single example of a potential
extension that is neither hop-by-hop nor end-to-end in nature,
then the paragraph above might need to be edited slightly.
Your assumptions that I don't understand IPv6 or kernel code
are both demonstrably false. In fact, I've got a lot more
experience with IPv6 options than most folks, see for example
RFC-5570 and draft-rja-ilnp-nonce. I was also part of the team
that developed the VERY first IPv6 implementation in the entire world
(i.e. NRL IPv6+IPsec for 4.4 BSD) -- we had working IPv6 packets on
Ethernet BEFORE the IPng decision was announced. So I've got
specific IPv6 kernel experience going back to 1995.
Yours,
Ran
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
