Subject: Re: [mobile-ip] when the MN returns home

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 03 Jun 2002 17:45:36 -0700

hi Francis,

how about this as a solution, when MN returns home?

1. the MN attaches to the home link. doesnt know that it is at home yet.

2. configures a link local address. starts DAD for it. in parallel it 
   sends a router solicitation with unspecified source address.

3. DAD fails if the HA is defending the link local address. it should
   also get a router advertisement in parallel.

4. the router advertisment tells the MN, that it is at home. it ignores
   the DAD failure (it should delay reacting to DAD failure, till it
   gets the router advertisement)

5. the current spec already talks about how to obtain the link layer
   address of the HA, if the router advertisment does not contain the
   source link layer address option or if the router which sent it is
   not the HA on the link.

6. When the MN realizes it has come home, it immediately sends a 
   deregistration BU to the HA, using the home address as the source 
   address.

7. the HA receives the BU and removes the binding cache entries for 
   the MN.

   (steps 6 and 7 work, Francis. even if the HA is defending the home 
    address of the MN, it can handle a unicast packet sent to it. it 
    does not matter if this unicast packet has the home address as 
    the source address. this has been tested at every interop I have 
    been to.)
   
please let me know, which of the above steps dont work. I think we
can come up with a solution.

regards
Vijay

ps: the MN should do step (2) everytime it attaches to a new link.

Francis Dupont wrote:
> 
>  In your previous mail you wrote:
> 
>    > => which source address the MN should use to send the deregistration
>    > message?
> 
>    the global unicast home address.
> 
> => this address is always protected by the HA: it is the worst choice.
> 
>    the deregistration BU is unicast to the HA. this works.
> 
> => with an old draft or with my proposal:
>  - the MN has just been attached to the home link
>  - it builds its link-local address and performs DAD for it
>  - (perhaps in parallel) its sends a RtSol to get prefixes and
>    a default router
>  - it gets a RtAdv from any routers on the home link (by application
>    of the Murphy's law, the first router to answer is never the HA).
>  - it finds a home prefix in the RtAdv and discovers it is at home
>  - it builds its addresses from the prefixes:
>    * if it performs DAD, it fails for the home address
>    * if it doesn't perform DAD (it was the case when I try 4 years ago),
>      see after
>  - it tries to send a BU to the HA
>  - as the HA address is not in the neighbor cache it sends a NbSol with:
>    * the home address as the source
>    * the solicited-node multicast of the HA address as the destination
>    * the HA address at the target
>  - the HA receives the NbSol and does a stupid thing with it,
>    in my case it sends a NbAdv to the previous care-of address of the MN
>    with a RH.
>  - the MN retries
>  - the MN retries
>  ...
> 
> Conclusion: it does not work. My fix was simple: I modify the code
> to always send the BU from the link-local address. It always works
> until someone has the bad idea to use S=0 or a previous equivalent.
> 
>    > => no, RFC 2462 describes a mechanism and an optional optimization.
>    > I simply propose(d) to keep the mechanism as it is and to forbid the
>    > optimization.
> 
>    it is not for MIPv6 to forbid this optimization. the safe thing to
>    do would be for the HA to defend the MN's link local address also.
> 
> => but this doesn't work...
> 
>    > => I have no trouble with the second statement. IMHO the optional optimization
>    > is a bad idea and should remove from RFC 2462 (bis or before). I believe
>    > most IPv6 implementors share my opinion, for instance the KAME team has
>    > removed the optimization from its code (ask them why).
> 
>    you can include me among the people who share this opinion. but you
>    still have a problem. there could always be an IPv6 implementation
>    which uses this optimization.
> 
> => could => must not
> 
>    > => as soon as an address can be formed in an other way than stateless
>    > autoconf (and this is the case with a HA on the link) the optimization
> 
>    why do you say if a HA exists on a link, stateful address configuration
>    would be used?
> 
> => no, what I said is mobility in the HA is not using stateless autoconf
> or even a stateless autoconf like mechanism. Mobility in the HA with
> S=1 and D=1 is very like manual configuration.
> I don't believe in DHCPv6: the highly tuned mechanisms to allocate addresses
> as a rare resource are not so well suited for IPv6 where there are 2^64
> available addresses per link...
> 
> Regards
> 
> [email-masked]
> 
> PS: I propose again:
>  - use RFC 2462 without the link-local optimization of DAD on the home link
>  - engrave the value 1 for the S bit
>  - ask the IPv6 WG to remove the link-local optimization in 2462bis

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Jun 2002 15:27:41 +0200

=> this is first an IPv6 WG issue so it should first be fixed by
the IPv6 WG. Or ask to change the charter of both mobile-ip and ipv6 WGs?

   

=> IPv6 specs are very accurate about what to do when DAD fails for
your own link-local address. What you suggest is *not* in the specs!

=> two remarks:
 - the current spec is wrong (some olders are correct so this is easy to fix)
 - if the MN link-local address is defended then the defender (the HA?)
   must put its link-layer address in the NA. The problem here is not
   to get the link-layer address, it is to recognize it is the HA one.

=> you assume there is no security, no network access control, etc,
on the home link. IMHO you should provide a temporary link-local address
the MN may use without trouble.

      
=> no interop used any kind of network access control.

=> we should get a resolution on the DAD or DIIDD issue first.
We are wasting our time on this list...

=> yes, the MN should follow RFC 2462 as it is an IPv6 node too.

Regards

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 04 Jun 2002 10:57:16 -0400

Ahh, I just found where this is specified and it looks like this
is a modification on the behavior mandated by 2461.

 From 2461:

"7.1.1.  Validation of Neighbor Solicitations

     A node MUST silently discard any received Neighbor Solicitation
     messages that do not satisfy all of the following validity checks:

     ....

       - If the IP source address is the unspecified address, the IP
         destination address is a solicited-node multicast address.

       - If the IP source address is the unspecified address, there is no
         source link-layer address option in the message."

It looks like Mobile IPv6 draft (section 11.6.7, paragraph 2) assumes that
a unicasted NS with an unspecified source will be accepted.  It will not be
because of the above rules.

If the intension is to supercede the 2461 NS validation rules, it should
be explicitely stated in the draft (and even then it's debatable if that's
the right thing).

-vlad

-- 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich	       Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 	       Tel: (603) 884-1079
Nashua, NH 03062	       ZKO3-3/T07

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Jun 2002 10:21:00 -0700

> your own link-local address. What you suggest is *not* in the specs!

I know that. I am saying MIPv6 MNs do that. they wait till they get
the router advert before responding to DAD.

>    to get the link-layer address, it is to recognize it is the HA one.

oops.. I thought the spec has been fixed. yes it is still broken. 
anyway here is how you can do it. this is from a mail I had sent 
in Aug 2001. this has been tested at the interops. 

the MN detects that it has returned home by getting a router
advertisement from the home agent or from a router on the home link. 
lets assume the router advertisement does not have a source link 
layer address option.

now the MN needs the home agent's MAC address to send a 
deregistration BU.

the MN sends a neighbor solicitation first

neighbor solicitation 
        src = unspecified address
        dst = all nodes multicast address
        target = Home Agent

the home agent receives the NS and respnds with a NA. since the 
source address for the NS was unspecified, the NA is sent to the 
all nodes multicast address.

neighbor advertisment
        src = link local
        dst = all nodes multicast address
        target = Home Agent

the MN receives this NA and creates a REACHABLE neighbor cache 
for the Home Agent.

after that the MN sends a BU for deregistration. the NS is a
basically a DAD probe. ofcourse if there are better ways, you 
can use it.

> the MN may use without trouble.

most network access control elements have two paths. uncontrolled
and controlled. you just need a special rule in your network access
control allowing packets which contain a BU. infact you can go 
farther and check the destination of the BU against the known home 
agents on the link. ofcourse, if your default router is your HA,
this is even easier. 

> We are wasting our time on this list...

there are two parts to this.

1. somebody could configure MN's link local address if the HA
is not defending it.

2. somebody can configure MN's home address if the HA is only 
defending the MN's home address and not the link local address. 
this is mainly because of RFC 2462's DAD optimization. if the 
IPv6 WG decides DAD optimization is a bad idea, we still have
(1), right??

regards
Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Jun 2002 10:28:58 -0700

> because of the above rules.

this is wrong in the spec. I thought this was fixed long back. see my 
earlier mail replying to Francis. the destination address is set to all
nodes multicast address. it is basically a DAD probe for the HA's
address.

maybe Francis has a better way of doing this. but currently we do a 
DAD probe for the HA's address and obtain the link layer address from
the subsequent Neighbor Advertisment from the HA.

ofcourse the best thing is for the HA to include Source Link Layer
address option in the router advert. this has two problems. 
(1) overhead. (2) the router which sent the router advert might not 
be the MN's HA. (I hate this. I wish there was just one HA on the 
home link and that is the default router).

