Subject: Re: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt

From: JinHyeock Choi <[email-masked]>
Date: Mon, 14 Jan 2008 14:29:46 +0430

Dear Suresh & Greg

I managed to go over the draft and thanks for your trouble.

Before making comments, I'd like to ensure that I understand the draft right.
Here are a few clarifying questions.

1. Assumption
The draft seems to assume the following w.r.t prefix advertisement.

   1) All routers on the link advertise the same prefixes.
   2) It's out of scope how routers would synchronize their advertisement.

Do I understand right?

2. Link identification.
The draft seems to check for link change as below.

   1) Upon receiving link-layer indication,
           a host would send an RS and an NS simultaneously.
   2) If the host receives a solicited NA from a known node
       of a previously attached link,
           the host assumes it still remains in the same link.
   3) If the host receives a solicited RA with a known prefix
       of a previously attached link,
           the host assumes it still remains in the same link.
       Otherwise, i.e. the host receives no known prefix in the RA,
           the host assumes it moved to a different link.
   4) When 2 & 3 give conflicting answers, 3's decision is definite.

Do I understand right?

3. Fast Router Advertisement
The draft seems to speed up RA delivery as below.

   1) Upon receiving an RS with a tentative option,
       a DNA router immediately sends back an unicast RA without random delay
      (with token bucket based rate control)
   2) It's out of the scope how mulitple DNA routers would avoid collision.

Do I understand right?

Thanks in advance for your kind consideration.

Best Regards

JinHyeock

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 14 Jan 2008 10:40:19 -0800

Comments below. > Date: Mon, 14 Jan 2008 14:29:46 +0430> From: [email-masked]> To: [email-masked]> Subject: Re: [DNA] RE: Review of draft-krishnan-dna-simple-01.txt> CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]> > Dear Suresh & Greg> > I managed to go over the draft and thanks for your trouble.> > Before making comments, I'd like to ensure that I understand the draft right.> Here are a few clarifying questions.> > 1. Assumption> The draft seems to assume the following w.r.t prefix advertisement.> > 1) All routers on the link advertise the same prefixes.
 
[BA] No.  It is possible to send multiple NS so that this assumption is not required. 
> 2) It's out of scope how routers would synchronize their advertisement.> > Do I understand right?> > 2. Link identification.> The draft seems to check for link change as below.> > 1) Upon receiving link-layer indication,> a host would send an RS and an NS simultaneously.
 
[BA] Yes.
> 2) If the host receives a solicited NA from a known node> of a previously attached link,> the host assumes it still remains in the same link.
 
[BA] Yes -- unless the RA provides different information. 
> 3) If the host receives a solicited RA with a known prefix> of a previously attached link,> the host assumes it still remains in the same link.> Otherwise, i.e. the host receives no known prefix in the RA,> the host assumes it moved to a different link.
 
[BA] There is also the possibility that DHCPv6 is in use, in which
case 2) can confirm the validity of an IPv6 address whose lease has
not yet expired. 
> 4) When 2 & 3 give conflicting answers, 3's decision is definite.
 
[BA] Correct -- except for DHCPv6 case, where 2) may confirm
the validity of a previously assigned address, but 3) may indicate
the need to send a DHCPv6 request.   As before if the DHCPv6
assigned address conflicts with the address determined in 2),
then DHCPv6 wins.

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 15 Jan 2008 05:41:55 +0900

Dear Bernard

thanks for your comments.

>  [BA] No.  It is possible to send multiple NS so that this assumption is not

Multiple NSs won't correct the wrong DNA decision from RAs with
disjoint prefix lists. An NS/NA based DNA decision is overruled by RA
based DNA decision. Upon receiving an RA with  no known prefix, a host
will assume a link change even if NS/ NA exchange indicates no link
change.

> > a host would send an RS and an NS simultaneously.

ok.

>  [BA] Yes -- unless the RA provides different information.

ok.

>  case 2) can confirm the validity of an IPv6 address whose lease has

ok.

>  assigned address conflicts with the address determined in 2),

ok.

Thanks for your kind consideration.

best regards

JinHyeock

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 14 Jan 2008 18:09:13 -0800

> Multiple NSs won't correct the wrong DNA decision from RAs with> disjoint prefix lists. An NS/NA based DNA decision is overruled by RA> based DNA decision. Upon receiving an RA with no known prefix, a host> will assume a link change even if NS/ NA exchange indicates no link> change.
 
[BA] Why?  If a NUD exchange suceeds, the host should merely assume
that the information it got from that particular router is still valid, not that
it has confirmed *all* the information from *all* the routers.   So if it
assigned a still-valid address based on a particular prefix announcement,
it need only confirm reachability to the router that sent that prefix
announcement.  Receiving an RA with no known prefix from some other
router is immaterial.  And of course, if that same router updates its prefix list,
then the previously cached DNA configuration information is invalidated. 
 
As an example, if a host previously recieved an RA with no known prefix,
and as a result got a valid address assigned via DHCPv6, it should be able
to confirm the validity of that address based on a NUD exchange with the
router (while doing a DHCPv6 configuration exchange in the background).

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 15 Jan 2008 07:47:53 +0430

