Subject: [mobile-ip] Resolution for issue #198

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 08 Jan 2003 10:55:34 -0800

Hello folks,

I guess that issue #198 is closed.

I do have a question, though, more or less out
of curiosity.  The following text is proposed to
be removed:

>    If the mobile node does Neighbor Solicitation to learn the home
>    agent's link-layer address, in this special case of the mobile node
>    returning home, the mobile node MUST multicast the packet, and in
>    addition set the Source Address of this Neighbor Solicitation to the
>    unspecified address (0:0:0:0:0:0:0:0).  The target of the Neighbor
>    Solicitation MUST be set to the home agent's IPv6 address, which is
>    known to the mobile node.  The destination IP address MUST be set to
>    the Solicited-Node multicast address [3].  The home agent will be
>    unable to distinguish this solicitation from a similar packet that
>    would only be used for DAD, and it will respond as if for DAD. The
>    home agent will send a multicast Neighbor Advertisement back to the
>    mobile node with the Solicited flag (S) set to zero.  The mobile node
>    SHOULD accept this advertisement, and set the state of the Neighbor
>    Cache entry for the home agent to REACHABLE.

What I want to know is what the intended effect will be from the removal.
It seems to me that there isn't any actual effect, because:

- The home agent has to be able to respond as noted in the
  paragraph, just because it has to follow protocol, and

- The mobile node has to be allowed to issue such multicast packets
  anyway, even if it never moves away from the home network, and
  even if it keeps records of the home agent's Link-Layer address.

I guess the point of the paragraph was to show how to do something
that has to be allowed, but with the new strategy is now not always
needed.

Regards,
Charlie P.

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 8 Jan 2003 14:28:43 -0700

Charles -

Actually, I was pleased to remove this DAD probe for address resolution ND
hack from my list of MN requirements to implement, since now I'm assured
(due to the new requirement text added per this issue, which makes it
mandatory for the HA to include the Source Link-Layer Address option in the
RA) that my MN implementation will discover the router's link-layer address
in the solicited RA (and, upon doing that, set the state of the Neighbor
Cache entry for the HA to REACHABLE for this special case).

With the new strategy of the HA including the Source Link-Layer Address
option in all RAs that it sends, this hack of doing a DAD probe to resolve
the HA's link-layer address is now NEVER needed (or, if it is needed, you
have a non-compliant HA implementation that you are attempting to
interoperate with).

My vote is always for reducing the complexity on the MN (unless there is a
real need/significant benefit for having it), since we are very motivated to
reduce ROM and RAM usage as much as possible in our embedded systems
protocol implementation.

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Charles E.
> Perkins
> Sent: Wednesday, January 08, 2003 11:56 AM
> To: Mobile IP Working Group
> Subject: [mobile-ip] Resolution for issue #198
>
>
> Hello folks,
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Jan 2003 18:12:54 +0200

> that has to be allowed, but with the new strategy is now not always

Yes. (Or more exactly, is never needed as far as our spec
is concerned.)

Jari