From robin@huawei.com Tue Dec 1 01:49:58 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DBBB3A6A2A for ; Tue, 1 Dec 2009 01:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] 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 z5c83qCQNjwy for ; Tue, 1 Dec 2009 01:49:57 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id EA8753A67F4 for ; Tue, 1 Dec 2009 01:49:56 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTY00M2SWMZPQ@szxga03-in.huawei.com> for savi@ietf.org; Tue, 01 Dec 2009 17:49:48 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTY00K9KWMZ27@szxga03-in.huawei.com> for savi@ietf.org; Tue, 01 Dec 2009 17:49:47 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [188.36.252.226]) by szxmc03-in.huawei.com (mshttpd); Tue, 01 Dec 2009 17:49:47 +0800 Date: Tue, 01 Dec 2009 17:49:47 +0800 From: zhengruobin 35664 In-reply-to: <4B10DED3.5070001@it.uc3m.es> To: marcelo bagnulo braun Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <000501ca6fd5$9f08ed40$7a28460a@china.huawei.com> <4B10DED3.5070001@it.uc3m.es> Cc: savi@ietf.org Subject: Re: [savi] about draft-ietf-savi-fcfs-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 09:49:58 -0000 Hi marcelo=2C BRAS is the abbreviation of Broadband Remote Access Server=2C which is de= fined by DSL Forum in TR101=2E In the IPv4 access network=2C the bindings of IPv6 address and a port are= done by DHCPv4 snooping=2E But in the IPv6 access network=2C the SLAAC m= ay be used insteads of DHCPv6 for IPv6 address assignment=2E Thus=2C in c= ase of SLAAC=2C a mechanism to discover the bindings of IPv6 address and = a port is needed=2E Robin ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A marcelo bagnulo braun =3Cmarcelo=40it=2Euc3m=2Ees=3E= =C8=D5=C6=DA=3A =D0=C7=C6=DA=C1=F9=2C =CA=AE=D2=BB=D4=C2 28=C8=D5=2C 2009= =CF=C2=CE=E74=3A27 =D6=F7=CC=E2=3A Re=3A =5Bsavi=5D about draft-ietf-savi-fcfs-02 =CA=D5=BC=FE=C8=CB=3A robin =3Crobin=40huawei=2Ecom=3E =B3=AD=CB=CD=3A savi=40ietf=2Eorg =3E robin escribi=A8=AE=3A =3E =3E Hi marcelo=2C =3E =3E In IPv4 world=2C there is a binding of IPv4 address and port in = =3E BRAS = =3E = =3E what is bras=3F =3E = =3E =3E for the =3E =3E sake of security=2E When migration to IPv6=2C we do need a method= to = =3E bind the =3E =3E IPv6 address and its corresponding port=2E = =3E =3E The optimization defined by the MAY in draft-ietf-savi-fcfs-01 = =3E provided a =3E =3E practical solution for this=2E = =3E =3E =3E =3E = =3E i am not sure i follow (fwiwi i am not oposing to this=2C i simply = =3E fail to = =3E understnad what you are saying) =3E even without this optimization=2C we can create a binding for any = =3E IPv6 = =3E address and a port=2C so i am not sure i understnad what is your poin= t=2E =3E = =3E = =3E The only potential issue that i understnad this optimization is = =3E addressing=2C is the case of legacy implementations=2C that follow = =3E 2462 = =3E instead of 4862 that may not do the DAD for the global address if = =3E they = =3E have done so for the corresponding link local=2E =3E = =3E Regards=2C marcelo =3E = =3E = =3E = =3E =3E Best Regards=2C =3E =3E =3E =3E Robin =3E =3E =3E =3E -----Original Message----- =3E =3E From=3A marcelo bagnulo braun =5Bmailto=3Amarcelo=40it=2Euc3m=2Ee= s=5D = =3E =3E Sent=3A Friday=2C November 27=2C 2009 3=3A26 PM =3E =3E To=3A zhengruobin 35664 =3E =3E Cc=3A savi=40ietf=2Eorg =3E =3E Subject=3A Re=3A =5Bsavi=5D about draft-ietf-savi-fcfs-02 =3E =3E =3E =3E zhengruobin 35664 escribi=A8=AE=3A =3E =3E = =3E =3E=3E Hi There=2C =3E =3E=3E =3E =3E=3E In the draft-ietf-savi-fcfs-01=2C there is a description as = =3E follows in =3E =3E=3E = =3E =3E 3=2E2=2E2=2E Processing of control packets of draft-ietf-savi-fc= fs-01=3A =3E =3E = =3E =3E=3E =22If no NADV message for that Target Address is received in =3E =3E=3E DADTimeout=2C then the status of the entry is change = to = =3E valid and =3E =3E=3E the lifetime of the entry is set to LIFETIME=2E In = =3E addition=2C if =3E =3E=3E the address contained in the newly created entry is a= link =3E =3E=3E local address=2C FCFS SAVI MAY as well create entries= = =3E for the =3E =3E=3E global addresses resulting from concatenating the = =3E Interface=3E=3E Identifier of the link local address and the= = =3E global prefixes =3E =3E=3E contained in the Prefix List for the Interface throug= h = =3E which=3E=3E the NSOL message was received=2E=22 =3E =3E=3E =3E =3E=3E But the above is not covered in the draft-ietf-savi-fcfs-02=2E= I = =3E wonder what =3E =3E=3E = =3E =3E happened to this=2E =3E =3E = =3E =3E=3E = =3E =3E=3E = =3E =3E =3E =3E i understand you are talking about the optimization defined by = =3E the MAY=2C = =3E =3E right=3F =3E =3E since the version 01 has been through a major rewriting=2C this = =3E was = =3E =3E dropped unitentionally=2E =3E =3E =3E =3E I will include it in the next version if people still think it = =3E is a good = =3E =3E idea =3E =3E =3E =3E regards=2C marcelo =3E =3E =3E =3E =3E =3E =3E =3E = =3E =3E=3E Best regards=2C =3E =3E=3E =3E =3E=3E Robin =3E =3E=3E =3E =3E=3E =3E =3E=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F =3E =3E=3E savi mailing list =3E =3E=3E savi=40ietf=2Eorg =3E =3E=3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E =3E=3E =3E =3E=3E = =3E =3E=3E = =3E =3E =3E =3E =3E =3E = =3E = =3E From marcelo@it.uc3m.es Tue Dec 1 01:59:45 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89F33A67BE for ; Tue, 1 Dec 2009 01:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.176 X-Spam-Level: X-Spam-Status: No, score=-5.176 tagged_above=-999 required=5 tests=[AWL=-1.366, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 bka5YK88lrcd for ; Tue, 1 Dec 2009 01:59:44 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 5DC0C3A6A33 for ; Tue, 1 Dec 2009 01:59:44 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id DD3EB65524E; Tue, 1 Dec 2009 10:59:35 +0100 (CET) Message-ID: <4B14E907.8040009@it.uc3m.es> Date: Tue, 01 Dec 2009 10:59:35 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: zhengruobin 35664 References: <000501ca6fd5$9f08ed40$7a28460a@china.huawei.com> <4B10DED3.5070001@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17042.006 Cc: savi@ietf.org Subject: Re: [savi] about draft-ietf-savi-fcfs-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 09:59:45 -0000 zhengruobin 35664 escribió: > Hi marcelo, > > BRAS is the abbreviation of Broadband Remote Access Server, which is defined by DSL Forum in TR101. > > In the IPv4 access network, the bindings of IPv6 address and a port are done by DHCPv4 snooping. But in the IPv6 access network, the SLAAC may be used insteads of DHCPv6 for IPv6 address assignment. Thus, in case of SLAAC, a mechanism to discover the bindings of IPv6 address and a port is needed. > > make sense AFIAU, this is covered int he new version of the draft... what do you think it is missing? I mean, the particular text you are pointing out was an optimization for the in order to automatically create the binding for the gloabl addresses once the binding for the local address has been created. I don't have any problem with that optimization, but i think it changes much the resulting baheviour. So, i am not sure what do you think it is missing in order to support the case you describe. Regards, marcelo > Robin > > ----- 原邮件 ----- > 发件人: marcelo bagnulo braun > 日期: 星期六, 十一月 28日, 2009 下午4:27 > 主题: Re: [savi] about draft-ietf-savi-fcfs-02 > 收件人: robin > 抄送: savi@ietf.org > > >> robin escribió: >> >>> Hi marcelo, >>> In IPv4 world, there is a binding of IPv4 address and port in >>> >> BRAS >> >> what is bras? >> >> >>> for the >>> sake of security. When migration to IPv6, we do need a method to >>> >> bind the >> >>> IPv6 address and its corresponding port. >>> The optimization defined by the MAY in draft-ietf-savi-fcfs-01 >>> >> provided a >> >>> practical solution for this. >>> >>> >>> >> i am not sure i follow (fwiwi i am not oposing to this, i simply >> fail to >> understnad what you are saying) >> even without this optimization, we can create a binding for any >> IPv6 >> address and a port, so i am not sure i understnad what is your point. >> >> >> The only potential issue that i understnad this optimization is >> addressing, is the case of legacy implementations, that follow >> 2462 >> instead of 4862 that may not do the DAD for the global address if >> they >> have done so for the corresponding link local. >> >> Regards, marcelo >> >> >> >> >>> Best Regards, >>> >>> Robin >>> >>> -----Original Message----- >>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>> Sent: Friday, November 27, 2009 3:26 PM >>> To: zhengruobin 35664 >>> Cc: savi@ietf.org >>> Subject: Re: [savi] about draft-ietf-savi-fcfs-02 >>> >>> zhengruobin 35664 escribió: >>> >>> >>>> Hi There, >>>> >>>> In the draft-ietf-savi-fcfs-01, there is a description as >>>> >> follows in >> >>>> >>>> >>> 3.2.2. Processing of control packets of draft-ietf-savi-fcfs-01: >>> >>> >>>> "If no NADV message for that Target Address is received in >>>> DADTimeout, then the status of the entry is change to >>>> >> valid and >> >>>> the lifetime of the entry is set to LIFETIME. In >>>> >> addition, if >> >>>> the address contained in the newly created entry is a link >>>> local address, FCFS SAVI MAY as well create entries >>>> >> for the >> >>>> global addresses resulting from concatenating the >>>> >> Interface>> Identifier of the link local address and the >> global prefixes >> >>>> contained in the Prefix List for the Interface through >>>> >> which>> the NSOL message was received." >> >>>> But the above is not covered in the draft-ietf-savi-fcfs-02. I >>>> >> wonder what >> >>>> >>>> >>> happened to this. >>> >>> >>>> >>>> >>>> >>> i understand you are talking about the optimization defined by >>> >> the MAY, >> >>> right? >>> since the version 01 has been through a major rewriting, this >>> >> was >> >>> dropped unitentionally. >>> >>> I will include it in the next version if people still think it >>> >> is a good >> >>> idea >>> >>> regards, marcelo >>> >>> >>> >>> >>> >>>> Best regards, >>>> >>>> Robin >>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>>> >>>> >>>> >>> >>> >> > > From robin@huawei.com Tue Dec 1 02:55:46 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D24D43A6992 for ; Tue, 1 Dec 2009 02:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.242 X-Spam-Level: * X-Spam-Status: No, score=1.242 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] 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 Ri9H48Zjk6kp for ; Tue, 1 Dec 2009 02:55:45 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 998D13A698D for ; Tue, 1 Dec 2009 02:55:45 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTY005ZUZKKCM@szxga04-in.huawei.com> for savi@ietf.org; Tue, 01 Dec 2009 18:53:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTY001B6ZKKY0@szxga04-in.huawei.com> for savi@ietf.org; Tue, 01 Dec 2009 18:53:08 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [188.36.252.226]) by szxmc03-in.huawei.com (mshttpd); Tue, 01 Dec 2009 18:53:08 +0800 Date: Tue, 01 Dec 2009 18:53:08 +0800 From: zhengruobin 35664 In-reply-to: <4B14E907.8040009@it.uc3m.es> To: marcelo bagnulo braun Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <000501ca6fd5$9f08ed40$7a28460a@china.huawei.com> <4B10DED3.5070001@it.uc3m.es> <4B14E907.8040009@it.uc3m.es> Cc: savi@ietf.org Subject: Re: [savi] about draft-ietf-savi-fcfs-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 10:55:46 -0000 Hi Marcelo=2C In the draft-ietf-savi-fcfs-01=2C it proposes =22 if the address contain= ed in the newly created entry is a link local address=2C FCFS SAVI MAY as well create entries for the global addr= esses resulting from concatenating the = Interface Identifier of the link local address and the global prefixes co= ntained in the Prefix List for the Interface through = which the NSOL message was received=2E=22 However=2C this is missing in d= raft-ietf-savi-fcfs-02=2E I don=27t know what was the original purpose of this optimization for add= ressing=2E But it seems to me that it may be used to discover the user=27= s global address by SAVI device in case of SLAAC=2E = Best regards=2C Robin ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A marcelo bagnulo braun =3Cmarcelo=40it=2Euc3m=2Ees=3E= =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=B6=FE=D4=C2 1=C8=D5=2C 2009 = =CF=C2=CE=E76=3A29 =D6=F7=CC=E2=3A Re=3A =5Bsavi=5D about draft-ietf-savi-fcfs-02 =CA=D5=BC=FE=C8=CB=3A zhengruobin 35664 =3Crobin=40huawei=2Ecom=3E =B3=AD=CB=CD=3A savi=40ietf=2Eorg =3E zhengruobin 35664 escribi=A8=AE=3A =3E =3E Hi marcelo=2C =3E =3E =3E =3E BRAS is the abbreviation of Broadband Remote Access Server=2C = =3E which is defined by DSL Forum in TR101=2E =3E =3E =3E =3E In the IPv4 access network=2C the bindings of IPv6 address and a = =3E port are done by DHCPv4 snooping=2E But in the IPv6 access network=2C= = =3E the SLAAC may be used insteads of DHCPv6 for IPv6 address = =3E assignment=2E Thus=2C in case of SLAAC=2C a mechanism to discover the= = =3E bindings of IPv6 address and a port is needed=2E =3E =3E =3E =3E = =3E make sense =3E AFIAU=2C this is covered int he new version of the draft=2E=2E=2E wha= t do you =3E think it is missing=3F =3E = =3E I mean=2C the particular text you are pointing out was an = =3E optimization for =3E the in order to automatically create the binding for the gloabl =3E addresses once the binding for the local address has been created=2E = I =3E don=27t have any problem with that optimization=2C but i think it cha= nges =3E much the resulting baheviour=2E =3E = =3E So=2C i am not sure what do you think it is missing in order to suppo= rt =3E the case you describe=2E =3E = =3E Regards=2C marcelo =3E = =3E =3E Robin =3E =3E =3E =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =3E =B7=A2=BC=FE=C8=CB=3A marcelo bagnulo braun =3Cmarcelo=40it=2Euc3= m=2Ees=3E =3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=C1=F9=2C =CA=AE=D2=BB=D4=C2 28=C8=D5= =2C 2009 =CF=C2=CE=E74=3A27 =3E =3E =D6=F7=CC=E2=3A Re=3A =5Bsavi=5D about draft-ietf-savi-fcfs-02 =3E =3E =CA=D5=BC=FE=C8=CB=3A robin =3Crobin=40huawei=2Ecom=3E =3E =3E =B3=AD=CB=CD=3A savi=40ietf=2Eorg =3E =3E =3E =3E = =3E =3E=3E robin escribi=A8=AE=3A =3E =3E=3E = =3E =3E=3E=3E Hi marcelo=2C =3E =3E=3E=3E In IPv4 world=2C there is a binding of IPv4 address and por= t in = =3E =3E=3E=3E = =3E =3E=3E BRAS = =3E =3E=3E =3E =3E=3E what is bras=3F =3E =3E=3E =3E =3E=3E = =3E =3E=3E=3E for the =3E =3E=3E=3E sake of security=2E When migration to IPv6=2C we do need a = method = =3E to = =3E =3E=3E=3E = =3E =3E=3E bind the =3E =3E=3E = =3E =3E=3E=3E IPv6 address and its corresponding port=2E = =3E =3E=3E=3E The optimization defined by the MAY in draft-ietf-savi-fcfs= -01 = =3E =3E=3E=3E = =3E =3E=3E provided a =3E =3E=3E = =3E =3E=3E=3E practical solution for this=2E = =3E =3E=3E=3E =3E =3E=3E=3E = =3E =3E=3E=3E = =3E =3E=3E i am not sure i follow (fwiwi i am not oposing to this=2C i = =3E simply = =3E =3E=3E fail to = =3E =3E=3E understnad what you are saying) =3E =3E=3E even without this optimization=2C we can create a binding for = any = =3E =3E=3E IPv6 = =3E =3E=3E address and a port=2C so i am not sure i understnad what is yo= ur = =3E point=2E=3E=3E =3E =3E=3E =3E =3E=3E The only potential issue that i understnad this optimization i= s = =3E =3E=3E addressing=2C is the case of legacy implementations=2C that fo= llow = =3E =3E=3E 2462 = =3E =3E=3E instead of 4862 that may not do the DAD for the global address= = =3E if = =3E =3E=3E they = =3E =3E=3E have done so for the corresponding link local=2E =3E =3E=3E =3E =3E=3E Regards=2C marcelo =3E =3E=3E =3E =3E=3E =3E =3E=3E =3E =3E=3E = =3E =3E=3E=3E Best Regards=2C =3E =3E=3E=3E =3E =3E=3E=3E Robin =3E =3E=3E=3E =3E =3E=3E=3E -----Original Message----- =3E =3E=3E=3E From=3A marcelo bagnulo braun =5Bmailto=3Amarcelo=40it=2Euc= 3m=2Ees=5D = =3E =3E=3E=3E Sent=3A Friday=2C November 27=2C 2009 3=3A26 PM =3E =3E=3E=3E To=3A zhengruobin 35664 =3E =3E=3E=3E Cc=3A savi=40ietf=2Eorg =3E =3E=3E=3E Subject=3A Re=3A =5Bsavi=5D about draft-ietf-savi-fcfs-02 =3E =3E=3E=3E =3E =3E=3E=3E zhengruobin 35664 escribi=A8=AE=3A =3E =3E=3E=3E = =3E =3E=3E=3E = =3E =3E=3E=3E=3E Hi There=2C =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E In the draft-ietf-savi-fcfs-01=2C there is a description= as = =3E =3E=3E=3E=3E = =3E =3E=3E follows in =3E =3E=3E = =3E =3E=3E=3E=3E = =3E =3E=3E=3E=3E = =3E =3E=3E=3E 3=2E2=2E2=2E Processing of control packets of draft-ietf-s= avi-fcfs-01=3A =3E =3E=3E=3E = =3E =3E=3E=3E = =3E =3E=3E=3E=3E =22If no NADV message for that Target Address is receive= d in =3E =3E=3E=3E=3E DADTimeout=2C then the status of the entry is c= hange = =3E to = =3E =3E=3E=3E=3E = =3E =3E=3E valid and =3E =3E=3E = =3E =3E=3E=3E=3E the lifetime of the entry is set to LIFETIME=2E= In = =3E =3E=3E=3E=3E = =3E =3E=3E addition=2C if =3E =3E=3E = =3E =3E=3E=3E=3E the address contained in the newly created entr= y is = =3E a link =3E =3E=3E=3E=3E local address=2C FCFS SAVI MAY as well create e= ntries = =3E =3E=3E=3E=3E = =3E =3E=3E for the =3E =3E=3E = =3E =3E=3E=3E=3E global addresses resulting from concatenating t= he = =3E =3E=3E=3E=3E = =3E =3E=3E Interface=3E=3E Identifier of the link local address = and = =3E the = =3E =3E=3E global prefixes =3E =3E=3E = =3E =3E=3E=3E=3E contained in the Prefix List for the Interface = =3E through = =3E =3E=3E=3E=3E = =3E =3E=3E which=3E=3E the NSOL message was received=2E=22 =3E =3E=3E = =3E =3E=3E=3E=3E But the above is not covered in the draft-ietf-savi-fcfs= -02=2E = =3E I = =3E =3E=3E=3E=3E = =3E =3E=3E wonder what =3E =3E=3E = =3E =3E=3E=3E=3E = =3E =3E=3E=3E=3E = =3E =3E=3E=3E happened to this=2E =3E =3E=3E=3E = =3E =3E=3E=3E = =3E =3E=3E=3E=3E = =3E =3E=3E=3E=3E = =3E =3E=3E=3E=3E = =3E =3E=3E=3E i understand you are talking about the optimization defined= by = =3E =3E=3E=3E = =3E =3E=3E the MAY=2C = =3E =3E=3E = =3E =3E=3E=3E right=3F =3E =3E=3E=3E since the version 01 has been through a major rewriting=2C = this = =3E =3E=3E=3E = =3E =3E=3E was = =3E =3E=3E = =3E =3E=3E=3E dropped unitentionally=2E =3E =3E=3E=3E =3E =3E=3E=3E I will include it in the next version if people still think= it = =3E =3E=3E=3E = =3E =3E=3E is a good = =3E =3E=3E = =3E =3E=3E=3E idea =3E =3E=3E=3E =3E =3E=3E=3E regards=2C marcelo =3E =3E=3E=3E =3E =3E=3E=3E =3E =3E=3E=3E =3E =3E=3E=3E = =3E =3E=3E=3E = =3E =3E=3E=3E=3E Best regards=2C =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E Robin =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F =3E =3E=3E=3E=3E savi mailing list =3E =3E=3E=3E=3E savi=40ietf=2Eorg =3E =3E=3E=3E=3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/savi =3E =3E=3E=3E=3E =3E =3E=3E=3E=3E = =3E =3E=3E=3E=3E = =3E =3E=3E=3E=3E = =3E =3E=3E=3E = =3E =3E=3E=3E = =3E =3E=3E = =3E =3E =3E =3E = =3E = =3E From marcelo@it.uc3m.es Tue Dec 1 03:06:54 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B520D28C1D4 for ; Tue, 1 Dec 2009 03:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.096 X-Spam-Level: X-Spam-Status: No, score=-5.096 tagged_above=-999 required=5 tests=[AWL=-1.286, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 xkxuAm-Y3d5m for ; Tue, 1 Dec 2009 03:06:53 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 48FBF3A698D for ; Tue, 1 Dec 2009 03:06:52 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 8E9916C19CA; Tue, 1 Dec 2009 12:06:44 +0100 (CET) Message-ID: <4B14F8C4.9080603@it.uc3m.es> Date: Tue, 01 Dec 2009 12:06:44 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: zhengruobin 35664 References: <000501ca6fd5$9f08ed40$7a28460a@china.huawei.com> <4B10DED3.5070001@it.uc3m.es> <4B14E907.8040009@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17042.006 Cc: savi@ietf.org Subject: Re: [savi] about draft-ietf-savi-fcfs-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 11:06:54 -0000 zhengruobin 35664 escribió: > Hi Marcelo, > > In the draft-ietf-savi-fcfs-01, it proposes " if the address contained in the newly created entry is a link > local address, FCFS SAVI MAY as well create entries for the global addresses resulting from concatenating the > Interface Identifier of the link local address and the global prefixes contained in the Prefix List for the Interface through > which the NSOL message was received." However, this is missing in draft-ietf-savi-fcfs-02. > > I don't know what was the original purpose of this optimization for addressing. But it seems to me that it may be used to discover the user's global address by SAVI device in case of SLAAC. > But the node will do a DAD for the gloabl address as well, right? so the savi device will learn it when that happens, right? That is why i said it is an optimization. What am i missing? regards, marcelo > Best regards, > > Robin > > > ----- 原邮件 ----- > 发件人: marcelo bagnulo braun > 日期: 星期二, 十二月 1日, 2009 下午6:29 > 主题: Re: [savi] about draft-ietf-savi-fcfs-02 > 收件人: zhengruobin 35664 > 抄送: savi@ietf.org > > >> zhengruobin 35664 escribió: >> >>> Hi marcelo, >>> >>> BRAS is the abbreviation of Broadband Remote Access Server, >>> >> which is defined by DSL Forum in TR101. >> >>> In the IPv4 access network, the bindings of IPv6 address and a >>> >> port are done by DHCPv4 snooping. But in the IPv6 access network, >> the SLAAC may be used insteads of DHCPv6 for IPv6 address >> assignment. Thus, in case of SLAAC, a mechanism to discover the >> bindings of IPv6 address and a port is needed. >> >>> >>> >> make sense >> AFIAU, this is covered int he new version of the draft... what do you >> think it is missing? >> >> I mean, the particular text you are pointing out was an >> optimization for >> the in order to automatically create the binding for the gloabl >> addresses once the binding for the local address has been created. I >> don't have any problem with that optimization, but i think it changes >> much the resulting baheviour. >> >> So, i am not sure what do you think it is missing in order to support >> the case you describe. >> >> Regards, marcelo >> >> >>> Robin >>> >>> ----- 原邮件 ----- >>> 发件人: marcelo bagnulo braun >>> 日期: 星期六, 十一月 28日, 2009 下午4:27 >>> 主题: Re: [savi] about draft-ietf-savi-fcfs-02 >>> 收件人: robin >>> 抄送: savi@ietf.org >>> >>> >>> >>>> robin escribió: >>>> >>>> >>>>> Hi marcelo, >>>>> In IPv4 world, there is a binding of IPv4 address and port in >>>>> >>>>> >>>> BRAS >>>> >>>> what is bras? >>>> >>>> >>>> >>>>> for the >>>>> sake of security. When migration to IPv6, we do need a method >>>>> >> to >> >>>>> >>>>> >>>> bind the >>>> >>>> >>>>> IPv6 address and its corresponding port. >>>>> The optimization defined by the MAY in draft-ietf-savi-fcfs-01 >>>>> >>>>> >>>> provided a >>>> >>>> >>>>> practical solution for this. >>>>> >>>>> >>>>> >>>>> >>>> i am not sure i follow (fwiwi i am not oposing to this, i >>>> >> simply >> >>>> fail to >>>> understnad what you are saying) >>>> even without this optimization, we can create a binding for any >>>> IPv6 >>>> address and a port, so i am not sure i understnad what is your >>>> >> point.>> >> >>>> The only potential issue that i understnad this optimization is >>>> addressing, is the case of legacy implementations, that follow >>>> 2462 >>>> instead of 4862 that may not do the DAD for the global address >>>> >> if >> >>>> they >>>> have done so for the corresponding link local. >>>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> >>>> >>>>> Best Regards, >>>>> >>>>> Robin >>>>> >>>>> -----Original Message----- >>>>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>>>> Sent: Friday, November 27, 2009 3:26 PM >>>>> To: zhengruobin 35664 >>>>> Cc: savi@ietf.org >>>>> Subject: Re: [savi] about draft-ietf-savi-fcfs-02 >>>>> >>>>> zhengruobin 35664 escribió: >>>>> >>>>> >>>>> >>>>>> Hi There, >>>>>> >>>>>> In the draft-ietf-savi-fcfs-01, there is a description as >>>>>> >>>>>> >>>> follows in >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>> 3.2.2. Processing of control packets of draft-ietf-savi-fcfs-01: >>>>> >>>>> >>>>> >>>>>> "If no NADV message for that Target Address is received in >>>>>> DADTimeout, then the status of the entry is change >>>>>> >> to >> >>>>>> >>>>>> >>>> valid and >>>> >>>> >>>>>> the lifetime of the entry is set to LIFETIME. In >>>>>> >>>>>> >>>> addition, if >>>> >>>> >>>>>> the address contained in the newly created entry is >>>>>> >> a link >> >>>>>> local address, FCFS SAVI MAY as well create entries >>>>>> >>>>>> >>>> for the >>>> >>>> >>>>>> global addresses resulting from concatenating the >>>>>> >>>>>> >>>> Interface>> Identifier of the link local address and >>>> >> the >> >>>> global prefixes >>>> >>>> >>>>>> contained in the Prefix List for the Interface >>>>>> >> through >> >>>>>> >>>>>> >>>> which>> the NSOL message was received." >>>> >>>> >>>>>> But the above is not covered in the draft-ietf-savi-fcfs-02. >>>>>> >> I >> >>>>>> >>>>>> >>>> wonder what >>>> >>>> >>>>>> >>>>>> >>>>>> >>>>> happened to this. >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> i understand you are talking about the optimization defined by >>>>> >>>>> >>>> the MAY, >>>> >>>> >>>>> right? >>>>> since the version 01 has been through a major rewriting, this >>>>> >>>>> >>>> was >>>> >>>> >>>>> dropped unitentionally. >>>>> >>>>> I will include it in the next version if people still think it >>>>> >>>>> >>>> is a good >>>> >>>> >>>>> idea >>>>> >>>>> regards, marcelo >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Best regards, >>>>>> >>>>>> Robin >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > From marcelo@it.uc3m.es Tue Dec 1 03:34:50 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2703E3A68B7 for ; Tue, 1 Dec 2009 03:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.025 X-Spam-Level: X-Spam-Status: No, score=-5.025 tagged_above=-999 required=5 tests=[AWL=-1.215, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 VlSqIjEsnR9J for ; Tue, 1 Dec 2009 03:34:48 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 53F143A6819 for ; Tue, 1 Dec 2009 03:34:48 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 7FFB76C30B4; Tue, 1 Dec 2009 12:34:39 +0100 (CET) Message-ID: <4B14FF4C.4070907@it.uc3m.es> Date: Tue, 01 Dec 2009 12:34:36 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: zhengruobin 35664 , SAVI Mailing List References: <000501ca6fd5$9f08ed40$7a28460a@china.huawei.com> <4B10DED3.5070001@it.uc3m.es> <4B14E907.8040009@it.uc3m.es> <4B14F8C4.9080603@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17042.006 Subject: Re: [savi] about draft-ietf-savi-fcfs-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 11:34:50 -0000 (mm, it seems the savi cc got lost somehwere. i include it back) zhengruobin 35664 escribió: > Hi Marcelo, > > A DAD for a LLA is mandatory. But a DAD for a global address is not mandatory. > How about in case of only DAD for a LLA? > > right, this is what i was mentioning earlier. This has changed from rfc2462 to rfc4862 In rfc2462, this was accepted. in rfc4862, the rfc reads: 5.4. Duplicate Address Detection Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of whether they are obtained through stateless autoconfiguration, DHCPv6, or manual configuration, with the following exceptions: - An interface whose DupAddrDetectTransmits variable is set to zero does not perform Duplicate Address Detection. - Duplicate Address Detection MUST NOT be performed on anycast addresses (note that anycast addresses cannot syntactically be distinguished from unicast addresses). - Each individual unicast address SHOULD be tested for uniqueness. Note that there are implementations deployed that only perform Duplicate Address Detection for the link-local address and skip the test for the global address that uses the same interface identifier as that of the link-local address. Whereas this document does not invalidate such implementations, this kind of "optimization" is NOT RECOMMENDED, and new implementations MUST NOT do that optimization. So, this is not reccomended i.e. if you do that and something breaks, then it is your problem. So the question is whether we want to account for these type of hosts or not. As i mentioned earlier, i don't have a problem with doing that. I would be interested in hearing what other people have to say about this. Regards, marcelo > Best regards, > > Robin > > ----- 原邮件 ----- > 发件人: marcelo bagnulo braun > 日期: 星期二, 十二月 1日, 2009 下午7:07 > 主题: Re: [savi] about draft-ietf-savi-fcfs-02 > 收件人: zhengruobin 35664 > 抄送: savi@ietf.org > > >> zhengruobin 35664 escribió: >> >>> Hi Marcelo, >>> >>> In the draft-ietf-savi-fcfs-01, it proposes " if the address >>> >> contained in the newly created entry is a link >> >>> local address, FCFS SAVI MAY as well create entries for the >>> >> global addresses resulting from concatenating the >> >>> Interface Identifier of the link local address and the global >>> >> prefixes contained in the Prefix List for the Interface through >> >>> which the NSOL message was received." However, this is missing >>> >> in draft-ietf-savi-fcfs-02. >> >>> I don't know what was the original purpose of this optimization >>> >> for addressing. But it seems to me that it may be used to discover >> the user's global address by SAVI device in case of SLAAC. >> >>> >>> >> But the node will do a DAD for the gloabl address as well, right? >> so the >> savi device will learn it when that happens, right? >> >> That is why i said it is an optimization. >> What am i missing? >> >> regards, marcelo >> >> >> >>> Best regards, >>> >>> Robin >>> >>> >>> ----- 原邮件 ----- >>> 发件人: marcelo bagnulo braun >>> 日期: 星期二, 十二月 1日, 2009 下午6:29 >>> 主题: Re: [savi] about draft-ietf-savi-fcfs-02 >>> 收件人: zhengruobin 35664 >>> 抄送: savi@ietf.org >>> >>> >>> >>>> zhengruobin 35664 escribió: >>>> >>>> >>>>> Hi marcelo, >>>>> >>>>> BRAS is the abbreviation of Broadband Remote Access Server, >>>>> >>>>> >>>> which is defined by DSL Forum in TR101. >>>> >>>> >>>>> In the IPv4 access network, the bindings of IPv6 address and a >>>>> >>>>> >>>> port are done by DHCPv4 snooping. But in the IPv6 access >>>> >> network, >> >>>> the SLAAC may be used insteads of DHCPv6 for IPv6 address >>>> assignment. Thus, in case of SLAAC, a mechanism to discover the >>>> bindings of IPv6 address and a port is needed. >>>> >>>> >>>>> >>>>> >>>>> >>>> make sense >>>> AFIAU, this is covered int he new version of the draft... what >>>> >> do you >> >>>> think it is missing? >>>> >>>> I mean, the particular text you are pointing out was an >>>> optimization for >>>> the in order to automatically create the binding for the gloabl >>>> addresses once the binding for the local address has been >>>> >> created. I >> >>>> don't have any problem with that optimization, but i think it >>>> >> changes>> much the resulting baheviour. >> >>>> So, i am not sure what do you think it is missing in order to >>>> >> support>> the case you describe. >> >>>> Regards, marcelo >>>> >>>> >>>> >>>>> Robin >>>>> >>>>> ----- 原邮件 ----- >>>>> 发件人: marcelo bagnulo braun >>>>> 日期: 星期六, 十一月 28日, 2009 下午4:27 >>>>> 主题: Re: [savi] about draft-ietf-savi-fcfs-02 >>>>> 收件人: robin >>>>> 抄送: savi@ietf.org >>>>> >>>>> >>>>> >>>>> >>>>>> robin escribió: >>>>>> >>>>>> >>>>>> >>>>>>> Hi marcelo, >>>>>>> In IPv4 world, there is a binding of IPv4 address and port >>>>>>> >> in >> >>>>>>> >>>>>>> >>>>>>> >>>>>> BRAS >>>>>> >>>>>> what is bras? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> for the >>>>>>> sake of security. When migration to IPv6, we do need a >>>>>>> >> method >> >>>>>>> >>>>>>> >>>> to >>>> >>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> bind the >>>>>> >>>>>> >>>>>> >>>>>>> IPv6 address and its corresponding port. >>>>>>> The optimization defined by the MAY in draft-ietf-savi-fcfs- >>>>>>> >> 01 >> >>>>>>> >>>>>>> >>>>>>> >>>>>> provided a >>>>>> >>>>>> >>>>>> >>>>>>> practical solution for this. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> i am not sure i follow (fwiwi i am not oposing to this, i >>>>>> >>>>>> >>>> simply >>>> >>>> >>>>>> fail to >>>>>> understnad what you are saying) >>>>>> even without this optimization, we can create a binding for >>>>>> >> any >> >>>>>> IPv6 >>>>>> address and a port, so i am not sure i understnad what is >>>>>> >> your >> >>>>>> >>>>>> >>>> point.>> >>>> >>>> >>>>>> The only potential issue that i understnad this optimization >>>>>> >> is >> >>>>>> addressing, is the case of legacy implementations, that >>>>>> >> follow >> >>>>>> 2462 >>>>>> instead of 4862 that may not do the DAD for the global >>>>>> >> address >> >>>>>> >>>>>> >>>> if >>>> >>>> >>>>>> they >>>>>> have done so for the corresponding link local. >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Robin >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >>>>>>> Sent: Friday, November 27, 2009 3:26 PM >>>>>>> To: zhengruobin 35664 >>>>>>> Cc: savi@ietf.org >>>>>>> Subject: Re: [savi] about draft-ietf-savi-fcfs-02 >>>>>>> >>>>>>> zhengruobin 35664 escribió: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi There, >>>>>>>> >>>>>>>> In the draft-ietf-savi-fcfs-01, there is a description as >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> follows in >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> 3.2.2. Processing of control packets of draft-ietf-savi- >>>>>>> >> fcfs-01: >> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> "If no NADV message for that Target Address is received in >>>>>>>> DADTimeout, then the status of the entry is change >>>>>>>> >>>>>>>> >>>> to >>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> valid and >>>>>> >>>>>> >>>>>> >>>>>>>> the lifetime of the entry is set to LIFETIME. In >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> addition, if >>>>>> >>>>>> >>>>>> >>>>>>>> the address contained in the newly created entry >>>>>>>> >> is >> >>>>>>>> >>>>>>>> >>>> a link >>>> >>>> >>>>>>>> local address, FCFS SAVI MAY as well create >>>>>>>> >> entries >> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> for the >>>>>> >>>>>> >>>>>> >>>>>>>> global addresses resulting from concatenating the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> Interface>> Identifier of the link local address and >>>>>> >>>>>> >>>> the >>>> >>>> >>>>>> global prefixes >>>>>> >>>>>> >>>>>> >>>>>>>> contained in the Prefix List for the Interface >>>>>>>> >>>>>>>> >>>> through >>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> which>> the NSOL message was received." >>>>>> >>>>>> >>>>>> >>>>>>>> But the above is not covered in the draft-ietf-savi-fcfs- >>>>>>>> >> 02. >> >>>>>>>> >>>>>>>> >>>> I >>>> >>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> wonder what >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> happened to this. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> i understand you are talking about the optimization defined >>>>>>> >> by >> >>>>>>> >>>>>>> >>>>>>> >>>>>> the MAY, >>>>>> >>>>>> >>>>>> >>>>>>> right? >>>>>>> since the version 01 has been through a major rewriting, >>>>>>> >> this >> >>>>>>> >>>>>>> >>>>>>> >>>>>> was >>>>>> >>>>>> >>>>>> >>>>>>> dropped unitentionally. >>>>>>> >>>>>>> I will include it in the next version if people still think >>>>>>> >> it >> >>>>>>> >>>>>>> >>>>>>> >>>>>> is a good >>>>>> >>>>>> >>>>>> >>>>>>> idea >>>>>>> >>>>>>> regards, marcelo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Robin >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> savi mailing list >>>>>>>> savi@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > > From alberto@it.uc3m.es Tue Dec 1 06:52:03 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9797C3A67E2 for ; Tue, 1 Dec 2009 06:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.695 X-Spam-Level: X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 FdxboFJQN8pz for ; Tue, 1 Dec 2009 06:52:02 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B298D3A682B for ; Tue, 1 Dec 2009 06:52:01 -0800 (PST) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id C31646C2B27; Tue, 1 Dec 2009 15:51:52 +0100 (CET) From: =?utf-8?Q?Alberto_Garc=C3=ADa?= To: "'marcelo bagnulo braun'" , "'zhengruobin 35664'" , "'SAVI Mailing List'" References: <000501ca6fd5$9f08ed40$7a28460a@china.huawei.com><4B10DED3.5070001@it.uc3m.es><4B14E907.8040009@it.uc3m.es><4B14F8C4.9080603@it.uc3m.es> <4B14FF4C.4070907@it.uc3m.es> Date: Tue, 1 Dec 2009 15:51:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acpyekhq14smCRv1RQKivRXzvg4OjgAGjr1w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <4B14FF4C.4070907@it.uc3m.es> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17042.007 Subject: Re: [savi] about draft-ietf-savi-fcfs-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 14:52:03 -0000 Hi | -----Mensaje original----- | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En nombre de = marcelo | bagnulo braun | Enviado el: martes, 01 de diciembre de 2009 12:35 | Para: zhengruobin 35664; SAVI Mailing List | Asunto: Re: [savi] about draft-ietf-savi-fcfs-02 | =20 | (mm, it seems the savi cc got lost somehwere. i include it back) | =20 | zhengruobin 35664 escribi=C3=B3: | > Hi Marcelo, | > | > A DAD for a LLA is mandatory. But a DAD for a global address is not | mandatory. | > How about in case of only DAD for a LLA? Even if hosts don't do DAD for global addresses and SAVI does not create = a binding for the global address 'resulting' from the LLA when the LLA = address does DAD, I don't see much problem. (fcfs-v02): the reception of a data packet with the global address as = source address when the SAVI device is in NO_BIND state triggers a = 2xDAD_NSOL that is sent through the Trusted ports and moves to = TENTATIVE. Unless there is a binding in other SAVI device and a host has = the address configured, the timer expires and state moves to VALID.=20 Any problem with this behavior? (apart from loosing - buffering - some = data packets) Regards, Alberto | > | > | right, this is what i was mentioning earlier. | =20 | This has changed from rfc2462 to rfc4862 | =20 | In rfc2462, this was accepted. | =20 | in rfc4862, the rfc reads: | =20 | 5.4. Duplicate Address Detection | =20 | =20 | Duplicate Address Detection MUST be performed on all unicast | addresses prior to assigning them to an interface, regardless of | whether they are obtained through stateless autoconfiguration, | DHCPv6, or manual configuration, with the following exceptions: | =20 | - An interface whose DupAddrDetectTransmits variable is set to zero | does not perform Duplicate Address Detection. | =20 | - Duplicate Address Detection MUST NOT be performed on anycast | addresses (note that anycast addresses cannot syntactically be | distinguished from unicast addresses). | =20 | - Each individual unicast address SHOULD be tested for uniqueness. | Note that there are implementations deployed that only perform | Duplicate Address Detection for the link-local address and skip | the test for the global address that uses the same interface | identifier as that of the link-local address. Whereas this | document does not invalidate such implementations, this kind of | "optimization" is NOT RECOMMENDED, and new implementations MUST | NOT do that optimization. | =20 | =20 | So, this is not reccomended i.e. if you do that and something breaks, | then it is your problem. | =20 | So the question is whether we want to account for these type of hosts = or | not. | =20 | As i mentioned earlier, i don't have a problem with doing that. I = would | be interested in hearing what other people have to say about this. | =20 | =20 | Regards, marcelo | =20 | =20 | > Best regards, | > | > Robin | > | > ----- =E5=8E=9F=E9=82=AE=E4=BB=B6 ----- | > =E5=8F=91=E4=BB=B6=E4=BA=BA: marcelo bagnulo braun = | > =E6=97=A5=E6=9C=9F: =E6=98=9F=E6=9C=9F=E4=BA=8C, = =E5=8D=81=E4=BA=8C=E6=9C=88 1=E6=97=A5, 2009 =E4=B8=8B=E5=8D=887:07 | > =E4=B8=BB=E9=A2=98: Re: [savi] about draft-ietf-savi-fcfs-02 | > =E6=94=B6=E4=BB=B6=E4=BA=BA: zhengruobin 35664 | > =E6=8A=84=E9=80=81: savi@ietf.org | > | > | >> zhengruobin 35664 escribi=C3=B3: | >> | >>> Hi Marcelo, | >>> | >>> In the draft-ietf-savi-fcfs-01, it proposes " if the address | >>> | >> contained in the newly created entry is a link | >> | >>> local address, FCFS SAVI MAY as well create entries for the | >>> | >> global addresses resulting from concatenating the | >> | >>> Interface Identifier of the link local address and the global | >>> | >> prefixes contained in the Prefix List for the Interface through | >> | >>> which the NSOL message was received." However, this is missing | >>> | >> in draft-ietf-savi-fcfs-02. | >> | >>> I don't know what was the original purpose of this optimization | >>> | >> for addressing. But it seems to me that it may be used to discover | >> the user's global address by SAVI device in case of SLAAC. | >> | >>> | >>> | >> But the node will do a DAD for the gloabl address as well, right? | >> so the | >> savi device will learn it when that happens, right? | >> | >> That is why i said it is an optimization. | >> What am i missing? | >> | >> regards, marcelo | >> | >> | >> | >>> Best regards, | >>> | >>> Robin | >>> | >>> | >>> ----- =E5=8E=9F=E9=82=AE=E4=BB=B6 ----- | >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: marcelo bagnulo braun = | >>> =E6=97=A5=E6=9C=9F: =E6=98=9F=E6=9C=9F=E4=BA=8C, = =E5=8D=81=E4=BA=8C=E6=9C=88 1=E6=97=A5, 2009 =E4=B8=8B=E5=8D=886:29 | >>> =E4=B8=BB=E9=A2=98: Re: [savi] about draft-ietf-savi-fcfs-02 | >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: zhengruobin 35664 | >>> =E6=8A=84=E9=80=81: savi@ietf.org | >>> | >>> | >>> | >>>> zhengruobin 35664 escribi=C3=B3: | >>>> | >>>> | >>>>> Hi marcelo, | >>>>> | >>>>> BRAS is the abbreviation of Broadband Remote Access Server, | >>>>> | >>>>> | >>>> which is defined by DSL Forum in TR101. | >>>> | >>>> | >>>>> In the IPv4 access network, the bindings of IPv6 address and a | >>>>> | >>>>> | >>>> port are done by DHCPv4 snooping. But in the IPv6 access | >>>> | >> network, | >> | >>>> the SLAAC may be used insteads of DHCPv6 for IPv6 address | >>>> assignment. Thus, in case of SLAAC, a mechanism to discover the | >>>> bindings of IPv6 address and a port is needed. | >>>> | >>>> | >>>>> | >>>>> | >>>>> | >>>> make sense | >>>> AFIAU, this is covered int he new version of the draft... what | >>>> | >> do you | >> | >>>> think it is missing? | >>>> | >>>> I mean, the particular text you are pointing out was an | >>>> optimization for | >>>> the in order to automatically create the binding for the gloabl | >>>> addresses once the binding for the local address has been | >>>> | >> created. I | >> | >>>> don't have any problem with that optimization, but i think it | >>>> | >> changes>> much the resulting baheviour. | >> | >>>> So, i am not sure what do you think it is missing in order to | >>>> | >> support>> the case you describe. | >> | >>>> Regards, marcelo | >>>> | >>>> | >>>> | >>>>> Robin | >>>>> | >>>>> ----- =E5=8E=9F=E9=82=AE=E4=BB=B6 ----- | >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: marcelo bagnulo braun = | >>>>> =E6=97=A5=E6=9C=9F: =E6=98=9F=E6=9C=9F=E5=85=AD, = =E5=8D=81=E4=B8=80=E6=9C=88 28=E6=97=A5, 2009 =E4=B8=8B=E5=8D=884:27 | >>>>> =E4=B8=BB=E9=A2=98: Re: [savi] about draft-ietf-savi-fcfs-02 | >>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: robin | >>>>> =E6=8A=84=E9=80=81: savi@ietf.org | >>>>> | >>>>> | >>>>> | >>>>> | >>>>>> robin escribi=C3=B3: | >>>>>> | >>>>>> | >>>>>> | >>>>>>> Hi marcelo, | >>>>>>> In IPv4 world, there is a binding of IPv4 address and port | >>>>>>> | >> in | >> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>> BRAS | >>>>>> | >>>>>> what is bras? | >>>>>> | >>>>>> | >>>>>> | >>>>>> | >>>>>>> for the | >>>>>>> sake of security. When migration to IPv6, we do need a | >>>>>>> | >> method | >> | >>>>>>> | >>>>>>> | >>>> to | >>>> | >>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>> bind the | >>>>>> | >>>>>> | >>>>>> | >>>>>>> IPv6 address and its corresponding port. | >>>>>>> The optimization defined by the MAY in draft-ietf-savi-fcfs- | >>>>>>> | >> 01 | >> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>> provided a | >>>>>> | >>>>>> | >>>>>> | >>>>>>> practical solution for this. | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>> i am not sure i follow (fwiwi i am not oposing to this, i | >>>>>> | >>>>>> | >>>> simply | >>>> | >>>> | >>>>>> fail to | >>>>>> understnad what you are saying) | >>>>>> even without this optimization, we can create a binding for | >>>>>> | >> any | >> | >>>>>> IPv6 | >>>>>> address and a port, so i am not sure i understnad what is | >>>>>> | >> your | >> | >>>>>> | >>>>>> | >>>> point.>> | >>>> | >>>> | >>>>>> The only potential issue that i understnad this optimization | >>>>>> | >> is | >> | >>>>>> addressing, is the case of legacy implementations, that | >>>>>> | >> follow | >> | >>>>>> 2462 | >>>>>> instead of 4862 that may not do the DAD for the global | >>>>>> | >> address | >> | >>>>>> | >>>>>> | >>>> if | >>>> | >>>> | >>>>>> they | >>>>>> have done so for the corresponding link local. | >>>>>> | >>>>>> Regards, marcelo | >>>>>> | >>>>>> | >>>>>> | >>>>>> | >>>>>> | >>>>>> | >>>>>>> Best Regards, | >>>>>>> | >>>>>>> Robin | >>>>>>> | >>>>>>> -----Original Message----- | >>>>>>> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] | >>>>>>> Sent: Friday, November 27, 2009 3:26 PM | >>>>>>> To: zhengruobin 35664 | >>>>>>> Cc: savi@ietf.org | >>>>>>> Subject: Re: [savi] about draft-ietf-savi-fcfs-02 | >>>>>>> | >>>>>>> zhengruobin 35664 escribi=C3=B3: | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>>> Hi There, | >>>>>>>> | >>>>>>>> In the draft-ietf-savi-fcfs-01, there is a description as | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>> follows in | >>>>>> | >>>>>> | >>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>> 3.2.2. Processing of control packets of draft-ietf-savi- | >>>>>>> | >> fcfs-01: | >> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>>> "If no NADV message for that Target Address is received in | >>>>>>>> DADTimeout, then the status of the entry is change | >>>>>>>> | >>>>>>>> | >>>> to | >>>> | >>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>> valid and | >>>>>> | >>>>>> | >>>>>> | >>>>>>>> the lifetime of the entry is set to LIFETIME. In | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>> addition, if | >>>>>> | >>>>>> | >>>>>> | >>>>>>>> the address contained in the newly created entry | >>>>>>>> | >> is | >> | >>>>>>>> | >>>>>>>> | >>>> a link | >>>> | >>>> | >>>>>>>> local address, FCFS SAVI MAY as well create | >>>>>>>> | >> entries | >> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>> for the | >>>>>> | >>>>>> | >>>>>> | >>>>>>>> global addresses resulting from concatenating the | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>> Interface>> Identifier of the link local address and | >>>>>> | >>>>>> | >>>> the | >>>> | >>>> | >>>>>> global prefixes | >>>>>> | >>>>>> | >>>>>> | >>>>>>>> contained in the Prefix List for the Interface | >>>>>>>> | >>>>>>>> | >>>> through | >>>> | >>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>> which>> the NSOL message was received." | >>>>>> | >>>>>> | >>>>>> | >>>>>>>> But the above is not covered in the draft-ietf-savi-fcfs- | >>>>>>>> | >> 02. | >> | >>>>>>>> | >>>>>>>> | >>>> I | >>>> | >>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>> wonder what | >>>>>> | >>>>>> | >>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>> happened to this. | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>> i understand you are talking about the optimization defined | >>>>>>> | >> by | >> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>> the MAY, | >>>>>> | >>>>>> | >>>>>> | >>>>>>> right? | >>>>>>> since the version 01 has been through a major rewriting, | >>>>>>> | >> this | >> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>> was | >>>>>> | >>>>>> | >>>>>> | >>>>>>> dropped unitentionally. | >>>>>>> | >>>>>>> I will include it in the next version if people still think | >>>>>>> | >> it | >> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>> is a good | >>>>>> | >>>>>> | >>>>>> | >>>>>>> idea | >>>>>>> | >>>>>>> regards, marcelo | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>>> Best regards, | >>>>>>>> | >>>>>>>> Robin | >>>>>>>> | >>>>>>>> | >>>>>>>> _______________________________________________ | >>>>>>>> savi mailing list | >>>>>>>> savi@ietf.org | >>>>>>>> https://www.ietf.org/mailman/listinfo/savi | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>>> | >>>>>> | >>>>>> | >>>>>> | >>>>> | >>>>> | >>>>> | >>>> | >>>> | >>> | >>> | >> | > | > | =20 | _______________________________________________ | savi mailing list | savi@ietf.org | https://www.ietf.org/mailman/listinfo/savi From robin@huawei.com Tue Dec 1 09:23:04 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1964A3A68B8 for ; Tue, 1 Dec 2009 09:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.918 X-Spam-Level: * X-Spam-Status: No, score=1.918 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] 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 WbULB90LmGdD for ; Tue, 1 Dec 2009 09:23:03 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1B5613A689B for ; Tue, 1 Dec 2009 09:23:03 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTZ00HMTHLNAX@szxga04-in.huawei.com> for savi@ietf.org; Wed, 02 Dec 2009 01:22:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTZ00BGPHLNZ7@szxga04-in.huawei.com> for savi@ietf.org; Wed, 02 Dec 2009 01:22:35 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [188.36.252.226]) by szxmc03-in.huawei.com (mshttpd); Wed, 02 Dec 2009 01:22:35 +0800 Date: Wed, 02 Dec 2009 01:22:35 +0800 From: zhengruobin 35664 In-reply-to: To: Alberto Garc=?gb2312?B?qKo=?=a Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <000501ca6fd5$9f08ed40$7a28460a@china.huawei.com> <4B10DED3.5070001@it.uc3m.es> <4B14E907.8040009@it.uc3m.es> <4B14F8C4.9080603@it.uc3m.es> <4B14FF4C.4070907@it.uc3m.es> Cc: 'SAVI Mailing List' Subject: Re: [savi] about draft-ietf-savi-fcfs-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 17:23:04 -0000 Hi Alberto=2C As far as a wireless interface between the SAVI device and mobile user is= concerned=2C the DAD for all the global addresses seems making no sense=2E= Can you imagine how much bandwidth in the wireless interface consumes by= the DAD procedure for all the global addresses=2E In order to prevent that=2C usually the router will allocate different pr= efix to different mobile user or access loop such that the global address= of different user will not be duplicated=2E So I don=27t see the necessa= rity to do the DAD for global addresses in all cases=2E Best regards=2C Robin ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Alberto Garc=A8=AAa =3Calberto=40it=2Euc3m=2Ees=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=B6=FE=D4=C2 1=C8=D5=2C 2009 = =CF=C2=CE=E710=3A52 =D6=F7=CC=E2=3A RE=3A =5Bsavi=5D about draft-ietf-savi-fcfs-02 =CA=D5=BC=FE=C8=CB=3A =27marcelo bagnulo braun=27 =3Cmarcelo=40it=2Euc3m=2E= es=3E=2C =27zhengruobin 35664=27 =3Crobin=40huawei=2Ecom=3E=2C =27SAVI Ma= iling List=27 =3Csavi=40ietf=2Eorg=3E =3E Hi =3E = =3E =7C -----Mensaje original----- =3E =7C De=3A savi-bounces=40ietf=2Eorg =5Bmailto=3Asavi-bounces=40ietf=2E= org=5D En = =3E nombre de marcelo =3E =7C bagnulo braun =3E =7C Enviado el=3A martes=2C 01 de diciembre de 2009 12=3A35 =3E =7C Para=3A zhengruobin 35664=3B SAVI Mailing List =3E =7C Asunto=3A Re=3A =5Bsavi=5D about draft-ietf-savi-fcfs-02 =3E =7C = =3E =7C (mm=2C it seems the savi cc got lost somehwere=2E i include it b= ack) =3E =7C = =3E =7C zhengruobin 35664 escribi=A8=AE=3A =3E =7C =3E Hi Marcelo=2C =3E =7C =3E =3E =7C =3E A DAD for a LLA is mandatory=2E But a DAD for a global addre= ss = =3E is not =3E =7C mandatory=2E =3E =7C =3E How about in case of only DAD for a LLA=3F =3E = =3E Even if hosts don=27t do DAD for global addresses and SAVI does not = =3E create a binding for the global address =27resulting=27 from the LLA = =3E when the LLA address does DAD=2C I don=27t see much problem=2E =3E (fcfs-v02)=3A the reception of a data packet with the global address = =3E as source address when the SAVI device is in NO=5FBIND state = =3E triggers a 2xDAD=5FNSOL that is sent through the Trusted ports and = =3E moves to TENTATIVE=2E Unless there is a binding in other SAVI device = =3E and a host has the address configured=2C the timer expires and state = =3E moves to VALID=2E = =3E = =3E Any problem with this behavior=3F (apart from loosing - buffering - = =3E some data packets) =3E = =3E Regards=2C =3E Alberto =3E = From yaoa02@mails.tsinghua.edu.cn Tue Dec 1 19:48:03 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E383A6812 for ; Tue, 1 Dec 2009 19:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.679 X-Spam-Level: * X-Spam-Status: No, score=1.679 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] 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 TXaqXWMFwajF for ; Tue, 1 Dec 2009 19:48:02 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 20A813A67AE for ; Tue, 1 Dec 2009 19:48:00 -0800 (PST) Received: from tu132199.ip.tsinghua.edu.cn ([166.111.132.199] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NFgBv-0003Mb-47 for savi@ietf.org; Wed, 02 Dec 2009 11:47:47 +0800 From: "Guang Yao" To: "'SAVI Mailing List'" References: <000501ca6fd5$9f08ed40$7a28460a@china.huawei.com> <4B10DED3.5070001@it.uc3m.es> <4B14E907.8040009@it.uc3m.es> <4B14F8C4.9080603@it.uc3m.es> <4B14FF4C.4070907@it.uc3m.es> In-Reply-To: Date: Wed, 2 Dec 2009 11:47:36 +0800 Message-ID: <003301ca7302$3034b590$909e20b0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpyqu0EaaDKfE9FQtinKTo5GZcqYgAU48BQ Content-Language: zh-cn Subject: Re: [savi] about draft-ietf-savi-fcfs-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 03:48:03 -0000 Hi Robin, This is a situation. If the router knows different users will use = different addresses, surely there is no need to depend on DAD snooping. Actually, = it can perform prefix level filtering instead, with the same performance as address level filtering in this case. But I have some questions, 1. In the position of host, does it knows it has a unique prefix and = there is no need to perform DAD? I mean, will the DAD procedure be left out in reality? 2. I can't imagine how much bandwidth will be consumed by DAD procedure. Isn't only one packet for each address in total? Best Regards, Guang > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf = Of > zhengruobin 35664 > Sent: Wednesday, December 02, 2009 1:23 AM > To: Alberto Garc =A8=AA a > Cc: 'SAVI Mailing List' > Subject: Re: [savi] about draft-ietf-savi-fcfs-02 >=20 >=20 > Hi Alberto, >=20 > As far as a wireless interface between the SAVI device and mobile user = is > concerned, the DAD for all the global addresses seems making no sense. = Can > you imagine how much bandwidth in the wireless interface consumes by = the > DAD procedure for all the global addresses. >=20 > In order to prevent that, usually the router will allocate different prefix to > different mobile user or access loop such that the global address of different > user will not be duplicated. So I don't see the necessarity to do the = DAD for > global addresses in all cases. >=20 > Best regards, >=20 > Robin >=20 > ----- =D4=AD=D3=CA=BC=FE ----- > =B7=A2=BC=FE=C8=CB: Alberto Garc=A8=AAa > =C8=D5=C6=DA: =D0=C7=C6=DA=B6=FE, =CA=AE=B6=FE=D4=C2 1=C8=D5, 2009 = =CF=C2=CE=E710:52 > =D6=F7=CC=E2: RE: [savi] about draft-ietf-savi-fcfs-02 > =CA=D5=BC=FE=C8=CB: 'marcelo bagnulo braun' , = 'zhengruobin 35664' > , 'SAVI Mailing List' >=20 > > Hi > > > > | -----Mensaje original----- > > | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En > > nombre de marcelo > > | bagnulo braun > > | Enviado el: martes, 01 de diciembre de 2009 12:35 > > | Para: zhengruobin 35664; SAVI Mailing List > > | Asunto: Re: [savi] about draft-ietf-savi-fcfs-02 > > | > > | (mm, it seems the savi cc got lost somehwere. i include it back) > > | > > | zhengruobin 35664 escribi=A8=AE: > > | > Hi Marcelo, > > | > > > | > A DAD for a LLA is mandatory. But a DAD for a global address > > is not > > | mandatory. > > | > How about in case of only DAD for a LLA? > > > > Even if hosts don't do DAD for global addresses and SAVI does not > > create a binding for the global address 'resulting' from the LLA > > when the LLA address does DAD, I don't see much problem. > > (fcfs-v02): the reception of a data packet with the global address > > as source address when the SAVI device is in NO_BIND state > > triggers a 2xDAD_NSOL that is sent through the Trusted ports and > > moves to TENTATIVE. Unless there is a binding in other SAVI device > > and a host has the address configured, the timer expires and state > > moves to VALID. > > > > Any problem with this behavior? (apart from loosing - buffering - > > some data packets) > > > > Regards, > > Alberto > > >=20 > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Wed Dec 2 00:37:47 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D7E3A6A66 for ; Wed, 2 Dec 2009 00:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.961 X-Spam-Level: X-Spam-Status: No, score=-4.961 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, 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 oUHtQlo0tV2M for ; Wed, 2 Dec 2009 00:37:46 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 2E32728C15D for ; Wed, 2 Dec 2009 00:37:06 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id BDA24B4C591; Wed, 2 Dec 2009 09:36:57 +0100 (CET) Message-ID: <4B16272B.608@it.uc3m.es> Date: Wed, 02 Dec 2009 09:36:59 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: zhengruobin 35664 References: <000501ca6fd5$9f08ed40$7a28460a@china.huawei.com> <4B10DED3.5070001@it.uc3m.es> <4B14E907.8040009@it.uc3m.es> <4B14F8C4.9080603@it.uc3m.es> <4B14FF4C.4070907@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: 'SAVI Mailing List' , =?GB2312?B?QWxiZXJ0byBHYXJjqKph?= Subject: Re: [savi] about draft-ietf-savi-fcfs-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 08:37:47 -0000 zhengruobin 35664 escribió: > Hi Alberto, > > As far as a wireless interface between the SAVI device and mobile user is concerned, the DAD for all the global addresses seems making no sense. Can you imagine how much bandwidth in the wireless interface consumes by the DAD procedure for all the global addresses. > > In order to prevent that, usually the router will allocate different prefix to different mobile user or access loop such that the global address of different user will not be duplicated. So I don't see the necessarity to do the DAD for global addresses in all cases. > > but the same argument would apply to the link local address, right? Regards, marcelo > Best regards, > > Robin > > ----- 原邮件 ----- > 发件人: Alberto García > 日期: 星期二, 十二月 1日, 2009 下午10:52 > 主题: RE: [savi] about draft-ietf-savi-fcfs-02 > 收件人: 'marcelo bagnulo braun' , 'zhengruobin 35664' , 'SAVI Mailing List' > > >> Hi >> >> | -----Mensaje original----- >> | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En >> nombre de marcelo >> | bagnulo braun >> | Enviado el: martes, 01 de diciembre de 2009 12:35 >> | Para: zhengruobin 35664; SAVI Mailing List >> | Asunto: Re: [savi] about draft-ietf-savi-fcfs-02 >> | >> | (mm, it seems the savi cc got lost somehwere. i include it back) >> | >> | zhengruobin 35664 escribió: >> | > Hi Marcelo, >> | > >> | > A DAD for a LLA is mandatory. But a DAD for a global address >> is not >> | mandatory. >> | > How about in case of only DAD for a LLA? >> >> Even if hosts don't do DAD for global addresses and SAVI does not >> create a binding for the global address 'resulting' from the LLA >> when the LLA address does DAD, I don't see much problem. >> (fcfs-v02): the reception of a data packet with the global address >> as source address when the SAVI device is in NO_BIND state >> triggers a 2xDAD_NSOL that is sent through the Trusted ports and >> moves to TENTATIVE. Unless there is a binding in other SAVI device >> and a host has the address configured, the timer expires and state >> moves to VALID. >> >> Any problem with this behavior? (apart from loosing - buffering - >> some data packets) >> >> Regards, >> Alberto >> >> > > > From robin@huawei.com Wed Dec 2 06:08:45 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 409143A6AC6 for ; Wed, 2 Dec 2009 06:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.993 X-Spam-Level: * X-Spam-Status: No, score=1.993 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] 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 hRQJJSqYzWeC for ; Wed, 2 Dec 2009 06:08:44 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 52B8D3A6A5C for ; Wed, 2 Dec 2009 06:08:44 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU1004GA3A27Q@szxga02-in.huawei.com> for savi@ietf.org; Wed, 02 Dec 2009 22:08:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU10039M3A1A9@szxga02-in.huawei.com> for savi@ietf.org; Wed, 02 Dec 2009 22:08:25 +0800 (CST) Received: from [172.24.1.3] (Forwarded-For: [188.36.252.226]) by szxmc03-in.huawei.com (mshttpd); Wed, 02 Dec 2009 22:08:25 +0800 Date: Wed, 02 Dec 2009 22:08:25 +0800 From: zhengruobin 35664 In-reply-to: <4B16272B.608@it.uc3m.es> To: marcelo bagnulo braun Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: normal References: <000501ca6fd5$9f08ed40$7a28460a@china.huawei.com> <4B10DED3.5070001@it.uc3m.es> <4B14E907.8040009@it.uc3m.es> <4B14F8C4.9080603@it.uc3m.es> <4B14FF4C.4070907@it.uc3m.es> <4B16272B.608@it.uc3m.es> Cc: 'SAVI Mailing List' , Alberto Garc=?gb2312?B?qKo=?=a Subject: Re: [savi] about draft-ietf-savi-fcfs-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 14:08:45 -0000 Yes=2E I think the working group should do something to migrate the side = effect of DAD=2E What do you guys think=3F Best regards=2C Robin ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A marcelo bagnulo braun =3Cmarcelo=40it=2Euc3m=2Ees=3E= =C8=D5=C6=DA=3A =D0=C7=C6=DA=C8=FD=2C =CA=AE=B6=FE=D4=C2 2=C8=D5=2C 2009 = =CF=C2=CE=E74=3A37 =D6=F7=CC=E2=3A Re=3A =5Bsavi=5D about draft-ietf-savi-fcfs-02 =CA=D5=BC=FE=C8=CB=3A zhengruobin 35664 =3Crobin=40huawei=2Ecom=3E =B3=AD=CB=CD=3A Alberto Garc=A8=AAa =3Calberto=40it=2Euc3m=2Ees=3E=2C =27= SAVI Mailing List=27 =3Csavi=40ietf=2Eorg=3E =3E zhengruobin 35664 escribi=A8=AE=3A =3E =3E Hi Alberto=2C =3E =3E =3E =3E As far as a wireless interface between the SAVI device and = =3E mobile user is concerned=2C the DAD for all the global addresses = =3E seems making no sense=2E Can you imagine how much bandwidth in the = =3E wireless interface consumes by the DAD procedure for all the = =3E global addresses=2E =3E =3E =3E =3E In order to prevent that=2C usually the router will allocate = =3E different prefix to different mobile user or access loop such that = =3E the global address of different user will not be duplicated=2E So I = =3E don=27t see the necessarity to do the DAD for global addresses in = =3E all cases=2E =3E =3E =3E =3E = =3E but the same argument would apply to the link local address=2C right=3F= =3E = =3E Regards=2C marcelo =3E = =3E =3E Best regards=2C =3E =3E =3E =3E Robin =3E =3E =3E =3E ----- =D4=AD=D3=CA=BC=FE ----- =3E =3E =B7=A2=BC=FE=C8=CB=3A Alberto Garc=A8=AAa =3Calberto=40it=2Euc3m=2E= es=3E =3E =3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =CA=AE=B6=FE=D4=C2 1=C8=D5=2C= 2009 =CF=C2=CE=E710=3A52 =3E =3E =D6=F7=CC=E2=3A RE=3A =5Bsavi=5D about draft-ietf-savi-fcfs-02 =3E =3E =CA=D5=BC=FE=C8=CB=3A =27marcelo bagnulo braun=27 =3Cmarcelo=40it= =2Euc3m=2Ees=3E=2C =27zhengruobin = =3E 35664=27 =3Crobin=40huawei=2Ecom=3E=2C =27SAVI Mailing List=27 =3Csav= i=40ietf=2Eorg=3E =3E =3E =3E =3E = =3E =3E=3E Hi =3E =3E=3E =3E =3E=3E =7C -----Mensaje original----- =3E =3E=3E =7C De=3A savi-bounces=40ietf=2Eorg =5Bmailto=3Asavi-bounces=40= ietf=2Eorg=5D En = =3E =3E=3E nombre de marcelo =3E =3E=3E =7C bagnulo braun =3E =3E=3E =7C Enviado el=3A martes=2C 01 de diciembre de 2009 12=3A35 =3E =3E=3E =7C Para=3A zhengruobin 35664=3B SAVI Mailing List =3E =3E=3E =7C Asunto=3A Re=3A =5Bsavi=5D about draft-ietf-savi-fcfs-02 =3E =3E=3E =7C = =3E =3E=3E =7C (mm=2C it seems the savi cc got lost somehwere=2E i inclu= de it back) =3E =3E=3E =7C = =3E =3E=3E =7C zhengruobin 35664 escribi=A8=AE=3A =3E =3E=3E =7C =3E Hi Marcelo=2C =3E =3E=3E =7C =3E =3E =3E=3E =7C =3E A DAD for a LLA is mandatory=2E But a DAD for a globa= l = =3E address = =3E =3E=3E is not =3E =3E=3E =7C mandatory=2E =3E =3E=3E =7C =3E How about in case of only DAD for a LLA=3F =3E =3E=3E =3E =3E=3E Even if hosts don=27t do DAD for global addresses and SAVI doe= s = =3E not = =3E =3E=3E create a binding for the global address =27resulting=27 from t= he = =3E LLA = =3E =3E=3E when the LLA address does DAD=2C I don=27t see much problem=2E= =3E =3E=3E (fcfs-v02)=3A the reception of a data packet with the global = =3E address = =3E =3E=3E as source address when the SAVI device is in NO=5FBIND state = =3E =3E=3E triggers a 2xDAD=5FNSOL that is sent through the Trusted ports= = =3E and = =3E =3E=3E moves to TENTATIVE=2E Unless there is a binding in other SAVI = =3E device = =3E =3E=3E and a host has the address configured=2C the timer expires and= = =3E state = =3E =3E=3E moves to VALID=2E = =3E =3E=3E =3E =3E=3E Any problem with this behavior=3F (apart from loosing - buffer= ing = =3E - = =3E =3E=3E some data packets) =3E =3E=3E =3E =3E=3E Regards=2C =3E =3E=3E Alberto =3E =3E=3E =3E =3E=3E = =3E =3E =3E =3E =3E =3E = =3E = =3E From lihy@huawei.com Wed Dec 2 07:21:38 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A5028C208 for ; Wed, 2 Dec 2009 07:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] 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 kY0PdpBLMjln for ; Wed, 2 Dec 2009 07:21:38 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 0757A28C205 for ; Wed, 2 Dec 2009 07:21:38 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU100KOT6N76Z@usaga03-in.huawei.com> for savi@ietf.org; Wed, 02 Dec 2009 09:21:07 -0600 (CST) Received: from [192.168.175.191] ([188.36.252.226]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU1006086N544@usaga03-in.huawei.com> for savi@ietf.org; Wed, 02 Dec 2009 09:21:07 -0600 (CST) Date: Wed, 02 Dec 2009 23:21:05 +0800 From: Hongyu Li In-reply-to: <4B16272B.608@it.uc3m.es> To: marcelo bagnulo braun Message-id: <5B5A891E-B1E5-47C6-8651-7AFCA3F35C4F@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.1076) Content-type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-transfer-encoding: quoted-printable References: <000501ca6fd5$9f08ed40$7a28460a@china.huawei.com> <4B10DED3.5070001@it.uc3m.es> <4B14E907.8040009@it.uc3m.es> <4B14F8C4.9080603@it.uc3m.es> <4B14FF4C.4070907@it.uc3m.es> <4B16272B.608@it.uc3m.es> Cc: 'SAVI Mailing List' , =?GB2312?Q?Alberto_Garc=A8=AAa?= , zhengruobin 35664 Subject: Re: [savi] about draft-ietf-savi-fcfs-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 15:21:39 -0000 DAD for LLA is definitely useful in certain cases. Pls refer to the =20 slides from Dave Allen, the BBF A&T co-chair, which were presented in =20= SAVI in 76th meeting. cheers, Hongyu =D4=DA 2009-12-2=A3=AC=CF=C2=CE=E74:36=A3=AC marcelo bagnulo braun = =D0=B4=B5=C0=A3=BA > zhengruobin 35664 escribi=A8=AE: >> Hi Alberto, >> >> As far as a wireless interface between the SAVI device and mobile =20 >> user is concerned, the DAD for all the global addresses seems =20 >> making no sense. Can you imagine how much bandwidth in the wireless =20= >> interface consumes by the DAD procedure for all the global addresses. >> >> In order to prevent that, usually the router will allocate =20 >> different prefix to different mobile user or access loop such that =20= >> the global address of different user will not be duplicated. So I =20 >> don't see the necessarity to do the DAD for global addresses in all =20= >> cases. >> >> > but the same argument would apply to the link local address, right? > > Regards, marcelo > >> Best regards, >> >> Robin >> >> ----- =D4=AD=D3=CA=BC=FE ----- >> =B7=A2=BC=FE=C8=CB: Alberto Garc=A8=AAa >> =C8=D5=C6=DA: =D0=C7=C6=DA=B6=FE, =CA=AE=B6=FE=D4=C2 1=C8=D5, 2009 = =CF=C2=CE=E710:52 >> =D6=F7=CC=E2: RE: [savi] about draft-ietf-savi-fcfs-02 >> =CA=D5=BC=FE=C8=CB: 'marcelo bagnulo braun' , = 'zhengruobin =20 >> 35664' , 'SAVI Mailing List' >> >> >>> Hi >>> >>> | -----Mensaje original----- >>> | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En >>> nombre de marcelo >>> | bagnulo braun >>> | Enviado el: martes, 01 de diciembre de 2009 12:35 >>> | Para: zhengruobin 35664; SAVI Mailing List >>> | Asunto: Re: [savi] about draft-ietf-savi-fcfs-02 >>> | >>> | (mm, it seems the savi cc got lost somehwere. i include it back) >>> | >>> | zhengruobin 35664 escribi=A8=AE: >>> | > Hi Marcelo, >>> | > >>> | > A DAD for a LLA is mandatory. But a DAD for a global address >>> is not >>> | mandatory. >>> | > How about in case of only DAD for a LLA? >>> >>> Even if hosts don't do DAD for global addresses and SAVI does not >>> create a binding for the global address 'resulting' from the LLA >>> when the LLA address does DAD, I don't see much problem. >>> (fcfs-v02): the reception of a data packet with the global address >>> as source address when the SAVI device is in NO_BIND state >>> triggers a 2xDAD_NSOL that is sent through the Trusted ports and >>> moves to TENTATIVE. Unless there is a binding in other SAVI device >>> and a host has the address configured, the timer expires and state >>> moves to VALID. >>> >>> Any problem with this behavior? (apart from loosing - buffering - >>> some data packets) >>> >>> Regards, >>> Alberto >>> >>> >> >> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Wed Dec 2 08:55:37 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80BCF3A6ADB for ; Wed, 2 Dec 2009 08:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[AWL=-1.576, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_61=0.6, MIME_CHARSET_FARAWAY=2.45, 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 Ovgh71ldG0C6 for ; Wed, 2 Dec 2009 08:55:36 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5156D3A6ADA for ; Wed, 2 Dec 2009 08:55:35 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [95.18.31.197]) by smtp01.uc3m.es (Postfix) with ESMTP id 23DEFBA84EF; Wed, 2 Dec 2009 17:55:26 +0100 (CET) Message-ID: <4B169BF1.3050003@it.uc3m.es> Date: Wed, 02 Dec 2009 17:55:13 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: zhengruobin 35664 References: <000501ca6fd5$9f08ed40$7a28460a@china.huawei.com> <4B10DED3.5070001@it.uc3m.es> <4B14E907.8040009@it.uc3m.es> <4B14F8C4.9080603@it.uc3m.es> <4B14FF4C.4070907@it.uc3m.es> <4B16272B.608@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: 'SAVI Mailing List' , =?GB2312?B?QWxiZXJ0byBHYXJjqKph?= Subject: Re: [savi] about draft-ietf-savi-fcfs-02 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 16:55:37 -0000 zhengruobin 35664 escribió: > Yes. by yes, you mean that the same problem occurs with link locals, right? If so, this is just one more case where the DAD packet is not present for an address. This can be handled by triggering the proxy DAD upon the reception of data apcket,s which is already in the current version of the draft. Regards, marcelo > I think the working group should do something to migrate the side effect of DAD. What do you guys think? > > Best regards, > > Robin > > ----- 原邮件 ----- > 发件人: marcelo bagnulo braun > 日期: 星期三, 十二月 2日, 2009 下午4:37 > 主题: Re: [savi] about draft-ietf-savi-fcfs-02 > 收件人: zhengruobin 35664 > 抄送: Alberto García , 'SAVI Mailing List' > > >> zhengruobin 35664 escribió: >> >>> Hi Alberto, >>> >>> As far as a wireless interface between the SAVI device and >>> >> mobile user is concerned, the DAD for all the global addresses >> seems making no sense. Can you imagine how much bandwidth in the >> wireless interface consumes by the DAD procedure for all the >> global addresses. >> >>> In order to prevent that, usually the router will allocate >>> >> different prefix to different mobile user or access loop such that >> the global address of different user will not be duplicated. So I >> don't see the necessarity to do the DAD for global addresses in >> all cases. >> >>> >>> >> but the same argument would apply to the link local address, right? >> >> Regards, marcelo >> >> >>> Best regards, >>> >>> Robin >>> >>> ----- 原邮件 ----- >>> 发件人: Alberto García >>> 日期: 星期二, 十二月 1日, 2009 下午10:52 >>> 主题: RE: [savi] about draft-ietf-savi-fcfs-02 >>> 收件人: 'marcelo bagnulo braun' , 'zhengruobin >>> >> 35664' , 'SAVI Mailing List' >> >>> >>> >>>> Hi >>>> >>>> | -----Mensaje original----- >>>> | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En >>>> nombre de marcelo >>>> | bagnulo braun >>>> | Enviado el: martes, 01 de diciembre de 2009 12:35 >>>> | Para: zhengruobin 35664; SAVI Mailing List >>>> | Asunto: Re: [savi] about draft-ietf-savi-fcfs-02 >>>> | >>>> | (mm, it seems the savi cc got lost somehwere. i include it back) >>>> | >>>> | zhengruobin 35664 escribió: >>>> | > Hi Marcelo, >>>> | > >>>> | > A DAD for a LLA is mandatory. But a DAD for a global >>>> >> address >> >>>> is not >>>> | mandatory. >>>> | > How about in case of only DAD for a LLA? >>>> >>>> Even if hosts don't do DAD for global addresses and SAVI does >>>> >> not >> >>>> create a binding for the global address 'resulting' from the >>>> >> LLA >> >>>> when the LLA address does DAD, I don't see much problem. >>>> (fcfs-v02): the reception of a data packet with the global >>>> >> address >> >>>> as source address when the SAVI device is in NO_BIND state >>>> triggers a 2xDAD_NSOL that is sent through the Trusted ports >>>> >> and >> >>>> moves to TENTATIVE. Unless there is a binding in other SAVI >>>> >> device >> >>>> and a host has the address configured, the timer expires and >>>> >> state >> >>>> moves to VALID. >>>> >>>> Any problem with this behavior? (apart from loosing - buffering >>>> >> - >> >>>> some data packets) >>>> >>>> Regards, >>>> Alberto >>>> >>>> >>>> >>> >>> >> > > From christian.vogt@ericsson.com Thu Dec 3 11:00:30 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8B43A68E6 for ; Thu, 3 Dec 2009 11:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 ARAbrHup6Vem for ; Thu, 3 Dec 2009 11:00:29 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id D5D213A68E4 for ; Thu, 3 Dec 2009 11:00:26 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nB3J0Q18015801 for ; Thu, 3 Dec 2009 13:00:26 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 3 Dec 2009 14:00:17 -0500 From: Christian Vogt To: SAVI Mailing List Date: Thu, 3 Dec 2009 14:01:20 -0500 Thread-Topic: [savi] Consensus call on adopting draft-bi-savi-dhcp-00 Thread-Index: Acp0StnSOwvJtNL0R2miNRK7A0yFMQ== Message-ID: <5001C0A6-F145-48B3-8001-D84E47B993D5@ericsson.com> References: <44328038-1840-4B14-B616-CF33E023FBC6@ericsson.com> In-Reply-To: <44328038-1840-4B14-B616-CF33E023FBC6@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [savi] Consensus call on adopting draft-bi-savi-dhcp-00 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 19:00:30 -0000 Folks - We recently had a consensus call about adopting Internet draft "draft-bi-savi-dhcp-00" as a working group document. The feedback we received was unanimous: 13 people agreed to adopt the Internet draft, and nobody was against it. This means that we will adopt draft-bi-savi-dhcp-00 as a working group document I will now talk to our area directors about this decision, and afterwards have Jun Bi and his co-authors re-submit draft-bi-savi-dhcp-00 as draft-ietf-savi-dhcp-00. - Christian On Nov 9, 2009, Christian Vogt wrote: > Folks - >=20 > During the SAVI working group meeting today, we made a consensus check > about adopting Internet draft "draft-bi-savi-dhcp-00" as a working group > document, showing a clear majority of attendees in favor. I would now > like to initiate a confirming consensus call here on the mailing list. >=20 > Please answer the following question with either "yes" or "no": >=20 > Should the SAVI working group adopt Internet draft > "draft-bi-savi-dhcp-00" as a starting point for the SAVI protocol > specification for DHCP-assigned IP addresses? >=20 > Please respond before Friday, November 20. I am attaching Internet > draft "draft-bi-savi-dhcp-00" for your convenience. >=20 > - Christian From christian.vogt@ericsson.com Thu Dec 3 11:05:37 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB8B73A6782 for ; Thu, 3 Dec 2009 11:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 8snkdJxHtoAW for ; Thu, 3 Dec 2009 11:05:37 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 110543A62C1 for ; Thu, 3 Dec 2009 11:05:36 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nB3J5a3H028493 for ; Thu, 3 Dec 2009 13:05:36 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.197]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 3 Dec 2009 14:05:27 -0500 From: Christian Vogt To: SAVI Mailing List Date: Thu, 3 Dec 2009 14:06:39 -0500 Thread-Topic: Update of SAVI working group milestones Thread-Index: Acp0S5M7gbsc2jKiRAqG20uNf/cvsw== Message-ID: <5ABE43AE-4943-4326-AA94-44B84B477A4A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [savi] Update of SAVI working group milestones X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 19:05:38 -0000 All - I would like to make updates to the SAVI working group milestones to include the new DHCP solution document and the new, though yet-to-be- selected framework document, as well as to reflect the past delay of=20 the group. Below is a suggestion of how the new milestones should=20 look like. If you see an issue with these, please speak up. - Christian PROPOSED NEW MILESTONES Jul 2008 WG approval Aug 2008 First WG draft on threats Oct 2008 First WG draft on SLAAC solution Dec 2008 First WG draft on SeND solution Dec 2009 First WG draft on DHCP solution Dec 2009 First WG draft on protocol framework Mar 2010 First WG draft on solution for Ethernet-based broadband access ne= tworks Mar 2010 Submit document on threats to IESG for Informational RFC Dec 2010 Submit SLAAC solution to IESG for Proposed Standard Dec 2010 Submit SeND solution to IESG for Proposed Standard Dec 2010 Submit DHCP solution to IESG for Proposed Standard Dec 2010 Submit protocol framework to IESG for Informational RFC Dec 2010 Submit Ethernet-based broadband access network solution to IESG f= or Proposed Standard From junbi@tsinghua.edu.cn Thu Dec 3 17:33:05 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6065E3A6951 for ; Thu, 3 Dec 2009 17:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.103 X-Spam-Level: X-Spam-Status: No, score=-1.103 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, STOX_REPLY_TYPE=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 95EjhbYZiBqf for ; Thu, 3 Dec 2009 17:33:04 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 5DE053A694E for ; Thu, 3 Dec 2009 17:33:04 -0800 (PST) Received: from th053200.ip.tsinghua.edu.cn ([59.66.53.200] helo=junbiVAIO) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NGN2M-0000BX-TD; Fri, 04 Dec 2009 09:32:46 +0800 Message-ID: From: "Jun Bi" To: "Christian Vogt" , "SAVI Mailing List" References: <44328038-1840-4B14-B616-CF33E023FBC6@ericsson.com> <5001C0A6-F145-48B3-8001-D84E47B993D5@ericsson.com> In-Reply-To: <5001C0A6-F145-48B3-8001-D84E47B993D5@ericsson.com> Date: Fri, 4 Dec 2009 09:32:54 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 Subject: Re: [savi] Consensus call on adopting draft-bi-savi-dhcp-00 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 01:33:05 -0000 Thanks, Jun Bi -------------------------------------------------- From: "Christian Vogt" Sent: Friday, December 04, 2009 3:01 AM To: "SAVI Mailing List" Subject: Re: [savi] Consensus call on adopting draft-bi-savi-dhcp-00 > Folks - > > We recently had a consensus call about adopting Internet draft > "draft-bi-savi-dhcp-00" as a working group document. The feedback we > received was unanimous: 13 people agreed to adopt the Internet draft, > and nobody was against it. This means that we will adopt > draft-bi-savi-dhcp-00 as a working group document > > I will now talk to our area directors about this decision, and > afterwards have Jun Bi and his co-authors re-submit > draft-bi-savi-dhcp-00 as draft-ietf-savi-dhcp-00. > > - Christian > > > > On Nov 9, 2009, Christian Vogt wrote: > >> Folks - >> >> During the SAVI working group meeting today, we made a consensus check >> about adopting Internet draft "draft-bi-savi-dhcp-00" as a working group >> document, showing a clear majority of attendees in favor. I would now >> like to initiate a confirming consensus call here on the mailing list. >> >> Please answer the following question with either "yes" or "no": >> >> Should the SAVI working group adopt Internet draft >> "draft-bi-savi-dhcp-00" as a starting point for the SAVI protocol >> specification for DHCP-assigned IP addresses? >> >> Please respond before Friday, November 20. I am attaching Internet >> draft "draft-bi-savi-dhcp-00" for your convenience. >> >> - Christian > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From alberto@it.uc3m.es Thu Dec 10 02:00:38 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A32A3A67AA for ; Thu, 10 Dec 2009 02:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.689 X-Spam-Level: X-Spam-Status: No, score=-4.689 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 CP9P1qd8JyCp for ; Thu, 10 Dec 2009 02:00:32 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 0EEB43A688F for ; Thu, 10 Dec 2009 02:00:31 -0800 (PST) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id A9752BA60FD for ; Thu, 10 Dec 2009 11:00:18 +0100 (CET) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: "'SAVI Mailing List'" Date: Thu, 10 Dec 2009 11:00:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0144_01CA7987.F656A5E0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acp5ft3DrqEqo/NRRA29cOC6TZIMqA== X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Subject: [savi] SLAAC-SAVI and host address configuration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 10:00:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0144_01CA7987.F656A5E0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Hi, Regarding to the SLAAC-SAVI mechanism proposed so far (draft-ietf-savi-fcfs-02), I think that there are some caveats in the behavior of SLAAC hosts when they are in the process of configuring their own addresses (i.e. when the address of the host is still tentative). Suppose that a host has configured an address, has a valid binding in a SAVI device, and then it restarts the network configuration so the address is configured again, DAD is executed by sending a DAD NSOL message, etc. (for example, the user powers down and up the host - it happens all the time :-)). Suppose that while the host is performing DAD and the SAVI device was in VALID state for this address, the lifetime timer expires in the SAVI device. Current specification says that the SAVI device sends a DAD_NSOL message to the host, and changes the state to TESTING_LIFETIME. But in this particular case (the host is still configuring its address) the DAD_NSOL message stops address configuration in the host (instead of generating a DAD_NADV). Current SAVI design assumes that sending DAD_NSOL is in general side-effect free for hosts, while this is not the case when the hosts are in the process of configuring its own address. Note that the same problem occurs when a host is configuring its address and another host tries to use the same address either in a validating port of the same SAVI device, or in another SAVI device: current specification assumes that the first host can answer to DAD_NSOL messages, while this is not the case if it is configuring its address. I think the solution for this is to create a WAIT_FOR_CONFIG state. If a host is in VALID, TESTING_TP, or TESTING_VP state, and a DAD_NSOL is received from the port currently associated to the binding, the SAVI device moves to this state and lifetime is set to LIFETIME. While the SAVI device is in this state, messages from other hosts are not considered (in particular, DAD_NSOL messages are not forwarded to the host configuring its address). The state moves to VALID when the lifetime expires, or when data packets are received from the current validating port (because in this case we know the address configuration process has finished). The underlying supposition for this behavior is that if a host sends a DAD_NSOL message from the port from which a binding exists, (a) the host is proving that it is alive and (b) this host in this port is supposed to be more legitimate than other hosts trying to use the address in other ports at the same time. Therefore, the address configuration procedure for this host should be protected, as well as the binding for it. Do you think this makes sense? Regards, Alberto ------=_NextPart_000_0144_01CA7987.F656A5E0 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable

Hi,

Regarding to the SLAAC-SAVI mechanism proposed = so far (draft-ietf-savi-fcfs-02), I think that there are some caveats in the = behavior of SLAAC hosts when they are in the process of configuring their own = addresses (i.e. when the address of the host is still tentative). =

Suppose that a host has configured an address, = has a valid binding in a SAVI device, and then it restarts the network = configuration so the address is configured again, DAD is executed by sending a DAD NSOL = message, etc. (for example, the user powers down and up the host – it = happens all the time J). Suppose that while the host is performing DAD and the SAVI device was in VALID = state for this address, the lifetime timer expires in the SAVI device. Current specification says that the SAVI device sends a DAD_NSOL message to the = host, and changes the state to TESTING_LIFETIME. But in this particular case = (the host is still configuring its address) the DAD_NSOL message stops = address configuration in the host (instead of generating a DAD_NADV). Current = SAVI design assumes that sending DAD_NSOL is in general side-effect free for = hosts, while this is not the case when the hosts are in the process of = configuring its own address.

Note that the same problem occurs when a host = is configuring its address and another host tries to use the same address either in a validating port of the same SAVI device, or in another SAVI device: = current specification assumes that the first host can answer to DAD_NSOL = messages, while this is not the case if it is configuring its = address.

I think the solution for this is to create a = WAIT_FOR_CONFIG state. If a host is in VALID, TESTING_TP, or TESTING_VP state, and a = DAD_NSOL is received from the port currently associated to the binding, the SAVI = device moves to this state and lifetime is set to LIFETIME. While the SAVI = device is in this state, messages from other hosts are not considered (in = particular, DAD_NSOL messages are not forwarded to the host configuring its = address). The state moves to VALID when the lifetime expires, or when data packets are received from the current validating port (because in this case we know = the address configuration process has finished). The underlying supposition = for this behavior is that if a host sends a DAD_NSOL message from the port = from which a binding exists, (a) the host is proving that it is alive and (b) = this host in this port is supposed to be more legitimate than other hosts = trying to use the address in other ports at the same time. Therefore, the address configuration procedure for this host should be protected, as well as = the binding for it.

 

Do you think this makes = sense?

Regards,

Alberto

=A0=

------=_NextPart_000_0144_01CA7987.F656A5E0-- From yaoa02@mails.tsinghua.edu.cn Thu Dec 10 02:23:26 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5AD3A6AC7 for ; Thu, 10 Dec 2009 02:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 xEzu30T8phYg for ; Thu, 10 Dec 2009 02:23:20 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 275D73A67DB for ; Thu, 10 Dec 2009 02:23:18 -0800 (PST) Received: from th024119.ip.tsinghua.edu.cn ([59.66.24.119] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NIgAn-00013O-Br; Thu, 10 Dec 2009 18:23:01 +0800 From: "Guang Yao" To: =?ISO-8859-1?Q?'Alberto_Garc=EDa'?= References: In-Reply-To: Date: Thu, 10 Dec 2009 18:22:50 +0800 Message-ID: <002d01ca7982$b9f6f780$2de4e680$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CA79C5.C81A3780" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp5ft3DrqEqo/NRRA29cOC6TZIMqAAAW7xw Content-Language: zh-cn Cc: 'SAVI Mailing List' Subject: Re: [savi] SLAAC-SAVI and host address configuration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 10:23:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002E_01CA79C5.C81A3780 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Alberto =20 DAD_NSOL should never be sent to the host who is supposed to use the = target address. And it is not necessary. Actually this case is mention in DHCP solution draft and the corresponding slides of IETF76. =20 If a probe should be sent to host to detect alive, use NSOL but not DAD NSOL. =20 BR, Guang =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa Sent: Thursday, December 10, 2009 6:00 PM To: 'SAVI Mailing List' Subject: [savi] SLAAC-SAVI and host address configuration =20 Hi, Regarding to the SLAAC-SAVI mechanism proposed so far (draft-ietf-savi-fcfs-02), I think that there are some caveats in the behavior of SLAAC hosts when they are in the process of configuring = their own addresses (i.e. when the address of the host is still tentative).=20 Suppose that a host has configured an address, has a valid binding in a = SAVI device, and then it restarts the network configuration so the address is configured again, DAD is executed by sending a DAD NSOL message, etc. = (for example, the user powers down and up the host =96 it happens all the = time J). Suppose that while the host is performing DAD and the SAVI device was in VALID state for this address, the lifetime timer expires in the SAVI = device. Current specification says that the SAVI device sends a DAD_NSOL message = to the host, and changes the state to TESTING_LIFETIME. But in this = particular case (the host is still configuring its address) the DAD_NSOL message = stops address configuration in the host (instead of generating a DAD_NADV). Current SAVI design assumes that sending DAD_NSOL is in general = side-effect free for hosts, while this is not the case when the hosts are in the = process of configuring its own address.=20 Note that the same problem occurs when a host is configuring its address = and another host tries to use the same address either in a validating port = of the same SAVI device, or in another SAVI device: current specification assumes that the first host can answer to DAD_NSOL messages, while this = is not the case if it is configuring its address. I think the solution for this is to create a WAIT_FOR_CONFIG state. If a host is in VALID, TESTING_TP, or TESTING_VP state, and a DAD_NSOL is received from the port currently associated to the binding, the SAVI = device moves to this state and lifetime is set to LIFETIME. While the SAVI = device is in this state, messages from other hosts are not considered (in particular, DAD_NSOL messages are not forwarded to the host configuring = its address). The state moves to VALID when the lifetime expires, or when = data packets are received from the current validating port (because in this = case we know the address configuration process has finished). The underlying supposition for this behavior is that if a host sends a DAD_NSOL message from the port from which a binding exists, (a) the host is proving that = it is alive and (b) this host in this port is supposed to be more = legitimate than other hosts trying to use the address in other ports at the same = time. Therefore, the address configuration procedure for this host should be protected, as well as the binding for it. =20 Do you think this makes sense? Regards, Alberto =20 ------=_NextPart_000_002E_01CA79C5.C81A3780 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, Alberto

 

DAD_NSOL should never be sent to the host who is supposed = to use the target address. And it is not necessary. Actually this case is = mention in DHCP solution draft and the corresponding slides of = IETF76.

 

If a probe should be sent to host to detect alive, use = NSOL but not DAD NSOL.

 

BR,

Guang

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa
Sent: Thursday, December 10, 2009 6:00 PM
To: 'SAVI Mailing List'
Subject: [savi] SLAAC-SAVI and host address = configuration

 

Hi,

Regarding to the SLAAC-SAVI mechanism proposed so far (draft-ietf-savi-fcfs-02), I = think that there are some caveats in the behavior of SLAAC hosts when they are = in the process of configuring their own addresses (i.e. when the address of the = host is still tentative).

Suppose that a host has configured an address, has a valid binding in a SAVI = device, and then it restarts the network configuration so the address is = configured again, DAD is executed by sending a DAD NSOL message, etc. (for example, = the user powers down and up the host – it happens all the time = J). Suppose that while the host is performing DAD and the SAVI device was in VALID = state for this address, the lifetime timer expires in the SAVI device. Current specification says that the SAVI device sends a DAD_NSOL message to the = host, and changes the state to TESTING_LIFETIME. But in this particular case = (the host is still configuring its address) the DAD_NSOL message stops = address configuration in the host (instead of generating a DAD_NADV). Current = SAVI design assumes that sending DAD_NSOL is in general side-effect free for = hosts, while this is not the case when the hosts are in the process of = configuring its own address.

Note that the same problem occurs when a host is configuring its address and = another host tries to use the same address either in a validating port of the = same SAVI device, or in another SAVI device: current specification assumes that = the first host can answer to DAD_NSOL messages, while this is not the case if it = is configuring its address.

I think the solution for this is to create a WAIT_FOR_CONFIG state. If a = host is in VALID, TESTING_TP, or TESTING_VP state, and a DAD_NSOL is received = from the port currently associated to the binding, the SAVI device moves to this = state and lifetime is set to LIFETIME. While the SAVI device is in this state, messages from other hosts are not considered (in particular, DAD_NSOL = messages are not forwarded to the host configuring its address). The state moves = to VALID when the lifetime expires, or when data packets are received from = the current validating port (because in this case we know the address = configuration process has finished). The underlying supposition for this behavior is = that if a host sends a DAD_NSOL message from the port from which a binding = exists, (a) the host is proving that it is alive and (b) this host in this port is = supposed to be more legitimate than other hosts trying to use the address in = other ports at the same time. Therefore, the address configuration procedure for = this host should be protected, as well as the binding for = it.

 

Do you think this makes sense?

Regards,=

Alberto<= /o:p>

 

------=_NextPart_000_002E_01CA79C5.C81A3780-- From alberto@it.uc3m.es Thu Dec 10 04:29:28 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D3B3A6B34 for ; Thu, 10 Dec 2009 04:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.695 X-Spam-Level: X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 dQ28mBxZM7GC for ; Thu, 10 Dec 2009 04:29:18 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id D33193A6B27 for ; Thu, 10 Dec 2009 04:29:17 -0800 (PST) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id B8D7E72DB2D; Thu, 10 Dec 2009 13:29:02 +0100 (CET) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: "'Guang Yao'" References: <002d01ca7982$b9f6f780$2de4e680$@tsinghua.edu.cn> Date: Thu, 10 Dec 2009 13:29:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_016C_01CA799C.BE231630" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acp5ft3DrqEqo/NRRA29cOC6TZIMqAAAW7xwAARmmmA= In-Reply-To: <002d01ca7982$b9f6f780$2de4e680$@tsinghua.edu.cn> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: 'SAVI Mailing List' Subject: Re: [savi] SLAAC-SAVI and host address configuration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 12:29:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_016C_01CA799C.BE231630 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Hi Guang, I agree that it is a good idea to use (unicast address sourced) NSOL = instead of DAD_NSOL for the messages that the SAVI device synthesize to check if = a host is still in the port or not (when it is in VALID state and the = lifetime timer expires, or when a data packet is received from a Validating port different to the current binding).=20 But my question goes further: if the SAVI host receives a DAD_NSOL from = the port through which a binding exists, do we want to protect the binding = from other hosts sending DAD_NSOL messages? (in this period, the host at the = port with the binding is not defending its address) We could, if we wanted (by means of something like the WAIT_FOR_CONFIG = state I commented), by making the SAVI device defending the address by sending DAD_NADV. I think the point to discuss is if it is reasonable to prefer = a host that is configuring an address in the port for which we have a = binding, over hosts doing the same in other locations.=20 As it is currently defined, there are many situations in which a host in other ports would configure the address even if a host is trying so in = the port for which a binding exists. Has this being discussed in IETF76? =20 Regards, Alberto =20 _____ =20 De: Guang Yao [mailto:yaoa02@mails.tsinghua.edu.cn]=20 Enviado el: jueves, 10 de diciembre de 2009 11:23 Para: 'Alberto Garc=EDa' CC: 'SAVI Mailing List' Asunto: RE: [savi] SLAAC-SAVI and host address configuration =20 Hi, Alberto =20 DAD_NSOL should never be sent to the host who is supposed to use the = target address. And it is not necessary. Actually this case is mention in DHCP solution draft and the corresponding slides of IETF76. =20 If a probe should be sent to host to detect alive, use NSOL but not DAD NSOL. =20 BR, Guang =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa Sent: Thursday, December 10, 2009 6:00 PM To: 'SAVI Mailing List' Subject: [savi] SLAAC-SAVI and host address configuration =20 Hi, Regarding to the SLAAC-SAVI mechanism proposed so far (draft-ietf-savi-fcfs-02), I think that there are some caveats in the behavior of SLAAC hosts when they are in the process of configuring = their own addresses (i.e. when the address of the host is still tentative).=20 Suppose that a host has configured an address, has a valid binding in a = SAVI device, and then it restarts the network configuration so the address is configured again, DAD is executed by sending a DAD NSOL message, etc. = (for example, the user powers down and up the host - it happens all the time :-)). Suppose that while the host is performing DAD and the SAVI device = was in VALID state for this address, the lifetime timer expires in the SAVI device. Current specification says that the SAVI device sends a DAD_NSOL message to the host, and changes the state to TESTING_LIFETIME. But in = this particular case (the host is still configuring its address) the DAD_NSOL message stops address configuration in the host (instead of generating a DAD_NADV). Current SAVI design assumes that sending DAD_NSOL is in = general side-effect free for hosts, while this is not the case when the hosts = are in the process of configuring its own address.=20 Note that the same problem occurs when a host is configuring its address = and another host tries to use the same address either in a validating port = of the same SAVI device, or in another SAVI device: current specification assumes that the first host can answer to DAD_NSOL messages, while this = is not the case if it is configuring its address. I think the solution for this is to create a WAIT_FOR_CONFIG state. If a host is in VALID, TESTING_TP, or TESTING_VP state, and a DAD_NSOL is received from the port currently associated to the binding, the SAVI = device moves to this state and lifetime is set to LIFETIME. While the SAVI = device is in this state, messages from other hosts are not considered (in particular, DAD_NSOL messages are not forwarded to the host configuring = its address). The state moves to VALID when the lifetime expires, or when = data packets are received from the current validating port (because in this = case we know the address configuration process has finished). The underlying supposition for this behavior is that if a host sends a DAD_NSOL message from the port from which a binding exists, (a) the host is proving that = it is alive and (b) this host in this port is supposed to be more = legitimate than other hosts trying to use the address in other ports at the same = time. Therefore, the address configuration procedure for this host should be protected, as well as the binding for it. =20 Do you think this makes sense? Regards, Alberto =20 ------=_NextPart_000_016C_01CA799C.BE231630 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable

Hi = Guang,

I agree that it = is a good idea to use (unicast address sourced) NSOL instead of DAD_NSOL for the = messages that the SAVI device synthesize to check if a host is still in the port = or not (when it is in VALID state and the lifetime timer expires, or when a = data packet is received from a Validating port different to the current = binding).

But my question = goes further: if the SAVI host receives a DAD_NSOL from the port through = which a binding exists, do we want to protect the binding from other hosts = sending DAD_NSOL messages? (in this period, the host at the port with the binding is not = defending its address)

We could, if we = wanted (by means of something like the WAIT_FOR_CONFIG state I commented), by = making the SAVI device defending the address by sending DAD_NADV. I think the = point to discuss is if it is reasonable to prefer a host that is configuring an = address in the port for which we have a binding, over hosts doing the same in = other locations.

As it is = currently defined, there are many situations in which a host in other ports would configure the address even if a host is trying so in the port for which = a binding exists.

Has this being = discussed in IETF76?

 =

Regards,

Alberto

 =

De: Guang = Yao [mailto:yaoa02@mails.tsinghua.edu.cn]
Enviado el: jueves, 10 de diciembre de 2009 11:23
Para: 'Alberto = Garc=EDa'
CC: 'SAVI Mailing = List'
Asunto: RE: [savi] = SLAAC-SAVI and host address configuration

 

Hi, = Alberto

 <= /o:p>

DAD_NSOL = should never be sent to the host who is supposed to use the target address. And = it is not necessary. Actually this case is mention in DHCP solution draft and = the corresponding slides of IETF76.

 <= /o:p>

If a probe = should be sent to host to detect alive, use NSOL but not DAD = NSOL.

 <= /o:p>

BR,

Guang

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa
Sent: Thursday, December = 10, 2009 6:00 PM
To: 'SAVI Mailing = List'
Subject: [savi] = SLAAC-SAVI and host address configuration

 

Hi,

Regarding to the SLAAC-SAVI mechanism proposed = so far (draft-ietf-savi-fcfs-02), I think that there are some caveats in the = behavior of SLAAC hosts when they are in the process of configuring their own = addresses (i.e. when the address of the host is still tentative). =

Suppose that a host has configured an address, = has a valid binding in a SAVI device, and then it restarts the network = configuration so the address is configured again, DAD is executed by sending a DAD = NSOL message, etc. (for example, the user powers down and up the host – = it happens all the time J). Suppose that while the host is performing DAD and the SAVI device was in = VALID state for this address, the lifetime timer expires in the SAVI device. = Current specification says that the SAVI device sends a DAD_NSOL message to the = host, and changes the state to TESTING_LIFETIME. But in this particular case = (the host is still configuring its address) the DAD_NSOL message stops = address configuration in the host (instead of generating a DAD_NADV). Current = SAVI design assumes that sending DAD_NSOL is in general side-effect free for hosts, = while this is not the case when the hosts are in the process of configuring = its own address.

Note that the same problem occurs when a host = is configuring its address and another host tries to use the same address = either in a validating port of the same SAVI device, or in another SAVI device: current specification assumes that the first host can answer to DAD_NSOL messages, while this is not the case if it is configuring its = address.

I think the solution for this is to create a WAIT_FOR_CONFIG state. If a host is in VALID, TESTING_TP, or TESTING_VP = state, and a DAD_NSOL is received from the port currently associated to the = binding, the SAVI device moves to this state and lifetime is set to LIFETIME. = While the SAVI device is in this state, messages from other hosts are not = considered (in particular, DAD_NSOL messages are not forwarded to the host configuring = its address). The state moves to VALID when the lifetime expires, or when = data packets are received from the current validating port (because in this = case we know the address configuration process has finished). The underlying supposition for this behavior is that if a host sends a DAD_NSOL message = from the port from which a binding exists, (a) the host is proving that it is = alive and (b) this host in this port is supposed to be more legitimate than = other hosts trying to use the address in other ports at the same time. = Therefore, the address configuration procedure for this host should be protected, as = well as the binding for it.

 

Do you think this makes = sense?

Regards,

Alberto

 

------=_NextPart_000_016C_01CA799C.BE231630-- From yaoa02@mails.tsinghua.edu.cn Tue Dec 15 01:28:57 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088543A68A4 for ; Tue, 15 Dec 2009 01:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.294 X-Spam-Level: * X-Spam-Status: No, score=1.294 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292] 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 cbW67TGWmqbQ for ; Tue, 15 Dec 2009 01:28:48 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 106AA3A6834 for ; Tue, 15 Dec 2009 01:28:44 -0800 (PST) Received: from th211043.ip.tsinghua.edu.cn ([59.66.211.43] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NKThh-0006BT-MK for savi@ietf.org; Tue, 15 Dec 2009 17:28:25 +0800 From: "Guang Yao" Sender: "Guang Yao" Cc: "'SAVI Mailing List'" References: <002d01ca7982$b9f6f780$2de4e680$@tsinghua.edu.cn> In-Reply-To: Date: Tue, 15 Dec 2009 17:28:20 +0800 Message-ID: <006c01ca7d68$f0d2fb70$d278f250$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01CA7DAB.FEF63B70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp5ft3DrqEqo/NRRA29cOC6TZIMqAAAW7xwAARmmmAA8zy0AA== Content-Language: zh-cn Subject: Re: [savi] SLAAC-SAVI and host address configuration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 09:28:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006D_01CA7DAB.FEF63B70 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Alberto =20 Maybe we must protect the binding. Or else there may some kind of = attacking. For example, a host may send a DAD_NSOL for the same address immediately after it receives the first one. So, protecting the first one will do no evil, although it is always hard to know who is the real first one. =20 However, this protection is aggressive and violates DAD. RFC4862 = implies if there are simultaneous DAD NSOLs, none can use the tentative address. = Maybe no perfect solution here for the tradeoff of security and fairness. =20 A very rare situation: two SAVI devices may protect the same address = from each other by sending DAD_NADV. Thus binding should not be protected = from DAD_NADV. =20 I think you have made a good point. =20 BR, Guang =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa Sent: Thursday, December 10, 2009 8:29 PM To: 'Guang Yao' Cc: 'SAVI Mailing List' Subject: Re: [savi] SLAAC-SAVI and host address configuration =20 Hi Guang, I agree that it is a good idea to use (unicast address sourced) NSOL = instead of DAD_NSOL for the messages that the SAVI device synthesize to check if = a host is still in the port or not (when it is in VALID state and the = lifetime timer expires, or when a data packet is received from a Validating port different to the current binding).=20 But my question goes further: if the SAVI host receives a DAD_NSOL from = the port through which a binding exists, do we want to protect the binding = from other hosts sending DAD_NSOL messages? (in this period, the host at the = port with the binding is not defending its address) We could, if we wanted (by means of something like the WAIT_FOR_CONFIG = state I commented), by making the SAVI device defending the address by sending DAD_NADV. I think the point to discuss is if it is reasonable to prefer = a host that is configuring an address in the port for which we have a = binding, over hosts doing the same in other locations.=20 As it is currently defined, there are many situations in which a host in other ports would configure the address even if a host is trying so in = the port for which a binding exists. Has this being discussed in IETF76? =20 Regards, Alberto =20 _____ =20 De: Guang Yao [mailto:yaoa02@mails.tsinghua.edu.cn]=20 Enviado el: jueves, 10 de diciembre de 2009 11:23 Para: 'Alberto Garc=EDa' CC: 'SAVI Mailing List' Asunto: RE: [savi] SLAAC-SAVI and host address configuration =20 Hi, Alberto =20 DAD_NSOL should never be sent to the host who is supposed to use the = target address. And it is not necessary. Actually this case is mention in DHCP solution draft and the corresponding slides of IETF76. =20 If a probe should be sent to host to detect alive, use NSOL but not DAD NSOL. =20 BR, Guang =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa Sent: Thursday, December 10, 2009 6:00 PM To: 'SAVI Mailing List' Subject: [savi] SLAAC-SAVI and host address configuration =20 Hi, Regarding to the SLAAC-SAVI mechanism proposed so far (draft-ietf-savi-fcfs-02), I think that there are some caveats in the behavior of SLAAC hosts when they are in the process of configuring = their own addresses (i.e. when the address of the host is still tentative).=20 Suppose that a host has configured an address, has a valid binding in a = SAVI device, and then it restarts the network configuration so the address is configured again, DAD is executed by sending a DAD NSOL message, etc. = (for example, the user powers down and up the host =96 it happens all the = time J). Suppose that while the host is performing DAD and the SAVI device was in VALID state for this address, the lifetime timer expires in the SAVI = device. Current specification says that the SAVI device sends a DAD_NSOL message = to the host, and changes the state to TESTING_LIFETIME. But in this = particular case (the host is still configuring its address) the DAD_NSOL message = stops address configuration in the host (instead of generating a DAD_NADV). Current SAVI design assumes that sending DAD_NSOL is in general = side-effect free for hosts, while this is not the case when the hosts are in the = process of configuring its own address.=20 Note that the same problem occurs when a host is configuring its address = and another host tries to use the same address either in a validating port = of the same SAVI device, or in another SAVI device: current specification assumes that the first host can answer to DAD_NSOL messages, while this = is not the case if it is configuring its address. I think the solution for this is to create a WAIT_FOR_CONFIG state. If a host is in VALID, TESTING_TP, or TESTING_VP state, and a DAD_NSOL is received from the port currently associated to the binding, the SAVI = device moves to this state and lifetime is set to LIFETIME. While the SAVI = device is in this state, messages from other hosts are not considered (in particular, DAD_NSOL messages are not forwarded to the host configuring = its address). The state moves to VALID when the lifetime expires, or when = data packets are received from the current validating port (because in this = case we know the address configuration process has finished). The underlying supposition for this behavior is that if a host sends a DAD_NSOL message from the port from which a binding exists, (a) the host is proving that = it is alive and (b) this host in this port is supposed to be more = legitimate than other hosts trying to use the address in other ports at the same = time. Therefore, the address configuration procedure for this host should be protected, as well as the binding for it. =20 Do you think this makes sense? Regards, Alberto =20 ------=_NextPart_000_006D_01CA7DAB.FEF63B70 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, Alberto

 

Maybe we must protect the binding. Or else there may some = kind of attacking. For example, a host may send a DAD_NSOL for the same = address immediately after it receives the first one. So, protecting the first = one will do no evil, although it is always hard to know who is the real first = one.

 

However, this protection is aggressive and  violates = DAD. RFC4862 implies if there are simultaneous DAD NSOLs, none can use the tentative address. Maybe no perfect solution here for the tradeoff of security and fairness.

 

A very rare situation: two SAVI devices may protect the = same address from each other by sending DAD_NADV. Thus binding should not be protected from DAD_NADV.

 

I think you have made a good point.

 

BR,

Guang

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa
Sent: Thursday, December 10, 2009 8:29 PM
To: 'Guang Yao'
Cc: 'SAVI Mailing List'
Subject: Re: [savi] SLAAC-SAVI and host address = configuration

 

Hi Guang,

I agree that it is a good idea to use (unicast address = sourced) NSOL instead of DAD_NSOL for the messages that the SAVI device = synthesize to check if a host is still in the port or not (when it is in VALID state = and the lifetime timer expires, or when a data packet is received from a = Validating port different to the current binding).

But my question goes further: if the SAVI host receives a = DAD_NSOL from the port through which a binding exists, do we want to protect the = binding from other hosts sending DAD_NSOL messages? (in this period, the host at = the port with the binding is not defending its = address)

We could, if we wanted (by means of something like the WAIT_FOR_CONFIG state I commented), by making the SAVI device defending = the address by sending DAD_NADV. I think the point to discuss is if it is reasonable to prefer a host that is configuring an address in the port = for which we have a binding, over hosts doing the same in other locations. =

As it is currently defined, there are many situations in = which a host in other ports would configure the address even if a host is trying = so in the port for which a binding exists.

Has this being discussed in IETF76?

 

Regards,

Alberto

 

De: = Guang Yao [mailto:yaoa02@mails.tsinghua.edu.cn]
Enviado el: jueves, 10 de diciembre de 2009 11:23
Para: 'Alberto Garc=EDa'
CC: 'SAVI Mailing List'
Asunto: RE: [savi] SLAAC-SAVI and host address = configuration

 

Hi, Alberto

 

DAD_NSOL should never be sent to the host who is supposed = to use the target address. And it is not necessary. Actually this case is = mention in DHCP solution draft and the corresponding slides of = IETF76.

 

If a probe should be sent to host to detect alive, use = NSOL but not DAD NSOL.

 

BR,

Guang

 

From: savi-bounces@ietf.org = [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa
Sent: Thursday, December 10, 2009 6:00 PM
To: 'SAVI Mailing List'
Subject: [savi] SLAAC-SAVI and host address = configuration

 

Hi,

Regarding to the SLAAC-SAVI mechanism proposed so far (draft-ietf-savi-fcfs-02), I = think that there are some caveats in the behavior of SLAAC hosts when they are = in the process of configuring their own addresses (i.e. when the address of the = host is still tentative).

Suppose that a host has configured an address, has a valid binding in a SAVI = device, and then it restarts the network configuration so the address is = configured again, DAD is executed by sending a DAD NSOL message, etc. (for example, = the user powers down and up the host – it happens all the time = J). Suppose that while the host is performing DAD and the SAVI device was in VALID = state for this address, the lifetime timer expires in the SAVI device. Current specification says that the SAVI device sends a DAD_NSOL message to the = host, and changes the state to TESTING_LIFETIME. But in this particular case = (the host is still configuring its address) the DAD_NSOL message stops = address configuration in the host (instead of generating a DAD_NADV). Current = SAVI design assumes that sending DAD_NSOL is in general side-effect free for = hosts, while this is not the case when the hosts are in the process of = configuring its own address.

Note that the same problem occurs when a host is configuring its address and = another host tries to use the same address either in a validating port of the = same SAVI device, or in another SAVI device: current specification assumes that = the first host can answer to DAD_NSOL messages, while this is not the case if it = is configuring its address.

I think the solution for this is to create a WAIT_FOR_CONFIG state. If a = host is in VALID, TESTING_TP, or TESTING_VP state, and a DAD_NSOL is received = from the port currently associated to the binding, the SAVI device moves to this = state and lifetime is set to LIFETIME. While the SAVI device is in this state, = messages from other hosts are not considered (in particular, DAD_NSOL messages = are not forwarded to the host configuring its address). The state moves to VALID = when the lifetime expires, or when data packets are received from the current validating port (because in this case we know the address configuration = process has finished). The underlying supposition for this behavior is that if a = host sends a DAD_NSOL message from the port from which a binding exists, (a) = the host is proving that it is alive and (b) this host in this port is = supposed to be more legitimate than other hosts trying to use the address in other = ports at the same time. Therefore, the address configuration procedure for this = host should be protected, as well as the binding for = it.

 

Do you think this makes sense?

Regards,=

Alberto<= /o:p>

 

------=_NextPart_000_006D_01CA7DAB.FEF63B70-- From alberto@it.uc3m.es Tue Dec 15 02:58:35 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14883A69C2 for ; Tue, 15 Dec 2009 02:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.515 X-Spam-Level: X-Spam-Status: No, score=-4.515 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 AIZrJKxyEmFw for ; Tue, 15 Dec 2009 02:58:21 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id F39313A672E for ; Tue, 15 Dec 2009 02:58:20 -0800 (PST) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id F0C26D1D; Tue, 15 Dec 2009 11:58:05 +0100 (CET) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: "'Guang Yao'" References: <002d01ca7982$b9f6f780$2de4e680$@tsinghua.edu.cn> <006401ca7d66$4d6a2aa0$e83e7fe0$@tsinghua.edu.cn> Date: Tue, 15 Dec 2009 11:58:06 +0100 Message-ID: <9CFAED83D3B54E998DA902BD3A46A54D@bombo> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01CA7D7D.DD3DCF80" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <006401ca7d66$4d6a2aa0$e83e7fe0$@tsinghua.edu.cn> Thread-Index: Acp5ft3DrqEqo/NRRA29cOC6TZIMqAAAW7xwAARmmmAA8zy0AAADnebQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: 'SAVI Mailing List' Subject: Re: [savi] SLAAC-SAVI and host address configuration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 10:58:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A7_01CA7D7D.DD3DCF80 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Hi, Thanks for your comments. I think there are two different issues: =20 1- When a binding exists for an address in a SAVI device. A host = connected to the port associated to the binding can turn down and then up, and = send a DAD_NSOL. In this case, I think it should be fair to preserve the = existing binding and defend the address, based on the past events (there was a = host that successfully obtained a binding, and the time since the host = defended its right to have the binding is very short). If we want to protect = this, no DAD_NSOL should be forwarded to the host, and the SAVI device should = defend the address for other ports (sending DAD_NADV) while the host cannot do that.=20 I think it is nice to allow hosts to keep their addresses if address reconfiguration occurs in a short period of time >From DAD perspective, although it is not the behavior specified in = RFC4862, I think it is not opposed to its spirit, in the sense that here we have = a criteria to decide which node "deserves most" the address, the one that = had the binding first. For the hosts it is not an operational problem (only changes which host wins in a collision)=20 What do you think about this case? =20 2- When there is no binding for the address in a SAVI device, and two = hosts try to use the same address. In this case, I agree we do not have any SAVI-specific clue to decide which should succeed. In RFC4862 two things = may occur: either none of them configure the address (because both hosts = start address configuration, send DAD_NSOL, and both receive the DAD_NSOL of = the other when they are in tentative state), or the last one configures its address (one starts address configuration well before the other, sends DAD_NSOL but the other host is not configuring the address yet so it is = not considered; some time later the other starts address configuration, = sends its DAD_NSOL and stops address configuration for the first host).=20 The current SAVI specification does not address this collision in the address configuration (says nothing about DAD_NSOL received in TENTATIVE state). To address this case,=20 - in TENTATIVE state if a DAD_NSOL is received for the same = address from a validating port P', it should be forwarded to the Validating port = P (this will stop address configuration in the host at P), and the state should remain in TENTATIVE, but now testing port P' (the last one, and = the port that may succeed). Note that the SAVI devices cannot know if the = second host will succeed in its address configuration or not (this depends on = the time at which the DAD_NSOL message of the first host arrived), but we = know that the host at P will not succeed, so moving the binding to tentative = the binding for P' (which can configure its address or not) seems = appropriate. - In TENTATIVE state if a DAD_NSOL is received from a trusted = port, the state is changed to NO_BIND. The host in the local port will not succeed.=20 An additional thing should be discussed: currently, there is equal = treatment when either a DAD_NSOL or a data packet arrives when SAVI is in NO_BIND state (send DAD_NSOL and move to TENTATIVE). However, the host sending = data (this means it has its address configured) should not be treated equally = if a DAD_NSOL is received: in this case I think we should protect the = binding for this host since it will not unconfigure the address when receiving a DAD_NSOL. DAD_NADV from other SAVI device should move the state to = NO_BIND, but DAD_NSOL messages should be just forwarded to the host to let it = defend the address. To implement this different behavior, I think the TENTATIVE state should be forked into a TENTATIVE_DAD_NSOL and TENTATIVE_DATA (depending on the packet being received when the SAVI device was in NO_BIND). I don't think this enables any attack (which could not be made using DAD_NSOL), since it protects the host first using the address (with = data). What do you think? =20 Regarding to the attack you comment, a DAD_NSOL sent immediately after = it receives other DAD_NSOL, yes it can occur. Some degree of protection is provided if IGMP snooping is enabled, since only hosts subscribing to = the Solicited node address can receive DAD_NSOL. It is very difficult to = protect even for SAVI since you cannot identify when the second DAD_NSOL is a = reply or a legitimate collision. If you don't want to suffer from this, SEND = is the answer (although this issue is not specifically solved in the RFCs, solutions are straightforward because there is some material that should = be different if generated by different hosts). =20 I don't find the situation in which the following occurs: "A very rare situation: two SAVI devices may protect the same address from each other = by sending DAD_NADV. Thus binding should not be protected from DAD_NADV." = Can you explain? =20 Regards, Alberto =20 _____ =20 De: Guang Yao [mailto:yaog@netarchlab.tsinghua.edu.cn]=20 Enviado el: martes, 15 de diciembre de 2009 10:09 Para: 'Alberto Garc=EDa' CC: 'SAVI Mailing List' Asunto: RE: [savi] SLAAC-SAVI and host address configuration =20 Hi, Alberto =20 Maybe we must protect the binding. Or else there may some kind of = attacking. For example, a host may send a DAD_NSOL for the same address immediately after it receives the first one. So, protecting the first one will do no evil, although it is always hard to know who is the real first one. =20 However, this protection is aggressive and violates DAD. RFC4862 = implies if there are simultaneous DAD NSOLs, none can use the tentative address. = Maybe no perfect solution here for the tradeoff of security and fairness. =20 A very rare situation: two SAVI devices may protect the same address = from each other by sending DAD_NADV. Thus binding should not be protected = from DAD_NADV. =20 I think you have made a good point. =20 BR, Guang =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa Sent: Thursday, December 10, 2009 8:29 PM To: 'Guang Yao' Cc: 'SAVI Mailing List' Subject: Re: [savi] SLAAC-SAVI and host address configuration =20 Hi Guang, I agree that it is a good idea to use (unicast address sourced) NSOL = instead of DAD_NSOL for the messages that the SAVI device synthesize to check if = a host is still in the port or not (when it is in VALID state and the = lifetime timer expires, or when a data packet is received from a Validating port different to the current binding).=20 But my question goes further: if the SAVI host receives a DAD_NSOL from = the port through which a binding exists, do we want to protect the binding = from other hosts sending DAD_NSOL messages? (in this period, the host at the = port with the binding is not defending its address) We could, if we wanted (by means of something like the WAIT_FOR_CONFIG = state I commented), by making the SAVI device defending the address by sending DAD_NADV. I think the point to discuss is if it is reasonable to prefer = a host that is configuring an address in the port for which we have a = binding, over hosts doing the same in other locations.=20 As it is currently defined, there are many situations in which a host in other ports would configure the address even if a host is trying so in = the port for which a binding exists. Has this being discussed in IETF76? =20 Regards, Alberto =20 _____ =20 De: Guang Yao [mailto:yaoa02@mails.tsinghua.edu.cn]=20 Enviado el: jueves, 10 de diciembre de 2009 11:23 Para: 'Alberto Garc=EDa' CC: 'SAVI Mailing List' Asunto: RE: [savi] SLAAC-SAVI and host address configuration =20 Hi, Alberto =20 DAD_NSOL should never be sent to the host who is supposed to use the = target address. And it is not necessary. Actually this case is mention in DHCP solution draft and the corresponding slides of IETF76. =20 If a probe should be sent to host to detect alive, use NSOL but not DAD NSOL. =20 BR, Guang =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa Sent: Thursday, December 10, 2009 6:00 PM To: 'SAVI Mailing List' Subject: [savi] SLAAC-SAVI and host address configuration =20 Hi, Regarding to the SLAAC-SAVI mechanism proposed so far (draft-ietf-savi-fcfs-02), I think that there are some caveats in the behavior of SLAAC hosts when they are in the process of configuring = their own addresses (i.e. when the address of the host is still tentative).=20 Suppose that a host has configured an address, has a valid binding in a = SAVI device, and then it restarts the network configuration so the address is configured again, DAD is executed by sending a DAD NSOL message, etc. = (for example, the user powers down and up the host - it happens all the time :-)). Suppose that while the host is performing DAD and the SAVI device = was in VALID state for this address, the lifetime timer expires in the SAVI device. Current specification says that the SAVI device sends a DAD_NSOL message to the host, and changes the state to TESTING_LIFETIME. But in = this particular case (the host is still configuring its address) the DAD_NSOL message stops address configuration in the host (instead of generating a DAD_NADV). Current SAVI design assumes that sending DAD_NSOL is in = general side-effect free for hosts, while this is not the case when the hosts = are in the process of configuring its own address.=20 Note that the same problem occurs when a host is configuring its address = and another host tries to use the same address either in a validating port = of the same SAVI device, or in another SAVI device: current specification assumes that the first host can answer to DAD_NSOL messages, while this = is not the case if it is configuring its address. I think the solution for this is to create a WAIT_FOR_CONFIG state. If a host is in VALID, TESTING_TP, or TESTING_VP state, and a DAD_NSOL is received from the port currently associated to the binding, the SAVI = device moves to this state and lifetime is set to LIFETIME. While the SAVI = device is in this state, messages from other hosts are not considered (in particular, DAD_NSOL messages are not forwarded to the host configuring = its address). The state moves to VALID when the lifetime expires, or when = data packets are received from the current validating port (because in this = case we know the address configuration process has finished). The underlying supposition for this behavior is that if a host sends a DAD_NSOL message from the port from which a binding exists, (a) the host is proving that = it is alive and (b) this host in this port is supposed to be more = legitimate than other hosts trying to use the address in other ports at the same = time. Therefore, the address configuration procedure for this host should be protected, as well as the binding for it. =20 Do you think this makes sense? Regards, Alberto =20 ------=_NextPart_000_00A7_01CA7D7D.DD3DCF80 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for your = comments.

I think there = are two different issues:

 =

1- When a = binding exists for an address in a SAVI device. A host connected to the port associated = to the binding can turn down and then up, and send a DAD_NSOL. In this case, I = think it should be fair to preserve the existing binding and defend the = address, based on the past events (there was a host that successfully obtained a binding, and the time since the host defended its right to have the = binding is very short). If we want to protect this, no DAD_NSOL should be forwarded = to the host, and the SAVI device should defend the address for other ports = (sending DAD_NADV) while the host cannot do that.

I think it is = nice to allow hosts to keep their addresses if address reconfiguration occurs in = a short period of time

From DAD = perspective, although it is not the behavior specified in RFC4862, I think it is not = opposed to its spirit, in the sense that here we have a criteria to decide which = node “deserves most” the address, the one that had the binding first. For the = hosts it is not an operational problem (only changes which host wins in a = collision)

What do you = think about this case?

 =

2- When there is = no binding for the address in a SAVI device, and two hosts try to use the = same address. In this case, I agree we do not have any SAVI-specific clue to = decide which should succeed. In RFC4862 two things may occur: either none of = them configure the address (because both hosts start address configuration, = send DAD_NSOL, and both receive the DAD_NSOL of the other when they are in = tentative state), or the last one configures its address (one starts address configuration well before the other, sends DAD_NSOL but the other host = is not configuring the address yet so it is not considered; some time later the = other starts address configuration, sends its DAD_NSOL and stops address = configuration for the first host).

The current SAVI specification does not address this collision in the address = configuration (says nothing about DAD_NSOL received in TENTATIVE state). To address this = case,

-        in TENTATIVE state if a DAD_NSOL is received for the same = address from a validating port P’, it should be forwarded to the = Validating port P (this will stop address configuration in the host at P), and the state = should remain in TENTATIVE, but now testing port P’ (the last one, and = the port that may succeed). Note that the SAVI devices cannot know if the second = host will succeed in its address configuration or not (this depends on the = time at which the DAD_NSOL message of the first host arrived), but we know that the = host at P will not succeed, so moving the binding to tentative the binding for = P’ (which can configure its address or not) seems = appropriate.

-        In TENTATIVE state if a DAD_NSOL is received from a trusted = port, the state is changed to NO_BIND. The host in the local port will not = succeed.

An additional = thing should be discussed: currently, there is equal treatment when either a = DAD_NSOL or a data packet arrives when SAVI is in NO_BIND state (send DAD_NSOL = and move to TENTATIVE). However, the host sending data (this means it has its = address configured) should not be treated equally if a DAD_NSOL is received: in = this case I think we should protect the binding for this host since it will = not unconfigure the address when receiving a DAD_NSOL. DAD_NADV from other SAVI device = should move the state to NO_BIND, but DAD_NSOL messages should be just = forwarded to the host to let it defend the address. To implement this different = behavior, I think the TENTATIVE state should be forked into a TENTATIVE_DAD_NSOL and TENTATIVE_DATA (depending on the packet being received when the SAVI = device was in NO_BIND).

I don’t = think this enables any attack (which could not be made using DAD_NSOL), since it = protects the host first using the address (with data). What do you = think?

 =

Regarding to the = attack you comment, a DAD_NSOL sent immediately after it receives other = DAD_NSOL, yes it can occur. Some degree of protection is provided if IGMP snooping is enabled, since only hosts subscribing to the Solicited node address can = receive DAD_NSOL. It is very difficult to protect even for SAVI since you cannot = identify when the second DAD_NSOL is a reply or a legitimate collision. If you = don’t want to suffer from this, SEND is the answer (although this issue is not specifically solved in the RFCs, solutions are straightforward because = there is some material that should be different if generated by different = hosts).

 =

I don’t = find the situation in which the following occurs: “A very rare situation: two SAVI devices may protect the = same address from each other by sending DAD_NADV. Thus binding should not be protected from DAD_NADV.” Can you explain?<= /span>

 =

Regards,

Alberto

 =

De:= Guang Yao [mailto:yaog@netarchlab.tsinghua.edu.cn]
Enviado el: martes, 15 de diciembre de 2009 10:09
Para: 'Alberto Garc=EDa'
CC: 'SAVI Mailing = List'
Asunto: RE: [savi] = SLAAC-SAVI and host address configuration

 

Hi, = Alberto

 <= /o:p>

Maybe we = must protect the binding. Or else there may some kind of attacking. For = example, a host may send a DAD_NSOL for the same address immediately after it = receives the first one. So, protecting the first one will do no evil, although it is = always hard to know who is the real first one.

 <= /o:p>

However, = this protection is aggressive and  violates DAD. RFC4862 implies if = there are simultaneous DAD NSOLs, none can use the tentative address. Maybe no = perfect solution here for the tradeoff of security and = fairness.

 

A very rare situation: two SAVI devices may protect the same address from each other = by sending DAD_NADV. Thus binding should not be protected from = DAD_NADV.

 <= /o:p>

I think you = have made a good point.

 <= /o:p>

BR,

Guang

 <= /o:p>

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa
Sent: Thursday, December = 10, 2009 8:29 PM
To: 'Guang Yao'
Cc: 'SAVI Mailing = List'
Subject: Re: [savi] = SLAAC-SAVI and host address configuration

 

Hi = Guang,

I agree that it = is a good idea to use (unicast address sourced) NSOL instead of DAD_NSOL for the = messages that the SAVI device synthesize to check if a host is still in the port = or not (when it is in VALID state and the lifetime timer expires, or when a = data packet is received from a Validating port different to the current = binding).

But my question = goes further: if the SAVI host receives a DAD_NSOL from the port through = which a binding exists, do we want to protect the binding from other hosts = sending DAD_NSOL messages? (in this period, the host at the port with the = binding is not defending its address)

We could, if we = wanted (by means of something like the WAIT_FOR_CONFIG state I commented), by = making the SAVI device defending the address by sending DAD_NADV. I think the = point to discuss is if it is reasonable to prefer a host that is configuring an = address in the port for which we have a binding, over hosts doing the same in = other locations.

As it is = currently defined, there are many situations in which a host in other ports would configure the address even if a host is trying so in the port for which = a binding exists.

Has this being = discussed in IETF76?

 =

Regards,

Alberto

 =

De: Guang = Yao [mailto:yaoa02@mails.tsinghua.edu.cn]
Enviado el: jueves, 10 de diciembre de 2009 11:23
Para: 'Alberto = Garc=EDa'
CC: 'SAVI Mailing = List'
Asunto: RE: [savi] = SLAAC-SAVI and host address configuration

 

Hi, = Alberto

 <= /o:p>

DAD_NSOL = should never be sent to the host who is supposed to use the target address. And = it is not necessary. Actually this case is mention in DHCP solution draft and = the corresponding slides of IETF76.

 <= /o:p>

If a probe = should be sent to host to detect alive, use NSOL but not DAD = NSOL.

 <= /o:p>

BR,

Guang

 <= /o:p>

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa
Sent: Thursday, December = 10, 2009 6:00 PM
To: 'SAVI Mailing = List'
Subject: [savi] = SLAAC-SAVI and host address configuration

 

Hi,

Regarding to the SLAAC-SAVI mechanism proposed = so far (draft-ietf-savi-fcfs-02), I think that there are some caveats in the = behavior of SLAAC hosts when they are in the process of configuring their own = addresses (i.e. when the address of the host is still tentative). =

Suppose that a host has configured an address, = has a valid binding in a SAVI device, and then it restarts the network = configuration so the address is configured again, DAD is executed by sending a DAD = NSOL message, etc. (for example, the user powers down and up the host – = it happens all the time J). Suppose that while the host is performing DAD and the SAVI device was in = VALID state for this address, the lifetime timer expires in the SAVI device. = Current specification says that the SAVI device sends a DAD_NSOL message to the = host, and changes the state to TESTING_LIFETIME. But in this particular case = (the host is still configuring its address) the DAD_NSOL message stops = address configuration in the host (instead of generating a DAD_NADV). Current SAVI design = assumes that sending DAD_NSOL is in general side-effect free for hosts, while = this is not the case when the hosts are in the process of configuring its own = address.

Note that the same problem occurs when a host = is configuring its address and another host tries to use the same address = either in a validating port of the same SAVI device, or in another SAVI device: current specification assumes that the first host can answer to DAD_NSOL messages, while this is not the case if it is configuring its = address.

I think the solution for this is to create a WAIT_FOR_CONFIG state. If a host is in VALID, TESTING_TP, or TESTING_VP = state, and a DAD_NSOL is received from the port currently associated to the = binding, the SAVI device moves to this state and lifetime is set to LIFETIME. = While the SAVI device is in this state, messages from other hosts are not = considered (in particular, DAD_NSOL messages are not forwarded to the host configuring = its address). The state moves to VALID when the lifetime expires, or when = data packets are received from the current validating port (because in this = case we know the address configuration process has finished). The underlying supposition for this behavior is that if a host sends a DAD_NSOL message = from the port from which a binding exists, (a) the host is proving that it is = alive and (b) this host in this port is supposed to be more legitimate than = other hosts trying to use the address in other ports at the same time. = Therefore, the address configuration procedure for this host should be protected, as = well as the binding for it.

 

Do you think this makes = sense?

Regards,

Alberto

 

------=_NextPart_000_00A7_01CA7D7D.DD3DCF80-- From christian.vogt@ericsson.com Wed Dec 16 08:25:56 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14113A69DB for ; Wed, 16 Dec 2009 08:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 EoQ8HoMWiBqp for ; Wed, 16 Dec 2009 08:25:56 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 155793A67FA for ; Wed, 16 Dec 2009 08:25:55 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nBGGQGHU010460; Wed, 16 Dec 2009 10:26:24 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.137]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 16 Dec 2009 11:25:36 -0500 From: Christian Vogt To: Jun Bi Date: Wed, 16 Dec 2009 11:25:35 -0500 Thread-Topic: [savi] Consensus call on adopting draft-bi-savi-dhcp-00 Thread-Index: Acp+bGVD+1U40QWvTAmM8gfuYJ4wgQ== Message-ID: <8B4AC2A8-2ECA-4BCB-B833-865A3A46C096@ericsson.com> References: <44328038-1840-4B14-B616-CF33E023FBC6@ericsson.com> <5001C0A6-F145-48B3-8001-D84E47B993D5@ericsson.com> In-Reply-To: <5001C0A6-F145-48B3-8001-D84E47B993D5@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SAVI Mailing List Subject: Re: [savi] Consensus call on adopting draft-bi-savi-dhcp-00 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 16:25:56 -0000 Jun and all - Our new deliverables and milestones have been approved. Jun, please go ahead and re-submit the current version of draft-bi-savi-dhcp as draft- ietf-savi-dhcp-00. Thanks. - Christian On Dec 3, 2009, Christian Vogt wrote: > Folks - > > We recently had a consensus call about adopting Internet draft > "draft-bi-savi-dhcp-00" as a working group document. The feedback we > received was unanimous: 13 people agreed to adopt the Internet draft, > and nobody was against it. This means that we will adopt > draft-bi-savi-dhcp-00 as a working group document > > I will now talk to our area directors about this decision, and > afterwards have Jun Bi and his co-authors re-submit > draft-bi-savi-dhcp-00 as draft-ietf-savi-dhcp-00. > > - Christian From yaoa02@mails.tsinghua.edu.cn Wed Dec 16 20:28:32 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8E23A6939 for ; Wed, 16 Dec 2009 20:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.99 X-Spam-Level: X-Spam-Status: No, score=0.99 tagged_above=-999 required=5 tests=[AWL=0.689, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 VwUBIDg2UwdZ for ; Wed, 16 Dec 2009 20:28:17 -0800 (PST) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id C60FF3A6936 for ; Wed, 16 Dec 2009 20:28:12 -0800 (PST) Received: from tu132199.ip.tsinghua.edu.cn ([166.111.132.199] helo=yaoguangPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1NL7xw-0006fS-F9; Thu, 17 Dec 2009 12:27:52 +0800 From: "Guang Yao" To: =?iso-8859-1?Q?'Alberto_Garc=EDa'?= References: <002d01ca7982$b9f6f780$2de4e680$@tsinghua.edu.cn> <006401ca7d66$4d6a2aa0$e83e7fe0$@tsinghua.edu.cn> <9CFAED83D3B54E998DA902BD3A46A54D@bombo> In-Reply-To: <9CFAED83D3B54E998DA902BD3A46A54D@bombo> Date: Thu, 17 Dec 2009 12:27:43 +0800 Message-ID: <001101ca7ed1$47116f30$d5344d90$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01CA7F14.5534AF30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp5ft3DrqEqo/NRRA29cOC6TZIMqAAAW7xwAARmmmAA8zy0AAADnebQAFebQ1A= Content-Language: zh-cn Cc: 'SAVI Mailing List' Subject: Re: [savi] SLAAC-SAVI and host address configuration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 04:28:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01CA7F14.5534AF30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Alberto =20 Please see my comments inline. =20 BR, Guang =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa Sent: Tuesday, December 15, 2009 6:58 PM To: 'Guang Yao' Cc: 'SAVI Mailing List' Subject: Re: [savi] SLAAC-SAVI and host address configuration =20 Hi, Thanks for your comments. I think there are two different issues: =20 1- When a binding exists for an address in a SAVI device. A host connected to the port associated to the binding can turn down and then = up, and send a DAD_NSOL. In this case, I think it should be fair to preserve = the existing binding and defend the address, based on the past events (there = was a host that successfully obtained a binding, and the time since the host defended its right to have the binding is very short).=20 [Guang Yao]=20 A situation: the host changes to another port, and sends DAD_NSOL for = its previous address. (And the previous port is attached by another host immediately.) If the address is preserved, the moving host has to configure another address. This protection will actually disturb smooth port movement. =20 If we want to protect this, no DAD_NSOL should be forwarded to the host, = and the SAVI device should defend the address for other ports (sending = DAD_NADV) while the host cannot do that.=20 I think it is nice to allow hosts to keep their addresses if address reconfiguration occurs in a short period of time [Guang Yao]=20 I agree it=92s nice to keep address for a short time, if and only if = there is not a DAD_NSOL. Though this may allow some kind of scanning attack against a = disconnected host, it=92s not very bad for the host can always use another address. =20 >From DAD perspective, although it is not the behavior specified in = RFC4862, I think it is not opposed to its spirit, in the sense that here we have = a criteria to decide which node =93deserves most=94 the address, the one = that had the binding first. For the hosts it is not an operational problem (only changes which host wins in a collision)=20 What do you think about this case? =20 2- When there is no binding for the address in a SAVI device, and two = hosts try to use the same address. In this case, I agree we do not have any SAVI-specific clue to decide which should succeed. In RFC4862 two things = may occur: either none of them configure the address (because both hosts = start address configuration, send DAD_NSOL, and both receive the DAD_NSOL of = the other when they are in tentative state), or the last one configures its address (one starts address configuration well before the other, sends DAD_NSOL but the other host is not configuring the address yet so it is = not considered; some time later the other starts address configuration, = sends its DAD_NSOL and stops address configuration for the first host).=20 =20 [Guang Yao]=20 IMO, for a SAVI solution, it=92s better to make sure only one host is configured the tentative address. Even none is better than both. However, It=92s a real hard problem for current RFC4862. If there is a timestamp in DAD_NSOL, and DAD is sensitive to the timestamp, things may = be easier to handle. =20 The current SAVI specification does not address this collision in the address configuration (says nothing about DAD_NSOL received in TENTATIVE state). To address this case,=20 - in TENTATIVE state if a DAD_NSOL is received for the same address = from a validating port P=92, it should be forwarded to the Validating port P = (this will stop address configuration in the host at P), and the state should remain in TENTATIVE, but now testing port P=92 (the last one, and the = port that may succeed). Note that the SAVI devices cannot know if the second = host will succeed in its address configuration or not (this depends on the = time at which the DAD_NSOL message of the first host arrived), but we know = that the host at P will not succeed, so moving the binding to tentative the binding for P=92 (which can configure its address or not) seems = appropriate. - In TENTATIVE state if a DAD_NSOL is received from a trusted port, = the state is changed to NO_BIND. The host in the local port will not = succeed.=20 An additional thing should be discussed: currently, there is equal = treatment when either a DAD_NSOL or a data packet arrives when SAVI is in NO_BIND state (send DAD_NSOL and move to TENTATIVE). However, the host sending = data (this means it has its address configured) should not be treated equally = if a DAD_NSOL is received: in this case I think we should protect the = binding for this host since it will not unconfigure the address when receiving a DAD_NSOL. DAD_NADV from other SAVI device should move the state to = NO_BIND, but DAD_NSOL messages should be just forwarded to the host to let it = defend the address. To implement this different behavior, I think the TENTATIVE state should be forked into a TENTATIVE_DAD_NSOL and TENTATIVE_DATA (depending on the packet being received when the SAVI device was in NO_BIND). I don=92t think this enables any attack (which could not be made using DAD_NSOL), since it protects the host first using the address (with = data). What do you think? [Guang Yao]=20 An attack: an attacker receives a DAD_NSOL, and sends data packet immediately. =20 I find it=92s very hard to judge if there is no rule. Maybe we should = define the rules in DAD. =20 Regarding to the attack you comment, a DAD_NSOL sent immediately after = it receives other DAD_NSOL, yes it can occur. Some degree of protection is provided if IGMP snooping is enabled, since only hosts subscribing to = the Solicited node address can receive DAD_NSOL. It is very difficult to = protect even for SAVI since you cannot identify when the second DAD_NSOL is a = reply or a legitimate collision. If you don=92t want to suffer from this, SEND = is the answer (although this issue is not specifically solved in the RFCs, solutions are straightforward because there is some material that should = be different if generated by different hosts). [Guang Yao]=20 Typical SAVI device is layer-2 switch. And IGMP snooping wouldn=92t help = in such devices. This attack is too easy . I=92m afraid it may be used to argue how = fragile SAVI is. =20 =20 I don=92t find the situation in which the following occurs: =93A very = rare situation: two SAVI devices may protect the same address from each other = by sending DAD_NADV. Thus binding should not be protected from DAD_NADV.=94 = Can you explain? [Guang Yao]=20 It means, two SAVI devices get a DAD_NSOL from local nearly = simultaneously, and then get the DAD_NSOL from each other. If both of they want to = protect local binding, there will be two bindings in the network for one = address. But anyway, it=92s a really rare situation. =20 Regards, Alberto =20 _____ =20 De: Guang Yao [mailto:yaog@netarchlab.tsinghua.edu.cn]=20 Enviado el: martes, 15 de diciembre de 2009 10:09 Para: 'Alberto Garc=EDa' CC: 'SAVI Mailing List' Asunto: RE: [savi] SLAAC-SAVI and host address configuration =20 Hi, Alberto =20 Maybe we must protect the binding. Or else there may some kind of = attacking. For example, a host may send a DAD_NSOL for the same address immediately after it receives the first one. So, protecting the first one will do no evil, although it is always hard to know who is the real first one. =20 However, this protection is aggressive and violates DAD. RFC4862 = implies if there are simultaneous DAD NSOLs, none can use the tentative address. = Maybe no perfect solution here for the tradeoff of security and fairness. =20 A very rare situation: two SAVI devices may protect the same address = from each other by sending DAD_NADV. Thus binding should not be protected = from DAD_NADV. =20 I think you have made a good point. =20 BR, Guang =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa Sent: Thursday, December 10, 2009 8:29 PM To: 'Guang Yao' Cc: 'SAVI Mailing List' Subject: Re: [savi] SLAAC-SAVI and host address configuration =20 Hi Guang, I agree that it is a good idea to use (unicast address sourced) NSOL = instead of DAD_NSOL for the messages that the SAVI device synthesize to check if = a host is still in the port or not (when it is in VALID state and the = lifetime timer expires, or when a data packet is received from a Validating port different to the current binding).=20 But my question goes further: if the SAVI host receives a DAD_NSOL from = the port through which a binding exists, do we want to protect the binding = from other hosts sending DAD_NSOL messages? (in this period, the host at the = port with the binding is not defending its address) We could, if we wanted (by means of something like the WAIT_FOR_CONFIG = state I commented), by making the SAVI device defending the address by sending DAD_NADV. I think the point to discuss is if it is reasonable to prefer = a host that is configuring an address in the port for which we have a = binding, over hosts doing the same in other locations.=20 As it is currently defined, there are many situations in which a host in other ports would configure the address even if a host is trying so in = the port for which a binding exists. Has this being discussed in IETF76? =20 Regards, Alberto =20 _____ =20 De: Guang Yao [mailto:yaoa02@mails.tsinghua.edu.cn]=20 Enviado el: jueves, 10 de diciembre de 2009 11:23 Para: 'Alberto Garc=EDa' CC: 'SAVI Mailing List' Asunto: RE: [savi] SLAAC-SAVI and host address configuration =20 Hi, Alberto =20 DAD_NSOL should never be sent to the host who is supposed to use the = target address. And it is not necessary. Actually this case is mention in DHCP solution draft and the corresponding slides of IETF76. =20 If a probe should be sent to host to detect alive, use NSOL but not DAD NSOL. =20 BR, Guang =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa Sent: Thursday, December 10, 2009 6:00 PM To: 'SAVI Mailing List' Subject: [savi] SLAAC-SAVI and host address configuration =20 Hi, Regarding to the SLAAC-SAVI mechanism proposed so far (draft-ietf-savi-fcfs-02), I think that there are some caveats in the behavior of SLAAC hosts when they are in the process of configuring = their own addresses (i.e. when the address of the host is still tentative).=20 Suppose that a host has configured an address, has a valid binding in a = SAVI device, and then it restarts the network configuration so the address is configured again, DAD is executed by sending a DAD NSOL message, etc. = (for example, the user powers down and up the host =96 it happens all the = time J). Suppose that while the host is performing DAD and the SAVI device was in VALID state for this address, the lifetime timer expires in the SAVI = device. Current specification says that the SAVI device sends a DAD_NSOL message = to the host, and changes the state to TESTING_LIFETIME. But in this = particular case (the host is still configuring its address) the DAD_NSOL message = stops address configuration in the host (instead of generating a DAD_NADV). Current SAVI design assumes that sending DAD_NSOL is in general = side-effect free for hosts, while this is not the case when the hosts are in the = process of configuring its own address.=20 Note that the same problem occurs when a host is configuring its address = and another host tries to use the same address either in a validating port = of the same SAVI device, or in another SAVI device: current specification assumes that the first host can answer to DAD_NSOL messages, while this = is not the case if it is configuring its address. I think the solution for this is to create a WAIT_FOR_CONFIG state. If a host is in VALID, TESTING_TP, or TESTING_VP state, and a DAD_NSOL is received from the port currently associated to the binding, the SAVI = device moves to this state and lifetime is set to LIFETIME. While the SAVI = device is in this state, messages from other hosts are not considered (in particular, DAD_NSOL messages are not forwarded to the host configuring = its address). The state moves to VALID when the lifetime expires, or when = data packets are received from the current validating port (because in this = case we know the address configuration process has finished). The underlying supposition for this behavior is that if a host sends a DAD_NSOL message from the port from which a binding exists, (a) the host is proving that = it is alive and (b) this host in this port is supposed to be more = legitimate than other hosts trying to use the address in other ports at the same = time. Therefore, the address configuration procedure for this host should be protected, as well as the binding for it. =20 Do you think this makes sense? Regards, Alberto =20 ------=_NextPart_000_0012_01CA7F14.5534AF30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, Alberto

 

Please see my comments inline.

 

BR,

Guang

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa
Sent: Tuesday, December 15, 2009 6:58 PM
To: 'Guang Yao'
Cc: 'SAVI Mailing List'
Subject: Re: [savi] SLAAC-SAVI and host address = configuration

 

Hi,

Thanks for your comments.

I think there are two different = issues:

 

1-     When a binding exists for = an address in a SAVI device. A host connected to the port associated to the = binding can turn down and then up, and send a DAD_NSOL. In this case, I think it = should be fair to preserve the existing binding and defend the address, based = on the past events (there was a host that successfully obtained a binding, and = the time since the host defended its right to have the binding is very = short).

[Guang Yao] =

A situation: the host changes to = another port, and sends DAD_NSOL for its previous address. (And the previous = port is attached by another host immediately.)

If the address is preserved, the = moving host has to configure another address.

This protection will actually = disturb smooth port movement.

 

If we want to protect this, no DAD_NSOL should be forwarded = to the host, and the SAVI device should defend the address for other ports = (sending DAD_NADV) while the host cannot do that.

I think it is nice to allow hosts to keep their addresses if address reconfiguration occurs in a short period of = time

[Guang Yao] =

I agree it’s nice to keep = address for a short time, if and only if there is not a = DAD_NSOL.

Though this may allow some kind of scanning attack against a disconnected host, it’s not very bad for = the host can always use another address.

 

From DAD perspective, although it is not the behavior = specified in RFC4862, I think it is not opposed to its spirit, in the sense that here = we have a criteria to decide which node “deserves most” the = address, the one that had the binding first. For the hosts it is not an = operational problem (only changes which host wins in a collision) =

What do you think about this case?

 

2- When there is no binding for the address in a SAVI = device, and two hosts try to use the same address. In this case, I agree we do not = have any SAVI-specific clue to decide which should succeed. In RFC4862 two things = may occur: either none of them configure the address (because both hosts = start address configuration, send DAD_NSOL, and both receive the DAD_NSOL of = the other when they are in tentative state), or the last one configures its = address (one starts address configuration well before the other, sends DAD_NSOL = but the other host is not configuring the address yet so it is not considered; = some time later the other starts address configuration, sends its DAD_NSOL = and stops address configuration for the first host).

 

[Guang Yao] =

IMO, for a SAVI solution, = it’s better to make sure only one host is configured the tentative address. = Even none is better than both.

However, It’s a real hard = problem for current RFC4862. If there is a timestamp in DAD_NSOL, and DAD is = sensitive to the timestamp, things may be easier to = handle.

 

The current SAVI specification does not address this = collision in the address configuration (says nothing about DAD_NSOL received in = TENTATIVE state). To address this case,

-     in TENTATIVE state if a = DAD_NSOL is received for the same address from a validating port P’, it = should be forwarded to the Validating port P (this will stop address configuration = in the host at P), and the state should remain in TENTATIVE, but now testing = port P’ (the last one, and the port that may succeed). Note that the = SAVI devices cannot know if the second host will succeed in its address = configuration or not (this depends on the time at which the DAD_NSOL message of the = first host arrived), but we know that the host at P will not succeed, so = moving the binding to tentative the binding for P’ (which can configure its = address or not) seems appropriate.

-     In TENTATIVE state if a = DAD_NSOL is received from a trusted port, the state is changed to NO_BIND. The = host in the local port will not succeed.

An additional thing should be discussed: currently, there is = equal treatment when either a DAD_NSOL or a data packet arrives when SAVI is = in NO_BIND state (send DAD_NSOL and move to TENTATIVE). However, the host = sending data (this means it has its address configured) should not be treated = equally if a DAD_NSOL is received: in this case I think we should protect the = binding for this host since it will not unconfigure the address when receiving a DAD_NSOL. DAD_NADV from other SAVI device should move the state to = NO_BIND, but DAD_NSOL messages should be just forwarded to the host to let it defend = the address. To implement this different behavior, I think the TENTATIVE = state should be forked into a TENTATIVE_DAD_NSOL and TENTATIVE_DATA (depending = on the packet being received when the SAVI device was in = NO_BIND).

I don’t think this enables any attack (which could not = be made using DAD_NSOL), since it protects the host first using the address = (with data). What do you think?

[Guang Yao] =

An attack: an attacker receives a DAD_NSOL, and sends data packet = immediately.

 

I find it’s very hard to = judge if there is no rule. Maybe we should define the rules in = DAD.

 

Regarding to the attack you comment, a DAD_NSOL sent = immediately after it receives other DAD_NSOL, yes it can occur. Some degree of = protection is provided if IGMP snooping is enabled, since only hosts subscribing to = the Solicited node address can receive DAD_NSOL. It is very difficult to = protect even for SAVI since you cannot identify when the second DAD_NSOL is a = reply or a legitimate collision. If you don’t want to suffer from this, = SEND is the answer (although this issue is not specifically solved in the RFCs, solutions are straightforward because there is some material that should = be different if generated by different hosts).

[Guang Yao] =

Typical SAVI device is layer-2 = switch. And IGMP snooping wouldn’t help in such = devices.

This attack is too easy . = I’m afraid it may be used to argue how fragile SAVI = is.

 

 

I don’t find the situation in which the following = occurs: “A very rare situation: two SAVI devices may protect the = same address from each other by sending DAD_NADV. Thus binding should not be protected from DAD_NADV.” Can you = explain?

[Guang Yao] =

It means, two SAVI devices get a = DAD_NSOL from local nearly simultaneously, and then get the DAD_NSOL from each = other. If both of they want to protect local binding, there will be two bindings = in the network for one address. But anyway, it’s a really rare = situation.

 

Regards,

Alberto

 

De: Guang Yao [mailto:yaog@netarchlab.tsinghua.edu.cn]
Enviado el: martes, 15 de diciembre de 2009 10:09
Para: 'Alberto Garc=EDa'
CC: 'SAVI Mailing List'
Asunto: RE: [savi] SLAAC-SAVI and host address = configuration

 

Hi, Alberto

 

Maybe we must protect the binding. Or else there may some = kind of attacking. For example, a host may send a DAD_NSOL for the same = address immediately after it receives the first one. So, protecting the first = one will do no evil, although it is always hard to know who is the real first = one.

 

However, this protection is aggressive and  violates = DAD. RFC4862 implies if there are simultaneous DAD NSOLs, none can use the = tentative address. Maybe no perfect solution here for the tradeoff of security and fairness.

 

A very rare situation: two SAVI devices may protect the = same address from each other by sending DAD_NADV. Thus binding should not be protected from DAD_NADV.

 

I think you have made a good point.

 

BR,

Guang

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa
Sent: Thursday, December 10, 2009 8:29 PM
To: 'Guang Yao'
Cc: 'SAVI Mailing List'
Subject: Re: [savi] SLAAC-SAVI and host address = configuration

 

Hi Guang,

I agree that it is a good idea to use (unicast address = sourced) NSOL instead of DAD_NSOL for the messages that the SAVI device = synthesize to check if a host is still in the port or not (when it is in VALID state = and the lifetime timer expires, or when a data packet is received from a = Validating port different to the current binding).

But my question goes further: if the SAVI host receives a = DAD_NSOL from the port through which a binding exists, do we want to protect the = binding from other hosts sending DAD_NSOL messages? (in this period, the host at = the port with the binding is not defending its = address)

We could, if we wanted (by means of something like the WAIT_FOR_CONFIG state I commented), by making the SAVI device defending = the address by sending DAD_NADV. I think the point to discuss is if it is reasonable to prefer a host that is configuring an address in the port = for which we have a binding, over hosts doing the same in other locations. =

As it is currently defined, there are many situations in = which a host in other ports would configure the address even if a host is trying = so in the port for which a binding exists.

Has this being discussed in IETF76?

 

Regards,

Alberto

 

De: = Guang Yao [mailto:yaoa02@mails.tsinghua.edu.cn]
Enviado el: jueves, 10 de diciembre de 2009 11:23
Para: 'Alberto Garc=EDa'
CC: 'SAVI Mailing List'
Asunto: RE: [savi] SLAAC-SAVI and host address = configuration

 

Hi, Alberto

 

DAD_NSOL should never be sent to the host who is supposed = to use the target address. And it is not necessary. Actually this case is = mention in DHCP solution draft and the corresponding slides of = IETF76.

 

If a probe should be sent to host to detect alive, use = NSOL but not DAD NSOL.

 

BR,

Guang

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa
Sent: Thursday, December 10, 2009 6:00 PM
To: 'SAVI Mailing List'
Subject: [savi] SLAAC-SAVI and host address = configuration

 

Hi,

Regarding to the SLAAC-SAVI mechanism proposed so far (draft-ietf-savi-fcfs-02), I = think that there are some caveats in the behavior of SLAAC hosts when they are = in the process of configuring their own addresses (i.e. when the address of the = host is still tentative).

Suppose that a host has configured an address, has a valid binding in a SAVI = device, and then it restarts the network configuration so the address is configured = again, DAD is executed by sending a DAD NSOL message, etc. (for example, the = user powers down and up the host – it happens all the time J). Suppose that while the host is performing DAD and the SAVI device was in VALID = state for this address, the lifetime timer expires in the SAVI device. Current specification says that the SAVI device sends a DAD_NSOL message to the = host, and changes the state to TESTING_LIFETIME. But in this particular case = (the host is still configuring its address) the DAD_NSOL message stops = address configuration in the host (instead of generating a DAD_NADV). Current = SAVI design assumes that sending DAD_NSOL is in general side-effect free for = hosts, while this is not the case when the hosts are in the process of = configuring its own address.

Note that the same problem occurs when a host is configuring its address and = another host tries to use the same address either in a validating port of the = same SAVI device, or in another SAVI device: current specification assumes that = the first host can answer to DAD_NSOL messages, while this is not the case if it = is configuring its address.

I think the solution for this is to create a WAIT_FOR_CONFIG state. If a = host is in VALID, TESTING_TP, or TESTING_VP state, and a DAD_NSOL is received = from the port currently associated to the binding, the SAVI device moves to this = state and lifetime is set to LIFETIME. While the SAVI device is in this state, messages from other hosts are not considered (in particular, DAD_NSOL = messages are not forwarded to the host configuring its address). The state moves = to VALID when the lifetime expires, or when data packets are received from = the current validating port (because in this case we know the address = configuration process has finished). The underlying supposition for this behavior is = that if a host sends a DAD_NSOL message from the port from which a binding = exists, (a) the host is proving that it is alive and (b) this host in this port is = supposed to be more legitimate than other hosts trying to use the address in = other ports at the same time. Therefore, the address configuration procedure for = this host should be protected, as well as the binding for = it.

 

Do you think this makes sense?

Regards,=

Alberto<= /o:p>

 

------=_NextPart_000_0012_01CA7F14.5534AF30-- From jari.arkko@piuha.net Thu Dec 17 02:04:46 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5A33A6969 for ; Thu, 17 Dec 2009 02:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 1ihbAonjg5rM for ; Thu, 17 Dec 2009 02:04:45 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 424573A6877 for ; Thu, 17 Dec 2009 02:04:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 40DB2D494C; Thu, 17 Dec 2009 12:04:30 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLRiYdPT9EcO; Thu, 17 Dec 2009 12:04:29 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D408ED491C; Thu, 17 Dec 2009 12:04:28 +0200 (EET) Message-ID: <4B2A022B.5080603@piuha.net> Date: Thu, 17 Dec 2009 12:04:27 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: SAVI Mailing List , Bill Fenner Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ralph Droms Subject: [savi] working group chairs X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 10:04:46 -0000 Bill Fenner will step down as WG chair for SAVI, due to day job taking too much of his time. I'd like to thank Bill for all his efforts in the working group and in the times leading to the creation of the working group. Thank you. But as a result of his stepping down, we are looking for a replacement. If you are interested in becoming a chair for this working group together with Christian Vogt, please talk to the ADs. If you have any question about the position don't hesitate to ask us, Bill, or Christian about it. Jari Arkko From root@core3.amsl.com Thu Dec 17 02:15:01 2009 Return-Path: X-Original-To: savi@ietf.org Delivered-To: savi@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DAA123A69C5; Thu, 17 Dec 2009 02:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091217101501.DAA123A69C5@core3.amsl.com> Date: Thu, 17 Dec 2009 02:15:01 -0800 (PST) Cc: savi@ietf.org Subject: [savi] I-D Action:draft-ietf-savi-dhcp-00.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 10:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Address Validation Improvements Working Group of the IETF. Title : SAVI Solution for DHCPv4/v6 Author(s) : J. Bi, et al. Filename : draft-ietf-savi-dhcp-00.txt Pages : 20 Date : 2009-12-17 This document specifies the procedure for creating bindings between a DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and an anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets with forged IP addresses generated on the local link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-dhcp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-savi-dhcp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-17020248.I-D@ietf.org> --NextPart-- From alberto@it.uc3m.es Thu Dec 17 11:17:32 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B613A6984 for ; Thu, 17 Dec 2009 11:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.679 X-Spam-Level: X-Spam-Status: No, score=-5.679 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 SqIyBO5WD6EA for ; Thu, 17 Dec 2009 11:17:13 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 44A893A6886 for ; Thu, 17 Dec 2009 11:17:10 -0800 (PST) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 48E5F730D48; Thu, 17 Dec 2009 20:16:54 +0100 (CET) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: "'Guang Yao'" References: <002d01ca7982$b9f6f780$2de4e680$@tsinghua.edu.cn> <006401ca7d66$4d6a2aa0$e83e7fe0$@tsinghua.edu.cn> <9CFAED83D3B54E998DA902BD3A46A54D@bombo> <001101ca7ed1$47116f30$d5344d90$@tsinghua.edu.cn> Date: Thu, 17 Dec 2009 20:16:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01CA7F55.DD2CAA00" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acp5ft3DrqEqo/NRRA29cOC6TZIMqAAAW7xwAARmmmAA8zy0AAADnebQAFebQ1AAF6v40A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <001101ca7ed1$47116f30$d5344d90$@tsinghua.edu.cn> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: 'SAVI Mailing List' Subject: Re: [savi] SLAAC-SAVI and host address configuration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 19:17:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0053_01CA7F55.DD2CAA00 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Hi, Also inline =20 _____ =20 De: Guang Yao [mailto:yaoa02@mails.tsinghua.edu.cn]=20 Enviado el: jueves, 17 de diciembre de 2009 5:28 Para: 'Alberto Garc=EDa' CC: 'SAVI Mailing List' Asunto: RE: [savi] SLAAC-SAVI and host address configuration =20 Hi, Alberto =20 Please see my comments inline. =20 BR, Guang =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa Sent: Tuesday, December 15, 2009 6:58 PM To: 'Guang Yao' Cc: 'SAVI Mailing List' Subject: Re: [savi] SLAAC-SAVI and host address configuration =20 Hi, Thanks for your comments. I think there are two different issues: =20 1- When a binding exists for an address in a SAVI device. A host connected to the port associated to the binding can turn down and then = up, and send a DAD_NSOL. In this case, I think it should be fair to preserve = the existing binding and defend the address, based on the past events (there = was a host that successfully obtained a binding, and the time since the host defended its right to have the binding is very short).=20 [Guang Yao]=20 A situation: the host changes to another port, and sends DAD_NSOL for = its previous address. (And the previous port is attached by another host immediately.) If the address is preserved, the moving host has to configure another address. This protection will actually disturb smooth port movement. [Alberto] This problem occurs only when the node has made DAD_NSOL _and_ then moves. And it lasts for LIFETIME since the host issued a DAD_NSOL. The choices are: - protect hosts turning down and up their addresses, and let a node = doing that not be able to communicate after moving during LIFETIME time - don't protect hosts turning down and up their addresses (let anybody generate a binding for this address in this case). I think we have to choose one.=20 =20 =20 =20 If we want to protect this, no DAD_NSOL should be forwarded to the host, = and the SAVI device should defend the address for other ports (sending = DAD_NADV) while the host cannot do that.=20 I think it is nice to allow hosts to keep their addresses if address reconfiguration occurs in a short period of time [Guang Yao]=20 I agree it's nice to keep address for a short time, if and only if there = is not a DAD_NSOL. [Alberto]: I don't understand. Maybe "if and only if there is a = DAD_NSOL"? Though this may allow some kind of scanning attack against a = disconnected host, it's not very bad for the host can always use another address. =20 >From DAD perspective, although it is not the behavior specified in = RFC4862, I think it is not opposed to its spirit, in the sense that here we have = a criteria to decide which node "deserves most" the address, the one that = had the binding first. For the hosts it is not an operational problem (only changes which host wins in a collision)=20 What do you think about this case? =20 2- When there is no binding for the address in a SAVI device, and two = hosts try to use the same address. In this case, I agree we do not have any SAVI-specific clue to decide which should succeed. In RFC4862 two things = may occur: either none of them configure the address (because both hosts = start address configuration, send DAD_NSOL, and both receive the DAD_NSOL of = the other when they are in tentative state), or the last one configures its address (one starts address configuration well before the other, sends DAD_NSOL but the other host is not configuring the address yet so it is = not considered; some time later the other starts address configuration, = sends its DAD_NSOL and stops address configuration for the first host).=20 =20 [Guang Yao]=20 IMO, for a SAVI solution, it's better to make sure only one host is configured the tentative address. Even none is better than both. However, It's a real hard problem for current RFC4862. If there is a timestamp in DAD_NSOL, and DAD is sensitive to the timestamp, things may = be easier to handle. =20 The current SAVI specification does not address this collision in the address configuration (says nothing about DAD_NSOL received in TENTATIVE state). To address this case,=20 - in TENTATIVE state if a DAD_NSOL is received for the same address = from a validating port P', it should be forwarded to the Validating port P = (this will stop address configuration in the host at P), and the state should remain in TENTATIVE, but now testing port P' (the last one, and the port that may succeed). Note that the SAVI devices cannot know if the second = host will succeed in its address configuration or not (this depends on the = time at which the DAD_NSOL message of the first host arrived), but we know = that the host at P will not succeed, so moving the binding to tentative the binding for P' (which can configure its address or not) seems = appropriate. - In TENTATIVE state if a DAD_NSOL is received from a trusted port, = the state is changed to NO_BIND. The host in the local port will not = succeed.=20 An additional thing should be discussed: currently, there is equal = treatment when either a DAD_NSOL or a data packet arrives when SAVI is in NO_BIND state (send DAD_NSOL and move to TENTATIVE). However, the host sending = data (this means it has its address configured) should not be treated equally = if a DAD_NSOL is received: in this case I think we should protect the = binding for this host since it will not unconfigure the address when receiving a DAD_NSOL. DAD_NADV from other SAVI device should move the state to = NO_BIND, but DAD_NSOL messages should be just forwarded to the host to let it = defend the address. To implement this different behavior, I think the TENTATIVE state should be forked into a TENTATIVE_DAD_NSOL and TENTATIVE_DATA (depending on the packet being received when the SAVI device was in NO_BIND). I don't think this enables any attack (which could not be made using DAD_NSOL), since it protects the host first using the address (with = data). What do you think? [Guang Yao]=20 An attack: an attacker receives a DAD_NSOL, and sends data packet immediately. [Alberto] This is the attack I describe in the next paragraph. The = solution is to use SEND (IGMP snooping also provides some protection) I find it's very hard to judge if there is no rule. Maybe we should = define the rules in DAD. =20 Regarding to the attack you comment, a DAD_NSOL sent immediately after = it receives other DAD_NSOL, yes it can occur. Some degree of protection is provided if IGMP snooping is enabled, since only hosts subscribing to = the Solicited node address can receive DAD_NSOL. It is very difficult to = protect even for SAVI since you cannot identify when the second DAD_NSOL is a = reply or a legitimate collision. If you don't want to suffer from this, SEND = is the answer (although this issue is not specifically solved in the RFCs, solutions are straightforward because there is some material that should = be different if generated by different hosts). [Guang Yao]=20 Typical SAVI device is layer-2 switch. And IGMP snooping wouldn't help = in such devices. This attack is too easy . I'm afraid it may be used to argue how fragile SAVI is. [Alberto] Yes. I prefer to see it as a nice incentive for SEND. =20 I don't find the situation in which the following occurs: "A very rare situation: two SAVI devices may protect the same address from each other = by sending DAD_NADV. Thus binding should not be protected from DAD_NADV." = Can you explain? [Guang Yao]=20 It means, two SAVI devices get a DAD_NSOL from local nearly = simultaneously, and then get the DAD_NSOL from each other. If both of they want to = protect local binding, there will be two bindings in the network for one = address. But anyway, it's a really rare situation. [Alberto] Ummm. Not sure of what you are talking about. If DAD_NSOLs are issued almost simultaneously, the case 2) discussed above applies in general. And only one binding is created.=20 Can you detail a case in which two bindings are created? =20 =20 Regards, Alberto =20 _____ =20 De: Guang Yao [mailto:yaog@netarchlab.tsinghua.edu.cn]=20 Enviado el: martes, 15 de diciembre de 2009 10:09 Para: 'Alberto Garc=EDa' CC: 'SAVI Mailing List' Asunto: RE: [savi] SLAAC-SAVI and host address configuration =20 Hi, Alberto =20 Maybe we must protect the binding. Or else there may some kind of = attacking. For example, a host may send a DAD_NSOL for the same address immediately after it receives the first one. So, protecting the first one will do no evil, although it is always hard to know who is the real first one. =20 However, this protection is aggressive and violates DAD. RFC4862 = implies if there are simultaneous DAD NSOLs, none can use the tentative address. = Maybe no perfect solution here for the tradeoff of security and fairness. =20 A very rare situation: two SAVI devices may protect the same address = from each other by sending DAD_NADV. Thus binding should not be protected = from DAD_NADV. =20 I think you have made a good point. =20 BR, Guang =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa Sent: Thursday, December 10, 2009 8:29 PM To: 'Guang Yao' Cc: 'SAVI Mailing List' Subject: Re: [savi] SLAAC-SAVI and host address configuration =20 Hi Guang, I agree that it is a good idea to use (unicast address sourced) NSOL = instead of DAD_NSOL for the messages that the SAVI device synthesize to check if = a host is still in the port or not (when it is in VALID state and the = lifetime timer expires, or when a data packet is received from a Validating port different to the current binding).=20 But my question goes further: if the SAVI host receives a DAD_NSOL from = the port through which a binding exists, do we want to protect the binding = from other hosts sending DAD_NSOL messages? (in this period, the host at the = port with the binding is not defending its address) We could, if we wanted (by means of something like the WAIT_FOR_CONFIG = state I commented), by making the SAVI device defending the address by sending DAD_NADV. I think the point to discuss is if it is reasonable to prefer = a host that is configuring an address in the port for which we have a = binding, over hosts doing the same in other locations.=20 As it is currently defined, there are many situations in which a host in other ports would configure the address even if a host is trying so in = the port for which a binding exists. Has this being discussed in IETF76? =20 Regards, Alberto =20 _____ =20 De: Guang Yao [mailto:yaoa02@mails.tsinghua.edu.cn]=20 Enviado el: jueves, 10 de diciembre de 2009 11:23 Para: 'Alberto Garc=EDa' CC: 'SAVI Mailing List' Asunto: RE: [savi] SLAAC-SAVI and host address configuration =20 Hi, Alberto =20 DAD_NSOL should never be sent to the host who is supposed to use the = target address. And it is not necessary. Actually this case is mention in DHCP solution draft and the corresponding slides of IETF76. =20 If a probe should be sent to host to detect alive, use NSOL but not DAD NSOL. =20 BR, Guang =20 From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa Sent: Thursday, December 10, 2009 6:00 PM To: 'SAVI Mailing List' Subject: [savi] SLAAC-SAVI and host address configuration =20 Hi, Regarding to the SLAAC-SAVI mechanism proposed so far (draft-ietf-savi-fcfs-02), I think that there are some caveats in the behavior of SLAAC hosts when they are in the process of configuring = their own addresses (i.e. when the address of the host is still tentative).=20 Suppose that a host has configured an address, has a valid binding in a = SAVI device, and then it restarts the network configuration so the address is configured again, DAD is executed by sending a DAD NSOL message, etc. = (for example, the user powers down and up the host - it happens all the time :-)). Suppose that while the host is performing DAD and the SAVI device = was in VALID state for this address, the lifetime timer expires in the SAVI device. Current specification says that the SAVI device sends a DAD_NSOL message to the host, and changes the state to TESTING_LIFETIME. But in = this particular case (the host is still configuring its address) the DAD_NSOL message stops address configuration in the host (instead of generating a DAD_NADV). Current SAVI design assumes that sending DAD_NSOL is in = general side-effect free for hosts, while this is not the case when the hosts = are in the process of configuring its own address.=20 Note that the same problem occurs when a host is configuring its address = and another host tries to use the same address either in a validating port = of the same SAVI device, or in another SAVI device: current specification assumes that the first host can answer to DAD_NSOL messages, while this = is not the case if it is configuring its address. I think the solution for this is to create a WAIT_FOR_CONFIG state. If a host is in VALID, TESTING_TP, or TESTING_VP state, and a DAD_NSOL is received from the port currently associated to the binding, the SAVI = device moves to this state and lifetime is set to LIFETIME. While the SAVI = device is in this state, messages from other hosts are not considered (in particular, DAD_NSOL messages are not forwarded to the host configuring = its address). The state moves to VALID when the lifetime expires, or when = data packets are received from the current validating port (because in this = case we know the address configuration process has finished). The underlying supposition for this behavior is that if a host sends a DAD_NSOL message from the port from which a binding exists, (a) the host is proving that = it is alive and (b) this host in this port is supposed to be more = legitimate than other hosts trying to use the address in other ports at the same = time. Therefore, the address configuration procedure for this host should be protected, as well as the binding for it. =20 Do you think this makes sense? Regards, Alberto =20 ------=_NextPart_000_0053_01CA7F55.DD2CAA00 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable

Hi,

Also = inline

 

De: Guang = Yao [mailto:yaoa02@mails.tsinghua.edu.cn]
Enviado el: jueves, 17 de diciembre de 2009 5:28
Para: 'Alberto Garc=EDa'
CC: 'SAVI Mailing = List'
Asunto: RE: [savi] = SLAAC-SAVI and host address configuration

 

Hi, = Alberto

 <= /o:p>

Please see = my comments inline.

 <= /o:p>

BR,

Guang

 

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa
Sent: Tuesday, December = 15, 2009 6:58 PM
To: 'Guang Yao'
Cc: 'SAVI Mailing = List'
Subject: Re: [savi] = SLAAC-SAVI and host address configuration

 

Hi,

Thanks for your = comments.

I think there = are two different issues:

 =

1-     = When a binding exists for an address in a = SAVI device. A host connected to the port associated to the binding can turn = down and then up, and send a DAD_NSOL. In this case, I think it should be = fair to preserve the existing binding and defend the address, based on the past = events (there was a host that successfully obtained a binding, and the time = since the host defended its right to have the binding is very short). =

[Guang Yao] =

A situation: the host changes to = another port, and sends DAD_NSOL for its previous address. (And the previous = port is attached by another host = immediately.)

If the address is preserved, the = moving host has to configure another = address.

This protection will actually = disturb smooth port movement.

[Alberto] This = problem occurs only when the node has made DAD_NSOL _and_ then moves. And it lasts for LIFETIME since the host issued a = DAD_NSOL.

The choices = are:

-   protect hosts turning down and up their addresses, and let a node doing that not be able to communicate after = moving during LIFETIME time

-   don’t protect hosts turning down = and up their addresses (let anybody generate a binding for this address in this = case).

I think we = have to choose one.

 

 =

 =

If we want to = protect this, no DAD_NSOL should be forwarded to the host, and the SAVI device = should defend the address for other ports (sending DAD_NADV) while the host = cannot do that.

I think it is = nice to allow hosts to keep their addresses if address reconfiguration occurs in = a short period of time

[Guang Yao] =

I agree it’s nice to keep = address for a short time, if and only if there is not a = DAD_NSOL.

[Alberto]: I = don’t understand. Maybe “if and only if there is a = DAD_NSOL”?

Though this may allow some kind of = scanning attack against a disconnected host, it’s not very bad for the host = can always use another address.

 =

From DAD = perspective, although it is not the behavior specified in RFC4862, I think it is not = opposed to its spirit, in the sense that here we have a criteria to decide which = node “deserves most” the address, the one that had the binding = first. For the hosts it is not an operational problem (only changes which host = wins in a collision)

What do you = think about this case?

 =

2- When there is = no binding for the address in a SAVI device, and two hosts try to use the = same address. In this case, I agree we do not have any SAVI-specific clue to = decide which should succeed. In RFC4862 two things may occur: either none of = them configure the address (because both hosts start address configuration, = send DAD_NSOL, and both receive the DAD_NSOL of the other when they are in = tentative state), or the last one configures its address (one starts address configuration well before the other, sends DAD_NSOL but the other host = is not configuring the address yet so it is not considered; some time later the = other starts address configuration, sends its DAD_NSOL and stops address configuration for the first host).

 

[Guang Yao] =

IMO, for a SAVI solution, it’s = better to make sure only one host is configured the tentative address. Even = none is better than both.

However, It’s a real hard = problem for current RFC4862. If there is a timestamp in DAD_NSOL, and DAD is = sensitive to the timestamp, things may be easier to = handle.

 <= /o:p>

The current SAVI specification does not address this collision in the address = configuration (says nothing about DAD_NSOL received in TENTATIVE state). To address = this case,

-   in TENTATIVE state if a DAD_NSOL is = received for the same address from a validating port P’, it should be forwarded = to the Validating port P (this will stop address configuration in the host at = P), and the state should remain in TENTATIVE, but now testing port P’ (the = last one, and the port that may succeed). Note that the SAVI devices cannot = know if the second host will succeed in its address configuration or not (this = depends on the time at which the DAD_NSOL message of the first host arrived), = but we know that the host at P will not succeed, so moving the binding to = tentative the binding for P’ (which can configure its address or not) seems = appropriate.

-   In TENTATIVE state if a DAD_NSOL is = received from a trusted port, the state is changed to NO_BIND. The host in the local = port will not succeed.

An additional = thing should be discussed: currently, there is equal treatment when either a = DAD_NSOL or a data packet arrives when SAVI is in NO_BIND state (send DAD_NSOL = and move to TENTATIVE). However, the host sending data (this means it has its = address configured) should not be treated equally if a DAD_NSOL is received: in = this case I think we should protect the binding for this host since it will = not unconfigure the address when receiving a DAD_NSOL. DAD_NADV from other = SAVI device should move the state to NO_BIND, but DAD_NSOL messages should be = just forwarded to the host to let it defend the address. To implement this = different behavior, I think the TENTATIVE state should be forked into a TENTATIVE_DAD_NSOL and TENTATIVE_DATA (depending on the packet being = received when the SAVI device was in NO_BIND).

I don’t = think this enables any attack (which could not be made using DAD_NSOL), since it = protects the host first using the address (with data). What do you = think?

[Guang Yao] =

An attack: an attacker receives a = DAD_NSOL, and sends data packet immediately.

[Alberto] This = is the attack I describe in the next paragraph. The solution is to use SEND = (IGMP snooping also provides some protection)

I find it’s very hard to judge = if there is no rule. Maybe we should define the rules in = DAD.

 =

Regarding to the = attack you comment, a DAD_NSOL sent immediately after it receives other = DAD_NSOL, yes it can occur. Some degree of protection is provided if IGMP snooping is enabled, since only hosts subscribing to the Solicited node address can = receive DAD_NSOL. It is very difficult to protect even for SAVI since you cannot identify when the second DAD_NSOL is a reply or a legitimate collision. = If you don’t want to suffer from this, SEND is the answer (although this = issue is not specifically solved in the RFCs, solutions are straightforward = because there is some material that should be different if generated by = different hosts).

[Guang Yao] =

Typical SAVI device is layer-2 = switch. And IGMP snooping wouldn’t help in such = devices.

This attack is too easy . I’m = afraid it may be used to argue how fragile SAVI = is.

[Alberto] Yes. = I prefer to see it as a nice incentive for SEND.

 =

I don’t = find the situation in which the following occurs: “A very rare situation: two SAVI = devices may protect the same address from each other by sending DAD_NADV. Thus = binding should not be protected from DAD_NADV.” Can you explain?

[Guang Yao] =

It means, two SAVI devices get a = DAD_NSOL from local nearly simultaneously, and then get the DAD_NSOL from each = other. If both of they want to protect local binding, there will be two bindings = in the network for one address. But anyway, it’s a really rare = situation.

[Alberto] = Ummm. Not sure of what you are talking about. If DAD_NSOLs are issued almost simultaneously, the case 2) discussed above applies in general. And only = one binding is created.

Can you detail = a case in which two bindings are created?

 =

 =

Regards,

Alberto

 =

De:= Guang Yao [mailto:yaog@netarchlab.tsinghua.edu.cn]
Enviado el: martes, 15 de diciembre de 2009 10:09
Para: 'Alberto Garc=EDa'
CC: 'SAVI = Mailing List'
Asunto: RE: [savi] = SLAAC-SAVI and host address configuration

 

Hi, = Alberto

 <= /o:p>

Maybe we = must protect the binding. Or else there may some kind of attacking. For = example, a host may send a DAD_NSOL for the same address immediately after it = receives the first one. So, protecting the first one will do no evil, although it is = always hard to know who is the real first one.

 <= /o:p>

However, = this protection is aggressive and  violates DAD. RFC4862 implies if = there are simultaneous DAD NSOLs, none can use the tentative address. Maybe no = perfect solution here for the tradeoff of security and = fairness.

 <= /o:p>

A very rare situation: two SAVI devices may protect the same address from each other = by sending DAD_NADV. Thus binding should not be protected from = DAD_NADV.

 <= /o:p>

I think you = have made a good point.

 <= /o:p>

BR,

Guang

 <= /o:p>

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa
Sent: Thursday, December = 10, 2009 8:29 PM
To: 'Guang Yao'
Cc: 'SAVI Mailing = List'
Subject: Re: [savi] = SLAAC-SAVI and host address configuration

 

Hi = Guang,

I agree that it = is a good idea to use (unicast address sourced) NSOL instead of DAD_NSOL for the = messages that the SAVI device synthesize to check if a host is still in the port = or not (when it is in VALID state and the lifetime timer expires, or when a = data packet is received from a Validating port different to the current = binding).

But my question = goes further: if the SAVI host receives a DAD_NSOL from the port through = which a binding exists, do we want to protect the binding from other hosts = sending DAD_NSOL messages? (in this period, the host at the port with the = binding is not defending its address)

We could, if we = wanted (by means of something like the WAIT_FOR_CONFIG state I commented), by = making the SAVI device defending the address by sending DAD_NADV. I think the = point to discuss is if it is reasonable to prefer a host that is configuring an = address in the port for which we have a binding, over hosts doing the same in = other locations.

As it is = currently defined, there are many situations in which a host in other ports would configure the address even if a host is trying so in the port for which = a binding exists.

Has this being = discussed in IETF76?

 =

Regards,

Alberto

 =

De: Guang = Yao [mailto:yaoa02@mails.tsinghua.edu.cn]
Enviado el: jueves, 10 de diciembre de 2009 11:23
Para: 'Alberto Garc=EDa'
CC: 'SAVI Mailing = List'
Asunto: RE: [savi] = SLAAC-SAVI and host address configuration

 

Hi, = Alberto

 <= /o:p>

DAD_NSOL = should never be sent to the host who is supposed to use the target address. And = it is not necessary. Actually this case is mention in DHCP solution draft and = the corresponding slides of IETF76.

 <= /o:p>

If a probe = should be sent to host to detect alive, use NSOL but not DAD = NSOL.

 <= /o:p>

BR,

Guang

 <= /o:p>

From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Alberto Garc=EDa
Sent: Thursday, December = 10, 2009 6:00 PM
To: 'SAVI Mailing = List'
Subject: [savi] = SLAAC-SAVI and host address configuration

 

Hi,

Regarding to the SLAAC-SAVI mechanism proposed = so far (draft-ietf-savi-fcfs-02), I think that there are some caveats in the = behavior of SLAAC hosts when they are in the process of configuring their own = addresses (i.e. when the address of the host is still tentative). =

Suppose that a host has configured an address, = has a valid binding in a SAVI device, and then it restarts the network = configuration so the address is configured again, DAD is executed by sending a DAD = NSOL message, etc. (for example, the user powers down and up the host – = it happens all the time J). Suppose that while the host is performing DAD and the SAVI device was in = VALID state for this address, the lifetime timer expires in the SAVI device. = Current specification says that the SAVI device sends a DAD_NSOL message to the host, and = changes the state to TESTING_LIFETIME. But in this particular case (the host is = still configuring its address) the DAD_NSOL message stops address = configuration in the host (instead of generating a DAD_NADV). Current SAVI design assumes = that sending DAD_NSOL is in general side-effect free for hosts, while this is = not the case when the hosts are in the process of configuring its own = address.

Note that the same problem occurs when a host = is configuring its address and another host tries to use the same address = either in a validating port of the same SAVI device, or in another SAVI device: current specification assumes that the first host can answer to DAD_NSOL messages, while this is not the case if it is configuring its = address.

I think the solution for this is to create a WAIT_FOR_CONFIG state. If a host is in VALID, TESTING_TP, or TESTING_VP = state, and a DAD_NSOL is received from the port currently associated to the = binding, the SAVI device moves to this state and lifetime is set to LIFETIME. = While the SAVI device is in this state, messages from other hosts are not = considered (in particular, DAD_NSOL messages are not forwarded to the host configuring = its address). The state moves to VALID when the lifetime expires, or when = data packets are received from the current validating port (because in this = case we know the address configuration process has finished). The underlying supposition for this behavior is that if a host sends a DAD_NSOL message = from the port from which a binding exists, (a) the host is proving that it is = alive and (b) this host in this port is supposed to be more legitimate than = other hosts trying to use the address in other ports at the same time. = Therefore, the address configuration procedure for this host should be protected, as = well as the binding for it.

 

Do you think this makes = sense?

Regards,

Alberto

 

------=_NextPart_000_0053_01CA7F55.DD2CAA00-- From christian.vogt@ericsson.com Sun Dec 20 13:23:20 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BCAC3A67F2 for ; Sun, 20 Dec 2009 13:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 J282rUmKSDQb for ; Sun, 20 Dec 2009 13:23:19 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 682733A67E7 for ; Sun, 20 Dec 2009 13:23:19 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id nBKLNvN0023310 for ; Sun, 20 Dec 2009 15:23:57 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.164]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 20 Dec 2009 16:23:02 -0500 From: Christian Vogt To: SAVI Mailing List Date: Sun, 20 Dec 2009 16:22:51 -0500 Thread-Topic: [savi] Update of SAVI working group milestones Thread-Index: AcqBupy7KKZdoZVFQi2C+U/KFgX9ZQ== Message-ID: <09473E7E-315A-45FA-B4AD-0EB86EBD704F@ericsson.com> References: <5ABE43AE-4943-4326-AA94-44B84B477A4A@ericsson.com> In-Reply-To: <5ABE43AE-4943-4326-AA94-44B84B477A4A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [savi] Update of SAVI working group milestones X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2009 21:23:20 -0000 Folks - FYI, the milestones on our charter web page have been updated: http://www.ietf.org/dyn/wg/charter/savi-charter.html - Christian On Dec 3, 2009, Christian Vogt wrote: > All - > > I would like to make updates to the SAVI working group milestones to > include the new DHCP solution document and the new, though yet-to-be- > selected framework document, as well as to reflect the past delay of > the group. Below is a suggestion of how the new milestones should > look like. If you see an issue with these, please speak up. > > - Christian > > > PROPOSED NEW MILESTONES > > Jul 2008 WG approval > > Aug 2008 First WG draft on threats > > Oct 2008 First WG draft on SLAAC solution > > Dec 2008 First WG draft on SeND solution > > Dec 2009 First WG draft on DHCP solution > > Dec 2009 First WG draft on protocol framework > > Mar 2010 First WG draft on solution for Ethernet-based broadband =20 > access networks > > Mar 2010 Submit document on threats to IESG for Informational RFC > > Dec 2010 Submit SLAAC solution to IESG for Proposed Standard > > Dec 2010 Submit SeND solution to IESG for Proposed Standard > > Dec 2010 Submit DHCP solution to IESG for Proposed Standard > > Dec 2010 Submit protocol framework to IESG for Informational RFC > > Dec 2010 Submit Ethernet-based broadband access network solution to =20 > IESG for Proposed Standard From christian.vogt@ericsson.com Tue Dec 22 10:06:29 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADB43A6A58 for ; Tue, 22 Dec 2009 10:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 RZd2jrmVQcd2 for ; Tue, 22 Dec 2009 10:06:28 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id CC2993A682E for ; Tue, 22 Dec 2009 10:06:28 -0800 (PST) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id DA7D3C6AFF; Tue, 22 Dec 2009 13:06:11 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 22 Dec 2009 13:06:11 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=wKXhdtrLx2OnsO3HvHnGbrbDTmE=; b=GL3epaOXNy4tdTNhnHkZMEl6vh/elOg3Oo1B2xgjA2i8JCEFWMuVmkredu63Xa8ZqVUm5dnGNVeTLIIxuRnIiGuyARk1Hn/qBAtS3QRKaiki1LrIMMfG8rMR6tKBvbcZpENQHZACMMHqOUOcfXd93cTwQqPrQZwcuN5AsA6A+PY= X-Sasl-enc: AfA1lb5akntllx0tXTiZTuZhtJTdS/AKSMRNq1J4/dDk 1261505171 Received: from [192.168.178.27] (koln-5d81978f.pool.mediaWays.net [93.129.151.143]) by mail.messagingengine.com (Postfix) with ESMTPSA id 38E064B963F; Tue, 22 Dec 2009 13:06:11 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Christian Vogt In-Reply-To: Date: Tue, 22 Dec 2009 19:06:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <002d01ca7982$b9f6f780$2de4e680$@tsinghua.edu.cn> To: =?iso-8859-1?Q?Alberto_Garc=EDa?= X-Mailer: Apple Mail (2.1075.2) Cc: 'SAVI Mailing List' , 'Guang Yao' Subject: Re: [savi] SLAAC-SAVI and host address configuration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 18:06:29 -0000 On Dec 10, 2009, Alberto Garc=EDa wrote: > But my question goes further: if the SAVI host receives a DAD_NSOL =20 > from > the port through which a binding exists, do we want to protect the > binding from other hosts sending DAD_NSOL messages? This is a good observation. But is this case really worth being dealt with separately? Keep in mind that one of this working group's high- level design goals is simplicity; it is OK not to have optimal behavior in all corner cases. In my opinion, this applies in particular to the case you are describing, since the vulnerability of hosts re-configuring their IP address already exists with regular SLAAC. - Christian From alberto@it.uc3m.es Wed Dec 23 07:09:02 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6E53A6881 for ; Wed, 23 Dec 2009 07:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.561 X-Spam-Level: X-Spam-Status: No, score=-4.561 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, 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 nVwtOIDxLb0r for ; Wed, 23 Dec 2009 07:09:01 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 551043A680B for ; Wed, 23 Dec 2009 07:09:01 -0800 (PST) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 4FFF77F40CB; Wed, 23 Dec 2009 16:08:43 +0100 (CET) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: "'Christian Vogt'" References: <002d01ca7982$b9f6f780$2de4e680$@tsinghua.edu.cn> Date: Wed, 23 Dec 2009 16:08:42 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcqDMXQ4FhWHbptBTNqvJItY/XCbPAArbHjw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17086.007 Cc: 'SAVI Mailing List' , 'Guang Yao' Subject: Re: [savi] SLAAC-SAVI and host address configuration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 15:09:02 -0000 Hi Christian, | -----Mensaje original----- | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En nombre de | Christian Vogt | Enviado el: martes, 22 de diciembre de 2009 19:06 | Para: Alberto Garc=EDa | CC: 'SAVI Mailing List'; 'Guang Yao' | Asunto: Re: [savi] SLAAC-SAVI and host address configuration | =20 | On Dec 10, 2009, Alberto Garc=EDa wrote: | =20 | > But my question goes further: if the SAVI host receives a DAD_NSOL | > from | > the port through which a binding exists, do we want to protect the | > binding from other hosts sending DAD_NSOL messages? | =20 | This is a good observation. But is this case really worth being = dealt | with separately? Keep in mind that one of this working group's high- | level design goals is simplicity; it is OK not to have optimal = behavior | in all corner cases. In my opinion, this applies in particular to = the | case you are describing, since the vulnerability of hosts = re-configuring | their IP address already exists with regular SLAAC. I assume we want to increase protection against vulnerabilities existing = in regular SLAAC (otherwise, we would not be defining SAVI).=20 Although, of course, I admit the addition of each particular feature is debatable.=20 The cost in implementation effort for this case is roughly increasing = one state the state machine (from 6 to 7 states -> around 15% of code, considering that in all states all events to consider are more or less = the same).=20 Considering the frequency of this event, it occurs naturally in "some" = cases (eg. when popular OS receive an OS update and ask you to reboot the = system, when it crashes, ...). Although I don't know if it occurs in so "many" = cases to justify its deployment.=20 Alberto | =20 | - Christian | =20 | =20 | _______________________________________________ | savi mailing list | savi@ietf.org | https://www.ietf.org/mailman/listinfo/savi From christian.vogt@ericsson.com Wed Dec 23 08:41:02 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27C33A6923 for ; Wed, 23 Dec 2009 08:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 rSOSR3DUs7z9 for ; Wed, 23 Dec 2009 08:41:01 -0800 (PST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by core3.amsl.com (Postfix) with ESMTP id C80713A68C4 for ; Wed, 23 Dec 2009 08:41:01 -0800 (PST) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id D76F0C75EB; Wed, 23 Dec 2009 11:40:44 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 23 Dec 2009 11:40:44 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=vea86PgRqE37T2Dsd7mMkOR1RvQ=; b=W8A/KujheU0PAPuZKC4gMCT6YX1h7tAp0DB8PmQgL+eHknw2y8ZCm2e9RUnwsSITHgzHiU34b6k5zL0OPiD7oQQX7MEJr1jnHygz7MzCcHSOJHgkb1nxroFn/LVxpNHTZBdE9gMV2/sJHELLGw5O7bfxk8mFfx1coem/1g9BUSs= X-Sasl-enc: feQQlKiGDbxWcn64f2lRmWOh0aS3zstFgmlMZjwygdZY 1261586444 Received: from [192.168.178.27] (koln-5d81aca1.pool.mediaWays.net [93.129.172.161]) by mail.messagingengine.com (Postfix) with ESMTPSA id 351964BAD21; Wed, 23 Dec 2009 11:40:44 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Christian Vogt In-Reply-To: Date: Wed, 23 Dec 2009 17:40:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <29AA6961-8B45-4386-9CA8-4095482E52D6@ericsson.com> References: <002d01ca7982$b9f6f780$2de4e680$@tsinghua.edu.cn> To: =?iso-8859-1?Q?Alberto_Garc=EDa?= X-Mailer: Apple Mail (2.1075.2) Cc: 'SAVI Mailing List' , 'Guang Yao' Subject: Re: [savi] SLAAC-SAVI and host address configuration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2009 16:41:03 -0000 On Dec 23, 2009, at 16:08, Alberto Garc=EDa wrote: > Considering the frequency of this event, it occurs naturally in "some" > cases (eg. when popular OS receive an OS update and ask you to reboot > the system, when it crashes, ...). Although I don't know if it =20 > occurs in > so "many" cases to justify its deployment. The extra state you are proposing would be of benefit for hosts with statically configured addresses, right? Other hosts wouldn't care which IP address they get after a reboot, so there is no need to protect an old IP address for those hosts during reboot. The question is hence how important we consider the case of hosts with statically configured addresses. What's your opinion? What do others think? - Christian From alberto@it.uc3m.es Tue Dec 29 03:22:07 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20BF43A6902 for ; Tue, 29 Dec 2009 03:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3, 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 IxNSwmxSgyJV for ; Tue, 29 Dec 2009 03:22:06 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 956E33A68D9 for ; Tue, 29 Dec 2009 03:22:04 -0800 (PST) X-uc3m-safe: yes Received: from bombo (81.60.177.195.dyn.user.ono.com [81.60.177.195]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id F3A9F6C285A; Tue, 29 Dec 2009 12:21:42 +0100 (CET) From: =?iso-8859-15?Q?Alberto_Garc=EDa?= To: "'Christian Vogt'" References: <002d01ca7982$b9f6f780$2de4e680$@tsinghua.edu.cn> <29AA6961-8B45-4386-9CA8-4095482E52D6@ericsson.com> Date: Tue, 29 Dec 2009 12:21:40 +0100 Message-ID: <5EC7F13703AF4F6092EBFE9AB1DC7B45@bombo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqD7q60KXu29HI7QA+wQE5z3xwHNgAAcNJQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <29AA6961-8B45-4386-9CA8-4095482E52D6@ericsson.com> X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17098.006 Cc: 'SAVI Mailing List' , 'Guang Yao' Subject: Re: [savi] SLAAC-SAVI and host address configuration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 11:22:07 -0000 Hi Christian, | -----Mensaje original----- | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En nombre de | Christian Vogt | Enviado el: mi=E9rcoles, 23 de diciembre de 2009 17:41 | Para: Alberto Garc=EDa | CC: 'SAVI Mailing List'; 'Guang Yao' | Asunto: Re: [savi] SLAAC-SAVI and host address configuration | =20 | On Dec 23, 2009, at 16:08, Alberto Garc=EDa wrote: | =20 | > Considering the frequency of this event, it occurs naturally in = "some" | > cases (eg. when popular OS receive an OS update and ask you to = reboot | > the system, when it crashes, ...). Although I don't know if it | > occurs in | > so "many" cases to justify its deployment. | =20 | The extra state you are proposing would be of benefit for hosts with | statically configured addresses, right? Other hosts wouldn't care = which | IP address they get after a reboot, so there is no need to protect an | old IP address for those hosts during reboot. First, one question: when you talk about "statically configured = addresses", are you referring also to SLAAC addresses? In the discussion above, I = think the benefit would be for any SLAAC-configured (RFC4862) address, since = it is not clear to me that the behavior of RFC4862 hosts is different to statically configured address when the address tried in the first time = (and maybe configured some time before) is used by other host when the node reboot. Although the solution for SLAAC hosts could be just to generate randomly a new address, it is not clear to me that SLAAC hosts do this. RFC4862 5.4.5 suggests "just disabling network operation on the = interface" (From my point of view, RFC4862 is a bit na=EFve by assuming that = duplicate address only come from layer-2 address duplication, and not from an = attack, but...). A Microsoft note (http://msdn.microsoft.com/en-us/library/aa917171.aspx) says "If = duplicate address detection fails, you must manually configure the node"...=20 It is not clear to me what other SLAACnimplementations do when an = address is already in use, but may be not try a completely new address.=20 (By the way, SEND has a more defined behavior for this case - try up to = 3 addresses by changing a field, and only accept secured responses for the last 2 tries.) However, I agree that conceptually there is not much difference between = a host that reboot shortly after being communicating and a host that = connects again much later. In the last case it is not easy to provide means to protect the address, so maybe it does not worth the effort to protect = the first case (even if we technically could). Regards, Alberto | =20 | The question is hence how important we consider the case of hosts = with | statically configured addresses. What's your opinion? What do = others | think? | =20 | - Christian | =20 | =20 | _______________________________________________ | savi mailing list | savi@ietf.org | https://www.ietf.org/mailman/listinfo/savi From christian.vogt@ericsson.com Tue Dec 29 06:00:38 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60CC63A69A1 for ; Tue, 29 Dec 2009 06:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 l5nQ9hFmWgBc for ; Tue, 29 Dec 2009 06:00:37 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 8E36B3A680C for ; Tue, 29 Dec 2009 06:00:37 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id nBTE1V6n009748; Tue, 29 Dec 2009 08:01:32 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.164]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 29 Dec 2009 09:00:13 -0500 From: Christian Vogt To: =?iso-8859-1?Q?Alberto_Garc=EDa?= Date: Tue, 29 Dec 2009 09:00:05 -0500 Thread-Topic: [savi] SLAAC-SAVI and host address configuration Thread-Index: AcqIjz1/DQ8WPxfYRfi73Y5e8ewK8A== Message-ID: References: <002d01ca7982$b9f6f780$2de4e680$@tsinghua.edu.cn> <29AA6961-8B45-4386-9CA8-4095482E52D6@ericsson.com> <5EC7F13703AF4F6092EBFE9AB1DC7B45@bombo> In-Reply-To: <5EC7F13703AF4F6092EBFE9AB1DC7B45@bombo> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SAVI Mailing List , Guang Yao Subject: Re: [savi] SLAAC-SAVI and host address configuration X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2009 14:00:38 -0000 Hi Alberto - >> The extra state you are proposing would be of benefit for hosts with >> statically configured addresses, right? Other hosts wouldn't care =20 >> which >> IP address they get after a reboot, so there is no need to protect an >> old IP address for those hosts during reboot. > > First, one question: when you talk about "statically configured > addresses", are you referring also to SLAAC addresses? In the =20 > discussion > above, I think the benefit would be for any SLAAC-configured (RFC4862) > address [...] I agree with you that your proposal would affect any SLAAC-configured IP address. But my point was that your proposal has real value only for manually pre-configured IP addresses. For these IP addresses, a DAD collision is harmful because it breaks the pre-configuration. For other IP addresses, a DAD collision is not harmful: They can be replaced without breaking a pre-configuration and, after a reboot, there are also no active sessions that would break due to the IP address change. Does this make sense? This said, I take you point that a DAD collision can cause hosts to be unable to communicate: > Although the solution for SLAAC hosts could be just to generate =20 > randomly > a new address, it is not clear to me that SLAAC hosts do this. RFC4862 > 5.4.5 suggests "just disabling network operation on the interface" But keep in mind that your proposal doesn't fully solve this problem: If you reserve the IP address for the original owner, then the other host trying to configure this IP address is screwed. If you don't reserve the IP address, the original owner is screwed. In fact, one would need to augment SLAAC with better DAD collision recovery mechanisms in order to solve this problem fully. And perhaps this is something we should propose to the 6man working group? Thoughts? - Christian