Subject: [DNA] [New I-D] FW: I-D ACTION:draft-daniel-dna-fastraopt-00.txt

From: "Soohong Daniel [email-masked]" <[email-masked]>
Date: Sat, 11 Jun 2005 10:43:32 +0900

fyi. 

All commnets are highly welcome.

Regards,
---------------------------------------------
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Saturday, June 11, 2005 4:37 AM
> To: [email-masked]
> Subject: I-D ACTION:draft-daniel-dna-fastraopt-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: IPv6 Fast Neighbor Discovery Option
> 	Author(s)	: S. Park
> 	Filename	: draft-daniel-dna-fastraopt-00.txt
> 	Pages		: 0
> 	Date		: 2005-6-10
> 	
> To minimize router delay in response to Router Solicitation message,
>    several scheme are being discussed in IETF.  This document 
> suggests a
>    new Neighbor Discovery option which is included in Router
>    Solicitation and/or Router Advertisement messages to achieve fast
>    network attachment.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-daniel-dna-fastraopt-00.txt
ENCODING mime
FILE /internet-drafts/draft-daniel-dna-fastraopt-00.txt

---

From: Brett Pentland <[email-masked]>
Date: Mon, 13 Jun 2005 11:02:09 +1000

Hello Daniel,

I read through your draft and have a question.  In the introduction, you
recognise that the reason for the RA random delay in RFC 2461 is to
prevent simultaneous responses from multiple routers.  I can't see
anything in your draft that replaces the random delay to provide this
separation.  Are you just proposing that like 
draft-mkhalil-ipv6-fastra-05.txt, one router be configured to provide
fast responses?

The difference would then just be that fast responses are only given
by that configured router to hosts that specifically request it.

If you have to go to the effort of configuring one router to be able to
provide fast responses, then why would you ever want it not to provide
a fast response?

Brett.

Soohong Daniel [email-masked] wrote:
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>I-D-Announce mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: James Kempf <[email-masked]>
Date: Mon, 13 Jun 2005 09:52:57 -0700

Danial,

The DT considered having a designated "fast responder" and rejected the idea
based on the need for configuration. The algorithm described in
draft-pentland doesn't require configuring any router to be the fast
responder. This has two benefical effects: 1) it removes the possibility of
error and need for additional human attention which makes network management
easier, 2) it removes problems if the designated fast responder crashes or
is taken offline.

            jak

---

From: James Kempf <[email-masked]>
Date: Mon, 13 Jun 2005 10:44:52 -0700

I've been meaning to write this up for some time. Below is some text for a
section to add to draft-pentland about the interaction of DNA with host
address configuration, both unicast and multicast. It covers stateful and
stateless address configuration. The text is intended to be for a new
section in draft-pentland, presuming, of course, that the WG approves
draft-pentland as the basis for the WG draft.

Comments?

            jak

---------------------------
5.2.5 DNA and Address Configuration

When a host moves to a new link, a potential exists for a change in the
validity of its unicast link local and global addresses, and its multicast
addresses. In this section, host processing for address configuration is
specified. The section considers both statelessly and statefully configured
addresses.

5.2.5.1 Duplicate Address Detection

A DNA host MUST support optimistic Duplicate Address Detection [RFCoDAD] for
autoconfiguring unicast link local addresses. If a DNA host uses address
autoconfiguration [RFC2462] for global addresses, the  DNA host MUST support
optimistic Duplicate Address Detection for autoconfiguring global unicast
addresses.

5.2.5.2 DNA and the Address Autoconfiguration State Machine

When a link level event occurs indicating that the host has moved from one
link to another, DNA requires the host to determine whether a change in IP
link has occured by sending an RS. The DNA host SHOULD select one of its
link local addresses that is in the "Confirmed" state (i.e. assigned to an
interface) and utilize that as the source address on the DNA RS. If the host
has no "Confirmed" link local addresses but does have an address in the
"Optimistic" state, it MUST utilize that as the source address. Since
optimistic Duplicate Address Detection is required for DNA, the host should
not have any addresses in the "Tentative" state. If the host currently has
no link local addresses, it MUST construct one and put it into the
"Optimistic" state. Note that the presence of a duplicate link local address
 on the link will not interfere with the ability of the link to route a
