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

From: Suresh Krishnan <[email-masked]>
Date: Wed, 27 Feb 2008 18:36:20 -0500

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: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

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-krishnan-dna-simple-03.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://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/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

Send a message to:
	[email-masked].
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
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 29 Feb 2008 22:15:10 +0900

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 <[email-masked]> wrote:
>
> Hi Folks,

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 29 Feb 2008 10:10:36 -0500

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

> From the draft, it's not clear to me, among above two,

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.

> If you provide pseudocode as Sathya did in Sec 5.2.6.1. of DNAv6,

OK. Will do.

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

Yes. Your understanding is correct.

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

> 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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 29 Feb 2008 07:00:46 -0800

> Link identification mechanism is mostly described in Sec 3.5 but it only listed the cases when

[BA] I think it need not come from a known router. 

> when a solicited RA without a known prefix from unknown router arrives

[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.e. when a host actually moves to a new link.

[BA] I would say "not previously visited link". 
 
> lest there should be communication disruption.

[BA] Agreed.  

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

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

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

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

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

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

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 29 Feb 2008 10:26:56 -0500

Hi Bernard,
   Please find comments inline.

> what the goals of Simple DNA are, and which cases it

I will add an applicability section in the next revision.

> never worse than today, and better in the common case (common router

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

> Detection be added to go over this.

I will add a section on DAD issues.

> 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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 29 Feb 2008 07:32:55 -0800

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

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 29 Feb 2008 10:38:19 -0500

Hi Bernard,

> 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

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 29 Feb 2008 11:46:11 -0800

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