Subject: [DNA] Sending RS probe after link-change in simple DNA

From: Julien Laganier <[email-masked]>
Date: Wed, 05 Mar 2008 14:54:25 +0100

Folks,

I see two problems with the current behavior when sending RS probe with 
simple DNA.

1. Router creating a NCE for a global address belonging to a different 
subnet:

Let's suppose the host change from link1 to link2 which have 
respectively prefixes prefix1 and prefix2 announced by router1 and 
router2. Let's suppose the RS probe sent by the host is sourced from a 
global unicast address under the prefix prefix1 obtained from the 
previous router router1, e.g. prefix1::iid.

According to RFC4861 the RS should contain a SLLAO:

>    A host sends Router Solicitations to the all-routers multicast
> address.  The IP source address is set to either one of the
> interface's unicast addresses or the unspecified address.  The
> Source Link-Layer Address option SHOULD be set to the host's
> link-layer address, if the IP source address is not the unspecified
> address.

When the router receives the RS with the SLLAO, the following happens 
according to RFC4861:

>    Router Solicitations in which the Source Address is the
> unspecified address MUST NOT update the router's Neighbor Cache;
> solicitations with a proper source address update the Neighbor Cache
> as follows. If the router already has a Neighbor Cache entry for the
> solicitation's sender, the solicitation contains a Source
> Link-Layer Address option, and the received link-layer address
> differs from that already in the cache, then the link-layer address
> SHOULD be updated in the appropriate Neighbor Cache entry, and its
> reachability state MUST also be set to STALE.  If there is no
> existing Neighbor Cache entry for the solicitation's sender, the
> router creates one, installs the link- layer address and sets its
> reachability state to STALE as specified in Section 7.3.3.

Thus since a SLLAO is present but router2 has no existing NCE for the 
host, router 2 will create a NCE for the global unicast address 
prefix1::iid although prefix1 is not on-link and not advertized on 
link2 by router2.

Isn't that a problem?

If it is that could be avoided by specifying that a simple DNA host MUST 
source its RS probes from one of its link-local addresses.

2. Problem of default router selection when moving in a NETLMM domain.

As you might know, when a host moves within a NETLMM domain, although it 
may change attachment link, it will consistently receive the same 
router advertisement in RAs sent by the NETLMM MAGs acting as default 
router.

Let's suppose a host change from link1 to link2 served by MAG1 and MAG2. 
With the currently specified behavior of a simple DNA host, if the 
prefix is the same then the host should conclude it hasn't changed 
link:

>   On reception of a Router Advertisement which contains prefixes which
> intersect with those previously advertised by a known router, the
> host utilizes the configuration associated with the detected network.

Thus after the link change the host will continue to use the 
configuration valid on link1 where the default router is MAG1. However, 
it is now attached to link2, where MAG2 should be the default router. 
Since MAG2 and MAG1 might well have different link-local addresses and 
MAC addresses. Thus, MAG2 will be added to the default router list but 
won't be selected as default router instead of MAG1. This is going to 
be a problem since host won't be able to send packets to its default 
router MAG1. Thus connectivity for the host will be disabled until NUD 
concludes MAG1 isn't reachable causing MAG2 to be selected as a new 
default router.

The DNAv6 protocol had the following provision in section 
5.2.6.3 "Router Reachability Detection and Default Router Selection" to 
make it work well with NETLMM:

>    Prior to sending a DNA RS in response to an indication of link
> change, the host SHOULD set all Neighbor Cache entries for routers
> on its Default Router List to STALE.  When the host receives an RA in
> reply to the RS, the host SHOULD mark that router's Neighbor Cache
> Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the
> REACHABLE state if one does not currently exist.
>
>    The host SHOULD also update its Default Router List in the
> following fashion.  If any of the routers returning RAs are already
> on the default router list, the host SHOULD use the information in
> the RA to update the Default Route List entry with the new
> information.  The host SHOULD add entries to the Default Router List
> for any routers returning RAs that are not on the list.  The host
> SHOULD confine selection of a router from the Default Router List to
> those routers whose Neighbor Cache entries are in the REACHABLE
> state.  Note that the Default Router List SHOULD be updated as
> described here regardless of whether the RA indicates that the host
> has changed to a new IP link, since changes in router reachability
> are possible on some link types even if the host remains on the same
> IP link.

