Hi Jari, Thanks for the review. Please find responses inline.
On 11/21/2011 01:21 PM, Jari Arkko wrote: > I have reviewed this draft. It is ready to move forward, and I have requested > a last call to be initiated. In the meantime, I also had a few mostly > editorial comments that you may want to take into account: > >> Also, Several existing deployed IPv6 routers and several existing >> > > s/Several/several/ Will fix. > >> This document intends >> to define a standard format for IPv6 extension headers. > > This document defines a standard ... Will fix. > >> The base IPv6 standard [RFC2460 <http://tools.ietf.org/html/rfc2460>] >> defines 3 extension headers (i.e. >> Routing Header, Destination Options Header, Hop-by-Hop Options >> Header) to be used for any new IPv6 options. The same standard only >> allows the creation of new Extension Headers in limited circumstances >> [RFC2460] Section 4.6 <http://tools.ietf.org/html/rfc2460#section-4.6>. >> >> As noted above, the use of any option with Hop-by-Hop behaviour can >> be problematic in the global public Internet. So new IPv6 Extension >> Header(s) having hop-by-hop behaviour MUST NOT be created or >> specified. Also, new options for the existing Hop-by-Hop Header >> SHOULD NOT be created or specified unless no alternative is feasible. >> Any proposal to create a new option for the existing Hop-by-Hop >> Header MUST include a detailed explanation of why the hop-by-hop >> behaviour is absolutely essential in the Internet-Draft proposing the >> new option with hop-by-hop behaviour. >> > > It might also be useful to point to RFCs 5095 and 5871 as pointing out > difficulties that the design of new routing header types can bring. E.g. > "Similarly, as discussed in RFCs 5095 and 5871, the design of new Routing > Header types may lead to security vulnerabilities and alternatives for such > designs need to be carefully assessed." These two RFCs deal with security issues specific to routing headers that are not widely applicable to other extension headers that may be created. Also new routing header types can be created without even creating any new extension headers. Is there something specific from these RFCs that you think will be applicable here? > >> The scheme proposed in this document is not intended to be backward >> compatible with all the currently defined IPv6 extension headers. It >> applies only to newly defined extension headers. Specifically, the >> fragment header predates this document and does not follow the format >> proposed in this document. > > Are there others? If yes, it would be good to mention them as well. AH and ESP do not follow this scheme either but there was no consensus to treat them as extension headers since they could be used with IPv4 as well. I argued that RFC2460 identifies them as extension headers but there were not many takers for that argument. Thanks Suresh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
