Subject: MIPv6 questions

From: "Jacques J. Ludman" <[email-masked]>
Date: Mon, 3 Apr 2000 13:57:22 -0400

I work in test development at UNHs InterOperability Lab and am currently
working on our Mobile IPv6 test suite.  I am having trouble discerning the
exact method by which (in the presence of a home-address option) ICMP6
checksums are calculated, and similarly, how AH works in this light:

	- We have 2 running MIPv6 implementations in our lab, and they
compute their ICMP6 checksum values differently in the presence of a
home-address option.  1 creates its pseudo-header based on the original
source address, the other implementation does it based on the address
present in the home-address option.  It is my understanding that the
latter of these approaches is the correct one based on the following text
in section 5.4 of the mobility draft (v. 11).

"  Upon receipt of a packet containing a Home Address option, the
   receiving node replaces the Source Address in the IPv6 header with
   the Home Address in the Home Address option. "

	- What order should/must the binding update, home-address option
and authentication header be placed in a binding update packet?  Strict
destination option processing order as prescribed in rfc2460 _almost_
forces the home-address option to be before the binding update (you can't
process options further in the packet, but you ?can? look ahead (both
ahead in that destination option header and for later destination option 
headers) to see if they exist).
		o If the home-address option precedes the authentication
header, does the AH calculate its ICV value based on a source address of
the home-address or the original value?  If it uses the orignial value,
then the original source address (which is used in computing the new
care-of address) is _not_ protected by the AH.  Also this would cause the
text of the AH document (RFC2402) to be out of date in a couple places
(source address is no longer immutable, ... ).  The alternative would seem
to violate option processing order.

Any insights would be greatly appreciated.

thx,
jj

ps: if I had my druthers, I would mandate (MUST) that the order be AH,
home-address, binding update and if they are not in this order the
receiving node MUST discard the packet.

 -----------------------------------------
/ Jacques J.Ludman			  \
| IP Consortium, UNH InterOperability Lab |
| Morse Hall, Room 332                    |
| 32 College Rd, Durham NH 03824	  |
\ tel: 862-0090 fax: 862-1761		  /
 -----------------------------------------

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Apr 2000 10:54:16 +0200

In your previous mail you wrote:

=> ICMPv6 checksums are computed with a pseudo-header which is
independent of all kinds of optional headers as the packet is
before applying them (RFC 2460 8.1).

   
=> I agree. RFC 2460 was written before the home address option but
the text about routing header is clear. Next version of RFC 2460 should
have a statement about home address options...
The transparency argument of sections 10.[12] of last I-D applies too
(ie. the upper-layer should do the same thing than no mobile IPv6 is here).

=> there are two questions:
 - the place of the destination option header which carries the home
   address option: it must be before the authentication header (I-D 11,
   section 10.2).
 - the place of the home address option into a destination option header:
   this doesn't matter, for instance if a binding update option and a home
   address option are both in the same header they can be in *any* order
   (but this should not happen because of the IPSec processing rule).

   		o If the home-address option precedes the authentication
   header, does the AH calculate its ICV value based on a source address of
   the home-address or the original value?

=> the home-address because of the order of headers (I-D 11, section 10.2).

   The alternative would seem to violate option processing order.

=> the option processing order (which is only recommended by RFC 2460)
is amended by the I-D 11. The rule against duplication of headers too
(as I noted in a previous mail in this list).

=> just read the last I-D section 10.2 which is very clear about IPSec
processing and header ordering.

=> if headers are not in the right order then the packet will not be
authenticated then will be discarded, ie. no extra statement is needed.

Regards

[email-masked]