From jari.arkko@piuha.net Thu Jul 9 05:28:24 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 BD9EA28C1CD for ; Thu, 9 Jul 2009 05:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 EGYeD5fHHMHr for ; Thu, 9 Jul 2009 05:28:23 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id CCBDF3A6BB9 for ; Thu, 9 Jul 2009 05:28:22 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id F2DEA198702; Thu, 9 Jul 2009 15:28:48 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 083381986EE; Thu, 9 Jul 2009 15:28:46 +0300 (EEST) Message-ID: <4A55E27D.80200@piuha.net> Date: Thu, 09 Jul 2009 15:28:45 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: draft-ietf-dna-simple@tools.ietf.org, dna@ietf.org, "Suresh Krishnan (QB/EMC)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [dna] AD review of 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: Thu, 09 Jul 2009 12:28:24 -0000 Suresh, I have reviewed this draft. Overall, the draft was easy to read and well written. I have no problem with the specified algorithms. However, the draft appears to contain a fair amount of extra material on Fast RAs and the full-blown dna-protocol that WG worked earlier on. These need to be removed; the specification can and should stand on its own, and not depend on these other components. In addition, there are a few technical issues, including the use of SLLA and lack of clear specification for a general purpose implementation wrt configuration. Here are my specific comments: Substantial: > The probing node SHOULD include a Source link-layer address option in > the probe messages. If the node believes that the source address of > the NS may not be unique on the newly attached link, it MAY omit the > Source link-layer address option in the probe messages. I would like to understand this better. How does a general purpose operating system implementation deal with the above? How does it know that "the source address of the NS may not be unique"? AFAICT, if you omit the SLLA and no link change happened, then most likely the router will remember your NC anyway, and be able to respond. However, if it does not remember you, a new NS/NA would be required, but DNA would still succeed, albeit a bit slower. However, if the host did move to a new link, then including the SLLA might cause disruption for another host that already holds the same address but uses a different link layer address. Why is the recommendation written as it is above? Is the assumption that colliding addresses are so rare that the optimization makes sense? On the other hand, it would appear that even without the SLLA DNA would still work in most cases. In any case, I don't think we can require general purpose implementations to assess the likelihood of collisions. Perhaps it would be easier to require that by default, no SLLA is included and that only through specific configuration option the SLLA use can be turned on and DNA made to operate faster/more reliably. > For the purpose of sending neighbor solicitations to previous > routers, the host first needs to pick a subset of operable IPv6 > addresses (candidate set) that it wishes to use. How this subset of > addresses is picked is based on host configuration. e.g. The host > may select configured addresses from each of zero, one or two > previously connected links. Please specify a default strategy. E.g., "How this subset of addresses is picked is based on host configuration. By default the host should select configured addresses from two previously connected links." > Where flooding may cause performance issues within the LAN, host > SHOULD limit the number of unicast solicitations. Again, the guidance for general purpose implementations in inadequate. Please specify a default strategy. I believe limiting the number of unicast solicitations to some small number (4?) by default is adequate (there are a number of messages on a new link even on DNAv4 and regular ND). > The probing node SHOULD NOT include a Source link-layer address > option if it has not performed duplicate address detection [RFC4862], > for the source address of the NS, on the newly attached link. > Performed DAD, when? Presumably it has been performed when the address first configured, no? And since DNA is the first thing that runs after a link change, DAD has not been run at this point either. So what does your recommendation really mean here? Never include SLLA? In any case, at this point we do not yet *know* if we are on a newly attached link or not. Therefore, we do not know if we've run DAD in the past on this link. Please clarify. > Hosts checking their network attachment are unsure of their address > status, and may be using Tentative link-layer addressing information > in their router or neighbour solicitations. > > A router which desires to support hosts' DNA operations MUST process > Tentative Options from unicast source addressed Router and Neighbour > Solicitations, as described in [I-D.ietf-dna-tentative]. This is the first time dna-tentative is referenced in this document. I wonder if there's really a need to have a normative reference, or even mention this. > 7. Constants > > > These constants are described as in [I-D.ietf-dna-protocol]. > > UNICAST_RA_INTERVAL > > Definition: The interval corresponding to the maximum average > rate of Router Solicitations that the router is prepared to > service with unicast responses. This is the interval at which > the token bucket controlling the unicast responses is > replenished. > > Value: 50 milliseconds > > MAX_UNICAST_RA_BURST > > Definition: The maximum size burst of Router Solicitations that > the router is prepared to service with unicast responses. This > is the maximum number of tokens allowed in the token bucket > controlling the unicast responses. > > Value: 20 > None of these appear to have anything to do with the Simple DNA procedure. Please remove. The only item that I can see be of relevance in this section is SEND_NA_GRACE_TIME. > When providing fast responses to router solicitations, it is possible > to cause collisions with other signaling packets on contention based > media. This can cause repeated packet loss or delay when multiple > routers are present on the link. > > As such the fast router advertisement system is NOT RECOMMENDED in > this form for media which are susceptible to collision loss. Such > environments may be better served using the procedures defined in > [I-D.ietf-dna-protocol]. This does not appear to have anything to do with Simple DNA either (router-side fast responses are not a subject of this specification). Delete? > The host MAY delay SEND_NA_GRACE_TIME after transmission before > adopting a new default router, if it is operating on a network where > there is significant threat of RA spoofing. I would simply say that this delay MAY be imposed when the host's current default router is a SEND-secured one. This prevents the downgrade from SEND to non-SEND, but does not require any configuration, and it doesn't slow things down when you were already using a non-SEND router. > It is easy for hosts soliciting without SEND to deplete a SEND > router's fast advertisement token buckets, and consume additional > bandwidth. As such, a router MAY choose to preserve a portion of > their token bucket to serve solicitations with SEND signatures. Again, this has very little to do with this specification. Move this to the fast RA spec instead. Editorial: Move draft-ietf-dna-protocol to informative references. > After the indication is received, the host considers all currently > configured (non-tentative) IP addresses to as deprecated until the > change detection process completes. s/to as/to be/ > addresses is picked is based on host configuration. e.g. The host s/The/the/ > If systems do not meet these assumptions or if systems seek > deterministic change detection operations they are directed to follow > the complete dna procedure as defined in [I-D.ietf-dna-protocol]. I would just delete this. I do not think we want to make what sounds like a fairly strong recommendation. Section 4.5.1 mentions that there are no options, while Setion 4.5.2 does not. > message contains an Identity Addociation for either a Temporary Association? Jari From bernard_aboba@hotmail.com Thu Jul 9 10:20: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 D030428C15D for ; Thu, 9 Jul 2009 10:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 RJxeh7Kw+CYE for ; Thu, 9 Jul 2009 10:20:25 -0700 (PDT) Received: from blu0-omc2-s6.blu0.hotmail.com (blu0-omc2-s6.blu0.hotmail.com [65.55.111.81]) by core3.amsl.com (Postfix) with ESMTP id B75FF3A6CEE for ; Thu, 9 Jul 2009 10:20:24 -0700 (PDT) Received: from BLU137-W1 ([65.55.111.71]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jul 2009 10:20:53 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_1aaaf575-eba3-4bda-8f4b-0546a95cb58f_" X-Originating-IP: [24.16.113.61] From: Bernard Aboba To: Jari Arkko , , , Suresh Krishnan Date: Thu, 9 Jul 2009 10:20:53 -0700 Importance: Normal In-Reply-To: <4A55E27D.80200@piuha.net> References: <4A55E27D.80200@piuha.net> MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2009 17:20:53.0064 (UTC) FILETIME=[9CA74C80:01CA00B9] Subject: Re: [dna] AD review of 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: Thu, 09 Jul 2009 17:20:26 -0000 --_1aaaf575-eba3-4bda-8f4b-0546a95cb58f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > The probing node SHOULD include a Source link-layer address option in=20 > > the probe messages. If the node believes that the source address of=20 > > the NS may not be unique on the newly attached link=2C it MAY omit the= =20 > > Source link-layer address option in the probe messages. >=20 > I would like to understand this better. How does a general purpose=20 > operating system implementation deal with the above? How does it know=20 > that "the source address of the NS may not be unique"? The goal of DNA is not only to detect network attachment=2C but also to=20 seed the ND cache so as to immediately enable incoming and outgoing=20 communications. By including the SLLA in unicast probe messages=2C the node can seed the ND cache of the router tgo enable communications in the opposite direction. =20 > AFAICT=2C if you omit the SLLA and no link change happened=2C then most=20 > likely the router will remember your NC anyway=2C and be able to respond.= =20 Only if the ND cache entry had not expired. Remember=2C the biggest win for DNA is when moving between links.=20 > However=2C if it does not remember you=2C a new NS/NA would be required= =2C but=20 > DNA would still succeed=2C albeit a bit slower. > However=2C if the host did move to a new link=2C then including the SLLA= =20 > might cause disruption for another host that already holds the same=20 > address but uses a different link layer address. The probes are sent to a unicast IP and MAC address. Therefore they can only be received if the node moves to a link on which the node has a valid IP address.=20 > Why is the recommendation written as it is above? Is the assumption that= =20 > colliding addresses are so rare that the optimization makes sense? On=20 > the other hand=2C it would appear that even without the SLLA DNA would=20 > still work in most cases. There are situations in which a node is unlikely to encounter collisions=2C and therefore DAD is not required. One is where the IP addre= ss=20 was allocated via DHCP=2C and the lease has not yet expired. If the DHCP=20 server is properly implemented=2C it will not hand out the same address to= =20 more than one host. DNAv4 makes this assumption.=20 During development of the draft=2C there was discussion as to whether there were other situations in which this assumption could be made as well.=20 For example=2C in situations where an IPv6 address is not manually or randomly assigned=2C but is based on a MAC address=2C would it be=20 reasonable to include the SLLA (and also not to do DAD). As I recall=2C the decision was made *not* to override any of the existing recommendations on DAD. For consistency's sake then=2C the SLLA should not be included in those same cases.=20 > In any case=2C I don't think we can require general purpose=20 > implementations to assess the likelihood of collisions.=20 Sure -- but the document should be written so as to clearly spell out the situations under which the SLLA is included. Those are the same circumstances in which the document should enable DAD to be avoided. However=2C currently the document is not consistent in this regard.=20 > Perhaps it would be easier to require that by default=2C no SLLA is incl= uded=20 > and that only through specific configuration option the SLLA use can be = turned on and=20 > DNA made to operate faster/more reliably. If the SLLA is only included in situations where DAD can be avoided=2C then I don't think this is an issue. That's how DNAv4 works.=20 > > For the purpose of sending neighbor solicitations to previous > > routers=2C the host first needs to pick a subset of operable IPv6 > > addresses (candidate set) that it wishes to use. How this subset of > > addresses is picked is based on host configuration. e.g. The host > > may select configured addresses from each of zero=2C one or two > > previously connected links. >=20 > Please specify a default strategy. E.g.=2C "How this subset of addresses= =20 > is picked is based on host configuration. By default the host should=20 > select configured addresses from two previously connected links." DNAv4 enables the host to send probes to all routers representing links with valid IP addresses. There is no language about subsets. This hasn't been an issue in practice=2C since a host will typically not have a large n= umber of valid IP addresses. So I'd prefer that this language be removed entirel= y.=20 > > Where flooding may cause performance issues within the LAN=2C host=20 > > SHOULD limit the number of unicast solicitations. This is a red herring that should have been removed from the document long ago. The initial deployment of DNAv4 uncovered some AP implementations that were non-compliant with IEEE 802.1D=2C but those issues have long sinc= e been fixed. There is no known "flooding" issue at this time.=20 > Again=2C the guidance for general purpose implementations in inadequate.= =20 > Please specify a default strategy. I believe limiting the number of=20 > unicast solicitations to some small number (4?) by default is adequate=20 > (there are a number of messages on a new link even on DNAv4 and regular N= D). >=20 > > The probing node SHOULD NOT include a Source link-layer address > > option if it has not performed duplicate address detection [RFC4862]= =2C > > for the source address of the NS=2C on the newly attached link. >=20 > Performed DAD=2C when? Presumably it has been performed when the address= =20 > first configured=2C no? And since DNA is the first thing that runs after = a=20 > link change=2C DAD has not been run at this point either. So what does=20 > your recommendation really mean here? Never include SLLA? It means that you only include SLLA in situations in which DAD can be avoided (such as where DHCPv6 is in use).=20 =20 > In any case=2C at this point we do not yet *know* if we are on a newly=20 > attached link or not. Therefore=2C we do not know if we've run DAD in the= =20 > past on this link. The probe is constructed to test whether the node is on the link or not.=20 If the address was assigned by DHCPv6 on the link=2C then the probe can omit the SLLA and if the probe succeeds=2C then DAD is not required.=20 >=20 > Please clarify. >=20 > > Hosts checking their network attachment are unsure of their address > > status=2C and may be using Tentative link-layer addressing informati= on > > in their router or neighbour solicitations. > > > > A router which desires to support hosts' DNA operations MUST process > > Tentative Options from unicast source addressed Router and Neighbour > > Solicitations=2C as described in [I-D.ietf-dna-tentative]. >=20 > This is the first time dna-tentative is referenced in this document. I=20 > wonder if there's really a need to have a normative reference=2C or even= =20 > mention this. I don't think so=2C since the WG decided to not modify DAD procedures except for the DHCPv6 case.=20 >=20 > > 7. Constants > > > > > > These constants are described as in [I-D.ietf-dna-protocol]. > > > > UNICAST_RA_INTERVAL > > > > Definition: The interval corresponding to the maximum average > > rate of Router Solicitations that the router is prepared to > > service with unicast responses. This is the interval at which > > the token bucket controlling the unicast responses is > > replenished. > > > > Value: 50 milliseconds > > > > MAX_UNICAST_RA_BURST > > > > Definition: The maximum size burst of Router Solicitations tha= t > > the router is prepared to service with unicast responses. Thi= s > > is the maximum number of tokens allowed in the token bucket > > controlling the unicast responses. > > > > Value: 20 > > >=20 > None of these appear to have anything to do with the Simple DNA=20 > procedure. Please remove. The only item that I can see be of relevance=20 > in this section is SEND_NA_GRACE_TIME. I agree. Not sure why this material remains in the document.=20 > > When providing fast responses to router solicitations=2C it is possi= ble > > to cause collisions with other signaling packets on contention based > > media. This can cause repeated packet loss or delay when multiple > > routers are present on the link. > > > > As such the fast router advertisement system is NOT RECOMMENDED in > > this form for media which are susceptible to collision loss. Such > > environments may be better served using the procedures defined in > > [I-D.ietf-dna-protocol]. >=20 > This does not appear to have anything to do with Simple DNA either=20 > (router-side fast responses are not a subject of this specification).=20 > Delete? Yup.=20 > > The host MAY delay SEND_NA_GRACE_TIME after transmission before > > adopting a new default router=2C if it is operating on a network whe= re > > there is significant threat of RA spoofing. >=20 > I would simply say that this delay MAY be imposed when the host's=20 > current default router is a SEND-secured one. This prevents the=20 > downgrade from SEND to non-SEND=2C but does not require any configuration= =2C=20 > and it doesn't slow things down when you were already using a non-SEND=20 > router. >=20 > > It is easy for hosts soliciting without SEND to deplete a SEND > > router's fast advertisement token buckets=2C and consume additional > > bandwidth. As such=2C a router MAY choose to preserve a portion of > > their token bucket to serve solicitations with SEND signatures. >=20 > Again=2C this has very little to do with this specification. Move this to= =20 > the fast RA spec instead. >=20 > Editorial: >=20 > Move draft-ietf-dna-protocol to informative references. Right.=20 --_1aaaf575-eba3-4bda-8f4b-0546a95cb58f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B >=3B The probing node SHOULD include a Source link-layer address o= ption in
>=3B >=3B the probe messages. If the node believes that t= he source address of
>=3B >=3B the NS may not be unique on the newl= y attached link=2C it MAY omit the
>=3B >=3B Source link-layer addr= ess option in the probe messages.
>=3B
>=3B I would like to unde= rstand this better. How does a general purpose
>=3B operating system= implementation deal with the above? How does it know
>=3B that "the = source address of the NS may not be unique"?

