Subject: [dna] Comments on Simple DNA

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 12 Aug 2008 02:09:23 +0900

Dear Suresh & Greg

Here are the issues I mentioned during Dublin meeting. I post them
before I lose them.

1. Verification of IP address per router.
Previously DNA relied on link identification. So a host verifies all
addresses (and IP parameters) at a stroke. However Simple DNA aims to
verify IP address (and IP parameter) per router. I propose we write
down the change clearly.

2. Verification procedure
I have difficulty grasping the exact verification procedure. If you
provide pseudocode as Sathya did in Sec 5.2.6.1. of DNAv6, that would
be of help.

3. Two kinds of IP addresses
Simple DNA host should keep both operable and valid IPv6 addresses.
Their meaning are much different, so we'd better take more care with
the terms such as 'valid' or existing'. For example, in abstract, it's
written that

   Detecting Network Attachment allows hosts to assess if its existing
   addressing or routing configuration is valid From [email-masked]  Mon Aug 11 10:09:32 2008
Date: Tue, 12 Aug 2008 02:09:23 +0900
From: "JinHyeock Choi" <[email-masked]>
Cc: [email-masked]
Subject: [dna] Comments on Simple DNA
Sender: [email-masked]

Dear Suresh & Greg

Here are the issues I mentioned during Dublin meeting. I post them
before I lose them.

1. Verification of IP address per router.
Previously DNA relied on link identification. So a host verifies all
addresses (and IP parameters) at a stroke. However Simple DNA aims to
verify IP address (and IP parameter) per router. I propose we write
down the change clearly.

2. Verification procedure
I have difficulty grasping the exact verification procedure. If you
provide pseudocode as Sathya did in Sec 5.2.6.1. of DNAv6, that would
be of help.

3. Two kinds of IP addresses
Simple DNA host should keep both operable and valid IPv6 addresses.
Their meaning are much different, so we'd better take more care with
the terms such as 'valid' or existing'. For example, in abstract, it's
written that

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

However, I assume, you meant that "host assess whether its addresses
are operable" because it only have to check prefix lifetime to assess
whether an address is valid.

4. Applicability statement
Please write down that simple DNA is to optimize for visiting
previously attached link.

Thanks for your kind consideration.

best regards

JinHyeock
_______________________________________________
dna mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dna

newly connected
   network.

However, I assume, you meant that "host assess whether its addresses
are operable" because it only have to check prefix lifetime to assess
whether an address is valid.

4. Applicability statement
Please write down that simple DNA is to optimize for visiting
previously attached link.

Thanks for your kind consideration.

best regards

JinHyeock
_______________________________________________
dna mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dna

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 12 Aug 2008 17:59:07 -0700

Some other comments: 

I believe that the documents needs a detailed description of the contents of
ND and RS packets (such as included options,  
and source/dest addresses).   For example, I believe ND packets are sent to
the unicast linkscope address of the router, 
not a multicast address, whereas RS packets are sent to a multicast address.

2. Separation of DAD advice for DHCPv6 and stateless auto-config.  During
the meeting, it was said that the document
mentioned that DAD was not needed for still-valid DHCPv6 obtained addresses,
but on reading the document, I could not 
find this statement (or a section specifically about behavior with
DHCPv6-obtained addresses).  I think there may also
be a need for a statement about DHCP config override (even if stateless
autoconfig is used, and the RS and ND determination
are in agreement, DHCPv6 config could still override portions of the
configuration). 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
JinHyeock Choi
Sent: Monday, August 11, 2008 10:09 AM
Cc: [email-masked]
SFrom [email-masked]  Tue Aug 12 17:59:12 2008
From: "Bernard Aboba" <[email-masked]>
To: "'JinHyeock Choi'" <[email-masked]>
Date: Tue, 12 Aug 2008 17:59:07 -0700
Cc: [email-masked]
Subject: Re: [dna] Comments on Simple DNA
Sender: [email-masked]

Some other comments: 

I believe that the documents needs a detailed description of the contents of
ND and RS packets (such as included options,  
and source/dest addresses).   For example, I believe ND packets are sent to
the unicast linkscope address of the router, 
not a multicast address, whereas RS packets are sent to a multicast address.

