Hi Folks,
   We have submitted a new version of the simple dna
protocol. The new 
draft addresses significant issues raised by Bernard Aboba,
Jin-hyeock 
Choi and Thomas Narten. Please take a look and send comments
to the list 
or to us personally. We would like to discuss this draft at
the dna wg 
meeting in Philly.

Thanks
Suresh


-------- Original Message --------
Subject: I-D Action:draft-krishnan-dna-simple-03.txt
Date: Wed, 27 Feb 2008 08:30:01 -0800 (PST)
From: Internet-Draftsietf.org
Reply-To: internet-draftsietf.org
To: i-d-announceietf.org

A New Internet-Draft is available from the on-line
Internet-Drafts 
directories.

	Title           : Simple procedures for Detecting Network
Attachment in 
IPv6
	Author(s)       : S. Krishnan, G. Daley
	Filename        : draft-krishnan-dna-simple-03.txt
	Pages           : 13
	Date            : 2008-02-25

Detecting Network Attachment allows hosts to assess if its
existing
addressing or routing configuration is valid for a newly
connected
network.

This document provides simple procedures for detecting
network
attachment in IPv6 hosts, and procedures for routers to
support such
services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kr
ishnan-dna-simple-03.txt

To remove yourself from the I-D Announcement list, send a
message to
i-d-announce-requestietf.org with the word unsubscribe in the
body of
the message.
You can also visit h
ttps://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login
with the
username "anonymous" and a password of your e-mail
address. After
logging in, type "cd internet-drafts" and then
	"get draft-krishnan-dna-simple-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/s
hadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailservietf.org.
In the body type:
	"FILE
/internet-drafts/draft-krishnan-dna-simple-03.txt".

NOTE:   The mail server at ietf.org can return the document
in
	MIME-encoded form by using the "mpack" utility. 
To use this
	feature, insert the command "ENCODING mime"
before the "FILE"
	command.  To decode the response(s), you will need
"munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant
mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which
have been split
	up into multiple messages), so check your local
documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail
reader
implementation to automatically retrieve the ASCII version
of the
Internet-Draft.

Dear Suresh & Greg

Thanks for your trouble updating the draft. However, I can't
but confess
that I'm still confused.

Here are my main concerns.

1. Link identification or not?

I kept assuming that DNA would be based on link
identification,
i.e. to verify whether a DNA host remains in the same link
or not.

Whereas recently Bernard expressed an opinion that
the assumption might not hold for simple DNA as below.

   "One question for simple DNA is whether we are
attempting to determine
   a "link" or just connectivity to a particular
router interface.
This is a subtle,
   but potentially important difference.  My impression had
been that the goal
   was the latter."

>From the draft, it's not clear to me, among above two,
which simple DNA aim to.

Kindly clarify whether simple DNA is based on link
identification or not.

2. Link identification mechanism.

If simple DNA is based on link identification,
the link identification mechanism is not clear to me.

Link identification mechanism is mostly described in Sec
3.5
but it only listed the cases when
1) a solicited NA from a known test node arrives,
2) a solicited RA with a known prefix arrives
  (it's not clear whether the RA should come from a known
router or not)
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 un unknown
router arrives
(which may occur the most in link change case.)

If you provide pseudocode as Sathya did in Sec 5.2.6.1. of
DNAv6,
that would be of help.

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.

IMO, DNA optimization is needed the most for such link
change case,
because then the host no longer has a valid IP address and
should configure a new address as soon as possible
lest there should be communication disruption.

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.

I think DNA optimization should provide some improvement
for the case of link change.  From that viewpoint, I am not
sure of
the suitability of NS/ NA based improvement.

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?

Thanks for your kind consideration.

best regards

JinHyeock