The goal of DNA is not = only to detect network attachment=2C but also to
seed the ND cache so a= s to immediately enable incoming and outgoing
communications. =3B B= y including the SLLA in unicast probe messages=2C the
node can seed the = ND cache of the router tgo enable communications
in the opposite directi= on. =3B

>=3B AFAICT=2C if you omit the SLLA and no link chang= e happened=2C then most
>=3B likely the router will remember your NC = anyway=2C and be able to respond.

Only if the ND cache entry had no= t expired. =3B =3B Remember=2C the biggest win
for DNA is when m= oving between links.

>=3B However=2C if it does not remember you= =2C a new NS/NA would be required=2C but
>=3B DNA would still succeed= =2C albeit a bit slower.

>=3B However=2C if the host did move to a= new link=2C then including the SLLA
>=3B might cause disruption for = another host that already holds the same
>=3B address but uses a diff= erent link layer address.

The probes are sent to a unicast IP and MA= C address. =3B Therefore they
can only be received if the node moves= to a link on which the node has
a valid IP address.

>=3B Why = is the recommendation written as it is above? Is the assumption that
&g= t=3B colliding addresses are so rare that the optimization makes sense? On =
>=3B the other hand=2C it would appear that even without the SLLA DNA= would
>=3B still work in most cases.

There are situations in = which a node is unlikely to encounter
collisions=2C and therefore DAD is= not required. =3B One is where the IP address
was allocated via DH= CP=2C and the lease has not yet expired. =3B If the DHCP
server is = properly implemented=2C it will not hand out the same address to
more t= han one host. =3B DNAv4 makes this assumption.

During developme= nt of the draft=2C there was discussion as to whether there
were other s= ituations in which this assumption could be made as well.
For example= =2C in situations where an IPv6 address is not manually or
randomly assi= gned=2C but is based on a MAC address=2C would it be
reasonable to incl= ude the SLLA (and also not to do DAD). =3B =3B As I
recall=2C th= e decision was made *not* to override any of the existing
recommendation= s on DAD. =3B For consistency's sake then=2C the SLLA
should not be = included in those same cases.

>=3B In any case=2C I don't think w= e can require general purpose
>=3B implementations to assess the like= lihood of collisions.

Sure -- but the document should be written so= as to clearly spell
out the situations under which the SLLA is included= . =3B Those are the
same circumstances in which the document should = enable DAD to
be avoided. =3B However=2C currently the document is n= ot consistent in
this regard.

>=3B Perhaps it would =3B be= easier to require that by default=2C no SLLA is included
>=3B and th= at only =3B through specific configuration option the SLLA use can be t= urned on and
>=3B DNA made to operate faster/more reliably.

If= the SLLA is only included in situations where DAD can be avoided=2C thenI don't think this is an issue. =3B That's how DNAv4 works.

&= gt=3B >=3B For the purpose of sending neighbor solicitations to previo= us
>=3B >=3B routers=2C the host first needs to pick a subset of = operable IPv6
>=3B >=3B addresses (candidate set) that it wishes = to use. How this subset of
>=3B >=3B addresses is picked is base= d on host configuration. e.g. The host
>=3B >=3B may select conf= igured addresses from each of zero=2C one or two
>=3B >=3B previo= usly connected links.
>=3B
>=3B Please specify a default strateg= y. E.g.=2C "How this subset of addresses
>=3B is picked is based on h= ost configuration. By default the host should
>=3B select configured = addresses from two previously connected links."

DNAv4 enables the ho= st to send probes to all routers representing links
with valid IP addres= ses. =3B There is no language about subsets. =3B This hasn't
bee= n an issue in practice=2C since a host will typically not have a large numb= er
of valid IP addresses. =3B So I'd prefer that this language be re= moved entirely.

>=3B >=3B Where flooding may cause performance = issues within the LAN=2C host
>=3B >=3B SHOULD limit the number of = unicast solicitations.

This is a red herring that should have been r= emoved from the document long
ago. =3B The initial deployment of DNA= v4 uncovered some AP implementations
that were non-compliant with IEEE 8= 02.1D=2C but those issues have long since
been fixed. =3B There is n= o known "flooding" issue at this time.

>=3B Again=2C the guidance= for general purpose implementations in inadequate.
>=3B Please speci= fy a default strategy. I believe limiting the number of
>=3B unicast = solicitations to some small number (4?) by default is adequate
>=3B (= there are a number of messages on a new link even on DNAv4 and regular ND).=
>=3B
>=3B >=3B The probing node SHOULD NOT include a Sourc= e link-layer address
>=3B >=3B option if it has not performed dup= licate address detection [RFC4862]=2C
>=3B >=3B for the source ad= dress of the NS=2C on the newly attached link.
>=3B
>=3B Perform= ed DAD=2C when? Presumably it has been performed when the address
>= =3B first configured=2C no? And since DNA is the first thing that runs afte= r a
>=3B link change=2C DAD has not been run at this point either. So= what does
>=3B your recommendation really mean here? Never include S= LLA?

It means that you only include SLLA in situations in which DAD = can be
avoided (such as where DHCPv6 is in use).
 =3B
>=3B = In any case=2C at this point we do not yet *know* if we are on a newly
= >=3B attached link or not. Therefore=2C we do not know if we've run DAD i= n the
>=3B past on this link.

The probe is constructed to test= whether the node is on the link or not.
If the address was assigned by= DHCPv6 on the link=2C then the probe can
omit the SLLA and if the probe= succeeds=2C then DAD is not required.

>=3B
>=3B Please cla= rify.
>=3B
>=3B >=3B Hosts checking their network attachmen= t are unsure of their address
>=3B >=3B status=2C and may be usin= g Tentative link-layer addressing information
>=3B >=3B in their = router or neighbour solicitations.
>=3B >=3B
>=3B >=3B A r= outer which desires to support hosts' DNA operations MUST process
>=3B= >=3B Tentative Options from unicast source addressed Router and Neigh= bour
>=3B >=3B Solicitations=2C as described in [I-D.ietf-dna-ten= tative].
>=3B
>=3B This is the first time dna-tentative is refer= enced in this document. I
>=3B wonder if there's really a need to hav= e a normative reference=2C or even
>=3B mention this.

I don't = think so=2C since the WG decided to not modify DAD procedures
except for= the DHCPv6 case.

>=3B
>=3B >=3B 7. Constants
>=3B &= gt=3B
>=3B >=3B
>=3B >=3B These constants are described as= in [I-D.ietf-dna-protocol].
>=3B >=3B
>=3B >=3B UNICAS= T_RA_INTERVAL
>=3B >=3B
>=3B >=3B Definition: The in= terval corresponding to the maximum average
>=3B >=3B rate = of Router Solicitations that the router is prepared to
>=3B >=3B = service with unicast responses. This is the interval at which
>= =3B >=3B the token bucket controlling the unicast responses is>=3B >=3B replenished.
>=3B >=3B
>=3B >=3B = Value: 50 milliseconds
>=3B >=3B
>=3B >=3B MAX_UN= ICAST_RA_BURST
>=3B >=3B
>=3B >=3B Definition: The m= aximum size burst of Router Solicitations that
>=3B >=3B th= e router is prepared to service with unicast responses. This
>=3B >= =3B is the maximum number of tokens allowed in the token bucket>=3B >=3B controlling the unicast responses.
>=3B >=3B=
>=3B >=3B Value: 20
>=3B >=3B
>=3B
>=3B = None of these appear to have anything to do with the Simple DNA
>=3B = procedure. Please remove. The only item that I can see be of relevance
= >=3B in this section is SEND_NA_GRACE_TIME.