unicast RA from the router back to the host, because the TSLLA option is
included in the RS and is utilized by the router on the RA frame.

If the host receives no RA in reply, it MUST transition all addresses to the
"Optimistic" state and act according to [RFC2461] as if no router has been
discovered on the link.

If the received RAs indicate that the host has not moved to a new IP link
(i.e. the IP link has not changed) either because a DNA RA has been received
or nonDNA RAs have been received and the host performs CPL, then the host is
REQUIRED to leave the state of all "Confirmed" and "Optimistic" addresses
unchanged and continue with optimistic Duplicate Address Detection for
"Optimistic" addresses. This includes both unicast link local and
statelessly autoconfigured unicast global addresses (but not statefully
configured global unicast addresses).

If the received RAs indicate that the host has moved to a new IP link (i.e.
the IP link has changed), either because a DNA RA has been received or
nonDNA RAs have been received and the host performs CPL, the host MUST
transition all autoconfigured addresses in the "Confirmed" state to
"Optimistic" and begin optimistic Duplicate Address Detection signaling for
them. Optimistic Duplicate Address Detection signaling for "Optimistic"
addresses MUST also be restarted and continued until either a duplicate is
detected or the signaling timeout occurs, according to [RFCoDAD].

5.2.5.3 DNA and Statefully Configured Addresses

The DHCPv6 specification [RFC3315] requires hosts to send a DHCPv6 CONFIRM
message when a change in link is detected. Since the DNA protocol provides
the same level of movement detection as the DHCPv6 CONFIRM, it is
RECOMMENDED that DNA hosts not utilize the DHCPv6 CONFIRM message when a DNA
RA is received, to avoid excessive signaling.

When a DNA RA is received, statefully configured addresses are handled
similarly to autoconfigured addresses. If the received RA indicates that the
host has not moved to a new IP link, the statefully configured addresses are
still valid and can continue to be used until their lease expires. If the
DNA RA indicates that the host has moved to another link, the host is
REQUIRED to begin stateful configuration again.

If, however, a nonDNA RA is received, the host SHOULD use the DHCPv6 CONFIRM
message as described in RFC 3315 rather than wait for additional RAs to
perform CPL, since it reduces the amount of time required for the host to
confirm whether or not it has moved to a new link. If the CONFIRM message
validates the addresses, then the host can continue to use them. If not, the
host MUST perform DHCPv6 stateful address configuration again, as described
by RFC 3315.

5.2.5.4 Change in IP Link Address Configuration Type

It is possible that a host may encounter a change in IP link address
configuration type (for example, from stateful to stateless) when it moves
from one IP link to another. The solicited RA will indicate what type of
address configuration to perform in this case, and MUST be followed.

In general, a change in IP link address configuration type should not occur
if the host does not change IP link. However, if the initial DNA RA
indicates that the host has not changed IP link but the IP link address
configuration type is different from the last indication of the address
configuration type on the link, the host SHOULD wait for additional RAs
before beginning address reconfiguration. If all RAs agree as to the address
configuration type change, then the host MUST perform address
reconfiguration as specified by the RAs even though it has not changed to a
new link. If the RAs do not agree, then it is likely that the routers are
misconfigured, and the host MAY continue to use previous addresses as
described above, but an error message should be logged to inform the network
administrator, and the host should be vigilant for possible errors.

5.2.5.5 Multicast Address Configuration

If the returned DNA RA indicates that the host has not moved to a new IP
link, no further action is required for multicast addresses to which the
host has subscribed.

