Re: Re: Reclassification of DNA Protocol and new Simple DNA protocol

>>      o  As a performance optimization, it must not
sacrifice
>>         correctness.  In other words, false
positives are not
>>         acceptable.  DNAv6 must not conclude that a
host has returned
>>         to a previously visited link where it has
an operable IP
>>         address if this is not in fact the case.
>
>Simple DNA will not produce false positives unless two
routers on two 
>different links happen to have the same link local
address and MAC address. 
>Is this a likely scenario that needs to be addressed?

The combination of same link local address *and* MAC address
is unlikely, 
assuming that the MAC address is globally unique.  However,
not all link 
layers will have a globally unique MAC address, so that
there may be a need 
to restrict applicability to those that do.

>I think Simple DNA works as quick as RFC4861 in the
worst case (false 
>negative) scenarios.

>This is why we send the RS and the NSs in parallel as
you suggested. This 
>ensures that the simple DNA procedure does not run
slower than just using 
>RSs.

Right.

>The heuristic in use for simple dna is to store and use
the previous 'n' 
>link configurations. Thus it satisfies (a). It we use a
sufficiently large 
>value of 'n' we can ensure that (b) is met. We recommend
n to be 2 but if 
>you think that the number is too low we can increase
it.

A previous link configuration should only be tried if it is
still 
corresponds to a valid address.  Otherwise, confirming
presence of the 
corresponding router could result in installation of a
configuration which 
is no longer valid, which would create a false positive. In
practice this 
will restrict the DNAv6 traffic substantially so I'm not
clear that it is 
necessary to recommend a value of "n".

Hi Bernard,
   Please see my responses inline

Bernard Aboba wrote:
> The combination of same link local address *and* MAC
address is 
> unlikely, assuming that the MAC address is globally
unique.  However, 
> not all link layers will have a globally unique MAC
address, so that 
> there may be a need to restrict applicability to those
that do.

I will add some text in the assumptions and mention the
pitfalls if this 
does not hold true.

> 
>> The heuristic in use for simple dna is to store and
use the previous 
>> 'n' link configurations. Thus it satisfies (a). It
we use a 
>> sufficiently large value of 'n' we can ensure that
(b) is met. We 
>> recommend n to be 2 but if you think that the
number is too low we can 
>> increase it.
> 
> A previous link configuration should only be tried if
it is still 
> corresponds to a valid address.  Otherwise, confirming
presence of the 
> corresponding router could result in installation of a
configuration 
> which is no longer valid, which would create a false
positive. In 
> practice this will restrict the DNAv6 traffic
substantially so I'm not 
> clear that it is necessary to recommend a value of
"n".

The following text in Section 3.4 already sets this as a
restriction

"If the addresses obtained from a previous router are
no longer valid, 
the host SHOULD NOT send a Neighbour Solicitation to that
router."

Does this convey what you want or Would you like some
stronger text?

Thanks
Suresh

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

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.

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

However, in simple DNA, RS would contain Tentative option,
instead of 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?

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

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

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

Hi Jin,
   Just one comment.

JinHyeock Choi wrote:
> 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.

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

Hi Bernard,
   Please find comments inline.

Bernard Aboba 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.
> 
> [BA] I think that makes sense.

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

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

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

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

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

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

Julien Laganier wrote:
> 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:
> <snipped>
> ...
> 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?

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.

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

Dear Suresh

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

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

   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.

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

On Wednesday 05 March 2008, Suresh Krishnan wrote:
> Hi Bernard,
>    Please find comments inline.
>
> Bernard Aboba 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.
> >
> > [BA] I think that makes sense.
>
> 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.

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

> >  > 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.
> >
> > [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.
>
> I can add this text, but is this any different from
4861 behavior?

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.

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

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

> Thanks
> Suresh