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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 15 Jan 2003 16:34:05 -0000

Hi Jari:

The change adopted for issue 198 seems to imply that the MN learns that
it comes back home from a RA issued by THE HA it is registered to. But
if there are a bunch of HAs, or routers that are not HAs on the same
prefix, then the MN may get the info from a different source. Then what
does it do? Sollicit and wait till its HA talks? 

There are cases of MN coming back home, with the memory of which HA it
registered to being lost, eg in a reboot, so it may be difficult to
deregister properly.

There may be a simple way, like to consider a priority on who should own
the home address. For instance, HAs should be low priority and always
yield (remove the BCE) when they detect a duplicate. A MN that
autoconf'ed its home address should go on and compute a new one. A MN
with a configured home address should stick to it and win against the
others - if the condition stays for a period, then it would retreat as
ND suggests).

What do you think?

Pascal

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: vendredi 10 janvier 2003 17:13
> To: Charles E. Perkins
> Cc: Mobile IP Working Group
> Subject: Re: [mobile-ip] Resolution for issue #198
> 
> 
> Charles E. Perkins wrote:
> 
> > 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.
> 
> Yes. (Or more exactly, is never needed as far as our spec
> is concerned.)
> 
> Jari
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Sun, 19 Jan 2003 15:24:35 +0200

> registered to being lost, eg in a reboot, so it may be difficult to

Sigh, it appears that we can't omit this special case. I'll still
keep SLLA as mandatory but we'll have to specify how to deal with
this in the case there are multiple home agents. I'll put the old
text on this back.

See http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev6.html#return-home

Alternatively, we could have required the mobile node to wait
until its own home agent advertises the information. However,
this will fail if that home agent is off at the moment -- and
while we have a procedure on what to do if the home agent is not
responding, we don't have a procedure on what to do if
we end up "half-way home". So it seems like our only possibility is
to take back the old paragraph.

Jari

---

From: Ville Nuorvala <[email-masked]>
Date: Mon, 20 Jan 2003 13:56:44 +0200 (EET)

> this in the case there are multiple home agents. I'll put the old

This might have come up in some previous issue, and if so, my apologies
for bringing it up again, but what if the MN's old HA is actually
rebooting at the same time as the MN returns home?

If the HA is performing DAD for its address at the same time as it hears
the probe from the MN, it has more or less been DoS:ed.

The possibility for this is very remote, but it might never the less happen.

Ville
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: [email-masked], phone: +358 (0)9 451 5257

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Jan 2003 17:30:22 +0200

> The possibility for this is very remote, but it might never the less happen.

Good point. I don't see anything that prevents this from happening.
The mobile node can't use its own address yet, because the HA
is defending it. And if it sends using the unspecified address,
the rebooting HA might think its another node with the same
address.

Possible solutions:

1) Hope that it doesn't happen ;-(
2) Go back to not allowing this special case, and
    hope that your own HA responds soon enough when
    you return home ;-(
3) Add the SLLA back as an allowed option in MPA.
    Make it mandatory, and require the mobile node
    to store it.
4) As above, but carry the SLLA in a BA.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Jan 2003 19:20:34 +0200

> 4) As above, but carry the SLLA in a BA.

I'm leaning on #4 as the solution. We would need a
new mobility option for this, but this way it would
not be required to run prefix discovery just to get
the home agent's link-layer address, the address would
be more reliably in sync with bindings, etc.

What do people think?

If we go for this, the following changes are needed:
- Add a new mobility option, Home Agent Link-Layer Address
- Add new text to home agent BA production, saying this
   option should always be included (in virtual home nets
   it is not needed)
- Add new text to mobile node data section that the mobile
   node must remember this for the home registrations
- Remove the current special case text for NS with unspecified
   address
- Add text explaining where the MN can get the address.

Jari

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 20 Jan 2003 18:38:57 +0100

> - Add text explaining where the MN can get the address.

Sounds good.

-gabriel

---

From: Ville Nuorvala <[email-masked]>
Date: Mon, 20 Jan 2003 19:41:17 +0200 (EET)

>     hope that your own HA responds soon enough when

It might perhaps help a bit if the MN sends a RS with unspecified
source address when it's returning home in case it doesn't have a valid
neighbor cache entry for its HA.

This possibility came up in an internal discussion before we noticed the
misuse of DAD had (temporarily) been removed from the pre 20 draft.

> 4) As above, but carry the SLLA in a BA.

And the MN adds the neighbor cache entry for its HA when it hears
its homeprefixes advertised, right?

Of these solutions I like #4 best. I did come up with an alternative
solution for the problem myself, but it requires we expand Neighbor
Discovery a bit.