If, on the other hand, the DNA RA indicates that the host has moved to a new
IP link, the host MUST issue MLD [RFC3810] messages to the router for
subscribed multicast addresses, including the
Solicited_Node_Multicast_Address for any unicast addresses configured.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Jun 2005 15:22:44 -0700

James Kempf wrote:

> interface) and utilize that as the source address on the DNA RS.

Doesn't this imply that if the host has moved to a new link, and the 
Confirmed address is a duplicate on that link, that the host might 
accidentally overwrite the neighbor cache entry for the existing user of 
that link-local address?

That would seem to defeat the purpose of DAD.

It is safer to, immediately when the link level event arrives, switch 
all Confirmed addresses to Optimistic.
Then if it turns out that the host didn't move, it can switch those back 
to Confirmed.
And if it turns out that the host did move, it can send the actual NS 
DAD probe for all the IP addresses it has (the existing link-local 
addresses, as well as any newly configured IP addresses).

> Solicited_Node_Multicast_Address for any unicast addresses configured.

It actually needs to handle the Solicited node multicast addresses 
before starting any DAD procedure, to ensure that it will receive DAD 
messages when there are MLD snooping L2 switches.

   Erik

---

From: "Soohong Daniel [email-masked]" <[email-masked]>
Date: Tue, 14 Jun 2005 08:58:08 +0900

Jak, 

The purpose of this approach is just to separate fixed node
and mobile node as well as avoid configuring router to support 
fast router response. That is all. As Brett pointed out, I was
also think of multiple router issues to prevent simultaneous 
responses from them, but in my experience, it was not so 
serious problem in the real networks.

Regarding DT consideration, I didn't know of that since 
non-DT guys are not able to see what happen in DT..:-)

Regards,

> From: James Kempf [mailto:[email-masked]] 
> Sent: Tuesday, June 14, 2005 1:53 AM
> To: Soohong Daniel [email-masked]; [email-masked]
> Subject: Re: [DNA] [New I-D] FW: I-D 
> ACTION:draft-daniel-dna-fastraopt-00.txt
> 
> 
> Danial,
>

---

From: "Soohong Daniel [email-masked]" <[email-masked]>
Date: Tue, 14 Jun 2005 09:37:04 +0900

Jak, 

>similarly to autoconfigured addresses.

Just curious to know, 
It means that DNA RA has a kind of M/O flags of a general RA (rfc2462) 
or just uses them ? Above mention does not clear for me at this point.

>If the DNA RA indicates that the host has moved to another link, the host
is
>REQUIRED to begin stateful configuration again.

Suggested to be added following above sentence (if appropriate of course),

In DNA, it is beneficial to rapidly configure hosts. The DHCPv6 operation as
4-message exchange, however, allows for redundancy (multiple DHCPv6
servers) without wasting addresses, as addresses are only provisionally
assigned to a host until the host chooses and requests one of the
provisionally
assigned addresses. If the DNA host supports the Rapid Commit Option 
[RFC3315], it is possible that the exchange can be shortened from a 
4-message exchange to a 2-message exchange.

Regards,

---

From: James Kempf <[email-masked]>
Date: Mon, 13 Jun 2005 17:44:12 -0700

> That would seem to defeat the purpose of DAD.

Draft-pentland in Section 5.2.3 says this:

   Hosts MUST include a tentative source link layer address option
   (TSLLAO) in the RS message [13].  The router solicitation message is
   sent to the All_Routers_Multicast address and the source address MUST
   be the link local address of the host.

The router uses the TSLLAO to route back to the host, and the definition of
the TSLLAO means that it won't pollute the neighbor cache if there's a
duplicate. So there should be no effect on the router neighbor cache even if
there is a duplicate, and the router shouldn't send the RS to any other node
even if there is a duplicate because the TSLLAO will allow link routing to
work correctly.

> addresses, as well as any newly configured IP addresses).

I considered that, but the problem is that if the addresses are switched to
"Optimistic" . Section 3.3 of draft-ietf-ipv6-optimistic-dad says this about
the "Optimistic" state:

   * (modifies 5.4)  As soon as the initial Neighbor Solicitation is
        sent, the Optimistic Address is configured on the interface and
        available for use immediately.  The address MUST be flagged as
        'Optimistic'.

