Subject: [mobile-ip] Issue #23 and Issue #30

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 17 May 2002 16:11:21 -0700

hi,

I think the 'S' bit is being confused with a lot of other things.
anyway, here is an attempt to clarify things.

1. it is straight-forward for the HA to derive the MN's link local
   address from the MN's unicast address. please remove this from 
   the issues.

2. the HA MUST always defend the link local address of MN in addition
   to the home address (irrespective of what the 'S' bit is set to).

   this is because of RFC 2462. lets assume the HA is defending the 
   global address of the MN. and it does not defend the link local
   address. another node on the link could configure the MN's home 
   address. consider the following sequence of events
     -  node A configures MN's home address
     -  node A configures a link local address whose interface id
        is the same as the home address
     -  node A does DAD on the link local address alone (it does not
        have to do for the global address)
     -  the HA does not defend the link local address
     -  you have a problem.

   the MN can return home and do a successful degeristration without
   using its link local address. the argument that the link local 
   address is needed for deregistration when the MN returns home is
   not a valid one (sorry, Francis).

3. the philosophy behing the 'S' bit.

   imagine, the MN is at home. it configures a link local address.
   it also configures unicast addresses for each and every network
   prefix advertised on the home link. it also defends all these
   address, preventing anybody else from claiming these addresses.

   when the MN is away from home, the 'S' bit simulates the above.
   the HA defends not only the home address, but also the link
   local address and every address from every network prefix on the
   home link. when the MN returs home, it can claim all these 
   addresses back.

   the problem is, the HA has to figure out all these addresses from
   the home address in the BU from the MN. its easy deriving the link 
   local address. but for the other addresses, the HA has to make an 
   assumption (this is what Francis and Brian are against) that the 
   same interface id that was used for the home address is used for 
   the other addresses too. IMO, it is safe to make this assumption.
   this is because the MN is in a position to know if it uses different
   interface id for each address. accordingly it can set the 'S' bit.

   setting the 'S' bit to 1 turns off this functionality. the HA only
   defends the home address.

finally issue #23 and #30 can be recast what Francis and Brian are 
against (having to assume the same interface id for every unicast 
address).

and finally agree with the following text from Francis Dupont

> IMHO 11.6.7 should be more accurate, I propose to add to:
>
>   agent's use of the same address.  If the mobile node returns home
>   after the bindings for all of its care-of addresses have expired,
>   then it SHOULD perform DAD.
>
> near the end of page 138
>
>   <including for addresses which can have been registered with D and S
>    bits set to one>.

hope I havent missed anything.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Sat, 18 May 2002 15:47:19 +0200

=> I strongly object because this requirement will give major problems
when the mobile returns at home (the mobile forms the link-local address,
performs DAD (both steps are mandatory) and DAD fails: the MN should
deregister before or wait until the registration has expired).

      this is because of RFC 2462...

=> please sends this issue to the IPv6 WG.

      the MN can return home and do a successful deregeristration without
      using its link local address.

=> I won't argue about the second part of your statement but the first
one is wrong and DAD for the link-local address is mandatory (if it was
optional why to defend it :-).

   

=> I am against this assumption made "a priori". Even when this
assumption is developed (as here) I don't believe it is a good idea
because it is complex and misleading.

   
   
=> for simplicity IMHO the S bit should be removed (reserve its position
(set to 1) and put it into the for further study class) and the DAD issue
solved by making the "DAD optimization" illegal on the home link, i.e.:
 - any node attached to the home link MUST perform the DAD procedure
   (RFC 2462 5.4) for each address
 - the optional DAD procedure on the link-local address only is explicitely
   forbidden (because some addresses are not formed in an autoconf like way)
 - home agents receiving home registrations with the D bit set to 1 MUST
   perform the DAD procedure on the home address
   (if we keep the S-bit this becomes on all addresses derived from the
    home address, including the link-local one)
For answers to NSs, the proxy-NA logic is enough: no change is needed.

   >   <including for addresses which can have been registered with D and S
   
=> note that in my last proposal this will be the case...

Thanks

[email-masked]

---

From: Vladislav Yasevich <[email-masked]>
Date: Mon, 20 May 2002 11:07:36 -0400

Hi Vijay

>    address from the MN's unicast address. please remove this from 

Ok, I'll grant you that, given that the HA knows all the prefixes and
their lengths...

>    to the home address (irrespective of what the 'S' bit is set to).

I disagree.  Consider the use of privacy exensions that mobile nodes
might want to use.  There is no link-local address associated with such
addresses.

>         is the same as the home address

you have the above 2 steps reversed...

