Subject: Re: [DNA] Simple DNA [Fwd: I-D Action:draft-krishnan-dna-simple-03.txt]

From: JinHyeock Choi <[email-masked]>
Date: Tue, 04 Mar 2008 01:26:08 +0900

Dear Bernard

thanks for your kind reply which helped me to understand the scheme the better.

> > 3) a solicited RA without a known prefix from a known router arrives.
> >
> > I can't find the paragraphs for the case
> > when a solicited RA without a known prefix from unknown router arrives
>
> > (which may occur the most in link change case.)
>
> [BA] I think that the case of an solicited (or unsolicited) RA coming from
> an unknown router needs to be discussed (whether it has a known prefix
> or not). My assumption is that this will result in additional addresses
> being configured in addition to any known addresses that may be
> confirmed in the simple DNA exchange.

I have a question.

Assume an unknown prefix arrives from an unknown router
before any NA arrives from a known router.

Shall a DNA host immediately configures a new address &
send a BU (in case of MIPv6) or
wait a little further for a might-be NA from a known router?

If the latter is the case,
how long shall the host wait? A second?

> > 3. Little improvement in case of link change.
> >
> > Simple DNA optimization is mostly based on NS/NA exchange but
> > I am afraid that won't help for the case of link change,
> > i.e. when a host actually moves to a new link.
>
> [BA] I would say "not previously visited link".

ok. that's more precise.

> > According to Simple DNA, when a host moves to a new link,
> > it would receive no solicited NA and
> > should rely on a solicited RA which will arrive after random delay.
> >
> > So if the host has an on-going session, that would likely
> > to be disrupted. unless, by chance,
> > 1) the host happens to visit the currently attached link some time ago,
> > 2) has kept the link's information even after it detached from it and
> > 3) sends a NS to one of its routers with the preserved information.
>
> [BA] Steps 1-3 are at the core of DNAv4, in which the host may
> probe for any valid address.  This approach was based on the
> observation that most mobile hosts move between a stable
> set of links over the course of the day, which often they
> have previously visited.  As a result, they often have a valid
> address, yet existing TCP/IP stacks discard this address as
> soon as the host leaves the link.

thanks for your clarification. I had assumed that the case of Steps 1-3
is not common, whereas you assume it is.

> Since additional unicast NS/NA exchanges are inexpensive,
> DNAv4 does not restrict the host to only probing for 2 networks,
> because we found that it is often common for a host to have 3
> or more valid addresses on various links (e.g. home, work,
> hotspot).

ok. However, I wish we use the term 'valid address' in more clear
and precise way, lest there should be confusion.

The term 'valid address' may mean
1) an address which a host can use on the currently attached link or
2) an address with valid lifetime.

> [BA] I don't understand why "token bucket" control is necessary.   I think
> the draft needs more discussion of the potential address duplication issues,
> so that we can understand the importance of Tentative Option support.

ok.

> In Simple DNA, only a valid address can be reconfirmed, so that DAD
> had previously completed.  However, there may be circumstances in
> which another host had taken the address and completed DAD while
> the mobile host was away or asleep.   This could, for example,
> happen in the case of privacy addresses.   DNAv4 specification
> also mentions the case of a non-conformant DHCP server
> (Section 2).  I would suggest a section on Duplicate Address
> Detection be added to go over this.

ok.

> One other thing.  DNAv4 talks about confirmation of manually
> assigned addresses.  Is this not also possible in Simple DNA?

Is 'manually assigned address' different from
'statelessly autoconfigured address'?

I assumed that latter includes the former. In case I miss something,
kindly let me know.

Thanks for your kind consideration.

best regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 04 Mar 2008 01:26:58 +0900

Dear Suresh

Thanks to your kind clarification. Now I understand the draft better.

Since the scheme is no longer based on link identification, there
follow some changes. Some previous assumptions won't hold no longer.

Here are my modified concerns.

1. Applicability statement

I understand that
Simple DNA aims to optimize for the common case of
a host moving between a common set of links.

i.e. when a host performs simple DNA operation,
the optimization happens mostly when
1) the host happens to visit the currently attached link some time ago,
2) has kept the link's information even after it detached from it and
3) sends a NS to one of its routers with the preserved information.

Do I understand right?

If so, as Bernard wrote, this approach is based on the observation that
most mobile hosts move between a stable set of links over the course of
the day, which often they have previously visited.

Maybe we'd better mention the above in the applicability section.

2. The term 'valid address'
We need to define & use the term 'valid address' in more precise & clear way.

The term 'valid address' may mean two different things.

1) An address which a host can use on the currently attached link.
2) An address which has valid lifetime left, i.e. non-zero lifetime.

The fist is a proper subset (but not equal) of the second.

The first depends on where the host is currently attached,
whereas,
the second is independent of the host's current Point of Attachment.

Because now a host keeps addresses with non-zero life time,
even after it moved to another link,
I propose to make a clear distinction between two,
unless there should be a confusion.