so what this means to me is that the node would have to send NSes on the
link prior to switching its addresses to Optimistic, even if it is on the
same link, because it doesn't find out that it is on the same link until
after the RA returns. I'm not sure whether the extra traffic overhead on
each move is really necessary or beneficial.

Unfortunately, there's no good solution here. Here are the possible states
and their problems:

- Optimistic: requires NS/DAD signaling even if the host hasn't switched IP
links. If the host has switched IP links, then any packets sent with a
global unicast address while the RS/RA transaction is underway will be sent
with an address that is topologically incorrect (because the host may send
packets while an address is in "Optimistic").

- Confirmed: If the host has switched links, then any packets sent with a
global unicast address will be sent with an address that is topologically
incorrect, as above.

- Tentative: requires NS/DAD signaling even if the host hasn't switched IP
links, but no topologically incorrect addresses will be used if the host has
switched links since a host can't send any packets from a Tentative address.

- Deprecated: not relevant, since the host can continue to use the address
for existing connections and therefore would have the same problem with
topological incorrectness here as with Optimistic and Confirmed.

If we are OK with having the host signal to reconfirm addresses on every
move, then we could switch the link local address used as the source address
on the RS to Optimistic, and the others to Tentative prior to sending the
RS. This would avoid the problem with topological incorrectness for global
unicast addresses. When the RS returns, we could switch everything to
Optimistic if the host is on the same IP link, since no change in topology
has occured. If the IP link has changed, then the link local addresses could
be switched to Optimistic and the unicast global addresses could be dropped
(actually "dropped" is not in the state machine, and Deprecated isn't
appropriate because RFC 2462 allows the host to continue using Deprecated
addresses), and the host would then configure new global unicast addresses.

Any other ideas about how to handle this?

> messages when there are MLD snooping L2 switches.

Yes, that's true. I'll switch that around to make it clear.

            jak

---

From: James Kempf <[email-masked]>
Date: Mon, 13 Jun 2005 17:55:54 -0700

> or just uses them ? Above mention does not clear for me at this point.

The existing flags are unchanged.

> 4-message exchange to a 2-message exchange.

Sure, thanx for pointing this out.

            jak

---

From: Brett Pentland <[email-masked]>
Date: Tue, 14 Jun 2005 15:00:26 +1000

Hi Jim,

Thanks for doing this.  It looks like it will be a good addition to
the draft once the few issues that have been raised are addressed.

> link has occured by sending an RS. The DNA host SHOULD select one of its

We need to keep the terminology consistent (and this goes for the rest
of the draft too...)  The last discussions on this list that I can find
(around 26/5/05) talked about "point of attachment" for what you have
here called "link", and "link" for what you have called "IP link".  I
think the intention is to have them defined in the "L2 event
notifications for DNA" document.

> detected or the signaling timeout occurs, according to [RFCoDAD].

This sounds right for link-local addresses, but I think global addresses
will be invalid because of the link change and should be dropped
altogether.  New global addresses may be formed based on the prefix
information in the RA and those should go into the Optimistic state.

Brett.

---

From: James Kempf <[email-masked]>
Date: Tue, 14 Jun 2005 08:27:29 -0700

Hi Brett,

> notifications for DNA" document.

OK, sorry, I wrote it up quickly and didn't pay much attention to making the
terminology consistent. I'll clean it up once we have discussion complete.

> information in the RA and those should go into the Optimistic state.

Right, that makes sense.

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Jun 2005 20:02:57 -0700

> even if there is a duplicate because the TSLLAO will allow link routing to

This handles the RS not overwriting a previous entry in the routers 
neighbor cache, but doesn't prevent other hosts on the link (which send 
a NS for instance) from being polluted.

> each move is really necessary or beneficial.