I agree. Not sure why = this material remains in the document.

>=3B >=3B When provid= ing fast responses to router solicitations=2C it is possible
>=3B >= =3B to cause collisions with other signaling packets on contention based=
>=3B >=3B media. This can cause repeated packet loss or delay w= hen multiple
>=3B >=3B routers are present on the link.
>=3B= >=3B
>=3B >=3B As such the fast router advertisement system is= NOT RECOMMENDED in
>=3B >=3B this form for media which are susce= ptible to collision loss. Such
>=3B >=3B environments may be bet= ter served using the procedures defined in
>=3B >=3B [I-D.ietf-dn= a-protocol].
>=3B
>=3B This does not appear to have anything to = do with Simple DNA either
>=3B (router-side fast responses are not a = subject of this specification).
>=3B Delete?

Yup.

>= =3B >=3B The host MAY delay SEND_NA_GRACE_TIME after transmission befo= re
>=3B >=3B adopting a new default router=2C if it is operating = on a network where
>=3B >=3B there is significant threat of RA sp= oofing.
>=3B
>=3B I would simply say that this delay MAY be impo= sed when the host's
>=3B current default router is a SEND-secured one= . This prevents the
>=3B downgrade from SEND to non-SEND=2C but does = not require any configuration=2C
>=3B and it doesn't slow things down= when you were already using a non-SEND
>=3B router.
>=3B
&g= t=3B >=3B It is easy for hosts soliciting without SEND to deplete a SE= ND
>=3B >=3B router's fast advertisement token buckets=2C and con= sume additional
>=3B >=3B bandwidth. As such=2C a router MAY cho= ose to preserve a portion of
>=3B >=3B their token bucket to serv= e solicitations with SEND signatures.
>=3B
>=3B Again=2C this ha= s very little to do with this specification. Move this to
>=3B the fa= st RA spec instead.
>=3B
>=3B Editorial:
>=3B
>=3B Mo= ve draft-ietf-dna-protocol to informative references.