Would it be possible to adopt a similar behavior for simple DNA?

Thanks.

--julien

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 06 Mar 2008 01:25:17 +0900

Dear Julien

About your concerns,
we don't have to worry about the first one, a false NCE creation.

In simple DNA, RS/ NS messages use a Tentative Option, instead of SLLAO.
So there would not happen a false NCE.

It's more complex for your second concern, non valid router address.

Simple DNA is not based on link identification anymore,
i.e. it doesn't determine whether a host remains at the same link or not.

Instead simple DNA just verifies the validity of an address (or addresses)
by confirming reachability with the routers which is associated with
the address.

It is still unclear how simple DNA verify other IP configuration parameters
such as router address, prefix or MTU.

Kindly find my inline comments.

>  According to RFC4861 the RS should contain a SLLAO:

However, in simple DNA, RS would contain Tentative option,
instead of a SLLAO.

>  prefix1::iid although prefix1 is not on-link and not advertized on

No. Because the RS comes not with SLLAO but tentative option,
this would not happen.

>  concludes MAG1 isn't reachable causing MAG2 to be selected as a new

this is a problem. Maybe we should recommend that

Upon every DNA operation,
a host should re-affirm it's default router address & perform DAD,
even it turns out that the host remains at the same link.

best regards

JinHyeock

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 05 Mar 2008 09:16:04 -0800

> source its RS probes from one of its link-local addresses.

[BA] I think that makes sense.

> > host utilizes the configuration associated with the detected network.

[BA] This is wrong.  Previous configuration should only be reused if the
RA originates from a router corresponding to a valid address.  An
RA originating from another router should be processed normally. 

> > REACHABLE state if one does not currently exist.

[BA] I agree that something along these lines should be included in the
Simple DNA spec.  I would also suggest that a router responding to a unicast
NS be marked as REACHABLE.  

> Would it be possible to adopt a similar behavior for simple DNA?

[BA] I think it would be possible (and desirable).

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 05 Mar 2008 16:26:49 -0500

Hi Jin,
   Just one comment.

> even it turns out that the host remains at the same link.

This is already the case. Only an RA from a known router will confirm 
the addresses associated with that router as usable. Any other RA (i.e. 
not from a previously known router) will be processed using 4861/4862 rules.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 05 Mar 2008 16:44:15 -0500

Hi Bernard,
   Please find comments inline.

> [BA] I think that makes sense.

This problem does not arise since the RS will use the tentative option 
instead of the SLLAO.

> RA originating from another router should be processed normally.

I agree with you. That is why the text mentions "known router". Perhaps 
the term requires more clarification?

> NS be marked as REACHABLE. 

I can add this text, but is this any different from 4861 behavior?

> [BA] I think it would be possible (and desirable).

Again, I think this is the same behavior specified by 4861. Should we 
reiterate it here? I have no issues adding text similar to this, but I 
would like to avoid duplication between this document and 4861.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 05 Mar 2008 16:20:06 -0500

Hi Julien,
   Thanks for the comments. Please see responses inline.

Julien Laganier wrote:
> <snipped>
> ...

One of the requirements of Simple DNA is that the router support 
tentative options as defined in draft-ietf-dna-tentative-00.txt. So the 
RS will contain a tentative option (TO) instead of the SLLAO. And such 
option will not create a neighbor cache entry.

> concludes MAG1 isn't reachable causing MAG2 to be selected as a new 

The sentence above holds true only when an RA is received from a KNOWN 
ROUTER (i.e. one that has an entry in the SDAT). So this issue will 
occur only if MAG2 and MAG1 have the same link local AND MAC address ( 
in which case there is no real issue :-)