2. Separation of DAD advice for DHCPv6 and stateless auto-config.  During
the meeting, it was said that the document
mentioned that DAD was not needed for still-valid DHCPv6 obtained addresses,
but on reading the document, I could not 
find this statement (or a section specifically about behavior with
DHCPv6-obtained addresses).  I think there may also
be a need for a statement about DHCP config override (even if stateless
autoconfig is used, and the RS and ND determination
are in agreement, DHCPv6 config could still override portions of the
configuration). 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
JinHyeock Choi
Sent: Monday, August 11, 2008 10:09 AM
Cc: [email-masked]
Subjectubject: [dna] Comments on Simple DNA

Dear Suresh & Greg

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

best regards

JinHyeock

: [dna] Comments on Simple DNA

Dear Suresh & Greg

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

best regards

JinHyeock

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 13 Aug 2008 18:27:39 +0900

Dear Bernard

in-line comments.

> not a multicast address, whereas RS packets are sent to a multicast address.

agree. that would help to clarify the procedures.

> but on reading the document, I cFrom [email-masked]  Wed Aug 13 02:28:02 2008
Date: Wed, 13 Aug 2008 18:27:39 +0900
From: "JinHyeock Choi" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dna] Comments on Simple DNA
Sender: [email-masked]

Dear Bernard

in-line comments.

> not a multicast address, whereas RS packets are sent to a multicast address.

agree. that would help to clarify the procedures.

> but on reading the document, I could nould not
> DHCPv6-obtained addresses).

In theory, DAD is needed even for a valid DHCPv6 obtained address.

As of RFC 4862,

               Both
    stateless address autoconfiguration and DHCPv6 may be used
    simultaneously.

So when a host with a DHCP address detaches for a while,
during the host's absence, it's possible (while not likely) that
another host may configure the same address in stateless
address autoconfiguration.

I guess that's why RFC 4862 mandates DAD
even for DHCP addresses as below

                                                                The Duplicate
   Address Detection algorithm is performed on all addresses,
   independently of whether they are obtained via stateless
   autoconfiguration or DHCPv6.

IMO simple DNA would better not delve into DAD problem too much
lest it should become simple no more.

best regards

JinHyeock

ot
> DHCPv6-obtained addresses).

In theory, DAD is needed even for a valid DHCPv6 obtained address.

As of RFC 4862,

               Both
    stateless address autoconfiguration and DHCPv6 may be used
    simultaneously.

So when a host with a DHCP address detaches for a while,
during the host's absence, it's possible (while not likely) that
another host may configure the same address in stateless
address autoconfiguration.

I guess that's why RFC 4862 mandates DAD
even for DHCP addresses as below

                                                                The Duplicate
   Address Detection algorithm is performed on all addresses,
   independently of whether they are obtained via stateless
   autoconfiguration or DHCPv6.

IMO simple DNA would better not delve into DAD problem too much
lest it should become simple no more.

best regards

JinHyeock

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 13 Aug 2008 18:22:59 -0700

JinHyeock said:

"In theory, DAD is needed even for a valid DHCPv6 obtained address.

As of RFC 4862,
          
    Both stateless address autoconfiguration and DHCPv6 may be used
    simultaneously.

I guess that's why RFC 4862 mandates DAD even for DHCP addresses as below"

   The Duplicate Address Detection algorithm is performed on all addresses,
   independently of whether they are obtained via stateless
   autoconfiguration or DHCPv6.

IMO simple DNA would better not delve into DAD problem too much
lest it should become simple no more."

During the meeting we discussed the circumstances under which DAD could be
avoided.  I agree that simple DNA should not get into the details too much,
but it would be good to have some guidance on wheFrom [email-masked]  Wed Aug 13 18:23:24 2008
From: "Bernard Aboba" <[email-masked]>
To: "'JinHyeock Choi'" <[email-masked]>
Date: Wed, 13 Aug 2008 18:22:59 -0700
Cc: [email-masked]
Subject: Re: [dna] Comments on Simple DNA
Sender: [email-masked]

JinHyeock said:

"In theory, DAD is needed even for a valid DHCPv6 obtained address.

