Subject: AD review of draft-ietf-6man-exthdr

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Nov 2011 10:21:47 -0800

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/

> This document intends
>     to define a standard format for IPv6 extension headers.

This document defines a standard ...

>     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."

>     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.

Jari

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 22 Nov 2011 00:08:02 -0500

Hi Jari,
  Thanks for the review. Please find responses inline.

>>     Also, Several existing deployed IPv6 routers and several existing

Will fix.

> This document defines a standard ...

Will fix.

> 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 d…

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?

> 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