Hi,
In fact, the Home Address has to be also BEFORE the fragment header to
allow firewalls to read it. Those firewalls
can be on other destinations than those listed in the Routing Header.
May be it needs to clarify to put a recommendation in RFC2460 or
in the next RFC MobileIPv6 this special case.
Best regards
JINMEI Tatuya / 神明達哉 wrote:
>
> 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]
--
________________________Aime LEROUZIC____________________________
BULL S.A ECHIROLLES FRANCE mailto:[EMAIL PROTECTED]
http://www-frec.bull.com tel: +33 (0)4 76 29 75 51
Communications TCPIP http://intranet/lerouzic
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