As of RFC 4862,
          
    Both stateless address autoconfiguration and DHCPv6 may be used
    simultaneously.

I guess that's why RFC 4862 mandates DAD even for DHCP addresses as below"

   The Duplicate Address Detection algorithm is performed on all addresses,
   independently of whether they are obtained via stateless
   autoconfiguration or DHCPv6.

IMO simple DNA would better not delve into DAD problem too much
lest it should become simple no more."

During the meeting we discussed the circumstances under which DAD could be
avoided.  I agree that simple DNA should not get into the details too much,
but it would be good to have some guidance on when to dn to do DAD and when it
can be skipped. 

o DAD and when it
can be skipped.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 27 Aug 2008 18:14:35 -0400

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

> verify IP address (and IP parameter) per router. I propose we write

OK. I agree with you about writing down the purpose of simple dna but I 
am not sure if we want to talk about a change. Simple dna has always 
been about this.

> provide pseudocode as Sathya did in Sec 5.2.6.1. of DNAv6, that would

OK.

> However, I assumFrom [email-masked]  Wed Aug 27 15:09:44 2008
Date: Wed, 27 Aug 2008 18:14:35 -0400
From: Suresh Krishnan <[email-masked]>
To: JinHyeock Choi <[email-masked]>
Cc: [email-masked]
Subject: Re: [dna] Comments on Simple DNA
Sender: [email-masked]

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

> verify IP address (and IP parameter) per router. I propose we write

OK. I agree with you about writing down the purpose of simple dna but I 
am not sure if we want to talk about a change. Simple dna has always 
been about this.

> provide pseudocode as Sathya did in Sec 5.2.6.1. of DNAv6, that would

OK.

> However, Ie, you meant that "host assess whether its addresses

Yes. I will will fix this.

> previously attached link.

I will propose text to the mailing list for this.

Thanks
Suresh

 assume, you meant that "host assess whether its addresses
> whether an address is valid.

Yes. I will will fix this.

> previously attached link.

I will propose text to the mailing list for this.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 28 Aug 2008 19:22:27 -0400

Hi Bernard,
   Thanks for your comments. Please see responses inline.

> not a multicast address, whereas RS packets are sent to a multicast address.

OK. Sounds like a great idea. I will include this in the next revision

> are in agreement, DHCPv6 config could still override portions of the

I was assuming that the host will follow 4861 behavior if nothing is 
specified in the document. Would you like a strong From [email-masked]  Thu Aug 28 16:17:26 2008
Date: Thu, 28 Aug 2008 19:22:27 -0400
From: Suresh Krishnan <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: [dna] Comments on Simple DNA
Sender: [email-masked]

Hi Bernard,
   Thanks for your comments. Please see responses inline.

> not a multicast address, whereas RS packets are sent to a multicast address.

OK. Sounds like a great idea. I will include this in the next revision

> are in agreement, DHCPv6 config could still override portions of the

I was assuming that the host will follow 4861 behavior if nothing is 
specified in the document. Would you like a srecommendation in the 
draft for this. I was just going to mention that DAD may not be 
necessary if the host was detached from the link for a short period of 
time (with no differentiation between addresses obtained using DHCPv6 or 
SLAAC). Do you have issues with such text?

Thanks
Suresh

trong recommendation in the 
draft for this. I was just going to mention that DAD may not be 
necessary if the host was detached from the link for a short period of 
time (with no differentiation between addresses obtained using DHCPv6 or 
SLAAC). Do you have issues with such text?

Thanks
Suresh

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 28 Aug 2008 22:45:22 -0700

Suresh said:

"I was assuming that the host will follow 4861 behavior if nothing is 
specified in the document. Would you like a strong recommendation in the 
draft for this. I was just going to mention that DAD may not be 
necessary if the host was detached from the link for a short period of 
time (with no differentiation between addresses obtained using DHCPv6 or 
SLAAC). Do you have issues with such text?"

In the case of DHCPv6-based address assignment, can't host may be detached
from the link until the lease expires? At least that's the advice provided
in the DNAv4 document.

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 28 Aug 2008 22:45:22 -0700

Suresh said: