Re: [Spud] updated draft PLUS charter, rev. 1 June

[Tom Herbert <[e-mail]>]

> I am also intrigued by Tom's earlier suggestion that using IPv6 DO headers might have reflection-reducing properties, given the installed base. We should look into that more deeply.
>
The solution would be to use hop-by-hop options. These would have a
lot of advantages:

- HBH options work with any transport or IP protocol (TCP, SCTP, UDP,
IPsec, GRE, etc.) not just new UDP based transport protocols. This
means adding host to network signaling could be done as an incremental
change to the existing mostly TCP Internet (I think this is a major
benefit).
- For a fragmented packet each fragment can contain hop-by-hop options
but not each one contains transport headers.
- Hop-by-hop options must be first extension header in the packet so a
network device only needs to parse the IPv6 header and one type of EH.
If a middlebox has to access the transport layer header and payload it
would need to be able to parse over other types of extension headers
(routing, DO, etc.)
- HBH can be replicated as desired in the outer headers if packets go
through an IP tunnel.
- IP protocol numbers are unambiguous. If IPv6 next-hdr value is 0 the
next header in a packet contains an extension header as a global
invariant. No magic numbers needed.
- Extension headers are not automatically reflected by any service.
- It is within the protocol to modify the contents of HBH options (as
specified in the definition of an option). There is also no checksum
that needs to be updated unlike the case of UDP payload being
modified.
- The rules for processing HBH options are being relaxed in 2460bis.
Previously, all nodes in a path were required to inspect them. The new
text allows nodes in the path to ignore them and forward packets as
without processing or modifying HBH options.
- RFC3542 defines a sockets API that seems to be supported by the
major OSes. Applications probably are permitted to set arbitrary
options in packets that may affect the network, however allowing
application specific options that are deemed safe can done by
whitelist.
- HBH options obviously only works with IPv6 and is not available in
IPv4. I actually think this is a good thing since supporting
forwarding looking functionality only in IPv6 would promote continued
transition to IPv6 in the Internet and is in alignment with the early
efforts for sunsetting IPv4.

 Tom