For example, the following expression in 3.4. confused me.

                                           The host SHOULD NOT send
   unicast Neighbor Solicitations to a test node corresponding to an
   IPv6 address that is no longer valid.

3. Deactivating 'Valid address'

If a host moves to a different link,
it should stop using its existing IP addresses,
even though they still have non-zero lifetime.

DNA needs a procedure to deactivate (i.e. stop using) existing addresses.

Previously DNA deactivated (dumped) the existing addresses,
when a link change is confirmed.

Because now DNA is no longer perform link identification,
I wonder how a simple DNA deactivates existing addresses?
i.e. when a simple DNA host stop using the existing addresses?

I understand that
Simple DNA address table (SDAT) includes both types of valid addresses
1) addresses which the host can use on the currently attached link and
2) addresses which the host can't, while they still have valid lifetime.

In my opinion, SDAT may need to distinguish those two kinds of addresses,
for example with flags.

Then a DNA host can deactivate existing addresses,
when one of the second class addresses is confirmed with NS/ NA exchange.

4. DHCPv6 address
To which router does a DNA host send an NS to confirm an DHCPv6 address?

In current SDAT form, for DHCPv6 address, only DUID is recorded.

5. Not previously visited link
I wish the draft describe in more detail the case
when a host moves in to a 'not previously visited link'.

For example, when a host receives un unknown prefix from an unknown router,
shall the host immediately configure a new address with the address
and send a BU (in case of MIPv6) or
wait still further for a might-be reply from a known node?

Kindly find my in-line comments.

>  > From the draft, it's not clear to me, among above two,
>  > which simple DNA aim to.
>
>  It is the latter. The node verifies viability of a set of addresses it
>  owns by verifying the reachability of the router that advertised the
>  corresponding prefixes.

ok. I propose to put into the draft the paragraphs about DHCPv6 addresses.

>  > 4. Router Modification
>  >
>  > The draft says that simple DNA assumes no router change. Is it
>  > necessary? Previously router modification had been allowed.
>  >
>  > Moreover simple DNA draft mandates that routers MUST support Tentative
>  > Option and mentions token bucket control. Isn't it a router change?
>
>  I don't think we need token bucket control. But the idea is that
>  tentative options are required for oDAD and hence independent of DNA

ok, without token bucket control, we can make the draft simpler.

best regards

JinHyeock

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 03 Mar 2008 12:04:58 -0500

Hi Jin,
   Please find responses inline.

> 3) sends a NS to one of its routers with the preserved information.

Yes. This is correct.

> Maybe we'd better mention the above in the applicability section.

OK.

> unless there should be a confusion.

In the draft, the term "valid address" refers to option 2)

>    IPv6 address that is no longer valid.

This sentence means that "if there is an address stored in the SDAT, and 
the valid lifetime has passed, do not send an NS to check for the 
router's reachability".

> 2) addresses which the host can't, while they still have valid lifetime.

Correct.

> In my opinion, SDAT may need to distinguish those two kinds of addresses,

Not really. When a link change occurs, the host will consider all the 
addresses to be type 2). i.e. None of the addresses in the table are 
usable until confirmed usable.

> when one of the second class addresses is confirmed with NS/ NA exchange.

You mean activate instead of deactivate, right? If so, the answer is yes.

> In current SDAT form, for DHCPv6 address, only DUID is recorded.

The DHCPv6 operation is not specified in the draft. It is only for 
future proofing the table.

> wait still further for a might-be reply from a known node?

This is my subjective take on this. Feel free to disagree. The idea of 
the NS/NA exchange is to complete BEFORE the RA arrives. If an RA 
arrives before the NA, the host will configure an address out of the RA 
and send a BU. Note that this does not mean that, the other yet to be 
confirmed addresses are invalid. An NA that arrives after the RA will 
still confirm the address as usable. I think I can add some text to make 
it clearer.

Cheers
Suresh

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 03 Mar 2008 20:04:21 -0800

> future proofing the table.

[BA] Can't Simple DNA confirm a DHCPv6-assigned address?  That seems like a 
useful thing to be able to handle -- and the current draft can address that case, no? 

> still confirm the address as usable. I think I can add some text to make 

Yes, this seems like a reasonable approach.  In DNAv4 we said that if
the alternative method (in that case, DHCP) arrived first, we would stop
retransmitting probes (and presumably ignore probe responses).   I'd
say the same thing about DHCPv6, by the way.  If the DHCPv6 response
comes back before a probe response, then just configure the address
and stop the probes.

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 04 Mar 2008 21:01:49 +0900

Dear Suresh

Thanks for your clarification. I think we're almost there. :-)

Kindly fine my inline comments.

>  owns by verifying the reachability of the router that advertised the

I forgot a few questions.

First, I assume that the expression 'verify VIABILITY of an address' means

'determine whether a host can use the address on the currently attached link'.

Second, I assume that
a DNA host verifies the viability of each address INDIVIDUALLY or
INDEPENDENTLY,
i.e.
the viability of one address doesn't imply
the viability of another address (or its negation).