Don't know if people are willing to do this, but here's my idea anyhow:

5) NS ICMP Code != 0 <TBD> => message is not a true DAD message:

   1) MN multicasts DAD solicitation with Code = <TBD>.
   2) HA silently discards message if it's doing DAD, otherwise replies
      as in the normal Code = 0 case.

   This shouldn't break anything, since nodes not supporting this MUST
   silently discard the packet AFAICS (RFC 2461 Section 7.1.1).

Ville

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 20 Jan 2003 10:06:54 -0800

> be more reliably in sync with bindings, etc.

the MN storing the link layer address of the HA is a
really bad idea, IMO. so what happens if I change the 
interface card on the HA? what happens if I decide
to move the home link to a different interface on
the HA?

I think we should go back to the earlier DAD probe 
(even though it looks like a hack).

>    option should always be included (in virtual home nets

this is a huge overhead on each binding ack. maybe the
MN comes home very rarely. it doesnt make sense including
it in every binding ack.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 20 Jan 2003 10:09:17 -0800

>    silently discard the packet AFAICS (RFC 2461 Section 7.1.1).

actually this doesnt look too bad. :-) we could do this. we just
need to define a new ICMP code for neighbor solicitation. is
that a big deal?

Vijay

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 20 Jan 2003 19:08:15 +0100

> its homeprefixes advertised, right?

Some more food for thought: Even though nodes shouldn't change
link-layer addresses, this is a SHOULD NOT instead of a MUST NOT.
So what happens if after this binding ack is sent,
the HA changes link-layer address?

>    silently discard the packet AFAICS (RFC 2461 Section 7.1.1).

Not unlike MIPv4 mobility agent discovery... This would allow the MN
to discover fresh link-layer info.

-gabriel

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Jan 2003 22:32:35 +0200

> need to define a new ICMP code for neighbor solicitation. is

I like #5 too. It certainly is architecturally better than relying
on stable link layer addresses.

By the way, I'm trying to ship draft 20 today. If I could get some
additional folks verifying that this solution is the way to go, I
could put in the solution. Otherwise I'm not quite sure what to do,
I wouldn't like to ship anything with a known bug that could disable
a home agent.

Jari

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 20 Jan 2003 21:59:22 +0100

> on stable link layer addresses.

Excellent, sounds like consensus. This is also cleaner from the
point of view that now this hack of the MN's probing for the
HA address is cleanly distinguished from real probes.

> I wouldn't like to ship anything with a known bug that could disable

Cool, ship it! We'll deal with further issues that may arise during
last call.

-gabriel

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Jan 2003 23:11:00 +0200

Here's some text for solution #5.

Section 11.5.4:

    ...
    solicitation.  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 ICMP Code field MUST be
    set to 1 in order to distinguish this solicitation from a similar
    packet that would only be used for DAD, as described in Section 7.x.
    The home agent will send a multicast Neighbor Advertisement back
    to the mobile node with the Solicited flag (S) set to zero. In any
    case, the mobile node SHOULD record the information from the Source
    Link-Layer Address option or from the advertisement, and set the
    state of the Neighbor Cache entry for the home agent to REACHABLE.

Section 7.x, Modified Neighbor Solicitation Message Format

    Mobile nodes may need to send Neighbor Solicitations to
    their home agent when the home agent still has a binding
    for them. As the home agent defends the mobile node's
    addresses on the home link, the mobile node can
    not use its own addresses until it it successfully
    deletes the binding. However, in order to do this
    it must send a Binding Update to the home
    agent, and possibly find its link-layer address.

    The modified Neighbor Solicitation message allows this to
    be done with the IP Source Address set to the unspecified
    address and the ICMP Code field set to 1. The modified
    format MUST NOT be used except for the purpose of
    discovering the link-layer address of a home agent
    when the mobile node is returning home (Section 11.5.4).

          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |     Type      |     Code      |          Checksum             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                           Reserved                            |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +                                                               +
         |                                                               |
         +                       Target Address                          +
         |                                                               |
         +                                                               +
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   Options ...
         +-+-+-+-+-+-+-+-+-+-+-+-

    This format represents the following changes over that originally
    specified for Neighbor Discovery [12]:

    IP Fields:

       Source Address

                      The unspecified address.

    ICMP Fields:

       Code

                      1

    Upon receiving a Neighbor Solicitation message from the unspecified
    address with the Code field set to 1, home agents MUST process this
    message as described in Section 7.2.3 of RFC 2461 [ref]. Such messages
    MUST NOT be considered as a sign that the sending node is performing
    Duplicate Address Detection [ref].

Section 8.4:

    o Every home agent MUST support the extended Neighbor Solicitation
      message format described in Section 7.x.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Jan 2003 12:04:39 +0100

What do people think?
   
=> I don't understand where is the issue. And I am strongly against
3, 4 and 5.

[email-masked]

PS: I believed the HA LLA discovery issue was solved by making the SLLA
mandatory is HA RAs?

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Jan 2003 12:07:51 +0100

=> this is the scope of the IPv6 WG, not the mobile-ip WG.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Jan 2003 12:10:26 +0100

=> I agree.

=> I agree. I was never against it, I only had a concern
about to mandate it (i.e., a MAY is strong enough).

   
=> I agree. We should not try to rebuild the world for this evening...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Jan 2003 12:11:33 +0100

=> RFC 2461 has not to be revised by the mobile-ip WG <dot>

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Jan 2003 12:15:43 +0100

> on stable link layer addresses.
   
   Excellent, sounds like consensus.

=> is it a joke?

=> if it is shipped we'll have to answer to a recharter query of this WG...

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Jan 2003 12:21:47 +0100

=> please don't assume consensus for #5. Don't try to fight against
the IPv6 WG (the trouble with the IPsec WG should have been enough).

   Section 11.5.4:
   
       ...

=> this MUST is a problem. I am in favor of a MAY with a warning.

---

From: Ville Nuorvala <[email-masked]>
Date: Tue, 21 Jan 2003 17:19:30 +0200 (EET)

Hi Francis!

The issue is that the MN might need to do ND to get the LLA of its
HA if there are multiple advertising HA:s on the home link, as Pascal
pointed out, but the (mis)use of DAD probes beyond their scope leads to
complications. (MN returning home unwittingly DoS:ing rebooting HA)

This was the problem we were trying to solve.

As to the mobile-ip/IPv6 WG issue relating to my proposition, you are
probably right. As a relative newcomer to the IETF forums, I wasn't aware
of all the bureaucracy and red-tape involved in the decision making
process. Is the interaction (not to mention cooperation) between the
different IETF WG:s really as problematic as you would imply?

As to my actual solution, it doesn't break anything, as normal RFC 2461
compliant nodes (all nodes except HA:s) just silently discard the packet,
while the old hack actually broke the DAD protocol. The only problem with
my solution is that one ICMP code (out of AFAIK 255 free ones) needs to be
allocated for this purpose. Which one is worse?

If the IPv6 WG was about to permit a hack that breaks DAD, I honestly
don't understand why it wouldn't permit a solution that doesn't.

Regards,
Ville

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Jan 2003 17:45:39 +0100

=> this is a very marginal issue :
 -1- the MN fails to get the HA LLA in time
 -2- the MN uses the DAD for the HA address as a last chance to solve 1
 -3- the HA was rebooting and misinterprets the DAD.
For -1- we mandates the HA RA includes SLLA (which is optional), so
in fact -1- is the MN fails to get the HA RA. Note this RA can be
triggered by a RS, including a RS to the HA solicited multicast address
(it cannot be multicasted (because the HA LLA is not known) but the
destination address of a RS is "typically" the all-routers, i.e.,
there is some freedom).
For -2- IMHO it should be only a last chance solution so a MAY is enough.
Of course with a MUST someone can believe we have to invent a very complex
stuff for a case that should not happen...

   probably right.

=> past delirium in the mobile-ip WG about DAD made an IAB member
announce this clear menace to recharter the mobile-ip WG.
And there is the whole upsetting history with the ipsec WG and the IESG.

   As a relative newcomer to the IETF forums, I wasn't aware
   of all the bureaucracy and red-tape involved in the decision making
   process. Is the interaction (not to mention cooperation) between the
   different IETF WG:s really as problematic as you would imply?
   
=> yes, it is problematic to do random changes in a draft standard
from another WG. This is the best way to get at least hard concerns
from the IESG.

   As to my actual solution, it doesn't break anything, as normal RFC 2461
   compliant nodes (all nodes except HA:s) just silently discard the packet,
   while the old hack actually broke the DAD protocol.

=> so we should find a way to avoid the need of the old hack, not to
replace it by another hack.

   The only problem with my solution is that one ICMP code (out of
   AFAIK 255 free ones) needs to be allocated for this purpose.

=> to create new ICMPs to solve any problem is never a good solution.

=> it doesn't break DAD, it is just a misuse of DAD so with a warning
implementors can for instance interpret DAD failure for HA in a soft way.

My main concern is the rush at the last minute to a new solution to
a very old problem...

Regards