Hi Ran, > I believe there would be broad support within the IPv6 WG to > have a small clarification to RFC-2460 that required the use > of Destination Options in all cases where they can be made to > work (in essence, this is Joel's I and II above). > > However, that could be done in a 1-page (plus boilerplate) draft. > > Since Suresh has been driving this issue, perhaps Suresh > could create such a 1-page (plus boilerplate) draft for the > IPv6 WG to review ? (:-)
I'm up for it :-). In fact I already suggested the meat in http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html "RFC2460 allows the use of both extension headers and destination options in order to encode optional destination information in an IPv6 packet. The use of destination options to encode this information, provides more flexible handling characteristics and better backward compatibility than using extension headers. Because of this, implementations SHOULD use destination options as the preferred mechanism for encoding optional destination information, and use a new extension header only if destination options do not satisfy their needs. The request for allocation of a Specific Type value MUST be accompanied by an specific explanation of why destination options could not be used to convey this information." Let's see how that is received by the WG. I would appreciate your responses to that specific mail. Cheers Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
