Subject: [mobile-ip] Re:

From: Charlie Perkins <[email-masked]>
Date: Tue, 04 Sep 2001 14:19:52 -0700

Hello Lars,

Charles Perkins wrote:

> Date: Thu, 2 Aug 2001 21:10:51 +0300 (EET DST)
> From: Lars Henrik Petander <[email-masked]>

> When implementing DHAAD, we noticed that the resending policy for the
> DHAAD request is not specified in draft 14. However, it probably should be
> specified, since the initial request or reply can easily get lost if MN
> moves.

O.K.  Here is my proposed text:

     If, after a mobile node transmits a Home Agent Address
     Discovery Request message to the Home Agents Anycast address,
     it does not receive a corresponding Home Agent Address
     Discovery Reply message within INITIAL_DHAAD_TIMEOUT
     seconds, the mobile node MAY retransmit the same
     Request message to the same anycast address.  This
     retransmission MAY be repeated up to a maximum
     of DHAAD_RETRIES attempts.  Each retransmission MUST
     be delayed by twice the time interval of the previous
     retransmission.

> Regarding the processing of the home address option section 8.1 says:
>    "... However, any actual modifications
>    to the Source Address field in the packet's IPv6 header MUST not
>    be performed until after all processing of other options contained
>    in the same Destination Options extension header is completed."
>
> Normally destination options are handled independently of each other in
> the order they are in the packet, which allows a clean design for
> destination option processing. Unfortuantely draft section 8.1 breaks this
> and requires the handler to go back to the home address option after
> processing all other destination options in the header. I wonder, whether
> this behaviour is really worth the complications it causes.

I agree that the specification needs to be changed.  Here is some
proposed text, which basically puts two sentences together.  The
second sentence specifies the required effect, and the new combined
sentence states that the required effect must be made to happen, but
doesn't say just how to make it happen.

     However, any actual modifications to the Source Address field in the
     packet's IPv6 header MUST be carried out in such a fashion that
     further processing of such a packet after all IPv6 options processing
     (e.g., at the transport layer)
     does not need to know that the original Source Address was a
     care-of address, or that the Home Address option was used in the packet.

Comments or suggestions for improvement will be appreciated.

Regards,
Charlie P.