There is no technical reason for optimistic DAD to require that the NS 
be sent before or even after state change AFAIK. Do you see a technical 
reason?

AFAIK The state change says "don't pollute" and the NS is there to find 
out whether there is a duplicate.

   Erik

---

From: Brett Pentland <[email-masked]>
Date: Fri, 17 Jun 2005 17:17:43 +1000

<snip>
> non-DT guys are not able to see what happen in DT..:-)
<snip>

Regarding this, we have just opened up the design team mailing list
archive in case anyone is interested.

The archive is at:

http://www.ctie.monash.edu.au/warchive/dna-dt

Cheers,
Brett.

---

From: Brett Pentland <[email-masked]>
Date: Fri, 17 Jun 2005 17:20:28 +1000

Oops.  Should have given the previous email a relevant subject header.

Brett.

Brett Pentland wrote:
>> Regarding DT consideration, I didn't know of that since non-DT guys 
>> are not able to see what happen in DT..:-)
> 
> <snip>
>

---

From: James Kempf <[email-masked]>
Date: Mon, 20 Jun 2005 15:10:09 -0700

> a NS for instance) from being polluted.

Right, it would mean suspending NS responses for the duration of the
response to the RS. Of course, that's what Optimistic does.

> be sent before or even after state change AFAIK. Do you see a technical

No, but unfortunately the oDAD document doesn't say anything about this.
Most implementors of oDAD will probably send it out when the state change to
Optimistic happens, because the draft says that, but when combined with DNA,
I suspect there may be some confusion unless we make it clear.

How about: the node SHOULD avoid sending the NS until after the RS is
returned?

Note that even if we do change the state to Optimistic, there is still the
issue I raised about the node originating packets with a topologically
incorrect source address if it has moved to a new IP link. The only way to
prevent that from happening is to make the addresses Tentative (and suppress
the DAD NS until after the RA returns) until the node actually finds out in
the RA whether it actually has moved to a new IP link or not.

> out whether there is a duplicate.

That is the spirit.

            jak

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 21 Jun 2005 08:34:16 +1000

> I suspect there may be some confusion unless we make it clear.

G'day James,

	OptiDAD got a "discuss" from IESG, so there's a last round
of revision happening some time Real Soon Now.  If there's something
you reckon needs clarification, now's the time to discuss it!

> the RA whether it actually has moved to a new IP link or not.

Yeah, I think the safest thing is to Deprecate any addresses at Link
Down, and Tentative/Optimistic them at Link Up.  That should allow
source address selection to behave correctly in the case of multiple
interface devices as well.

-----N

---

From: Greg Daley <[email-masked]>
Date: Tue, 21 Jun 2005 15:21:52 +1000

Hi Nick.

> On 2005-06-20, James Kempf wrote:
[cut]
> interface devices as well.

This may be the safest way (making them deprecated) but may also result
in devices having no non-::1 addresses available to applications when
they receive a (momentary) link-layer down indication.

(Just asking): Is this appropriate behaviour?

It would be good to have an applications perspective on this...

Perhaps it would be OK in a MIPv6 environment, since there could
always be a home address to bind to, even if it's no good for
routing to the internet at the moment while all links are down...

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Jun 2005 03:16:57 -0700

> No, but unfortunately the oDAD document doesn't say anything about this.

I suspect the oDAD document has no need to say anything. It isn't until 
one tries to combine oDAD with DNA that the issue of separating the 
optimistic state change and the sending of the NS appears.

> I suspect there may be some confusion unless we make it clear.

Agreed.

> How about: the node SHOULD avoid sending the NS until after the RS is

Or. more generally, until it has determined that it has moved to a new 
link. If an RS is returned which indicates that it didn't move, then 
there is no need to send an RS.

> the RA whether it actually has moved to a new IP link or not.

Originating such packets is ok I think. If the host has moved to a new 
link it will not receive any "replies". It might make sense and assume 
that it didn't move in this case until it's discovered that it did move.

   Erik

---

From: James Kempf <[email-masked]>
Date: Tue, 21 Jun 2005 08:41:17 -0700

> you reckon needs clarification, now's the time to discuss it!

I'll take another look at the draft and see if I can come up with some
suggested changes. Where should I send them?

> interface devices as well.

The problem with Deprecated is that any apps with such addresses active
still continue to send on the address, though new socket connections will
not be opened, so new connections will favor interfaces with Confirmed
addresses. I suppose one could take the position that this is OK, and it is
up to some additional mechanism (seamless handover support?, buffering in
the IP stack while the link transition is occuring?) to handle this problem;
that is, it is outside the scope of DNA to handle it.

            jak

---

From: James Kempf <[email-masked]>
Date: Tue, 21 Jun 2005 09:46:07 -0700

> there is no need to send an RS.

You mean "no need to send an NS" I think.

Well, there is unfortunately an off chance that, while the host is in
transit from one wireless AP to another, someone comes on the link, sends
out one NS to DAD an address that the in-transit host had claimed, and gets
back no response. The new host would therefore conclude that the address was
not a duplicate, but when the in-transit host came back on the link, it
would be a duplicate. Considering the low probability of a collision in
general (which is what makes oDAD statistically possible in the first
place), this case is even more wildly unlikely, but it is still not
completely impossible. :-(

> that it didn't move in this case until it's discovered that it did move.

OK. So moving to Optimistic prior to sending the RS rather than to Tentative
is probably OK. I think this aligns with what I mentioned in my response to
Nick, that handling packets sent to an address while the host is in transit
is out of scope for DNA.

Do you think making the addresses Deprecated on Link Down is OK, like Nick
suggested? This would prevent any new applications from opening sockets on
them. If the host is multi-interface, these sockets would be directed to a
Confirmed or Optimistic address on another interface, which might or might
not be a benefit.

            jak

---

From: James Kempf <[email-masked]>
Date: Tue, 21 Jun 2005 15:59:29 -0700

> There is also an off chance with a wired Ethernet and hosts that never
> move, that when A boots up and sends the NS, the some switch or link is
> overloaded so that it drops the single NS, hence B (which has the same
> address as A) never sees the NS.
>
> The point is that DAD was not designed to discover duplicates under any
> assumptions; it was designed to be a light-weight mechanism to discover
> (infrequently occurring) duplicate address with a reasonable
> probability, since without any DAD, should a duplicate exist, it is
> quite painful to debug for the user/operator.
>

OK, sounds fine. Then I guess we can say that the host moves the addresses
to Optimistic before it sends the RS, but defers NS until it knows whether
or not it is on a new IP link.

> Multihoming is out of scope of RFC 2461 for a good reason :-)
>
> I actually don't think we want to overload the deprecated or any other
> existing state with the notion that an interface is (suspected to be)
> not working, or flaky, or high packet loss. I think all those quality
> metrics should be captured using a separate mechanism. The the stack,
> when it has multiple interfaces to choose from, take those quality
> metrics into account.
>

So then it sounds like we should keep the address state unchanged until the
Link Up, and only then change to Optimistic.

> My 2 cents,

Anybody else have a comment?

            jak

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 21 Jun 2005 15:06:05 -0700

> You mean "no need to send an NS" I think.

Oops - yes.

My 2 cents,
    Erik

---

From: Greg Daley <[email-masked]>
Date: Wed, 22 Jun 2005 11:21:36 +1000

Hi James & Eric,

James Kempf wrote:
[cut]
> Anybody else have a comment?

Sounds like a reasonable assumption.

Should this be tied to the Link-Up indications, or to the DNA reception
and processing of hints?

For example, if no link-layer indication is received does the
reception of an 'unexpected' RA and subsequent initiation of
DNA operations cause Optimistic to be set?

I'd guess it's tied to DNA initiation, rather than the Link-Up
explicitly.

Greg

---

From: Christian Vogt <[email-masked]>
Date: Wed, 22 Jun 2005 12:42:18 +0200

>>> There is no technical reason for optimistic DAD to require that
 >>> the NS be sent before or even after state change AFAIK. Do you
 >>> see a technical reason?
 >>
 > I suspect the oDAD document has no need to say anything. It isn't
 > until one tries to combine oDAD with DNA that the issue of separating
 > the optimistic state change and the sending of the NS appears.

Hi Erik, hi all,

yes, there ARE scenarios without DNA where you would want to use a 
tentative/optimistic address before the initial NS is sent.

I am actually working on a little draft that identifies some of those 
situations.  Below is the relevant extract.  (Credits also go to Greg; 
we have been discussing some of this before.)

In essence:  There are (at least) three situations in which having to 
send the NS implies additional delays:  The NS must be preceeded by a 
MLD Report, and there is a delay of up to 1 second for the MLD Report 
after interface re-activation in RFC 2462bis.

There are two possible solutions:

(1)  Allow a MN to send the MLD Report without delay (like it may send 
an RS without delay according to RFC2461bis).
(2)  Allow the MN to use a tentative/optimistic address before the 
initial NS is sent.

I have proposed the first option on the IPv6 list where folks agreed 
that this should probably be attended to within the DNA WG.

I'm at a conference right now, but will try to wrap the draft up in between.

- Christian

++++
2.3.  Situation C

--- Routers on the new IP link do not support the TSLLAO for
RSs.  The mobile node solicits a unicast RA.

Soliciting a unicast RA requires the mobile node to send a RS from an 
optimistic address.

- MN sends a MLD Report for an optimistic address.
- MN sends a NS for the optimistic address, initiating ODAD.
- MN sends a RS from the optimistic address.
- MN receives a unicast RA.

The MLD Report (step 1) is delayed for up to 1 second 
(MAX_RTR_SOLICITATION_DELAY) because it is the first message transmitted 
after (re-) enabling the interface [RFC2462bis].

2.4.  Situation D

--- Routers on the new IP link do not support the TSLLAO for
RSs, but do send unsolicited multicast RAs every 30ms to 70ms according 
to rules in [RFC3775].

- MN receives a multicast RA.
- MN sends a MLD Report for an optimistic address.
- MN sends an initial NS for the optimistic address (ODAD).

The MLD Report (step 2) is delayed for two reasons.  First, it is the 
first message transmitted after (re-) enabling the interface.  This 
calls for a delay of up to 1 second (MAX_RTR_SOLICITATION_DELAY) 
[RFC2462bis].  Second, the MLD Report is sent in response to a multicast 
RA.  This also calls for a delay of up to 1 seconds 
(MAX_RTR_SOLICITATION_DELAY) [RFC2462bis].

2.5.  Situation E

--- Routers on the new IP link do not support the TSLLAO for
RSs.  The mobile node solicits a multicast RA.

The mobile node can send the RS from the unspecified address, 
eliminating the requirement to initiate ODAD at this point.

- MN sends an RS from the unspecified address.
- MN receives a multicast RA.
- MN sends a MLD Report for an optimistic address.
- MN send a NS for the optimistic address, initiating ODAD.

The RS (step 1) may be sent immediately, even though this is the first 
message transmitted after (re-) enabling the interface [RFC2461bis].

The multicast RA (step 2) is delayed for up to 3 seconds (maximum of 
MAX_RA_DELAY_TIME and MIN_DELAY_BETWEEN_RAS) [RFC2461bis].

The MLD Report (step 3) is delayed for up to 1 second 
(MAX_RTR_SOLICITATION_DELAY) because it is sent in response to a 
multicast RA [RFC2462bis].
++++

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

Erik Nordmark wrote:
> James Kempf wrote:
> 
>>> There is no technical reason for optimistic DAD to require that
>>> the NS be sent before or even after state change AFAIK. Do you
>>> see a technical reason?
>>> 
>> 
>> 
> I suspect the oDAD document has no need to say anything. It isn't
> until one tries to combine oDAD with DNA that the issue of separating
> the optimistic state change and the sending of the NS appears.
> 
>> Most implementors of oDAD will probably send it out when the state
>>  change to Optimistic happens, because the draft says that, but
>> when combined with DNA, I suspect there may be some confusion
>> unless we make it clear.
> 
> 
> Agreed.
> 
>> How about: the node SHOULD avoid sending the NS until after the RS
>> is returned?
> 
> 
> Or. more generally, until it has determined that it has moved to a
> new link. If an RS is returned which indicates that it didn't move,
> then there is no need to send an RS.
> 
>> Note that even if we do change the state to Optimistic, there is
>> still the issue I raised about the node originating packets with a
>> topologically incorrect source address if it has moved to a new IP
>> link. The only way to prevent that from happening is to make the
>> addresses Tentative (and suppress the DAD NS until after the RA
>> returns) until the node actually finds out in the RA whether it
>> actually has moved to a new IP link or not.
> 
> 
> Originating such packets is ok I think. If the host has moved to a
> new link it will not receive any "replies". It might make sense and
> assume that it didn't move in this case until it's discovered that it
> did move.
> 
> Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Jun 2005 04:44:05 -0700

> I'd guess it's tied to DNA initiation, rather than the Link-Up

Things wouldn't work safely from a DAD perspective if there is no 
link-up notification.

Take an example:
1. Host moves and attaches to link B (no link-up notification)
2. Host receives a NS for it's link-local address. It responds since it
    isn't aware that it might have moved to a different link.
3. Host receives an unsolicited RA, which has some 'unexpected' things
    in it (e.g., only unknown prefixes). This triggers DNA; move
    addresses to optimistic state and send RS.

The issue is that if the link-local address is a duplicate on the new 
link, then at #2 the host would mess up things for the existing user of 
that link-local address on the new link.

So things can't be very robust without a link-up notification.

    Erik

---

From: James Kempf <[email-masked]>
Date: Wed, 22 Jun 2005 08:41:11 -0700

> I'd guess it's tied to DNA initiation, rather than the Link-Up

Well, there's a couple cases to consider.

Case 1: Multicast RA

Suppose the host receives a multicast DNA RA, either as a result of failover
to multicast mode due to RS overload on the router or simply as a multicast
beacon. If the host can conclude that it has not moved to a new IP link, no
changes in address state are required. If the host can conclude that it has
moved to a new IP link, the old addresses should be Deprecated, the host
should form a new link local address, set state to Optimistic, oDAD it, and
then form new global unicast addresses, etc., just as if it had moved, even
if it didn't get a link event indicating movement (the link event may have
failed for some reason). But the host doesn't need to do anything "prior" to
sending the RS, because it didn't send one.

Case 2: Unsolicted unicast RA

This case is pretty unlikely and is probably due to an error (or somebody
playing a trick on the host by sending an RS with the victim's link address
in the TSLLAO and the victim's link local address as the source address).
I'd say in this case the host should be cautious and should issue a unicast
DNA RA in order to confirm. But I don't think it should make any changes in
its address state machine in this case, because there is no link event
indicating a link change. If a link change actually did occur, of course,
the addresses need to be reconfigured.

How does that sound?

            jak

---

From: James Kempf <[email-masked]>
Date: Wed, 22 Jun 2005 09:46:26 -0700

Erik,

Yes, I agree, I think we discussed this in the DT. But I think it's still
possible that it might be an error case.

There two error cases are that the host receives a multicast RA w.o. any
Link Up, and the host receives an unsolicited unicast RA w.o. a any Link Up.
In a separate email, I proposed a couple ways to handle this, maybe you
could take a look at it and comment?

It's also possible that the host receives a multicast RA with Link Up, as,
for example, if it sends an RS and the router is overloaded, but that case
should be covered by the procedure for what to do before sending a DNA RS.

            jak