Hi Thomas, Please see responses inline. > -----Original Message----- > From: Thomas Narten [mailto:[email protected]] > Sent: Monday, January 03, 2011 3:40 PM > To: Suresh Krishnan > Cc: Tony Li; [email protected] > Subject: Re: I-D Action:draft-ietf-6man-exthdr-01.txt > > FWIW, I'm sympathetic to Tony's basic sense that it is > unclear that we need to do this work/document. > > I'm still not clear on exactly what *real* problem it solves. > > Suresh Krishnan <[email protected]> writes: > > > Since RFC2460 came out, four new extension headers have > been defined. > > > 135 - Mobility header > > 139 - HIP > > 140 - Shim6 > > 141 - WESP > > 2 of the above code points are used by IPv4, so having a > generic extension header mechanism for IPv6 would have saved > only 2 code points. No need to panic folks... > > > The idea of burning one protocol number right now was > suggested by the > > WG in order to limit further exhaustion of the protocol > number space. > > Would it be more acceptable to you, if we do not ask for an IANA > > allocation for a protocol number at this point, and wait till the > > first "Specific Type" request comes up? > > My general sense is that this work is mostly just good common > sense advice to someone who has a need to define a new > extension type. But until we see such a concrete proposal, I > am not convinced (yet) that we should define anything new > that suggests people go change implementations or allocate > code points. Both are premature.
OK. > > As one concrete example, RFC 5175 defines extensions for > adding future RA flags. But, none have been defined yet, so > the work really isn't needed yet and implementations > certainly don't need to do anything yet. However, that has > not stopped NIST and DoD from citing these documents > recommendations to implement. > > Upleveling a bit, and thinking about routing headers and > destination options, my general sense is about such options is: > > 1) Destination options are the preferred route. Any other > kind of option will be extremely hard to deploy, has all > kinds of barriers, etc. (This proposal will have no impact on > future destination options. Right?) Correct. And I proposed adding the following text to this draft to state this fact. "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." http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html > > 2) The routing header is essentially deprecated, and we > probably won't define any more. We've already deprecated RHO. > RH1 was never used, is now deprecated, and arguably shouldn't > even count as ever having been defined. RH2 is the MIP > routing header. RH2 was originally a regular type 0 option, > but was changed because of the fear that firewalls would > block packets with such options by default, preventing MIPv6 > from being deployed. If we had to do it all over again, MIPv6 > arguably should have used a destination option, since by > definition RH2 is only processed if the two addresses in the > routing header are on the same node, which is much more in > line with the intention behind destination options. > > Which leads me to ask, exactly what kinds of future options > do we think will take advantage of this new format? Not sure. The goal is to make sure that other wgs that define ipv6 specific optional information do so in a consistent way. I think the burden would be on them to prove that destination options do not fit their need. > > Note, my bias on this general topic is based on experience > that unless we have something concrete driving this sort of > work, we risk getting it wrong. So, I'm still trying to be > convinced we need to do this sort of work *now*. If there was > an actual proposal for a new option that solved some sort of > real problem, things might be different. The "concrete" thing was the need for firewalls to differentiate between unknown extension headers and unknown transport protocols. There were two firewall vendors who spoke up for this at a 6man wg meeting. It is possible that they no longer care. That is why I am trying to see if there is any reason to continue with the draft, and if so what it should contain. I would Appreciate your comments on this mail. http://www.ietf.org/mail-archive/web/ipv6/current/msg13207.html Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
