Subject: [mobile-ip] Mobile IPv6 draft revision

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 20 Aug 2001 13:38:56 -0700

Hello folks,

Following the recent discussion, I believe a new revision to the
existing Mobile IPv6 draft ...-14 is needed.  The new draft would
have the following features:

- Removal of all text related to Mobile Routers, including the
  'R' bit of the Binding Update

- Reorganizing the Binding Update format so that:
  = authentication data is able to be included as a suboption
  = Specify that the Binding Update needs a new header number
  = Specify that the Binding Update must follow AH whenever
    AH is present.
  This will allow use of AH in the future, but allow the use
  of other authentication algorithms which can be specified
  directly to depend on specialized key exchange protocols
  as has been discussed recently.

- other minor fixes that have been reported.

I believe these fixes conform to recent consensus, do not
represent a significant upheaval to existing implementations,
and may help to make future discussion more productive.

Comments?

Regards,
Charlie P.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 20 Aug 2001 15:45:23 -0400

Hi Charlie,
  What about security?
I suggest waiting a bit until this is resolved and then issue a
super-duper final version to go for other steps
rather than keep increasing the version numbers 13, 14, 15, etc.

> and may help to make future discussion more productive.

Kind regards,

--
Behcet

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Aug 2001 12:00:25 +0200

> and may help to make future discussion more productive.

How about a consistency requirement for HA to join all-routers mc
address, in some cases?  The cases where it is required to send RA's.

Thanks,

Alex

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 Aug 2001 14:51:04 +0200

I've discussed about this with Charlie but we need mailing list approval.

My concern is about section 10.20 (returning Home).
Context is:

   When sending this Binding Update to its home agent, the mobile
   node must be careful in how it uses Neighbor Solicitation [17] (if
   needed) to learn the home agent's link-layer address, since the home
   agent will be currently configured to defend the mobile node's home
   address for Duplicate Address Detection.  In particular, a Neighbor
   Solicitation from the mobile node using its home address as the
   Source Address would be detected by the home agent as a duplicate
   address.  In many cases, Neighbor Solicitation by the mobile node
   for the home agent's address will not be necessary, since the mobile
   node may have already learned the home agent's link-layer address,
   for example from a Source Link-Layer Address option in the Router
   Advertisement from which it learned that its home address was on-link
   and that the mobile node had thus returned home.

The real issue is not "the Source Address would be detected by the
home agent as a duplicate address", it is simpler: the home
deregistration is not yet done so packets to the home address are
tunneled via the previous care-of address. But the result is the
same: NSs from the home address don't work.
Another detail to fix: the RA "from which it learned ..." is from
a router, not in all cases from the HA itself (Murphy's law applies:
if there is more than one router (the HA), the first RA will never
be from the HA, near 100% hit in my experiments :-).

The current proposal is:

   <context> 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 unicast 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).  Since the solicitation is unicast, the home
   agent will be able to distinguish from a similar packet that would
   only be used 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.

The text is not very clear but the NS is for the HA own address.
The problem is that this simply cannot work because in order to unicast
the NS to the HA, the HA link-layer address must be already known...

The current proposal is a (wrong) fix of the old proposal (ID 12):

   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 set the Source Address of this Neighbor Solicitation
   to the unspecified address.

This works but is a DAD probe for the HA own address so a better
solution was sought...

My proposal to fix the problem is:
 - first to roll back to the previous version
 - second to weaken the MUST to a MAY (not a SHOULD in order to keep
   a place for the last item)
 - third to list all the cases where there is an immediate solution
   (immediate: without changing a word in other IPv6 standards)
 - four to seek for another better solution

Third: cases where ID 12 solution is not needed (in order):
 - RA from the HA with a source link-layer option
 - if the link-local address MN is not registered, just use it
   as source to multicast a NS for the HA address
 - if a MN address is not registered, idem

Four: hints for a better solution:
 - make a source address available to MNs
 - RAs from the HA may not include a source link-layer option,
   make the inclusion of source link-layer option mandatory for HAs
 - HAs may not send RAs on reception of RS, make answer mandatory for HAs
 - HAs must delay answer (RFC 2461 6.2.6), remove this delay when
   the RS comes from a MN (of course the issue is to recognize this case).

So my last idea about a solution is:
 - when the MN detect a possible link change to the home link
   (from the link-layer or by the reception of a RA with a home prefix)
   the MN MUST multicast some RS without its source link-layer option
   (change to the SHOULD in RFC 2461 4.2) from its home address to
   all routers
 - an ordinary router just applies RFC 2461 6.2.6
 - a HA which doesn't serve the MN (i.e. hasn't a home registration
   for the MN home address) applies RFC 2461 6.2.6 with a little
   improvement: it SHOULD multicast (to all nodes) the RA
   (note: RFC 2461 gives the choice between unicast or multicast
   solicited RAs)
 - a HA which serves the MN (i.e. has a home registration for the
   MN home address) MUST multicast to all nodes the RA without delay
   with a source link-layer option if the link has addresses.

This makes the default mechanism (good RAs from the HA) to work in
all cases with an exception: the MN must be a host because a router
must not send RSs... So I am in favor to keep the old solution with
a MAY.

Regards

[email-masked]

PS: if multicasts to all routers/all nodes are too expensive,
solicited-node addresses do the job (the MN home address and
the HA own address are known) and doesn't need a deep change
into current router implementations (no check of the multicast
destination of RS/RA, BTW RFC 2461 6.1.1 & 6.1.2 has not such
a check in RS/RA validation rules).

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 22 Aug 2001 12:06:26 -0700

hi Francis,

some comments....

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

since the dst address on the NA is all nodes multicast 
address this packet skips any binding cache entry that
exists for the MN.

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

after that the MN sends a BU for deregistration.

wont this work? 

vijay