Right.
= --_1aaaf575-eba3-4bda-8f4b-0546a95cb58f_-- From jari.arkko@piuha.net Thu Jul 9 11:04:47 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 F118628C178 for ; Thu, 9 Jul 2009 11:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 dDJHzZ-2vfyH for ; Thu, 9 Jul 2009 11:04:45 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 0D0D728C23B for ; Thu, 9 Jul 2009 11:04:34 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 020A219872A; Thu, 9 Jul 2009 21:05:00 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 468981986EE; Thu, 9 Jul 2009 21:05:00 +0300 (EEST) Message-ID: <4A56314B.5090509@piuha.net> Date: Thu, 09 Jul 2009 21:04:59 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Bernard Aboba References: <4A55E27D.80200@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org Subject: Re: [dna] AD review of 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: Thu, 09 Jul 2009 18:04:47 -0000 Bernard, Thanks for your response. I think I understand the logic better now. Suresh, can we change the draft as suggested by Bernard? Jari Bernard Aboba wrote: > > > The probing node SHOULD include a Source link-layer address option in > > > the probe messages. If the node believes that the source address of > > > the NS may not be unique on the newly attached link, it MAY omit the > > > Source link-layer address option in the probe messages. > > > > I would like to understand this better. How does a general purpose > > operating system implementation deal with the above? How does it know > > that "the source address of the NS may not be unique"? > > The goal of DNA is not only to detect network attachment, but also to > seed the ND cache so as to immediately enable incoming and outgoing > communications. By including the SLLA in unicast probe messages, the > node can seed the ND cache of the router tgo enable communications > in the opposite direction. > > > AFAICT, if you omit the SLLA and no link change happened, then most > > likely the router will remember your NC anyway, and be able to respond. > > Only if the ND cache entry had not expired. Remember, the biggest win > for DNA is when moving between links. > > > However, if it does not remember you, a new NS/NA would be required, > but > > DNA would still succeed, albeit a bit slower. > > > However, if the host did move to a new link, then including the SLLA > > might cause disruption for another host that already holds the same > > address but uses a different link layer address. > > The probes are sent to a unicast IP and MAC address. Therefore they > can only be received if the node moves to a link on which the node has > a valid IP address. > > > Why is the recommendation written as it is above? Is the assumption > that > > colliding addresses are so rare that the optimization makes sense? On > > the other hand, it would appear that even without the SLLA DNA would > > still work in most cases. > > There are situations in which a node is unlikely to encounter > collisions, and therefore DAD is not required. One is where the IP > address > was allocated via DHCP, and the lease has not yet expired. If the DHCP > server is properly implemented, it will not hand out the same address to > more than one host. DNAv4 makes this assumption. > > During development of the draft, there was discussion as to whether there > were other situations in which this assumption could be made as well. > For example, in situations where an IPv6 address is not manually or > randomly assigned, but is based on a MAC address, would it be > reasonable to include the SLLA (and also not to do DAD). As I > recall, the decision was made *not* to override any of the existing > recommendations on DAD. For consistency's sake then, the SLLA > should not be included in those same cases. > > > In any case, I don't think we can require general purpose > > implementations to assess the likelihood of collisions. > > Sure -- but the document should be written so as to clearly spell > out the situations under which the SLLA is included. Those are the > same circumstances in which the document should enable DAD to > be avoided. However, currently the document is not consistent in > this regard. > > > Perhaps it would be easier to require that by default, no SLLA is > included > > and that only through specific configuration option the SLLA use > can be turned on and > > DNA made to operate faster/more reliably. > > If the SLLA is only included in situations where DAD can be avoided, then > I don't think this is an issue. That's how DNAv4 works. > > > > For the purpose of sending neighbor solicitations to previous > > > routers, the host first needs to pick a subset of operable IPv6 > > > addresses (candidate set) that it wishes to use. How this subset of > > > addresses is picked is based on host configuration. e.g. The host > > > may select configured addresses from each of zero, one or two > > > previously connected links. > > > > Please specify a default strategy. E.g., "How this subset of addresses > > is picked is based on host configuration. By default the host should > > select configured addresses from two previously connected links." > > DNAv4 enables the host to send probes to all routers representing links > with valid IP addresses. There is no language about subsets. This hasn't > been an issue in practice, since a host will typically not have a > large number > of valid IP addresses. So I'd prefer that this language be removed > entirely. > > > > Where flooding may cause performance issues within the LAN, host > > > SHOULD limit the number of unicast solicitations. > > This is a red herring that should have been removed from the document long > ago. The initial deployment of DNAv4 uncovered some AP implementations > that were non-compliant with IEEE 802.1D, but those issues have long since > been fixed. There is no known "flooding" issue at this time. > > > Again, the guidance for general purpose implementations in inadequate. > > Please specify a default strategy. I believe limiting the number of > > unicast solicitations to some small number (4?) by default is adequate > > (there are a number of messages on a new link even on DNAv4 and > regular ND). > > > > > The probing node SHOULD NOT include a Source link-layer address > > > option if it has not performed duplicate address detection [RFC4862], > > > for the source address of the NS, on the newly attached link. > > > > Performed DAD, when? Presumably it has been performed when the address > > first configured, no? And since DNA is the first thing that runs > after a > > link change, DAD has not been run at this point either. So what does > > your recommendation really mean here? Never include SLLA? > > It means that you only include SLLA in situations in which DAD can be > avoided (such as where DHCPv6 is in use). > > > In any case, at this point we do not yet *know* if we are on a newly > > attached link or not. Therefore, we do not know if we've run DAD in the > > past on this link. > > The probe is constructed to test whether the node is on the link or not. > If the address was assigned by DHCPv6 on the link, then the probe can > omit the SLLA and if the probe succeeds, then DAD is not required. > > > > > Please clarify. > > > > > Hosts checking their network attachment are unsure of their address > > > status, and may be using Tentative link-layer addressing information > > > in their router or neighbour solicitations. > > > > > > A router which desires to support hosts' DNA operations MUST process > > > Tentative Options from unicast source addressed Router and Neighbour > > > Solicitations, as described in [I-D.ietf-dna-tentative]. > > > > This is the first time dna-tentative is referenced in this document. I > > wonder if there's really a need to have a normative reference, or even > > mention this. > > I don't think so, since the WG decided to not modify DAD procedures > except for the DHCPv6 case. > > > > > > 7. Constants > > > > > > > > > These constants are described as in [I-D.ietf-dna-protocol]. > > > > > > UNICAST_RA_INTERVAL > > > > > > Definition: The interval corresponding to the maximum average > > > rate of Router Solicitations that the router is prepared to > > > service with unicast responses. This is the interval at which > > > the token bucket controlling the unicast responses is > > > replenished. > > > > > > Value: 50 milliseconds > > > > > > MAX_UNICAST_RA_BURST > > > > > > Definition: The maximum size burst of Router Solicitations that > > > the router is prepared to service with unicast responses. This > > > is the maximum number of tokens allowed in the token bucket > > > controlling the unicast responses. > > > > > > Value: 20 > > > > > > > None of these appear to have anything to do with the Simple DNA > > procedure. Please remove. The only item that I can see be of relevance > > in this section is SEND_NA_GRACE_TIME. > > I agree. Not sure why this material remains in the document. > > > > When providing fast responses to router solicitations, it is possible > > > to cause collisions with other signaling packets on contention based > > > media. This can cause repeated packet loss or delay when multiple > > > routers are present on the link. > > > > > > As such the fast router advertisement system is NOT RECOMMENDED in > > > this form for media which are susceptible to collision loss. Such > > > environments may be better served using the procedures defined in > > > [I-D.ietf-dna-protocol]. > > > > This does not appear to have anything to do with Simple DNA either > > (router-side fast responses are not a subject of this specification). > > Delete? > > Yup. > > > > The host MAY delay SEND_NA_GRACE_TIME after transmission before > > > adopting a new default router, if it is operating on a network where > > > there is significant threat of RA spoofing. > > > > I would simply say that this delay MAY be imposed when the host's > > current default router is a SEND-secured one. This prevents the > > downgrade from SEND to non-SEND, but does not require any > configuration, > > and it doesn't slow things down when you were already using a non-SEND > > router. > > > > > It is easy for hosts soliciting without SEND to deplete a SEND > > > router's fast advertisement token buckets, and consume additional > > > bandwidth. As such, a router MAY choose to preserve a portion of > > > their token bucket to serve solicitations with SEND signatures. > > > > Again, this has very little to do with this specification. Move this to > > the fast RA spec instead. > > > > Editorial: > > > > Move draft-ietf-dna-protocol to informative references. > > Right. > From suresh.krishnan@ericsson.com Thu Jul 9 15:25: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 D624628C267 for ; Thu, 9 Jul 2009 15:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 UaO8Cc2nZDNM for ; Thu, 9 Jul 2009 15:25:12 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 5601628C266 for ; Thu, 9 Jul 2009 15:25:12 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n69MPXlU019347; Thu, 9 Jul 2009 17:25:33 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jul 2009 17:25:26 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jul 2009 17:25:25 -0500 Message-ID: <4A566E17.7010907@ericsson.com> Date: Thu, 09 Jul 2009 18:24:23 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Jari Arkko References: <4A55E27D.80200@piuha.net> <4A56314B.5090509@piuha.net> In-Reply-To: <4A56314B.5090509@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2009 22:25:25.0591 (UTC) FILETIME=[27EDA670:01CA00E4] Cc: dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org Subject: Re: [dna] AD review of 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: Thu, 09 Jul 2009 22:25:13 -0000 Hi Jari/Bernard, I will try to come up with a new revision incorporating your comments by the deadline. Thanks Suresh On 09-07-09 02:04 PM, Jari Arkko wrote: > Bernard, > > Thanks for your response. I think I understand the logic better now. > Suresh, can we change the draft as suggested by Bernard? > > Jari > > Bernard Aboba wrote: >> > > The probing node SHOULD include a Source link-layer address option in >> > > the probe messages. If the node believes that the source address of >> > > the NS may not be unique on the newly attached link, it MAY omit the >> > > Source link-layer address option in the probe messages. >> > >> > I would like to understand this better. How does a general purpose >> > operating system implementation deal with the above? How does it know >> > that "the source address of the NS may not be unique"? >> >> The goal of DNA is not only to detect network attachment, but also to >> seed the ND cache so as to immediately enable incoming and outgoing >> communications. By including the SLLA in unicast probe messages, the >> node can seed the ND cache of the router tgo enable communications >> in the opposite direction. >> > AFAICT, if you omit the SLLA and no link change happened, then most >> > likely the router will remember your NC anyway, and be able to respond. >> >> Only if the ND cache entry had not expired. Remember, the biggest win >> for DNA is when moving between links. >> >> > However, if it does not remember you, a new NS/NA would be required, >> but >> > DNA would still succeed, albeit a bit slower. >> >> > However, if the host did move to a new link, then including the SLLA >> > might cause disruption for another host that already holds the same >> > address but uses a different link layer address. >> >> The probes are sent to a unicast IP and MAC address. Therefore they >> can only be received if the node moves to a link on which the node has >> a valid IP address. >> >> > Why is the recommendation written as it is above? Is the assumption >> that >> > colliding addresses are so rare that the optimization makes sense? On >> > the other hand, it would appear that even without the SLLA DNA would >> > still work in most cases. >> >> There are situations in which a node is unlikely to encounter >> collisions, and therefore DAD is not required. One is where the IP >> address >> was allocated via DHCP, and the lease has not yet expired. If the DHCP >> server is properly implemented, it will not hand out the same address to >> more than one host. DNAv4 makes this assumption. >> >> During development of the draft, there was discussion as to whether there >> were other situations in which this assumption could be made as well. >> For example, in situations where an IPv6 address is not manually or >> randomly assigned, but is based on a MAC address, would it be >> reasonable to include the SLLA (and also not to do DAD). As I >> recall, the decision was made *not* to override any of the existing >> recommendations on DAD. For consistency's sake then, the SLLA >> should not be included in those same cases. >> >> > In any case, I don't think we can require general purpose >> > implementations to assess the likelihood of collisions. >> >> Sure -- but the document should be written so as to clearly spell >> out the situations under which the SLLA is included. Those are the >> same circumstances in which the document should enable DAD to >> be avoided. However, currently the document is not consistent in >> this regard. >> >> > Perhaps it would be easier to require that by default, no SLLA is >> included >> > and that only through specific configuration option the SLLA use >> can be turned on and >> > DNA made to operate faster/more reliably. >> >> If the SLLA is only included in situations where DAD can be avoided, then >> I don't think this is an issue. That's how DNAv4 works. >> >> > > For the purpose of sending neighbor solicitations to previous >> > > routers, the host first needs to pick a subset of operable IPv6 >> > > addresses (candidate set) that it wishes to use. How this subset of >> > > addresses is picked is based on host configuration. e.g. The host >> > > may select configured addresses from each of zero, one or two >> > > previously connected links. >> > >> > Please specify a default strategy. E.g., "How this subset of addresses >> > is picked is based on host configuration. By default the host should >> > select configured addresses from two previously connected links." >> >> DNAv4 enables the host to send probes to all routers representing links >> with valid IP addresses. There is no language about subsets. This >> hasn't >> been an issue in practice, since a host will typically not have a >> large number >> of valid IP addresses. So I'd prefer that this language be removed >> entirely. >> >> > > Where flooding may cause performance issues within the LAN, host >> > > SHOULD limit the number of unicast solicitations. >> >> This is a red herring that should have been removed from the document >> long >> ago. The initial deployment of DNAv4 uncovered some AP implementations >> that were non-compliant with IEEE 802.1D, but those issues have long >> since >> been fixed. There is no known "flooding" issue at this time. >> >> > Again, the guidance for general purpose implementations in inadequate. >> > Please specify a default strategy. I believe limiting the number of >> > unicast solicitations to some small number (4?) by default is adequate >> > (there are a number of messages on a new link even on DNAv4 and >> regular ND). >> > >> > > The probing node SHOULD NOT include a Source link-layer address >> > > option if it has not performed duplicate address detection [RFC4862], >> > > for the source address of the NS, on the newly attached link. >> > >> > Performed DAD, when? Presumably it has been performed when the address >> > first configured, no? And since DNA is the first thing that runs >> after a >> > link change, DAD has not been run at this point either. So what does >> > your recommendation really mean here? Never include SLLA? >> >> It means that you only include SLLA in situations in which DAD can be >> avoided (such as where DHCPv6 is in use). >> >> > In any case, at this point we do not yet *know* if we are on a newly >> > attached link or not. Therefore, we do not know if we've run DAD in the >> > past on this link. >> >> The probe is constructed to test whether the node is on the link or not. >> If the address was assigned by DHCPv6 on the link, then the probe can >> omit the SLLA and if the probe succeeds, then DAD is not required. >> >> > >> > Please clarify. >> > >> > > Hosts checking their network attachment are unsure of their address >> > > status, and may be using Tentative link-layer addressing information >> > > in their router or neighbour solicitations. >> > > >> > > A router which desires to support hosts' DNA operations MUST process >> > > Tentative Options from unicast source addressed Router and Neighbour >> > > Solicitations, as described in [I-D.ietf-dna-tentative]. >> > >> > This is the first time dna-tentative is referenced in this document. I >> > wonder if there's really a need to have a normative reference, or even >> > mention this. >> >> I don't think so, since the WG decided to not modify DAD procedures >> except for the DHCPv6 case. >> >> > >> > > 7. Constants >> > > >> > > >> > > These constants are described as in [I-D.ietf-dna-protocol]. >> > > >> > > UNICAST_RA_INTERVAL >> > > >> > > Definition: The interval corresponding to the maximum average >> > > rate of Router Solicitations that the router is prepared to >> > > service with unicast responses. This is the interval at which >> > > the token bucket controlling the unicast responses is >> > > replenished. >> > > >> > > Value: 50 milliseconds >> > > >> > > MAX_UNICAST_RA_BURST >> > > >> > > Definition: The maximum size burst of Router Solicitations that >> > > the router is prepared to service with unicast responses. This >> > > is the maximum number of tokens allowed in the token bucket >> > > controlling the unicast responses. >> > > >> > > Value: 20 >> > > >> > >> > None of these appear to have anything to do with the Simple DNA >> > procedure. Please remove. The only item that I can see be of relevance >> > in this section is SEND_NA_GRACE_TIME. >> >> I agree. Not sure why this material remains in the document. >> >> > > When providing fast responses to router solicitations, it is possible >> > > to cause collisions with other signaling packets on contention based >> > > media. This can cause repeated packet loss or delay when multiple >> > > routers are present on the link. >> > > >> > > As such the fast router advertisement system is NOT RECOMMENDED in >> > > this form for media which are susceptible to collision loss. Such >> > > environments may be better served using the procedures defined in >> > > [I-D.ietf-dna-protocol]. >> > >> > This does not appear to have anything to do with Simple DNA either >> > (router-side fast responses are not a subject of this specification). >> > Delete? >> >> Yup. >> >> > > The host MAY delay SEND_NA_GRACE_TIME after transmission before >> > > adopting a new default router, if it is operating on a network where >> > > there is significant threat of RA spoofing. >> > >> > I would simply say that this delay MAY be imposed when the host's >> > current default router is a SEND-secured one. This prevents the >> > downgrade from SEND to non-SEND, but does not require any >> configuration, >> > and it doesn't slow things down when you were already using a non-SEND >> > router. >> > >> > > It is easy for hosts soliciting without SEND to deplete a SEND >> > > router's fast advertisement token buckets, and consume additional >> > > bandwidth. As such, a router MAY choose to preserve a portion of >> > > their token bucket to serve solicitations with SEND signatures. >> > >> > Again, this has very little to do with this specification. Move this to >> > the fast RA spec instead. >> > >> > Editorial: >> > >> > Move draft-ietf-dna-protocol to informative references. >> >> Right. >> > From bernard_aboba@hotmail.com Thu Jul 16 10:38:29 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 E606B3A6DAA for ; Thu, 16 Jul 2009 10:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 qzirrFZrX+qJ for ; Thu, 16 Jul 2009 10:38:27 -0700 (PDT) Received: from blu0-omc2-s36.blu0.hotmail.com (blu0-omc2-s36.blu0.hotmail.com [65.55.111.111]) by core3.amsl.com (Postfix) with ESMTP id 1EBC43A6DAC for ; Thu, 16 Jul 2009 10:38:27 -0700 (PDT) Received: from BLU137-W28 ([65.55.111.72]) by blu0-omc2-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 10:39:00 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_80567358-e8a9-4fac-b365-768a8551b774_" X-Originating-IP: [216.31.230.230] From: Bernard Aboba To: Jari Arkko , , , Suresh Krishnan Date: Thu, 16 Jul 2009 10:38:59 -0700 Importance: Normal In-Reply-To: References: <4A55E27D.80200@piuha.net> MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jul 2009 17:39:00.0094 (UTC) FILETIME=[4D7729E0:01CA063C] Subject: Re: [dna] AD review of 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: Thu, 16 Jul 2009 17:38:30 -0000 --_80567358-e8a9-4fac-b365-768a8551b774_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think that there are still some issues in the revised draft.=20 =20 " 4.5.1. Neighbor Solicitation messages This section describes the contents of the neighbor solicitation probe messages sent during the probing procedure. Source Address: A link-local address assigned to the probing host. Destination Address: The link-local address of the router being probed as learnt from the SDAT. Hop Limit: 255 ND Options: Target Address: The link-local address of the router being probed as learnt from the SDAT. The probing node SHOULD include a Source link-layer address option in the probe messages if the address was obtained using DHCPv6 and the lease has not expired. Otherwise the probing node SHOULD NOT include the Source link-layer address option in the probe messages. " =20 [BA] This section does not mention the destination MAC address. Unless th= at is set to the unicast MAC address of the router=2C it is possible that t= he NS could be received by another router using the same linklocal address.= After all=2C linklocal addresses need not be globally unique.=20 =20 " =20 4.5.2. Router Solicitation messages This section describes the contents of the router solicitation probe message sent during the probing procedure. Source Address: A link-local address assigned to the probing host. Destination Address: The all-routers multicast address. Hop Limit: 255 The probing node SHOULD include a Source link-layer address option in the probe messages if the address was obtained using DHCPv6 and the lease has not expired. Otherwise the probing node SHOULD NOT include the Source link-layer address option in the probe messages. " =20 [BA] Including the SSLAO in the RS seems odd because it is sent to a multic= ast address. Unlike the NS=2C the RS is not constructed for a particular r= outer=2C and therefore its construction should not depend how the address w= as obtained -- since another router could receive it. In the case where th= e address was obtained from DHCPv6=2C and the host is on one of the probed = links=2C we'd expect the unicast NS to be responded to=2C and since that do= es include the SSLAO=2C I think we're covered.=20 =20 4.6. Sending DHCPv6 probes Where the host has acquired addresses from DHCPv6 or the host does not have a global prefix=2C it MAY prefer to use DHCPv6 messages either before or simultanously with Neighbour Discovery probing. [BA] Doing DHCPv6 *before* NS probing does not make sense to me. Earlier= =2C it is said that NS probing occurs simulataneously with sending the RS= =2C right after "link up". This sentence seems to contradict that.=20 =20 Also=2C linking DHCPv6 procedures to DNA seems odd. In DNAv4=2C it is made= clear that DNA did not resut in any changes to DHCPv4 procedures. Is that= the intent here=2C or does DNA have some impact on how/when DHCPv6 message= s are sent?=20 =20 =20 4.7. Response Gathering When a responding Neighbour Advertisement is received from a test node=2C the host MUST verify that both the IPv6 and link layer (MAC) addresses of the test node match the expected values before utilizing the configuration associated with the detected network (prefixes=2C MTU etc.). [BA] It seems odd to check the MAC address in a response=2C but not to talk= about the destination MAC address in the request. Was this intentional?=20 =20 Section 4.9 =20 If the confirmed address was assigned manually=2C the implementation SHOU= LD NOT unconfigure the manually assigned address and SHOULD log an error about the mismatching prefix. [BA] Elsewhere the draft talks about stateless autoconfig and DHCPv6-assign= ed addresses=2C but not manual assignment. Is the intent of the document = to suggest use of DNAv6 for configuration of manually assigned addresses? = If so=2C then some of the caveats discussed in the DNAv4 document could app= ly. For example=2C NS probes don't need much if any retransmission becaus= e alternatives (RS=2C DHCPv6) are retransmitted. But if we are talking abo= ut manual assignment=2C then these alternate mechanisms may not help -- and= NS probe retransmission can become more important.=20 =20 =20 From: bernard_aboba@hotmail.com To: jari.arkko@piuha.net=3B draft-ietf-dna-simple@tools.ietf.org=3B dna@iet= f.org=3B suresh.krishnan@ericsson.com Date: Thu=2C 9 Jul 2009 10:20:53 -0700 Subject: Re: [dna] AD review of draft-ietf-dna-simple > > The probing node SHOULD include a Source link-layer address option in=20 > > the probe messages. If the node believes that the source address of=20 > > the NS may not be unique on the newly attached link=2C it MAY omit the= =20 > > Source link-layer address option in the probe messages. >=20 > I would like to understand this better. How does a general purpose=20 > operating system implementation deal with the above? How does it know=20 > that "the source address of the NS may not be unique"? The goal of DNA is not only to detect network attachment=2C but also to=20 seed the ND cache so as to immediately enable incoming and outgoing=20 communications. By including the SLLA in unicast probe messages=2C the node can seed the ND cache of the router tgo enable communications in the opposite direction. =20 > AFAICT=2C if you omit the SLLA and no link change happened=2C then most=20 > likely the router will remember your NC anyway=2C and be able to respond.= =20 Only if the ND cache entry had not expired. Remember=2C the biggest win for DNA is when moving between links.=20 > However=2C if it does not remember you=2C a new NS/NA would be required= =2C but=20 > DNA would still succeed=2C albeit a bit slower. > However=2C if the host did move to a new link=2C then including the SLLA= =20 > might cause disruption for another host that already holds the same=20 > address but uses a different link layer address. The probes are sent to a unicast IP and MAC address. Therefore they can only be received if the node moves to a link on which the node has a valid IP address.=20 > Why is the recommendation written as it is above? Is the assumption that= =20 > colliding addresses are so rare that the optimization makes sense? On=20 > the other hand=2C it would appear that even without the SLLA DNA would=20 > still work in most cases. There are situations in which a node is unlikely to encounter collisions=2C and therefore DAD is not required. One is where the IP addre= ss=20 was allocated via DHCP=2C and the lease has not yet expired. If the DHCP=20 server is properly implemented=2C it will not hand out the same address to= =20 more than one host. DNAv4 makes this assumption.=20 During development of the draft=2C there was discussion as to whether there were other situations in which this assumption could be made as well.=20 For example=2C in situations where an IPv6 address is not manually or randomly assigned=2C but is based on a MAC address=2C would it be=20 reasonable to include the SLLA (and also not to do DAD). As I recall=2C the decision was made *not* to override any of the existing recommendations on DAD. For consistency's sake then=2C the SLLA should not be included in those same cases.=20 > In any case=2C I don't think we can require general purpose=20 > implementations to assess the likelihood of collisions.=20 Sure -- but the document should be written so as to clearly spell out the situations under which the SLLA is included. Those are the same circumstances in which the document should enable DAD to be avoided. However=2C currently the document is not consistent in this regard.=20 > Perhaps it would be easier to require that by default=2C no SLLA is incl= uded=20 > and that only through specific configuration option the SLLA use can be = turned on and=20 > DNA made to operate faster/more reliably. If the SLLA is only included in situations where DAD can be avoided=2C then I don't think this is an issue. That's how DNAv4 works.=20 > > For the purpose of sending neighbor solicitations to previous > > routers=2C the host first needs to pick a subset of operable IPv6 > > addresses (candidate set) that it wishes to use. How this subset of > > addresses is picked is based on host configuration. e.g. The host > > may select configured addresses from each of zero=2C one or two > > previously connected links. >=20 > Please specify a default strategy. E.g.=2C "How this subset of addresses= =20 > is picked is based on host configuration. By default the host should=20 > select configured addresses from two previously connected links." DNAv4 enables the host to send probes to all routers representing links with valid IP addresses. There is no language about subsets. This hasn't been an issue in practice=2C since a host will typically not have a large n= umber of valid IP addresses. So I'd prefer that this language be removed entirel= y.=20 > > Where flooding may cause performance issues within the LAN=2C host=20 > > SHOULD limit the number of unicast solicitations. This is a red herring that should have been removed from the document long ago. The initial deployment of DNAv4 uncovered some AP implementations that were non-compliant with IEEE 802.1D=2C but those issues have long sinc= e been fixed. There is no known "flooding" issue at this time.=20 > Again=2C the guidance for general purpose implementations in inadequate.= =20 > Please specify a default strategy. I believe limiting the number of=20 > unicast solicitations to some small number (4?) by default is adequate=20 > (there are a number of messages on a new link even on DNAv4 and regular N= D). >=20 > > The probing node SHOULD NOT include a Source link-layer address > > option if it has not performed duplicate address detection [RFC4862]=2C > > for the source address of the NS=2C on the newly attached link. >=20 > Performed DAD=2C when? Presumably it has been performed when the address= =20 > first configured=2C no? And since DNA is the first thing that runs after = a=20 > link change=2C DAD has not been run at this point either. So what does=20 > your recommendation really mean here? Never include SLLA? It means that you only include SLLA in situations in which DAD can be avoided (such as where DHCPv6 is in use).=20 =20 > In any case=2C at this point we do not yet *know* if we are on a newly=20 > attached link or not. Therefore=2C we do not know if we've run DAD in the= =20 > past on this link. The probe is constructed to test whether the node is on the link or not.=20 If the address was assigned by DHCPv6 on the link=2C then the probe can omit the SLLA and if the probe succeeds=2C then DAD is not required.=20 >=20 > Please clarify. >=20 > > Hosts checking their network attachment are unsure of their address > > status=2C and may be using Tentative link-layer addressing information > > in their router or neighbour solicitations. > > > > A router which desires to support hosts' DNA operations MUST process > > Tentative Options from unicast source addressed Router and Neighbour > > Solicitations=2C as described in [I-D.ietf-dna-tentative]. >=20 > This is the first time dna-tentative is referenced in this document. I=20 > wonder if there's really a need to have a normative reference=2C or even= =20 > mention this. I don't think so=2C since the WG decided to not modify DAD procedures except for the DHCPv6 case.=20 >=20 > > 7. Constants > > > > > > These constants are described as in [I-D.ietf-dna-protocol]. > > > > UNICAST_RA_INTERVAL > > > > Definition: The interval corresponding to the maximum average > > rate of Router Solicitations that the router is prepared to > > service with unicast responses. This is the interval at which > > the token bucket controlling the unicast responses is > > replenished. > > > > Value: 50 milliseconds > > > > MAX_UNICAST_RA_BURST > > > > Definition: The maximum size burst of Router Solicitations that > > the router is prepared to service with unicast responses. This > > is the maximum number of tokens allowed in the token bucket > > controlling the unicast responses. > > > > Value: 20 > > >=20 > None of these appear to have anything to do with the Simple DNA=20 > procedure. Please remove. The only item that I can see be of relevance=20 > in this section is SEND_NA_GRACE_TIME. I agree. Not sure why this material remains in the document.=20 > > When providing fast responses to router solicitations=2C it is possible > > to cause collisions with other signaling packets on contention based > > media. This can cause repeated packet loss or delay when multiple > > routers are present on the link. > > > > As such the fast router advertisement system is NOT RECOMMENDED in > > this form for media which are susceptible to collision loss. Such > > environments may be better served using the procedures defined in > > [I-D.ietf-dna-protocol]. >=20 > This does not appear to have anything to do with Simple DNA either=20 > (router-side fast responses are not a subject of this specification).=20 > Delete? Yup.=20 > > The host MAY delay SEND_NA_GRACE_TIME after transmission before > > adopting a new default router=2C if it is operating on a network where > > there is significant threat of RA spoofing. >=20 > I would simply say that this delay MAY be imposed when the host's=20 > current default router is a SEND-secured one. This prevents the=20 > downgrade from SEND to non-SEND=2C but does not require any configuration= =2C=20 > and it doesn't slow things down when you were already using a non-SEND=20 > router. >=20 > > It is easy for hosts soliciting without SEND to deplete a SEND > > router's fast advertisement token buckets=2C and consume additional > > bandwidth. As such=2C a router MAY choose to preserve a portion of > > their token bucket to serve solicitations with SEND signatures. >=20 > Again=2C this has very little to do with this specification. Move this to= =20 > the fast RA spec instead. >=20 > Editorial: >=20 > Move draft-ietf-dna-protocol to informative references. Right.=20 --_80567358-e8a9-4fac-b365-768a8551b774_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think that there are still some issues in the revised draft.
 =3B