In case I misunderstand, kindly let me know.

Then I have two questions.

1. How does simple DNA verifies an address with DHCPv6?

There may be no router associated with the corresponding address.

IMO, it's better for simple DNA to deal with DHCPv6 addresses also
and the simplest way may be
1) associate a DHCPv6 address with one of default routers and
2) verify its viability by confirming the reachability with the router.

2. How does a simple DNA verify other IP configuration parameters
such as prefix or MTU.

Previously link identification verifies all IP configuration parameters
in one stroke.
i.e.
If a host remains at the same link, its all IP configuration are still valid,
If not, it's all IP configuration are invalid.

Because now simple DNA verifies only addresses,
it's not clear to me how a host would verify other parameters.

>  In the draft, the term "valid address" refers to option 2)

I have an impression that, in the existing documents,
the term 'valid address' mostly refers option 1).

Even in Sec 3 of simple DNA, the term 'valid' is used as below.

   When the link-layer becomes available again, it is important to
   determine whether the existing addressing and routing configuration
   are still valid.

'valid' in the above seems to refer option 1).

So I don't feel comfortable using 'valid' as option 2).

Instead I propose that we use
'valid address' for option 1) and 'address with non-zero lifetime' for
option 2).

Also it would be better for the draft to define option 1) & option 2)
in a clear & explicit way.

While working on DNA, I got burned much from the confusion surrounding
the term 'link' and became almost paranoia about unclear definitions.
The experience taught me 'a term which can confuse will'. :-)

>  the valid lifetime has passed, do not send an NS to check for the

We can make matters simpler by stating that

"SDAT only stores an address with valid lifetime.
When the valid life time expires, SDAT omits the address".

Then we don't have to worry about sending an NS for expired address
and entailing paragraphs.

>  usable until confirmed usable.

ok. I think 'a link change occurs' in the above is an error.

Let me rephrase it as below.
when a link-layer indication occurs to initiate DNA procedures,
a DNA host will consider all the address to be type 2) and stop using them,
until each address is verified by NS/ NA exchange with an associated router.

In this sense, a simple DNA host deactivates all its existing addresses
upon DNA initiation.

>  You mean activate instead of deactivate, right? If so, the answer is yes.

I meant 'deactivate' but we don't have to worry about this anymore
because your explanation above made this irrelevant.

>  future proofing the table.

IMO, simple DNA would better provide a way to
verify an address configured with DHCPv6.

>  and send a BU.

ok. this is reasonable. I agree.

>  Note that this does not mean that, the other yet to be

ok. thanks for your trouble.

best regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 04 Mar 2008 21:02:23 +0900

Dear Bernard

> useful thing to be able to handle --

agree.

> and the current draft can address that
> case, no?

I am not sure.

> comes back before a probe response, then just configure the address

agree.

best regards

JinHyeock

---

From: [email-masked]
Date: Mon, 03 Mar 2008 09:18:30 -0800

> how long shall the host wait? A second?

[BA] This is a good question -- and one I think that the draft should
answer.

> is not common, whereas you assume it is.

[BA] Perhaps it would be useful for the Applicability section to discuss
this assumption and the situations in which it would be valid (and not
valid).

For example, if we are talking about a vehicle moving on a highway,
the assumption might not be valid, whereas if we are talking about
a consumer who frequently moves from the home, a work office to
the (same) coffee shop, then it would be.

> 2) an address with valid lifetime.

[BA] I agree that the term needs to be defined in the terminology section.
In DNAv4, the term "operable address" is used, with the following 
definition:

"   Operable address
      In this specification, the term "operable address" refers either
      to a static IPv4 address, or an address assigned via DHCPv4 that
      has not been returned to the DHCP server via a DHCP RELEASE
      message, and whose lease has not yet expired."

This seems close to 2) above.

> Is 'manually assigned address' different from 'statelessly autoconfigured 
> address'?
>

[BA] As used in DNAv4, the term "manually assigned" meant an address that 
was fixed
and not assigned via DHCPv4.    So the question is whether such a concept 
makes sense
for DNAv6.  As Suresh noted, if we assume that it only makes sense to assign 
an address
that is valid given the advertised prefixes,  then the handling of a 
"manual" address would
not be very different from a "statelessly autoconfigured address", assuming 
that it is placed
into the address cache with an infinite lifetime.

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 11 Mar 2008 19:30:07 +0900

Dear Bernard

Please find my inline comments.

>  [BA] This is a good question -- and one I think that the draft should

Suresh already kindly answered as

to which I agreed as below

and you also agreed.

So I assume that we all agreed to 'immediate new address configuration
& BU sending'.

>  This seems close to 2) above.

It would be useful (or maybe indispensable) to define the term explicitly.

I feel uncomfortable using the term 'valid address' as 2). I have an
impression that, in the existing documents, the term 'valid address'
mostly refers 1).

So I already proposed that we use 'valid address' for option 1) and
'address with non-zero lifetime' for option 2).

best regards

JinHyeock