Before finishing the last call for the mobile IPv6 draft, I'd like to
comment on the draft.
I hope this is not too late, and apologize in advance if this has
already been discussed.
Section 10.2 of the draft says as follows:
- Since the mobile node is away from home, the mobile node inserts
a Home Address option into the packet, replacing the Source
Address in the packet's IP header with a care-of address suitable
for the link on which the packet is being sent, as described in
Section 10.1. The Destination Options header in which the Home
Address option is inserted MUST appear in the packet before the
AH [11] (or ESP [12]) header, so that the Home Address option is
processed by the destination node before the AH or ESP header is
processed.
It seems to me that the order of the destination options header
including the home address option is not conformant to the recommended
order of extension headers specified in RFC 2460:
When more than one extension header is used in the same packet, it is
recommended that those headers appear in the following order:
IPv6 header
Hop-by-Hop Options header
Destination Options header (note 1)
Routing header
Fragment header
Authentication header (note 2)
Encapsulating Security Payload header (note 2)
Destination Options header (note 3)
upper-layer header
note 1: for options to be processed by the first destination
that appears in the IPv6 Destination Address field
plus subsequent destinations listed in the Routing
header.
note 2: additional recommendations regarding the relative
order of the Authentication and Encapsulating
Security Payload headers are given in [RFC-2406].
note 3: for options to be processed only by the final
destination of the packet.
At least for me, the above order assumes that a destination options
header placed before an authentication header (or an ESP) should also
be accompanied with a routing header. However, the mobile IPv6 draft
does not mention a routing header at all (I guess the draft does not
care about a routing header).
Is my concern about the order correct? If so, at least I want the
draft to describe the intention of the unrecommended order and
possible effects on implementation.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