"

4.5.1. =3B Nei= ghbor Solicitation messages



 =3B =3B This section describes the contents of the = neighbor solicitation
 =3B =3B probe messages sent during the pr= obing procedure.

 =3B =3B Source Address: =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B A link-local = address assigned to the
 =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B probing host.

 =3B =3B Destinati= on Address: =3B =3B =3B =3B =3B The link-local address = of the router being
 =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B probed as learnt from the SDAT.

 =3B&nb= sp=3B Hop Limit: =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B 255

&n= bsp=3B =3B ND Options:

 =3B =3B Target Address: =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B The= link-local address of the router being
 =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B probed as learnt from the SDAT.=

 =3B =3B The probing node SHOULD include a Source link-laye= r address option in
 =3B =3B the probe messages if the address w= as obtained using DHCPv6 and the
 =3B =3B lease has not expired.=  =3B Otherwise the probing node SHOULD NOT include
 =3B =3B = the Source link-layer address option in the probe messages.
"
 =3B
[BA] This section does not mention the =3Bdestination MAC address. = =3B =3B Unless that is set to the unicast MAC address of the router=2C = it is possible that the NS could be received by another router using the sa= me linklocal address. =3B After all=2C linklocal addresses need not be = globally unique.
 =3B
"
 =3B =3B