> On Thu, Feb 28, 2008 at 8:36 AM, Suresh Krishnan
<suresh.krishnanericsson.com> wrote:
>
> Hi Folks,
>    We have submitted a new version of the simple dna
protocol. The new
>  draft addresses significant issues raised by Bernard
Aboba, Jin-hyeock
>  Choi and Thomas Narten. Please take a look and send
comments to the list
>  or to us personally. We would like to discuss this
draft at the dna wg
>  meeting in Philly.
>
>  Thanks
>  Suresh
>
>
>  -------- Original Message --------
>  Subject: I-D Action:draft-krishnan-dna-simple-03.txt
>  Date: Wed, 27 Feb 2008 08:30:01 -0800 (PST)
>  From: Internet-Draftsietf.org
>  Reply-To: internet-draftsietf.org
>  To: i-d-announceietf.org
>
>  A New Internet-Draft is available from the on-line
Internet-Drafts
>  directories.
>
>         Title           : Simple procedures for
Detecting Network Attachment in
>  IPv6
>         Author(s)       : S. Krishnan, G. Daley
>         Filename        :
draft-krishnan-dna-simple-03.txt
>         Pages           : 13
>         Date            : 2008-02-25
>
>  Detecting Network Attachment allows hosts to assess if
its existing
>  addressing or routing configuration is valid for a
newly connected
>  network.
>
>  This document provides simple procedures for detecting
network
>  attachment in IPv6 hosts, and procedures for routers
to support such
>  services.
>
>  A URL for this Internet-Draft is:
>  http://www.ietf.org/internet-drafts/draft-kr
ishnan-dna-simple-03.txt
>
>  To remove yourself from the I-D Announcement list,
send a message to
>  i-d-announce-requestietf.org with the word
unsubscribe in the body of
>  the message.
>  You can also visit h
ttps://www1.ietf.org/mailman/listinfo/I-D-announce
>  to change your subscription settings.
>
>  Internet-Drafts are also available by anonymous FTP.
Login with the
>  username "anonymous" and a password of your
e-mail address. After
>  logging in, type "cd internet-drafts" and
then
>         "get
draft-krishnan-dna-simple-03.txt".
>
>  A list of Internet-Drafts directories can be found in
>  http://www.ietf.org/s
hadow.html
>  or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>  Internet-Drafts can also be obtained by e-mail.
>
>  Send a message to:
>         mailservietf.org.
>  In the body type:
>         "FILE
/internet-drafts/draft-krishnan-dna-simple-03.txt".
>
>  NOTE:   The mail server at ietf.org can return the
document in
>         MIME-encoded form by using the
"mpack" utility.  To use this
>         feature, insert the command "ENCODING
mime" before the "FILE"
>         command.  To decode the response(s), you will
need "munpack" or
>         a MIME-compliant mail reader.  Different
MIME-compliant mail readers
>         exhibit different behavior, especially when
dealing with
>         "multipart" MIME messages (i.e.
documents which have been split
>         up into multiple messages), so check your local
documentation on
>         how to manipulate these messages.
>
>  Below is the data which will enable a MIME compliant
mail reader
>  implementation to automatically retrieve the ASCII
version of the
>  Internet-Draft.
>
>
> _______________________________________________
>  I-D-Announce mailing list
>  I-D-Announceietf.org
>  ht
tps://www.ietf.org/mailman/listinfo/i-d-announce
>
>
>

Hi Jin,
   Thanks for the comments. Please find responses inline.

JinHyeock Choi wrote:
> Dear Suresh & Greg
> 
> Thanks for your trouble updating the draft. However, I
can't but confess
> that I'm still confused.
> 
> Here are my main concerns.
> 
> 1. Link identification or not?
> 
> I kept assuming that DNA would be based on link
identification,
> i.e. to verify whether a DNA host remains in the same
link or not.
> 
> Whereas recently Bernard expressed an opinion that
> the assumption might not hold for simple DNA as below.
> 
>    "One question for simple DNA is whether we are
attempting to determine
>    a "link" or just connectivity to a
particular router interface.
> This is a subtle,
>    but potentially important difference.  My impression
had been that the goal
>    was the latter."
> 
> 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.

> 
> Kindly clarify whether simple DNA is based on link
identification or not.
> 

I would say no.

> 2. Link identification mechanism.
> 
> If simple DNA is based on link identification,
> the link identification mechanism is not clear to me.
> 
> Link identification mechanism is mostly described in
Sec 3.5
> but it only listed the cases when
> 1) a solicited NA from a known test node arrives,
> 2) a solicited RA with a known prefix arrives
>   (it's not clear whether the RA should come from a
known router or not)
> 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 un
unknown router arrives
> (which may occur the most in link change case.)
> 
> If you provide pseudocode as Sathya did in Sec 5.2.6.1.
of DNAv6,
> that would be of help.

OK. Will do.