Thanks
Suresh

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 06 Mar 2008 22:41:57 +0900

Dear Suresh

>  not from a previously known router) will be processed using 4861/4862 rules.

Allow me to make more clear expression.

The above is about
not to verify host's IP address
but to verify default router's address.

Overall I still have difficulty discerning
how simple DNA verifies IP configuration parameters other than IP address
such as prefix, router address or MTU.
(I'm still waiting for your reply.)

Right now, it's written in 3.5. that

For example, assume a host has two default routers R1 and R2.
Also assume that, upon DNA initiation,
the host receives an RA with a known prefix from R1.

At this point, will the host start utilizing R2 as a valid default router
or wait till NS/ NA exchange with R2/ RA from R2?

The above paragraph gives an impression of the first.

Thanks in advance for your kind consideration.

best regards

JinHyeock

---

From: Julien Laganier <[email-masked]>
Date: Thu, 06 Mar 2008 17:30:47 +0100

On Wednesday 05 March 2008, Suresh Krishnan wrote:
> >  > Thus since a SLLAO is present but router2 has no existing NCE
> >  > for the host, router 2 will create a NCE for the global unicast
> >  > address prefix1::iid although prefix1 is not on-link and not
> >  > advertized on link2 by router2.
> >  >
> >  > Isn't that a problem?
> >  >
> >  > If it is that could be avoided by specifying that a simple DNA
> >  > host MUST source its RS probes from one of its link-local
> >  > addresses.
> >
> This problem does not arise since the RS will use the tentative
> option instead of the SLLAO.

Ah, ok, missed that. However if the RS is sourced from a link-local we 
don't even need to rely on the tentative option.

Why would it be useful to source the RS from a global unicast as opposed 
to a link-local address? In other word what would we loose by 
restricting the source address to a link-local? That seems like an easy 
and cheap fix.

> >  > As you might know, when a host moves within a NETLMM domain,
> >  > although it may change attachment link, it will consistently
> >  > receive the same router advertisement in RAs sent by the NETLMM
> >  > MAGs acting as default router.
> >  >
> >  > Let's suppose a host change from link1 to link2 served by MAG1
> >  > and MAG2. With the currently specified behavior of a simple DNA
> >  > host, if the prefix is the same then the host should conclude it
> >  > hasn't changed
> >  >
> >  > link:
> >  > > On reception of a Router Advertisement which contains prefixes
> >  > > which intersect with those previously advertised by a known
> >  > > router, the host utilizes the configuration associated with
> >  > > the detected network.
> >
> > [BA] This is wrong.  Previous configuration should only be reused
> > if the RA originates from a router corresponding to a valid
> > address.  An RA originating from another router should be processed
> > normally.
>
> I agree with you. That is why the text mentions "known router".
> Perhaps the term requires more clarification?

Then at minimum the text should have "On reception of a Router 
Advertisement from a *known* router...". 

But that wouldn't be necessary if we adopt the text coming from DNAv6 
spec regarding default router selection (copied below).

> >  > configuration valid on link1 where the default router is MAG1.
> >  > However, it is now attached to link2, where MAG2 should be the
> >  > default router. Since MAG2 and MAG1 might well have different
> >  > link-local addresses and MAC addresses. Thus, MAG2 will be added
> >  > to the default router list but won't be selected as default
> >  > router instead of MAG1. This is going to be a problem since host
> >  > won't be able to send packets to its default router MAG1. Thus
> >  > connectivity for the host will be disabled until NUD concludes
> >  > MAG1 isn't reachable causing MAG2 to be selected as a new
> >  > default router.
> >  >
> >  > > change, the host SHOULD set all Neighbor Cache entries for
> >  > > routers on its Default Router List to STALE. When the host
> >  > > receives an RA in reply to the RS, the host SHOULD mark that
> >  > > router's Neighbor Cache Entry [3] as REACHABLE, or add a
> >  > > Neighbor Cache Entry in the REACHABLE state if one does not
> >  > > currently exist.
> >
> > [BA] I agree that something along these lines should be included in
> > the Simple DNA spec.  I would also suggest that a router responding
> > to a unicast NS be marked as REACHABLE.
>

Yes it is. According to RFC4861 Section 6.3.4 "Default router selections 
are made whenever communication to a destination appears to be 
failing", i.e. when NUD concludes the previous router is no longer 
reachable, that is after a timeout. The above text from the DNAv6 spec 
would allow to start to use the router that send the RA immediately.

> >  > > following fashion. If any of the routers returning RAs are
> >  > > already on the default router list, the host SHOULD use the
> >  > > information in the RA to update the Default Route List entry
> >  > > with the new information. The host SHOULD add entries to the
> >  > > Default Router List for any routers returning RAs that are not
> >  > > on the list. The host SHOULD confine selection of a router
> >  > > from the Default Router List to those routers whose Neighbor
> >  > > Cache entries are in the REACHABLE state. Note that the
> >  > > Default Router List SHOULD be updated as described here
> >  > > regardless of whether the RA indicates that the host has
> >  > > changed to a new IP link, since changes in router reachability
> >  > > are possible on some link types even if the host remains on
> >  > > the same IP link.
> >  >
> reiterate it here? I have no issues adding text similar to this, but
> I would like to avoid duplication between this document and 4861.

This is different from 4861. RFC 4861 section 6.3.6 only states "Routers 
that are reachable or probably reachable (i.e., in any state other than 
INCOMPLETE) SHOULD be preferred over routers whose reachability is 
unknown or suspect (i.e., in the INCOMPLETE state, or for which no 
Neighbor Cache entry exists).

Since the WG had previously agreed on the above text from DNAv6, IMHO we 
can just take it as is since it solve the problem without 
inconvenience.

--julien

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 06 Mar 2008 12:04:10 -0800

> > This problem does not arise since the RS will use the tentative> > option instead of the SLLAO.> > Ah, ok, missed that. However if the RS is sourced from a link-local we > don't even need to rely on the tentative option.> > Why would it be useful to source the RS from a global unicast as opposed > to a link-local address? In other word what would we loose by > restricting the source address to a link-local? That seems like an easy > and cheap fix.
[BA] Unless the tentative option is universally supported on routers, it would
probably be best not to rely on it.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 06 Mar 2008 12:05:51 -0800

> For example, assume a host has two default routers R1 and R2.> Also assume that, upon DNA initiation,> the host receives an RA with a known prefix from R1.> > At this point, will the host start utilizing R2 as a valid default router> or wait till NS/ NA exchange with R2/ RA from R2?
[BA] I hope that it will wait for the NS/NA exchange (unless it receives
an RA from R2).

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 06 Mar 2008 23:50:55 -0500

Hi Jin,

> (I'm still waiting for your reply.)

If the host verifies a router address through an NS/NA pair it assumes 
all the addresses formed from the prefixes obtained from that router are 
valid (the prefix and the router address are stored in the SDAT). Right 
now MTU information is not stored. I am fine with including it in the SDAT.

> The above paragraph gives an impression of the first.

I meant the second one(wait for NS/NA or RA with R2). But you are right. 
The sentence is unclear. I think I will rephrase the sentence to 
clarify. Do you have any suggestions?

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 06 Mar 2008 23:59:50 -0500

Hi Julien,

> restricting the source address to a link-local? That seems like an easy 

Sounds like a good idea. I will make the change as you suggest.

> would allow to start to use the router that send the RA immediately.

Aah, OK. I see the issue now. So the bone of contention is that we will 
differentiate between REACHABLE and STALE while 4861 will not (it will 
differentiate between INCOMPLETE and non-INCOMPLETE only). I agree with 
you and I will adopt the text from the DNA solution.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 07 Mar 2008 00:06:31 -0500

Hi Bernard,
   Thanks for the comments. (Merging two of your mails) Please see 
responses inline.

> probably be best not to rely on it. 

I agree with you and Julien on this and I will make the change to use a 
link local address as the source address of the RS.

 > [BA] I hope that it will wait for the NS/NA exchange (unless it receives

Yes, it does. It will wait for either an NS/NA exchange with R2 to 
complete or receive an RA from R2 before using R2 as a default router.

Thanks
Suresh

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 07 Mar 2008 18:29:02 +0900

Suresh

>  clarify. Do you have any suggestions?

ok. now I have an impression that

simple DNA verifies IP configuration parameters
such as IP address, prefix & MTU
by individually confirming the reachability with an associated router.

Do I understand right?

thanks for your kind consideration.

best regards

JinHyeock

---

From: Julien Laganier <[email-masked]>
Date: Sun, 09 Mar 2008 20:21:09 +0100

Hi Suresh,

Thanks for adopting the changes I suggested.

--julien

On Friday 07 March 2008, Suresh Krishnan wrote:
> >>>  > for the host, router 2 will create a NCE for the global
> >>>  > unicast address prefix1::iid although prefix1 is not on-link
> >>>  > and not advertized on link2 by router2.
> >>>  >
> >>>  > Isn't that a problem?
> >>>  >
> > Ah, ok, missed that. However if the RS is sourced from a link-local
> > we don't even need to rely on the tentative option.
> >
> > Why would it be useful to source the RS from a global unicast as
> > opposed to a link-local address? In other word what would we loose
> > by restricting the source address to a link-local? That seems like
> > an easy and cheap fix.
>
> >>>  > receive the same router advertisement in RAs sent by the
> >>>  > NETLMM MAGs acting as default router.
> >>>  >
> >>>  > and MAG2. With the currently specified behavior of a simple
> >>>  > DNA host, if the prefix is the same then the host should
> >>>  > conclude it hasn't changed
> >>>  >
> >>>  > link:
> >>>  > > On reception of a Router Advertisement which contains
> >>>  > > prefixes which intersect with those previously advertised by
> >>>  > > a known router, the host utilizes the configuration
> >>>  > > associated with the detected network.
> >>>
> >>> address.  An RA originating from another router should be
> >>> processed normally.
> >>
> > But that wouldn't be necessary if we adopt the text coming from
> > DNAv6 spec regarding default router selection (copied below).
> >
> >>>  > link-local addresses and MAC addresses. Thus, MAG2 will be
> >>>  > added to the default router list but won't be selected as
> >>>  > default router instead of MAG1. This is going to be a problem
> >>>  > since host won't be able to send packets to its default router
> >>>  > MAG1. Thus connectivity for the host will be disabled until
> >>>  > NUD concludes MAG1 isn't reachable causing MAG2 to be selected
> >>>  > as a new default router.
> >>>  >
> >>>  > > Prior to sending a DNA RS in response to an indication of
> >>>  > > link change, the host SHOULD set all Neighbor Cache entries
> >>>  > > for routers on its Default Router List to STALE. When the
> >>>  > > host receives an RA in reply to the RS, the host SHOULD mark
> >>>  > > that router's Neighbor Cache Entry [3] as REACHABLE, or add
> >>>  > > a Neighbor Cache Entry in the REACHABLE state if one does
> >>>  > > not currently exist.
> >>>
> >>> [BA] I agree that something along these lines should be included
> >>> in the Simple DNA spec.  I would also suggest that a router
> >>> responding to a unicast NS be marked as REACHABLE.
> >>
> > Yes it is. According to RFC4861 Section 6.3.4 "Default router
> > selections are made whenever communication to a destination appears
> > to be failing", i.e. when NUD concludes the previous router is no
> > longer reachable, that is after a timeout. The above text from the
> > DNAv6 spec would allow to start to use the router that send the RA
> > immediately.
>
> Aah, OK. I see the issue now. So the bone of contention is that we
> will differentiate between REACHABLE and STALE while 4861 will not
> (it will differentiate between INCOMPLETE and non-INCOMPLETE only). I
> agree with you and I will adopt the text from the DNA solution.
>
> Thanks
> Suresh