From snarayanan@csumb.edu Sat Oct 31 15:50:50 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971CA3A6820 for ; Sat, 31 Oct 2009 15:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvLBwoIiokrL for ; Sat, 31 Oct 2009 15:50:48 -0700 (PDT) Received: from exprod5og113.obsmtp.com (exprod5og113.obsmtp.com [64.18.0.26]) by core3.amsl.com (Postfix) with SMTP id 3D9F23A680F for ; Sat, 31 Oct 2009 15:50:48 -0700 (PDT) Received: from source ([209.85.223.175]) by exprod5ob113.postini.com ([64.18.4.12]) with SMTP ID DSNKSuy/WXVe/xRDRcRhseVcMXoOEvxjunmv@postini.com; Sat, 31 Oct 2009 15:51:07 PDT Received: by iwn5 with SMTP id 5so2923679iwn.11 for ; Sat, 31 Oct 2009 15:51:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.6.153 with SMTP id 25mr1292756ibz.54.1257029465259; Sat, 31 Oct 2009 15:51:05 -0700 (PDT) In-Reply-To: <4AEA0FCE.4000704@piuha.net> References: <4ADE2B90.6060900@ericsson.com> <4AEA0FCE.4000704@piuha.net> From: Sathya Narayanan Date: Sat, 31 Oct 2009 15:50:45 -0700 Message-ID: To: Jari Arkko Content-Type: multipart/alternative; boundary=0015176f03e0bfc009047742fae3 X-Mailman-Approved-At: Mon, 02 Nov 2009 07:23:02 -0800 Cc: DNA , "dna@ietf.org" Subject: Re: [dna] Comments on draft-ietf-dna-protocol X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 23:16:45 -0000 --0015176f03e0bfc009047742fae3 Content-Type: text/plain; charset=ISO-8859-1 Jari Thanks for the detailed comments. I wanted to acknowledge the email and let you know that this is on my to-do list; I will work on incorporating your comments on to the document over the next couple of weeks. Worst case, I will need to move it until Thanksgiving break at which point I am likely to have more time to devote to this. Hope that is alright. best Sathya On Thu, Oct 29, 2009 at 2:57 PM, Jari Arkko wrote: > Sathya, > > Here are a few comments on draft-ietf-dna-protocol. Overall, this is a > complex scheme and having read this again after a long break, I'm now even > more glad that we got the dna-simple document moving forward. However, I > think we should publish even dna-protocol as an RFC. It is an interesting > design worth a permanent record. I do have a long list of comments, though, > and I hope you can publish a new draft version so that the document can be > taken forward. I'm thinking of Historical or Experimental as the proper > designation for the document. > > Detailed comments: > > The document needs to be resubmitted as it is currently expired. > > Design document for Detecting Network Attachment in IPv6 Networks (DNAv6 >> Design) >> >> > Might be better as "Design Alternative for Detecting ..." > > Abstract is too long. Maybe you should just keep this part: > > In this memo, a mechanism > that was developed for detection of network attachment is documented > for future reference. This memo is an informational document and > thus does not define a new standard. The mechanism proposed in this > informational RFC requires the hosts to monitor all the prefixes > advertised on the link and use it for link identification in the > presence of non-DNAv6 routers is presented. A more efficient link- > identification mechanism requiring the DNAv6 routers to monitor the > link for advertised prefixes to assist the hosts in link > identification combined with a fast router advertisement mechanism > that selects the order of response for the router deterministically > is also presented. > > Run spell on the document. > > This memo also defines a mechanism to exchange Source Link-Layer Address >> without affecting the neighbor caches when the host is performing Optimistic >> DAD. >> >> > > Wasn't this already in draft-ietf-dna-tentative? > > Even though this >> document recommends the use of a prefix as the representative of the >> link, future specifications can use the Learned Prefix Option to >> include a non-prefix identifier as long as this identifier is 128 bit >> long to avoid collision with any currently assigned prefix. So, any >> future non-prefix link identifier MUST be 128 bits long. >> 5.1.6.3.1 Using non-prefix identifier as common prefix >> > > I felt that this extensibility confused the document a little bit. Could > this be removed? > > DNAv6 avoids this delay by using a different mechanism to ensure that >> two routers will not respond at exactly the same time while allowing >> one of the routers on the link to respond immediately. The results of >> that function are then compared to create >> a ranking, and the ranking determines the delay each router will use >> when responding to the RS. The router which is ranked as #0 will >> respond with a zero delay. >> >> > > Do I understand correctly that there will still be several responses to a > single RS? Perhaps this should be highlighted. Note that that your scheme > does not provide the same overall limit on the number of RAs appearing on > the link as the rate limit defined in RFC 4861. > > 4.1 New Flags >> >> This document defines two new flags to be exchanged between the >> router and hosts. >> > I'd like to see these flags in the extension option defined in RFC 5075, > not directly in the RA header. > > the following information MUST be stored: >> >> 1. Link-local source address of advertising router >> >> 2. Token equal to the first 64 bits of an SHA-1 hash of the above address >> >> > It seems a bit silly to have a MUST requirement to store X and f(X)... > > Each router MUST include itself in the DNARouterList and generate a >> token for itself as described above based on the link-local address >> used in its RA messages. >> >> > As above. > > an abbreviated Router Advertisement.This abbreviated advertisement >> > > Missing space > > A CompleteRA is formed as follows: >> > > Missing space > > Note that this smallest prefix >> is the smallest of all the prefixes configured on the routers on the >> link and may not be the smallest prefix used in the link through >> stateful address configuration. >> >> > > Although, at least currently, prefixes used even for stateful address > autoconfiguration come from RAs. > > > When a router receives a new prefix in PIO, if the prefix is smaller >> than the current common prefix and has valid lifetime greater than >> LEAST_VALID_LIFETIME, the router selects that new prefix as a new >> common prefix. >> > But it is also possible that the new smallest prefix comes through > configuration in THIS router. In that case it is not the reception of the > PIO that triggers this selection. > > Whenever a router sends an RA, whether solicited or unsolicited, it >> MUST include the common prefix in it. Hence, all RAs MUST carry the >> common prefix except the abbreviated RA message sent in response to a >> RS with LO. >> > > I guess I am missing the point of having BOTH the landmark AND the common > prefix. Is there some difference in use that prevents just selecting one, > and sticking to that? > > And if the RAs responding to LO can skip the common prefix, why is it so > important to include the common prefix in other RAs? Important enough that a > MUST is needed? Or, if the MUST is really needed, is there something that > breaks when use just the landmark option? > > Sinice information from the Learned Prefix Option is only stored in >> > typo > > IF (Receive RA is a CompleteRA) THEN >> >> { >> >> /* We already checked if there are any matching prefix before. >> Since this is a CompleteRA, implies link-change.*/ >> >> Link change has occured. >> >> RETURN; // Don't have to do the following checks. >> >> } >> >> { >> >> Link change has occured. >> >> RETURN; // Don't have to do the following checks. >> >> } --> >> >> IF (DNAHostPrefixList is marked as complete (i.e. the completeness >> criteria is already met)) THEN >> >> > > The code seems broken. Is there an IF missing around the braces above? > There seems to be a RETURN followed by some further code, which does not > make sense. > > Wait for NUM_RS_RA_COMPLETE exchanges of RS/RA message to be done >> since the previous link UP event (Previous link UP event here refers >> to the link UP received before the current link UP event that lead to >> this processing). >> >> IF (One of the received RA contains a prefix matching a prefix in >> DNAHostPrefixList from before the current link UP event), THEN No >> link change has occured ELSE link change has occured. >> >> > > Pseudo-code style changed here. Please use the same style, braces etc. > > Note that this procedure does not prevent a MN from sending packets >> > s/MN/host/ > > > Missing things: I did not see a discussion of how prefixes or routers get > removed from the host or router data structures. > > received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA >> > > It seems weird that you refer to the old 2461 here. Also, is the procedure > presented in Section 5.2.7.3 according to the current understanding of the > M&O bits? > > 6.3 Tentative options >> > If you refer to draft-ietf-dna-tentative, do you need this section? > > SEND says that DAD defenses MAY be accepted even from non SEND nodes >> > > ... according to the SEND specification (RFC 3971 Section N.N) DAD defenses > ... > > SEND says that DAD defenses MAY be accepted even from non SEND nodes >> for the first configured address [4]. >> >> While deconfiguring the address is a valid action in the case where a >> host collides with another address owner after arrival on a new link, >> In the case that the host returns immediately to the same link, such >> a DAD defense NA message may be a denial-of-service attempt. >> >> > It seems that there are two separate cases. I believe 3971 & 3972 still > hold: whenever you create a new address, you should not accept collisions > beyond a certain collision count. However, IF you have confirmed that you > re-attached to the same link... I would not run DAD. > > 10. Informative References >> > > You need to split references to normative and informative. > > [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery >> for IP Version 6 (IPv6)", RFC 2461, December 1998. >> >> > > Refer to the new one instead. > > Jari > > -- Sathya Narayanan mailto://snarayanan@csumb.edu <=== Please note new email address --0015176f03e0bfc009047742fae3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jari

Thanks for the detailed comments.

I wanted to acknowledg= e the email and let you know that this is on my to-do list; I will work on = incorporating your comments on to the document over the next couple of week= s. Worst case, I will need to move it until Thanksgiving break at which poi= nt I am likely to have more time to devote to this. Hope that is alright.
best
Sathya

On Thu, Oct 29, 2009 a= t 2:57 PM, Jari Arkko <jari.arkko@piuha.net> wrote:
Sathya,

Here are a few comments on draft-ietf-dna-protocol. Overall, this is a comp= lex scheme and having read this again after a long break, I'm now even = more glad that we got the dna-simple document moving forward. However, I th= ink we should publish even dna-protocol as an RFC. It is an interesting des= ign worth a permanent record. I do have a long list of comments, though, an= d I hope you can publish a new draft version so that the document can be ta= ken forward. I'm thinking of Historical or Experimental as the proper d= esignation for the document.

Detailed comments:

The document needs to be resubmitted as it is currently expired.

Design document for Detecting Network Attachment in IPv6 Networks (DNAv6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Design)
=A0
Might be better as "Design Alternative for Detecting ..."

Abstract is too long. Maybe you should just keep this part:

=A0In this memo, a mechanism
=A0that was developed for detection of network attachment is documented =A0for future reference. =A0This memo is an informational document and
=A0thus does not define a new standard. =A0The mechanism proposed in this<= br> =A0informational RFC requires the hosts to monitor all the prefixes
=A0advertised on the link and use it for link identification in the
=A0presence of non-DNAv6 routers is presented. =A0A more efficient link- =A0identification mechanism requiring the DNAv6 routers to monitor the
=A0link for advertised prefixes to assist the hosts in link
=A0identification combined with a fast router advertisement mechanism
=A0that selects the order of response for the router deterministically
=A0is also presented.

Run spell on the document.

This memo also defines a mechanism to exchange Source Link-Layer Address wi= thout affecting the neighbor caches when the host is performing Optimistic = DAD.
=A0

Wasn't this already in draft-ietf-dna-tentative?

Even though this
=A0 document recommends the use of a prefix as the representative of the =A0 link, future specifications can use the Learned Prefix Option to
=A0 include a non-prefix identifier as long as this identifier is 128 bit<= br> =A0 long to avoid collision with any currently assigned prefix. =A0So, any=
=A0 future non-prefix link identifier MUST be 128 bits long.
=A05.1.6.3.1 =A0Using non-prefix identifier as common prefix

I felt that this extensibility confused the document a little bit. Could th= is be removed?

=A0 DNAv6 avoids this delay by using a different mechanism to ensure that<= br> =A0 two routers will not respond at exactly the same time while allowing =A0 one of the routers on the link to respond immediately. The results of = that function are then compared to create
=A0 a ranking, and the ranking determines the delay each router will use =A0 when responding to the RS. =A0The router which is ranked as #0 will =A0 respond with a zero delay.
=A0

Do I understand correctly that there will still be several responses to a s= ingle RS? Perhaps this should be highlighted. Note that that your scheme do= es not provide the same overall limit on the number of RAs appearing on the= link as the rate limit defined in RFC 4861.

4.1 =A0New Flags

=A0 This document defines two new flags to be exchanged between the
=A0 router and hosts.
I'd like to see these flags in the extension option defined in RFC 5075= , not directly in the RA header.

the following information MUST be stored:

1. =A0Link-local source address of advertising router

2. =A0Token equal to the first 64 bits of an SHA-1 hash of the above addres= s
=A0
It seems a bit silly to have a MUST requirement to store X and f(X)...

=A0 Each router MUST include itself in the DNARouterList and generate a =A0 token for itself as described above based on the link-local address =A0 used in its RA messages.
=A0
As above.

=A0 an abbreviated Router Advertisement.This abbreviated advertisement

Missing space

=A0 A CompleteRA is formed as follows:

Missing space

Note that this smallest prefix
=A0 is the smallest of all the prefixes configured on the routers on the =A0 link and may not be the smallest prefix used in the link through =A0 = stateful address configuration.
=A0

Although, at least currently, prefixes used even for stateful address autoc= onfiguration come from RAs.


When a router receives a new prefix in PIO, if the prefix is smaller
=A0 than the current common prefix and has valid lifetime greater than
=A0 LEAST_VALID_LIFETIME, the router selects that new prefix as a new
=A0 common prefix. =A0
But it is also possible that the new smallest prefix comes through configur= ation in THIS router. In that case it is not the reception of the PIO that = triggers this selection.

=A0 Whenever a router sends an RA, whether solicited or unsolicited, it =A0 MUST include the common prefix in it. =A0Hence, all RAs MUST carry the=
=A0 common prefix except the abbreviated RA message sent in response to a<= br> =A0 RS with LO.

I guess I am missing the point of having BOTH the landmark AND the common p= refix. Is there some difference in use that prevents just selecting one, an= d sticking to that?

And if the RAs responding to LO can skip the common prefix, why is it so im= portant to include the common prefix in other RAs? Important enough that a = MUST is needed? Or, if the MUST is really needed, is there something that b= reaks when use just the landmark option?

=A0 Sinice information from the Learned Prefix Option is only stored in
typo

=A0 IF (Receive RA is a CompleteRA) THEN

=A0 {

=A0 =A0 =A0/* We already checked if there are any matching prefix before.<= br> =A0 =A0 =A0Since this is a CompleteRA, implies link-change.*/

=A0 =A0 =A0Link change has occured.

=A0 =A0 =A0RETURN; // Don't have to do the following checks.

=A0 }

=A0 {

=A0 =A0 =A0Link change has occured.

=A0 =A0 =A0RETURN; // Don't have to do the following checks.

=A0 } -->

=A0 IF (DNAHostPrefixList is marked as complete (i.e. the completeness
=A0 criteria is already met)) THEN
=A0

The code seems broken. Is there an IF missing around the braces above? Ther= e seems to be a RETURN followed by some further code, which does not make s= ense.

=A0 Wait for NUM_RS_RA_COMPLETE exchanges of RS/RA message to be done
=A0 since the previous link UP event (Previous link UP event here refers =A0 to the link UP received before the current link UP event that lead to<= br> =A0 this processing).

=A0 IF (One of the received RA contains a prefix matching a prefix in
=A0 DNAHostPrefixList from before the current link UP event), THEN No
=A0 link change has occured ELSE link change has occured.
=A0

Pseudo-code style changed here. Please use the same style, braces etc.

=A0 Note that this procedure does not prevent a MN from sending packets
s/MN/host/


Missing things: I did not see a discussion of how prefixes or routers get r= emoved from the host or router data structures.

=A0 received RAs as in Section 5.5.3 of RFC 2461 [3]. =A0That is, if an RA=

It seems weird that you refer to the old 2461 here. Also, is the procedure = presented in Section 5.2.7.3 according to the current understanding of the = M&O bits?

6.3 =A0Tentative options
If you refer to draft-ietf-dna-tentative, do you need this section?

=A0 SEND says that DAD defenses MAY be accepted even from non SEND nodes

... according to the SEND specification (RFC 3971 Section N.N) DAD defenses= ...

SEND says that DAD defenses MAY be accepted even from non SEND nodes
for the first configured address [4].

While deconfiguring the address is a valid action in the case where a
host collides with another address owner after arrival on a new link,
In the case that the host returns immediately to the same link, such
a DAD defense NA message may be a denial-of-service attempt.
=A0
It seems that there are two separate cases. I believe 3971 & 3972 still= hold: whenever you create a new address, you should not accept collisions = beyond a certain collision count. However, IF you have confirmed that you r= e-attached to the same link... I would not run DAD.

10. =A0Informative References

You need to split references to normative and informative.

=A0 [3] =A0 Narten, T., Nordmark, E., and W. Simpson, "Neighbor Disco= very
=A0 =A0 =A0 =A0 for IP Version 6 (IPv6)", RFC 2461, December 1998. =A0

Refer to the new one instead.

Jari




--
Sathya Narayanan=
mailto://snarayanan@csumb.edu <=3D=3D=3D Please note new email address
--0015176f03e0bfc009047742fae3-- From jari.arkko@piuha.net Fri Nov 20 00:39:46 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4833A6A9B; Fri, 20 Nov 2009 00:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ye6fS1UPPT0; Fri, 20 Nov 2009 00:39:45 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 76F173A6A5C; Fri, 20 Nov 2009 00:39:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8CFC8D4931; Fri, 20 Nov 2009 10:39:41 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fsS2BsZ+Lwt; Fri, 20 Nov 2009 10:39:40 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6DBD9D491E; Fri, 20 Nov 2009 10:39:40 +0200 (EET) Message-ID: <4B0655CB.2040309@piuha.net> Date: Fri, 20 Nov 2009 10:39:39 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Suresh Krishnan (QB/EMC)" , "draft-ietf-dna-simple@tools.ietf.org" , Ralph Droms , Lars Eggert Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DNA , "dna@ietf.org" , IESG Subject: [dna] next steps on draft-ietf-dna-simple X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 08:39:46 -0000 The IESG reviewed this draft in our meeting yesterday. A number of issues were brought up, most of it already resolved but some still remain. Here are the changes that I've entered as RFC Editor notes: 1) Updates 4861 issue per Brian Carpenter's review comments: Please remove the "Updates 4861" claim from the header. 2) Unclear specification with respect to what the draft requires about fast RAs. I believe the current wording referred to draft-ietf-dna-frd. Some readers thought our specification was requiring a change from the 4861 rules that dictate a delay before the RS can go out. Please remove the following text from Section 2.4: As a result, in addition to implementing simple DNA, it is desirable that routers adopt procedures which allow for fast unicast Router Advertisement (RA) messages. 3) An additional security consideration issue was brought in secdir review. Please add the following text to the end of the security considerations section: The DNA procedure does not in itself provide positive, secure authentication of the router(s) on the network, or authentication of the network itself, as e.g. would be provided by mutual authentication at the link layer. Therefore when such assurance is not available, the host MUST NOT make any security-sensitive decisions based on the DNA procedure. In particular, it MUST NOT decide it has rejoined a network known to be physically secure, and proceed to abandon cryptographic protection. 4) Lars Eggert was happy that the draft included retransmission rules, but noted that the draft should also set an upper limit on how many previous routers are probed. Please add the following text to end of Section 4.4: A Simple DNA implementation SHOULD limit probing to at most six previously seen routers. Everyone happy with these changes? Also, we have a few remaining issues: 5) Lars asked whether some of the SHOULDs in the document should really be MUSTs. In my review this is not universally true at least. For instance, you may give some freedom for implementations to avoid sending probes if there are too many link up events in a short time period. However, we'd like you Suresh go through the document and for each SHOULD think about what the right keyword is. Sometimes it might be a MUST, sometimes a SHOULD. In some of the cases where its a SHOULD, it might be good to include a sentence or two about what issues might be considered when implementing it. 6) We need to respond to Ralph Droms' detailed review. (Thank you Ralph!) I think we can forget the Updates 4861 part of his discuss, but the rest is relevant. I'm including his Discuss here for completeness sake: This document calls for the transmission of an initial DHCPv6 message without the initial delay specified in section 17.1.2 of RFC 3315. The document also modifies the retransmission rules for several messages. And, although I hate to raise this issue, this document suggests that a DHCPv6 transaction is initiated before the hsot has seen the M/O bits in an RA. In section 4.1, I think each table entry should include: o Link-local IPv6 address of the router that advertised the prefix. o Link-layer (MAC) address of the router that advertised the prefix. o One or more IPv6 addresses; for each address include: * flag to indicate whether the address was obtained through SLAAC or DHCPv6 * preferred lifetime * valid lifetime * other configuration information if address was obtained through DHCPv6: - DUID - IA_ID - flag indicating IA_NA/IA_TA - other configuration information (DNS recursive servers, NTP servers, etc.) o One or more prefixes assigned to the link * preferred lifetime * valid lifetime * on-link flag In section 4.2: o Sending of neighbor discovery or DHCPv6 probes is incorrect ("or"). The host always sends NS probes and RS requests; it *may* send a DHCPv6 confirmation early as an optimization. In section 4.4: For the purpose of sending neighbor solicitations to previous routers, the host first identifies the set of operable IPv6 addresses (candidate set) that it wishes to use. If the addresses obtained from a previous router are no longer valid, the host does not include these addresses in the candidate set for NS based probing. s/operable/valid/ At this point, the host does not know what link it is attached to, so it cannot determine which addresses are operable. Also, the second sentence in this paragraph is redundant assuming the change to "valid" is made. More abstractly, I would rewrite this paragraph and the following paragraph to allow for multiple addresses on an interface: For the purpose of sending Neighbor Solicitation messages to previous routers, the host first identifies the set of candidate routers to probe. Any router in the SDAT for which there is at least one valid address is in the set of candidate routers. For each router in the candidate set, the host obtains the link-local and MAC addresses of the router from the SDAT. The host then sends a unicast Neighbor Solicitation to the router's link-local address. In the next paragraph, make "Router Solicitations" singular. The first paragraph in this section has a MUST requirement that the host only send one Router Solicitation. In section 4.5.1, I am baffled by the last paragraph. No DHCPv6 address is used anywhere else in the probe NS message and I can think of no reason why "The probing node SHOULD include a Source link-layer address option in the probe messages if the address was obtained using DHCPv6". Section 4.6 is somewhat problematic, in that a host is expected to use a Confirm message if it already has assigned addresses and a Solicit message if not. Thinking about the problem a little, I would suggest turning the solution around as follows: * Send a Solicit message * Compare the addresses in the Advertise message to the addresses in the SDAT * If a match is found, assume connection to the corresponding link; otherwise * Complete the DHCPv6 message exchange with a Request and wait for the Reply Otherwise, the host will need to send a Confirm message for each of candidate links and a Solicit message in case it is attached to a new link. In section 4.7, 2nd para, if the host receives an RA, why wouldn't it just use the current info in the RA; why would it try to reuse any cached info from a previous attachment? Also in the same para, what does it mean to receive a "DHCPv6 message [...] which contains prefixes that intersect with those previously advertised by a known router"? A DHCPv6 message contains assigned addresses and other configuration information, but no prefixes. I'm guessing the idea is to use the DHCPv6 response as an optimization, in case it is received before any NA or RA messages. If I have that right, then the check would have to be that the set of addresses in the DHCPv6 message matches the set of previously assigned addresses associated with the probed router. Comment: [2009-11-19] The authors should take a pass over the entire document to confirm that all descriptions of the purpose of this mechanism is to determine if the host has reattached to *any* previously attached link, rather than determining if the host has reattached to the link the host just left. For example: 4. Host Operations When a host has an existing configuration for IP address prefixes and next hop routing, it may be disconnected from its link-layer, and then subsequently reconnect the link-layer on the same interface. When the link-layer becomes available again, it is important to determine whether the existing addressing and routing configuration are still valid. In order to determine this, the host performs the detecting network attachment procedure. This document describes more than just detecting change; it describes how to find any link the host to which the host might have been previously connected. In the Introduction: Why do "Hosts require procedures to simply and reliably identify if they have moved to a different IP network" I think all of the text in the first paragraph of the introduction is more or less at odds with the rest of the document. Moving to a different IP network is not what this document is about. The machinery in this document identifies if a host reattaches to a link to which it has been previously attached. It accomplishes that result by determining if it has reachability to a router it has previously used as a default router. If the host determines it has been previously attached to its current link, it reuses the previously used addresses and other configuration information. Similarly, section 2.1 has several goals that mention "link change" when, in fact, Simple DNA is all about determining link reattachment. Section 2.2: When a host moves to a completely new link that is previously unknown, the performance of the Simple DNA protocol will be identical to that using standard neighbor discovery procedures [RFC4861]. But, section 4.6 suggests initiating DHCPv6 before receiving an RA, which reduces latency in completing DHCPv6 transaction for address assignment on a new link. Section 2.4: Since simple DNA does not modify the DHCPv6 protocol or state machine, the operation of DHCPv6 is unchanged. Not true. Simple DNA hanges the timing of DHCPv6 transmission and uses Solicit when Confirm would be appropriate. In section 2.5, if assumption 1 does not hold, a host may make an incorrect determination of which link it has attached to. In section 4, the second paragraph describes reattaching to the same link, while Simple DNA determines whether the host has reattached to *any* link to which it has previously been attached. In section 4.5.2, is there any difference between this RS message contents and the RS message contents specified in RFC 4861? If there is no difference, just reference the appropriate section of RFC 4861. There should be some text somewhere about when info is cached in the SDAT and when info is flushed from the SDAT. From bernard_aboba@hotmail.com Fri Nov 20 05:30:06 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17D03A6AC6 for ; Fri, 20 Nov 2009 05:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.326 X-Spam-Level: X-Spam-Status: No, score=-0.326 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3L-dQ2y17Tq for ; Fri, 20 Nov 2009 05:30:06 -0800 (PST) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by core3.amsl.com (Postfix) with ESMTP id 397FD3A68EF for ; Fri, 20 Nov 2009 05:30:04 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.72]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 05:30:01 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Jari Arkko'" , "'Suresh Krishnan \(QB/EMC\)'" , , "'Ralph Droms'" , "'Lars Eggert'" References: <4B0655CB.2040309@piuha.net> In-Reply-To: <4B0655CB.2040309@piuha.net> Date: Fri, 20 Nov 2009 05:30:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppvQLJ7ItJirIBTUaGOr1PTwr3RgAJZBYg Content-Language: en-us X-OriginalArrivalTime: 20 Nov 2009 13:30:01.0757 (UTC) FILETIME=[8FFC14D0:01CA69E5] Cc: 'DNA' , dna@ietf.org Subject: Re: [dna] next steps on draft-ietf-dna-simple X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 13:30:06 -0000 Jari said: Please add the following text to the end of the security considerations section: The DNA procedure does not in itself provide positive, secure authentication of the router(s) on the network, or authentication of the network itself, as e.g. would be provided by mutual authentication at the link layer. Therefore when such assurance is not available, the host MUST NOT make any security-sensitive decisions based on the DNA procedure. In particular, it MUST NOT decide it has rejoined a network known to be physically secure, and proceed to abandon cryptographic protection. [BA] Where SEND is in use, DNA *does* provide positive, secure authentication of the router(s) on the network. Also, the procedures of Section 4.7.1 ensure that DNA does not override secure mechanisms available on a network, such as DHCPv6 security or SEND. Therefore, DNA provides security equivalent to existing procedures. While it's true that a host should not make security decisions based on insecure mechanisms (e.g. insecure DHCPv6 or RS/RA), that advice is not unique to simple DNA. 4) Lars Eggert was happy that the draft included retransmission rules, but noted that the draft should also set an upper limit on how many previous routers are probed. Please add the following text to end of Section 4.4: A Simple DNA implementation SHOULD limit probing to at most six previously seen routers. [BA] This is fine; existing implementations typically have such a limit. From bernard_aboba@hotmail.com Fri Nov 20 05:37:11 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32F43A6937; Fri, 20 Nov 2009 05:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.562 X-Spam-Level: X-Spam-Status: No, score=-0.562 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKE08ebKqwWO; Fri, 20 Nov 2009 05:37:10 -0800 (PST) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by core3.amsl.com (Postfix) with ESMTP id C6E873A6A98; Fri, 20 Nov 2009 05:37:10 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.73]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 05:37:08 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Jari Arkko'" , "'Suresh Krishnan \(QB/EMC\)'" , , "'Ralph Droms'" , "'Lars Eggert'" References: <4B0655CB.2040309@piuha.net> In-Reply-To: <4B0655CB.2040309@piuha.net> Date: Fri, 20 Nov 2009 05:37:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcppvQLJ7ItJirIBTUaGOr1PTwr3RgAKJhDQ Content-Language: en-us X-OriginalArrivalTime: 20 Nov 2009 13:37:08.0320 (UTC) FILETIME=[8E3C6E00:01CA69E6] Cc: 'DNA' , dna@ietf.org, 'IESG' Subject: [dna] DNA and DHCPv6 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 13:37:11 -0000 I believe that many of Ralph's issues below are the result of poor wording in the document. The draft specifically says that it does not change the DHCPv6 protocol, state machine or timers, so that any situation in which there is an implied DHCPv6 change represents an error. So if a host delays transmission of an initial DHCPv6 message that should still be the case with DNA. Also, the draft should not change the retransmission rules for DHCPv6. The paragraph in question, (which is not well worded) was intended to refer only to NS retransmission. With respect to the M/O bits, the draft should not change the behavior of an implementation. So if an implementation ignores the M/O bits (as some do), then that behavior should continue. If it doesn't ignore them, then it will continue to take them into account as it did before. Also, DNA does not change the assumptions which DHCPv6 uses to obtain an address. If DHCPv6 would normally attempt to confirm a previously held address, it should continue to do so; if it would normally attempt to obtain a new address, it will do that instead. Given the above, DHCPv6 and DNA largely operate as "ships in the night"; the only interaction comes when the two procedures come to different conclusions, in which case the text in Section 4.7.1 comes into play. From rdroms@cisco.com Fri Nov 20 06:23:19 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527AD28C12B; Fri, 20 Nov 2009 06:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78ReAqhIUcZI; Fri, 20 Nov 2009 06:23:18 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0050E3A6AD3; Fri, 20 Nov 2009 06:23:17 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJo0BktAZnwN/2dsb2JhbAC8fIkeCI5HgksIgWkEgW8 X-IronPort-AV: E=Sophos;i="4.44,777,1249257600"; d="scan'208";a="69187838" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Nov 2009 14:23:11 +0000 Received: from bxb-rdroms-8712.cisco.com (bxb-rdroms-8712.cisco.com [10.98.10.83]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAKENAts029851; Fri, 20 Nov 2009 14:23:10 GMT Message-Id: From: Ralph Droms To: Bernard Aboba In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Nov 2009 09:23:10 -0500 References: <4B0655CB.2040309@piuha.net> X-Mailer: Apple Mail (2.936) Cc: DNA , dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org, IESG , Lars Eggert , dhc WG Subject: Re: [dna] DNA and DHCPv6 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 14:23:19 -0000 Bernard - thanks for the clarifications; I've included some comments inline. Also adding dhc WG for comments. On Nov 20, 2009, at 8:37 AM 11/20/09, Bernard Aboba wrote: > I believe that many of Ralph's issues below are the result of poor > wording > in the document. > > The draft specifically says that it does not change the DHCPv6 > protocol, state machine or timers, so that any situation in which > there is an implied DHCPv6 change represents an error. It makes sense to me that DHCPv6 would not be changed by this document. DHCPv6 already has a mechanism through which a host can determine, in one DHCPv6 message exchange, if it has reattached to its most recently attached link. If the host has moved to a new link, an additional 4 message exchange (possibly optimized to 2 messages) is necessary to get configuration information for the new link. In addition to the text that may imply skipping an initial delay when sending an initial DHCPv6 message, the third paragraph of section 4.6 of this document changes the DHCPv6 protocol by specifying that a host always send a Solicit message first, possibly including addresses from previously visited links as hints. I think the text about this step is a little fuzzy about which addresses should be sent and how they should be sent. I could imagine an argument for a change to DHCPv6 that requires the host to send a Confirm message for each of its currently valid addresses and a Solicit message, all in a burst, to probe all possible links in parallel, rather than just checking for reattachment to the most recently attached link. However, it would be a significant change to DHCPv6 that has the potential for significant load on the DHCPv6 service. Another link between Simple DNA and DHCPv6 comes to mind at this point. Here is the second paragraph of section 4.7: On reception of a Router Advertisement or advertising DHCPv6 message (a REPLY or ADVERTISE) which contains prefixes that intersect with those previously advertised by a known router, the host utilizes the configuration associated with the detected network. What, exactly, does "utilize the configuration" mean, in relation to DHCPv6? Does the host use any DHCPv6-assigned addresses without sending a Confirm message to the DHCPv6 service? If the host has not reattached to its most recently attached link, presumably the host will have received a NAK from the DHCPv6 service from its initial Confirm (which checked just the most recently attached link). Depending on the timing, the host may have already initiated a DHCPv6 message exchange for the current link. Also, this paragraph specifies "prefixes that intersect with those previously advertised by a known router". Suppose the set of prefixes intersects but is not identical to those previously advertised? I assume the host uses the newly received configuration. But, by now the host has all the current configuration information from its local router, so what's the point? > So if a host delays transmission of an initial DHCPv6 message that > should still be the case with DNA. Also, the draft should not > change the retransmission rules for DHCPv6. The paragraph in > question, > (which is not well worded) was intended to refer only to NS > retransmission. OK. > > With respect to the M/O bits, the draft should not change the behavior > of an implementation. So if an implementation ignores the M/O bits > (as some do), then that behavior should continue. If it > doesn't ignore them, then it will continue to take them into account > as > it did before. OK. > Also, DNA does not change the assumptions which DHCPv6 uses to obtain > an address. If DHCPv6 would normally attempt to confirm a previously > held address, it should continue to do so; if it would normally > attempt to obtain a new address, it will do that instead. As I mentioned above, I don't think the behavior you describe here is currently described in the document. > Given the above, DHCPv6 and DNA largely operate as "ships in the > night"; the only interaction comes when the two procedures come > to different conclusions, in which case the text in Section 4.7.1 > comes into play. OK. - Ralph From bernard_aboba@hotmail.com Fri Nov 20 08:39:51 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25ED3A6906; Fri, 20 Nov 2009 08:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[AWL=1.231, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhbIgotjczcP; Fri, 20 Nov 2009 08:39:50 -0800 (PST) Received: from blu0-omc3-s18.blu0.hotmail.com (blu0-omc3-s18.blu0.hotmail.com [65.55.116.93]) by core3.amsl.com (Postfix) with ESMTP id B5DFF3A6878; Fri, 20 Nov 2009 08:39:50 -0800 (PST) Received: from BLU137-DS1 ([65.55.116.72]) by blu0-omc3-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 08:39:48 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Ralph Droms'" References: <4B0655CB.2040309@piuha.net> In-Reply-To: Date: Fri, 20 Nov 2009 08:39:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpp7P2ElBMOyIWOTYaCaojG4o2LhgAD/mPA Content-Language: en-us X-OriginalArrivalTime: 20 Nov 2009 16:39:48.0095 (UTC) FILETIME=[12C560F0:01CA6A00] Cc: 'DNA' , dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org, 'IESG' , 'Lars Eggert' , 'dhc WG' Subject: Re: [dna] DNA and DHCPv6 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 16:39:51 -0000 > I believe that many of Ralph's issues below are the result of poor > wording in the document. > > The draft specifically says that it does not change the DHCPv6 > protocol, state machine or timers, so that any situation in which > there is an implied DHCPv6 change represents an error. "It makes sense to me that DHCPv6 would not be changed by this document. DHCPv6 already has a mechanism through which a host can determine, in one DHCPv6 message exchange, if it has reattached to its most recently attached link. If the host has moved to a new link, an additional 4 message exchange (possibly optimized to 2 messages) is necessary to get configuration information for the new link." [BA] Right. That mechanism should be used as is, with no changes. "In addition to the text that may imply skipping an initial delay when sending an initial DHCPv6 message, the third paragraph of section 4.6 of this document changes the DHCPv6 protocol by specifying that a host always send a Solicit message first, possibly including addresses from previously visited links as hints. I think the text about this step is a little fuzzy about which addresses should be sent and how they should be sent." [BA] The contents of DHCPv6 packets shouldn't be dependent on any aspect of DNA. For example, DNA shouldn't influence whether a Solicit message is sent first nor what addresses are used as hints. Whatever any implementation already does should be left alone. After all, DNA is just an optimization. "I could imagine an argument for a change to DHCPv6 that requires the host to send a Confirm message for each of its currently valid addresses and a Solicit message, all in a burst, to probe all possible links in parallel, rather than just checking for reattachment to the most recently attached link. However, it would be a significant change to DHCPv6 that has the potential for significant load on the DHCPv6 service." [BA] I don't see a need to change DHCPv6, particularly if this would create potential problems. "Another link between Simple DNA and DHCPv6 comes to mind at this point. Here is the second paragraph of section 4.7: On reception of a Router Advertisement or advertising DHCPv6 message (a REPLY or ADVERTISE) which contains prefixes that intersect with those previously advertised by a known router, the host utilizes the configuration associated with the detected network. What, exactly, does "utilize the configuration" mean, in relation to DHCPv6? Does the host use any DHCPv6-assigned addresses without sending a Confirm message to the DHCPv6 service? If the host has not reattached to its most recently attached link, presumably the host will have received a NAK from the DHCPv6 service from its initial Confirm (which checked just the most recently attached link). Depending on the timing, the host may have already initiated a DHCPv6 message exchange for the current link." [BA] I have no idea what this paragraph means (or even why it is necessary). Shouldn't a host just do what it would normally do in response to these messages? After all, DNA is only really about use of neighbor discovery, not RS/RA or DHCPv6. "Also, this paragraph specifies "prefixes that intersect with those previously advertised by a known router". Suppose the set of prefixes intersects but is not identical to those previously advertised? I assume the host uses the newly received configuration. But, by now the host has all the current configuration information from its local router, so what's the point?" [BA] As far as I can see, the only case worth additional discussion is the one in which there are prefixes that don't intersect. "As I mentioned above, I don't think the behavior you describe here is currently described in the document." [BA] Right. My take is that this (and other DHCPv6 changes you mention) are unnecessary and should be removed. From rdroms@cisco.com Fri Nov 20 09:14:06 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC603A6946; Fri, 20 Nov 2009 09:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv13Ago31PhD; Fri, 20 Nov 2009 09:14:04 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1CCFA3A6358; Fri, 20 Nov 2009 09:14:04 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGJdBktAZnwN/2dsb2JhbAC9O5dihDwEgW8 X-IronPort-AV: E=Sophos;i="4.44,778,1249257600"; d="scan'208";a="69165349" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Nov 2009 17:14:00 +0000 Received: from bxb-rdroms-8712.cisco.com (bxb-rdroms-8712.cisco.com [10.98.10.83]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nAKHDx1I003968; Fri, 20 Nov 2009 17:13:59 GMT Message-Id: From: Ralph Droms To: Bernard Aboba In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Nov 2009 12:13:59 -0500 References: <4B0655CB.2040309@piuha.net> X-Mailer: Apple Mail (2.936) Cc: DNA , dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org, IESG IESG , dhc WG Subject: Re: [dna] DNA and DHCPv6 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 17:14:06 -0000 So, would this be an accurate description of Simple DNA: * Send NS for each candidate link to the default router for that link * Initiate RS/RA exchange as specified in RFC 4861 * Initiate DHCPv6 exchange as specified in RFC 3315 * If an NA is received, used cached info for corresponding link from SDAT * Process any received RAs as specified in RFC 4861 * Use info from DHCPv6 exchange as specified in RFC 3315 * Info from RA and/or DHCPv6 overrides any reused cached info based on NA - Ralph On Nov 20, 2009, at 11:39 AM 11/20/09, Bernard Aboba wrote: >> I believe that many of Ralph's issues below are the result of poor >> wording in the document. >> >> The draft specifically says that it does not change the DHCPv6 >> protocol, state machine or timers, so that any situation in which >> there is an implied DHCPv6 change represents an error. > > "It makes sense to me that DHCPv6 would not be changed by this > document. DHCPv6 already has a mechanism through which a host can > determine, in one DHCPv6 message exchange, if it has reattached to its > most recently attached link. If the host has moved to a new link, an > additional 4 message exchange (possibly optimized to 2 messages) is > necessary to get configuration information for the new link." > > [BA] Right. That mechanism should be used as is, with no changes. > > "In addition to the text that may imply skipping an initial delay when > sending an initial DHCPv6 message, the third paragraph of section 4.6 > of this document changes the DHCPv6 protocol by specifying that a host > always send a Solicit message first, possibly including addresses from > previously visited links as hints. I think the text about this step > is a little fuzzy about which addresses should be sent and how they > should be sent." > > [BA] The contents of DHCPv6 packets shouldn't be dependent on any > aspect of > DNA. > For example, DNA shouldn't influence whether a Solicit message is > sent first > nor > what addresses are used as hints. Whatever any implementation already > does should be left alone. After all, DNA is just an optimization. > > "I could imagine an argument for a change to DHCPv6 that requires the > host to send a Confirm message for each of its currently valid > addresses and a Solicit message, all in a burst, to probe all possible > links in parallel, rather than just checking for reattachment to the > most recently attached link. However, it would be a significant > change to DHCPv6 that has the potential for significant load on the > DHCPv6 service." > > [BA] I don't see a need to change DHCPv6, particularly if this would > create potential problems. > > "Another link between Simple DNA and DHCPv6 comes to mind at this > point. Here is the second paragraph of section 4.7: > > On reception of a Router Advertisement or advertising DHCPv6 > message > (a REPLY or ADVERTISE) which contains prefixes that intersect with > those previously advertised by a known router, the host utilizes > the > configuration associated with the detected network. > > What, exactly, does "utilize the configuration" mean, in relation to > DHCPv6? Does the host use any DHCPv6-assigned addresses without > sending a Confirm message to the DHCPv6 service? If the host has not > reattached to its most recently attached link, presumably the host > will have received a NAK from the DHCPv6 service from its initial > Confirm (which checked just the most recently attached link). > Depending on the timing, the host may have already initiated a DHCPv6 > message exchange for the current link." > > [BA] I have no idea what this paragraph means (or even why it is > necessary). > > Shouldn't a host just do what it would normally do in response to > these > messages? After all, DNA is only really about use of neighbor > discovery, > not RS/RA or DHCPv6. > > "Also, this paragraph specifies "prefixes that intersect with those > previously advertised by a known router". Suppose the set of prefixes > intersects but is not identical to those previously advertised? I > assume the host uses the newly received configuration. But, by now > the host has all the current configuration information from its local > router, so what's the point?" > > [BA] As far as I can see, the only case worth additional discussion is > the one in which there are prefixes that don't intersect. > > "As I mentioned above, I don't think the behavior you describe here is > currently described in the document." > > [BA] Right. My take is that this (and other DHCPv6 changes you > mention) > are unnecessary and should be removed. > From bernard_aboba@hotmail.com Fri Nov 20 10:15:11 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63A383A6837; Fri, 20 Nov 2009 10:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=1.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7Fww1sPuGGg; Fri, 20 Nov 2009 10:15:10 -0800 (PST) Received: from blu0-omc3-s27.blu0.hotmail.com (blu0-omc3-s27.blu0.hotmail.com [65.55.116.102]) by core3.amsl.com (Postfix) with ESMTP id 877593A6825; Fri, 20 Nov 2009 10:15:10 -0800 (PST) Received: from BLU137-DS5 ([65.55.116.74]) by blu0-omc3-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 10:15:07 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Ralph Droms'" References: <4B0655CB.2040309@piuha.net> In-Reply-To: Date: Fri, 20 Nov 2009 10:15:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpqBNnNVd3CGmG9QOq/2sdEBHweEQACBh2A Content-Language: en-us X-OriginalArrivalTime: 20 Nov 2009 18:15:07.0642 (UTC) FILETIME=[63E2FDA0:01CA6A0D] Cc: 'DNA' , dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org, 'IESG IESG' , 'dhc WG' Subject: Re: [dna] DNA and DHCPv6 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 18:15:11 -0000 "So, would this be an accurate description of Simple DNA: * Send NS for each candidate link to the default router for that link * Initiate RS/RA exchange as specified in RFC 4861 * Initiate DHCPv6 exchange as specified in RFC 3315 * If an NA is received, used cached info for corresponding link from SDAT * Process any received RAs as specified in RFC 4861 * Use info from DHCPv6 exchange as specified in RFC 3315 * Info from RA and/or DHCPv6 overrides any reused cached info based on NA" [BA] I believe so, yes. Aside from the DHCPv6 issues, there were a few deviations with respect to RS/RA that were raised in the IESG review. I think we need to look at those carefully as well. From bernard_aboba@hotmail.com Fri Nov 20 10:36:01 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B573A694A; Fri, 20 Nov 2009 10:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=1.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leLFlvhv8Gu9; Fri, 20 Nov 2009 10:36:00 -0800 (PST) Received: from blu0-omc3-s20.blu0.hotmail.com (blu0-omc3-s20.blu0.hotmail.com [65.55.116.95]) by core3.amsl.com (Postfix) with ESMTP id AF42E3A6927; Fri, 20 Nov 2009 10:36:00 -0800 (PST) Received: from BLU137-DS4 ([65.55.116.72]) by blu0-omc3-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Nov 2009 10:35:58 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Bernard Aboba'" , "'Ralph Droms'" References: <4B0655CB.2040309@piuha.net> <25152_1258740954_4B06DCDA_25152_2200991_1_BLU137-DS54781303180257DD0D9B193A10@phx.gbl> In-Reply-To: <25152_1258740954_4B06DCDA_25152_2200991_1_BLU137-DS54781303180257DD0D9B193A10@phx.gbl> Date: Fri, 20 Nov 2009 10:35:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpqBNnNVd3CGmG9QOq/2sdEBHweEQACBh2AAAC75EA= Content-Language: en-us X-OriginalArrivalTime: 20 Nov 2009 18:35:58.0132 (UTC) FILETIME=[4D3C9F40:01CA6A10] Cc: 'DNA' , dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org, 'IESG IESG' , 'dhc WG' Subject: Re: [dna] [DNA] RE: DNA and DHCPv6 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2009 18:36:01 -0000 One potential wrinkle occurs in the case where the NS/NA, RS/RA and DHCPv6 exchanges have unequal levels of security. For example, Section 4.7.1 states that if the NS/NA is secured with SEND and the DHCPv6 exchange is not, then DNA takes priority. However, where there are equal levels of security (or insecurity), then I believe DNA should work as per below. -----Original Message----- From: owner-dna@ecselists.eng.monash.edu.au [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of Bernard Aboba Sent: Friday, November 20, 2009 10:15 AM To: 'Ralph Droms' Cc: 'DNA'; dna@ietf.org; 'Suresh Krishnan (QB/EMC)'; draft-ietf-dna-simple@tools.ietf.org; 'Jari Arkko'; 'IESG IESG'; 'dhc WG' Subject: [DNA] RE: DNA and DHCPv6 "So, would this be an accurate description of Simple DNA: * Send NS for each candidate link to the default router for that link * Initiate RS/RA exchange as specified in RFC 4861 * Initiate DHCPv6 exchange as specified in RFC 3315 * If an NA is received, used cached info for corresponding link from SDAT * Process any received RAs as specified in RFC 4861 * Use info from DHCPv6 exchange as specified in RFC 3315 * Info from RA and/or DHCPv6 overrides any reused cached info based on NA" [BA] I believe so, yes. Aside from the DHCPv6 issues, there were a few deviations with respect to RS/RA that were raised in the IESG review. I think we need to look at those carefully as well. From mellon@fugue.com Tue Nov 24 09:52:33 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4EB13A6820 for ; Tue, 24 Nov 2009 09:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wV1we+ptQAqV for ; Tue, 24 Nov 2009 09:52:32 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id E20D13A6914 for ; Tue, 24 Nov 2009 09:52:32 -0800 (PST) Received: from [192.168.1.47] (pool-74-108-155-75.nycmny.east.verizon.net [74.108.155.75]) by toccata.fugue.com (Postfix) with ESMTPSA id 511AF34E47EA for ; Tue, 24 Nov 2009 10:55:35 -0700 (MST) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Nov 2009 12:52:26 -0500 Message-Id: To: dna@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [dna] Review of draft-ietf-dna-simple-11 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 17:52:33 -0000 Ralph asked participants in the DHC working group to review the draft, = so I gave it a read. I have some comments. I realize that some of = these comments are partially addressed in the summary message Jari sent = to the list recently, but it's difficult to know what to include and = what to leave out, so I just included it all. =46rom section 2.1: o False positives are not acceptable. A host should not conclude that there is no link change when there is one. o False negatives are acceptable. A host can conclude that there is a link change when there is none. This seems backwards, unless there is no cost to a false negative. If a host concludes that there was a link change when there was none, and as a consequence abandons the IP addresses it was using on the previous link, that's going to create a (potentially noticeable) hiccup while it reacquires its address. Depending on the IP stack, it's possible that connections might also be broken, e.g. if a syscall returns EHOSTUNREACH due to a transient routing outage. More, from section 4.3: It SHOULD also set all Neighbor Cache entries for the routers on its Default Router List to STALE. This is done to speed up the acquisition of a new default router when link change has occurred. It's my impression that by default, a stale routing table entry won't be used, so if an application writes to an open tcp connection while the routing table entry is stale, it will get an EHOSTUNREACH, and the connection will be dropped. I have had this exact experience with IPv4 DNA implementations when my WiFi router signal is flaky. This is much worse than taking a long time (500ms isn't really that long) to identify a new link. This would also be a problem in the case where you are on a WiFi network with more than one device advertising the same SSID - when you switch to a new beacon, arguably this is a DNA event, but it would = clearly be a mistake to break existing connections in this case. In section 4.6, the draft seems to be saying that the DHCPv6 client should starty soliciting before it receives an RA. This does actually change the DHCPv6 state machine. In fact, the DHCPv6 protocol has a specific message for checking in the event of a DNA event: the Confirm message. I think Ralph already brought this up; I mention it because it appears to be a problem to me as well. I also think that this section goes into a lot of extra detail that is unnecessary and probably harmful to interoperability, since what it says doesn't really match what RFC3315 says. It would be better to just refer to RFC3315 here. Section 4.7.1 also seems to have a problem in that in this case we have started the Confirm process before we receive an RA. If the RA conflicts with the address we are attempting to confirm, we may know this to be the case before we get a reply (or no reply) from a DHCPv6 server. This could be because the RA comes before the DHCPv6 Reply message, or it could be because the link has in fact changed, and there is no DHCPv6 server on the new link. In either case, there is no need to wait for the response from the DHCPv6 server. Also, 4.7.1 doesn't talk about what to do if the NS and RS results differ, and the NA is secure whereas the RA is not. In that case it seems to me that it would make sense to trust the NA rather than the RA (presumably in that case a trustworthy RA would eventually follow, since the router that responded to the NS with a secure NA will presumably send a secure RA in response to the RS). But there's a window of opportunity here for a rogue RA to unseat a secure router. There's a similar problem in section 4.7 because section 4.7 instructs the implementor to test whether an NA comes from the same router as an RA, but doesn't talk about what to do if the security of the two messages differs. So this is another opportunity for an attacker to get in a quick DoS. The same problem exists in section 4.9, where receipt of an NA, RA or DHCP Reply will terminate other DNA operations, without regard to the security level of the response that terminates the other state machines. Section 5 provides pseudocode for this process. Thread C of the pseudocode is not asynchronous, and hence not correct. Even if it could be made asynchronous, the protocol spec should be fully descriptive; if it is not, conflicts between the spec and the pseudocode will create interoperability problems, and being sure that the two are the same is an unsolved computer science problem. So section 5 should be deleted. Section 7 doesn't mention what to do in the dual-stack case. Maybe this is too big a can of worms... I see that some of the issues I mention above are addressed in the security considerations section. This is the wrong place for this - the handling of SEND needs to be wrapped into the spec in section 4. Security Considerations is the wrong place to put more of the protocol spec. From bernard_aboba@hotmail.com Tue Nov 24 10:14:15 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AB928C0DD for ; Tue, 24 Nov 2009 10:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.865 X-Spam-Level: X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v90w1LEKVogb for ; Tue, 24 Nov 2009 10:14:14 -0800 (PST) Received: from blu0-omc4-s20.blu0.hotmail.com (blu0-omc4-s20.blu0.hotmail.com [65.55.111.159]) by core3.amsl.com (Postfix) with ESMTP id 45D8B28C114 for ; Tue, 24 Nov 2009 10:14:14 -0800 (PST) Received: from BLU137-DS7 ([65.55.111.135]) by blu0-omc4-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 10:14:09 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Ted Lemon'" , References: In-Reply-To: Date: Tue, 24 Nov 2009 10:14:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcptLuTq2KBG1odbSZW5OOLQvFqBIQAAqEtw Content-Language: en-us X-OriginalArrivalTime: 24 Nov 2009 18:14:09.0643 (UTC) FILETIME=[EAF80BB0:01CA6D31] Subject: Re: [dna] Review of draft-ietf-dna-simple-11 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:14:15 -0000 Ted Lemon said: "From section 2.1: o False positives are not acceptable. A host should not conclude that there is no link change when there is one. o False negatives are acceptable. A host can conclude that there is a link change when there is none. This seems backwards, unless there is no cost to a false negative. If a host concludes that there was a link change when there was none, and as a consequence abandons the IP addresses it was using on the previous link, that's going to create a (potentially noticeable) hiccup while it reacquires its address. Depending on the IP stack, it's possible that connections might also be broken, e.g. if a syscall returns EHOSTUNREACH due to a transient routing outage." The paragraphs above do not correctly define the meaning of "false positive" and "false negative". Here is what RFC 4436 says: o As a performance optimization, it must not sacrifice correctness. In other words, false positives are not acceptable. DNAv4 must not conclude that a host has returned to a previously visited link where it has an operable IP address if this is not in fact the case. o As a performance optimization, false negatives are acceptable. It is not an absolute requirement that this optimization correctly recognize a previously visited link in all possible cases. For example, if a router ignores unicast ARP Requests, then DNAv4 will not be able to detect that it has returned to the same link in the future. This is acceptable because the host still operates correctly as it did without DNAv4, just without the performance benefit. Users and network operators who desire the performance improvement offered by DNAv4 can upgrade their routers to support DNAv4. From bernard_aboba@hotmail.com Tue Nov 24 10:18:13 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3FFE3A6816 for ; Tue, 24 Nov 2009 10:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h26XPW+pYnxB for ; Tue, 24 Nov 2009 10:18:12 -0800 (PST) Received: from blu0-omc4-s31.blu0.hotmail.com (blu0-omc4-s31.blu0.hotmail.com [65.55.111.170]) by core3.amsl.com (Postfix) with ESMTP id 18DF23A67C1 for ; Tue, 24 Nov 2009 10:18:12 -0800 (PST) Received: from BLU137-DS7 ([65.55.111.135]) by blu0-omc4-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 10:18:07 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Ted Lemon'" , References: In-Reply-To: Date: Tue, 24 Nov 2009 10:18:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcptLuTq2KBG1odbSZW5OOLQvFqBIQAAxuQg Content-Language: en-us X-OriginalArrivalTime: 24 Nov 2009 18:18:07.0385 (UTC) FILETIME=[78AC9890:01CA6D32] Subject: Re: [dna] Review of draft-ietf-dna-simple-11 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:18:13 -0000 Ted Lemon said: "More, from section 4.3: It SHOULD also set all Neighbor Cache entries for the routers on its Default Router List to STALE. This is done to speed up the acquisition of a new default router when link change has occurred. It's my impression that by default, a stale routing table entry won't be used, so if an application writes to an open tcp connection while the routing table entry is stale, it will get an EHOSTUNREACH, and the connection will be dropped. I have had this exact experience with IPv4 DNA implementations when my WiFi router signal is flaky. This is much worse than taking a long time (500ms isn't really that long) to identify a new link. This would also be a problem in the case where you are on a WiFi network with more than one device advertising the same SSID - when you switch to a new beacon, arguably this is a DNA event, but it would clearly be a mistake to break existing connections in this case. [BA] I agree that the paragraph cited does not make sense. RFC 4436 does not contain equivalent advice. In general, Simple DNAv6 should seek to minimize connectivity disruption. From bernard_aboba@hotmail.com Tue Nov 24 10:23:21 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713A43A68B7 for ; Tue, 24 Nov 2009 10:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.944, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0g68KRlr-OJj for ; Tue, 24 Nov 2009 10:23:20 -0800 (PST) Received: from blu0-omc4-s15.blu0.hotmail.com (blu0-omc4-s15.blu0.hotmail.com [65.55.111.154]) by core3.amsl.com (Postfix) with ESMTP id 9B4783A6820 for ; Tue, 24 Nov 2009 10:23:20 -0800 (PST) Received: from BLU137-DS3 ([65.55.111.135]) by blu0-omc4-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 10:23:16 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Ted Lemon'" , References: In-Reply-To: Date: Tue, 24 Nov 2009 10:23:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcptLuTq2KBG1odbSZW5OOLQvFqBIQABAwOQ Content-Language: en-us X-OriginalArrivalTime: 24 Nov 2009 18:23:16.0168 (UTC) FILETIME=[30B92480:01CA6D33] Subject: Re: [dna] Review of draft-ietf-dna-simple-11 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:23:21 -0000 Ted Lemon said: "In section 4.6, the draft seems to be saying that the DHCPv6 client should starty soliciting before it receives an RA. This does actually change the DHCPv6 state machine. In fact, the DHCPv6 protocol has a specific message for checking in the event of a DNA event: the Confirm message. I think Ralph already brought this up; I mention it because it appears to be a problem to me as well. I also think that this section goes into a lot of extra detail that is unnecessary and probably harmful to interoperability, since what it says doesn't really match what RFC3315 says. It would be better to just refer to RFC3315 here." [BA] I agree. Elsewhere the document states that it does not modify DHCPv6, but the draft is sprinkled with instances where it does in fact do this. As far as I can tell, none of these changes add value and so they should be replaced by a reference to RFC 3315. From bernard_aboba@hotmail.com Tue Nov 24 10:36:26 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A86C528C145 for ; Tue, 24 Nov 2009 10:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6PCv9r3xw+D for ; Tue, 24 Nov 2009 10:36:25 -0800 (PST) Received: from blu0-omc4-s8.blu0.hotmail.com (blu0-omc4-s8.blu0.hotmail.com [65.55.111.147]) by core3.amsl.com (Postfix) with ESMTP id BD3E23A67C1 for ; Tue, 24 Nov 2009 10:36:25 -0800 (PST) Received: from BLU137-DS7 ([65.55.111.137]) by blu0-omc4-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 10:36:21 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Ted Lemon'" , References: In-Reply-To: Date: Tue, 24 Nov 2009 10:36:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcptLuTq2KBG1odbSZW5OOLQvFqBIQABFTrA Content-Language: en-us X-OriginalArrivalTime: 24 Nov 2009 18:36:21.0234 (UTC) FILETIME=[04A8B520:01CA6D35] Subject: Re: [dna] Review of draft-ietf-dna-simple-11 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:36:26 -0000 Ted Lemon said: "Section 4.7.1 also seems to have a problem in that in this case we have started the Confirm process before we receive an RA. If the RA conflicts with the address we are attempting to confirm, we may know this to be the case before we get a reply (or no reply) from a DHCPv6 server. This could be because the RA comes before the DHCPv6 Reply message, or it could be because the link has in fact changed, and there is no DHCPv6 server on the new link. In either case, there is no need to wait for the response from the DHCPv6 server." [BA] I agree that there is no need to wait. As Ralph noted, simple DNAv6 shouldn't be suggesting that a DHCPv6 exchange be initiated prior to the RS/RA exchange. Rather, it should just co-exist with whatever the implementation already does. Ted Lemon also said: "Also, 4.7.1 doesn't talk about what to do if the NS and RS results differ, and the NA is secure whereas the RA is not. In that case it seems to me that it would make sense to trust the NA rather than the RA (presumably in that case a trustworthy RA would eventually follow, since the router that responded to the NS with a secure NA will presumably send a secure RA in response to the RS). But there's a window of opportunity here for a rogue RA to unseat a secure router. There's a similar problem in section 4.7 because section 4.7 instructs the implementor to test whether an NA comes from the same router as an RA, but doesn't talk about what to do if the security of the two messages differs. So this is another opportunity for an attacker to get in a quick DoS. " [BA] I agree that a secure NA should take precedence over an insecure RA. The same problem exists in section 4.9, where receipt of an NA, RA or DHCP Reply will terminate other DNA operations, without regard to the security level of the response that terminates the other state machines. [BA] Completion of Simple DNAv6 should not terminate the other state machines. My understanding was that the text in Section 4.9 was only supposed to refer to termination of the NS/NA probing. Since Simple DNAv6 isn't supposed to change the behavior of RS/RA or DHCPv6, terminating other state machines isn't appropriate -- and can lead to false positives and negatives in contradiction to the goals stated in the beginning of the document. Section 7 doesn't mention what to do in the dual-stack case. Maybe this is too big a can of worms... [BA] Is there any reason why DNAv4 and DNAv6 can't operate independently? I see that some of the issues I mention above are addressed in the security considerations section. This is the wrong place for this - the handling of SEND needs to be wrapped into the spec in section 4. Security Considerations is the wrong place to put more of the protocol spec. [BA] I agree. From narten@us.ibm.com Tue Nov 24 11:31:09 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48CA33A67C1 for ; Tue, 24 Nov 2009 11:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlTEYSd2Glfr for ; Tue, 24 Nov 2009 11:31:08 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 715AE3A67A6 for ; Tue, 24 Nov 2009 11:31:08 -0800 (PST) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nAOJTnOE030120 for ; Tue, 24 Nov 2009 12:29:49 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nAOJUa8j032780 for ; Tue, 24 Nov 2009 12:30:41 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nAOJUaIV022630 for ; Tue, 24 Nov 2009 12:30:36 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-48-44-201.mts.ibm.com [9.48.44.201]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nAOJUZ82022566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 12:30:36 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id nAOJUYtS006913; Tue, 24 Nov 2009 14:30:34 -0500 Message-Id: <200911241930.nAOJUYtS006913@cichlid.raleigh.ibm.com> To: Ted Lemon In-reply-to: References: Comments: In-reply-to Ted Lemon message dated "Tue, 24 Nov 2009 12:52:26 -0500." Date: Tue, 24 Nov 2009 14:30:34 -0500 From: Thomas Narten Cc: dna@ietf.org Subject: Re: [dna] Review of draft-ietf-dna-simple-11 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:31:09 -0000 Ted Lemon writes: > Ralph asked participants in the DHC working group to review the draft, so I gave it a read. I have some comments. I realize that some of these comments are partially addressed in the summary message Jari sent to the list recently, but it's difficult to know what to include and what to leave out, so I just included it all. > >From section 2.1: > o False positives are not acceptable. A host should not conclude > that there is no link change when there is one. > o False negatives are acceptable. A host can conclude that there is > a link change when there is none. > This seems backwards, unless there is no cost to a false negative. If > a host concludes that there was a link change when there was none, and > as a consequence abandons the IP addresses it was using on the > previous link, that's going to create a (potentially noticeable) > hiccup while it reacquires its address. Depending on the IP stack, > it's possible that connections might also be broken, e.g. if a syscall > returns EHOSTUNREACH due to a transient routing outage. Note, as a comparison point, a stack that does not implement DNA. When the node encounters a "link up" event, that presumably also implies a "link down" event preceding the "link up" event, and the default course of action should be to throw away all the old configuration information and then start the configuration process from scratch. Thus, the concern you cite above happens today with our current specs. DNA doesn't make things worse. (Of course, different stacks may do different things, but from a specification perspective, I believe the above behavior is what the specs imply, if they don't say it explicitely.) Thomas From bernard_aboba@hotmail.com Tue Nov 24 12:42:22 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FAB3A6908 for ; Tue, 24 Nov 2009 12:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+2xQFCQ2tgh for ; Tue, 24 Nov 2009 12:42:21 -0800 (PST) Received: from blu0-omc1-s1.blu0.hotmail.com (blu0-omc1-s1.blu0.hotmail.com [65.55.116.12]) by core3.amsl.com (Postfix) with ESMTP id 68B7A3A67C0 for ; Tue, 24 Nov 2009 12:42:21 -0800 (PST) Received: from BLU137-DS1 ([65.55.116.8]) by blu0-omc1-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Nov 2009 12:42:17 -0800 X-Originating-IP: [64.134.238.98] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Thomas Narten'" , "'Ted Lemon'" References: <200911241930.nAOJUYtS006913@cichlid.raleigh.ibm.com> In-Reply-To: <200911241930.nAOJUYtS006913@cichlid.raleigh.ibm.com> Date: Tue, 24 Nov 2009 12:42:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcptPKqIn+kS/BNbRbWnxDtEMAO5sQACUD9w Content-Language: en-us X-OriginalArrivalTime: 24 Nov 2009 20:42:17.0128 (UTC) FILETIME=[9C52A280:01CA6D46] Cc: dna@ietf.org Subject: Re: [dna] Review of draft-ietf-dna-simple-11 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 20:42:22 -0000 Thomas Narten said: "Note, as a comparison point, a stack that does not implement DNA. When the node encounters a "link up" event, that presumably also implies a "link down" event preceding the "link up" event, and the default course of action should be to throw away all the old configuration information and then start the configuration process from scratch." [BA] Reception of a "link up" event doesn't necessarily imply a previous "link down" event, nor should reception of either a "link down" or a "link up" event necessarily result in throwing away old configuration Information. As Ted noted, a "Link Up" event can be received as a result of jitter on wireless interfaces, in which case the IP address might have remained unchanged. A "Link Down" indication can be followed by a "Link Up" for the same network, so that discarding configuration Information in this case may also not be a good idea. See RFC 4907 for more discussion on this. From mellon@fugue.com Tue Nov 24 12:50:06 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0FB3A6978 for ; Tue, 24 Nov 2009 12:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRJqydwhcQyu for ; Tue, 24 Nov 2009 12:50:05 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by core3.amsl.com (Postfix) with ESMTP id C14E23A6877 for ; Tue, 24 Nov 2009 12:50:05 -0800 (PST) Received: from [192.168.1.43] (pool-173-68-246-74.nycmny.east.verizon.net [173.68.246.74]) by toccata.fugue.com (Postfix) with ESMTPSA id E077F34E4643; Tue, 24 Nov 2009 13:53:07 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ted Lemon In-Reply-To: <200911241930.nAOJUYtS006913@cichlid.raleigh.ibm.com> Date: Tue, 24 Nov 2009 15:49:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <662DC005-A950-404E-AA47-F1BF43B6E9E0@fugue.com> References: <200911241930.nAOJUYtS006913@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1077) Cc: dna@ietf.org Subject: Re: [dna] Review of draft-ietf-dna-simple-11 X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 20:50:06 -0000 On Nov 24, 2009, at 2:30 PM, Thomas Narten wrote: > Note, as a comparison point, a stack that does not implement DNA. When > the node encounters a "link up" event, that presumably also implies a > "link down" event preceding the "link up" event, and the default > course of action should be to throw away all the old configuration > information and then start the configuration process from scratch. Nope, a device that doesn't implement DNA doesn't detect these events. = It's possible that a device might detect network attachment badly, which = is the point of this document, but if you are noticing link = transactions, by definition you are detecting network attachment. From snarayanan@csumb.edu Wed Nov 25 11:34:07 2009 Return-Path: X-Original-To: dna@core3.amsl.com Delivered-To: dna@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0083A6B27 for ; Wed, 25 Nov 2009 11:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WtX9+bkOGgA for ; Wed, 25 Nov 2009 11:34:06 -0800 (PST) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by core3.amsl.com (Postfix) with SMTP id 9EC183A6B0C for ; Wed, 25 Nov 2009 11:34:05 -0800 (PST) Received: from source ([209.85.211.194]) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKSw2GqLPiz9sPw0Fq9lT2/gNTqEy6sig7@postini.com; Wed, 25 Nov 2009 11:34:01 PST Received: by ywh32 with SMTP id 32so27782ywh.14 for ; Wed, 25 Nov 2009 11:34:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.115.4 with SMTP id s4mr775158anm.81.1259177640183; Wed, 25 Nov 2009 11:34:00 -0800 (PST) In-Reply-To: <4AEA0FCE.4000704@piuha.net> References: <4ADE2B90.6060900@ericsson.com> <4AEA0FCE.4000704@piuha.net> From: Sathya Narayanan Date: Wed, 25 Nov 2009 11:33:40 -0800 Message-ID: To: Jari Arkko Content-Type: multipart/alternative; boundary=001636ed6d43f3c7d604793723c6 Cc: "dna@ietf.org" Subject: Re: [dna] Comments on draft-ietf-dna-protocol X-BeenThere: dna@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DNA working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 19:34:08 -0000 --001636ed6d43f3c7d604793723c6 Content-Type: text/plain; charset=ISO-8859-1 Jari I have incorporated your comments in the document. I am going to submit the modified draft to IETF so that we have a current draft for everybody to review. Few followups: Even though this >> document recommends the use of a prefix as the representative of the >> link, future specifications can use the Learned Prefix Option to >> include a non-prefix identifier as long as this identifier is 128 bit >> long to avoid collision with any currently assigned prefix. So, any >> future non-prefix link identifier MUST be 128 bits long. >> 5.1.6.3.1 Using non-prefix identifier as common prefix >> > > I felt that this extensibility confused the document a little bit. Could > this be removed? > The non-prefix link identifier: if my memory serves me right, we added this to allow for the possibility of using other identifiers from underlying technologies (in particular WiMAX, I think). I removed the reference to non-prefix link identifiers from the document. > > DNAv6 avoids this delay by using a different mechanism to ensure that >> two routers will not respond at exactly the same time while allowing >> one of the routers on the link to respond immediately. The results of >> that function are then compared to create >> a ranking, and the ranking determines the delay each router will use >> when responding to the RS. The router which is ranked as #0 will >> respond with a zero delay. >> >> > > Do I understand correctly that there will still be several responses to a > single RS? Perhaps this should be highlighted. Note that that your scheme > does not provide the same overall limit on the number of RAs appearing on > the link as the rate limit defined in RFC 4861. > I added an explicit sentence "This modified mechanism replaces the rate limit on responses to RS required by > 4.1 New Flags >> >> This document defines two new flags to be exchanged between the >> router and hosts. >> > I'd like to see these flags in the extension option defined in RFC 5075, > not directly in the RA header. > If my memory serves me right, we explicitly removed any specific packet format or option format information from this memo to avoid any confusion in terms of its readiness to be implemented. If we are going to publish this as an 'experimental' or 'informational' RFC, is it ok to include packet formats in the document. For now, I just included a single sentence: The flags and the options MUST be implemented using Router Advertisement Flags option specified in RFC 5075 . Note that this smallest prefix >> is the smallest of all the prefixes configured on the routers on the >> link and may not be the smallest prefix used in the link through >> stateful address configuration. >> >> > > Although, at least currently, prefixes used even for stateful address > autoconfiguration come from RAs. > Hmmm ... I am not sure what you want me to do here. I just added this sentence at the end of the previous para. "Although, at the time of the writing of this memo, prefixes used even for stateful address autoconfiguration come from RAs." > > Whenever a router sends an RA, whether solicited or unsolicited, it >> MUST include the common prefix in it. Hence, all RAs MUST carry the >> common prefix except the abbreviated RA message sent in response to a >> RS with LO. >> > > I guess I am missing the point of having BOTH the landmark AND the common > prefix. Is there some difference in use that prevents just selecting one, > and sticking to that? > > And if the RAs responding to LO can skip the common prefix, why is it so > important to include the common prefix in other RAs? Important enough that a > MUST is needed? Or, if the MUST is really needed, is there something that > breaks when use just the landmark option? > Again, if my memory serves me right :-), we do need both of them: the idea was to allow LO as an efficient way of asking "Am I still on the link with this Landmark?" and get an answer "yes/no" - while Complete RA had other advantages (backward compatible with non-DNA hosts is the most important of them, I think) - so if the complete RA is being broken up we need to have something common across the RAs to avoid uncessary link change detection. > Missing things: I did not see a discussion of how prefixes or routers get > removed from the host or router data structures. > Evey data structure suggested has an associated expiry time through which the content will be removed. We don't have any specific text to that end, do you think we need to add something? > > received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA >> > > It seems weird that you refer to the old 2461 here. Also, is the procedure > presented in Section 5.2.7.3 according to the current understanding of the > M&O bits? > I changed references to 2461 to 4861 and removed the specific section number. I am not sure I know the answer to your question - I don't know what is the current understanding of M&O bits - I am hoping somebody can respond to this; I will also look into it. > > 6.3 Tentative options >> > If you refer to draft-ietf-dna-tentative, do you need this section? > I am not sure - for now I am leaving the section in. > > SEND says that DAD defenses MAY be accepted even from non SEND nodes >> > > ... according to the SEND specification (RFC 3971 Section N.N) DAD defenses > ... > > SEND says that DAD defenses MAY be accepted even from non SEND nodes >> for the first configured address [4]. >> >> While deconfiguring the address is a valid action in the case where a >> host collides with another address owner after arrival on a new link, >> In the case that the host returns immediately to the same link, such >> a DAD defense NA message may be a denial-of-service attempt. >> >> > It seems that there are two separate cases. I believe 3971 & 3972 still > hold: whenever you create a new address, you should not accept collisions > beyond a certain collision count. However, IF you have confirmed that you > re-attached to the same link... I would not run DAD. > I need clarification on this point: if we decide not to run DAD, we have to make changes in other places: particularly Section 5.2.7. says "If the host determines from the received RAs that it has not moved to a new link (i.e. the link has not changed) and the previous state of an address was "Optimistic", then the host MUST send an NS to confirm that the address is unique on the link. This is required because optimistic Duplicate Address Detection may not have completed on the previous point of attachment, so the host may not have confirmed address uniqueness. " Do you want to me change this as well? There is reason given here for doing oDAD, which we need to be careful about? Sathya --001636ed6d43f3c7d604793723c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jari

I have incorporated your comments in the document. I am going t= o submit the modified draft to IETF so that we have a current draft for eve= rybody to review.

Few followups:

Even though this
=A0 document recommends the use of a prefix as the representative of the =A0 link, future specifications can use the Learned Prefix Option to
=A0 include a non-prefix identifier as long as this identifier is 128 bit<= br> =A0 long to avoid collision with any currently assigned prefix. =A0So, any=
=A0 future non-prefix link identifier MUST be 128 bits long.
=A05.1.6.3.1 =A0Using non-prefix identifier as common prefix

I felt that this extensibility confused the document a little bit. Could th= is be removed?
The non-prefix link identifier: if my m= emory serves me right, we added this to allow for the possibility of using other identifiers from underlying technologies (in particular WiMAX, I think). I removed the reference to non-prefix link identifiers from the document.
=A0

=A0 DNAv6 avoids this delay by using a different mechanism to ensure that<= br> =A0 two routers will not respond at exactly the same time while allowing =A0 one of the routers on the link to respond immediately. The results of = that function are then compared to create
=A0 a ranking, and the ranking determines the delay each router will use =A0 when responding to the RS. =A0The router which is ranked as #0 will =A0 respond with a zero delay.
=A0

Do I understand correctly that there will still be several responses to a s= ingle RS? Perhaps this should be highlighted. Note that that your scheme do= es not provide the same overall limit on the number of RAs appearing on the= link as the rate limit defined in RFC 4861.
I added an explicit sentence "This modified mechanis= m replaces the rate limit on responses to RS required by <xref target=3D'RFC4861 />&q= uot; - Is this what you had in mind? I also replaced all reference to 2461 = with 4861; since I haven't been involved in IETF for couple of years no= w, I just want to make sure that the changes from 2461 to 4861 is not going= to affect the original thinking of the DNA design. If somebody could comme= nt on that, that would be great.
=A0

4.1 =A0New Flags

=A0 This document defines two new flags to be exchanged between the
=A0 router and hosts.
I'd like to see these flags in the extension option defined in RFC 5075= , not directly in the RA header.
If my memory serves m= e right, we explicitly removed any specific packet format or option format = information from this memo to avoid any confusion in terms of its readiness= to be implemented. If we are going to publish this as an 'experimental= ' or 'informational' RFC,=A0 is it ok to include packet formats= in the document. For now, I just included a single sentence:=A0 The flags = and the options MUST be implemented using Router Advertisement Flags option= specified in RFC 5075 <xref target=3D'RFC5075' />.

Note that this smallest prefix
=A0 is the smallest of all the prefixes configured on the routers on the =A0 link and may not be the smallest prefix used in the link through =A0 = stateful address configuration.
=A0

Although, at least currently, prefixes used even for stateful address autoc= onfiguration come from RAs.
Hmmm ... I am not sure wha= t you want me to do here. I just added this sentence at the end of the prev= ious para. "Although, at the time of the writing of this memo, prefixe= s used even for stateful address autoconfiguration come from RAs."

=A0

=A0 Whenever a router sends an RA, whether solicited or unsolicited, it =A0 MUST include the common prefix in it. =A0Hence, all RAs MUST carry the=
=A0 common prefix except the abbreviated RA message sent in response to a<= br> =A0 RS with LO.

I guess I am missing the point of having BOTH the landmark AND the common p= refix. Is there some difference in use that prevents just selecting one, an= d sticking to that?

And if the RAs responding to LO can skip the common prefix, why is it so im= portant to include the common prefix in other RAs? Important enough that a = MUST is needed? Or, if the MUST is really needed, is there something that b= reaks when use just the landmark option?
Again, if my memory serves me right :-), we do need both = of them: the idea was to allow LO as an efficient way of asking "Am I = still on the link with this Landmark?" and get an answer "yes/no&= quot; - while Complete RA had other advantages (backward compatible with no= n-DNA hosts is the most important of them, I think) - so if the complete RA= is being broken up we need to have something common across the RAs to avoi= d uncessary link change detection.=A0


Missing things: I did not see a discussion of how prefixes or routers get r= emoved from the host or router data structures.
Evey d= ata structure suggested has an associated expiry time through which the con= tent will be removed. We don't have any specific text to that end, do y= ou think we need to add something?

=A0

=A0 received RAs as in Section 5.5.3 of RFC 2461 [3]. =A0That is, if an RA=

It seems weird that you refer to the old 2461 here. Also, is the procedure = presented in Section 5.2.7.3 according to the current understanding of the = M&O bits?

I changed references to 2461 to 4861= and removed the specific section number. I am not sure I know the answer t= o your question - I don't know what is the current understanding of M&a= mp;O bits - I am hoping somebody can respond to this; I will also look into= it.
=A0

6.3 =A0Tentative options
If you refer to draft-ietf-dna-tentative, do you need this section?

I am not sure - for now I am leaving the section in.
= =A0

=A0 SEND says that DAD defenses MAY be accepted even from non SEND nodes

... according to the SEND specification (RFC 3971 Section N.N) DAD defenses= ...

SEND says that DAD defenses MAY be accepted even from non SEND nodes
for the first configured address [4].

While deconfiguring the address is a valid action in the case where a
host collides with another address owner after arrival on a new link,
In the case that the host returns immediately to the same link, such
a DAD defense NA message may be a denial-of-service attempt.
=A0
It seems that there are two separate cases. I believe 3971 & 3972 still= hold: whenever you create a new address, you should not accept collisions = beyond a certain collision count. However, IF you have confirmed that you r= e-attached to the same link... I would not run DAD.

I need clarification on this point: if we decide not = to run DAD, we have to make changes in other places: particularly Section 5= .2.7. says
"If the host determines from the received RAs that it ha= s not moved to
   a new link (i.e. the link has not changed) and the previous state o=
f
   an address was "Optimistic", then the host MUST send an N=
S to confirm
   that the address is unique on the link.  This is require=
d because


   optimistic Duplicate Address Detection may not have completed on the
=
   previous point of attachment, so the host may not have confirmed
   a=
ddress uniqueness.
"
=A0Do you want to me change this as w= ell? There is reason given here for doing oDAD, which we need to be careful= about?

Sathya


--001636ed6d43f3c7d604793723c6--