>      -  the HA does not defend the link local address

I agree with Francis.  This optimization is a bad idea on the home link.

>    defends the home address.

Ahh, but according to the statement you made above, the HA has to defent
the link-local as well.  What whould happend for more then one binding
with S=1?

Q:  Do we need a "Defend Link-local" bit?  Set the bit on the binding
     for a home address from which to derive the link-local.

Just a thought.

-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: Mon, 20 May 2002 15:27:08 -0700

Francis Dupont wrote:
> 
>  In your previous mail you wrote:
> 

I thought that was obvious. the MN MUST deregister before using either 
the link local address or the home address after coming home. what is 
the use in having the link local address available to the MN, if it 
cant use the home address? it cant use the home address because the HA 
is defending it. so the first thing the MN has to do after coming to 
the home link is to deregister. after it deregisters, both the link 
local address and the home address are available to the MN.

> => please sends this issue to the IPv6 WG.

and?? wait for RFC 2462 bis?

> because it is complex and misleading.

I agree that this assumption is not the right one. but look at it this
way. the MN is in the best position to know if it uses different 
interface id for each address. accordingly it can set the 'S' bit.

>    (RFC 2462 5.4) for each address

doesnt this mean RFC 2462 bis?? this is going to take time. and also
all links are potentially home links. a MIPv6 HA can be put on any
IPv6 link. the change you are suggesting is for every host, not just
hosts on the home link.

regards
Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 20 May 2002 15:39:29 -0700

> might want to use.  There is no link-local address associated with such

use of privacy extensions for the home address? I thought privacy 
extensions would be used for the CoA. you want to hide your current
location, not the reachable address, right? the MN wont be reachable 
if it keeps changing its HoA often.

> you have the above 2 steps reversed...

you are right.... sorry for the slip.

> I agree with Francis.  This optimization is a bad idea on the home link.

what is a home link? how is it different from any IPv6 link? you
are suggesting modifications to RFC 2462??

> the link-local as well.  What whould happend for more then one binding

arghh, another slip. my opinion was that the HA MUST defend both
home address and link irrespective of the 'S' bit.

>      for a home address from which to derive the link-local.

we could, if needed. thats fine with me.

regards
Vijay

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 May 2002 11:24:05 +0200

I thought that was obvious. the MN MUST deregister before using either 
   the link local address or the home address after coming home.

=> which source address the MN should use to send the deregistration
message?

   what is the use in having the link local address available to the MN, if it 
   cant use the home address?

=> this use is the source address of the deregistration message.

   it cant use the home address because the HA 
   is defending it. so the first thing the MN has to do after coming to 
   the home link is to deregister.

=> on this point (only :-) we agree.

   after it deregisters, both the link 
   local address and the home address are available to the MN.
   
=> an address should be available before.

   
=> just read the charters of mobile-ip and ipv6 WGs: DAD is *not* in
the charter of mobile-ip!

   
   >    (RFC 2462 5.4) for each address
   
   doesnt this mean RFC 2462 bis??

=> 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.

   this is going to take time. and also all links are potentially home links.

=> 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).

   a MIPv6 HA can be put on any
   IPv6 link. the change you are suggesting is for every host, not just
   hosts on the home link.
   
=> 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
opens the door to troubles so *must* be disabled (or, according to RFC 2462
spirit, *must* *not* be enabled).

Regards

PS: from RFC 2462 (end of page 9, section 4 Protocol overview):

   For safety, all addresses must be tested for uniqueness prior to
   their assignment to an interface.  In the case of addresses created
   through stateless autoconfig, however, the uniqueness of an address
   is determined primarily by the portion of the address formed from an
   interface identifier.  Thus, if a node has already verified the
   uniqueness of a link-local address, additional addresses created from
   the same interface identifier need not be tested individually. In
   contrast, all addresses obtained manually or via stateful address
   autoconfiguration should be tested for uniqueness individually. To
   accommodate sites that believe the overhead of performing Duplicate
   Address Detection outweighs its benefits, the use of Duplicate
   Address Detection can be disabled through the administrative setting
   of a per-interface configuration flag.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 May 2002 17:00:10 +0200 (CEST)

> if it keeps changing its HoA often.

Using RFC 3041 temporary addresses for the CoA doesn't really hide the
location - you could still easily see which ISP the CoA is delegated to.

I could imagine MNs that want to use RFC 3041 home addresses for communication
they originate where the MN wants more anonymity, while the MN retains
a stable home address at which it can be contacted.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 May 2002 18:38:47 +0200