4.5.2. =3B Rou= ter Solicitation messages



 =3B =3B This section describes the contents of the = router solicitation probe
 =3B =3B message sent during the probi= ng procedure.

 =3B =3B Source Address: =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B A link-local ad= dress assigned to the
 =3B =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B probing host.

 =3B =3B Destination = Address: =3B =3B =3B =3B =3B The all-routers multicast = address.

 =3B =3B Hop Limit: =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B 255

 =3B =3B The probing node SHOULD include a= Source link-layer address option in
 =3B =3B the probe messages= if the address was obtained using DHCPv6 and the
 =3B =3B lease= has not expired. =3B Otherwise the probing node SHOULD NOT include
=  =3B =3B the Source link-layer address option in the probe messages= .

"
 =3B
[BA] Including the SSLAO in the RS seems odd because it is sent to a multic= ast address. =3B Unlike the NS=2C the RS is not constructed for a parti= cular router=2C and therefore its construction should not depend how the ad= dress was obtained -- since another router could receive it. =3B In the= case where the address was obtained from DHCPv6=2C and the host is on one = of the probed links=2C we'd expect the unicast NS to be responded to=2C and= since that does include the SSLAO=2C I think we're covered.
 =3B

4.6. =3B Sending= DHCPv6 probes



 =3B =3B Where the host has acquired addresses from = DHCPv6 or the host does
 =3B =3B not have a global prefix=2C it = MAY prefer to use DHCPv6 messages either
 =3B =3B before or simu= ltanously with Neighbour Discovery probing.

[BA] Doing DHCPv6 *before* NS probing does not make sense to me. =3B&nb= sp=3BEarlier=2C it is said that NS probing occurs simulataneously with send= ing the RS=2C right after "link up". =3B This sentence seems to contrad= ict that.
 =3B
Also=2C linking DHCPv6 procedures to DNA seems odd. =3B In DNAv4=2C it = is made clear that DNA did not resut in any changes to DHCPv4 procedures.&n= bsp=3B Is that the intent here=2C or =3Bdoes DNA have some impact on ho= w/when DHCPv6 messages are sent?
 =3B
 =3B =3B

4.7. =3B Respons= e Gathering



 =3B =3B When a responding Neighbour Advertisement i= s received from a test
 =3B =3B node=2C the host MUST verify tha= t both the IPv6 and link layer (MAC)
 =3B =3B addresses of the t= est node match the expected values before utilizing
 =3B =3B the= configuration associated with the detected network (prefixes=2C MTU
&nb= sp=3B =3B etc.).

[BA] It seems odd to check the MAC address in a response=2C but not to talk= about the destination MAC address in the request. Was this intentional?  =3B
Section 4.9
 =3B
 =3B If the confirmed address was assigned manually=2C the implementati= on SHOULD
 =3B =3B NOT unconfigure the manually assigned address= and SHOULD log an error
 =3B =3B about the mismatching prefix.<= BR>
[BA] Elsewhere the draft talks about stateless autoconfig and DHCPv6-assign= ed addresses=2C but not manual assignment.  =3B Is the intent of the do= cument to suggest use of DNAv6 for configuration of manually assigned addre= sses? =3B If so=2C then some of the =3Bcaveats discussed in the DNA= v4 document could =3Bapply. =3B =3B For example=2C NS probes do= n't need much if any retransmission because alternatives (RS=2C DHCPv6) are= retransmitted. =3B But if we are talking about manual assignment=2C th= en these alternate mechanisms may not help -- and NS probe retransmission c= an become more important.
 =3B
 =3B
From: bernard_aboba@hotmail.com
To: jari.arkko@piuha.net=3B draft-ietf-d= na-simple@tools.ietf.org=3B dna@ietf.org=3B suresh.krishnan@ericsson.comDate: Thu=2C 9 Jul 2009 10:20:53 -0700
Subject: Re: [dna] AD review of = draft-ietf-dna-simple

>=3B >=3B The probing node SHOULD include a Source link-layer address o= ption in
>=3B >=3B the probe messages. If the node believes that th= e source address of
>=3B >=3B the NS may not be unique on the newly= attached link=2C it MAY omit the
>=3B >=3B Source link-layer addre= ss option in the probe messages.
>=3B
>=3B I would like to under= stand this better. How does a general purpose
>=3B operating system i= mplementation deal with the above? How does it know
>=3B that "the so= urce address of the NS may not be unique"?

The goal of DNA is not on= ly to detect network attachment=2C but also to
seed the ND cache so as = to immediately enable incoming and outgoing
communications. =3B By = including the SLLA in unicast probe messages=2C the
node can seed the ND= cache of the router tgo enable communications
in the opposite direction= . =3B

>=3B AFAICT=2C if you omit the SLLA and no link change = happened=2C then most
>=3B likely the router will remember your NC an= yway=2C and be able to respond.

Only if the ND cache entry had not = expired. =3B =3B Remember=2C the biggest win
for DNA is when mov= ing between links.

>=3B However=2C if it does not remember you=2C= a new NS/NA would be required=2C but
>=3B DNA would still succeed=2C= albeit a bit slower.

>=3B However=2C if the host did move to a ne= w link=2C then including the SLLA
>=3B might cause disruption for ano= ther host that already holds the same
>=3B address but uses a differe= nt link layer address.

The probes are sent to a unicast IP and MAC a= ddress. =3B Therefore they
can only be received if the node moves to= a link on which the node has
a valid IP address.

>=3B Why is = the recommendation written as it is above? Is the assumption that
>= =3B colliding addresses are so rare that the optimization makes sense? On <= BR>>=3B the other hand=2C it would appear that even without the SLLA DNA = would
>=3B still work in most cases.

There are situations in w= hich a node is unlikely to encounter
collisions=2C and therefore DAD is = not required. =3B One is where the IP address
was allocated via DHC= P=2C and the lease has not yet expired. =3B If the DHCP
server is p= roperly implemented=2C it will not hand out the same address to
more th= an one host. =3B DNAv4 makes this assumption.

During developmen= t of the draft=2C there was discussion as to whether there
were other si= tuations in which this assumption could be made as well.
For example=2C= in situations where an IPv6 address is not manually or
randomly assigne= d=2C but is based on a MAC address=2C would it be
reasonable to include= the SLLA (and also not to do DAD). =3B =3B As I
recall=2C the d= ecision was made *not* to override any of the existing
recommendations o= n DAD. =3B For consistency's sake then=2C the SLLA
should not be inc= luded in those same cases.

>=3B In any case=2C I don't think we c= an require general purpose
>=3B implementations to assess the likelih= ood of collisions.

Sure -- but the document should be written so as= to clearly spell
out the situations under which the SLLA is included.&n= bsp=3B Those are the
same circumstances in which the document should ena= ble DAD to
be avoided. =3B However=2C currently the document is not = consistent in
this regard.

>=3B Perhaps it would =3B be ea= sier to require that by default=2C no SLLA is included
>=3B and that = only =3B through specific configuration option the SLLA use can be turn= ed on and
>=3B DNA made to operate faster/more reliably.

If th= e SLLA is only included in situations where DAD can be avoided=2C then
I= don't think this is an issue. =3B That's how DNAv4 works.

>= =3B >=3B For the purpose of sending neighbor solicitations to previous>=3B >=3B routers=2C the host first needs to pick a subset of operable= IPv6
>=3B >=3B addresses (candidate set) that it wishes to use. How= this subset of
>=3B >=3B addresses is picked is based on host confi= guration. e.g. The host
>=3B >=3B may select configured addresses fr= om each of zero=2C one or two
>=3B >=3B previously connected links.<= BR>>=3B
>=3B Please specify a default strategy. E.g.=2C "How this s= ubset of addresses
>=3B is picked is based on host configuration. By = default the host should
>=3B select configured addresses from two pre= viously connected links."

DNAv4 enables the host to send probes to a= ll routers representing links
with valid IP addresses. =3B There is = no language about subsets. =3B This hasn't
been an issue in practice= =2C since a host will typically not have a large number
of valid IP addr= esses. =3B So I'd prefer that this language be removed entirely.
>=3B >=3B Where flooding may cause performance issues within the LAN= =2C host
>=3B >=3B SHOULD limit the number of unicast solicitations= .

This is a red herring that should have been removed from the docum= ent long
ago. =3B The initial deployment of DNAv4 uncovered some AP = implementations
that were non-compliant with IEEE 802.1D=2C but those is= sues have long since
been fixed. =3B There is no known "flooding" is= sue at this time.

>=3B Again=2C the guidance for general purpose = implementations in inadequate.
>=3B Please specify a default strategy= . I believe limiting the number of
>=3B unicast solicitations to some= small number (4?) by default is adequate
>=3B (there are a number of= messages on a new link even on DNAv4 and regular ND).
>=3B
>=3B= >=3B The probing node SHOULD NOT include a Source link-layer address
= >=3B >=3B option if it has not performed duplicate address detection [R= FC4862]=2C
>=3B >=3B for the source address of the NS=2C on the newl= y attached link.
>=3B
>=3B Performed DAD=2C when? Presumably it = has been performed when the address
>=3B first configured=2C no? And = since DNA is the first thing that runs after a
>=3B link change=2C DA= D has not been run at this point either. So what does
>=3B your recom= mendation really mean here? Never include SLLA?

It means that you on= ly include SLLA in situations in which DAD can be
avoided (such as where= DHCPv6 is in use).
 =3B
>=3B In any case=2C at this point we = do not yet *know* if we are on a newly
>=3B attached link or not. The= refore=2C we do not know if we've run DAD in the
>=3B past on this li= nk.

The probe is constructed to test whether the node is on the link= or not.
If the address was assigned by DHCPv6 on the link=2C then the = probe can
omit the SLLA and if the probe succeeds=2C then DAD is not req= uired.

>=3B
>=3B Please clarify.
>=3B
>=3B >= =3B Hosts checking their network attachment are unsure of their address
= >=3B >=3B status=2C and may be using Tentative link-layer addressing in= formation
>=3B >=3B in their router or neighbour solicitations.
&= gt=3B >=3B
>=3B >=3B A router which desires to support hosts' DNA = operations MUST process
>=3B >=3B Tentative Options from unicast sou= rce addressed Router and Neighbour
>=3B >=3B Solicitations=2C as des= cribed in [I-D.ietf-dna-tentative].
>=3B
>=3B This is the first = time dna-tentative is referenced in this document. I
>=3B wonder if t= here's really a need to have a normative reference=2C or even
>=3B me= ntion this.

I don't think so=2C since the WG decided to not modify D= AD procedures
except for the DHCPv6 case.

>=3B
>=3B >= =3B 7. Constants
>=3B >=3B
>=3B >=3B
>=3B >=3B These c= onstants are described as in [I-D.ietf-dna-protocol].
>=3B >=3B
&= gt=3B >=3B UNICAST_RA_INTERVAL
>=3B >=3B
>=3B >=3B Definiti= on: The interval corresponding to the maximum average
>=3B >=3B rate= of Router Solicitations that the router is prepared to
>=3B >=3B se= rvice with unicast responses. This is the interval at which
>=3B >= =3B the token bucket controlling the unicast responses is
>=3B >=3B = replenished.
>=3B >=3B
>=3B >=3B Value: 50 milliseconds
&g= t=3B >=3B
>=3B >=3B MAX_UNICAST_RA_BURST
>=3B >=3B
>= =3B >=3B Definition: The maximum size burst of Router Solicitations that<= BR>>=3B >=3B the router is prepared to service with unicast responses. = This
>=3B >=3B is the maximum number of tokens allowed in the token = bucket
>=3B >=3B controlling the unicast responses.
>=3B >=3B=
>=3B >=3B Value: 20
>=3B >=3B
>=3B
>=3B None of t= hese appear to have anything to do with the Simple DNA
>=3B procedure= . Please remove. The only item that I can see be of relevance
>=3B in= this section is SEND_NA_GRACE_TIME.