> If the intension is to supercede the 2461 NS validation rules, it should

nope!

regards
Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Jun 2002 11:03:58 -0700

>         dst = all nodes multicast address

correction: the dst is set to solicted node multicast address
of the target address.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Jun 2002 11:11:59 -0700

> your own link-local address. What you suggest is *not* in the specs!

and the IPv6 specs say the interface SHOULD be disabled if DAD fails
for link-local address formed from the interface identifier.

section 5.4.5, RFC 2462

5.4.5.  When Duplicate Address Detection Fails

   A tentative address that is determined to be a duplicate as described
   above, MUST NOT be assigned to an interface and the node SHOULD log a
   system management error.  If the address is a link-local address
   formed from an interface identifier, the interface SHOULD be
   disabled.

this is extremem (IMO). I am just saying that an MN before disabling 
the interface, wait for the router advert to detect that it has 
returned home. the router solicitation was sent in parallel to the 
DAD neighbor solicitation. the router advert might even reach the MN 
first.

Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 04 Jun 2002 14:14:29 -0400

> nodes multicast address. it is basically a DAD probe for the HA's

This is the only spec I have (draft 17).  Also, it'll probably be better
to send to solicited node multicast of the HA address instead of all nodes.

-vlad

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 04 Jun 2002 14:17:56 -0400

Vijay

As you the spec states it is a SHOULD.  If you find a very good reason
(which you did) to not do that, you can overide the SHOULD behavior.

All we have to do is document the new behavior in the Mobile IPv6 spec
stating that this updates the bahavior in 2462.

-vlad

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Jun 2002 11:33:02 -0700

> stating that this updates the bahavior in 2462.

I agree.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 08 Jun 2002 00:27:12 +0300

> oops.. I thought the spec has been fixed. yes it is still broken. 

Assigned issue #44.

> in Aug 2001. this has been tested at the interops. 

Looks good to me.

I agree.

Jari