=> I agree but the idea is to change the interface ID (using for instance
the RFC 3041) at the same time to move to another link breaks the
continuity of care-of addresses and provides a kind of privacy.

=> this is a transparent (to mobility) use of RFC 3041.

Regards

PS: this discussion should be on the ipv6 WG list (with comments about
my I-D "RFC 3041 Considered Harmful" (draft-dupont-ipv6-rfc3041harmful-00.txt).

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 21 May 2002 17:29:42 -0700

hi Francis,

> => which source address the MN should use to send the deregistration

the global unicast home address. the deregistration BU is unicast to
the HA. this works. 

> I simply propose(d) to keep the mechanism as it is and to forbid the

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.

> 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.

> 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?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 21 May 2002 17:31:04 -0700

> a stable home address at which it can be contacted.

okay. I guess thats possible.... I hadnt considered this.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Wed, 22 May 2002 10:48:18 +0200

> => which source address the MN should use to send the deregistration
   
   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.

   
=> but this doesn't work...

   
=> could => must not

   
=> 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

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: Brian Haley <[email-masked]>
Date: Thu, 23 May 2002 15:59:37 -0400

> (set to 1) and put it into the for further study class)

I would agree with the removal of the S bit, preferring instead to define this
multiple address behavior in another draft.  I don't see any reason to keep it
and have it only defined as 1 for now though.

-Brian

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 May 2002 13:35:41 -0700

Hello,

It seems to me that the behavior is already simple enough,
and it makes a big difference if the mobile node has several
home addresses.  Taking it away burdens the already burdened
handover time.  The consequence would be a very strong
discouragement for any mobile node to use the IPv6 feature
of having multiple prefixes for the same link (in this
case, that means the home link).

Furthermore, I think the home agent should _always_ defend
the link-local address of the mobile node (regardless of the
setting of the 'S' bit, or its existence) while the mobile
node has a registered care-of address.  Anything else leads
to cramps.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 May 2002 14:33:09 -0700

Hello Francis,

I have to type and run, so I may not be able to participate
much before next week.  But...

>  - it builds its link-local address and performs DAD for it

Here is where I think your procedure is broken.

If the home agent has been defending the mobile node's link-local
address, then it would typically do so until the care-of address
expires.

(*) Thus, the mobile node DOES NOT have to do DAD.  It can use
    the link-local address it has been "using" all along.

>    * if it doesn't perform DAD (it was the case when I try 4 years ago),

This isn't necessarily so.  If a renumbering event has happened,
then the mobile node should have been notified by way of the
Binding Request mechanism.  If no event, no problem!

>    * the HA address at the target

This can be fixed by either
(a) keeping the home agent's information in the Neighbor Cache
(b) using the anycast address
(c) special-case code

>    in my case it sends a NbAdv to the previous care-of address of the MN

We can specify that the home agent doesn't do wrong things with such
packets.  In fact, I reckon we should do so.  Any home agent problem
should be fixed in a Mobile IPv6 draft somewhere along the line...

> until someone has the bad idea to use S=0 or a previous equivalent.

I think it can and should be made to work.

If I don't answer until next week, please forgive...

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 24 May 2002 11:49:16 +0200

home addresses.

=> we have first to understand why the MN has several home addresses:
for instance, if the MN has several home addresses because multi-homing
then the MN should use different HAs too: multiple paths are better
when they don't go through a single point of failure.

   Taking it away burdens the already burdened handover time.

=> IMHO we should get the mobility stuff ready and only after try
to optimize/accelerate it. And the S bit is cleary today an
overoptimization.

   The consequence would be a very strong
   discouragement for any mobile node to use the IPv6 feature
   of having multiple prefixes for the same link (in this
   case, that means the home link).
   
=> why? the MN can register their home addresses in parallel:
 - this takes near the same time
 - this makes multiple paths available at the same price.

   Furthermore, I think the home agent should _always_ defend
   the link-local address of the mobile node (regardless of the
   setting of the 'S' bit, or its existence) while the mobile
   node has a registered care-of address.

=> I STRONGLY object because this leads to cramps when the MN comes back
on the link.

   Anything else leads to cramps.
   
=> I disagree: it is too late to change DAD in DIIDD (Duplicate Interface
ID Detection) and this kind of actions is *not* in the mobile-ip charter.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 24 May 2002 12:24:36 +0200

=> my procedure is the strict application of RFC 2462 (5.3 & 5.4).

=> this is why I have a problem (:-).

=> this is in full contradiction with RFC 2462!

   
=> perhaps you have missed my point: I claim the MN must deregister
before performing DAD and if DAD is successful using the home address.