I agree. Not sure why this mate= rial remains in the document.

>=3B >=3B When providing fast res= ponses to router solicitations=2C it is possible
>=3B >=3B to cause = collisions with other signaling packets on contention based
>=3B >= =3B media. This can cause repeated packet loss or delay when multiple
&g= t=3B >=3B routers are present on the link.
>=3B >=3B
>=3B >= =3B As such the fast router advertisement system is NOT RECOMMENDED in
&= gt=3B >=3B this form for media which are susceptible to collision loss. S= uch
>=3B >=3B environments may be better served using the procedures= defined in
>=3B >=3B [I-D.ietf-dna-protocol].
>=3B
>=3B = This does not appear to have anything to do with Simple DNA either
>= =3B (router-side fast responses are not a subject of this specification). <= BR>>=3B Delete?

Yup.

>=3B >=3B The host MAY delay SEND= _NA_GRACE_TIME after transmission before
>=3B >=3B adopting a new de= fault router=2C if it is operating on a network where
>=3B >=3B ther= e is significant threat of RA spoofing.
>=3B
>=3B I would simply= say that this delay MAY be imposed when the host's
>=3B current defa= ult router is a SEND-secured one. This prevents the
>=3B downgrade fr= om SEND to non-SEND=2C but does not require any configuration=2C
>=3B= and it doesn't slow things down when you were already using a non-SEND >=3B router.
>=3B
>=3B >=3B It is easy for hosts soliciting= without SEND to deplete a SEND
>=3B >=3B router's fast advertisemen= t token buckets=2C and consume additional
>=3B >=3B bandwidth. As su= ch=2C a router MAY choose to preserve a portion of
>=3B >=3B their t= oken bucket to serve solicitations with SEND signatures.
>=3B
>= =3B Again=2C this has very little to do with this specification. Move this = to
>=3B the fast RA spec instead.
>=3B
>=3B Editorial:
= >=3B
>=3B Move draft-ietf-dna-protocol to informative references.
Right.

