Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt

From: Brett Pentland <[email-masked]>
Date: Thu, 21 Jul 2005 18:37:28 +1000

Hi Christian,

Sorry I only just got to read through the draft. Thanks for your
efforts.  It's a good summary of the situation.

Regarding the potential solution in section 4.2, I gather you are
talking about something like:

- Host sends RS with optimistic unicast source address and TSLLAO
- Router replies with unicast RA (using LLA from TSLLAO)
- Host only then sends MLD report (after delay)
- Host send NS for oDAD

This sounds good for most communications (assuming that most
communications with the host go through the router).  There
might still be a bit of a problem if an on-link device (other
than the router) tries to send a packet to the optimistic
address before the MLD report goes out since the host won't
receive the resulting NS from this on-link node.  I guess this
might come up if the host is a mobile node and tries to perform
route optimization with a node that just happens to be connected
to the same link as itself.

Any thoughts?
Brett.

---

From: Brett Pentland <[email-masked]>
Date: Mon, 25 Jul 2005 11:05:10 +1000

Hi Erik, Christian,

> But in that case wouldn't the new host send a NS as part of 
> communicating with the CoA of the peer? I guess it depends on the 
> details of any MIPv6 RO procedure.

Ah yes.  For some reason a forgot that the MN would be the one
initiating the communication.  Is there any way that an on-link
node could obtain the MN's CoA and try to initiate a
communication?

Brett.

---

From: Christian Vogt <[email-masked]>
Date: Sun, 24 Jul 2005 23:45:08 +0200

Hi Brett,

thanks for the feedback.

 > - Host only then sends MLD report (after delay)

Exactly, this is what we are having in mind.

The ODAD specification currently demands that the MN must send the 
initial NS (4th step above) before it can use an optimistic address. 
But this implies that the MLD Report would be the very first message, 
inducing a delay of up to a second.

Our proposal is to allow the MN to use the optimistic address before 
sending the initial NS.

 > to the same link as itself.

Good point.  In this case, the mobile node should recognize that its 
correspondent's address is on-link.  And it would initiate address 
resolution for the correspondent's address by sending a NS to the 
solicited-nodes address.  If the mobile node adds a TSLLAO to that NS, 
the correspondent should be able to respond (provided it understands the 
TSLLAO, which we have to assume in this case, I guess).

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 24 Jul 2005 12:05:13 -0700

> - Host only then sends MLD report (after delay)

Looks good to me.

Presumably the last step isn't needed if the host didn't move to a 
different link. (One might think the same thing applies to the third 
item, but due to MLD/IGMP snooping L2 devices, that wouldn't be safe 
when the host has changed its L2 attachment point.)

    Erik

---

From: Christian Vogt <[email-masked]>
Date: Sun, 24 Jul 2005 23:50:52 +0200

Hi Erik.

 > when the host has changed its L2 attachment point.)

Right, ODAD can be canceled when the mobile node learns from the RA that 
it is still on the same IP link.

 >> [...]                                               I guess this
 > But in that caFrom [email-masked] Sun Jul 24 23:36:06 2005
Date: Sun, 24 Jul 2005 23:50:52 +0200
From: Christian Vogt <[email-masked]>
Subject: Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt
Sender: [email-masked]
To: Erik Nordmark <[email-masked]>
Cc: Brett Pentland <[email-masked]>,
        DNA <[email-masked]>, TM-RO2 <[email-masked]>

Hi Erik.

 > when the host has changed its L2 attachment point.)

Right, ODAD can be canceled when the mobile node learns from the RA that 
it is still on the same IP link.

 >> [...]                                               I guess this

The mobile node should be fine when it uses a TSLLAO in the NS (and the 
peer understands the TSLLAO).

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 25 Jul 2005 09:32:03 +0200

Hi Brett, hi Erik.

 > node could obtain the MN's CoA and try to initiate a

Ok, you are talking about the case were an on-link node configures the 
MN's optimistic address after the MN has configured that address (as 
optimistic), but before the MN has sent the initial NS for that address, 
right?

Draft-ietf-ipv6-optimistic-dad-05.txt says:

    * (modifies 5.4.3) The node MUST NOT reply to a Neighbor Solicitation
         for an Optimistic Address from the unspecified address.  This NS
         indicates that the address is a duplicate, and it MUST be
         deconfigured as per the behaviour specified in RFC2462 for
         Tentative addresses.

In this case, the NS is from a node doing (0)DAD.  The rule ensures that 
  the node who sends the NS first wins and can retain the address.

    * (modifies 5.4.3) The node MUST reply to a Neighbor Solicitation for
         an Optimistic Address from a unicast address, but the reply MUST
         have the Override flag cleared (O=0).

In this case, the NS is from a node doing normal address resolution. 
This rule should not be a problem.

- Christian

---

From: Brett Pentland <[email-masked]>
Date: Mon, 25 Jul 2005 17:42:21 +1000

> optimistic), but before the MN has sent the initial NS for that address, 

No.  I was wondering if it's possible for an on-link node to obtain the
CoA and try to start a communication with the MN.  I guess this doesn't
make sense.  Thinking further, the MN would only be using the address in
this pre-oDAD state to get a RA.  It would have to send the MLD and NS
packets before it started using the address any further.

Maybe this does have implications for MIPv6, etc.  The MN can't really
send a binding update until after the NS which has to wait for the MLD
report.

Any thoughts?
Brett.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Jul 2005 03:28:42 -0700

> node could obtain the MN's CoA and try to initiate a

I decided to walk through the details for the case when a CN on a link 
and the MN moves to that link, and does RO with the CN.

The steps would be:
1. MN uses DNA to detect that it has moved; sees a link up notification, 
and sends an RS (address is optimistic)
2. Receives an RA which indicates that it has moved.
3. Sends a BU to the HA. Initiates the BU process with the CN by sending 
a CoTI (and HoTI). The CoTI is sent from the CoA to the CN's address, 
thus it triggers the NS/NA exchange with the CN.
4. CN receives the HoTI and responds with a HoT. Receives the CoTI at 
about the same time. Tries to send a CoT. Has the neighbor cache entry 
for the CoA from the NS it received in #3.

Looks ok.

But if the CN was really a MN (MN2) (i.e., we have two MNs which have 
moved to the same link), then the CoTI wouldn't be sent to the HoA2, and 
tunneled by HA2 to CoA2. Thus in #3 there wouldn't be a NS/NA exchange - 
the CoTI would be sent to HA2 (which we assume is off link).

But even in that case I think we are ok; the CoT will be sourced by MN2 
with HoA2 as the source address, thus MN2 will reverse tunnel it via 
HA2. Hence MN2 doesn't need a neighbor cache entry in #4.

Later (step 5) the MN sends the BU from CoA to CoA2, which makes it do a 
NS/NA exchange to find the link layer address for CoA2.

I guess one can do similar analysis for other RO schemes, but it might 
be a bit tedious.

One can instead argue that if the MN sends the MLD report as part of #3, 
even if it is sent after the other messages in #3, then the probability 
that something will try to do a NS/NA exchange with the MN before the 
MLD report is sent is very small. And should that ever happen, then the 
fact that the NS will be retransmitted after 1 second should take care 
of things.

So in summary, it's ok as long as the MLD report is sent "early", even 
if it isn't sent first.

    Erik

---

From: Brett Pentland <[email-masked]>
Date: Tue, 26 Jul 2005 11:27:23 +1000

> So in summary, it's ok as long as the MLD report is sent "early", even 

OK.  Sounds fine.  Thanks for working through it.

Brett.