Bernard

>  [BA] Why?

From the below, I had assumed that RA based decision always takes precedent.

  > >  assigned address conflicts with the address determined in 2),

However, from your remarks below, it seems that sometimes NS/ NA based
decision overrules RA based decision.

>  If a NUD exchange suceeds, the host should merely assume
>  router is immaterial.

ok. However this necessitates hosts to maintain the state of pairs, (a
prefix, a router which advertise the prefix). Also if an RA with no
known prefix arrives before a solicited NA, I assume the host
immediately decides a link change, instead of waiting for the NA.

I have difficulty discerning the above mechanism from the draft.
That's why I first tried to clarify DNA operation lest we should
discuss over irrelevant items.

>  And of course, if that same router updates its
>  prefix list,

ND allows a router to omits some prefixes when it advertises an RA. So
from a prefix list in an RA, a host has difficulty discerning whether
a missing prefix is invalidated or simply omitted.

>  router (while doing a DHCPv6 configuration exchange in the background).

This is not clear. With which router a host should perform NUD to
validate a DHCP based address? No router has specific relation with
the DHCP based address. Any router will do? If that's the case, why
can't we use that criterion for non-DHCP based address.

Now I come to wonder why RA based decision is assumed definite. Maybe
it's better to make NS/NA based decision takes precedents over RA
based decision.

Best Regards

JinHyeock

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 14 Jan 2008 19:49:02 -0800

> >  assigned address conflicts with the address determined in 2),

[JC] However, from your remarks below, it seems that sometimes NS/ NA based
decision overrules RA based decision.

[BA] I think that an RA from a router will over-ride an NA from that same
router, with respect to a given address.  But an RA from another router will
not. 

>  that the information it got from that particular router is still valid,
not
>  that

[JC] ok. However this necessitates hosts to maintain the state of pairs, (a
prefix, a router which advertise the prefix). Also if an RA with no
known prefix arrives before a solicited NA, I assume the host
immediately decides a link change, instead of waiting for the NA.

[BA] The way I think of it is that the host needs to determine
whether its existing addresses are valid.  It can determine that based
on receipt of an NS from a router, or receipt of RAs.   

Let us assume that formerly router A announced a prefix from which the
host formed address A.  Now with Simple DNA, the host tries to determine
if that address is still valid.  In response to an RS, it receives an RA
from that same router with no known prefix.  It can now conclude that 
address A is not valid, under the assumption that the prefix should have
been included if the router was still advertising it. 

However, the host could also have formed another address B based on an
announcement from router B.  With Simple DNA, the host sends a unicast NS
to router B which responds with a solicited NA.  The host can now assume
that
address B is still valid -- unless it receives an RA from router B
that is missing the prefix from which that address was derived.

[JC] I have difficulty discerning the above mechanism from the draft.
That's why I first tried to clarify DNA operation lest we should
discuss over irrelevant items.

[BA] You are correct that the current draft does not describe how 
Simple DNA needs to operate.  As you state, for simple DNAv6 the 
host needs to maintain lists of valid addresses and the 
corresponding routers from which they obtained those addresses.  
This is how DNAv4 works. 

>  then the previously cached DNA configuration information is invalidated.

[JC] ND allows a router to omit some prefixes when it advertises an RA. So
from a prefix list in an RA, a host has difficulty discerning whether
a missing prefix is invalidated or simply omitted.

[BA] Right -- but if the router wants to deprecate a previously announced
prefix, it does have to announce it, no?  We are assuming that the host
only uses simple DNAv6 to re-confirm addresses that would otherwise be
still valid (e.g. addresses whose DHCPv6 lease has not yet expired, or
whose prefix is still valid).  If the address is invalid, then the host
should not be using simple DNAv6. 

>  router (while doing a DHCPv6 configuration exchange in the background).

[JC] This is not clear. With which router a host should perform NUD to
validate a DHCP based address? No router has specific relation with
the DHCP based address. Any router will do? If that's the case, why
can't we use that criterion for non-DHCP based address.

[BA]  To validate a DHCPv6-based address, the host should perform NUD
to the router which lead it to believe that DHCPv6 was supported on
the link.  If it receives an NA, it can assume that the DHCPv6
address is still valid, assuming that the original lease has not yet
expired.  Of course, if it receives an RA from that router indicating
that conditions have changed (e.g. now DHCPv6 is no longer supported),
or receives a response from the DHCPv6 server indicating that another
address is being assigned, then the host's configuration should change.

[JC] Now I come to wonder why RA based decision is assumed definite. Maybe
it's better to make NS/NA based decision takes precedents over RA
based decision.

[BA] Receipt of an RA is additional information which may invalidate an
assumption made as a result of receipt of an NA.  For example, the RA
could indicate different prefixes, or a change in address assignment
mechanism (stateless to stateful or the other way around). 

In any case, I think it is important that we write all of this down in the
Simple DNAv6 draft so that we can evaluate it and understand how well it
works and under what conditions it might not work.   I had sent my comments
on the draft in a previous mail.

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 14 Jan 2008 23:02:24 -0500

