comments on draft-baker-6man-hbh-header-handling-03

[神明達哉 <[e-mail]>]

I've read draft-baker-6man-hbh-header-handling-03 and have a few (I
guess minor) comments:

- Section 2.2

   As a side comment, the Routing Header, which is an extension header
   rather than a list of options, is treated similarly; when a system is
   the destination of a packet and not the last one in the Routing
   Header's list, it swaps the destination address with the indicated
   address in the list, and updates the hop count and the list depth
   accordingly.

To be very accurate (and in my understanding), this level of behavior
depends on the type of the routing header.  Now-deprecated type-0
routing header certainly behaves this way, but I guess other types of
routing header may not necessarily behave as described above, as long
as it meets the general rules defined in RFC2460.

- Section 2.2

   Such options must be marked appropriately (their option type is of
   the form XX1XXXXX), and are excluded from checksum calculations in AH
   and ESP.

If this draft focuses on hop-by-hop options, this sentence is not 100%
accurate or at least a bit confusing, since the HbH options header is
excluded from ESP's integrity check.

The same comment applies to Section 2.3 (regarding HbH options
header).

- Section 2.3

   Use cases under current consideration take this a step further: a
   router or middleware process MAY add an extension header, [...]

I suspect this violates the latest clarification in rfc2460bis:

   Extension headers must never be inserted by any node other than the
   source of the packet.

BTW, I'm not sure how I should interpret "middleware process".  Does
this mean some kind of shim layer on the sending node?  If so, in that
case we may be able to say it 'MAY add an extension header', but
without a clear definition of this term I'm not sure if it's correct.

--
JINMEI, Tatuya