> 
> 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.
> 
> IMO, DNA optimization is needed the most for such link
change case,
> because then the host no longer has a valid IP address
and
> should configure a new address as soon as possible
> lest there should be communication disruption.
> 
> 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.

Yes. Your understanding is correct.

> 
> I think DNA optimization should provide some
improvement
> for the case of link change.  From that viewpoint, I am
not sure of
> the suitability of NS/ NA based improvement.

As discussed above, the improvement results from the NS/NA
exchange. The 
goal is to be no slower than standard NS behavior and
optimize for the 
use cases where possible.

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

Thanks
Suresh

Hi Bernard,
   Please find comments inline.

Bernard Aboba wrote:
> 
>  > I think DNA optimization should provide some
improvement
>  > for the case of link change. From that viewpoint,
I am not sure of
>  > the suitability of NS/ NA based improvement.
> 
> [BA] I would agree that Simple DNA should handle
common
> link change cases at least as well as DNAv4 does. 
Overall,
> I think that this issue points out the need for an
> "Applicability" section in the Simple DNA
specification, similar
> to that in DNAv4 Section 1.1, in order to point out
exactly
> what the goals of Simple DNA are, and which cases it
> can handle.

I will add an applicability section in the next revision.

> 
>  > 4. Router Modification
>  >
>  > The draft says that simple DNA assumes no router
change. Is it
>  > necessary? Previously router modification had
been allowed.
> 
> [BA] Within DNAv4, the goal was first to "do no
harm" -- no degradation
> if the router did not support unicast ARP.  The second
goal was to
> "optimize for the common case" of a host
moving between a common set of
> links.  So my opinion would be that Simple DNA should
have a similar goal:
> never worse than today, and better in the common case
(common router
> behavior).

Yes. This is my understanding as well. I think I will
clarify this in 
the Applicability section.

> 
>  > Moreover simple DNA draft mandates that routers
MUST support Tentative
>  > Option and mentions token bucket control. Isn't
it a router change?
> 
> [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.
> 
> 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.

I will add a section on DAD issues.

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

I am not sure how we can confirm a manually assigned
address. Thinking 
aloud, we can associate a manually assigned address with a
prefix 
announced by a router and confirm using the reachability of
the router. 
Does that sound reasonable to you?

Thanks
Suresh

Hi Bernard,

Bernard Aboba wrote:
>  > I am not sure how we can confirm a manually
assigned address. Thinking
>  > aloud, we can associate a manually assigned
address with a prefix
>  > announced by a router and confirm using the
reachability of the router.
>  > Does that sound reasonable to you?
> 
> Yes.  Also if NA does not appear, but RA does
(confirming the
> prefix used in the manual address) that should be ok
too, no?

Receiving an RA confirming a prefix should be OK too. Do we
have to 
handle this (manual addresses) as a specific case? I was
thinking of 
just including text in the document specifying adding an
entry into the 
DNA address table for this manually assigned address along
with the 
associated prefix and the router from which we heard the
prefix. 
Everything else should work fine after this.

Thanks
Suresh

> Receiving an RA confirming a prefix should be OK too.
Do we have to 
> handle this (manual addresses) as a specific case? I
was thinking of 
> just including text in the document specifying adding
an entry into the 
> DNA address table for this manually assigned address
along with the 
> associated prefix and the router from which we heard
the prefix. 
> Everything else should work fine after this.

Putting the manual address into the DNA address table is
fine.  
With respect to Simple DNA, I think that handling of manual
addresses
is actually simpler than it was with DNAv4. 

In working on DNAv4, there was a concern about the 
implications for probe retransmission.  Normally a unicast
ARP 
probe might be sent only once or twice.  For a dynamic
address 
this was not such a big deal, since other mechanisms (e.g.
DHCPv4) 
were running simultaneously and they would retransmit; as a
result,
the host would be likely to get an address as long as the
DHCP server
was up, even if the ARP probes were dropped for some reason.

However, for the manual address case, without probe
retransmission,
failure rates for DNAv4 could be quite high.   For example,
consider a
wireless network with high frame loss and only a single
probe being
sent.  Failure rates of 10% or more could be experienced. 

With Simple DNA, I think the situation is better because
even if the
NS probes are lost, the RS will still be periodically
retransmitted.  So
overall, the probability of a false negative is lower.   

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

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.

Thanks for your kind consideration.

best regards

JinHyeock