= --_80567358-e8a9-4fac-b365-768a8551b774_-- From suresh.krishnan@ericsson.com Thu Jul 16 15:39:27 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 3410428C279 for ; Thu, 16 Jul 2009 15:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 YDBiMJChM7rr for ; Thu, 16 Jul 2009 15:39:26 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 653A928C247 for ; Thu, 16 Jul 2009 15:39:17 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n6GMdgH8002393; Thu, 16 Jul 2009 17:39:49 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jul 2009 17:39:46 -0500 Received: from [142.133.10.113] ([142.133.10.113]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jul 2009 17:39:45 -0500 Message-ID: <4A5FABFE.2030209@ericsson.com> Date: Thu, 16 Jul 2009 18:38:54 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Bernard Aboba References: <4A55E27D.80200@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2009 22:39:45.0702 (UTC) FILETIME=[517C6C60:01CA0666] Cc: dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org Subject: Re: [dna] AD review of 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: Thu, 16 Jul 2009 22:39:27 -0000 Hi Bernard, Thanks for the comments. On 09-07-16 01:38 PM, Bernard Aboba wrote: > [BA] This section does not mention the destination MAC address. Unless > that is set to the unicast MAC address of the router, it is possible > that the NS could be received by another router using the same linklocal > address. After all, linklocal addresses need not be globally unique. Agree. I will make this change. > > " > > > > *4.5.2**. Router Solicitation messages* > > > > This section describes the contents of the router solicitation probe > message sent during the probing procedure. > > Source Address: A link-local address assigned to the > probing host. > > Destination Address: The all-routers multicast address. > > Hop Limit: 255 > > The probing node SHOULD include a Source link-layer address option in > the probe messages if the address was obtained using DHCPv6 and the > lease has not expired. Otherwise the probing node SHOULD NOT include > the Source link-layer address option in the probe messages. > > " > > [BA] Including the SSLAO in the RS seems odd because it is sent to a > multicast address. Unlike the NS, the RS is not constructed for a > particular router, and therefore its construction should not depend how > the address was obtained -- since another router could receive it. In > the case where the address was obtained from DHCPv6, and the host is on > one of the probed links, we'd expect the unicast NS to be responded to, > and since that does include the SSLAO, I think we're covered. We do not know which probe will succeed first, the RS or the NS, since they are sent in parallel. To expedite the proceedings we include the SLLAO on the RS. But when we reattach to a known link (which is the case we optimize for) the NS will succeed and we probably don't need the SLLAO in the RS. I will go ahead and remove this. > > > > *4.6**. Sending DHCPv6 probes* > > > > Where the host has acquired addresses from DHCPv6 or the host does > not have a global prefix, it MAY prefer to use DHCPv6 messages either > before or simultanously with Neighbour Discovery probing. > > [BA] Doing DHCPv6 *before* NS probing does not make sense to > me. Earlier, it is said that NS probing occurs simulataneously with > sending the RS, right after "link up". This sentence seems to > contradict that. It refers to "neighbor discovery" probing, which includes both RS and NS probing. Please see below. > > Also, linking DHCPv6 procedures to DNA seems odd. In DNAv4, it is made > clear that DNA did not resut in any changes to DHCPv4 procedures. Is > that the intent here, or does DNA have some impact on how/when DHCPv6 > messages are sent? It does not have any impact on when DHCPv6 messages are sent. Would you like this text to be removed? > > > > > *4.7**. Response Gathering* > > > > When a responding Neighbour Advertisement is received from a test > node, the host MUST verify that both the IPv6 and link layer (MAC) > addresses of the test node match the expected values before utilizing > the configuration associated with the detected network (prefixes, MTU > etc.). > > [BA] It seems odd to check the MAC address in a response, but not to > talk about the destination MAC address in the request. Was this > intentional? No. I will add the destination MAC address to the request as well. > > Section 4.9 > > If the confirmed address was assigned manually, the implementation SHOULD > NOT unconfigure the manually assigned address and SHOULD log an error > about the mismatching prefix. > > [BA] Elsewhere the draft talks about stateless autoconfig and > DHCPv6-assigned addresses, but not manual assignment. Is the intent of > the document to suggest use of DNAv6 for configuration of manually > assigned addresses? If so, then some of the caveats discussed in the > DNAv4 document could apply. For example, NS probes don't need much if > any retransmission because alternatives (RS, DHCPv6) are retransmitted. > But if we are talking about manual assignment, then these alternate > mechanisms may not help -- and NS probe retransmission can become more > important. I will try to add more text regarding manually configured addresses. Thanks Suresh From bernard_aboba@hotmail.com Thu Jul 16 22:55:52 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 EF2433A6884 for ; Thu, 16 Jul 2009 22:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 onJpaEIRUORh for ; Thu, 16 Jul 2009 22:55:52 -0700 (PDT) Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com [65.55.116.78]) by core3.amsl.com (Postfix) with ESMTP id 174363A67D0 for ; Thu, 16 Jul 2009 22:55:52 -0700 (PDT) Received: from BLU137-W8 ([65.55.116.74]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 22:56:23 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_bfa51c2f-b04e-4819-b469-a574e2c176d3_" X-Originating-IP: [24.16.113.61] From: Bernard Aboba To: Suresh Krishnan Date: Thu, 16 Jul 2009 22:56:22 -0700 Importance: Normal In-Reply-To: <4A5FABFE.2030209@ericsson.com> References: <4A55E27D.80200@piuha.net> <4A5FABFE.2030209@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jul 2009 05:56:23.0311 (UTC) FILETIME=[507A51F0:01CA06A3] Cc: dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org Subject: Re: [dna] AD review of 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, 17 Jul 2009 05:55:53 -0000 --_bfa51c2f-b04e-4819-b469-a574e2c176d3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It does not have any impact on when DHCPv6 messages are sent. Would you=20 > like this text to be removed? All that needs to be said is that DHCPv6=2C if it is triggered=2C occurs in= parallel=2C and that DNA does not imply any changes to the DHCPv6 protocol or state machine. It= also would make sense to state that if DHCPv6 completes with a different result= =2C that (as with RS) this takes precedence over DNA. > > [BA] Elsewhere the draft talks about stateless autoconfig and=20 > > DHCPv6-assigned addresses=2C but not manual assignment. Is the intent= of=20 > > the document to suggest use of DNAv6 for configuration of manually=20 > > assigned addresses? If so=2C then some of the caveats discussed in the= =20 > > DNAv4 document could apply. For example=2C NS probes don't need much = if=20 > > any retransmission because alternatives (RS=2C DHCPv6) are retransmitte= d. =20 > > But if we are talking about manual assignment=2C then these alternate=20 > > mechanisms may not help -- and NS probe retransmission can become more= =20 > > important. >=20 >=20 > I will try to add more text regarding manually configured addresses. OK. The DNAv4 draft talks a bit about manually configured addresses=2C but= my understanding is that this functionality has not been implemented.=20 --_bfa51c2f-b04e-4819-b469-a574e2c176d3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B It does not have any impact on when DHCPv6 messages are sent. Would = you
>=3B like this text to be removed?

All that needs to be sa= id is that DHCPv6=2C if it is triggered=2C occurs in parallel=2C and thatDNA does not imply any changes to the DHCPv6 protocol or state machine.&n= bsp=3B It also
would make sense to state that if DHCPv6 completes with a= different result=2C that
(as with RS) this takes precedence over DNA.
>=3B >=3B [BA] Elsewhere the draft talks about stateless autoconf= ig and
>=3B >=3B DHCPv6-assigned addresses=2C but not manual assign= ment. Is the intent of
>=3B >=3B the document to suggest use of D= NAv6 for configuration of manually
>=3B >=3B assigned addresses? I= f so=2C then some of the caveats discussed in the
>=3B >=3B DNAv4 d= ocument could apply. For example=2C NS probes don't need much if
>= =3B >=3B any retransmission because alternatives (RS=2C DHCPv6) are retra= nsmitted.
>=3B >=3B But if we are talking about manual assignment= =2C then these alternate
>=3B >=3B mechanisms may not help -- and N= S probe retransmission can become more
>=3B >=3B important.
>= =3B
>=3B
>=3B I will try to add more text regarding manually co= nfigured addresses.

OK. =3B The DNAv4 draft talks a bit about ma= nually configured addresses=2C but my
understanding is that this functio= nality has not been implemented.
= --_bfa51c2f-b04e-4819-b469-a574e2c176d3_-- From bernard_aboba@hotmail.com Thu Jul 16 23:22: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 89C143A67ED for ; Thu, 16 Jul 2009 23:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 DbgC4yk3dNWH for ; Thu, 16 Jul 2009 23:22:08 -0700 (PDT) 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 6850B3A6359 for ; Thu, 16 Jul 2009 23:22:08 -0700 (PDT) Received: from BLU137-W20 ([65.55.116.72]) by blu0-omc3-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 23:19:45 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3855e59e-3f5a-4cab-b8c3-156b0c87576e_" X-Originating-IP: [24.16.113.61] From: Bernard Aboba To: , Suresh Krishnan Date: Thu, 16 Jul 2009 23:19:45 -0700 Importance: Normal In-Reply-To: <6983BF97BFC24D4EA551F140712329180119373E@melmail.netstarnetworks.com> References: <4A55E27D.80200@piuha.net> <4A5FABFE.2030209@ericsson.com> <6983BF97BFC24D4EA551F140712329180119373E@melmail.netstarnetworks.com> MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jul 2009 06:19:45.0202 (UTC) FILETIME=[9411E920:01CA06A6] Cc: dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org Subject: Re: [dna] AD review of 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, 17 Jul 2009 06:22:09 -0000 --_3855e59e-3f5a-4cab-b8c3-156b0c87576e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That brings up another point -- security. The DNAv4 document states that DNA is not appropriate for use in situations where security is required -- such as where DHCP authentication would be used. =20 So if you're looking to secure configuration with SEND or authenticated DHCPv6=2C does it make sense to use DNA?=20 Subject: RE: [dna] AD review of draft-ietf-dna-simple Date: Fri=2C 17 Jul 2009 16:06:16 +1000 From: gdaley@netstarnetworks.com To: bernard_aboba@hotmail.com=3B suresh.krishnan@ericsson.com CC: jari.arkko@piuha.net=3B draft-ietf-dna-simple@tools.ietf.org=3B dna@iet= f.org Hi Bernard=2C =20 Would it be possible to say that if DHCPv6 completes with a different=20 value to DNA=2C it takes precedence so long as this does not override a SEND advertisement where DHCPv6=20 is unauthenticated? =20 Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail:=20 gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532=20 4042 Fax: +61 3 8532 4032=20 =20 =20 =20 From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]=20 Sent: Friday=2C 17 July 2009 3:56=20 PM To: Suresh Krishnan Cc: Jari Arkko=3B=20 draft-ietf-dna-simple@tools.ietf.org=3B dna@ietf.org Subject: RE:=20 [dna] AD review of draft-ietf-dna-simple > It does not have any impact on when DHCPv6 messages are sent.=20 Would you=20 > like this text to be removed? All that needs to be=20 said is that DHCPv6=2C if it is triggered=2C occurs in parallel=2C and th= at DNA=20 does not imply any changes to the DHCPv6 protocol or state machine. It=20 also would make sense to state that if DHCPv6 completes with a different=20 result=2C that (as with RS) this takes precedence over DNA. > >=20 [BA] Elsewhere the draft talks about stateless autoconfig and=20 > >=20 DHCPv6-assigned addresses=2C but not manual assignment. Is the intent of= =20 =20 > > the document to suggest use of DNAv6 for configuration of=20 manually=20 > > assigned addresses? If so=2C then some of the caveats=20 discussed in the=20 > > DNAv4 document could apply. For example=2C NS=20 probes don't need much if=20 > > any retransmission because=20 alternatives (RS=2C DHCPv6) are retransmitted.=20 > > But if we are=20 talking about manual assignment=2C then these alternate=20 > > mechanisms=20 may not help -- and NS probe retransmission can become more=20 > >=20 important. >=20 >=20 > I will try to add more text regarding=20 manually configured addresses. OK. The DNAv4 draft talks a bit=20 about manually configured addresses=2C but my understanding is that this=20 functionality has not been implemented.=20 --_3855e59e-3f5a-4cab-b8c3-156b0c87576e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That brings up another point -- security. =3B The DNAv4 document states=
that DNA is not appropriate for use in situations where security is
= required -- such as where DHCP authentication would be used. =3B
So if you're looking to secure configuration with SEND or authenticatedDHCPv6=2C does it make sense to use DNA?

= Subject: RE: [dna] AD review of draft-ietf-dna-simple
Date: Fri=2C 17 Ju= l 2009 16:06:16 +1000
From: gdaley@netstarnetworks.com
To: bernard_ab= oba@hotmail.com=3B suresh.krishnan@ericsson.com
CC: jari.arkko@piuha.net= =3B draft-ietf-dna-simple@tools.ietf.org=3B dna@ietf.org

Hi Bernard=2C
 =3B
Would it be possible to say that if DHCPv= 6 completes with a different=20 value to DNA=2C it takes precedence
so long as this does not override a SEND = advertisement where DHCPv6=20 is unauthenticated?
 =3B
Greg Daley
Security Consultant
NetStar Australia Pty Ltd

E-mai= l:=20 gdaley@netstarnetworks.com
Mobile: +61 401 772 770
Direct: +61 3 8532= =20 4042
Fax: =3B =3B =3B +61 3 8532 4032
 =3B

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Friday=2C 17 July 200= 9 3:56=20 PM
To: Suresh Krishnan
Cc: Jari Arkko=3B=20 draft-ietf-dna-simple@tools.ietf.org=3B dna@ietf.org
Subject: R= E:=20 [dna] AD review of draft-ietf-dna-simple

>=3B It does not have any impact on when DHCPv6 messages are= sent.=20 Would you
>=3B like this text to be removed?

All that needs = to be=20 said is that DHCPv6=2C if it is triggered=2C occurs in parallel=2C and th= at
DNA=20 does not imply any changes to the DHCPv6 protocol or state machine. = =3B It=20 also
would make sense to state that if DHCPv6 completes with a differe= nt=20 result=2C that
(as with RS) this takes precedence over DNA.

>= =3B >=3B=20 [BA] Elsewhere the draft talks about stateless autoconfig and
>=3B = >=3B=20 DHCPv6-assigned addresses=2C but not manual assignment. Is the intent of= =20
>=3B >=3B the document to suggest use of DNAv6 for configuration = of=20 manually
>=3B >=3B assigned addresses? If so=2C then some of the = caveats=20 discussed in the
>=3B >=3B DNAv4 document could apply. For exampl= e=2C NS=20 probes don't need much if
>=3B >=3B any retransmission because=20 alternatives (RS=2C DHCPv6) are retransmitted.
>=3B >=3B But if w= e are=20 talking about manual assignment=2C then these alternate
>=3B >=3B= mechanisms=20 may not help -- and NS probe retransmission can become more
>=3B &g= t=3B=20 important.
>=3B
>=3B
>=3B I will try to add more text re= garding=20 manually configured addresses.

OK. =3B The DNAv4 draft talks a= bit=20 about manually configured addresses=2C but my
understanding is that th= is=20 functionality has not been implemented.
= --_3855e59e-3f5a-4cab-b8c3-156b0c87576e_-- From gdaley@netstarnetworks.com Thu Jul 16 23:06: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 E902A3A6E25 for ; Thu, 16 Jul 2009 23:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 Us56gHR0Puxv for ; Thu, 16 Jul 2009 23:06:07 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id AB2563A6E12 for ; Thu, 16 Jul 2009 23:06:06 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n6H66QRs010439; Fri, 17 Jul 2009 16:06:27 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 16:06:16 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA06A4.B2336D07" Date: Fri, 17 Jul 2009 16:06:16 +1000 Message-ID: <6983BF97BFC24D4EA551F140712329180119373E@melmail.netstarnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dna] AD review of draft-ietf-dna-simple Thread-Index: AcoGo1i3lbukH+0mRpWlNvslaTyQ6AAAMXCQ References: <4A55E27D.80200@piuha.net> <4A5FABFE.2030209@ericsson.com> From: "Greg Daley" To: "Bernard Aboba" , "Suresh Krishnan" X-OriginalArrivalTime: 17 Jul 2009 06:06:16.0950 (UTC) FILETIME=[B2507160:01CA06A4] X-Mailman-Approved-At: Mon, 20 Jul 2009 12:58:29 -0700 Cc: dna@ietf.org, draft-ietf-dna-simple@tools.ietf.org Subject: Re: [dna] AD review of 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, 17 Jul 2009 06:06:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA06A4.B2336D07 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bernard, =20 Would it be possible to say that if DHCPv6 completes with a different value to DNA, it takes precedence so long as this does not override a SEND advertisement where DHCPv6 is unauthenticated? =20 Greg Daley Security Consultant NetStar Australia Pty Ltd E-mail: gdaley@netstarnetworks.com Mobile: +61 401 772 770 Direct: +61 3 8532 4042 Fax: +61 3 8532 4032=20 =20 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Friday, 17 July 2009 3:56 PM To: Suresh Krishnan Cc: Jari Arkko; draft-ietf-dna-simple@tools.ietf.org; dna@ietf.org Subject: RE: [dna] AD review of draft-ietf-dna-simple =09 =09 > It does not have any impact on when DHCPv6 messages are sent. Would you=20 > like this text to be removed? =09 All that needs to be said is that DHCPv6, if it is triggered, occurs in parallel, and that DNA does not imply any changes to the DHCPv6 protocol or state machine. It also would make sense to state that if DHCPv6 completes with a different result, that (as with RS) this takes precedence over DNA. =09 > > [BA] Elsewhere the draft talks about stateless autoconfig and=20 > > DHCPv6-assigned addresses, but not manual assignment. Is the intent of=20 > > the document to suggest use of DNAv6 for configuration of manually=20 > > assigned addresses? If so, then some of the caveats discussed in the=20 > > DNAv4 document could apply. For example, NS probes don't need much if=20 > > any retransmission because alternatives (RS, DHCPv6) are retransmitted.=20 > > But if we are talking about manual assignment, then these alternate=20 > > mechanisms may not help -- and NS probe retransmission can become more=20 > > important. >=20 >=20 > I will try to add more text regarding manually configured addresses. =09 OK. The DNAv4 draft talks a bit about manually configured addresses, but my understanding is that this functionality has not been implemented.=20 =09 ------_=_NextPart_001_01CA06A4.B2336D07 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Bernard,
 
Would it be possible to say that if DHCPv6 completes with a = different=20 value to DNA, it takes precedence
so long as this does not override a SEND advertisement = where DHCPv6=20 is unauthenticated?
 

Greg Daley
Security Consultant
NetStar Australia Pty = Ltd

E-mail:=20 gdaley@netstarnetworks.com
Mobile: +61 401 772 770
Direct: +61 3 = 8532=20 4042
Fax:    +61 3 8532 4032

 

From: Bernard Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Friday, 17 July = 2009 3:56=20 PM
To: Suresh Krishnan
Cc: Jari Arkko;=20 draft-ietf-dna-simple@tools.ietf.org; dna@ietf.org
Subject: = RE:=20 [dna] AD review of draft-ietf-dna-simple

> It does not have any impact on when DHCPv6 messages = are sent.=20 Would you
> like this text to be removed?

All that needs = to be=20 said is that DHCPv6, if it is triggered, occurs in parallel, and = that
DNA=20 does not imply any changes to the DHCPv6 protocol or state = machine.  It=20 also
would make sense to state that if DHCPv6 completes with a = different=20 result, that
(as with RS) this takes precedence over = DNA.

> >=20 [BA] Elsewhere the draft talks about stateless autoconfig and
> = >=20 DHCPv6-assigned addresses, but not manual assignment. Is the intent of =
> > the document to suggest use of DNAv6 for configuration = of=20 manually
> > assigned addresses? If so, then some of the = caveats=20 discussed in the
> > DNAv4 document could apply. For = example, NS=20 probes don't need much if
> > any retransmission because=20 alternatives (RS, DHCPv6) are retransmitted.
> > But if we = are=20 talking about manual assignment, then these alternate
> > = mechanisms=20 may not help -- and NS probe retransmission can become more
> = >=20 important.
>
>
> I will try to add more text = regarding=20 manually configured addresses.

OK.  The DNAv4 draft talks = a bit=20 about manually configured addresses, but my
understanding is that = this=20 functionality has not been implemented. =
------_=_NextPart_001_01CA06A4.B2336D07--