=> how? the only way to get a neighbor cache entry in the reachable state
is to receive a neighbor advertisement from the HA, so the MN should
send a neighbor solicitation... The question is: with which source address?

=> don't joke: you can not do something useful with the anycast address.

   (c) special-case code
   
=> special-case code should be recommended only when the standard
procedure is not available. BTW there is one: perform DAD for the HA
address: the HA will defend its address and by a side effect provide
its link-layer address... But:
 - I don't want this procedure becomes the default
 - in last drafts this procedure was incorrectly "fixed" to use
   unicast probes.

   packets.

=> this is hard without opening a security hole.

   In fact, I reckon we should do so.  Any home agent problem
   should be fixed in a Mobile IPv6 draft somewhere along the line...
   
=> I prefer to avoid problems than to fix them.

   
=> is to defend only registered addresses too simple?

Regards

PS: my code was before the security introduction so I got only the ND joke.
If the MN returning at home has to re-establish a SA pair it has to get
a working source address to speak with the HA and the link-layer address
is a good candidate (IMHO this situation should be avoided by using longer
lifetimes for SAs than for bindings but there are many other reasons to
make an address locally usable for the MN as soon as it is attached).
PPS: about scoped address and IKE: IMHO it is safe if the addresses in
IKE ID (and soon TS :-) payloads are in a larger zone, i.e., a forbidden
case is to run IKE with global addresses to setup SAs with link-local
address selectors.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 24 May 2002 16:38:23 +0200 (CEST)

> until someone has the bad idea to use S=0 or a previous equivalent.

But, based on RFC 2373 saying that interface IDs are unique on the link,
one could argue that S=0 is the architecturally correct setting.
Thus assuming that <prefix>:<IID> can be claimed and used by the HA
while fe80:<IID> is claimed and used by the MN at home seems to violate
that architectural statement in RFC 2373.

BTW: Section 6.1.7 points to section 10.2 for a description of how the
(S) bit is used, but 10.2 doesn't appear to contain such text.

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Fri, 24 May 2002 18:00:27 +0200

=> but can you argue that for a mobile node which is not attached to
the home link? RFC 2373 (last draft has the same text) says:
 - IIDs in unicasts are used to identify interfaces on a link.
 - They are required to be unique on that link.
Is it equivalent to "IIDs in unicast are used to identify in an unique
way interfaces on a link"?

=> <prefix>:<IID> doesn't identify the interface of the HA.
The HA service is a proxy service so the rule to apply is the same
than for anycasts.

=> a simple question: is it forbidden for two routers to provide
a neighbor discovery proxy service for the same address? Of course
not so I believe your concern is not about the use but the claim,
i.e., about DAD. But as DAD is not DIIDD I can't see a real objection
to allow a proxy server to perform a DAD on an address it serves.

Regards

PS: IMHO a DIIDD should have been better than current DAD (more
architecturally correct for instance :-) but it is far too late
to fix that.

---

From: Vladislav Yasevich <[email-masked]>
Date: Fri, 24 May 2002 15:13:06 -0400

There seems to be a contension of whether the HA has
to proxy for the link-local address.  The interesting
thing is, that I believe there is a problem in both
arguments.

If the link-local address is not defended by the HA,
any other node on the link may be able to configure that
link-local address and using the DAD optimization in 2462,
can even configure global addresses.  This is bad.
The solution seems to be to prohibit the DAD optimization, but
that doesn't fully help as the link-local address was allowed.
So this still doesn't look right.

On the oter hand, if the link-local address is defended by the HA,
the other nodes will not be able to configure the link-local or global
addresses.  So everything seems OK, but there are problems with
this scenario as well.  The problems are in the same category of
the mobile returning home.

If the mobile is active when it returns home, it knows that it's
home when it recieves the RA contining the home prefix.  At this
time the mobile can unregister, but it needs the link-address of
the HA.  It can get that if the RAs contain the link-address option.
The RA will cause a creating of a STALE neighbor cache entry on
the MN, that the mobile can use.  Since the entry is STALE, the
unregistration packet will be sent and the entry will be transitioned
to DELAY state.  On the BAck, since the binding no-longer exists, normal
ND will work correctly.

If the mobile is inactive when it returns home (and the binding was
not deleted for whatever reason) the problem is bigger.
The MN will try to configure the link-local address as part of
standard IPv6 initialization (it has no idea it's home yet because it
doesn't have an interface up yet, so it hasn't seen an RA to tell it
that it's home), but will fail because the HA will defend the link-local 
address.

A possible workaround (a big hack :) to this is once DAD fails, the MN
can try to un-register with the HA using the following procedure:
	1. Send a RS to all-routers multicast from the :: address.
	2. Wait for the RA with the H bit set.
	   * for this to work the RA must contain the "Link Address" option.
	     this will create a stale cache entry on MN
	3. Send the unregistration using the :: address with the HOA listing
	   the last known home address (that the mobile usually stores).
	4. Imidiately start the DAD procedure again.

As I said, this is a big hack.  I don't know what the security implications
are and if IPSec can be used to verify this, so I leave that to someone who
knows more about IPSec and security.

Just my thoughts on the issue.
-vlad

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 24 May 2002 13:32:54 -0700

hi Vlad,

> So this still doesn't look right.

great, that you agree the link local address needs to be defended.

> not deleted for whatever reason) the problem is bigger.

it might help if we can know why the binding still exists. the only
reason I can think of is, the binding lifetime was more than the 
period during which the MN was inactive. this might be an extreme
case (?).

Vijay

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 25 May 2002 10:07:23 -0700

Hello Vlad,

I think the home agent MUST proxy for the mobile node's
link address while the mobile node has a valid binding.
I think the home agent should stop defending the link-local
address when the binding expires.  I also think the home agent
should accept packets with source address == mobile's
home address as long as they are addressed to the home agent.
Why not?

> that it's home), but will fail because the HA will defend the link-local

I don't think the HA should do this.

>            the last known home address (that the mobile usually stores).

In this situation, the mobile node SHOULD know its home address.
Otherwise, how could it tell if it is at home?  It has to know something.
And then it could send the Binding Update to the home agent
directly (with lifetime zero).

> knows more about IPSec and security.

Maybe we could make a special case for when the home agent
receives a Router Solitication (on link!) with the source address
== the mobile node's home address.

But the mobile node SHOULD NOT forget the home agent's
layer-2 address (assuming it needs it for framing).

The security issues are the same as the security issues for Neighbor
Discovery in general.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 25 May 2002 19:25:54 +0200

the MN, that the mobile can use.

=> you've made three implicit assumptions:
 - there is a link-layer address extension in the RA (a router MAY omit it)
 - the RA is sent by the HA (again the one router per link... :-)
 - and the HA address is in a prefix information with the R bit.
If one of these assumptions is false, you are in trouble.

   Since the entry is STALE, the unregistration packet will be sent

=> no because the unregistration packet is not sent to the link-local
address of the HA (another assumption: the MN creates neighbor cache
entries for global addresses at the reception of a RA).

   and the entry will be transitioned to DELAY state.  On the BAck,
   since the binding no-longer exists, normal ND will work correctly.
   
   ...

=> possible workarounds (without modification to neighbor discovery)
were discussed some years ago:
 - one is to perform DAD for the HA address (look at an old I-D).
   It works but is not very HA friendly (:-).
 - one is to use a RFC 3041 IID. It works but the MN MUST perform
   a DAD to check its temporary IID so this solution introduces
   a mandatory delay (I used it as an argument for a MAY for the
   previous solution).

=> the MN should do that when it is attached to a new link.

=> please add "from the HA"!

=> you MUST NOT do that (unspecified source address is forbidden in
this case: this constraint gave the two old working proposals).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sun, 26 May 2002 14:33:56 +0200

=> as I said this position is an artificial conversion of DAD in DIIDD
and should be discussed in the IPv6 WG for its pros and cons, not
in the mobile-ip WG.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 27 May 2002 10:15:05 +0200 (CEST)

> way interfaces on a link"?

A logical conclusion of the statement that an interface ID
identifies interfaces *and* that they are unique on a link, means that
an interface ID can only be used by one interface at a time.

But an alternative way to look at this is that the use of "proxy ND" 
doesn't really *assign* the interface ID to the proxying node - instead 
it remains assigned to the mobile node's interface.
If you follow that path then it seems like a node could proxy for some
addresses but not other addresses using the same interface ID.

However, due to the MAY for DAD in certain cases in RFC 2462 it seems 
inconsistent when the HA doesn't respond to DAD queries for the link-local
address while it responds to DAD queries for other address(es) derived from
the same interface ID.

> architecturally correct for instance :-) but it is far too late

Agreed. I think the thing to do is to clarify RFC 2373 and RFC 2462 to
make it clear that it isn't DIIDD.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 27 May 2002 10:56:47 +0200 (CEST)

> to DELAY state.  On the BAck, since the binding no-longer exists, normal

I haven't though about all the implementation details, but if there
was a way for the ND packets to bypass the binding cache lookup,
it seems like this complexity of needing the HAs link-layer address can
be avoided.

The ND packets shouldn't go outside of a link (whether that link
is a "wire" or a tunnel), thus applying MIPv6 checks that might add
a routing header or a home address option sounds odd.

This might be as simple as the ND code passing SO_DONTROUTE to ipv6_output
causing a bypass of the BCEs.

Of course, this doesn't make the "returning home" problem completely go away.
But it allows the MN at home to send a NS and get an NA back from the HA
I think. (Unless the HA is confused by itself proxying for the HoA?)

   Erik

---

From: Brian Haley <[email-masked]>
Date: Tue, 28 May 2002 12:12:46 -0400

> home address as long as they are addressed to the home agent.

In this case the MN can't use it's home address because it can't configure
it since DAD failed (i.e. it just booted and doesn't know where it is).

> I don't think the HA should do this.

Can you please explain what you meant by this?  Above you said the HA MUST
proxy for the MN's home address, doesn't that assume defend as well?

> directly (with lifetime zero).

The MN doesn't know it's home until it hears an RA, but in order to hear
it it's got to configure it's link-local address first.  It would have to be in
promisc mode otherwise.

> layer-2 address (assuming it needs it for framing).

But the MN might not have the HA's L2 address if it's doing DHAAD, I don't
believe the spec says it should keep the HA address in NV storage?

-Brian

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Tue, 28 May 2002 10:45:18 -0700

To hear the RA (which is multicasted to a well known address), the
interface does not really need to have an IP address, does it ?

Also, why does the mobile need to remember the link-layer address of the
HA ? What happens when the HA NIC is changed?

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Brian Haley
Sent: Tuesday, May 28, 2002 9:13 AM
To: Charlie Perkins
Cc: Vladislav Yasevich; [email-masked]
Subject: Re: [mobile-ip] Issue #23 and Issue #30

> home address as long as they are addressed to the home agent.

In this case the MN can't use it's home address because it can't
configure
it since DAD failed (i.e. it just booted and doesn't know where it is).

> I don't think the HA should do this.

Can you please explain what you meant by this?  Above you said the HA
MUST
proxy for the MN's home address, doesn't that assume defend as well?

The MN doesn't know it's home until it hears an RA, but in order to hear
it it's got to configure it's link-local address first.  It would have
to be in
promisc mode otherwise.

> layer-2 address (assuming it needs it for framing).

But the MN might not have the HA's L2 address if it's doing DHAAD, I
don't
believe the spec says it should keep the HA address in NV storage?

-Brian

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 28 May 2002 11:16:46 -0700

Hello Brian,

My model may be different than yours.

My assumptions:
1) The mobile node owns its home address until the lifetime expires.
2) The home agent proxies for the mobile's home address while
   it has a valid binding.
3) The mobile node knows how long the home address is valid.
4) The mobile node does not have to reconfigure its home address
   if it's valid (its lifetime has not expired).
5) The home agent defends the mobile node's link-local address
   while the mobile node is away from home.

Under these circumstances, the mobile node does not have to do
DAD when it returns to the home network.  It just has to inform
the home agent that it has arrived back on its home network.

Before going into other cases, please let me know if this much
is agreeable to you.

Under these assumptions, I think the problems you suggest
do not appear:

> it since DAD failed (i.e. it just booted and doesn't know where it is).

The mobile node should be able to use its home address as long as
it knows it is valid.  If the mobile node does NOT know its home
address and tries to autoconfigure it, then the solution depends
on whether you agree with my aforementioned assumptions.

> proxy for the MN's home address, doesn't that assume defend as well?

Do you still have this question, given my above assumptions?

> it it's got to configure it's link-local address first.  It would have to be in

I do not know why a mobile node should be unable to hear any
packets just because it has not completed autoconfiguration.
It should still recognize multicast packets... why not?

> believe the spec says it should keep the HA address in NV storage?

Perhaps the specification should say this, but a specification does
not usually mandate storage requirements for a protocol implementation.

Regards,
Charlie P.

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Tue, 28 May 2002 11:31:43 -0700

Charles,  a simple question. Why do you want to defend the link-local
address ?  

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Charles E.
Perkins
Sent: Tuesday, May 28, 2002 11:17 AM
To: Brian Haley
Cc: Vladislav Yasevich; [email-masked]
Subject: Re: [mobile-ip] Issue #23 and Issue #30

Hello Brian,

My assumptions:

configure

MUST

to be in

don't

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 28 May 2002 11:39:23 -0700

Hello Dr. Goswami,

If the home agent defends the link-local address, then
presumably it simultaneously defends all global addresses
that would be formed by replacing the link-local prefix
by any of the advertised prefixes on the link.

In fact, the home agent is supposed to keep track of all
those prefixes anyway, even the ones that it is not the
default router for.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 28 May 2002 12:26:25 -0700

Hello again,

I should clarify: My expectation is that the home agent should
ONLY defend the mobile node's link-local address, not its other
addresses.  Then, by implication, the other addresses will be
unavailable to nodes on the link because they can't form the
link-local address to start with.

Regards,
Charlie P.

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Tue, 28 May 2002 12:35:13 -0700

Thanks Charlie for the answer.  Why is it necessary to defend all the
possible global addresses that can be formed from the post-fix of the
link-local address (this number can be very large ) ?    

Subrata 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Charles E.
Perkins
Sent: Tuesday, May 28, 2002 12:26 PM
To: Dr. Subrata Goswami
Cc: [email-masked]
Subject: Re: [mobile-ip] Issue #23 and Issue #30

Hello again,

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 28 May 2002 12:40:15 -0700

Hello Subrata,

> link-local address (this number can be very large ) ?

Well, to my understanding, it is not necessary!

Do you know a reason why it would be needed?

Regards,
Charlie P.

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Tue, 28 May 2002 12:49:59 -0700

Hi Charlie, I can not think of any at this point. Eliminating the
requirement (of link-local address defence by HA) would simplify HA
design.

Subrata

-----Original Message-----
Sent: Tuesday, May 28, 2002 12:40 PM

Hello Subrata,

Regards,
Charlie P.

---

From: Brian Haley <[email-masked]>
Date: Tue, 28 May 2002 16:14:32 -0400

Hi Charlie,

>    if it's valid (its lifetime has not expired).

I guess I agree with these, but I'm a little confused by the different
meanings of "valid" above.  I would say:

When a MN is at home, it's global address is valid for as long as the
prefix it used to construct it is valid (and it's actively defending the
address (i.e. running)).  When away from home, it's global home address
is only valid if it has a binding with a HA that is defending/proxying
for the address. If a MN cannot register a binding with it's HA and the
lifetime has expired, it's global home address cannot be considered
valid and should not be used until a BU/BAck has successfully taken place.

>    while the mobile node is away from home.

This is separate issue from the above.  The goal here is to defend the
interface-id of the MN so that another node doesn't autoconfigure a
global address that the MN hasn't yet configured on the home link
using it (ala DAD optimization in RFC 2462).

> It should still recognize multicast packets... why not?

Yes, that seems correct, it just can't send a RS to speed-up the process if
it can't configure it's link-local address (I think?  It's been a while since
I looked at this...).

> not usually mandate storage requirements for a protocol implementation.

The Mobile IPv6 draft says MNs and HAs "MUST use non-volatile memory"
to store sequence numbers  :)

-Brian

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Tue, 28 May 2002 13:47:49 -0700

The link-local address does not have to be based on the IID, see the
following excerpt from RFC 2462.  

" If a node determines that its tentative link-local address is not
   unique, autoconfiguration stops and manual configuration of the
   interface is required.  To simplify recovery in this case, it should
   be possible for an administrator to supply an alternate interface
   identifier that overrides the default identifier in such a way that
   the autoconfiguration mechanism can then be applied using the new
   (presumably unique) interface identifier.  Alternatively, link-local
   and other addresses will need to be configured manually."

Subrata

-----Original Message-----
Sent: Tuesday, May 28, 2002 1:15 PM
To: Charles E. Perkins

Hi Charlie,

valid and should not be used until a BU/BAck has successfully taken
place.

> It should still recognize multicast packets... why not?

Yes, that seems correct, it just can't send a RS to speed-up the process
if
it can't configure it's link-local address (I think?  It's been a while
since
I looked at this...).

don't

-Brian

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 29 May 2002 12:43:32 -0400

[Vijay, hopefully you'll get this... we are vhaving e-mail problems...]

> great, that you agree the link local address needs to be defended.

That's what it looks like. ;)

> period during which the MN was inactive. this might be an extreme

Hmm.  Multiple cases:
     1. Mobile did not shutdown gracefully.
     2. Mobile lost the interface before shuttding down.
     3. Packet was lost.
     ... (i.e. I can't think of any more right now, but you get the poin?)

these are just some of the reason.

-vlad

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 29 May 2002 12:54:24 -0400

Charlie

> home address as long as they are addressed to the home agent.

We seem to agree on this point.

> I don't think the HA should do this.

Why not.  The HA has a valid binding and has recieve a NS packet in DAD
format for the link-local address HA is proxying for.  Why shouldn't the HA
reply?

> directly (with lifetime zero).

I thought that the mobile always knows it's home address.  I must at least
know it's home prefix for Dynamic HA Discovery and forming an address from
that is easy (assuming addrconf).

To send the BU to the home agent, it needs the link-level address.  The
way to get that address is either through NS/NA exchange or from the RA.
We can't do the NS/NA exchange since DAD on the link-local address failed
and we don't have any other ones yet.  So we need the RA.

> == the mobile node's home address.

Well, we don't really care what the source address is for the RS.  The
unspecified address (::) will trigger a multicast RA which is all we want
right now.

> layer-2 address (assuming it needs it for framing).

It can't do that.  This address will change every time you change a NIC or
change the default HA.

-vlad

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 29 May 2002 13:05:31 -0400

Charlie

I'll coment only on your assumptions since Brian already addresses
your comments.

>    while the mobile node is away from home.

These assumptions are correct; however, you are making an assumption
that the valid and prefered timers on the home address continue ticking
even when the mobile is powered off.  When the mobile comes up, it has
no idea how long it's home address would be considered valid.
It generally knows a home prefix, but it uses the timer values from
RAs to set the time-outs.

It might be able to figure out (and store in NV ram) the approximate
time when the prefix whould expire and then compare that time to current
to see if the address whould have still been valid.  However that assumes
that a clock on the mobile whould be somewhat accurate.

As you can see, that's a lot of assumptions to make. ;)

-vlad

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 29 May 2002 12:19:08 -0700

Hello Vlad,

> that a clock on the mobile whould be somewhat accurate.

If the mobile device is turned off, and remembers its home address,
but forgets the lifetime information, or has screwed up its clock,
then I agree it has to run through the whole rigamarole again.

I'd like to suggest that we first get a solution to the problem
for devices that are not so forgetful, and then see what steps
need to be taken for the more amnesiac devices.  I would very
much hope to avoid making trouble for the devices that have
better memories.

For the amnesiac devices, maybe the simplest thing to do it
to let DAD fail for the link-local address, since the home
agent is defending it.  Then, the amnesiac mobile node can
get another address.  If it wants to reclaim its former address,
it can do so by deregistering the previous care-of address.

I'm not so clear on how an amnesiac device can forget everything,
but still remember its security parameters with the home agent,
and still remember its previous care-of address, but on the
other hand I don't think this is the common case.

For truly amnesiac devices, using a new home address should
be O.K.  For devices that remember their DNS name, and thus
might need a stable resolution, I reckon they can remember
enough other stuff to make the simpler method work.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 29 May 2002 12:28:22 -0700

Hello Vlad,

> format for the link-local address HA is proxying for.  Why shouldn't the HA

Yes, I agree that the HA would defend the link-local address.
I can't remember just now what I meant by the above; I must have
been thinking that "I don't think the home agent should have to
do this", meaning that we should try to avoid the problem if possible.
It would be nice if the mobile node would remember its link-local
address and use the information to send a Binding Update to the
home agent.

If the mobile node tries and fails to configure the link-local
address, it can inspect the packet informing it of failure and
surmise that it is at home.  It can then attempt to send the
deregistration packet to the home agent.  Nothing to lose, right?
And, much to gain.

> that is easy (assuming addrconf).

And, it has to remember its security assocation with the home agent,
presumably.

> way to get that address is either through NS/NA exchange or from the RA.

Or from just remembering it, exactly as it remembers the home address.

> and we don't have any other ones yet.  So we need the RA.

This is debatable, but still if the home agent sends the Router Advertisement,
there is a way for the mobile node to make progress, just by finally
sending the deregistration.

> It can't do that.  This address will change every time you change a NIC or

Those are infrequent events, which can be handled by more cumbersome
methods.  The frequent case should be quite streamlined.

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 29 May 2002 13:00:22 -0700

>      2. Mobile lost the interface before shuttding down.

is your binding update list on the interface data structure??

>      3. Packet was lost.

didnt the mobile realise that it did not get the binding ack
back.

>      ... (i.e. I can't think of any more right now, but you get the poin?)

come on.. this is ridiculous. you want to build a 99.999% reliable
protocol??

looks like everybody wants to make a point when it comes to 
MIPv6. please lets move on......

Vijay

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 29 May 2002 13:23:32 -0700

Hello Brian,

I reckon we're pretty close here.

> valid and should not be used until a BU/BAck has successfully taken place.

I agree with this(*), and with the other points you made following.

> to store sequence numbers  :)

Ouch!  Uncle!  You win!

Regards,
Charlie P.

(*) but there are four extra apostrophes...