Hi Bernard and Jin,
Bernard Aboba wrote:
> not that

I have to admit that when we wrote the draft, we did not consider the 
precedence between the NS/NA tests and the RS/RA test. The way I see it 
today, an RA from a router containing disjoint prefixes will only 
override a positive NA confirmation from the same router and other than 
this there will be no interaction between the NS/NA tests and te RS/RA 
tests. I will give this a little more thought and come up with some text 
on this regard.

Thanks
Suresh

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 16 Jan 2008 13:43:04 +0430

Bernard

> router, with respect to a given address.  But an RA from another router will

Then the host should treat RAs differently according to sending
routers. That entails added complexity, which, I'm not sure desirable.
Simple DNA is supposed to simplify DNA operation.

> on receipt of an NS from a router, or receipt of RAs.

From your remark, I assume that a host verifies its addresses one bye
one. The verification of one address doesn't guarantee the validity of
others, right?

This also entails added complexity. Previously DNA checks whether the
host still remains in the same link or not, then accordingly verify
(or invalidate) all its addresses at the same time.

> that is missing the prefix from which that address was derived.

IMO, the host can verify address B based on the verification of
address A. If address A and B were valid in the same link and address
A is proven still valid, it's reasonable to assume that address B also
is still valid (except in some corner cases.)

> mechanism (stateless to stateful or the other way around).

I have in mind the following example.

Assume a host is attached to a link
with two access router R1 and R2
which advertise prefix 1 and prefix 2 respectively.

The host autoconfigures address 1 with prefix 1.

After a while, the host executes DNA and performs NUD with R1 and R2.

When a solicited NA from R2 arrives to confirm R2's reachability,
IMO, it's reasonable to assume that
address 1 with prefix 1 is still valid,
even though a solicited NA from R1 didn't arrive yet (or never).

> works and under what conditions it might not work.

agree. I wish simple DNA operation is presented more clearly lest we
should argue over irrelevant issues.

Best Regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 16 Jan 2008 14:00:59 +0430

Dear Suresh

> tests. I will give this a little more thought and come up with some text

I'm not sure such an intricate deliberation is necessary. In the first
place, simple DNA is supposed to be simple even though it may not
cover some corner cases.

For example, simple DNA can work as below.

1. In a link, a host generates 1) router list and 2) prefix list.

2. Upon initiating DNA, the host performs 1) NUD with routers and 2)
Router/ Prefix discovery.

3. If a solicited NA from a known router arrives,
       the host assumes that
             1) it still remains at the same link and
             2) its addresses are still valid (but it may perform oDAD
in case).
       and turn-off DNA.

4. If no solicited NA arrives and an RA with no known prefix arrives,
       the host assumes that it has moves to another link and
       invalidates all its addresses.

Then we don't have to worry about RA sources but the above will work
for most of the cases.

Best Regards

JinHyeock

---

From: [email-masked]
Date: Wed, 16 Jan 2008 22:42:29 -0800

> one. The verification of one address doesn't guarantee the validity of

The host verifies a subset of routers which generated valid addresses by 
doing
NUD to them and sending an RS.  Verifying reachability via NUD confirms all
prefixes formerly advertised by that router, so it can validate
multiple addresses at once.

> (or invalidate) all its addresses at the same time.

Simple DNA can do the same thing, by verifying all addresses obtained
from the same router simultaneously.  Since there are typically only
a few valid addresses, it is not a complex operation to send a few NSes
and one RS.

> is still valid (except in some corner cases.)

If router B is no longer present, and does not answer NS or send
RAs for prefix B, then the host probably should not conclude that
address B is still valid, even if router A is present and sends NA or RA.

> even though a solicited NA from R1 didn't arrive yet (or never).

Simple DNA will perform NUD to R1 and R2 simultaneous with sending an
RS.  When the solicited NA arrives from R1 it will autoconfigure address 1.
If R2 answers the NS, it will autoconfigure address 2.   It will also 
process
the RAs from R1 and/or R2.  However, if R2 doesn't answer the unicast NS
or the RS, then it won't auto-configure address 2 until it hears evidence 
that
R2 is still there.

---

From: JinHyeock Choi <[email-masked]>
Date: Sat, 19 Jan 2008 10:34:13 +0430

Bernard

now I come to understand simple DNA procedures the better. thanks for
your clarification.

> multiple addresses at once.

ok. Simple DNA verifies addresses per a router, whereas previous DNA
verifies addresses per a link.

> address B is still valid, even if router A is present and sends NA or RA.

The above will happen only when router B becomes out of order during
DNA procedure. It may be a corner case which simple DNA don't have to
worry.

> or the RS, then it won't auto-configure address 2 until it hears evidence

The example above is not about
how a host would autoconfigure a new address in relationship with DNA
operation but about
how a host would verify (already autoconfigured) existing addresses.

IMO, when the host receives a solicted NA from R1,
the host can use the existing address 2 (configured with the
information from R2)
even if it hears no evidence that R2 is still there.
At least, that's how current DNA operates.

Best Regards

JinHyeock