From fx.lebail@yahoo.com Mon Oct 3 01:49:39 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD6921F8AF8 for ; Mon, 3 Oct 2011 01:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.227 X-Spam-Level: X-Spam-Status: No, score=0.227 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX5zYi4gh0mH for ; Mon, 3 Oct 2011 01:49:38 -0700 (PDT) Received: from nm12-vm0.bullet.mail.ne1.yahoo.com (nm12-vm0.bullet.mail.ne1.yahoo.com [98.138.91.51]) by ietfa.amsl.com (Postfix) with SMTP id AA4F121F8AF5 for ; Mon, 3 Oct 2011 01:49:38 -0700 (PDT) Received: from [98.138.90.53] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 08:52:37 -0000 Received: from [98.138.89.199] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 08:52:37 -0000 Received: from [127.0.0.1] by omp1057.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 08:52:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 990788.81253.bm@omp1057.mail.ne1.yahoo.com Received: (qmail 68923 invoked by uid 60001); 3 Oct 2011 08:52:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1317631956; bh=kSXnPLIwEtn26O7ED7PqjI+X0BqsWr3X2RGG4oNyzR8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pPs2Wmhvkx1WDUKSiFKt6hRdShlpq6AiNnDB6LyxjyogjypLvZiYywDRUVY52Y917Q/smuoM/Vka3C4BDcW4fg1Z8f0hiVuJsENqh2HtGjRNzw1exltOW5IKUI2E/s0lnCZEBGcXW7KIf+w/y0Z+ttqdS+rbcbSpqfo3zlqCMIk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LOy2bDRtGNdk8qlAC199OVPHqVkEicVVRrgGToy6uhsKJu0VhD1SKmQcicm8lvfdXqVEPaWaJ2LU0clPfjkFiATBNR/kcWzSMdUksEsgmDNwX++XQavXIqWRTwrJ/prsD6G9vzaChRryhS74/EDYdZYqK/f5OpQ8S6TS0xRuHBk=; X-YMail-OSG: 3HLJiVEVM1mllmhmZNMKGTyLEAjXln1MNij7W_FbV2yyGU7 sMMf1Fe3LZN5v7oCLhBuhGHzUf0kG_pLjD.JmTp5immr744IXsqn2aLnxSB. zfWF2HJDBbKTiNNpX7hUiiX4IARDUxQNEP836FK1iqgQoSr7BIOdZ2q115PI cHCZdWMAtDhdbzXEESYRG1iLls3lysD53.3Lr7mftUy7vxQHmSoS811eV9uI VGFXVqmDT7FuDBrycrog9nXKF.tbL5DetL0mFHQ.93_s7KAP3WHMDB0P4_j_ Bok0s95MGMycULcpZF7uQRqRauxTYTDvK.ehO2HzDJ2AB_MaADIksXmZ1IrL 9D8lJG5RvGzMwnscCx7AK1rFNgfTdzsruE8famzqctINbPJzV5Rz56onn.cU OP8CN7EvkaP783TmZ_0KkqD80dfNVm6J40hp0cwcF3IUEurfma..xmgjmuAX LB7FIfT4FBDdZpcfJ4ZgXc9Iep.O.ImKFK1gj6c16FZvS8bmh4TgRiuweyg- - Received: from [193.49.124.107] by web126009.mail.ne1.yahoo.com via HTTP; Mon, 03 Oct 2011 01:52:36 PDT X-Mailer: YahooMailClassic/14.0.7 YahooMailWebService/0.8.114.317681 Message-ID: <1317631956.68419.YahooMailClassic@web126009.mail.ne1.yahoo.com> Date: Mon, 3 Oct 2011 01:52:36 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= Subject: Re: Question about Subnet-Router anycast address To: Ole Troan MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 08:49:39 -0000 Ole,=0A=0A> > I try to ping some routers on one of their=0A> Subnet-Router = anycast addresses (SRAA).=0A> > (http://tools.ietf.org/html/rfc4291#section= -2.6.1)=0A> > =0A> > Some (Cisco) reply with an unicast source address=0A> = (same subnet prefix).=0A> > Another one (Alcatel) reply with the SRAA as so= urce=0A> address.=0A> > A Linux kernel in IPv6 forwarding mode behave like = the=0A> Cisco router.=0A> > =0A> > The RFC 4291 removed the restrictions on= using IPv6=0A> anycast addresses, so a SRAA may be used as a source=0A> ad= dress.=0A> > =0A> > Is there an RFC which describe the reply source=0A> add= ress that must be used ?=0A> =0A> not as far as I know. the closest we have= is probably http://tools.ietf.org/html/draft-itojun-ipv6-anycast-analysis-= 02=0A=0AThanks for the link.=0AThis draft refers RFC 2373 that prohibited t= he use of anycast as source address. It's no more the case in RFC 4291.=0A= =0A> 6rd is one of the few applications using the Subnet router=0A> anycast= . we thought it useful for troubleshooting and then=0A> particularly as a w= ay to identify BR if the reply was the=0A> BR's unicast address instead of = the anycast. your mileage=0A> may vary.=0A=0AIf the source address of reply= differs from destination address of the request, some applications are bro= ken.=0A=0AThanks,=0AFran=E7ois-Xavier=0A From fx.lebail@yahoo.com Mon Oct 3 01:57:42 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C5621F8ACE for ; Mon, 3 Oct 2011 01:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSuh+wa84itf for ; Mon, 3 Oct 2011 01:57:41 -0700 (PDT) Received: from nm33-vm7.bullet.mail.ne1.yahoo.com (nm33-vm7.bullet.mail.ne1.yahoo.com [98.138.229.71]) by ietfa.amsl.com (Postfix) with SMTP id 7F18221F88A0 for ; Mon, 3 Oct 2011 01:57:41 -0700 (PDT) Received: from [98.138.90.55] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 09:00:38 -0000 Received: from [98.138.89.161] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 09:00:38 -0000 Received: from [127.0.0.1] by omp1017.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 09:00:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 223502.88259.bm@omp1017.mail.ne1.yahoo.com Received: (qmail 98584 invoked by uid 60001); 3 Oct 2011 09:00:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1317632438; bh=/o9mErFTReEtWhwLgttQV6Gx65PLFlul6rpWRsr240A=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GWgraWhBtfyqtNLJoKUKmn4mcybf6eeYvDMcYahqRXz9tHKPP8J2ZBVX/VqYn1E3ivgW+V2Kl0jg2yTUUXfcPqtjSQ1ECnIdKIVeym4N34q1iyxVZ5gHsUVTzOXwz9FN4YlSvs8nAoKwd2XoiEofovs4YnL86aa2AHbicK+HoXE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WHtDP7fuleOdEhzptLWCTvKHgHD9qkBZaf1oGpERI1rycFXVzGW2sz0EWlTMYr1AfiCW65fTLeFlats3RfBneWtLfq0L90J7a0fa+Q1p9mOSEl+J3hfJOCSxi7EdX/7dOgPWXMy8wU7/O6JAZ/shYJ66g3Ljdvn4btNNi2sPvO4=; X-YMail-OSG: AOJi38kVM1nNHXF3me0qqYd.Y9pG3QtmiWzPoE0nX6I087n dlJR1xsTGDxEz2a9bKZ0B3VuDkoD1vT6TuPEDxCQtjBWkorRXkyWazeA52xl f6pPV9tW.9soUNKTrp6y8Wj9a6Cu7Uwb9Tm4V0rtkVrHpcGdQKf2Jrz6y5I_ _Ij.z.s9q7XhNHzkCPP9rY_HL_klrpncyrtyjNm.RPDPGz6n9lAdPoXSFnDG T5.dV72goQYFeqqrMWYwTsu3b6xw12evgA_AvizKef4978_F4lyQktcZKhFE DO92S4ugQHG39mbw85lYTmbwPbZzqDPL7A7F3aNmlWmgriO9GuyplBvryUBk kwpsJSrZDHU9Tj1DJ5TjtyBD5fYn436Wha3oL5atLcYO45DyUpgcCEtjQ7mz lBlgoXULdyfAywp6I7sxeEwrI6dBucftsG8YjEpMss4JoiyewtfdOVWwyCMg PbO7_HZfcOBiuJ5hXE2sZPgoVfZZxui5UZIMOR7x9RjGSNTOXC4JLxPaEY_p 2yZBUE4xuIsdVkvcfWEb. Received: from [193.49.124.107] by web126002.mail.ne1.yahoo.com via HTTP; Mon, 03 Oct 2011 02:00:38 PDT X-Mailer: YahooMailClassic/14.0.7 YahooMailWebService/0.8.114.317681 Message-ID: <1317632438.97682.YahooMailClassic@web126002.mail.ne1.yahoo.com> Date: Mon, 3 Oct 2011 02:00:38 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= Subject: Re: Question about RFC 3484 To: Ole Troan In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 08:57:42 -0000 Ole,=0A=0A> > Section 4 of RFC 3484 states:=0A> >=A0 =A0=A0=A0(http://tools= .ietf.org/html/rfc3484#section-4)=0A> >=A0 =A0=A0=A04. Candidate Source Add= resses=0A> >=A0 =A0=A0=A0[. . .]=0A> >=A0 =A0 =A0 =A0 In any case, anycast= =0A> addresses, multicast addresses, and the=0A> >=A0 =A0 =A0 =A0 unspecifi= ed address MUST=0A> NOT be included in a candidate set.=0A> > =0A> > Are a = reply to an UDP datagram or ICMPv6 (e.g. ping)=0A> concerned ? =0A> > =0A> = > If yes, what is the rationale for not including an=0A> anycast address ?= =0A> =0A> because in the general case unaware applications do not=0A> work = with anycast.=0A=0ARFC 3484 states:=0A"It is desirable to have default algo= rithms, common across all =0Aimplementations, for selecting source and dest= ination addresses=0Aso that developers and administrators can reason about = and=0Apredict the behavior of their systems."=0A=0ASo the algorithms must t= ake into account the anycast addresses in replies.=0A=0AThanks,=0AFran=E7oi= s-Xavier From fx.lebail@yahoo.com Mon Oct 3 02:29:58 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FF921F8B0F for ; Mon, 3 Oct 2011 02:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA8PUfSSzmkP for ; Mon, 3 Oct 2011 02:29:57 -0700 (PDT) Received: from nm13.bullet.mail.ne1.yahoo.com (nm13.bullet.mail.ne1.yahoo.com [98.138.90.76]) by ietfa.amsl.com (Postfix) with SMTP id B729821F8B0C for ; Mon, 3 Oct 2011 02:29:57 -0700 (PDT) Received: from [98.138.90.51] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 09:32:56 -0000 Received: from [98.138.89.246] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 09:32:56 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 09:32:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 522091.6020.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 97683 invoked by uid 60001); 3 Oct 2011 09:32:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1317634376; bh=/uEmizefzg+o56u6m2RrMxWe2HXNel28V7X7EGWJl3U=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pqNt/GRpiErbOW2B5BE2XAFYl3WFvZ01DXZdfUbGevbKMRY0xgiCNlgRYgv2eUGtYXCEWbZMFs0vsqi5OawKD1UYnnlyaSK5BxB39zBNb0hZV5OlYIv9D8Hah6JfYTlC5m6bd3b32sKwLP4ntRBuT3vW6NkLakO7StxvVm5+GNI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ijxzgL8ifL7dGoDYgqAN8r/1Cu7saSN6rrhhB8sJVINL3OZRlpzNvyfhPT8VVhNGQ9hFSV9IL2Lsw4YoXS6dGdhgZBpGdkMezPbxvv76B6YFq/aSQtOi7YJzih0l2ZkdKpFZqxuCLV2gUnS/OL8GSQLkhXMwpS7oC5YrR8ak41E=; X-YMail-OSG: 89dZZC4VM1kb.Su2xD_J_8hWSvPfJ4Yrct6cGo2ecVgbksS I2kmS1X5h23mlDBtB8CBkTtaJfm2wcsrn1AEl.SrnDUOp4TU_wd7fLsRrtmu ZG5Ajpl6WiuhJrj6bvxGdR0xI1xYfR.XoS2CINv759QJR.c4OZFNJWCNF0MT BHlqtzw480o.gZmWMXGdZB4KIcSnC3z9tZZjjtsEj4lF_gUMRtcvoEdUCPLM J9DqyiOkAz3NmAALnVEcl95prhzy2YpUm9nS3_gSOMh3oXaEcKp_iaCqHurb eFDutR3tqT.nZ.tDA6LgKJO_7v11nPTIZ3HrkTeelMnMDmeD4gg1CppN74BF NDuEw0bcBCzbZIRIS1PeTiNxfzkwaCvnv01NvYBmrPgG6T6iwc51EMnAE58h luBKiC3vSpbcFjGXZsLeCMKVbE9MxIXAj6P0gaYiXqIPVmg-- Received: from [193.49.124.107] by web126013.mail.ne1.yahoo.com via HTTP; Mon, 03 Oct 2011 02:32:55 PDT X-Mailer: YahooMailClassic/14.0.7 YahooMailWebService/0.8.114.317681 Message-ID: <1317634375.95246.YahooMailClassic@web126013.mail.ne1.yahoo.com> Date: Mon, 3 Oct 2011 02:32:55 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= Subject: Re: Question about RFC 3484 To: Brian E Carpenter MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 09:29:58 -0000 Brian=0A=0A> > So, if the RFC 3484, Section 4 "Candidate Source=0A> Address= es" is involved in=0A> > the reply to datagrams sent to an anycast address,= it=0A> might be useful to=0A> > reassess the restrictions that excluded an= anycast=0A> address from the "candidate set", at least for the replies.=0A= > =0A> You would need to start a thread proposing a specific=0A> change to= =0A> draft-ietf-6man-rfc3484-revise if you want this to be=0A> done.=0A> = =0A> I'm not convinced; as Ole said, anycast remains a special=0A> case=0A>= for certain applications, so it will be hard to define a=0A> safe general = rule.=0A=0AI would agree, but the goal of the RFC 3484 is to "predict the b= ehavior=0Aof the systems" and we see that actual behaviour on routers with = SRAA is=0Aimplementations dependant, because the RFC 4291 allows a reply wi= th an=0Aanycast address as source and the RFC 3484 forbids it.=0A=0AThanks,= =0AFran=E7ois-Xavier=0A=0A=0A=0AThanks,=0AFran=E7ois-Xavier=0A From fx.lebail@yahoo.com Mon Oct 3 05:34:49 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1D121F8B0B for ; Mon, 3 Oct 2011 05:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.255 X-Spam-Level: X-Spam-Status: No, score=0.255 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqkt2xuz9REv for ; Mon, 3 Oct 2011 05:34:49 -0700 (PDT) Received: from nm32-vm4.bullet.mail.ne1.yahoo.com (nm32-vm4.bullet.mail.ne1.yahoo.com [98.138.229.52]) by ietfa.amsl.com (Postfix) with SMTP id B7D9921F8AF7 for ; Mon, 3 Oct 2011 05:34:48 -0700 (PDT) Received: from [98.138.90.51] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 12:37:47 -0000 Received: from [98.138.88.235] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 12:37:47 -0000 Received: from [127.0.0.1] by omp1035.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 12:37:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 48703.22835.bm@omp1035.mail.ne1.yahoo.com Received: (qmail 88578 invoked by uid 60001); 3 Oct 2011 12:37:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1317645466; bh=5CoPywZ3xiOuIuobjOQuNqPJtXUvTFwGYV6tYvY7tt8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WRt5Sc0foRQc58fW9QMQCxwgJPo/PvjRL+ZZ1b5SgNFhZUMdC/i0oZI5bR89qZ0AtMfXuTsrvqEoFfsoGKowcdzh1izlgf4ZUG2HTgSEPGMUFyK37HW9rNMljPAwI+N8lNEY5E2p5ayhsYBD8Ku//ZKEH8ZDr60Xl/aljZ6+L0U= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=039s22sdKR+SS8EL1taaicpTYdQeqt1VNbIluhzhrY4kHlCWIkgFYk0MqCtylfv6Ed73J5d3+EKo6kq+BQLLEtISLLHNutCHdeu4+ibL1mPLARC33o4KzXpf2xG89Y4c8lnmrW6+Jloi2of6XzIiROqsRy33YT79FmUnDdpmXtY=; X-YMail-OSG: W9q85XYVM1mAbfvb5sGBZzchVO6OmyqyWexoxX22mLrOZIg mqMghc55USUEvTT4_ATaV_z_5okFlI7Drp6AlScY.61EjOzeEPQt9MgQcwvw s5SyaQl6JSUpySwL7NslwB8fhOyjlVoXlOLGPIHX3yjYtL9_kxIpxxEa_2cd UogdImkzMCYWqXrlJk2y0duqqugxnwvDGb5hnB0PwyRZ07CznGtaszA0MLki soTICCly7uc.cT1QKi34shPvFfOr2i_iOgHfNGbqjSnTa5n1pxJpBLyDJFrF coeadH49hlF9Lb5i8W0OztKFGamKosbbY1RB1UGXYQ9eKxx.newDUacuUL5e febXnxxO0q4VsSacOFE4Ya5lSbdXhJWKgd.X0lQBrGC.79Yygltz7vJLQi6g bHlQ7XemAVqv_1sHthYSd4xJX8awoC4ernRif2ss4AzukwgDpEuWoIac_mgn 05aiXeelI Received: from [193.49.124.107] by web126007.mail.ne1.yahoo.com via HTTP; Mon, 03 Oct 2011 05:37:46 PDT X-Mailer: YahooMailClassic/14.0.7 YahooMailWebService/0.8.114.317681 Message-ID: <1317645466.78614.YahooMailClassic@web126007.mail.ne1.yahoo.com> Date: Mon, 3 Oct 2011 05:37:46 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= Subject: Re: Question about RFC 3484 To: Brian E Carpenter , Mark Andrews In-Reply-To: <20110929011301.19ED1144D680@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 12:34:49 -0000 Mark,=0A=0A> Brian E Carpenter writes:=0A> > On 2011-09-28 21:42, Fran=E7oi= s-Xavier Le Bail wrote:=0A> > > =0A> > > So, if the RFC 3484, Section 4 "Ca= ndidate Source=0A> > > Addresses" is involved in the reply to datagrams sen= t=0A> > > to an anycast address, it might be useful to reassess the=0A> > >= restrictions that excluded an anycast address from the=0A> > > "candidate = set", at least for the replies.=0A> > =0A> > You would need to start a thre= ad proposing a specific change to=0A> > draft-ietf-6man-rfc3484-revise if y= ou want this to be done.=0A> > =0A> > I'm not convinced; as Ole said, anyca= st remains a special case=0A> > for certain applications, so it will be har= d to define =0A> > a safe general rule.=0A> >=A0 =A0 Brian=0A>=0A> Just for= reference, in the last week, there was a compliant=0A> in bind-users that = we were rejecting replies to queries sent=0A> to the all routers IPv6 anyca= st address because the source address=0A> of the reply did not match the de= stination address of the=0A> query.=A0 The anycast address can be used as s= ource address relatively=0A> safely, even for TCP, if you constrain the pac= kets to be fragmented=0A> at network MTU and to also include a fragment hea= der in case=0A> they are going through a IPv4/IPv6 translator.=A0 With anyc= ast=0A> you don't want to trigger PMTU discovery.=0A> =0A> Mark=0A=0AThanks= , another argument for a reply with an anycast address is given in=0ARFC 49= 42:=0A2.1.6. Anycast Traffic Identification and Security=0A[. . .]=0A To = avoid exposing knowledge about the internal structure of the=0A network, = it is recommended that anycast servers now take advantage of=0A the abili= ty to return responses with the anycast address as the=0A source address = if possible.=0A=0AFran=E7ois-Xavier From narten@us.ibm.com Mon Oct 3 06:24:34 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9435721F8509 for ; Mon, 3 Oct 2011 06:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.356 X-Spam-Level: X-Spam-Status: No, score=-106.356 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6s0jnSnn8+Nf for ; Mon, 3 Oct 2011 06:24:34 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id EADA421F84A5 for ; Mon, 3 Oct 2011 06:24:33 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p93D4GxV016770 for ; Mon, 3 Oct 2011 09:04:16 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p93DJJ78082106 for ; Mon, 3 Oct 2011 09:19:19 -0400 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p93DJB3o011435 for ; Mon, 3 Oct 2011 07:19:14 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-230-151.mts.ibm.com [9.65.230.151]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p93DJ4IR008965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Oct 2011 07:19:05 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p93DIkVu030701; Mon, 3 Oct 2011 09:18:47 -0400 Message-Id: <201110031318.p93DIkVu030701@cichlid.raleigh.ibm.com> To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= Subject: Re: Question about Subnet-Router anycast address In-reply-to: <1317631956.68419.YahooMailClassic@web126009.mail.ne1.yahoo.com> References: <1317631956.68419.YahooMailClassic@web126009.mail.ne1.yahoo.com> Comments: In-reply-to =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= message dated "Mon, 03 Oct 2011 01:52:36 -0700." Date: Mon, 03 Oct 2011 09:18:46 -0400 From: Thomas Narten Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 13:24:34 -0000 =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= writes: > If the source address of reply differs from destination address of > the request, some applications are broken. If you are saying that applications should ignore the src address (in case it is anycast) when accpting replies, I very strongly disagree. The norm is (and has been forever) to require that the source address in a response (whether TCP or UDP) match the destination address in the original query. And for good reason. Thomas From fx.lebail@yahoo.com Mon Oct 3 07:06:00 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83E721F8B47 for ; Mon, 3 Oct 2011 07:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.26 X-Spam-Level: X-Spam-Status: No, score=0.26 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlf+BQaeELhB for ; Mon, 3 Oct 2011 07:06:00 -0700 (PDT) Received: from nm4-vm0.bullet.mail.ne1.yahoo.com (nm4-vm0.bullet.mail.ne1.yahoo.com [98.138.90.253]) by ietfa.amsl.com (Postfix) with SMTP id 54B7121F8AD8 for ; Mon, 3 Oct 2011 07:06:00 -0700 (PDT) Received: from [98.138.90.53] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 14:08:57 -0000 Received: from [98.138.89.170] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 14:08:57 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 03 Oct 2011 14:08:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 306334.21608.bm@omp1026.mail.ne1.yahoo.com Received: (qmail 98309 invoked by uid 60001); 3 Oct 2011 14:08:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1317650937; bh=LpgJyGAjvaDf1QKrHtTh1UTuPG05ylbXF8N8LIJv0O4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=B9xNgAvga4phmqrT/pKpTUsQlVmRHjaHQvAXKViSJflG+X7fjtOUSL8j8YgilDQmU3PzTUovjGljnLC8dvOUUW3k+3QgH9B4H1GEY3Tu8EhZN1kWfdO6UIe8SIOqCAkxY7vrsLsDpofrIOuphTnAiNLzJFuqnM0bYiORD9ynflk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xxqOLdJFHp17LUFkE+qCJZm96iO9/EYvMVFCn9TlczfF4zBBwUHLvB15AemqL0sQFPO8MKJaOvrKDOHHKEQSWtjMd/Vcf7K80TnkVG8/i9YRLLcqaI0Q6qPtbw1VZa8kUv8UkyQN5+hTrOEh8H5UxBb0UKpmiBa5NpZVfroTo9g=; X-YMail-OSG: qBWRaqgVM1khH85AAPqgOEnsXNHptaIXHzYrYKuyf0UIaBD 5yqJAO2ZrdU0Bh1Pw_w1WB7AarirS9pmUe0n833VjA0DgYQ2Spp9U.MJG_mo _KasAD6XRtwsM2c0wNalCsRyHky4H3XDXy1Q_pxLmHOomBDDJX7VwrVIbjT1 PiKm8.4UuOP3o6B1hESReAJYLshDJ5fVZGGxgqLfC0i0w_15cjhZ0_jKUzFM XQCRqtgRYIGvMiqqaLn1ii9xmYhiVgkUiUBmWECjmf_fjsyMVxvl4XG7lnj3 81P.h0fNic10H.a_LOV4rZ7dWkKQJzjWaJ.yDVXZXefQw.7QXwIHGSybkCKP a5nfYDR63spnsVAPzmyH_3flsokQ2AamSbyhl8hXo6IeTfTufZDJ3MZaaVH9 0p_ZHPCtSdBDsd75AULYAEsbnujYBn_qCXiLEn0akrkjSIbbB9y6i9p1.l0Z k4l64JvnZCWHUVH4qW3t_BDaY4VqMMtaTaYZghSf4qaEs6mlUnLq8muzKkg- - Received: from [193.49.124.107] by web126003.mail.ne1.yahoo.com via HTTP; Mon, 03 Oct 2011 07:08:57 PDT X-Mailer: YahooMailClassic/14.0.7 YahooMailWebService/0.8.114.317681 Message-ID: <1317650937.91291.YahooMailClassic@web126003.mail.ne1.yahoo.com> Date: Mon, 3 Oct 2011 07:08:57 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= Subject: Re: Question about Subnet-Router anycast address To: Thomas Narten MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 14:06:01 -0000 --- On Mon, 10/3/11, Thomas Narten wrote:=0A> writes:=0A> =0A> > If the source address of reply differs from= destination address of=0A> > the request, some applications are broken. = =0A> =0A> If you are saying that applications should ignore the src=0A> add= ress (in case it is anycast) when accpting replies, I very=0A> strongly dis= agree.=0A=0AI don't say that.=0A=0A> The norm is (and has been forever) to = require that the=0A> source address in a response (whether TCP or UDP) matc= h the destination=0A> address in the original query. And for good reason.= =0A=0ABut the RFC 3484, as I understand it, exclude anycast address from th= e =0Asource replies.=0A=0ASection 4 of RFC 3484 states:=0A=A0 =A0 (http://t= ools.ietf.org/html/rfc3484#section-4)=0A=A0 =A0 4. Candidate Source Address= es=0A=A0 =A0 [. . .]=0A=A0 =A0 =A0=A0=A0In any case, anycast addresses, mul= ticast addresses, and the=0A=A0 =A0 =A0=A0=A0unspecified address MUST NOT b= e included in a candidate set.=0A=0AIt might be useful to reassess this res= triction, at least for the replies.=0A=0AThanks,=0AFran=E7ois-Xavier From wesley.george@twcable.com Mon Oct 3 12:19:24 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC04E21F8DF2 for ; Mon, 3 Oct 2011 12:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIjywKi5S7MK for ; Mon, 3 Oct 2011 12:19:23 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 630AD21F8D44 for ; Mon, 3 Oct 2011 12:19:23 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,627,1309752000"; d="scan'208";a="266056881" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 Oct 2011 15:19:46 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 3 Oct 2011 15:22:25 -0400 From: "George, Wes" To: 6man Date: Mon, 3 Oct 2011 15:22:23 -0400 Subject: FW: New Version Notification for draft-george-6man-3627-historic-00.txt Thread-Topic: New Version Notification for draft-george-6man-3627-historic-00.txt Thread-Index: AcyCAUIVKVAL5D8GR827RSCz1LlArQAADNgg Message-ID: <34E4F50CAFA10349A41E0756550084FB105D6FBF@PRVPEXVS04.corp.twcable.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 19:19:24 -0000 QXQgSUVTRydzIHJlY29tbWVuZGF0aW9uIGFuZCB3aXRoIHRoZSBzdXBwb3J0IG9mIHRoZSBhdXRo b3JzIG9mIDM2MjcgYW5kIDYxNjQsIEkgcHV0IHRvZ2V0aGVyIGEgcXVpY2sgb25lLXBhZ2VyIG1h a2luZyAzNjI3IGhpc3RvcmljLiBJIHRoaW5rIHRoaXMgb25lIGNhbiBtb3ZlIHRocm91Z2ggcXVp Y2tseSwgYnV0IHNpbmNlIHRoZSBvdGhlciBkb2N1bWVudHMgd2VudCB0aHJvdWdoIDZtYW4sIEkg dGhvdWdodCBpdCBtYWRlIHNlbnNlIHRvIGFzayBmb3IgV0cgYWRvcHRpb24gb2YgdGhpcyBkb2N1 bWVudC4NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZ2VvcmdlLTZtYW4tMzYy Ny1oaXN0b3JpYy0wMA0KDQpUaGFua3MsDQoNCldlcyBHZW9yZ2UNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAwMywgMjAxMSAzOjE1 IFBNDQpUbzogR2VvcmdlLCBXZXMNCkNjOiBHZW9yZ2UsIFdlcw0KU3ViamVjdDogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1nZW9yZ2UtNm1hbi0zNjI3LWhpc3RvcmljLTAwLnR4 dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZ2VvcmdlLTZtYW4tMzYyNy1oaXN0b3Jp Yy0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBXZXNsZXkgR2Vvcmdl IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICBk cmFmdC1nZW9yZ2UtNm1hbi0zNjI3LWhpc3RvcmljDQpSZXZpc2lvbjogICAgICAgIDAwDQpUaXRs ZTogICAgICAgICAgIFJGQzM2MjcgdG8gSGlzdG9yaWMgc3RhdHVzDQpDcmVhdGlvbiBkYXRlOiAg IDIwMTEtMTAtMDMNCldHIElEOiAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1i ZXIgb2YgcGFnZXM6IDQNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IG1vdmVzIFJGQzM2 MjcgdG8gSElTVE9SSUMgc3RhdHVzLCBhcyBpdCBoYXMgYmVlbg0KICAgc3VwZXJzZWRlZCBieSBS RkM2MTY0Lg0KDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpUaGlzIEUtbWFpbCBhbmQg YW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9w cmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBv ciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRo aXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmll ZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlv biB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRv IHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5h bCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From jari.arkko@piuha.net Sat Oct 8 06:29:36 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F85E21F8B9F for ; Sat, 8 Oct 2011 06:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jKPga25VxFN for ; Sat, 8 Oct 2011 06:29:35 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5232021F8B9E for ; Sat, 8 Oct 2011 06:29:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 04A0B2D565; Sat, 8 Oct 2011 16:32:40 +0300 (EEST) 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 D4zJuZwqok-2; Sat, 8 Oct 2011 16:32:38 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9B1A32CE32; Sat, 8 Oct 2011 16:32:37 +0300 (EEST) Message-ID: <4E9050F4.6090309@piuha.net> Date: Sat, 08 Oct 2011 09:32:36 -0400 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Jonathan Hui Subject: Re: AD review of draft-ietf-6man-rpl-option References: <9AF35150-67E3-4947-8E34-862A6F1827EB@cisco.com> <4E614D68.90808@piuha.net> <393B51BF-579F-4A23-96A4-3CA228B95E24@cisco.com> In-Reply-To: <393B51BF-579F-4A23-96A4-3CA228B95E24@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 13:29:36 -0000 Jonathan, I think we have converged (one suggestion inline below though). Please submit the draft. > >>>>> Here are my comments in more detail: >>>>> >>>>>> Datagrams being forwarded within a RPL domain MUST include a RPL >>>>>> Option. For datagrams sourced within a RPL domain, the RPL Option >>>>>> MAHui,Y be included in the datagram itself. >>>>> I'm not sure I understand the difference or its motivation. Do you really mean that a packet might not have the option until it hits the first router? Or are you just talking about something that happens internally on a host, but on the wire all packets would still have the option? Also, since the tunnel (or something else) is used to include the option for datagrams sourced outside the RPL domain, wouldn't it be easier to just say this: >>>>> >>>>> "Datagrams sent between nodes within an RPL domain MUST include an RPL Option." >>>> Agree. >>>> >> OK > I spoke too quickly on the comment above. In fact, the RPL Option is not required when a RPL Source Route Header exists. With SRH, there is no potential for loops, so the RPL Option is not required. How about the following text? > > "Datagrams sent between nodes within a RPL domain MUST include a RPL Option or RPL Source Route Header. Datagrams MAY include both a RPL Option and a RPL Source Route Header." OK > >>>>>> For datagrams sourced >>>>>> outside a RPL domain, IPv6-in-IPv6 tunneling, as specified in >>>>>> [RFC2473] SHOULD be used to include a RPL Option. >>>>> This text should be aligned with whatever conclusion we will have for the issue that I raised with the other document. >>>> Agree. See my response to your other review. >>>> >> OK >> >>>>>> To help avoid IP-layer fragmentation, the RPL Option has a maximum >>>>>> size of RPL_OPTION_MAX_SIZE octets and links within a RPL domain >>>>>> SHOULD have a MTU of at least 1280 + 44 (outer IP header, Hop-by-Hop >>>>>> Option header, Option header) + RPL_OPTION_MAX_SIZE + (additional >>>>>> extension headers or options needed within RPL domain). >>>>>> >>>>> There's a same MTU issue here as in the other document. >>>> Agree. See my response to your other review. >>>> >> I have a text suggestion on the other thread now., > We will add the suggested text in the next revision. OK > >>>>>> The action taken by using the RPL Option and the potential set of >>>>>> sub-TLVs carried within the RPL Option MUST be specified by the RFC >>>>>> of the protocol that use that option. No TLVs are defined in this >>>>>> document. >>>>>> >>>>> I think you should define the behavior when a node encounters a sub-TLV that it does not recognize. E.g., ignore and move on to the next sub-TLV. Or do you want a stricter policy? In any case, for future extensions it will be necessary to know how they are treated by legacy RPL nodes. >>>> Yes, we need to define the behavior. I'm comfortable with specifying an skip-over-and-continue policy for unknown sub-TLVs. >>>> >> OK >> >>>>>> In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due >>>>>> to the added cost and complexity required to process and carry a >>>>>> datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers] describes >>>>>> how to avoid using IPv6-in-IPv6 tunneling in such specific cases and >>>>>> the risks involved. >>>>>> >>>>> Again, the same comments as in the other draft. Please delete this paragraph. >>>> Agree. >>>> >> OK >> >> >>>>>> For datagrams exiting the RPL domain, RPL Border Routers MUST remove >>>>>> the RPL Option from the datagram. If the RPL Option was included >>>>>> using tunneled mode and the RPL Border Router serves as the tunnel >>>>>> end-point, removing the outer IPv6 header serves to remove the RPL >>>>>> Option as well. Otherwise, the RPL Border Router assumes that the >>>>>> RPL Option was included using transport mode and MUST remove the RPL >>>>>> Option from the IPv6 Hop-by-Hop Option header. >>>>>> >>>>> The part about removing the RPL option even in a non-tunneled case relates to the issue of supporting that particular mode of operation. >>>>> >>>>> But in addition, I wonder if you should write the above text not in terms of packet modification operations but rather in terms of forwarding decision outcomes. Like this, for instance: >>>>> >>>>> "For datagrams destined to the RPL Border Router the router processes the packet in the usual way. For instance, if the RPL Option was included using tunneled mode and the RPL Border Router serves as the tunnel end-point, the router removes the outer IPv6 header, at the same removing the RPL Option as well. Datagrams destined elsewhere within the same RPL domain are forwarded to the right interface. Datagrams destined outside the RPL domain are dropped." >>>> The intent was to allow operation where a device within the RPL domain could source a packet destined outside the RPL domain and not use tunneling. In this case, we would like to simply remove the option at the border router rather than drop the packet. Do you see cases where removing the option is unacceptable? >>>> >> I don't know. >> >> But maybe it doesn't matter. If we don't have other alternative encapsulations than tunneling, the point is moot. And I'm not sure we do. The two drafts really only describe the tunneling case. Even if you source a packet from an RPL domain and want to send it to an outside destination, you'll still have to use both the routing header and the option, no? > I agree. As mentioned above, if the packet already includes a RPL routing header, it does not also need to include the RPL option. OK > >>>>>> 6. Usage of the RPL Option >>>>>> >>>>>> The RPL Option is only for use within a RPL domain. RPL routers MUST >>>>>> process and include the RPL Option when forwarding datagrams to other >>>>>> nodes within the RPL domain. Routers on the edge of a RPL domain >>>>>> MUST remove the RPL Option when forwarding datagrams to nodes outside >>>>>> the RPL domain. >>>>> What is it that this section says that is not already covered by sections 2 and 5: >>>>> >>>>> Sect 2: Datagrams being forwarded within a RPL domain MUST include a RPL Option. >>>>> >>>>> Sect 5: ... serves as the tunnel end-point, removing the outer IPv6 header serves to remove the RPL Option as well. Otherwise, the RPL Border Router assumes that the RPL Option was included using transport mode and MUST remove the RPL Option from the IPv6 Hop-by-Hop Option header. >>>> Agree. Will remove the redundant text. >>>> >> OK >> >>>>>> This option may be used to mount several potential attacks since >>>>>> routers may be flooded by bogus datagram containing the RPL option. >>>>>> It is thus RECOMMENDED for routers to implement a rate limiter for >>>>>> datagrams using the RPL Option. >>>>> Please open this up a bit. What specific danger does flooding by bogus datagrams and RPL options cause? What would be the default settings for the rate limiter? >>>> The option contains information that can affect the operation of RPL. For example, an inconsistent Rank value can cause a RPL router to reset its trickle timer. >>>> >>>> After some careful thought, I'm not sure specifying a default setting for a rate limiter is the best approach. Determining what is acceptable vs. unacceptable can vary greatly between different deployments and environments. But rather than rate limiting, how about the following: >>>> >>>> This option may be used to mount several potential attacks since >>>> routers may be flooded by bogus datagrams containing the RPL >>>> option. In particular, an inconsistent Rank value can cause a RPL >>>> router to reset its DIO Trickle timer. Thus, it is RECOMMENDED >>>> that a RPL router monitor triggers caused by receiving a RPL >>>> option and log conditions when the average rate is higher than >>>> expected. >>>> >> I like your description of the problem. But given the possibility of some DIO timer issues, wouldn't it be prudent to actually have some kind of rate limiting? Maybe not rate limiting of packets with this option, but rate limiting of packets causing a trigger to happen? > How about the following text? > > "In order to avoid any unacceptable impact on network operations, an implementation MAY allow a limit to be placed on the number of triggers caused by receiving a RPL option, and MAY allow a limit to be placed on the rate of messages sent by a specific neighbor. It MAY also allow logging an error or sending a notification when a rate threshold is reached." OK otherwise, but I would prefer to see a default for such a rate limit in the spec. That is, specify that by default such limit should be . > >>>>>> Opt Data Len: 8-bit field indicating the length of the option, in >>>>>> octets, excluding the Option Type and Opt Data Len fields. >>>>>> >>>>>> Down 'O': 1-bit flag as defined in Section 11 of >>>>>> [I-D.ietf-roll-rpl]. >>>>>> >>>>>> Rank-Error 'R': 1-bit flag as defined in Section 11 of >>>>>> [I-D.ietf-roll-rpl]. >>>>>> >>>>>> Forwarding-Error 'F': 1-bit flag as defined in Section 11 of >>>>>> [I-D.ietf-roll-rpl]. >>>>>> >>>>>> RPLInstanceID: 8-bit field as defined in Section 11 of >>>>>> [I-D.ietf-roll-rpl]. >>>>>> >>>>>> SenderRank: 16-bit field as defined in Section 11 of >>>>>> [I-D.ietf-roll-rpl]. >>>>>> >>>>>> Values within the RPL Option are expected to change en-route. >>>>> This specification needs to describe what the behavior of a router is with the content of the option. I think this is easy, you should just add to the end: "The processing shall follow the rules described in Section 11.2 of [roll-rpl]. >>>> Agree. >>>> >>>>> As an aside, the entire Section 11 is marked in roll-rpl as non-normative. I don't think that's actually right as far as 11.2 goes, because it contains tons of MUSTs and SHOULDs. Perhaps you want to fix that in AUTH48... >>>> Right. >>>> >> OK > Thanks. > > -- > Jonathan Hui > > From jari.arkko@piuha.net Sat Oct 8 06:39:04 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B9E21F8C19 for ; Sat, 8 Oct 2011 06:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWedPovcOlLj for ; Sat, 8 Oct 2011 06:39:03 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 907F821F87E2 for ; Sat, 8 Oct 2011 06:38:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8B6392D565; Sat, 8 Oct 2011 16:42:12 +0300 (EEST) 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 2ER9tbkNn1Cp; Sat, 8 Oct 2011 16:42:11 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id A3B752CE32; Sat, 8 Oct 2011 16:42:10 +0300 (EEST) Message-ID: <4E905331.9060800@piuha.net> Date: Sat, 08 Oct 2011 09:42:09 -0400 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Jonathan Hui Subject: Re: AD review of draft-ietf-6man-rpl-routing-header References: <4DF29EAA.1060103@piuha.net> <4E61485A.3050506@piuha.net> <6F298945-5A56-419C-9032-1F7D250487CA@cisco.com> In-Reply-To: <6F298945-5A56-419C-9032-1F7D250487CA@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List , draft-ietf-6man-rpl-routing-header@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 13:39:04 -0000 Jonathan, We have converged. Please make the changes and lets move the document forward. jari > Hi Jari, > > I think we are converging. If there are no other comments, we will update the draft based on your review. See below: > > On Sep 2, 2011, at 2:19 PM, Jari Arkko wrote: > >> Jonathan, >> >> Please see inline. If you agree with what I'm writing here you should just submit a new draft version and we can take it from there. But it might be that on some aspects we need further discussion. >> >>>>> links within a RPL domain SHOULD have >>>>> a MTU of at least 1280 + 40 (outer IP header) + SRH_MAX_SIZE (+ >>>>> additional extension headers or options needed within RPL domain) >>>>> octets. >>>>> >>>> I thought that 6LOWPAN was an important link layer for the application of RPL. Yet, RFC 4944 specifies a MTU of 1280 octets. The above requirement seems to be in contradiction with what is available on 6LOWPAN. Am I missing some extension of 6LOWPAN that changes the MTU, or some other link layer that is expected to be used with RPL? If I'm not missing anything, wouldn't this cause a problem? It would seem that either you cannot run RPL on 6LOWPAN, run 6LOWPAN on non standard MTU values (and we know MTU negotiation is difficult), or you have to change the expectations of other nodes in the IPv6 Internet about the minimum assured MTU. >>>> >>>> Please clarify/resolve/tell me what I am missing. >>> Yes, 6LoWPAN is one of the target link layers. I agree that this statement is problematic with strict adherence to RFC 4944. Note, however, that there are IEEE 802.15.4 variants (i.e. 802.15.4g) that support frame lengths up to 2KB. I'm not sure it would be wise to limit the capabilities of alternative IEEE 802.15.4 link technologies. >>> >>> I would propose to remove the cited statement. It is unnecessary given that the next revision of this draft will require tunneling. >> Ok. But it doesn't really remove the technical issue, which is a conflict two competing objectives (small MTU for efficiency and avoiding fragmentation due to header insertion). How about adding this text: >> >> "To avoid fragmentation, it is desirable to employ MTU sizes that allow for the header expansion, i.e., at least 1280 + 40 (outer IP header) + SRH_MAX_SIZE. Even so, to take advantage of this, the communicating endpoints need to be aware that they can not use the full MTU, through Path MTU discovery, for instance. The larger MTU size is unfortunately not available on all links, for instance on 6LOWPAN links the MTU is 1280 bytes. However, it is expected that much of the traffic on these types of networks consists of much smaller messages than the MTU anyway, so performance degradation through fragmentation would be limited." > I like this expanded text. It calls out important issues and provides useful insight. Will add it in the next revision. > >>>>> A common network configuration for a RPL domain is that all nodes >>>>> within a LLN share a common prefix. The SRH introduces the CmprI, >>>>> CmprE, and Pad fields to allow compaction of the Address[1..n] vector >>>>> when all entries share the same prefix as the IPv6 Destination >>>>> Address field of the packet carrying the SRH. >>>> So all segments are treated based on how many bytes they have in common with the destination address. But the destination address keeps changing as we go through the intermediate hops. Is it necessary to clarify that the comparison/shared prefix is with the final destination address, NOT the address that happens to be in the destination address field currently? >>> The intent really was to utilize the current IPv6 Destination value since all entries except the last will carry the same CmprI prefix bytes. Now, I can see there is an issue when we consider the final entry controlled by CmprE. The intent was that CmprE would only differ when operating in "transport mode" and the SRH would thus be removed according to Section 5 of the draft. >> OK >> >>>>> In very specific cases, IPv6-in-IPv6 tunneling may be undesirable due >>>>> to the added cost and complexity required to process and carry a >>>>> datagram with two IPv6 headers. [I-D.hui-6man-rpl-headers] describes >>>>> how to avoid using IPv6-in-IPv6 tunneling in such specific cases and >>>>> the risks involved. >>>>> >>>> This sounds like a recommendation to do something in a draft that has not been through the working group and approved as the something that is a sound practice. Unless the reference is normative, I think it is inappropriate to refer to an Internet draft in this manner. >>>> >>>> What I would recommend is to (1) change the "... SHOULD use IPv6-in-IPv6 tunneling ..." statement to a MUST in this draft, (2) remove the above text, and (3) make the corresponding changes to Section 5. Then we can take hui-6man-rpl-headers through the working group and provide a second, more light-weight approach that extends what we have RFC-to-be-draft-ietf-6man-rpl-routing-header. >>>> >>>> (FWIW, I think the problem begins when one adds the first byte to a packet somewhere along the route. It does not not matter so much how many bytes one adds, just the SRH or also the IP header. Most of the complications on MTUs and so one start at that point. In any case, SRHs may not be trivially small either. Assuming 64-bit prefix compression an SRH for 4 hops would be 40 bytes.) >>> In general, I agree with your concern. However, after re-reading the draft, do is it necessary to mandate a particular solution (i.e. RFC 2473)? Instead, how do you feel about the following modified text: >>> >>> To deliver a datagram, a router MAY specify a source route to reach >>> the destination using a SRH. There are two cases that determine how >>> to include an SRH with a datagram. >>> >>> 1. When the source node inserts an SRH, it may do so directly >>> within the datagram itself. >>> >>> 2. When an intermediate node inserts an SRH, it should do so in >>> a way that does not cause path MTU issues and ensures ICMP >>> errors caused by inserting the SRH return to the source of the >>> SRH rather than the original datagram. One such method is >>> IPv6-in-IPv6 tunneling [RFC 2473]. >> No, I don't think this will be sufficient. For one, we are writing specifications that should be complete and lead to interoperable solutions. We need to say what the implementations do. Secondly, I don't understand how the non-tunneling solution would deal with some of the fragmentation issues. In IPv6 we don't do fragmentation in routers on the path. Third, leaving any handwaving about other ways of doing the encap without full, WG-reviewed and accepted specification of that other way is not appropriate for a proposed standard RFC. >> >> I still recommend doing here what I suggested initially. > I understand the concern and agree with your reasoning. Will make this change in the next revision. > >>>>> If such addresses appear more than once and are separated by at least >>>>> one address not assigned to that router, the router MUST drop the >>>>> packet and SHOULD send an ICMP Parameter Problem, Code 0, to the >>>>> Source Address. >>>>> >>>> ... >>>> >>>>> else if 2 or more entries in Address[1..n] are assigned to >>>>> local interface and are separated by at least one >>>>> address not assigned to local interface { >>>>> discard the packet >>>>> } >>>>> >>>> The text and the code appear to disagree about whether to send an ICMP Parameter Problem message. Please align. I assume that an ICMP message is needed. >>> Agree. >> OK >> >>>>> Because this document specifies that SRH is only for use within a RPL >>>>> domain, such attacks cannot be mounted from outside the RPL domain. >>>>> As described in Section 5, RPL Border Routers MUST drop datagrams >>>>> entering or exiting the RPL domain that contain a SRH in the IPv6 >>>>> Extension headers. >>>>> >>>> This is good, and I think the security considerations are sufficient. However, I would be happier if the draft also recommended that by default, non-RPL routers and firewalls should drop packets with SRH. This would help ensure that SRH does not accidentally enter any network and expose some vulnerability. The practical effect that I'm looking for is, for instance, not having my Linux kernel process SRH unless I've configured it to use RPL. >>> Agree. >> OK >> >>>> Editorial: >>>> ====== >>>> >>>>> In the above scenario, datagrams traveling from source, S, to >>>>> destination, D, have the following packet structure: >>>>> >>>>> >>>>> +------+------+------+--------//-+ >>>>> | IPv6 | IPv6 | IPv6 | Packet | >>>>> | Src | Dst | SRH | Payload | >>>>> +------+------+------+--------//-+ >>>>> >>>> This figure is not as clear as it could be. Are the src and dst field referring to the IPv6 header fields? Would this picture be better if you showed the IPv6 header explicitly? Please clarify. >>> Yes, the src and dst fields are IPv6 header fields. Will update the figure to be more explicit. >> Good. >> >>>>> CmprE 4-bit unsigned integer. Number of prefix octets >>>>> from the segment that are elided. For example, a >>>>> SRH carrying a full IPv6 address in Addresses[n] >>>>> sets CmprE to 0. >>>>> >>>> I understood the definition CmprI, but I do not understand this, at least not at the point of the above text. What is "the segment" that you are referring to above? SRH carries multiple segments. Please clarify. >>>> >>>> Little further down it becomes clear that CmprE refers to the compression of the last segment. Please make this clear already in the above text. >>> Correct. Will clarify in the next revision. >> OK >> >>>> Comments relating to feedback from others: >>>> ============================ >>>> >>>> The ADs have received a question from Joseph Reddy, who was asking if the set of addresses in the SRH should also include the source address of the node inserting the SRH. His justification for this was the need to be able to send an ICMP error back to this node. Do we have an answer? >>> When using tunneling, the ICMP error should go back to the source of the outer IPv6 header. >> OK >> >>>> In April, Thomas Narten made some comments on the list and I didn't think that the discussion finished with any conclusion. Are his concerns (e.g., from his e-mail on April 29th) valid or not valid? I would like the working group to conclude this issue one way or the other. I refer to his comments regarding the feasibility of the loop check in particular. His e-mail is at http://www.ietf.org/mail-archive/web/ipv6/current/msg13887.html FWIW I agree with Thomas' editorial comment on Section 2 clarity. That should be easy to fix. >>> My personal belief is that LLN devices will generally have more computation capability relative to communication capability, so I'm not terribly concerned with the processing overhead. That said, I'm not a fan of the loop check and would prefer less complexity. We only required such checks to deal with security concerns that have been raised in the past with RH0. If others feel that the checks are unnecessary or have alternative suggestions, I'm more than happy to make the changes. >> The problem is that the concerns with RH0 are valid, so cecks (or at least some checks) are required, I think. One way to deal with this concern is to document the limitations of the RPL routing header, i.e., state upfront that it requires significant per-packet processing. Then the issue would at least not be a surprise to anyone. Thoughts? > I think it is reasonable to call out the costs up front. We will make this change in the next revision unless there are alternative ideas. > > Thanks. > > -- > Jonathan Hui > > From wesley.george@twcable.com Mon Oct 10 11:51:10 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22E221F8BA9 for ; Mon, 10 Oct 2011 11:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.814 X-Spam-Level: X-Spam-Status: No, score=0.814 tagged_above=-999 required=5 tests=[AWL=1.277, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7WTMI0j0f1E for ; Mon, 10 Oct 2011 11:51:10 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C500E21F8B9E for ; Mon, 10 Oct 2011 11:51:09 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,664,1309752000"; d="scan'208";a="268725816" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 10 Oct 2011 14:48:07 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 10 Oct 2011 14:51:08 -0400 From: "George, Wes" To: 6man Date: Mon, 10 Oct 2011 14:51:04 -0400 Subject: RE: New Version Notification for draft-george-6man-3627-historic-00.txt Thread-Topic: New Version Notification for draft-george-6man-3627-historic-00.txt Thread-Index: AcyCAUIVKVAL5D8GR827RSCz1LlArQAADNggAV5GOPA= Message-ID: <34E4F50CAFA10349A41E0756550084FB11D943A2@PRVPEXVS04.corp.twcable.com> References: <34E4F50CAFA10349A41E0756550084FB105D6FBF@PRVPEXVS04.corp.twcable.com> In-Reply-To: <34E4F50CAFA10349A41E0756550084FB105D6FBF@PRVPEXVS04.corp.twcable.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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 18:51:10 -0000 I've made some minor changes to the abstract at Bob Hinden's recommendation= , please review -01. http://tools.ietf.org/html/draft-george-6man-3627-historic-01 Chairs, can we proceed with calling WG adoption/WGLC? I don't see much need= for this to take up agenda time in Taipei, so I'd rather just move it alon= g on the list if possible. Thanks Wes -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Geo= rge, Wes Sent: Monday, October 03, 2011 3:22 PM To: 6man Subject: FW: New Version Notification for draft-george-6man-3627-historic-0= 0.txt At IESG's recommendation and with the support of the authors of 3627 and 61= 64, I put together a quick one-pager making 3627 historic. I think this one= can move through quickly, but since the other documents went through 6man,= I thought it made sense to ask for WG adoption of this document. http://tools.ietf.org/html/draft-george-6man-3627-historic-00 Thanks, Wes George -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, October 03, 2011 3:15 PM To: George, Wes Cc: George, Wes Subject: New Version Notification for draft-george-6man-3627-historic-00.tx= t A new version of I-D, draft-george-6man-3627-historic-00.txt has been succe= ssfully submitted by Wesley George and posted to the IETF repository. Filename: draft-george-6man-3627-historic Revision: 00 Title: RFC3627 to Historic status Creation date: 2011-10-03 WG ID: Individual Submission Number of pages: 4 Abstract: This document moves RFC3627 to HISTORIC status, as it has been superseded by RFC6164. The IETF Secretariat This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From arifumi@nttv6.net Mon Oct 10 19:58:56 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C0621F8CCB for ; Mon, 10 Oct 2011 19:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCh7DhA16SbE for ; Mon, 10 Oct 2011 19:58:55 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7F29221F8CC8 for ; Mon, 10 Oct 2011 19:58:55 -0700 (PDT) Received: from [IPv6:2001:fa8:1010::bc4b:7a10:9856:e422] ([IPv6:2001:fa8:1010:0:bc4b:7a10:9856:e422]) by leo.nttv6.net (8.14.4/8.14.4) with ESMTP id p9B2vQP6009845; Tue, 11 Oct 2011 11:57:27 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: Question about Subnet-Router anycast address Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Arifumi Matsumoto In-Reply-To: <1317650937.91291.YahooMailClassic@web126003.mail.ne1.yahoo.com> Date: Tue, 11 Oct 2011 12:02:52 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <733600C6-434C-4797-919E-002F86BDC710@nttv6.net> References: <1317650937.91291.YahooMailClassic@web126003.mail.ne1.yahoo.com> To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 02:58:56 -0000 Hi, On 2011/10/03, at 23:08, Fran=E7ois-Xavier Le Bail wrote: > --- On Mon, 10/3/11, Thomas Narten wrote: >> writes: >>=20 >>> If the source address of reply differs from destination address of >>> the request, some applications are broken.=20 >>=20 >> If you are saying that applications should ignore the src >> address (in case it is anycast) when accpting replies, I very >> strongly disagree. >=20 > I don't say that. >=20 >> The norm is (and has been forever) to require that the >> source address in a response (whether TCP or UDP) match the = destination >> address in the original query. And for good reason. >=20 > But the RFC 3484, as I understand it, exclude anycast address from the=20= > source replies. >=20 > Section 4 of RFC 3484 states: > (http://tools.ietf.org/html/rfc3484#section-4) > 4. Candidate Source Addresses > [. . .] > In any case, anycast addresses, multicast addresses, and the > unspecified address MUST NOT be included in a candidate set. >=20 > It might be useful to reassess this restriction, at least for the = replies. As in RFC 3484 section 2, these algorithms in RFC 3484 does not specify the rules for your case. It specifies the rules that are used when an application initiates a session and a destination address and a source address have to be chosen. It does not specify rules for selecting address for a returning packet. So, in my understanding, the only restriction for using an anycast source address was in RFC 3513. But, now that such a restriction was removed, RFC 3484 should also be updated to allow to select an anycast source address for a initiating session. -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From kerlyn2001@gmail.com Mon Oct 10 20:35:00 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3988B21F8CEE for ; Mon, 10 Oct 2011 20:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0rDGA6ZQlt3 for ; Mon, 10 Oct 2011 20:34:59 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4746421F8C76 for ; Mon, 10 Oct 2011 20:34:59 -0700 (PDT) Received: by iaby26 with SMTP id y26so9957671iab.31 for ; Mon, 10 Oct 2011 20:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=SAAn5NXzpT3Ic2huwCZMyqsK/H4VVJg2qYup2lwffeM=; b=ZJB/s8z7nU+q96Rfe4ovj7mxfVjo58CsC8/Qo0Kn4alHdFDEKqTrTVhW/3veNVYG6C 6VU5NntgCwaulIYgDDubgvCNwbgOFw/U0sO9WKMFnYPfouaPTXpTOo+pGqvLuo/9W0zb roDcXJitYEwciB9ZxpANkm5bhjJ+FSbNr6CdU= MIME-Version: 1.0 Received: by 10.42.189.6 with SMTP id dc6mr22370451icb.16.1318304098493; Mon, 10 Oct 2011 20:34:58 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.43.49.74 with HTTP; Mon, 10 Oct 2011 20:34:58 -0700 (PDT) In-Reply-To: <20111011032459.14911.91585.idtracker@ietfa.amsl.com> References: <20111011032459.14911.91585.idtracker@ietfa.amsl.com> Date: Mon, 10 Oct 2011 23:34:58 -0400 X-Google-Sender-Auth: Y784IuTof5iKC5_i5R8JWvVNm1k Message-ID: Subject: Fwd: New Version Notification for draft-lynn-6man-6lobac-02.txt From: Kerry Lynn To: 6man 6man Content-Type: multipart/alternative; boundary=20cf303ea6a47f256104aefd9744 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 03:35:00 -0000 --20cf303ea6a47f256104aefd9744 Content-Type: text/plain; charset=ISO-8859-1 Greetings, I would like to submit draft-lynn-6man-6lobac to 6man for consideration as a WG item. This I-D was originally presented in Quebec City and has now been updated to reflect comments from several IETF and industry reviewers. The corresponding BACnet change proposal to support IPv6 over MS/TP is currently in its first public review, which ends on 10/17/2011. This change proposal is available at https://osr.ashrae.org/default.aspx (click on Addendum an). In addition, I have received permission to make the relevant section (Clause 9) of the BACnet spec available to anyone who would like to see the base MS/TP specification. I look forward to your comments. Regards, -K- ---------- Forwarded message ---------- From: Date: Mon, Oct 10, 2011 at 11:24 PM Subject: New Version Notification for draft-lynn-6man-6lobac-02.txt To: kerlyn@ieee.org Cc: stuart.donaldson@honeywell.com, kerlyn@ieee.org, jerald.p.martocci@jci.com, cneilson@deltacontrols.com A new version of I-D, draft-lynn-6man-6lobac-02.txt has been successfully submitted by Kerry Lynn and posted to the IETF repository. Filename: draft-lynn-6man-6lobac Revision: 02 Title: Transmission of IPv6 over MS/TP Networks Creation date: 2011-10-10 WG ID: Individual Submission Number of pages: 14 Abstract: MS/TP (Master-Slave/Token-Passing) is a contention-free access method for the TIA-485-A physical layer that is used extensively in building automation networks. This document describes the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. The IETF Secretariat --20cf303ea6a47f256104aefd9744 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings,

I would like to submit=A0draft-lynn-6man-6lob= ac to 6man for consideration as
a WG item. =A0This I-D was origin= ally presented in Quebec City and has now
been updated=A0to refle= ct comments from several IETF and industry reviewers.

The corresponding BACnet change proposal to support IPv= 6 over MS/TP is
currently in its first public review, which ends = on 10/17/2011. =A0This change
proposal is available at=A0http= s://osr.ashrae.org/default.aspx=A0(click
on Addendum an).

In addition, I have received= permission to make the relevant section (Clause
9) of the BACnet= spec available to anyone who would like to see the base
MS/TP sp= ecification.

I look forward to your comments.

Regards, -K-

---------- Forward= ed message ----------
From: <internet-drafts@ie= tf.org>
Date: Mon, Oct 10, 2011 at 11:24 PM
Subject: New Version Notification fo= r draft-lynn-6man-6lobac-02.txt
To: k= erlyn@ieee.org
Cc: stuart.donaldson@honeywell.com, ker= lyn@ieee.org, jerald.p.mar= tocci@jci.com, cneilson@d= eltacontrols.com


A new version of I-D, draft-lynn-6man-6lobac-02.txt has been succes= sfully submitted by Kerry Lynn and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-lynn-6man-6lobac
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Transmission of IPv6 over MS/TP Networks
Creation date: =A0 2011-10-10
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 14

Abstract:
=A0 MS/TP (Master-Slave/Token-Passing) is a contention-free access method<= br> =A0 for the TIA-485-A physical layer that is used extensively in building<= br> =A0 automation networks. =A0This document describes the frame format for =A0 transmission of IPv6 packets and the method of forming link-local and<= br> =A0 statelessly autoconfigured IPv6 addresses on MS/TP networks.




The IETF Secretariat

--20cf303ea6a47f256104aefd9744-- From manav.bhatia@alcatel-lucent.com Tue Oct 11 05:44:52 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046B121F8D66 for ; Tue, 11 Oct 2011 05:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nt-7xwKez1tg for ; Tue, 11 Oct 2011 05:44:51 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8255C21F8D5D for ; Tue, 11 Oct 2011 05:44:51 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p9BCilIo011767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Oct 2011 07:44:49 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9BCik1R027048 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 11 Oct 2011 18:14:46 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.59]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 11 Oct 2011 18:14:46 +0530 From: "Bhatia, Manav (Manav)" To: "ipv6@ietf.org" Date: Tue, 11 Oct 2011 18:14:46 +0530 Subject: draft-ietf-6man-exthdr Thread-Topic: draft-ietf-6man-exthdr Thread-Index: AcyIE467h0/OBCuSSEWTF8o0sY5vUQ== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D006D5645@INBANSXCHMBSA1.in.alcatel-lucent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 12:44:52 -0000 Hi, This draft had finished the WG LC quite some time back. The latest version = contains all the changes that we were asked for. Can we now push it for the= AD review? Cheers, Manav= From shemant@cisco.com Tue Oct 11 08:39:19 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A2821F8E8F; Tue, 11 Oct 2011 08:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1qlDd99PgKV; Tue, 11 Oct 2011 08:39:18 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5B76A21F8E8D; Tue, 11 Oct 2011 08:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8650; q=dns/txt; s=iport; t=1318347558; x=1319557158; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=1F1heiFcYhG+q99Nuj+BnPXundbnf3lckbd+40ohGo4=; b=kg3J3OhkVHjpLQpX7iJwjwII7zVrkKdnjmWUkfmeVSV5FiTbsa4zxfFJ edge99BQrPivaMLE9BcHS2zEKgQcE4BvOOXyr4ibVjgoTzFgYzDiyGu7k 4+9ucI58b3TugP9ru9HTB10l6xq9LYhIYt96c23Tl6k8jf+jnPlw4zb73 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkAAIdilE6tJV2c/2dsb2JhbABDgk2WN48kgQWBUwEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAEBBAESCAEZh2OaIAGeW4ZrYQSHf5EnjD8 X-IronPort-AV: E=Sophos;i="4.68,523,1312156800"; d="scan'208,217";a="27570063" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 11 Oct 2011 15:39:17 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9BFdHV0001761; Tue, 11 Oct 2011 15:39:17 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 10:39:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC882B.EF9AB17A" Subject: RE: [v6ops] new draft: draft-asati-v6ops-dad-loopback Date: Tue, 11 Oct 2011 10:39:16 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] new draft: draft-asati-v6ops-dad-loopback Thread-Index: AcxmNKk5OsR2s8X4Toq0tm4Sfz7cwwh9e3mg References: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" , "Erik Kline" X-OriginalArrivalTime: 11 Oct 2011 15:39:17.0213 (UTC) FILETIME=[EFA040D0:01CC882B] Cc: v6ops@ietf.org, draft-asati-v6ops-dad-loopback@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:39:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC882B.EF9AB17A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lorenzo, =20 I realized that the looping back of ND messages, especially during DAD is an issue that needs to be solved at a fundamental level in ND DAD. Thus I and Wes Beebee came up with a new document for 6man that has no need to sending probes and then also raising questions such as the ones you raised as in what is the state of the address while the timer is ticking. You were on the right track with some of your statement below. There was some fun integrating with SEND and also some other subtle issues. I think our document can be referenced as an automated means in the draft-asati-v6ops-dad-loopback. See =20 http://www.ietf.org/id/draft-hsingh-6man-enhanced-dad-00.txt =20 Hemant=20 =20 =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti Sent: Monday, August 29, 2011 6:15 AM To: Erik Kline Cc: v6ops@ietf.org; draft-asati-v6ops-dad-loopback@tools.ietf.org Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback =20 On Mon, Aug 29, 2011 at 18:54, Erik Kline wrote: +1 to section 3.2, generally. =20 This is definitely a useful problem to solve. I have personally had to work around this situation more than once, sometimes by disabling DAD completely on routers. =20 A couple of points that the draft doesn't explain: - Why can't the node simply retry DAD without the nonce option? - How does the nonce option guarantee that the address is unique? Just probabilistically, because the nonce would have to collide? - Why only send the nonce on the second (and subsequent?) messages? Why not simply send out all NSes with nonces all the time? - What state is the address in while the timer is ticking? =20 Also: in some cases this happens when buggy drivers (typically wifi drivers) loop back the node's own multicast packets. This is a violation of 802.11, but nobody notices since it doesn't affect IPv4. With your proposed scheme, DAD would succeed, but the node would be continuously receiving its own multicast packets. What happens in such situations? ------_=_NextPart_001_01CC882B.EF9AB17A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lorenzo,

 

I realized that the looping back of ND messages, especially during = DAD is an issue that needs to be solved at a fundamental level in ND = DAD.   Thus I and Wes Beebee came up with a new document =  for 6man that has no need to sending probes and then also raising = questions such as the ones you raised as in what is the state of the = address while the timer is ticking.   You were on the right = track with some of your statement below.   There was some fun = integrating with SEND and also some other subtle issues.  I think = our document can be referenced as an automated means in the =  draft-asati-v6ops-dad-loopback.  See

 

htt= p://www.ietf.org/id/draft-hsingh-6man-enhanced-dad-00.txt<= /span>

 

Hemant

 

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Lorenzo Colitti
Sent: Monday, August 29, 2011 6:15 = AM
To: Erik Kline
Cc: v6ops@ietf.org; = draft-asati-v6ops-dad-loopback@tools.ietf.org
Subject: Re: = [v6ops] new draft: = draft-asati-v6ops-dad-loopback

 

On Mon, = Aug 29, 2011 at 18:54, Erik Kline <ek@google.com> wrote:

+1 to section 3.2, generally.

 

This = is definitely a useful problem to solve. I have personally had to work = around this situation more than once, sometimes by disabling DAD = completely on routers.

 

A = couple of points that the draft doesn't = explain:

- Why can't the = node simply retry DAD without the nonce = option?

- How does the = nonce option guarantee that the address is unique? Just = probabilistically, because the nonce would have to = collide?

- Why only = send the nonce on the second (and subsequent?) messages? Why not = simply send out all NSes with nonces all the = time?

- What state is the = address in while the timer is ticking?

 

Also: in some cases this happens when buggy drivers = (typically wifi drivers) loop back the node's own multicast packets. = This is a violation of 802.11, but nobody notices since it doesn't = affect IPv4. With your proposed scheme, DAD would succeed, but the node = would be continuously receiving its own multicast packets. What happens = in such situations?

------_=_NextPart_001_01CC882B.EF9AB17A-- From fred@cisco.com Tue Oct 11 08:48:01 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA1521F8E42; Tue, 11 Oct 2011 08:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.017 X-Spam-Level: X-Spam-Status: No, score=-102.017 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXVqFiTaKhml; Tue, 11 Oct 2011 08:48:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4355D21F8E38; Tue, 11 Oct 2011 08:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=13349; q=dns/txt; s=iport; t=1318348080; x=1319557680; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=dAjASoenf0g1R2kAHJk88hpFUijslh0JNwsSI6a66ng=; b=AxX/OE2zcJUZL08AMT+3FbA+wkt5jzdfN96XSgiaUsSY8fHcwQ8LAgH2 yFJc6ZWOBGBGAI/3OXv52YQbNW8WdVNDykn18cgjVKUrmU1C5lpKsFFnI pLng+NnlizgXytOicgT9qf0hjo9JzHZdVG5OgaBjJ3BtFbEXiSfX3WSvl I=; X-IronPort-AV: E=Sophos;i="4.68,524,1312156800"; d="scan'208,217";a="27570621" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 11 Oct 2011 15:47:59 +0000 Received: from Freds-Computer.local (rtp-vpn2-837.cisco.com [10.82.243.69]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9BFlwGr021707; Tue, 11 Oct 2011 15:47:58 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 11 Oct 2011 11:47:59 -0400 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 11 Oct 2011 11:47:59 -0400 Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> Date: Tue, 11 Oct 2011 11:47:38 -0400 Message-Id: References: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-14-738442450 Cc: v6ops@ietf.org, draft-asati-v6ops-dad-loopback@tools.ietf.org, ipv6@ietf.org, Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:48:01 -0000 --Apple-Mail-14-738442450 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just so everyone's on the same page, although this draft originally = targets v6ops, it is going to be looked at in 6man (per the 6man = chairs). That's a discussion you may want to have in 6man. On Oct 11, 2011, at 11:39 AM, Hemant Singh (shemant) wrote: > Lorenzo, > =20 > I realized that the looping back of ND messages, especially during DAD = is an issue that needs to be solved at a fundamental level in ND DAD. = Thus I and Wes Beebee came up with a new document for 6man that has no = need to sending probes and then also raising questions such as the ones = you raised as in what is the state of the address while the timer is = ticking. You were on the right track with some of your statement = below. There was some fun integrating with SEND and also some other = subtle issues. I think our document can be referenced as an automated = means in the draft-asati-v6ops-dad-loopback. See > =20 > http://www.ietf.org/id/draft-hsingh-6man-enhanced-dad-00.txt > =20 > Hemant > =20 > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Lorenzo Colitti > Sent: Monday, August 29, 2011 6:15 AM > To: Erik Kline > Cc: v6ops@ietf.org; draft-asati-v6ops-dad-loopback@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback > =20 > On Mon, Aug 29, 2011 at 18:54, Erik Kline wrote: > +1 to section 3.2, generally. > =20 > This is definitely a useful problem to solve. I have personally had to = work around this situation more than once, sometimes by disabling DAD = completely on routers. > =20 > A couple of points that the draft doesn't explain: > - Why can't the node simply retry DAD without the nonce option? > - How does the nonce option guarantee that the address is unique? Just = probabilistically, because the nonce would have to collide? > - Why only send the nonce on the second (and subsequent?) messages? = Why not simply send out all NSes with nonces all the time? > - What state is the address in while the timer is ticking? > =20 > Also: in some cases this happens when buggy drivers (typically wifi = drivers) loop back the node's own multicast packets. This is a violation = of 802.11, but nobody notices since it doesn't affect IPv4. With your = proposed scheme, DAD would succeed, but the node would be continuously = receiving its own multicast packets. What happens in such situations? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-14-738442450 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just so everyone's on the same page, although this = draft originally targets v6ops, it is going to be looked at in 6man (per = the 6man chairs). That's a discussion you may want to have in = 6man.

On Oct 11, 2011, at 11:39 AM, Hemant Singh = (shemant) wrote:

I = realized that the looping back of ND messages, especially during DAD is = an issue that needs to be solved at a fundamental level in ND = DAD.   Thus I and Wes Beebee came up with a new document =  for 6man that has no need to sending probes and then also raising = questions such as the ones you raised as in what is the state of the = address while the timer is ticking.   You were on the right = track with some of your statement below.   There was some fun = integrating with SEND and also some other subtle issues.  I think = our document can be referenced as an automated means in the =  draft-asati-v6ops-dad-loopback.  = See
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or= g] On Behalf = Of Lorenzo = Colitti
Sent: Monday, August 29, 2011 = 6:15 AM
To: Erik = Kline
Cc: v6ops@ietf.org;  Re: [v6ops] new draft: = draft-asati-v6ops-dad-loopback
__________________________________= _____________
v6ops mailing list
 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:06:19 -0000 All, This is a consensus call on adopting: Title : RFC3627 to Historic status Author(s) : Wesley George Filename : draft-george-6man-3627-historic-01.txt Pages : 4 Date : 2011-10-10 as a 6MAN working group document. Please state your opinion, positive or negative, on the mailing list or to the chairs. This consensus call will end on October 25, 2011. Regards, Brian & Bob From brian@innovationslab.net Tue Oct 11 10:06:27 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485AE21F8CA1 for ; Tue, 11 Oct 2011 10:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zIH1i0a8mYv for ; Tue, 11 Oct 2011 10:06:27 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id DF0D921F8C45 for ; Tue, 11 Oct 2011 10:06:26 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id B2B3B88122 for ; Tue, 11 Oct 2011 10:06:26 -0700 (PDT) Received: from tigers.local (unknown [75.94.92.25]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 94328130004 for ; Tue, 11 Oct 2011 10:06:25 -0700 (PDT) Message-ID: <4E947777.1040507@innovationslab.net> Date: Tue, 11 Oct 2011 13:05:59 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: Consensus call on adopting: draft-lynn-6man-6lobac X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:06:27 -0000 All, This is a consensus call on adopting: Title : Transmission of IPv6 over MS/TP Networks Author(s) : Kerry Lynn Jerry Martocci Carl Neilson Stuart Donaldson Filename : draft-lynn-6man-6lobac-02.txt Pages : 14 Date : 2011-10-10 as a 6MAN working group document. Please state your opinion, positive or negative, on the mailing list or to the chairs. This consensus call will end on October 25, 2011. Regards, Brian & Bob From dbbuie@nsa.gov Tue Oct 11 10:07:58 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1082021F8EF6 for ; Tue, 11 Oct 2011 10:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCofsePTRjh4 for ; Tue, 11 Oct 2011 10:07:57 -0700 (PDT) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1A621F8ECA for ; Tue, 11 Oct 2011 10:07:57 -0700 (PDT) Received: from MSCS-GH1-UEA01.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p9BH7u7D021403 for ; Tue, 11 Oct 2011 17:07:56 GMT Received: from MSIS-GH1-UEA04.corp.nsa.gov ([10.215.228.136]) by MSCS-GH1-UEA01.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Oct 2011 13:07:55 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8838.51B7CBBC" x-mimeole: Produced By Microsoft Exchange V6.5 Subject: Please remove from Allais Date: Tue, 11 Oct 2011 13:07:55 -0400 Message-ID: <574292FDCA23154F813B8ACCFBDDCEEB012D3BCE@MSIS-GH1-UEA04.corp.nsa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please remove from Allais Thread-Index: AcyIOFRfTrNHQPLQTiyWaKmG6aBp3A== From: "Buie, David" To: X-OriginalArrivalTime: 11 Oct 2011 17:07:55.0959 (UTC) FILETIME=[51D87C70:01CC8838] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:07:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8838.51B7CBBC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 David B. Buie=20 CAO Cyber Integration=20 Commercial: (443) 654-4592 Cell: (443) 244-5103(NEW) =20 ------_=_NextPart_001_01CC8838.51B7CBBC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

                = ;   David B. Buie

  &= nbsp;           &n= bsp;       CAO Cyber Integration =

  &n= bsp;         Commercial: = (443) 654-4592 Cell: (443) = 244-5103(NEW)

  &n= bsp;           &nb= sp;      =

------_=_NextPart_001_01CC8838.51B7CBBC-- From shemant@cisco.com Tue Oct 11 10:50:08 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D5821F8F4E for ; Tue, 11 Oct 2011 10:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNYshBZQ6tIK for ; Tue, 11 Oct 2011 10:50:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEDC21F8F4C for ; Tue, 11 Oct 2011 10:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1014; q=dns/txt; s=iport; t=1318355408; x=1319565008; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=GXfBVTjcGRXebrzUQnH3IE3yMGMVtwTlMj4wK7vn7ng=; b=P4FCtQKRar66yPZhnMrWkLsU9vx4n5H57b7LVUCz+afnTb24W4TvwM0g nc0OanY4PaA5rUTlqyuwyTGVjuGLKc+YwJ30dSDU4TGc2AD2yVHCZ4lln VA2zYoBsDluTzKYeVJGzz6YzY3DRM4ZjJHFN1yDgqlKlgQoXyx4mAYxp6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkAAFOBlE6tJV2c/2dsb2JhbABDmQaPJIEFgVMBAQEEAQEBDwEdCjQXBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodjmgcBnlUDhmthBId/kSeMPw X-IronPort-AV: E=Sophos;i="4.68,524,1312156800"; d="scan'208";a="27609267" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 11 Oct 2011 17:50:07 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9BHo7eF001350; Tue, 11 Oct 2011 17:50:07 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 12:50:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus call on adopting: draft-george-6man-3627-historic Date: Tue, 11 Oct 2011 12:50:06 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A35EF@XMB-RCD-109.cisco.com> In-Reply-To: <4E94776D.5080908@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call on adopting: draft-george-6man-3627-historic Thread-Index: AcyIOB0diG+ATRCySjuhK82J7dpLkQABf7sA References: <4E94776D.5080908@innovationslab.net> From: "Hemant Singh (shemant)" To: "Brian Haberman" , "IPv6 WG Mailing List" X-OriginalArrivalTime: 11 Oct 2011 17:50:07.0438 (UTC) FILETIME=[36B986E0:01CC883E] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 17:50:09 -0000 I support adopting this document. Thanks, Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Tuesday, October 11, 2011 1:06 PM To: IPv6 WG Mailing List Subject: Consensus call on adopting: draft-george-6man-3627-historic All, This is a consensus call on adopting: Title : RFC3627 to Historic status Author(s) : Wesley George Filename : draft-george-6man-3627-historic-01.txt Pages : 4 Date : 2011-10-10 as a 6MAN working group document. Please state your opinion, positive or negative, on the mailing list or to the chairs. This consensus call will end on October 25, 2011. Regards, Brian & Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From wesley.george@twcable.com Tue Oct 11 12:34:29 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1241F0C43 for ; Tue, 11 Oct 2011 12:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.059 X-Spam-Level: X-Spam-Status: No, score=0.059 tagged_above=-999 required=5 tests=[AWL=1.522, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcTas+9rPlvD for ; Tue, 11 Oct 2011 12:34:29 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id CB4E61F0C3D for ; Tue, 11 Oct 2011 12:34:28 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.67,671,1309752000"; d="scan'208";a="284174382" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 11 Oct 2011 15:30:59 -0400 Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 11 Oct 2011 15:34:22 -0400 From: "George, Wes" To: Brian Haberman , IPv6 WG Mailing List Date: Tue, 11 Oct 2011 15:34:20 -0400 Subject: RE: Consensus call on adopting: draft-lynn-6man-6lobac Thread-Topic: Consensus call on adopting: draft-lynn-6man-6lobac Thread-Index: AcyIODbgyUldudCRSyuUBEcAehr94gAFIjKQ Message-ID: <34E4F50CAFA10349A41E0756550084FB11D94CC0@PRVPEXVS04.corp.twcable.com> References: <4E947777.1040507@innovationslab.net> In-Reply-To: <4E947777.1040507@innovationslab.net> 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 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:34:29 -0000 Support adoption Thanks, Wes > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian Haberman > Sent: Tuesday, October 11, 2011 1:06 PM > To: IPv6 WG Mailing List > Subject: Consensus call on adopting: draft-lynn-6man-6lobac > > All, > This is a consensus call on adopting: > > Title : Transmission of IPv6 over MS/TP Networks > Author(s) : Kerry Lynn > Jerry Martocci > Carl Neilson > Stuart Donaldson > Filename : draft-lynn-6man-6lobac-02.txt > Pages : 14 > Date : 2011-10-10 > > as a 6MAN working group document. Please state your opinion, positive > or negative, on the mailing list or to the chairs. This consensus call > will end on October 25, 2011. > > Regards, > Brian & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From internet-drafts@ietf.org Tue Oct 11 22:17:16 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D607221F8B05; Tue, 11 Oct 2011 22:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEHDmIFtXYhJ; Tue, 11 Oct 2011 22:17:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8616921F8B0F; Tue, 11 Oct 2011 22:17:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111012051715.10542.59203.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2011 22:17:15 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 05:17:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : RPL Option for Carrying RPL Information in Data-Plane Da= tagrams Author(s) : Jonathan W. Hui JP Vasseur Filename : draft-ietf-6man-rpl-option-04.txt Pages : 14 Date : 2011-10-11 The RPL protocol requires data-plane datagrams to carry RPL routing information that is processed by RPL routers when forwarding those datagrams. This document describes the RPL Option for use within a RPL domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt From internet-drafts@ietf.org Tue Oct 11 22:18:10 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8C721F8C5E; Tue, 11 Oct 2011 22:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHi0mdDdlZvS; Tue, 11 Oct 2011 22:18:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5868521F8C18; Tue, 11 Oct 2011 22:18:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-rpl-routing-header-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111012051805.7813.22995.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2011 22:18:05 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 05:18:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : An IPv6 Routing Header for Source Routes with RPL Author(s) : Jonathan W. Hui JP Vasseur David E. Culler Vishwas Manral Filename : draft-ietf-6man-rpl-routing-header-04.txt Pages : 18 Date : 2011-10-11 In Low power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining at most a few routes. In some configurations, it is necessary to use these memory constrained routers to deliver datagrams to nodes within the LLN. The Routing for Low Power and Lossy Networks (RPL) protocol can be used in some deployments to store most, if not all, routes on one (e.g. the Directed Acyclic Graph (DAG) root) or few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-routing-header-04.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-routing-header-04.txt From jonhui@cisco.com Tue Oct 11 22:23:08 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A3F21F8C69 for ; Tue, 11 Oct 2011 22:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwOmc+uZ2OLg for ; Tue, 11 Oct 2011 22:23:07 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA1721F8BF8 for ; Tue, 11 Oct 2011 22:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=2725; q=dns/txt; s=iport; t=1318396987; x=1319606587; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=okqNhYZjGlQEWV43csWnkQZd5KoKNr5lWVViI8DHbzw=; b=ST2qHFFufHhBJh8lJ8NdKpXNzI9mNulZqM0XsWDj0NiYjQCbFUMUy5bE ZL5Hqj0FGtuBsCQsyQ8pv+h+PBVmgWYZ6L25em1kkMruSaPnFW+YTAugp /HajB49ZEdgIrP61LbHia0usjiq8aRy2xj+NqHY1UKnjkc6MovMGsX0YC Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOcjlU6rRDoJ/2dsb2JhbABDqC2BBYFTAQEBAQIBAQEBDwEnNBALHAMBAi8nJgIIBhMJGYdcB5lRAZ5ThndhBId/i3aRcw X-IronPort-AV: E=Sophos;i="4.69,332,1315180800"; d="scan'208";a="7354059" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 12 Oct 2011 05:23:07 +0000 Received: from sjc-vpn6-1638.cisco.com (sjc-vpn6-1638.cisco.com [10.21.126.102]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9C5N73h025735 for ; Wed, 12 Oct 2011 05:23:07 GMT From: Jonathan Hui Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: I-D Action: draft-ietf-6man-rpl-routing-header-04.txt Date: Tue, 11 Oct 2011 22:23:06 -0700 References: <20111012051805.7813.22995.idtracker@ietfa.amsl.com> To: IETF IPv6 Mailing List Message-Id: <853BDFEE-58AB-4766-A1E0-9590AD47F869@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 05:23:08 -0000 This update is intended to address Jari Arkko's AD review. Summary of changes: - Updated text on recommendations for avoiding fragmentation. - Clarify definition of CmprE where it is first mentioned. - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. - Update packet processing pseudocode to match the text on sending back = a parameter problem error. - Recommend that non-RPL devices drop packets with SRH by default. - Clarify packet structure figures. - State that checking for cycles represents significant per-packet = processing. -- Jonathan Hui Begin forwarded message: > From: internet-drafts@ietf.org > Date: October 11, 2011 10:18:05 PM PDT > To: i-d-announce@ietf.org > Cc: ipv6@ietf.org > Subject: I-D Action: draft-ietf-6man-rpl-routing-header-04.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Maintenance Working = Group of the IETF. >=20 > Title : An IPv6 Routing Header for Source Routes with = RPL > Author(s) : Jonathan W. Hui > JP Vasseur > David E. Culler > Vishwas Manral > Filename : draft-ietf-6man-rpl-routing-header-04.txt > Pages : 18 > Date : 2011-10-11 >=20 > In Low power and Lossy Networks (LLNs), memory constraints on = routers > may limit them to maintaining at most a few routes. In some > configurations, it is necessary to use these memory constrained > routers to deliver datagrams to nodes within the LLN. The Routing > for Low Power and Lossy Networks (RPL) protocol can be used in some > deployments to store most, if not all, routes on one (e.g. the > Directed Acyclic Graph (DAG) root) or few routers and forward the > IPv6 datagram using a source routing technique to avoid large = routing > tables on memory constrained routers. This document specifies a new > IPv6 Routing header type for delivering datagrams within a RPL > domain. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-routing-header-04.= txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-routing-header-04.t= xt > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jonhui@cisco.com Tue Oct 11 22:23:12 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F3221F8C82 for ; Tue, 11 Oct 2011 22:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOKeY+Shq8ZX for ; Tue, 11 Oct 2011 22:23:11 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6932021F8C7A for ; Tue, 11 Oct 2011 22:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=1983; q=dns/txt; s=iport; t=1318396991; x=1319606591; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=1+g/jettiaRJldfLCWFfuboMhMnxpLpHjBMZLG6OjBc=; b=LnbYYR7aPhgvesNyHxn0BDqXxAFcQ761blrQh/SxtGetpd8WEV4O1vzy u4EDpI/KwyTWtqBY9n4/ySv511llTkIf5SWk8Gza9sHQ+q6fHXxki69KY vkl3PbMvST5mVujXc94aIaqDdn9uWzvBrtixQprBiYAJNuNjT1JWMKfkK I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOcjlU6rRDoJ/2dsb2JhbABDqC2BBYFTAQEBAQIBAQEBDwEnNBALHAMBAi8nJgIIBhMJGYdcB5lRAZ5ThndhBId/i3aRcw X-IronPort-AV: E=Sophos;i="4.69,332,1315180800"; d="scan'208";a="7354063" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 12 Oct 2011 05:23:11 +0000 Received: from sjc-vpn6-1638.cisco.com (sjc-vpn6-1638.cisco.com [10.21.126.102]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9C5N73i025735 for ; Wed, 12 Oct 2011 05:23:11 GMT From: Jonathan Hui Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt Date: Tue, 11 Oct 2011 22:23:10 -0700 References: <20111012051715.10542.59203.idtracker@ietfa.amsl.com> To: IETF IPv6 Mailing List Message-Id: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 05:23:12 -0000 This update is intended to address Jari Arkko's AD review. Summary of changes: - Clarify when the RPL Option is used. - Updated text on recommendations for avoiding fragmentation. - Specify skip-over-and-continue policy for unrecognized sub-TLVs. - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. - Specify RPL Border Router operations in terms of forwarding decision = outcomes. - Expand security section. -- Jonathan Hui Begin forwarded message: > From: internet-drafts@ietf.org > Date: October 11, 2011 10:17:15 PM PDT > To: i-d-announce@ietf.org > Cc: ipv6@ietf.org > Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Maintenance Working = Group of the IETF. >=20 > Title : RPL Option for Carrying RPL Information in = Data-Plane Datagrams > Author(s) : Jonathan W. Hui > JP Vasseur > Filename : draft-ietf-6man-rpl-option-04.txt > Pages : 14 > Date : 2011-10-11 >=20 > The RPL protocol requires data-plane datagrams to carry RPL routing > information that is processed by RPL routers when forwarding those > datagrams. This document describes the RPL Option for use within a > RPL domain. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From shemant@cisco.com Fri Oct 14 08:45:30 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B688521F84F5 for ; Fri, 14 Oct 2011 08:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.61 X-Spam-Level: X-Spam-Status: No, score=-4.61 tagged_above=-999 required=5 tests=[AWL=1.989, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3OFYOfxGyJy for ; Fri, 14 Oct 2011 08:45:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E639321F8CC7 for ; Fri, 14 Oct 2011 08:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1926; q=dns/txt; s=iport; t=1318607130; x=1319816730; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=qz1ESt36LmUwacTYiLEBoCZd4dDJy3n+y5cWnHUUYjg=; b=Vbv9oesaurKJoo49pNJ5HJdWMwiADA07dO07AOs5pAnTT2bwOW7b1Re7 ucDNPLBC+NKy3UHn1NBun6JQarn1K16NVQyi5ADYupnXMl3MTUWHnOTDs 7j0cRN19rKKCblHTZDDQ/Z6mITWmn1jcMYHqf25YiVKiA3KDzUWGvg2S3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMAAAlYmE6tJXG8/2dsb2JhbABDhHaURY4ogQCBBYFuAQEBBBIBEA0EQw4GAQgRBAEBAwIGBhcBAgIDAUQHAQEFBAEEEwganzGBJgGMR5IQgSyFOTNhBIgBkSeMQg X-IronPort-AV: E=Sophos;i="4.69,346,1315180800"; d="scan'208";a="28502794" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 14 Oct 2011 15:45:29 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9EFjT4B003939 for ; Fri, 14 Oct 2011 15:45:29 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 10:45:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Date: Fri, 14 Oct 2011 10:45:28 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyKhZ7lfPfx1TdLRJyg2Rny3mnl0AAAnEmw From: "Hemant Singh (shemant)" To: "IPv6 WG Mailing List" X-OriginalArrivalTime: 14 Oct 2011 15:45:29.0569 (UTC) FILETIME=[4CCE8510:01CC8A88] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 15:45:30 -0000 Rm9sa3MsDQoNClBsZWFzZSByZXZpZXcgdGhpcyBkb2N1bWVudC4gDQoNClRoYW5rcywNCg0KSGVt YW50DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5 LCBPY3RvYmVyIDE0LCAyMDExIDExOjI2IEFNDQpUbzogSGVtYW50IFNpbmdoIChzaGVtYW50KQ0K Q2M6IEhlbWFudCBTaW5naCAoc2hlbWFudCkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtaHNpbmdoLTZtYW4tZW5oYW5jZWQtZGFkLTAxLnR4dA0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHNpbmdoLTZtYW4tZW5oYW5jZWQtZGFkLTAxLnR4dCBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEhlbWFudCBTaW5naCBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtaHNpbmdoLTZtYW4tZW5o YW5jZWQtZGFkDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBFbmhhbmNlZCBEdXBsaWNhdGUgQWRk cmVzcyBEZXRlY3Rpb24NCkNyZWF0aW9uIGRhdGU6CSAyMDExLTEwLTE0DQpXRyBJRDoJCSBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogNw0KDQpBYnN0cmFjdDoNCiAgIEFw cGVuZGl4IEEgb2YgW1JGQzQ4NjJdIGRpc2N1c3NlcyBMb29wYmFjayBTdXBwcmVzc2lvbiBhbmQg RHVwbGljYXRlDQogICBBZGRyZXNzIERldGVjdGlvbiAoREFEKS4gIEhvd2V2ZXIsIFtSRkM0ODYy XSBkb2VzIG5vdCBzZXR0bGUgb24gb25lDQogICBzcGVjaWZpYyBhdXRvbWF0ZWQgbWVhbnMgdG8g ZGV0ZWN0IExvb3BiYWNrIG9mIE5laWdoYm9yIERpc2NvdmVyeQ0KICAgKE5EKSBbUkZDNDg2MV0g bWVzc2FnZXMgdXNlZCBieSBEQUQuICBTZXZlcmFsIHNlcnZpY2UgcHJvdmlkZXINCiAgIGNvbW11 bml0aWVzIGhhdmUgZXhwcmVzc2VkIGEgbmVlZCBmb3IgYXV0b21hdGVkIGRldGVjdGlvbiBvZiBs b29wZWQNCiAgIGJhY2tlZCBORCBtZXNzYWdlcyB1c2VkIGJ5IERBRC4gIFRoaXMgZG9jdW1lbnQg b3V0bGluZXMgYW4gYWxnb3JpdGhtDQogICB0byBhdXRvbWF0ZSBkZXRlY3Rpb24gb2YgbG9vcGVk IGJhY2sgSVB2NiBORCBtZXNzYWdlcyB1c2VkIGJ5IERBRC4NCiAgIEZ1cnRoZXIsIGZvciBjZXJ0 YWluIGFjY2VzcyBuZXR3b3JrcyB0aGUgZG9jdW1lbnQgYXV0b21hdGVzIHJlc29sdmluZw0KICAg YSBzcGVjaWZpYyBkdXBsaWNhdGUgYWRkcmVzcyBjb25mbGljdC4NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From shemant@cisco.com Fri Oct 14 09:03:51 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7721521F8C14 for ; Fri, 14 Oct 2011 09:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.742 X-Spam-Level: X-Spam-Status: No, score=-4.742 tagged_above=-999 required=5 tests=[AWL=1.857, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD+oIDIKRjdn for ; Fri, 14 Oct 2011 09:03:50 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C60F421F8C0E for ; Fri, 14 Oct 2011 09:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=3266; q=dns/txt; s=iport; t=1318608230; x=1319817830; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Fi3VVnhU3NQ2oHwIxeSBLAExO3C8HE+lLWtPb9PHCwA=; b=hPH6gTMTPrSQoGFd6qiXTchKGapcJJOuuGVyXlQwQqfqMyLV6IYNvlNO Lq1s2g/1hhG7RepZkhZ38bvfgvelQNG1+NdGQb2lRZaRzdrtYYsUOGfv/ op9PigKs4NI0hNH5Yu4f6DmbkGgMrQ2gtvzga6C1LdC4MkGIFliCYHre3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMAABBdmE6tJV2b/2dsb2JhbABDmTuPKIEFgW4BAQEEAQEBDwEdCjQJAgwEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggah2WYcwGeVgOHGGEEiAGRJ4xC X-IronPort-AV: E=Sophos;i="4.69,347,1315180800"; d="scan'208";a="28504626" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 14 Oct 2011 16:03:48 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9EG3oIZ002567; Fri, 14 Oct 2011 16:03:50 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 11:03:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Date: Fri, 14 Oct 2011 11:03:46 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A439A@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyKhZ7lfPfx1TdLRJyg2Rny3mnl0AAAnEmwAAB/IpA= References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "IPv6 WG Mailing List" X-OriginalArrivalTime: 14 Oct 2011 16:03:48.0432 (UTC) FILETIME=[DBC7B500:01CC8A8A] Cc: Suresh Krishnan , Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 16:03:51 -0000 Broadband access folks, Of particular interest to you in this document will be this problem from the Introduction section.=20 [In another service provider network, two broadband modems in a home have the Ethernet ports of each modem connected to a network hub. The access concentrator serving the modems is the first-hop IPv6 router for the modems. The access concentrator also supports proxying of DAD messages. Each modem is IPv4 online. The network interface of the access concentrator serving the two broadband modems is enabled for IPv6 and the interface issues a NS(DAD) message for the IPv6 link- local address. The NS message reaches one modem first and this modem sends the message to the hub which sends the message to the second modem which forwards the message back to the access concentrator. The looped back NS message causes the network interface on the access concentrator to be in a DAD-failed state. Such a network interface typically serves over six thousand broadband modems causing all the modems (and hosts behind the modems) to fail to get IPv6 online on the access network. Additionally, it may be tedious for the access concentrator to find out which of the six thousand or more homes looped back the DAD message. Clearly there is a need for automated detection of looped back NS messages during DAD operations by a node.] Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Friday, October 14, 2011 11:45 AM To: IPv6 WG Mailing List Subject: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Folks, Please review this document.=20 Thanks, Hemant -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Friday, October 14, 2011 11:26 AM To: Hemant Singh (shemant) Cc: Hemant Singh (shemant) Subject: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt A new version of I-D, draft-hsingh-6man-enhanced-dad-01.txt has been successfully submitted by Hemant Singh and posted to the IETF repository. Filename: draft-hsingh-6man-enhanced-dad Revision: 01 Title: Enhanced Duplicate Address Detection Creation date: 2011-10-14 WG ID: Individual Submission Number of pages: 7 Abstract: Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate Address Detection (DAD). However, [RFC4862] does not settle on one specific automated means to detect Loopback of Neighbor Discovery (ND) [RFC4861] messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document outlines an algorithm to automate detection of looped back IPv6 ND messages used by DAD. Further, for certain access networks the document automates resolving a specific duplicate address conflict. =20 The IETF Secretariat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From shemant@cisco.com Fri Oct 14 15:41:16 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B670621F8AFC for ; Fri, 14 Oct 2011 15:41:16 -0700 (PDT) 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.638, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reLyqwyTL7h8 for ; Fri, 14 Oct 2011 15:41:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCC621F8AF4 for ; Fri, 14 Oct 2011 15:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2546; q=dns/txt; s=iport; t=1318632076; x=1319841676; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=y9dbhX+Q0gbDWpCGt0pj+J9ZlSWSnBjhAxo7DkhEhss=; b=Jgwxrrmns/jEOEz/dq/bptdQU+2gA5fw8daVSRUWMdri+oDuqkNKE3Dk UxV5cYewE0llipph5MIQ5bUE70CAg+3A5NYEMJbPsCpuNQThi4SakRUSj 1G7EzXsK/2P6Ji41/bRSRUd+as04qAqb+/ukcsBVXW7WjpHh5sypL3LPv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAIG5mE6tJXHA/2dsb2JhbABDhHaUSY4ogQCBBYFuAQEBAQMSARANBDoJAhACAQgOAwQBAQMCBgYXAQICAgEBRAgBCAEBBBMIDA6hFAGMR5F9gSyFOTNhBIgBkSeMQg X-IronPort-AV: E=Sophos;i="4.69,349,1315180800"; d="scan'208";a="28593498" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 14 Oct 2011 22:41:15 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9EMfFL6022618; Fri, 14 Oct 2011 22:41:15 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 17:41:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Date: Fri, 14 Oct 2011 17:41:14 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> In-Reply-To: <4E98B7AE.9050103@forthnet.gr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyKwLbNoaDcLsoeRj60sIGz7WGdKwAAFfDw References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> From: "Hemant Singh (shemant)" To: "Tassos Chatzithomaoglou" X-OriginalArrivalTime: 14 Oct 2011 22:41:15.0148 (UTC) FILETIME=[6187CCC0:01CC8AC2] Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 22:41:16 -0000 VGFzc29zLA0KDQpGcm9tOiBUYXNzb3MgQ2hhdHppdGhvbWFvZ2xvdSBbbWFpbHRvOmFjaGF0ekBm b3J0aG5ldC5ncl0gDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTQsIDIwMTEgNjoyOSBQTQ0KVG86 IEhlbWFudCBTaW5naCAoc2hlbWFudCkNCkNjOiBJUHY2IFdHIE1haWxpbmcgTGlzdA0KU3ViamVj dDogUmU6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhzaW5naC02bWFu LWVuaGFuY2VkLWRhZC0wMS50eHQNCg0KDQo+SSB3YXMgd29uZGVyaW5nLi4ud291bGRuJ3QgdGhl IGZsb3cgbGFiZWwgYmUgYSAiYmV0dGVyIiBmaWVsZCBmb3Igc3RvcmluZyB0aGlzIHJhbmRvbSBu dW1iZXI/DQo+SWYgaSByZW1lbWJlciBjb3JyZWN0bHksIGVhcmx5IGRyYWZ0cyBvZiBSUEwgd2Vy ZSB1c2luZyBpdCBmb3IgbG9vcCBkZXRlY3Rpb24gKG9rLCBpbiBhIHZlcnkgZGlmZmVyZW50IHdh eSksIGFsdGhvdWdoIGluIHRoZSBsYXRlciBvbmVzIGEgbmV3IG9wdGlvbiB3YXMgY2hvc2VuLg0K PlN1cmUsIFJGQyAzNjk3IGlzIHZlcnkgc3RyaWN0IG9uIGl0cyBzcGVjaWZpY2F0aW9uLCBzdXJl IFNFTkQgYWxyZWFkeSB1c2VzIHRoZSBOb25jZSBvcHRpb24sIGJ1dCBzaW5jZSB3ZSBhcmUgdGFs a2luZyBhYm91dCBORCBvbmx5ICg9YmVmb3JlIGFueSByZWFsIHNyYy9kc3QgZmxvdykgaSB3b3Vs ZCBsaWtlIHRvIGtub3cgdGhlID5yYXRpb25hbGUgYmVoaW5kIG9mIHRoaXMgZGVjaXNpb247IGNo b29zaW5nIGFuIGV4dHJhIG9wdGlvbiBpbnN0ZWFkIG9mIGEgbWFuZGF0b3J5IC11c2VsZXNzIHVu dGlsIHJlY2VudGx5LSBmaWVsZC4gTWF5YmUgdGhlbiwgYWxsIE5EIG1lc3NhZ2VzIGNvdWxkIGJl IHN1cHBvcnRlZCAobGVzcyBpbXBhY3Qgb24gbWVtb3J5PykuDQoNCj5JIG1heSBoYXZlIG1pc3Nl ZCBzb21lIHRhbGtzIGFib3V0IHRoaXMgaW4gdGhlIHBhc3QgKG9yIG1heWJlIGknbSB0YWxraW5n IG5vbnNlbnNlwqAgOi1bICksIHNvIHBsZWFzZSBmb3JnaXZlIG1lIGlmIHRoaXMgaXMgdGhlIGNh c2UuDQoNCk5vIGZvcmdpdmVuZXNzIG5lZWRlZCDimLouICBZb3UgaGF2ZSBiZWVuIGEgZ3JlYXQg cmV2aWV3ZXIgZm9yIGxvdCBvZiBkb2N1bWVudHMhICBUaGUgZmxvdyBsYWJlbCB3YXMgdGhlIGZp cnN0IGZpZWxkIEkgYW5kIGFub3RoZXIgY29sbGVhZ3VlIG9mIG1pbmUgYXQgQ2lzY28gdGhvdWdo dCBvZi4gICBIb3dldmVyIHlldCBhbm90aGVyIGNvbGxlYWd1ZSBvZiBtaW5lIHNob3QgZG93biB0 aGUgdXNlIG9mIEZsb3cgTGFiZWwgd2l0aCB0aGUgZm9sbG93aW5nIGNvbW1lbnRzIGluIGRvdWJs ZSBxdW90ZXMuDQoNCuKAnFVzaW5nIHRoZSBmbG93IGxhYmVsIGZvciB0aGlzIGlzIGxpa2VseSB0 byBiZSBoaWdobHkgY29udHJvdmVyc2lhbC7CoCBJIGNhbiBhbHJlYWR5IGhlYXIgcGVvcGxlIGNs YWltaW5nIGl0J3Mgbm90IGEgImZsb3ciLCBldGMu4oCdDQoNClRoZSBmbG93IGxhYmVsIGhhcyBh bm90aGVyIG51YW5jZS4gIEl0J3MgYSAyMC1iaXQgZmllbGQgYW5kIHRodXMgYSBub25jZSBnZW5l cmF0ZWQgd2l0aCBzdWNoIG51bWJlciBvZiBiaXRzIGhhcyBvbmUgaW4gYSBtaWxsaW9uIGNoYW5j ZSBvZiBhIGR1cGxpY2F0ZS4gIFRoZSBjb21tdW5pdHkgbWF5IHByZWZlciBhdCBsZWFzdCBhIDMy LWJpdCBub25jZSBvciBoaWdoZXIuICBUaGF0IGlzIHdoeSBJIGRlY2lkZWQgdG8ganVzdCB1c2Ug dGhlIE5vbmNlIE9wdGlvbiBmcm9tIFNFTkQgaW4gUkZDIDM5NzEuDQoNClRodXMgY2FuIHdlIG1v dmUgYXdheSBmcm9tIHRoZSBGbG93IExhYmVsIGFuZCB1c2UgdGhlIE5vbmNlIE9wdGlvbiBmcm9t IFNFTkQ/DQoNClRoYW5rcywNCg0KSGVtYW50DQoNCg0KDQo= From achatz@forthnetgroup.gr Fri Oct 14 15:42:37 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F295C21F8C7A for ; Fri, 14 Oct 2011 15:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQmLU7FZaZwU for ; Fri, 14 Oct 2011 15:42:37 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id B979221F8C74 for ; Fri, 14 Oct 2011 15:42:36 -0700 (PDT) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9EMgZGx012693; Sat, 15 Oct 2011 01:42:35 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9EMgZ0U020132; Sat, 15 Oct 2011 01:42:35 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9EMgPYZ004623; Sat, 15 Oct 2011 01:42:25 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4E98BACE.5020306@forthnetgroup.gr> Date: Sat, 15 Oct 2011 01:42:22 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet S.A. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1 MIME-Version: 1.0 To: "Hemant Singh (shemant)" Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 22:42:38 -0000 Hi,

I was wondering...wouldn't the flow label be a "better" field for storing this random number?
If i remember correctly, early drafts of RPL were using it for loop detection (ok, in a very different way), although in the later ones a new option was chosen.
Sure, RFC 3697 is very strict on its specification, sure SEND already uses the Nonce option, but since we are talking about ND only (=before any real src/dst flow) i would be interested to know the rationale behind of this decision; choosing an extra option instead of a mandatory -useless until recently- field. Maybe then, all ND messages could be supported (less impact on memory?).

I may have missed some talks about this in the past (or maybe i'm talking nonsense ), so please forgive me if this is the case.


Also, i have some comments...
   When the IPv6 network interface issues a NS(DAD) message, the
   interface includes the Nonce Option in the NS(DAD) message and saves
   the nonce in local store.  Subsequently if the interface receives an
   identical NS(DAD) message, the interface logs a system management
   message, updates any statistics counter, and drops the looped back
   NS(DAD).  If the DupAddrDetectTransmits variable for the interface is
   greater than one, subsequent NS(DAD) messages for the same Target
   Address should be suppressed.  If the interface receives a NS(DAD)
   message with a different nonce, the interface logs a DAD-failed
   system management message, updates any statistics, and behaves
   identical to the behavior specified in [RFC4862] for DAD failure.
I know we are talking about DAD, but maybe it should be re-written as....
If the interface receives a NS(DAD)
   message with a different nonce but the same Target address, the interface logs a DAD-failed
   system management message, updates any statistics, and behaves
   identical to the behavior specified in [RFC4862] for DAD failure.


   Six bytes of random nonce is sufficiently large for nonce collisions.
   However if there is a collision because two nodes generated the same
   random nonce, then the algorithm will incorrectly detect a looped
   back NS(DAD) when the NS(DAD) was issued to signal a genuine
   duplicate.  Since each looped back NS(DAD) event is logged to system
   management, the administrator of the network will have to intervene
   manually.
The same applies here...

However, if there is a collision because two nodes (that are using the same Target address in their NS(DAD)) generated the same
   random nonce, then the algorithm will incorrectly detect a looped
   back NS(DAD), while the NS(DAD) was issued to signal a genuine
   duplicate.

3.3.  Processing Rules for Receivers


   The node has been configured to use the algorithm of this document.
   If an interface on the node receives any NS(DAD) message that matches
   the interface address (in tentative or optimistic state), the
   receiver compares the nonce in the message with the saved nonce.  If
   a match is found, the node logs a system management message, updates
   any statistics counter, and drops the received message.  If the
   received NS(DAD) message includes a nonce and no match is found with
   the saved nonce, the node logs a system management message for DAD-
   failed and updates any statistics counter.
Also, some recommended changes about the above paragraph.
   If the node has been configured to use the algorithm of this document and
   an interface on the node receives any NS(DAD) message that matches
   the interface address (in tentative or optimistic state), the
   receiver MUST compare the nonce in the message with the saved nonce. If
   a match is found, the node SHOULD log a system management message, SHOULD update
   any statistics counter, and MUST drop the received message.  If the
   received NS(DAD) message includes a nonce and no match is found with
   the saved nonce, the node SHOULD log a system management message for DAD-
   failed and SHOULD update any statistics counter.



Lastly, i have a question about your example with the provider in "2. Introduction".
Although i don't have the whole picture (the DAD proxying part confused me a little bit) and the term access concentrator isn't very clear to me (we use dsl, not cable), shouldn't there be a warning about duplicate mac or mac-flapping somewhere?
I mean, if i understand correctly the topology, the NS(DAD) message followed the path AC => MODEM1 => HUB => MODEM2 => AC without changing its src mac. Unless the modems are also acting as ND proxies.
Am i thinking something wrong?


Regards,
Tassos


Hemant Singh (shemant) wrote on 14/10/2011 18:45: 
Folks,

Please review this document. 

Thanks,

Hemant

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: Friday, October 14, 2011 11:26 AM
To: Hemant Singh (shemant)
Cc: Hemant Singh (shemant)
Subject: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt

A new version of I-D, draft-hsingh-6man-enhanced-dad-01.txt has been successfully submitted by Hemant Singh and posted to the IETF repository.

Filename:	 draft-hsingh-6man-enhanced-dad
Revision:	 01
Title:		 Enhanced Duplicate Address Detection
Creation date:	 2011-10-14
WG ID:		 Individual Submission
Number of pages: 7

Abstract:
   Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate
   Address Detection (DAD).  However, [RFC4862] does not settle on one
   specific automated means to detect Loopback of Neighbor Discovery
   (ND) [RFC4861] messages used by DAD.  Several service provider
   communities have expressed a need for automated detection of looped
   backed ND messages used by DAD.  This document outlines an algorithm
   to automate detection of looped back IPv6 ND messages used by DAD.
   Further, for certain access networks the document automates resolving
   a specific duplicate address conflict.

                                                                                  


The IETF Secretariat
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
From shemant@cisco.com Fri Oct 14 16:02:51 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCCF21F8BB9 for ; Fri, 14 Oct 2011 16:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.052 X-Spam-Level: X-Spam-Status: No, score=-5.052 tagged_above=-999 required=5 tests=[AWL=1.547, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EssOgctNfN22 for ; Fri, 14 Oct 2011 16:02:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95621F8B77 for ; Fri, 14 Oct 2011 16:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=3736; q=dns/txt; s=iport; t=1318633370; x=1319842970; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=XMsnTD4ioZDfBMGMsHggjeazTXd1w6CTfs94etRvr3s=; b=g0tg7k2GoxmvPA0HhDI2/ta7TdtKxs4KhQzEolUBbePcBxGKWb9zIWQ/ 3/PN0c5H/3OpYT0dOsdhPxT8x16wv3gJVE/KkP/+eUTGLw5JAuyh8mbww +3vOf8kp6lb506kDFdcaSD9t2RNJwp067T9Mw+Cvtk9sqRQH2hcmduSLu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAADi/mE6tJXG8/2dsb2JhbABDhHaUSY4ogQCBBYFuAQEBAQMSARANBDoJAhACAQgOAwQBAQMCBgYXAQICAgEBRAgBCAEBBBMIGodlmSABjEeRfoEshTkzYQSIAZEnjEI X-IronPort-AV: E=Sophos;i="4.69,349,1315180800"; d="scan'208";a="28569531" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 14 Oct 2011 23:02:49 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9EN2mJ9008894; Fri, 14 Oct 2011 23:02:48 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 18:02:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Date: Fri, 14 Oct 2011 18:02:47 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031303C1@XMB-RCD-109.cisco.com> In-Reply-To: <4E98B7AE.9050103@forthnet.gr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyKwLbNoaDcLsoeRj60sIGz7WGdKwAAbmfg References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> From: "Hemant Singh (shemant)" To: "Tassos Chatzithomaoglou" X-OriginalArrivalTime: 14 Oct 2011 23:02:48.0973 (UTC) FILETIME=[64B5D3D0:01CC8AC5] Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 23:02:51 -0000 VGFzc29zLA0KDQpGcm9tOiBUYXNzb3MgQ2hhdHppdGhvbWFvZ2xvdSBbbWFpbHRvOmFjaGF0ekBm b3J0aG5ldC5ncl0gDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTQsIDIwMTEgNjoyOSBQTQ0KVG86 IEhlbWFudCBTaW5naCAoc2hlbWFudCkNCkNjOiBJUHY2IFdHIE1haWxpbmcgTGlzdA0KU3ViamVj dDogUmU6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhzaW5naC02bWFu LWVuaGFuY2VkLWRhZC0wMS50eHQNCg0KDQo+TGFzdGx5LCBpIGhhdmUgYSBxdWVzdGlvbiBhYm91 dCB5b3VyIGV4YW1wbGUgd2l0aCB0aGUgcHJvdmlkZXIgaW4gIjIuIEludHJvZHVjdGlvbiIuDQo+ QWx0aG91Z2ggaSBkb24ndCBoYXZlIHRoZSB3aG9sZSBwaWN0dXJlICh0aGUgREFEIHByb3h5aW5n IHBhcnQgY29uZnVzZWQgbWUgYSBsaXR0bGUgYml0KSBhbmQgdGhlIHRlcm0gYWNjZXNzIGNvbmNl bnRyYXRvciBpc24ndCB2ZXJ5IGNsZWFyIHRvIG1lICh3ZSB1c2UgZHNsLCBub3QgY2FibGUpLCBz aG91bGRuJ3QgdGhlcmUgYmUgYSA+d2FybmluZyBhYm91dCBkdXBsaWNhdGUgbWFjIG9yIG1hYy1m bGFwcGluZyBzb21ld2hlcmU/IA0KPkkgbWVhbiwgaWYgaSB1bmRlcnN0YW5kIGNvcnJlY3RseSB0 aGUgdG9wb2xvZ3ksIHRoZSBOUyhEQUQpIG1lc3NhZ2UgZm9sbG93ZWQgdGhlIHBhdGggQUMgPT4g TU9ERU0xID0+IEhVQiA9PiBNT0RFTTIgPT4gQUMgd2l0aG91dCBjaGFuZ2luZyBpdHMgc3JjIG1h Yy4gPlVubGVzcyB0aGUgbW9kZW1zIGFyZSA+YWxzbyBhY3RpbmcgYXMgTkQgcHJveGllcy4NCg0K VGhlIGNhYmxlIG1vZGVtcyBhcmUgZXNzZW50aWFsbHkgYnJpZGdlcyBhbmQgc28gaXMgdGhlIGh1 Yi4gIFRoYXQgaXMgd2h5IHRoZSBOUyhEQUQpIHRvdGFsbHkgcmVmbGVjdGVkIGJhY2sgdG8gdGhl IEFDIGFzIGlzIHdpdGhvdXQgY2hhbmdpbmcgYW55IHNyYyBtYWMuICBJIHRob3VnaHQgaXQgd291 bGQgYmUgY2xlYXIgYmVjYXVzZSBpZiBhIHBhY2tldCBpcyByZWZsZWN0ZWQgYmFjayBvciBsb29w ZWQgYmFjaywgdGhlIGRldmljZXMgaW4gdGhlIHBhdGggaGF2ZSBnb3QgdG8gYmUgYnJpZGdlcy4g IA0KDQpBaCwgSSBtZWFudCBhIENNVFMgd2hpY2ggaXMgb25lIGV4YW1wbGUgb2YgYW4gYWNjZXNz IGNvbmNlbnRyYXRvci4gIEkgYmVsaWV2ZSB0aGUgSUVURiB1c2VkIHRoZSB0ZXJtIG9mIGFjY2Vz cyBjb25jZW50cmF0b3IgZmlyc3QgaW4gUkZDIDQzODguICAgQ01UUyBpcyBhIENhYmxlIE1vZGVt IFRlcm1pbmF0aW9uIFN5c3RlbSBhbmQgb25lIENpc2NvIENNVFMgY2FuIHN1cHBvcnQgYWJvdXQg NDBLIGNhYmxlIG1vZGVtcyB3aXRoIGFuIGF2ZXJhZ2Ugb2Ygb25lIGhvc3QgUEMvQ1BFIHJvdXRl IGJlaGluZCBlYWNoIGNhYmxlIG1vZGVtLiAgVGhlIERTTCBkZXBsb3ltZW50IGlzIGEgTDIvTDMg c2VnbWVudGVkIG5ldHdvcmsgYW5kIHRodXMgb25lIGRldmljZSBzdWNoIGFzIHRoZSBDTVRTIG1h eSBub3QgYmUgdGhlaXIgTDIgYW5kIEwzIGNvbWJpbmVkIGRldmljZSBpbiBhIERTTEFNIGJ1dCB0 aGUgc2FtZSBjb25jZXB0IGFwcGxpZXMgdG8gRFNMIG5ldHdvcmtzIGFzIHdlbGwuICBCZXR3ZWVu IGNhYmxlIGFuZCBEU0wgdGhlIHdvcmxkd2lkZSBicm9hZGJhbmQgc3Vic2NyaWJlcnMgYXJlIG92 ZXIgMzAwIG1pbGxpb24gaW4gbnVtYmVyLiAgDQoNCkxldCBtZSBleHBsYWluIHRoZSBEQUQgUHJv eHkuICBZb3Ugc2VlLCBpZiB5b3UgaGF2ZSBhIHNpbXBsZSBFdGhlcm5ldCBMQU4gY29ycG9yYXRl IG5ldHdvcmssIHRoZW4gdGhlIE5EIHRyYWZmaWMgYmV0d2VlbiB0aGUgaG9zdHMgaW4gdGhlIExB TiBpcyBzZWVuIGJ5IGFsbCB0aGUgaG9zdHMgYnV0IG5vdCB0aGUgcm91dGVyIGluIHRoZSBMQU4g c2VnbWVudC4gIFRoZSByb3V0ZXIgaGFzIHRvIGltcGxlbWVudCBhIERBRCBQcm94eSBiZWZvcmUg dGhlIHJvdXRlciBjYW4gc2VlIGFsbCBEQUQgbWVzc2FnZXMgb2YgdGhlIExBTiBzZWdtZW50LiAg TW92aW5nIGF3YXkgZnJvbSB0aGUgdHJ1c3RlZCBFdGhlcm5ldCBMQU4gY29ycG9yYXRlIG5ldHdv cmsgdG8gYSBjYWJsZSBicm9hZGJhbmQgQ01UUyBkZXBsb3ltZW50LCB0aGUgQ01UUyBpcyBhIHRy dXN0ZWQgbm9kZSBpbiB0aGUgU1AgZG9tYWluIHdoaWxlIHRoZSBjbGllbnRzIHRoZSBDTVRTIHNl cnZlcywgcmVzaWRlIGluIGEgdW4tdHJ1c3RlZCBkb21haW4uICBUaGUgc3Vic2NyaWJlciBob21l cyBoYXZlIGhhY2tlZCB1cCBtb2RlbXMgb3Igcm91Z2UgUENzIGV0Yy4gIFRoYXQgaXMgd2h5IGlu IHN1Y2ggYSBuZXR3b3JrLCB0aGUgQ01UUyBpbXBsZW1lbnRzIGEgREFEIFByb3h5IHNvIHRoYXQg dGhlIENNVFMgZGVmZW5kcyBlYWNoIElQdjYgbGluay1sb2NhbCBvciBhIGdsb2JhbCBhZGRyZXNz IG9mIGEgY2xpZW50IGJlZm9yZSBhbnkgY2xpZW50IGlzIGFsbG93ZWQgaW4gdGhlIGNhYmxlIG5l dHdvcmsuICBOb3RlIHRoZSBEU0wgYnJvYWRiYW5kIGZvbGtzIGFsc28gaGF2ZSBhIERBRCBQcm94 eSBkcmFmdCBpbiB0aGUgSUVURiA2bWFuIFdHIGluICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtNm1hbi1kYWQtcHJveHkvLiAgIENhYmxlIElQdjYgc3RhbmRhcmRz IHdlcmUgY29tcGxldGVkIGFib3V0IDUtNiB5ZWFycyBiYWNrIGFuZCB0aHVzIGEgQ01UUyBhbHJl YWR5IHN1cHBvcnRzIGEgREFEIFByb3h5Lg0KDQpSZWdhcmRzLA0KDQpIZW1hbnQNCg== From achatz@forthnetgroup.gr Fri Oct 14 16:30:52 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5D221F84FD for ; Fri, 14 Oct 2011 16:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chHtTzcH7qFq for ; Fri, 14 Oct 2011 16:30:52 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id C815721F84FC for ; Fri, 14 Oct 2011 16:30:51 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9ENUoWk025757; Sat, 15 Oct 2011 02:30:50 +0300 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id p9ENUoeP012433; Sat, 15 Oct 2011 02:30:50 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9ENUnOI012872; Sat, 15 Oct 2011 02:30:50 +0300 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4E98C626.2060102@forthnetgroup.gr> Date: Sat, 15 Oct 2011 02:30:46 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet S.A. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1 MIME-Version: 1.0 To: "Hemant Singh (shemant)" Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 23:30:52 -0000 Hemant Singh (shemant) wrote on 15/10/2011 01:41: > Tassos, > > From: Tassos Chatzithomaoglou [mailto:achatz@forthnet.gr] > Sent: Friday, October 14, 2011 6:29 PM > To: Hemant Singh (shemant) > Cc: IPv6 WG Mailing List > Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt > > >> I was wondering...wouldn't the flow label be a "better" field for storing this random number? >> If i remember correctly, early drafts of RPL were using it for loop detection (ok, in a very different way), although in the later ones a new option was chosen. >> Sure, RFC 3697 is very strict on its specification, sure SEND already uses the Nonce option, but since we are talking about ND only (=before any real src/dst flow) i would like to know the>rationale behind of this decision; choosing an extra option instead of a mandatory -useless until recently- field. Maybe then, all ND messages could be supported (less impact on memory?). >> I may have missed some talks about this in the past (or maybe i'm talking nonsense :-[ ), so please forgive me if this is the case. > No forgiveness needed ☺. You have been a great reviewer for lot of documents! The flow label was the first field I and another colleague of mine at Cisco thought of. However yet another colleague of mine shot down the use of Flow Label with the following comments in double quotes. > > “Using the flow label for this is likely to be highly controversial. I can already hear people claiming it's not a "flow", etc.†> > The flow label has another nuance. It's a 20-bit field and thus a nonce generated with such number of bits has one in a million chance of a duplicate. The community may prefer at least a 32-bit nonce or higher. That is why I decided to just use the Nonce Option from SEND in RFC 3971. > > Thus can we move away from the Flow Label and use the Nonce Option from SEND? > > Thanks, > > Hemant > > That is ok with me. Just wanted to know the background story.;-) btw, draft-asati-v6ops-dad-loopback seems to be dealing with the same problem too (but from a different perspective). Section 3.2 of it is quite similar though. Are there any plans to merge these two docs? If not, will there be any references of each other? PS: previous email came from my old address, so i messed things a little bit. Regards, Tassos From brian.e.carpenter@gmail.com Fri Oct 14 16:43:59 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2379721F8CDB for ; Fri, 14 Oct 2011 16:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.954 X-Spam-Level: X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLBtkue4B9si for ; Fri, 14 Oct 2011 16:43:58 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4AE21F8CDA for ; Fri, 14 Oct 2011 16:43:58 -0700 (PDT) Received: by bkas6 with SMTP id s6so866230bka.31 for ; Fri, 14 Oct 2011 16:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zk+1m0xASjSM7be0ZbRbDsSjdyy/lgx5k20vyxvdQdc=; b=S16KhljHd/UsoYEK4IKNPR9T5bXy2mAMWWN/ClpT1Hck2n6RD/IyVHQajpPhnTXe+t D/VdH2nk2xj90JKH9CsHB1M+yvOsbCFXN//vKFkq4/KT0Wj5rBRcg9pd5w3OnR2s4g7J JDKEYQy+Kmobuwp/qaqFvKUOZOKSYrOSD77Q4= Received: by 10.223.7.18 with SMTP id b18mr6977454fab.31.1318635835528; Fri, 14 Oct 2011 16:43:55 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id w14sm6618197fae.13.2011.10.14.16.43.52 (version=SSLv3 cipher=OTHER); Fri, 14 Oct 2011 16:43:54 -0700 (PDT) Message-ID: <4E98C933.4040402@gmail.com> Date: Sat, 15 Oct 2011 12:43:47 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tassos Chatzithomaoglou Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> In-Reply-To: <4E98C626.2060102@forthnetgroup.gr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 23:43:59 -0000 Also remember that 3697 is obsoleted by draft-ietf-6man-flow-3697bis, which is fully approved and very close to becoming an RFC. Regards Brian On 2011-10-15 12:30, Tassos Chatzithomaoglou wrote: >=20 > Hemant Singh (shemant) wrote on 15/10/2011 01:41: >> Tassos, >> >> From: Tassos Chatzithomaoglou [mailto:achatz@forthnet.gr] >> Sent: Friday, October 14, 2011 6:29 PM >> To: Hemant Singh (shemant) >> Cc: IPv6 WG Mailing List >> Subject: Re: FW: New Version Notification for >> draft-hsingh-6man-enhanced-dad-01.txt >> >> >>> I was wondering...wouldn't the flow label be a "better" field for >>> storing this random number? >>> If i remember correctly, early drafts of RPL were using it for loop >>> detection (ok, in a very different way), although in the later ones a= >>> new option was chosen. >>> Sure, RFC 3697 is very strict on its specification, sure SEND already= >>> uses the Nonce option, but since we are talking about ND only >>> (=3Dbefore any real src/dst flow) i would like to know the>rationale >>> behind of this decision; choosing an extra option instead of a >>> mandatory -useless until recently- field. Maybe then, all ND messages= >>> could be supported (less impact on memory?). >>> I may have missed some talks about this in the past (or maybe i'm >>> talking nonsense :-[ ), so please forgive me if this is the case. >> No forgiveness needed =E2=98=BA. You have been a great reviewer for l= ot of >> documents! The flow label was the first field I and another colleague= >> of mine at Cisco thought of. However yet another colleague of mine >> shot down the use of Flow Label with the following comments in double >> quotes. >> >> =E2=80=9CUsing the flow label for this is likely to be highly controve= rsial.=20 >> I can already hear people claiming it's not a "flow", etc.=E2=80=9D >> >> The flow label has another nuance. It's a 20-bit field and thus a >> nonce generated with such number of bits has one in a million chance >> of a duplicate. The community may prefer at least a 32-bit nonce or >> higher. That is why I decided to just use the Nonce Option from SEND >> in RFC 3971. >> >> Thus can we move away from the Flow Label and use the Nonce Option >> from SEND? >> >> Thanks, >> >> Hemant >> >> > That is ok with me. Just wanted to know the background story.;-) >=20 >=20 > btw, draft-asati-v6ops-dad-loopback seems to be dealing with the same > problem too (but from a different perspective). Section 3.2 of it is > quite similar though. > Are there any plans to merge these two docs? If not, will there be any > references of each other? >=20 > PS: previous email came from my old address, so i messed things a littl= e > bit. >=20 > Regards, > Tassos >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From shemant@cisco.com Fri Oct 14 16:57:03 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A3621F8CE6 for ; Fri, 14 Oct 2011 16:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.833 X-Spam-Level: X-Spam-Status: No, score=-4.833 tagged_above=-999 required=5 tests=[AWL=1.166, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zBL0CUV7r-V for ; Fri, 14 Oct 2011 16:57:02 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A932821F8C6F for ; Fri, 14 Oct 2011 16:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2218; q=dns/txt; s=iport; t=1318636622; x=1319846222; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=cyqfecLjC765Jv3W63ovXe4cFNwfeHzmFITNKmjjjGk=; b=PuQiLejnFJnJvY71aXPeTMXisvh0hD+iIoca7FU9ms3fsabTKevGFnRA 2R4c3RxOwjfs06LkDAG/2Z9ltfu5C41h3fsJUqtki1A4ocWysl4NZJ6fb UFwnvra38jie2ITdB8/n752TecDPRRmjlGqYXHpl3NnnfqDtNivSPyS3n 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAOLKmE6tJXG9/2dsb2JhbABDhHaUSY4ogQCBBYFuAQEBAQMSARANBDoJAgwEAgEIDgMEAQEDAgYGFwECAgIBAUQIAQgBAQQTCBMHoGYBjEeReoEshTkzYQSIAZEnjEI X-IronPort-AV: E=Sophos;i="4.69,349,1315180800"; d="scan'208";a="28601458" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 14 Oct 2011 23:57:02 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9ENv2NF020130; Fri, 14 Oct 2011 23:57:02 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 18:57:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Date: Fri, 14 Oct 2011 18:57:00 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031303D6@XMB-RCD-109.cisco.com> In-Reply-To: <4E98C626.2060102@forthnetgroup.gr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyKyVAdqLjzTdJwSIyfxf6YQKKQugAAa2og References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> From: "Hemant Singh (shemant)" To: "Tassos Chatzithomaoglou" X-OriginalArrivalTime: 14 Oct 2011 23:57:02.0291 (UTC) FILETIME=[F7D6C230:01CC8ACC] Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 23:57:03 -0000 VGFzc29zLA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVGFzc29zIENoYXR6 aXRob21hb2dsb3UgW21haWx0bzphY2hhdHpAZm9ydGhuZXRncm91cC5ncl0gDQpTZW50OiBGcmlk YXksIE9jdG9iZXIgMTQsIDIwMTEgNzozMSBQTQ0KVG86IEhlbWFudCBTaW5naCAoc2hlbWFudCkN CkNjOiBJUHY2IFdHIE1haWxpbmcgTGlzdA0KU3ViamVjdDogUmU6IEZXOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWhzaW5naC02bWFuLWVuaGFuY2VkLWRhZC0wMS50eHQNCg0K DQo+YnR3LCBkcmFmdC1hc2F0aS12Nm9wcy1kYWQtbG9vcGJhY2sgc2VlbXMgdG8gYmUgZGVhbGlu ZyB3aXRoIHRoZSBzYW1lIHByb2JsZW0gdG9vIChidXQgZnJvbSBhIGRpZmZlcmVudCBwZXJzcGVj dGl2ZSkuIA0KPlNlY3Rpb24gMy4yIG9mIGl0IGlzIHF1aXRlIHNpbWlsYXIgdGhvdWdoLg0KPkFy ZSB0aGVyZSBhbnkgcGxhbnMgdG8gbWVyZ2UgdGhlc2UgdHdvIGRvY3M/IElmIG5vdCwgd2lsbCB0 aGVyZSBiZSBhbnkgcmVmZXJlbmNlcyBvZiBlYWNoIG90aGVyPw0KDQpUaGUgYXNhdGkgZG9jdW1l bnQgdXNlcyBhIHByb2JlIGFmdGVyIGEgZmlyc3QgTlMgaGFzIGJlZW4gc2VudCBhbmQgdGhlIE5T IGlzIGxvb3BlZCBiYWNrLiAgVGhlIHByb2JlIGhhcyBhIHRpbWVyIHRvby4gIEZ1cnRoZXIgdGhl IGFzYXRpIGRvY3VtZW50IGRvZXMgbm90IG1lbnRpb24gd2hhdCBzdGF0ZSBpcyB0aGUgbm9kZSBp biBkdXJpbmcgdGhlIHByb2JlLiAgIFRoZXJlIGFyZSBvcGVuIHF1ZXN0aW9ucyBhbmQgbm8gY29t cGxldGVkIHN0YXRlIG1hY2hpbmUgdGhhdCBkb2Vzbid0IG1ha2UgdGhlIHNvbHV0aW9uIDIgd29y a2FibGUgYXMgZGVzY3JpYmVkIGluIHRoZSAtMDEgYXNhdGkgZG9jdW1lbnQuICBJIHdvdWxkIGhh dmUgdGFsa2VkIHRvIFJhaml2IGJ1dCB0aGUgd2VlayB3ZSByZWxlYXNlZCBvdXQgZG9jdW1lbnQg aGUgaXMgb3V0IG9uIHZhY2F0aW9uIGZvciB0aGUgd2hvbGUgd2Vlay4gIEkgYWxyZWFkeSBlbWFp bGVkIG9uZSBwcm9wb3NhbCBmb3IgaG93IHRvIGRlYWwgd2l0aCB0aGUgdHdvIGRvY3VtZW50cyB0 byB2Nm9wcyBhbmQgSSBiZWxpZXZlIGFsc28gY2NlZCB0byA2bWFuLiAgDQoNCkkgcHJvcG9zZWQg dGhhdCB0aGUgYXNhdGkgZG9jdW1lbnQgcmVtb3ZlcyBzZWN0aW9uIDMuMiBhbmQgYW55IG90aGVy IHNlY3Rpb24gdGhhdCBwcm9wb3NlcyBhbiBhdXRvbWF0ZWQgc29sdXRpb24gdG8gZGV0ZWN0IHJl ZmxlY3RlZCBEQURzLiAgVGhlbiB0aGUgYXNhdGkgcmVmZXJlbmNlcyBkcmFmdC1oc2luZ2gtNm1h bi1lbmhhbmNlZC1kYWQgZm9yIGFuIGF1dG9tYXRlZCBzb2x1dGlvbi4gIFRoYXQgY2hhbmdlcyB0 aGUgYXNhdGkgZG9jdW1lbnQgYXMgYSBQcm9ibGVtIFN0YXRlbWVudCBkb2N1bWVudCB0aGF0IGFs c28gaW5jbHVkZXMgTWl0aWdhdGlvbiByZW1lZGllcyBhbmQgdGhlIGRvY3VtZW50IGNhbiBiZSBt b3ZlZCBpbiB2Nm9wcy4gIA0KDQpQUzogcHJldmlvdXMgZW1haWwgY2FtZSBmcm9tIG15IG9sZCBh ZGRyZXNzLCBzbyBpIG1lc3NlZCB0aGluZ3MgYSBsaXR0bGUgYml0Lg0KDQpObyBwcm9ibGVtLg0K DQpSZWdhcmRzLA0KDQpIZW1hbnQNCg== From jreddy@ti.com Fri Oct 14 17:15:08 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF03A21F8C6F for ; Fri, 14 Oct 2011 17:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wu+bLq13xrlE for ; Fri, 14 Oct 2011 17:15:08 -0700 (PDT) Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by ietfa.amsl.com (Postfix) with ESMTP id EFCF221F8B8E for ; Fri, 14 Oct 2011 17:15:07 -0700 (PDT) Received: from dlep34.itg.ti.com ([157.170.170.115]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id p9F0F65P024473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Oct 2011 19:15:06 -0500 Received: from dlep26.itg.ti.com (smtp-le.itg.ti.com [157.170.170.27]) by dlep34.itg.ti.com (8.13.7/8.13.8) with ESMTP id p9F0F6vk022891 for ; Fri, 14 Oct 2011 19:15:06 -0500 (CDT) Received: from DFLE70.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p9F0F68w018565 for ; Fri, 14 Oct 2011 19:15:06 -0500 (CDT) Received: from DFLE31.ent.ti.com ([fe80::e8cd:b360:bb27:563f]) by DFLE70.ent.ti.com ([fe80::db3:609a:aa62:e1ec%22]) with mapi id 14.01.0323.003; Fri, 14 Oct 2011 19:15:06 -0500 From: "Reddy, Joseph" To: "ipv6@ietf.org" Subject: Re: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt Thread-Topic: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt Thread-Index: AQHMis99Qa8fjJf8MkqNrmNKvj3mnA== Date: Sat, 15 Oct 2011 00:15:05 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DBEBC804@DFLE31.ent.ti.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.170.170.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 00:15:08 -0000 Hi Jonathan, The draft uses the term "RPL domain" in several places and this is not clea= rly defined.=20 I would imagine that it includes all nodes that are downstream of the RPL b= order router. But can you clarify if Host nodes that are downstream of the = border router but do not implement any part of RPL ( even as RPL Leaf nodes= ) should be considered part of the "RPL domain" ? In section 5, the draft now says "..Datagrams destined to nodes outside the= RPL domain are dropped if the outer-most IPv6 header contains a RPL Option= ..." This text would imply that any RPL node sending packets to nodes outside sh= ould always tunnel to the Root ? Is that the intention really or am I missi= ng something here..=20 Also note that if non-RPL Host is not considered part of the RPL domain, th= en I am not sure that a forwarding router can know if the destination is in= side the domain or not.=20 -Regards, Joseph ------------------------------ Message: 5 Date: Tue, 11 Oct 2011 22:23:10 -0700 From: Jonathan Hui To: IETF IPv6 Mailing List Subject: Fwd: I-D Action: draft-ietf-6man-rpl-option-04.txt Message-ID: <69ACD1F4-D0FA-4B94-8648-48F8CAFEB3EC@cisco.com> Content-Type: text/plain; charset=3Dus-ascii This update is intended to address Jari Arkko's AD review. Summary of changes: - Clarify when the RPL Option is used. - Updated text on recommendations for avoiding fragmentation. - Specify skip-over-and-continue policy for unrecognized sub-TLVs. - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST. - Specify RPL Border Router operations in terms of forwarding decision outc= omes. - Expand security section. -- Jonathan Hui Begin forwarded message: > From: internet-drafts@ietf.org > Date: October 11, 2011 10:17:15 PM PDT > To: i-d-announce@ietf.org > Cc: ipv6@ietf.org > Subject: I-D Action: draft-ietf-6man-rpl-option-04.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. This draft is a work item of the IPv6 Maintenance Working Group of t= he IETF. >=20 > Title : RPL Option for Carrying RPL Information in Data-Plane = Datagrams > Author(s) : Jonathan W. Hui > JP Vasseur > Filename : draft-ietf-6man-rpl-option-04.txt > Pages : 14 > Date : 2011-10-11 >=20 > The RPL protocol requires data-plane datagrams to carry RPL routing > information that is processed by RPL routers when forwarding those > datagrams. This document describes the RPL Option for use within a > RPL domain. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-04.txt > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From achatz@forthnetgroup.gr Fri Oct 14 17:17:27 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3211221F8CC2 for ; Fri, 14 Oct 2011 17:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyP383viVXQg for ; Fri, 14 Oct 2011 17:17:26 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB1921F8CA2 for ; Fri, 14 Oct 2011 17:17:26 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9F0HOxM013494; Sat, 15 Oct 2011 03:17:24 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9F0HOQt021138; Sat, 15 Oct 2011 03:17:24 +0300 Received: from [192.168.1.2] (194.219.113.191.dsl.dyn.forthnet.gr [194.219.113.191]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9F0HEUA017659; Sat, 15 Oct 2011 03:17:15 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4E98D102.3060601@forthnetgroup.gr> Date: Sat, 15 Oct 2011 03:17:06 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <4E98C933.4040402@gmail.com> In-Reply-To: <4E98C933.4040402@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 00:17:27 -0000 I have no objection Brian. I can understand the reason for keeping the flow label "clean". I was just wondering if there were any plans to use the flow label for ND traffic too, or we should consider that there are no real flows there. Regards, Tassos Brian E Carpenter wrote on 15/10/2011 02:43: > Also remember that 3697 is obsoleted by draft-ietf-6man-flow-3697bis, > which is fully approved and very close to becoming an RFC. > > Regards > Brian > > On 2011-10-15 12:30, Tassos Chatzithomaoglou wrote: >> Hemant Singh (shemant) wrote on 15/10/2011 01:41: >>> Tassos, >>> >>> From: Tassos Chatzithomaoglou [mailto:achatz@forthnet.gr] >>> Sent: Friday, October 14, 2011 6:29 PM >>> To: Hemant Singh (shemant) >>> Cc: IPv6 WG Mailing List >>> Subject: Re: FW: New Version Notification for >>> draft-hsingh-6man-enhanced-dad-01.txt >>> >>> >>>> I was wondering...wouldn't the flow label be a "better" field for >>>> storing this random number? >>>> If i remember correctly, early drafts of RPL were using it for loop >>>> detection (ok, in a very different way), although in the later ones a >>>> new option was chosen. >>>> Sure, RFC 3697 is very strict on its specification, sure SEND already >>>> uses the Nonce option, but since we are talking about ND only >>>> (=before any real src/dst flow) i would like to know the>rationale >>>> behind of this decision; choosing an extra option instead of a >>>> mandatory -useless until recently- field. Maybe then, all ND messages >>>> could be supported (less impact on memory?). >>>> I may have missed some talks about this in the past (or maybe i'm >>>> talking nonsense :-[ ), so please forgive me if this is the case. >>> No forgiveness needed ☺. You have been a great reviewer for lot of >>> documents! The flow label was the first field I and another colleague >>> of mine at Cisco thought of. However yet another colleague of mine >>> shot down the use of Flow Label with the following comments in double >>> quotes. >>> >>> “Using the flow label for this is likely to be highly controversial. >>> I can already hear people claiming it's not a "flow", etc.†>>> >>> The flow label has another nuance. It's a 20-bit field and thus a >>> nonce generated with such number of bits has one in a million chance >>> of a duplicate. The community may prefer at least a 32-bit nonce or >>> higher. That is why I decided to just use the Nonce Option from SEND >>> in RFC 3971. >>> >>> Thus can we move away from the Flow Label and use the Nonce Option >>> from SEND? >>> >>> Thanks, >>> >>> Hemant >>> >>> >> That is ok with me. Just wanted to know the background story.;-) >> >> >> btw, draft-asati-v6ops-dad-loopback seems to be dealing with the same >> problem too (but from a different perspective). Section 3.2 of it is >> quite similar though. >> Are there any plans to merge these two docs? If not, will there be any >> references of each other? >> >> PS: previous email came from my old address, so i messed things a little >> bit. >> >> Regards, >> Tassos >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > From shemant@cisco.com Fri Oct 14 17:24:59 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB0621F8BCD for ; Fri, 14 Oct 2011 17:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.258 X-Spam-Level: X-Spam-Status: No, score=-5.258 tagged_above=-999 required=5 tests=[AWL=1.341, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALtQCplOIRGp for ; Fri, 14 Oct 2011 17:24:58 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B0D9421F8BC4 for ; Fri, 14 Oct 2011 17:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1812; q=dns/txt; s=iport; t=1318638295; x=1319847895; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=G4zA6mb7oHwrOwbvYBf+pGdYmITZmvRv7DkZv03wZ1E=; b=ANjlGQ6Wrz4pinrYFsiZ/f+fCUahnblAk5DPtIZDToSqdB5Vr7xTkV5M HLu2Sj7j5CvxLKcy6xbKDkPf45zU9+TzwK0t1/Gbcn47LJ7e+8c+l6XtU qQl1O7ky+tFUsGag5tnqnw/p4SsInVMUBvgnoj6W0xp8qK7ntHLyZCfrI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAEDSmE6tJV2Z/2dsb2JhbABDhHaUSY4ogQCBBYFuAQEBAQMSARANBDoJAgwEAgEIDgMEAQEDAgYGFwECAgIBAUQIAQgBAQQBEggaoHIBjEeRd4EshTkzYQSIAZEnjEI X-IronPort-AV: E=Sophos;i="4.69,349,1315180800"; d="scan'208";a="28604140" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2011 00:24:55 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9F0Ot4I000978; Sat, 15 Oct 2011 00:24:55 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 19:24:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Date: Fri, 14 Oct 2011 19:24:54 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031303DE@XMB-RCD-109.cisco.com> In-Reply-To: <4E98D102.3060601@forthnetgroup.gr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyKz9HFL+CNmVP4S/q76qlUXCDrugAACrKA References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <4E98C933.4040402@gmail.com> <4E98D102.3060601@forthnetgroup.gr> From: "Hemant Singh (shemant)" To: "Tassos Chatzithomaoglou" , "Brian E Carpenter" X-OriginalArrivalTime: 15 Oct 2011 00:24:55.0584 (UTC) FILETIME=[DD330200:01CC8AD0] Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 00:24:59 -0000 QnJpYW4sDQoNClRoYW5rcyBmb3IgdGhlIHJlZmVyZW5jZS4gIEJUVywgSSB3YXMgcmVsYXRpdmVs eSBzb2xkIG9uIHVzaW5nIHRoZSBGbG93IExhYmVsIHRvIHN0aWNrIGEgbm9uY2UgaW50byBmb3Ig TkQgdHJhZmZpYyBiZWNhdXNlIE5EIHRyYWZmaWMgcmVtYWlucyBpbiB0aGUgbGluay1sb2NhbCBk b21haW4gYW5kIGlzIGNvbnRyb2wgdHJhZmZpYy4gIEl0J3Mgbm90IGxpa2UgYSBub25jZSBsYWJl bGVkIEZsb3cgTGFiZWwgZGF0YSBwYWNrZXQgaXMgbGVha2luZyBvdXQgdG8gdGhlIHdpZGUgYXJl YSBuZXR3b3JrLiAgQWxzbyB3aXRoIHRoZSBGbG93IExhYmVsIHRoZXJlIGlzIGxlc3MgY29uZnVz aW9uIHZzLiB3aGVuIHdlIHVzZSB0aGUgTm9uY2UgT3B0aW9uIGRlZmluZWQgZnJvbSBTRU5ELiAg SW4gYSBtaXhlZCBTRU5EIGFuZCB1bnNlY3VyZWQgKG5vIFNFTkQpIG5ldHdvcmssIHRoZSBsZW5n dGhzIG9mIHRoZSBub25jZXMgTVVTVCBiZSB0aGUgc2FtZS4gIE90aGVyd2lzZSBzb21lIHNsb3Bw eSBpbXBsZW1lbnRhdGlvbiBjYW4gY2F1c2UgYSBidWZmZXIgb3ZlcnJ1biBwYXJzaW5nIHRoZSBu b25jZS4gIA0KDQpJdCB3YXMgdGhlIDIwLWJpdHMgaW4gdGhlIEZsb3cgTGFiZWwgdGhhdCB3YXMg b25lIGJpZyByZWFzb24gdG8gZGl0Y2ggdXNpbmcgaXQgYW5kIHRoZW4gb3RoZXIgd2FzIHdoYXQg bXkgY29sbGVhZ3VlIHNhaWQgYWJvdXQgb3ZlcmxvYWRpbmcgdGhlIEZsb3cgTGFiZWwuIA0KDQpS ZWdhcmRzLA0KDQpIZW1hbnQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRh c3NvcyBDaGF0eml0aG9tYW9nbG91IFttYWlsdG86YWNoYXR6QGZvcnRobmV0Z3JvdXAuZ3JdIA0K U2VudDogRnJpZGF5LCBPY3RvYmVyIDE0LCAyMDExIDg6MTcgUE0NClRvOiBCcmlhbiBFIENhcnBl bnRlcg0KQ2M6IEhlbWFudCBTaW5naCAoc2hlbWFudCk7IElQdjYgV0cgTWFpbGluZyBMaXN0DQpT dWJqZWN0OiBSZTogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaHNpbmdo LTZtYW4tZW5oYW5jZWQtZGFkLTAxLnR4dA0KDQpJIGhhdmUgbm8gb2JqZWN0aW9uIEJyaWFuLiBJ IGNhbiB1bmRlcnN0YW5kIHRoZSByZWFzb24gZm9yIGtlZXBpbmcgdGhlIGZsb3cgbGFiZWwgImNs ZWFuIi4NCg0KSSB3YXMganVzdCB3b25kZXJpbmcgaWYgdGhlcmUgd2VyZSBhbnkgcGxhbnMgdG8g dXNlIHRoZSBmbG93IGxhYmVsIGZvciBORCB0cmFmZmljIHRvbywgb3IgDQp3ZSBzaG91bGQgY29u c2lkZXIgdGhhdCB0aGVyZSBhcmUgbm8gcmVhbCBmbG93cyB0aGVyZS4NCg0KUmVnYXJkcywNClRh c3Nvcw0KDQoNCg== From achatz@forthnetgroup.gr Fri Oct 14 17:29:00 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC6221F8CC2 for ; Fri, 14 Oct 2011 17:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxt6y0W4lHwG for ; Fri, 14 Oct 2011 17:29:00 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF3C21F8CBF for ; Fri, 14 Oct 2011 17:28:59 -0700 (PDT) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9F0SwBv012370; Sat, 15 Oct 2011 03:28:58 +0300 Received: from MX-IN-11.forthnet.gr (mx-in-11.forthnet.gr [193.92.150.31]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9F0SwrF026095; Sat, 15 Oct 2011 03:28:58 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-11.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9F0Svlp013817; Sat, 15 Oct 2011 03:28:58 +0300 Authentication-Results: MX-IN-11.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4E98D3C6.6090509@forthnetgroup.gr> Date: Sat, 15 Oct 2011 03:28:54 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet S.A. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1 MIME-Version: 1.0 To: "Hemant Singh (shemant)" Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303D6@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031303D6@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 00:29:00 -0000 Hemant Singh (shemant) wrote on 15/10/2011 02:57: > Tassos, > > -----Original Message----- > From: Tassos Chatzithomaoglou [mailto:achatz@forthnetgroup.gr] > Sent: Friday, October 14, 2011 7:31 PM > To: Hemant Singh (shemant) > Cc: IPv6 WG Mailing List > Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt > > >> btw, draft-asati-v6ops-dad-loopback seems to be dealing with the same problem too (but from a different perspective). >> Section 3.2 of it is quite similar though. >> Are there any plans to merge these two docs? If not, will there be any references of each other? > The asati document uses a probe after a first NS has been sent and the NS is looped back. The probe has a timer too. Further the asati document does not mention what state is the node in during the probe. There are open questions and no completed state machine that doesn't make the solution 2 workable as described in the -01 asati document. I would have talked to Rajiv but the week we released out document he is out on vacation for the whole week. I already emailed one proposal for how to deal with the two documents to v6ops and I believe also cced to 6man. > > I proposed that the asati document removes section 3.2 and any other section that proposes an automated solution to detect reflected DADs. Then the asati references draft-hsingh-6man-enhanced-dad for an automated solution. That changes the asati document as a Problem Statement document that also includes Mitigation remedies and the document can be moved in v6ops. > That works for me. -- Tassos From achatz@forthnetgroup.gr Sat Oct 15 04:49:47 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCBE21F8B1E for ; Sat, 15 Oct 2011 04:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.356 X-Spam-Level: X-Spam-Status: No, score=-1.356 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEcHZoyNmMPm for ; Sat, 15 Oct 2011 04:49:47 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 1615D21F8A66 for ; Sat, 15 Oct 2011 04:49:46 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9FBnkBm007028; Sat, 15 Oct 2011 14:49:46 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9FBnjJc010700; Sat, 15 Oct 2011 14:49:45 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id p9FBna9T022593; Sat, 15 Oct 2011 14:49:36 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4E99734C.5050304@forthnetgroup.gr> Date: Sat, 15 Oct 2011 14:49:32 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet S.A. User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <4E98C933.4040402@gmail.com> <4E98D102.3060601@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303DE@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031303DE@XMB-RCD-109.cisco.com> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 11:49:48 -0000 Also, looking at draft-ietf-6man-flow-3697bis-07, i can see the following under introduction:

A stateful
   scenario is one where a node that processes the flow label value
   needs to store information about the flow, including the flow label
   value.
...
   The flow label can be used most simply in stateless scenarios.  This
   specification concentrates on the stateless model and how it can be
   used as a default mechanism.  Details of stateful models, signaling,
   specific flow state establishment methods and their related service
   models are out of scope for this specification.
Does this mean that the usage of flow label on ND/DAD is out of scope of 3697bis?

--
Tassos

Hemant Singh (shemant) wrote on 15/10/2011 03:24: 
Brian,

Thanks for the reference.  BTW, I was relatively sold on using the Flow Label to stick a nonce into for ND traffic because ND traffic remains in the link-local domain and is control traffic.  It's not like a nonce labeled Flow Label data packet is leaking out to the wide area network.  Also with the Flow Label there is less confusion vs. when we use the Nonce Option defined from SEND.  In a mixed SEND and unsecured (no SEND) network, the lengths of the nonces MUST be the same.  Otherwise some sloppy implementation can cause a buffer overrun parsing the nonce.  

It was the 20-bits in the Flow Label that was one big reason to ditch using it and then other was what my colleague said about overloading the Flow Label. 

Regards,

Hemant

-----Original Message-----
From: Tassos Chatzithomaoglou [mailto:achatz@forthnetgroup.gr] 
Sent: Friday, October 14, 2011 8:17 PM
To: Brian E Carpenter
Cc: Hemant Singh (shemant); IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt

I have no objection Brian. I can understand the reason for keeping the flow label "clean".

I was just wondering if there were any plans to use the flow label for ND traffic too, or 
we should consider that there are no real flows there.

Regards,
Tassos
From shemant@cisco.com Sat Oct 15 05:55:34 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144AE21F8B3E for ; Sat, 15 Oct 2011 05:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=1.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX1tBrYzOH3p for ; Sat, 15 Oct 2011 05:55:33 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 53FA021F8B1C for ; Sat, 15 Oct 2011 05:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9644; q=dns/txt; s=iport; t=1318683333; x=1319892933; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=+EgndPwG7fYyhoR2MEH//1uYtDYhOUIZcvHaKuXxZ6A=; b=UOnHHqL4Zc8IhX+YxxtDujg5dfBqi2KPFuptQBoM5HhUx+ax8DLz3Ioj Ufpql5FDxcfzO1OUnPdkdpKF8pqrNo40islli3C6XmvaR7TigXqThOrzD BDvYKyYY7O3BJ4Bh4JP63ia5taZfw/5C5KvDzyX29QZMTtX51110iW3Z+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYAAAuCmU6tJV2Z/2dsb2JhbABDgk2CKJRHjiiBAIEFgW4BAQEBAxIBCQcKAz4JAhACAQgOAwQBAQsGFwECAgIBAUQIAQgBAQQBEggaoAwBjEeRJYZ0M2EEiAKRKoxC X-IronPort-AV: E=Sophos;i="4.69,350,1315180800"; d="scan'208,217";a="28664038" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 15 Oct 2011 12:55:32 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9FCtWXp026807; Sat, 15 Oct 2011 12:55:32 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 15 Oct 2011 07:55:32 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8B39.B91C3F95" Subject: RE: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Date: Sat, 15 Oct 2011 07:55:31 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303130411@XMB-RCD-109.cisco.com> In-Reply-To: <4E99734C.5050304@forthnetgroup.gr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyLMIpvCBFPWP5kRpSjTHBs6ttNOwACCdFQ References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <4E98C933.4040402@gmail.com> <4E98D102.3060601@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303DE@XMB-RCD-109.cisco.com> <4E99734C.5050304@forthnetgroup.gr> From: "Hemant Singh (shemant)" To: "Tassos Chatzithomaoglou" , "Brian E Carpenter" X-OriginalArrivalTime: 15 Oct 2011 12:55:32.0666 (UTC) FILETIME=[B96459A0:01CC8B39] Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 12:55:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8B39.B91C3F95 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBjZXJ0YWlubHkgZG9u4oCZdCBiZWxpZXZlIHNvLiAgIFRoZSB1c3VhbCB1c2Ugb2YgRmxvdyBM YWJlbCBzZWVtcyB0byBhc3N1bWUgdGhlIGxhYmVsZWQgcGFja2V0IHRyYXZlcnNlcyBtb3JlIHRo YW4gb25lIGhvcC4gIEFmdGVyIGFsbCwgdGhlIHR5cGljYWwgdXNlIG9mIHRoZSBGbG93IExhYmVs IGlzIHRvIGxldCBlYWNoIGhvcCBrbm93IHdoYXQgcHJvY2Vzc2luZyB0byBkbyBiYXNlZCBvbiB0 aGUgRmxvdyBMYWJlbC4gICBIb3dldmVyLCBhIGxpbmstbG9jYWwgZG9tYWluIHdob3NlIHRyYWZm aWMgaXMgcmVzdHJpY3RlZCB0byB3aXRoaW4gb25lIGxpbmsgd2l0aCBubyB0cmF2ZXJzYWwgYWNy b3NzIGEgcm91dGVyL2hvcCwgdGhlIEZsb3cgTGFiZWwgZG9lcyBub3QgaGF2ZSBhIGhvcC1ieS1o b3AgdXNlIGJ1dCBjZXJ0YWlubHkgaWYgc29tZSBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSBwcm92 aWRlZCB0byBhbGwgbm9kZXMgdGhlIGZsb3cgbGFiZWwgY2FuIGJlIHVzZWQuICBCdXQgc3VjaCBp bmZvcm1hdGlvbiBpcyBiZXN0IHByb3ZpZGVkIGJ5IHRoZSBjb250cm9sIHByb3RvY29sIG9mIE5E IHVzZWQgaW4gdGhlIGxpbmsuICBTbyB3aHkgb3ZlcmxvYWQgdGhlIEZsb3cgTGFiZWwuICAgQW55 d2F5LCBzb21lIGZvbGtzIG1heSBub3QgbGlrZSB0aGUgc21hbGwgc2l6ZSBvZiAyMCBiaXRzIHRv IGJlIHVzZWQgaW4gYSBub25jZSAuDQoNCiANCg0KSGVtYW50DQoNCiANCg0KRnJvbTogVGFzc29z IENoYXR6aXRob21hb2dsb3UgW21haWx0bzphY2hhdHpAZm9ydGhuZXRncm91cC5ncl0gDQpTZW50 OiBTYXR1cmRheSwgT2N0b2JlciAxNSwgMjAxMSA3OjUwIEFNDQpUbzogQnJpYW4gRSBDYXJwZW50 ZXINCkNjOiBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpOyBJUHY2IFdHIE1haWxpbmcgTGlzdA0KU3Vi amVjdDogUmU6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWhzaW5naC02 bWFuLWVuaGFuY2VkLWRhZC0wMS50eHQNCg0KIA0KDQpBbHNvLCBsb29raW5nIGF0IGRyYWZ0LWll dGYtNm1hbi1mbG93LTM2OTdiaXMtMDcsIGkgY2FuIHNlZSB0aGUgZm9sbG93aW5nIHVuZGVyIGlu dHJvZHVjdGlvbjoNCg0KQSBzdGF0ZWZ1bA0KICAgc2NlbmFyaW8gaXMgb25lIHdoZXJlIGEgbm9k ZSB0aGF0IHByb2Nlc3NlcyB0aGUgZmxvdyBsYWJlbCB2YWx1ZQ0KICAgbmVlZHMgdG8gc3RvcmUg aW5mb3JtYXRpb24gYWJvdXQgdGhlIGZsb3csIGluY2x1ZGluZyB0aGUgZmxvdyBsYWJlbA0KICAg dmFsdWUuIA0KDQouLi4NCg0KICAgVGhlIGZsb3cgbGFiZWwgY2FuIGJlIHVzZWQgbW9zdCBzaW1w bHkgaW4gc3RhdGVsZXNzIHNjZW5hcmlvcy4gIFRoaXMNCiAgIHNwZWNpZmljYXRpb24gY29uY2Vu dHJhdGVzIG9uIHRoZSBzdGF0ZWxlc3MgbW9kZWwgYW5kIGhvdyBpdCBjYW4gYmUNCiAgIHVzZWQg YXMgYSBkZWZhdWx0IG1lY2hhbmlzbS4gIERldGFpbHMgb2Ygc3RhdGVmdWwgbW9kZWxzLCBzaWdu YWxpbmcsDQogICBzcGVjaWZpYyBmbG93IHN0YXRlIGVzdGFibGlzaG1lbnQgbWV0aG9kcyBhbmQg dGhlaXIgcmVsYXRlZCBzZXJ2aWNlDQogICBtb2RlbHMgYXJlIG91dCBvZiBzY29wZSBmb3IgdGhp cyBzcGVjaWZpY2F0aW9uLiAgDQogDQoNCkRvZXMgdGhpcyBtZWFuIHRoYXQgdGhlIHVzYWdlIG9m IGZsb3cgbGFiZWwgb24gTkQvREFEIGlzIG91dCBvZiBzY29wZSBvZiAzNjk3YmlzPw0KDQotLQ0K VGFzc29zDQoNCg0KDQoNCiANCg== ------_=_NextPart_001_01CC8B39.B91C3F95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGJnY29sb3I9d2hp dGUgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rp b24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgY2VydGFpbmx5 IGRvbuKAmXQgYmVsaWV2ZSBzby7CoMKgIFRoZSB1c3VhbCB1c2Ugb2YgRmxvdyBMYWJlbCBzZWVt cyB0byBhc3N1bWUgdGhlIGxhYmVsZWQgcGFja2V0IHRyYXZlcnNlcyBtb3JlIHRoYW4gb25lIGhv cC7CoCBBZnRlciBhbGwsIHRoZSB0eXBpY2FsIHVzZSBvZiB0aGUgRmxvdyBMYWJlbCBpcyB0byBs ZXQgZWFjaCBob3Aga25vdyB3aGF0IHByb2Nlc3NpbmcgdG8gZG8gYmFzZWQgb24gdGhlIEZsb3cg TGFiZWwuwqAgwqBIb3dldmVyLCBhIGxpbmstbG9jYWwgZG9tYWluIHdob3NlIHRyYWZmaWMgaXMg cmVzdHJpY3RlZCB0byB3aXRoaW4gb25lIGxpbmsgd2l0aCBubyB0cmF2ZXJzYWwgYWNyb3NzIGEg cm91dGVyL2hvcCwgdGhlIEZsb3cgTGFiZWwgZG9lcyBub3QgaGF2ZSBhIGhvcC1ieS1ob3AgdXNl IGJ1dCBjZXJ0YWlubHkgaWYgc29tZSBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSBwcm92aWRlZCB0 byBhbGwgbm9kZXMgdGhlIGZsb3cgbGFiZWwgY2FuIGJlIHVzZWQuwqAgQnV0IHN1Y2ggaW5mb3Jt YXRpb24gaXMgYmVzdCBwcm92aWRlZCBieSB0aGUgY29udHJvbCBwcm90b2NvbCBvZiBORCB1c2Vk IGluIHRoZSBsaW5rLsKgIFNvIHdoeSBvdmVybG9hZCB0aGUgRmxvdyBMYWJlbC7CoMKgIEFueXdh eSwgc29tZSBmb2xrcyBtYXkgbm90IGxpa2UgdGhlIHNtYWxsIHNpemUgb2YgMjAgYml0cyB0byBi ZSB1c2VkIGluIGEgbm9uY2UgLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGVtYW50PG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBj bGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7Y29sb3I6d2luZG93dGV4dCc+IFRhc3NvcyBDaGF0eml0aG9tYW9nbG91IFttYWls dG86YWNoYXR6QGZvcnRobmV0Z3JvdXAuZ3JdIDxicj48Yj5TZW50OjwvYj4gU2F0dXJkYXksIE9j dG9iZXIgMTUsIDIwMTEgNzo1MCBBTTxicj48Yj5Ubzo8L2I+IEJyaWFuIEUgQ2FycGVudGVyPGJy PjxiPkNjOjwvYj4gSGVtYW50IFNpbmdoIChzaGVtYW50KTsgSVB2NiBXRyBNYWlsaW5nIExpc3Q8 YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1oc2luZ2gtNm1hbi1lbmhhbmNlZC1kYWQtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz5BbHNvLCBsb29raW5n IGF0IGRyYWZ0LWlldGYtNm1hbi1mbG93LTM2OTdiaXMtMDcsIGkgY2FuIHNlZSB0aGUgZm9sbG93 aW5nIHVuZGVyIGludHJvZHVjdGlvbjo8bzpwPjwvbzpwPjwvcD48cHJlPkEgc3RhdGVmdWw8bzpw PjwvbzpwPjwvcHJlPjxwcmU+wqDCoCBzY2VuYXJpbyBpcyBvbmUgd2hlcmUgYSBub2RlIHRoYXQg cHJvY2Vzc2VzIHRoZSBmbG93IGxhYmVsIHZhbHVlPG86cD48L286cD48L3ByZT48cHJlPsKgwqAg bmVlZHMgdG8gc3RvcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGZsb3csIGluY2x1ZGluZyB0aGUg ZmxvdyBsYWJlbDxvOnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIHZhbHVlLiA8bzpwPjwvbzpwPjwv cHJlPjxwIGNsYXNzPU1zb05vcm1hbD4uLi48bzpwPjwvbzpwPjwvcD48cHJlPsKgwqAgVGhlIGZs b3cgbGFiZWwgY2FuIGJlIHVzZWQgbW9zdCBzaW1wbHkgaW4gc3RhdGVsZXNzIHNjZW5hcmlvcy7C oCBUaGlzPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgc3BlY2lmaWNhdGlvbiBjb25jZW50cmF0 ZXMgb24gdGhlIHN0YXRlbGVzcyBtb2RlbCBhbmQgaG93IGl0IGNhbiBiZTxvOnA+PC9vOnA+PC9w cmU+PHByZT7CoMKgIHVzZWQgYXMgYSBkZWZhdWx0IG1lY2hhbmlzbS7CoCA8Yj5EZXRhaWxzIG9m IHN0YXRlZnVsIG1vZGVsczwvYj4sIHNpZ25hbGluZyw8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDC oCBzcGVjaWZpYyBmbG93IHN0YXRlIGVzdGFibGlzaG1lbnQgbWV0aG9kcyBhbmQgdGhlaXIgcmVs YXRlZCBzZXJ2aWNlPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgbW9kZWxzIDxiPmFyZSBvdXQg b2Ygc2NvcGUgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbjwvYj4uwqAgPG86cD48L286cD48L3ByZT48 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHAgY2xhc3M9TXNvTm9ybWFsPkRvZXMgdGhpcyBt ZWFuIHRoYXQgdGhlIHVzYWdlIG9mIGZsb3cgbGFiZWwgb24gTkQvREFEIGlzIG91dCBvZiBzY29w ZSBvZiAzNjk3YmlzPzxicj48YnI+LS08YnI+VGFzc29zPGJyPjxicj48YnI+PG86cD48L286cD48 L3A+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjwvZGl2PjwvYm9keT48L2h0bWw+ ------_=_NextPart_001_01CC8B39.B91C3F95-- From brian.e.carpenter@gmail.com Sat Oct 15 12:18:39 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A478021F8A69 for ; Sat, 15 Oct 2011 12:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.319 X-Spam-Level: X-Spam-Status: No, score=-103.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35c2e+hiQA4O for ; Sat, 15 Oct 2011 12:18:38 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8402B21F8A64 for ; Sat, 15 Oct 2011 12:18:38 -0700 (PDT) Received: by bkas6 with SMTP id s6so1967090bka.31 for ; Sat, 15 Oct 2011 12:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uJwYpwxuvBNqbWoncgkEOEf7QH1PIDnM80f2r8Dx5fo=; b=cY+Rb+t/GCtuSzQ54Q4MVZxYWQwu7LkXEYgM6ZWyh2FRHTA73zw4dpRUmzXK6c4gMF E8CXoy2jRYfKYlsA5YlUPUh+22oZcERz415IhcRp8msYezj7YZ4o5JsByowwak3ZYBey 5mv/xdy4xxuUE3vfve08b5s286IijVBpuLAA8= Received: by 10.223.63.75 with SMTP id a11mr12671250fai.9.1318706317587; Sat, 15 Oct 2011 12:18:37 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id r6sm12107896fam.0.2011.10.15.12.18.33 (version=SSLv3 cipher=OTHER); Sat, 15 Oct 2011 12:18:36 -0700 (PDT) Message-ID: <4E99DC84.2080001@gmail.com> Date: Sun, 16 Oct 2011 08:18:28 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hemant Singh (shemant)" Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <4E98C933.4040402@gmail.com> <4E98D102.3060601@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303DE@XMB-RCD-109.cisco.com> <4E99734C.5050304@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C303130411@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303130411@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 19:18:39 -0000 Answering Tassos' question specifically, if the use of the flow label for= ND/DAD requires a signalling phase to tell the other end the flow label value in use, it is clearly out of scope for 3697bis. (Not forbidden, just not described.) However, I can't imagine how you would signal anything before performing neighbour discovery. I thnk it's just orthogonal to 3697bis. The usage of the flow label in link-local scope before completing address assignment doesn't seem to = me to be constrained by 2460, 3697 or 3697bis. However, I agree that 20 bits is small for a nonce. It puts you into birthday-paradox territory on a LAN with a few hundred nodes. Brian On 2011-10-16 01:55, Hemant Singh (shemant) wrote: > I certainly don=E2=80=99t believe so. The usual use of Flow Label see= ms to assume the labeled packet traverses more than one hop. After all, = the typical use of the Flow Label is to let each hop know what processing= to do based on the Flow Label. However, a link-local domain whose traf= fic is restricted to within one link with no traversal across a router/ho= p, the Flow Label does not have a hop-by-hop use but certainly if some in= formation needs to be provided to all nodes the flow label can be used. = But such information is best provided by the control protocol of ND used = in the link. So why overload the Flow Label. Anyway, some folks may no= t like the small size of 20 bits to be used in a nonce . >=20 > =20 >=20 > Hemant >=20 > =20 >=20 > From: Tassos Chatzithomaoglou [mailto:achatz@forthnetgroup.gr]=20 > Sent: Saturday, October 15, 2011 7:50 AM > To: Brian E Carpenter > Cc: Hemant Singh (shemant); IPv6 WG Mailing List > Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhance= d-dad-01.txt >=20 > =20 >=20 > Also, looking at draft-ietf-6man-flow-3697bis-07, i can see the followi= ng under introduction: >=20 > A stateful > scenario is one where a node that processes the flow label value > needs to store information about the flow, including the flow label > value.=20 >=20 > ... >=20 > The flow label can be used most simply in stateless scenarios. This= > specification concentrates on the stateless model and how it can be > used as a default mechanism. Details of stateful models, signaling,= > specific flow state establishment methods and their related service > models are out of scope for this specification. =20 > =20 >=20 > Does this mean that the usage of flow label on ND/DAD is out of scope o= f 3697bis? >=20 > -- > Tassos >=20 >=20 >=20 >=20 > =20 From fx.lebail@yahoo.com Mon Oct 17 04:37:04 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE1521F8753 for ; Mon, 17 Oct 2011 04:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pslUZnvRQfux for ; Mon, 17 Oct 2011 04:37:04 -0700 (PDT) Received: from nm38-vm3.bullet.mail.ne1.yahoo.com (nm38-vm3.bullet.mail.ne1.yahoo.com [98.138.229.147]) by ietfa.amsl.com (Postfix) with SMTP id B71FA21F86EE for ; Mon, 17 Oct 2011 04:37:03 -0700 (PDT) Received: from [98.138.90.54] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 17 Oct 2011 11:37:00 -0000 Received: from [98.138.89.196] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 17 Oct 2011 11:37:00 -0000 Received: from [127.0.0.1] by omp1054.mail.ne1.yahoo.com with NNFMP; 17 Oct 2011 11:37:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 104279.81694.bm@omp1054.mail.ne1.yahoo.com Received: (qmail 10961 invoked by uid 60001); 17 Oct 2011 11:37:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1318851419; bh=dqjpeb6MTGrs+Dupc950QwCRQF53iVYp0UkaNsqpdY0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pMEqjr5iEN89hExN0lQiWgWTFf+jsTRkhsLYIZJcqa7ob28uZNa9Qy9JQPTgDPjIW5X04oAmD+gyLlVpoRAUJRF+YYoVcw+Tv6g6F1ORQdomwjwN+pGaGtGJStVMSxNkKqHYyytg5XIpYEh9fLb6cI5jWgwxXQpEbbM1ELnAqvc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=SBfH9rk49rrtPj5/WF0nazFPMKY2SnfpeF9ta7Kry/GKTa0a83I7j0L2QUOzAFVPw5R4aiTE0WQrE/B7PW4n5JEErMH3NVxnT9wd7IZW+BE/Y7Boy17EldOX/UDFcG4/EIY9WKHE9AcFA5Hg13MZ6qyYe0+UbhWqgoJKXWKz41Y=; X-YMail-OSG: 0QW3YNMVM1kznBQz_fwqipNrXUwNIHzVyg0.Rr8XcQC1VmH hu0XD8ETnpVVHoDKwA0kQtZNEXaBCHC4xizNc9OF9X1fXx8N_I8OIFcuRmQH qXWXkdXxXxjB6vKlWE66K8uhFJcCXaz.JDjAuj11CuYcH0pOAUB.RC8wC4Wy 8aAGgIRLXcQLjRx__8.tz_amIF3uWEM0lss3BlGpzc7Mcz7oEmqAwHerQVME DbWP05g8ZUd.yUWw8tXiFFDTt8TcXcca5jh6W8IDvDr7ae9O5h8XIpaH1VjQ BoAl61ulyeHtmcxLS3XtWC075P6y7f0GqOVi54HB8liaivPLMK.v99_75sZZ OjrkJqu2ejPqCPbO0GCgDJmvR9_UyfO32Zzme9G607Izp3LiPhbPcP.hOi0_ ip8hN0gkK4JPFueGu6WdRBd0JDiUt4BZ18NVYvXi8k6lxgQ-- Received: from [193.49.124.107] by web126019.mail.ne1.yahoo.com via HTTP; Mon, 17 Oct 2011 04:36:59 PDT X-Mailer: YahooMailWebService/0.8.114.317681 References: <1317650937.91291.YahooMailClassic@web126003.mail.ne1.yahoo.com> <733600C6-434C-4797-919E-002F86BDC710@nttv6.net> Message-ID: <1318851419.9309.YahooMailNeo@web126019.mail.ne1.yahoo.com> Date: Mon, 17 Oct 2011 04:36:59 -0700 (PDT) From: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= Subject: About draft-ietf-6man-rfc3484-revise (was Re: Question about Subnet-Router anycast address) To: "ipv6@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 11:37:04 -0000 Hi,=0A=0A----- Original Message -----=0A> From: Arifumi Matsumoto =0A> To: Fran=E7ois-Xavier Le Bail =0A> Cc: = Thomas Narten ; ipv6@ietf.org=0A> Sent: Tuesday, October= 11, 2011 5:02 AM=0A> Subject: Re: Question about Subnet-Router anycast add= ress=0A> =0A> On 2011/10/03, at 23:08, Fran=E7ois-Xavier Le Bail wrote:=0A>= =0A>>=A0 --- On Mon, 10/3/11, Thomas Narten wrote:=0A>= >>=A0 writes:=0A>>>=A0 The norm is (and has been fore= ver) to require that the=0A>>>=A0 source address in a response (whether TCP= or UDP) match the destination=0A>>>=A0 address in the original query. And = for good reason.=0A>> =0A>>=A0 But the RFC 3484, as I understand it, exclud= e anycast address from the =0A>>=A0 source replies.=0A>> =0A>>=A0 Section 4= of RFC 3484 states:=0A>> =A0 =A0=A0 (http://tools.ietf.org/html/rfc3484#se= ction-4)=0A>> =A0 =A0=A0 4. Candidate Source Addresses=0A>> =A0 =A0=A0 [. .= .]=0A>> =A0 =A0 =A0 =A0 In any case, anycast addresses, multicast addresse= s, and the=0A>> =A0 =A0 =A0 =A0 unspecified address MUST NOT be included in= a candidate set.=0A>> =0A>>=A0 It might be useful to reassess this restric= tion, at least for the replies.=0A> =0A> As in RFC 3484 section 2, these al= gorithms in RFC 3484 does=0A> not specify the rules for your case. It speci= fies the rules=0A> that are used when an application initiates a session an= d=0A> a destination address and a source address have to be chosen.=0A> It = does not specify rules for selecting address for a returning=0A> packet.=0A= =0A> =0A> So, in my understanding, the only restriction for using an=0A=0A>= anycast source address was in RFC 3513. But, now that such a=0A> restricti= on was removed, RFC 3484 should also be updated to=0A> allow to select an a= nycast source address for a initiating=0A> session.=0A> Arifumi Matsumoto= =0A=0A=0APerhaps it is not clear enough in RFC 3484 if the algorithm for so= urce =0Aaddress selection is involved or not for replies to IPv6 packets of= =0Aunconnected protocols (UDP, ICMP echo request, etc.).=0A=0AIf agreed, dr= aft-ietf-6man-rfc3484-revise should add a clear status on this question.=0A= =0A=0AThanks,=0AFran=E7ois-Xavier From shemant@cisco.com Mon Oct 17 07:14:24 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C477721F8BAE for ; Mon, 17 Oct 2011 07:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.375 X-Spam-Level: X-Spam-Status: No, score=-5.375 tagged_above=-999 required=5 tests=[AWL=1.224, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4njezuD1PhLL for ; Mon, 17 Oct 2011 07:14:24 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA9121F8BAD for ; Mon, 17 Oct 2011 07:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1290; q=dns/txt; s=iport; t=1318860864; x=1320070464; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=d07Rr11OFJ8btcM5TXOFZGLgVBNsPUS9dg9vZXQCS24=; b=FLPGS/2PrMkWamfFIapgHT/okDVXWCrH23ogWhpo0Xsri9Ilt4ZzuFXN OYDs6UDjoAhLh2DH5qBZAl9alZVG+dCzE17DvgWE0ab9rzVNB6E51KlMg RVDerIXth9aPgQJ084ZMLFO92Br81+gvz7isO3XOC8HMJSLnL+NPn63QG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAMg3nE6tJXG+/2dsb2JhbABDhHWUUY4nfIEFgW4BAQEEEgEQDQQ6CQIMBAIBCBEEAQEDAgYGFwECAgIBAR8lCAEIAQEEEwganXgBjEeRe4EwhUQzYQSIApEqhHyHRg X-IronPort-AV: E=Sophos;i="4.69,359,1315180800"; d="scan'208";a="28936586" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 17 Oct 2011 14:14:22 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9HEEM80018721; Mon, 17 Oct 2011 14:14:22 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 09:14:22 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Date: Mon, 17 Oct 2011 09:14:21 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30313054A@XMB-RCD-109.cisco.com> In-Reply-To: <4E99DC84.2080001@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyLbz7aG1Cu6oPuTmmsYfhYpBnLGQBZoTBA References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <4E98C933.4040402@gmail.com> <4E98D102.3060601@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303DE@XMB-RCD-109.cisco.com> <4E99734C.5050304@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C303130411@XMB-RCD-109.cisco.com> <4E99DC84.2080001@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" X-OriginalArrivalTime: 17 Oct 2011 14:14:22.0440 (UTC) FILETIME=[11621680:01CC8CD7] Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:14:24 -0000 DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21h aWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dIA0KU2VudDogU2F0dXJkYXksIE9jdG9i ZXIgMTUsIDIwMTEgMzoxOCBQTQ0KVG86IEhlbWFudCBTaW5naCAoc2hlbWFudCkNCkNjOiBUYXNz b3MgQ2hhdHppdGhvbWFvZ2xvdTsgSVB2NiBXRyBNYWlsaW5nIExpc3QNClN1YmplY3Q6IFJlOiBG VzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oc2luZ2gtNm1hbi1lbmhhbmNl ZC1kYWQtMDEudHh0DQoNCj5Ib3dldmVyLCBJIGFncmVlIHRoYXQgMjAgYml0cyBpcyBzbWFsbCBm b3IgYSBub25jZS4gDQoNCk5vdGUgU0VORCBpbiBSRkMgMzk3MSBoYXMgbGVmdCB0aGUgbGVuZ3Ro IG9mIHRoZSBOb25jZSBPcHRpb24gdG8gYmUgNiBieXRlcyBvciBoaWdoZXIuICBJIHBlcnNvbmFs bHkgd291bGQgbGlrZSBhbnkgcmVmbGVjdGVkLURBRCBhbGdvcml0aG0gdG8gc2V0dGxlIG9uIG9u ZSBmaXhlZCBsZW5ndGggZm9yIHRoZSBub25jZS4gIFRodXMgYSBxdWVzdGlvbiB0byB0aGUgbWFp bGVyLiAgV2hpY2ggb2YgNDggb3IgNjIgYml0cyBkbyBmb2xrcyBwcmVmZXIgYXMgbGVuZ3RoIG9m IHRoZSBub25jZSBmb3IgdGhlIHJlZmxlY3RlZC1EQUQgYWxnb3JpdGhtPyAgSSBob3BlIGZvbGtz IGRvIG5vdCB3YW50IHRvIGdvIGFueSBoaWdoZXIgdGhhbiA2MiBiaXRzLiAgTm90ZSB0aGUgTm9u Y2UgT3B0aW9uIGhhcyBzcGVjaWZpZWQgdGhhdCB0aGUgb3B0aW9uIGVuZCBvbiBhbiA4LWJ5dGUg Ym91bmRhcnkgYW5kIHNpbmNlIHRoZSBvcHRpb24gaXMgaW4gVExWIGZvcm1hdCwgMTYgYml0cyBh cmUgYWxyZWFkeSB0YWtlbiBieSB0aGUgVHlwZSBhbmQgTGVuZ3RoIGZpZWxkcyBvZiB0aGUgb3B0 aW9uLg0KDQpUaGFua3MsDQoNCkhlbWFudCAgDQo= From iesg-secretary@ietf.org Mon Oct 17 07:44:40 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AAF21F8BF7; Mon, 17 Oct 2011 07:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTY4cYqlNsvq; Mon, 17 Oct 2011 07:44:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B077E21F8BF4; Mon, 17 Oct 2011 07:44:39 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (RPL Option for Carrying RPL Information in Data-Plane Datagrams) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111017144439.1444.44920.idtracker@ietfa.amsl.com> Date: Mon, 17 Oct 2011 07:44:39 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:44:40 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'RPL Option for Carrying RPL Information in Data-Plane Datagrams' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The RPL protocol requires data-plane datagrams to carry RPL routing information that is processed by RPL routers when forwarding those datagrams. This document describes the RPL Option for use within a RPL domain. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-option/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-option/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Oct 17 08:11:30 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632A221F8C2A; Mon, 17 Oct 2011 08:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbCpiLvkancb; Mon, 17 Oct 2011 08:11:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3B421F8BBC; Mon, 17 Oct 2011 08:11:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (An IPv6 Routing Header for Source Routes with RPL) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111017151123.8627.1693.idtracker@ietfa.amsl.com> Date: Mon, 17 Oct 2011 08:11:23 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:11:30 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'An IPv6 Routing Header for Source Routes with RPL' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In Low power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining at most a few routes. In some configurations, it is necessary to use these memory constrained routers to deliver datagrams to nodes within the LLN. The Routing for Low Power and Lossy Networks (RPL) protocol can be used in some deployments to store most, if not all, routes on one (e.g. the Directed Acyclic Graph (DAG) root) or few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL domain. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-routing-header/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-routing-header/ No IPR declarations have been submitted directly on this I-D. From shemant@cisco.com Mon Oct 17 08:25:22 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F78821F8C3F for ; Mon, 17 Oct 2011 08:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.426 X-Spam-Level: X-Spam-Status: No, score=-5.426 tagged_above=-999 required=5 tests=[AWL=1.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL5oMfiUbWor for ; Mon, 17 Oct 2011 08:25:21 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE9621F8C1A for ; Mon, 17 Oct 2011 08:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2300; q=dns/txt; s=iport; t=1318865121; x=1320074721; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=HG3gQHA+SL8gXtmK3vsZsPb0quhvOJTqd23mbR92dQM=; b=WYKiGWMCjS/PRpcSdxQhk7yo4st/pNQGTwVaqM6Jnkb9WsSZlYFxj59P fmYkgEvRdOXNd/OBNDxxnd7HG4j8YQ9SC/CKHh5/xFNW4bz7Mv1eTU/e8 DgQ52pFyutiw5tFkVT7SovUG5QTfjjnNuZ2ChuB189dKOHv/NOdPs5982 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAPVHnE6tJXG9/2dsb2JhbABDmUaPI4EFgW4BAQEEEgEdCjQJAgwEAgEIDgMEAQELBhcBBgFFCAEIAQEEEwgBGYdllzsBnlKHJ2EEiAKRKoxC X-IronPort-AV: E=Sophos;i="4.69,359,1315180800"; d="scan'208";a="28965942" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 17 Oct 2011 15:25:21 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9HFPKkO015098; Mon, 17 Oct 2011 15:25:20 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 10:25:20 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Date: Mon, 17 Oct 2011 10:25:19 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031305A7@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyM3Xl5X9Ije881S6yi6QT5SWgOxAAAkBfA References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <4E98C933.4040402@gmail.com> <4E98D102.3060601@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303DE@XMB-RCD-109.cisco.com> <4E99734C.5050304@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C303130411@XMB-RCD-109.cisco.com> <4E99DC84.2080001@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30313054A@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Philip Homburg" X-OriginalArrivalTime: 17 Oct 2011 15:25:20.0499 (UTC) FILETIME=[FB625430:01CC8CE0] Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:25:22 -0000 -----Original Message----- From: pch-b29AA871B@u-1.phicoh.com [mailto:pch-b29AA871B@u-1.phicoh.com] On Behalf Of Philip Homburg Sent: Monday, October 17, 2011 11:00 AM To: Hemant Singh (shemant) Cc: IPv6 WG Mailing List Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt=20 >I think 20 bits should be already be more than enough. For simplicity, I would >just go for 64 bits. Appreciate the quick reply. Note BrianC already noted that 20 bits will not suffice by saying "It puts you into birthday-paradox territory on a LAN with a few hundred nodes.". His email is at the URL below. http://www.ietf.org/mail-archive/web/ipv6/current/msg14835.html We can go for a 62 bits long nonce in the Nonce Option. Can't pick 64 because the Nonce Option will then not end in an 8-byte boundary. See the details from RFC 3971 below.=20 Regards, Hemant 5.3.2. Nonce Option The purpose of the Nonce option is to make sure that an advertisement is a fresh response to a solicitation sent earlier by the node. The format of this option is described in the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Nonce ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 14 Length The length of the option (including the Type, Length, and Nonce fields) in units of 8 octets. Nonce A field containing a random number selected by the sender of the solicitation message. The length of the random number MUST be at least 6 bytes. The length of the random number MUST be selected so that the length of the nonce option is a multiple of 8 octets. From ichiroumakino@gmail.com Mon Oct 17 08:43:54 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A759E21F8C88 for ; Mon, 17 Oct 2011 08:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAk3P6TAxXkB for ; Mon, 17 Oct 2011 08:43:54 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E17C221F8C8D for ; Mon, 17 Oct 2011 08:43:53 -0700 (PDT) Received: by wwe6 with SMTP id 6so1564386wwe.13 for ; Mon, 17 Oct 2011 08:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=NTx6877jGnKdDMCiwMxAugaZro5pPWahv2hXpTSqFaQ=; b=eQMPkkai0k5cZ0N4vaZcCSE1B/o15hwKLXVeZyrvoPpkO5b6kdB8hZ/SC2eQ2lqtsZ a2PcIoxW45FlAilq4PPSWKHRltO2in7WrSVKVarsTNr1tqZ6eYDrG/OvlWp7tJoKGww5 nJPOL+/v6nvfA8k9Ys94WbghL2gnqTKSKD9To= Received: by 10.227.59.67 with SMTP id k3mr7057882wbh.108.1318866231678; Mon, 17 Oct 2011 08:43:51 -0700 (PDT) Received: from dhcp-10-61-100-173.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id j18sm31793281wbo.6.2011.10.17.08.43.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Oct 2011 08:43:50 -0700 (PDT) Sender: Ole Troan Subject: Re: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031305A7@XMB-RCD-109.cisco.com> Date: Mon, 17 Oct 2011 17:43:49 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <4E98C933.4040402@gmail.com> <4E98D102.3060601@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303DE@XMB-RCD-109.cisco.com> <4E99734C.5050304@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C303130411@XMB-RCD-109.cisco.com> <4E99DC84.2080001@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30313054A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031305A7@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: IPv6 WG Mailing List , Philip Homburg X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:43:54 -0000 >> I think 20 bits should be already be more than enough. For simplicity, > I would >> just go for 64 bits. > > Appreciate the quick reply. Note BrianC already noted that 20 bits will > not suffice by saying "It puts you into birthday-paradox territory on a > LAN with a few hundred nodes.". His email is at the URL below. > > http://www.ietf.org/mail-archive/web/ipv6/current/msg14835.html > > We can go for a 62 bits long nonce in the Nonce Option. Can't pick 64 > because the Nonce Option will then not end in an 8-byte boundary. See > the details from RFC 3971 below. I think you mean 48 bits. Ole > > Regards, > > Hemant > > 5.3.2. Nonce Option > > The purpose of the Nonce option is to make sure that an advertisement > is a fresh response to a solicitation sent earlier by the node. The > format of this option is described in the following: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Nonce ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | | > . . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type > > 14 > > Length > > The length of the option (including the Type, Length, and Nonce > fields) in units of 8 octets. > > Nonce > > A field containing a random number selected by the sender of the > solicitation message. The length of the random number MUST be at > least 6 bytes. The length of the random number MUST be selected > so that the length of the nonce option is a multiple of 8 octets. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From pch-b29AA871B@u-1.phicoh.com Mon Oct 17 08:00:17 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A56021F8C3A for ; Mon, 17 Oct 2011 08:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bii-ExmvB4-U for ; Mon, 17 Oct 2011 08:00:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC5B21F8C33 for ; Mon, 17 Oct 2011 08:00:16 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RFofh-0001ZQC; Mon, 17 Oct 2011 17:00:09 +0200 Message-Id: To: "Hemant Singh (shemant)" Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <4E98C933.4040402@gmail.com> <4E98D102.3060601@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303DE@XMB-RCD-109.cisco.com> <4E99734C.5050304@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C303130411@XMB-RCD-109.cisco.com> <4E99DC84.2080001@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30313054A@XMB-RCD-109.cisco.com> In-reply-to: Your message of "Mon, 17 Oct 2011 09:14:21 -0500 ." <5B6B2B64C9FE2A489045EEEADDAFF2C30313054A@XMB-RCD-109.cisco.com> Date: Mon, 17 Oct 2011 17:00:07 +0200 X-Mailman-Approved-At: Mon, 17 Oct 2011 08:44:54 -0700 Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:00:17 -0000 In your letter dated Mon, 17 Oct 2011 09:14:21 -0500 you wrote: >-----Original Message----- >From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >Sent: Saturday, October 15, 2011 3:18 PM >To: Hemant Singh (shemant) >Cc: Tassos Chatzithomaoglou; IPv6 WG Mailing List >Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-0 >1.txt > >>However, I agree that 20 bits is small for a nonce. > >Note SEND in RFC 3971 has left the length of the Nonce Option to be 6 bytes or > higher. I personally would like any reflected-DAD algorithm to settle on one > fixed length for the nonce. Thus a question to the mailer. Which of 48 or 6 >2 bits do folks prefer as length of the nonce for the reflected-DAD algorithm? > I hope folks do not want to go any higher than 62 bits. Note the Nonce Opti >on has specified that the option end on an 8-byte boundary and since the optio >n is in TLV format, 16 bits are already taken by the Type and Length fields of > the option. I think 20 bits should be already be more than enough. For simplicity, I would just go for 64 bits. Assuming hosts generate sufficiently strong pseudo-random numbers, 20 bits means that once every one million cases of a genuine duplicate address, both hosts may mistakenly assume there is a loopback problem. Given that duplicate addresses should be exceedingly rare already, one millionth of that is something that essential doesn't happen. There is however one thing to worry about: small devices without persistent state. If those devices end up with the same MAC address, then there is good chance that they will generate the same random number as well. From pch-b29AA871B@u-1.phicoh.com Mon Oct 17 08:41:14 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A13321F8B7E for ; Mon, 17 Oct 2011 08:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKABTHIAPwjH for ; Mon, 17 Oct 2011 08:41:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3C01F21F8B5A for ; Mon, 17 Oct 2011 08:41:13 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RFpJN-0001kQC; Mon, 17 Oct 2011 17:41:09 +0200 Message-Id: To: "Hemant Singh (shemant)" Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <4E98C933.4040402@gmail.com> <4E98D102.3060601@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303DE@XMB-RCD-109.cisco.com> <4E99734C.5050304@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C303130411@XMB-RCD-109.cisco.com> <4E99DC84.2080001@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30313054A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031305A7@XMB-RCD-109.cisco.com> In-reply-to: Your message of "Mon, 17 Oct 2011 10:25:19 -0500 ." <5B6B2B64C9FE2A489045EEEADDAFF2C3031305A7@XMB-RCD-109.cisco.com> Date: Mon, 17 Oct 2011 17:41:05 +0200 X-Mailman-Approved-At: Mon, 17 Oct 2011 08:44:54 -0700 Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:41:14 -0000 In your letter dated Mon, 17 Oct 2011 10:25:19 -0500 you wrote: >Appreciate the quick reply. Note BrianC already noted that 20 bits will >not suffice by saying "It puts you into birthday-paradox territory on a >LAN with a few hundred nodes.". His email is at the URL below. > >http://www.ietf.org/mail-archive/web/ipv6/current/msg14835.html I'm not sure how you would get a birthday paradox here. Applying the birthday paradox, you would get that if you have a network with a 1000 nodes, and all nodes try to configure the exact same IPv6 address at the same time, then there is a probability of about 0.5 that two nodes will mistakenly assume that there is a loopback situation and all the others will detect a duplicate address. That's not a problem I would worry about. >We can go for a 62 bits long nonce in the Nonce Option. Can't pick 64 >because the Nonce Option will then not end in an 8-byte boundary. See >the details from RFC 3971 below. > > 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Nonce ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | | > . . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Length > > The length of the option (including the Type, Length, and Nonce > fields) in units of 8 octets. > > Nonce > > A field containing a random number selected by the sender of the > solicitation message. The length of the random number MUST be at > least 6 bytes. The length of the random number MUST be selected > so that the length of the nonce option is a multiple of 8 octets. So it looks like the shortest nonce is 6 octets or 48 bits and then the next longer one is 14 octets or 112 bits. SEND doesn't seem to say anything about the length of the nonce. I guess that 48 bits should be enough to be secure. I think 48 bits is more than enough for DAD. From shemant@cisco.com Mon Oct 17 08:57:57 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A6721F8CF6 for ; Mon, 17 Oct 2011 08:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.473 X-Spam-Level: X-Spam-Status: No, score=-5.473 tagged_above=-999 required=5 tests=[AWL=1.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-l+J+AwKAw6 for ; Mon, 17 Oct 2011 08:57:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C4AD021F8CF5 for ; Mon, 17 Oct 2011 08:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=653; q=dns/txt; s=iport; t=1318867076; x=1320076676; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=5ZqRtKn56QJPGxHcaHFVjy84SzVFgW9ZXoFmdlOFuI8=; b=FH30lO72m0AQOV69rmL2qAnHR1gmKiXOtXO4FHrpMyPTao3SMz7RgKPQ kv6aeFMSplM3DZ6FJyjJCEZ2ch+cRVw0Qu6bm89n+zNzQK5M9wfWDyuGn YWNnzgvzNwHBuVrTTbC1/B9iYhY2F572S0hAGtdn42sRaI9NnCuBBGrA5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAERPnE6tJXG9/2dsb2JhbABDmUiPI4EFgW4BAQEEEgEdCjQJAgwEAgEIDgMEAQELBhcBBgEgJQkIAQEEEwgany8BnlyHJ2EEiAKRKoR8h0Y X-IronPort-AV: E=Sophos;i="4.69,359,1315180800"; d="scan'208";a="28971651" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 17 Oct 2011 15:57:56 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9HFvu7q029663; Mon, 17 Oct 2011 15:57:56 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 10:57:55 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Date: Mon, 17 Oct 2011 10:57:55 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031305DA@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyM45NCHyfGsX9+QDGWI0WFsvjyIgAAWNdQ References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <4E98C933.4040402@gmail.com> <4E98D102.3060601@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303DE@XMB-RCD-109.cisco.com> <4E99734C.5050304@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C303130411@XMB-RCD-109.cisco.com> <4E99DC84.2080001@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30313054A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031305A7@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Ole Troan" X-OriginalArrivalTime: 17 Oct 2011 15:57:55.0971 (UTC) FILETIME=[88EFAD30:01CC8CE5] Cc: IPv6 WG Mailing List , Philip Homburg X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:57:57 -0000 -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Monday, October 17, 2011 11:44 AM To: Hemant Singh (shemant) Cc: Philip Homburg; IPv6 WG Mailing List Subject: Re: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt >I think you mean 48 bits. Ah, I had suggested 48 or 62 bits in my first email for the mailer to pick one. Since Philip suggested to go with 64, I picked 62 bits due to the 8-byte boundary alignment of the nonce in the Nonce Option. I am open to 48 bits which is the minimum specified for length of the nonce in RFC 3971. Cheers, Hemant From v6ops@globis.net Mon Oct 17 09:32:47 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05AE21F8B2A for ; Mon, 17 Oct 2011 09:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVLF6WCbaHEz for ; Mon, 17 Oct 2011 09:32:47 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id C257B21F8B00 for ; Mon, 17 Oct 2011 09:32:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2F84487007F; Mon, 17 Oct 2011 18:32:45 +0200 (CEST) X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at globis01.globis.net X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 20 hex): Subject: ... for, draft-hsingh-6man-enhanced-dad-01.txt\n \n Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpscRhxznmKe; Mon, 17 Oct 2011 18:32:37 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 758FA870047; Mon, 17 Oct 2011 18:32:37 +0200 (CEST) Message-ID: <4E9C58A5.80001@globis.net> Date: Mon, 17 Oct 2011 18:32:37 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Philip Homburg , "Hemant Singh (shemant)" , Ole Troan , Brian E Carpenter Subject: Re: FW: New Version Notification for, draft-hsingh-6man-enhanced-dad-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 16:32:47 -0000 > > I think 20 bits should be already be more than enough. For simplicity, I would > just go for 64 bits. > > Assuming hosts generate sufficiently strong pseudo-random numbers, 20 bits > means that once every one million cases of a genuine duplicate address, > both hosts may mistakenly assume there is a loopback problem. > > Given that duplicate addresses should be exceedingly rare already, one > millionth of that is something that essential doesn't happen. > > Brian Carpenter and Ole Troan are both correct. The birthday paradox of a pair of nodes colliding applies here, so you should consider approx half the hash length as the practical effective length of the hash (Applied Cryptography: Bruce Schneier p166), reducing the probability of a collision to around one in 2^10 for a 20 bit nonce, or about one in a thousand. RFC 3971 defines the nonce option (including option length and type) as being a multiple of 8 octets including one octet for type field and one octet for the length field. Would therefore humbly suggest a minimum/ default / recommendation of an 8 octet nonce option (minus the existing 16 pre-assigned bits) meaning 48 bits available for the nonce field, with the option of using longer 16 or 24 octet nonce options if an implementer feels there is higher likelihood of encountering more than 2^24 nodes on the link (giving respectively 16*8-16 = 112 bit nonce & 24*8-16 = 176 bit nonce) You may think this is far fetched for an upper bound on the number of nodes on a single link, but you never know what will happen in the future, and standards writers been caught out often enough in the past when making statements like "16/24/32/56 bits will be enough." By definition a longer (e.g. 16) octet nonce option is never going to collide with a node using a shorter (e.g. 8) octet nonce option in the case of DAD, so not everyone has to use the same nonce length IMHO. Regards, RayH From shemant@cisco.com Mon Oct 17 10:23:10 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4956A21F8C75 for ; Mon, 17 Oct 2011 10:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.516 X-Spam-Level: X-Spam-Status: No, score=-5.516 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5dN-BD6K2Fx for ; Mon, 17 Oct 2011 10:23:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 89F0B21F8C1F for ; Mon, 17 Oct 2011 10:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1735; q=dns/txt; s=iport; t=1318872189; x=1320081789; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=qMnj1YiYCM1lr9v/eV5VvdFDR4OER093wkjvYPIkpfc=; b=XoEcB3zjb8C6A8Gd5CHjg/0+rJ9Fg4s3kfkAdGHVxvyZC5egQSEU90jb DXSI1ObweeChyHwl3qI8nPMx/xunvKEV/TviLZRrAgD/Zpg0/DCjL+tH2 uw1c9QbBtLBh/DpsG9kBGnkocT+lfwS4W9Zd4Hc4WO6yFsUNN9RG3xTEM A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBACVknE6tJXHA/2dsb2JhbABDmTqPI4EFgW4BAQEEEgEdCjQJAgwEAgEIDgMEAQELBhcBBgFFCAEIAQEEARIIGqACAZ5nhydhBIgCkSqMQg X-IronPort-AV: E=Sophos;i="4.69,360,1315180800"; d="scan'208";a="28998383" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 17 Oct 2011 17:23:09 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9HHN888006228; Mon, 17 Oct 2011 17:23:08 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 12:23:08 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: New Version Notification for, draft-hsingh-6man-enhanced-dad-01.txt Date: Mon, 17 Oct 2011 12:23:07 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30313065C@XMB-RCD-109.cisco.com> In-Reply-To: <4E9C58A5.80001@globis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for, draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyM6mhrlfwxXu/jTRGku7SUGXFaXgAA3WtQ References: <4E9C58A5.80001@globis.net> From: "Hemant Singh (shemant)" To: "Ray Hunter" , "Philip Homburg" , "Ole Troan" , "Brian E Carpenter" X-OriginalArrivalTime: 17 Oct 2011 17:23:08.0560 (UTC) FILETIME=[7046D900:01CC8CF1] Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:23:10 -0000 -----Original Message----- From: Ray Hunter [mailto:v6ops@globis.net]=20 Sent: Monday, October 17, 2011 12:33 PM To: Philip Homburg; Hemant Singh (shemant); Ole Troan; Brian E Carpenter Cc: IPv6 WG Mailing List Subject: Re: FW: New Version Notification for, draft-hsingh-6man-enhanced-dad-01.txt=20 >Would therefore humbly suggest a minimum/ default / recommendation of an=20 >8 octet nonce option (minus the existing 16 pre-assigned bits) meaning=20 >48 bits available for the nonce field, with the option of using longer=20 >16 or 24 octet nonce options if an implementer feels there is higher=20 >likelihood of encountering more than 2^24 nodes on the link (giving=20 >respectively 16*8-16 =3D 112 bit nonce & 24*8-16 =3D 176 bit nonce) First humble apologies for suggesting the 62 bits because combined with 16 bits of the Type and Length of the Nonce Option, the option won't align on an octet boundary. As for a minimum default with an option to use 16 or 24 octets in future, sounds fine to myself and Wes. Since the number of bits for the nonce was an open question for the -01 document, we will add text in a -02 version reflecting the closure. So then it should be OK to specify the default to be 48 bits and let an implementation use higher length if the implementation wants to. Also, could folks please see section 4 of the document and see this recommendation. [In a mixed SEND environment with SEND and unsecured nodes, the lengths of the nonce used by SEND and unsecured nodes MUST be identical.] The text above is suggested in case there are sloppy implementations that may overrun a buffer parsing the nonce when working in a mixed SEND environment.=20 Thanks, Hemant From shemant@cisco.com Mon Oct 17 10:25:18 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0AD21F8CCF for ; Mon, 17 Oct 2011 10:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.556 X-Spam-Level: X-Spam-Status: No, score=-5.556 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg5dOTkK14rL for ; Mon, 17 Oct 2011 10:25:18 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3D65621F8CC7 for ; Mon, 17 Oct 2011 10:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2636; q=dns/txt; s=iport; t=1318872318; x=1320081918; h=mime-version:subject:date:message-id:from:to:cc; bh=4P6fXMRGbpkPCaN02UY8698XCAQ83l3GcWc2NnpE0/c=; b=m9Awsbb9XVCGY/5YtJzMRDeXgI8KVtZmAd3w+TP7vOGBKdOGJ8JhgknD q9ALSRbycgGO2qqKNx0XoBaErxvbybKdd1jPy4Vzx+0xxEK/ZgWZ1YIvL ZXVayaUbNGUYPvGEP/MpIHF3J9tcFCYfwT+7qcVUzIFIQ4EOEBOQJY75Q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAF9knE6tJXG+/2dsb2JhbABDgk2mEIEFgXABBBIBCREDSRIBDB4GGAdXAQQbGqAEAZ5nhydhBIgCkSqMQg X-IronPort-AV: E=Sophos;i="4.69,360,1315180800"; d="scan'208,217";a="28996108" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 17 Oct 2011 17:25:17 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9HHPHpP023450; Mon, 17 Oct 2011 17:25:17 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 12:25:17 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8CF1.BCD6871E" Subject: curious about 64-bit alignment for Nonce Option by SEND? Date: Mon, 17 Oct 2011 12:25:16 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303130663@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: curious about 64-bit alignment for Nonce Option by SEND? Thread-Index: AcyM8byTq2iTAyhwS2Gf2k3GiHK2hQ== From: "Hemant Singh (shemant)" To: "IPv6 WG Mailing List" X-OriginalArrivalTime: 17 Oct 2011 17:25:17.0296 (UTC) FILETIME=[BD026700:01CC8CF1] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:25:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8CF1.BCD6871E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jari and other SEND authors, =20 I am curious why SEND proposed to align the Nonce Option on a 64-bit boundary? Was it due to a specific hardware reason? =20 Thanks, =20 Hemant ------_=_NextPart_001_01CC8CF1.BCD6871E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jari and = other SEND authors,

 

I am curious = why SEND proposed to align the Nonce Option on a 64-bit = boundary?   Was it due to a specific hardware = reason?

 

Thanks,

 

Hemant

------_=_NextPart_001_01CC8CF1.BCD6871E-- From shemant@cisco.com Mon Oct 17 11:00:57 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839F321F8BB2 for ; Mon, 17 Oct 2011 11:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.594 X-Spam-Level: X-Spam-Status: No, score=-5.594 tagged_above=-999 required=5 tests=[AWL=1.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63TPVtwLJLXL for ; Mon, 17 Oct 2011 11:00:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D50E521F8B2A for ; Mon, 17 Oct 2011 11:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1334; q=dns/txt; s=iport; t=1318874457; x=1320084057; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=8uE13Hh/EF0509p/mTvQiNqg+4ZEQL0A3rkCYkpB+0M=; b=kzBcSg6UYm9NanD1DE1Vv+TJI7QSz/4kVwgJAfKrCyl7fVjcDPJRo1nt iIlkPFG/MJr49Eas0N5lGPYpxS41dWkrcxCOVEOKb8DQyIB9VBmOYZD8r Af0FgU+LkBhJ7EojRaRVHlZuwqomy0izLiyDtwHLZtxXAb5EGKEf5TO/K c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEAAFxsnE6tJXG+/2dsb2JhbABDmTqPI4EFgW4BAQEEEgEdCjQJAgwEAgEIEQQBAQsGFwEGAUUIAQgBAQQBEggaoB0BnmSHJ2EEiAKRKYxB X-IronPort-AV: E=Sophos;i="4.69,360,1315180800"; d="scan'208";a="28979709" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 17 Oct 2011 18:00:56 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9HI0ueK005796; Mon, 17 Oct 2011 18:00:56 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 13:00:56 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: New Version Notification for, draft-hsingh-6man-enhanced-dad-01.txt Date: Mon, 17 Oct 2011 13:00:55 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30313069F@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30313065C@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for, draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyM6mhrlfwxXu/jTRGku7SUGXFaXgAA3WtQAAGZTiA= References: <4E9C58A5.80001@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30313065C@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Ray Hunter" , "Philip Homburg" , "Ole Troan" , "Brian E Carpenter" X-OriginalArrivalTime: 17 Oct 2011 18:00:56.0211 (UTC) FILETIME=[B7E6EE30:01CC8CF6] Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 18:00:57 -0000 -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Monday, October 17, 2011 1:23 PM To: Ray Hunter; Philip Homburg; Ole Troan; Brian E Carpenter Cc: IPv6 WG Mailing List Subject: RE: FW: New Version Notification for,draft-hsingh-6man-enhanced-dad-01.txt=20 >Since the number of bits for the nonce was an open question for the -01 document, we will add text in a -02 version reflecting the closure. So then it >should be OK to specify the default to be 48 bits and let an implementation use higher length if the implementation wants to. Actually, since we accepted Ray's idea, the idea matches the Nonce Option in RFC 3971 which also uses a minimum of 48 bits for the nonce and allows for a longer nonce. Since our document does not say anything else beyond RFC 3971, we don't have to add/change any text in this regard. This is the text we have in our document below. I raised the question today in case there was anyone who wanted one fixed length of the nonce in the reflected-DAD algorithm. [The document proposes use of the Nonce Option (specified in [RFC3971]). The nonce is a random number as specified in [RFC3971].] In the -02 version, we will incorporate editorial comments from Tassos. Regards, Hemant From jari.arkko@piuha.net Mon Oct 17 14:03:16 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C10F21F8C04 for ; Mon, 17 Oct 2011 14:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQGbD49qLoor for ; Mon, 17 Oct 2011 14:03:15 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 44D5721F8C0A for ; Mon, 17 Oct 2011 14:03:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EEC902D42C; Tue, 18 Oct 2011 00:03:13 +0300 (EEST) 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 Xim+XgdG+4Pr; Tue, 18 Oct 2011 00:03:13 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 4D1482CE32; Tue, 18 Oct 2011 00:03:13 +0300 (EEST) Message-ID: <4E9C9810.2010901@piuha.net> Date: Tue, 18 Oct 2011 00:03:12 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: "Hemant Singh (shemant)" Subject: Re: curious about 64-bit alignment for Nonce Option by SEND? References: <5B6B2B64C9FE2A489045EEEADDAFF2C303130663@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303130663@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 21:03:16 -0000 These options are ND options as specified in RFC 4861, which states: Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message. Options should be padded when necessary to ensure that they end on their natural 64-bit boundaries. All options are of the form: There are no other alignment rules on RFC 3971 options IIRC. The Nonce option section in RFC 3971 does say: The length of the random number MUST be at least 6 bytes. The length of the random number MUST be selected so that the length of the nonce option is a multiple of 8 octets. But this is just to satisfy RFC 4861 criteria and simplify the length field option processing, as the basic ND option length field is counted in units of 8 octets. So the possible actual random number sizes are 6, 14, 22, etc. If this is inconvenient to implementations, they could of course select a suitable random number size (e.g., 8 octets) and pad the rest to a constant value or copy some random number bytes to the option multiple times. Jari On 17.10.2011 20:25, Hemant Singh (shemant) wrote: > > Jari and other SEND authors, > > I am curious why SEND proposed to align the Nonce Option on a 64-bit boundary? Was it due to a specific hardware reason? > > Thanks, > > Hemant > From v6ops@globis.net Mon Oct 17 14:18:50 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B477221F8C49 for ; Mon, 17 Oct 2011 14:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcmiRVTR334a for ; Mon, 17 Oct 2011 14:18:50 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id D08B221F8C44 for ; Mon, 17 Oct 2011 14:18:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id DD1FB87007A; Mon, 17 Oct 2011 23:18:48 +0200 (CEST) X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at globis01.globis.net X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 20 hex): Subject: ... for, draft-hsingh-6man-enhanced-dad-01.txt\n \n Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp7vLIkhd6mh; Mon, 17 Oct 2011 23:18:39 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 59AE7870047; Mon, 17 Oct 2011 23:18:39 +0200 (CEST) Message-ID: <4E9C9BAF.5050402@globis.net> Date: Mon, 17 Oct 2011 23:18:39 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Philip Homburg , 6man Mailing List Subject: Re: FW: New Version Notification for, draft-hsingh-6man-enhanced-dad-01.txt Content-Type: multipart/alternative; boundary="------------010006060800010802000708" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 21:18:50 -0000 This is a multi-part message in MIME format. --------------010006060800010802000708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IMHO Both proposed options can reuse existing standards and code. Both should work. What's there to gain by making the nonce shorter? What's there to gain by limiting the nonce to a fixed length? I'm just thinking of cases like a whole bunch of products with IPv6 RFID tags going through a scanner on a palette and all trying to get an address at once. regards, RayH > Message: 1 > Date: Mon, 17 Oct 2011 17:41:05 +0200 > From: Philip Homburg > To: "Hemant Singh (shemant)" > Cc: IPv6 WG Mailing List > Subject: Re: FW: New Version Notification for > draft-hsingh-6man-enhanced-dad-01.txt > Message-ID: > > In your letter dated Mon, 17 Oct 2011 10:25:19 -0500 you wrote: > >> >Appreciate the quick reply. Note BrianC already noted that 20 bits will >> >not suffice by saying "It puts you into birthday-paradox territory on a >> >LAN with a few hundred nodes.". His email is at the URL below. >> > >> >http://www.ietf.org/mail-archive/web/ipv6/current/msg14835.html >> > > I'm not sure how you would get a birthday paradox here. Applying the birthday > paradox, you would get that if you have a network with a 1000 nodes, and all > nodes try to configure the exact same IPv6 address at the same time, then > there is a probability of about 0.5 that two nodes will mistakenly assume that > there is a loopback situation and all the others will detect a duplicate > address. > > That's not a problem I would worry about. > > --------------010006060800010802000708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit IMHO Both proposed options can reuse existing standards and code. Both should work.

What's there to gain by making the nonce shorter?
What's there to gain by limiting the nonce to a fixed length?

I'm just thinking of cases like a whole bunch of products with IPv6 RFID tags going through a scanner on a palette and all trying to get an address at once.

regards,
RayH
Message: 1
Date: Mon, 17 Oct 2011 17:41:05 +0200
From: Philip Homburg <pch-6man-1a@u-1.phicoh.com>
To: "Hemant Singh (shemant)" <shemant@cisco.com>
Cc: IPv6 WG Mailing List <ipv6@ietf.org>
Subject: Re: FW: New Version Notification for
	draft-hsingh-6man-enhanced-dad-01.txt 
Message-ID: <m1RFpJN-0001kQC@stereo.hq.phicoh.net>

In your letter dated Mon, 17 Oct 2011 10:25:19 -0500 you wrote:
  
>Appreciate the quick reply.  Note BrianC already noted that 20 bits will
>not suffice by saying "It puts you into birthday-paradox territory on a
>LAN with a few hundred nodes.".  His email is at the URL below.
>
>http://www.ietf.org/mail-archive/web/ipv6/current/msg14835.html
    

I'm not sure how you would get a birthday paradox here. Applying the birthday
paradox, you would get that if you have a network with a 1000 nodes, and all
nodes try to configure the exact same IPv6 address at the same time, then
there is a probability of about 0.5 that two nodes will mistakenly assume that
there is a loopback situation and all the others will detect a duplicate
address.

That's not a problem I would worry about.
--------------010006060800010802000708-- From shemant@cisco.com Mon Oct 17 15:29:49 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8AF911E8095 for ; Mon, 17 Oct 2011 15:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.628 X-Spam-Level: X-Spam-Status: No, score=-5.628 tagged_above=-999 required=5 tests=[AWL=0.971, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxvMlWcvffYd for ; Mon, 17 Oct 2011 15:29:49 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0781011E8082 for ; Mon, 17 Oct 2011 15:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2200; q=dns/txt; s=iport; t=1318890589; x=1320100189; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=QiXsOn5kAPumV1pQ5p4Wo3swJHR34qDTEQJSHUxZyw8=; b=D24BM4vtloitB63lKyP5+0oDZZ+aDV4gwBkDcLeCEBQgGTN+vrJKq+bX gFsQZRruK+SnW5qwhXkJ78OhYDbUC6ldGI4jsFilI3cLSnm+e5FQTJ2o3 eWTpqwxg2LvSKJ5/hZWUvGmuq6fq7ADfeSzzMdrET02dfMOFchl+9cmpy o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEAANqrnE6tJV2a/2dsb2JhbABDmTKPJYEFgW4BAQEEEgEdCjQLDAQCAQgRBAEBAQoGFwEGAUUJCAEBBBMIGodlmE4Bnm+HJ2EEiAKRKYxB X-IronPort-AV: E=Sophos;i="4.69,361,1315180800"; d="scan'208";a="29061938" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 17 Oct 2011 22:29:48 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9HMTmFF026164; Mon, 17 Oct 2011 22:29:48 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 17:29:48 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: curious about 64-bit alignment for Nonce Option by SEND? Date: Mon, 17 Oct 2011 17:29:46 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031307CA@XMB-RCD-109.cisco.com> In-Reply-To: <4E9C9810.2010901@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: curious about 64-bit alignment for Nonce Option by SEND? Thread-Index: AcyNEDHmT2r0mztFTnukidBguJvrggAC3VgQ References: <5B6B2B64C9FE2A489045EEEADDAFF2C303130663@XMB-RCD-109.cisco.com> <4E9C9810.2010901@piuha.net> From: "Hemant Singh (shemant)" To: "Jari Arkko" X-OriginalArrivalTime: 17 Oct 2011 22:29:48.0218 (UTC) FILETIME=[4753D9A0:01CC8D1C] Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 22:29:49 -0000 Jari, Ah, I forgot to check the ND RFC 4861 for option recommendations - appreciate the quick reply! I suspected all along to align data on the 64-bit boundary would be to use newer 64-bit processors. Good work on the SEND document because the Nonce Option is defined very well and we could use this option to catch reflected DAD messages. While I have you here, if you could review the section 4 related to mixed-SEND (secured and un-secured nodes) environments, it would be great. =20 http://tools.ietf.org/html/draft-hsingh-6man-enhanced-dad-01 Regards, Hemant -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Monday, October 17, 2011 5:03 PM To: Hemant Singh (shemant) Cc: IPv6 WG Mailing List Subject: Re: curious about 64-bit alignment for Nonce Option by SEND? These options are ND options as specified in RFC 4861, which states: Neighbor Discovery messages include zero or more options, some of which may appear multiple times in the same message. Options should be padded when necessary to ensure that they end on their natural 64-bit boundaries. All options are of the form: There are no other alignment rules on RFC 3971 options IIRC. The Nonce option section in RFC 3971 does say: The length of the random number MUST be at least 6 bytes. The length of the random number MUST be selected so that the length of the nonce option is a multiple of 8 octets. But this is just to satisfy RFC 4861 criteria and simplify the length field option processing, as the basic ND option length field is counted in units of 8 octets. So the possible actual random number sizes are 6, 14, 22, etc. If this is inconvenient to implementations, they could of course select a suitable random number size (e.g., 8 octets) and pad the rest to a constant value or copy some random number bytes to the option multiple times. Jari On 17.10.2011 20:25, Hemant Singh (shemant) wrote: > > Jari and other SEND authors, > > I am curious why SEND proposed to align the Nonce Option on a 64-bit boundary? Was it due to a specific hardware reason? > > Thanks, > > Hemant > From pthubert@cisco.com Tue Oct 18 00:12:43 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3612A1F0C77 for ; Tue, 18 Oct 2011 00:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.941 X-Spam-Level: X-Spam-Status: No, score=-7.941 tagged_above=-999 required=5 tests=[AWL=2.658, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ-K8TON4RoY for ; Tue, 18 Oct 2011 00:12:42 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 60F881F0C72 for ; Tue, 18 Oct 2011 00:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2403; q=dns/txt; s=iport; t=1318921962; x=1320131562; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=TIGvFAL/YvcQXYAUMQnYFV8u+iyLkcqpP4nLkemtPpM=; b=VeVmfxI0hwfCLriAK+78B3WapHqT5QSPliHOzQ1/YEkavRe/aQJz4KQu 6mkfqP6s+iRi1T1djIxvZAGCFHbuIuzrYfOEHhSkzWmGYB14mCiwWW192 3Bjnqy6u9buw3kh6EP8h2+zjUJiRXhZ2KC24whMc43eZhwFuQin/tXVwj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgAAOslnU6Q/khM/2dsb2JhbABDmTaPJoEFgW4BAQEBAgEBAQEPAR0KNAQMBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHXQiXNQGeegSHJ2EEmS+MJQ X-IronPort-AV: E=Sophos;i="4.69,363,1315180800"; d="scan'208";a="57994408" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 18 Oct 2011 07:12:35 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9I7CZbo001657; Tue, 18 Oct 2011 07:12:35 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 09:12:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus call on adopting: draft-lynn-6man-6lobac Date: Tue, 18 Oct 2011 09:12:34 +0200 Message-ID: In-Reply-To: <34E4F50CAFA10349A41E0756550084FB11D94CC0@PRVPEXVS04.corp.twcable.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call on adopting: draft-lynn-6man-6lobac Thread-Index: AcyIODbgyUldudCRSyuUBEcAehr94gAFIjKQAUYiMLA= References: <4E947777.1040507@innovationslab.net> <34E4F50CAFA10349A41E0756550084FB11D94CC0@PRVPEXVS04.corp.twcable.com> From: "Pascal Thubert (pthubert)" To: "George, Wes" , "Brian Haberman" , "IPv6 WG Mailing List" X-OriginalArrivalTime: 18 Oct 2011 07:12:35.0232 (UTC) FILETIME=[4F865A00:01CC8D65] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 07:12:43 -0000 +1 Cheers, Pascal -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of George, Wes Sent: mardi 11 octobre 2011 21:34 To: Brian Haberman; IPv6 WG Mailing List Subject: RE: Consensus call on adopting: draft-lynn-6man-6lobac Support adoption Thanks, Wes > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf=20 > Of Brian Haberman > Sent: Tuesday, October 11, 2011 1:06 PM > To: IPv6 WG Mailing List > Subject: Consensus call on adopting: draft-lynn-6man-6lobac > > All, > This is a consensus call on adopting: > > Title : Transmission of IPv6 over MS/TP Networks > Author(s) : Kerry Lynn > Jerry Martocci > Carl Neilson > Stuart Donaldson > Filename : draft-lynn-6man-6lobac-02.txt > Pages : 14 > Date : 2011-10-10 > > as a 6MAN working group document. Please state your opinion, positive > or negative, on the mailing list or to the chairs. This consensus=20 > call will end on October 25, 2011. > > Regards, > Brian & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From narten@us.ibm.com Tue Oct 18 03:15:59 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966B621F84AE for ; Tue, 18 Oct 2011 03:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1JPB45cMaIl for ; Tue, 18 Oct 2011 03:15:59 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1D44C21F84A2 for ; Tue, 18 Oct 2011 03:15:58 -0700 (PDT) Received: from /spool/local by us.ibm.com with XMail ESMTP for from ; Tue, 18 Oct 2011 04:15:47 -0600 Received: from d03relay05.boulder.ibm.com ([9.17.195.107]) by us.ibm.com ([192.168.1.133]) with XMail ESMTP; Tue, 18 Oct 2011 04:14:57 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p9IAEfOG087654 for ; Tue, 18 Oct 2011 04:14:44 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p9IAEdSb032219 for ; Tue, 18 Oct 2011 04:14:41 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-224-37.mts.ibm.com [9.65.224.37]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p9IAEc6E032180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Oct 2011 04:14:39 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p9IAEZ4p017059; Tue, 18 Oct 2011 06:14:36 -0400 Message-Id: <201110181014.p9IAEZ4p017059@cichlid.raleigh.ibm.com> To: "Hemant Singh (shemant)" Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C3031303D6@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303D6@XMB-RCD-109.cisco.com> Comments: In-reply-to "Hemant Singh (shemant)" message dated "Fri, 14 Oct 2011 18:57:00 -0500." Date: Tue, 18 Oct 2011 06:14:35 -0400 From: Thomas Narten x-cbid: 11101810-2398-0000-0000-00000118800E Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 10:15:59 -0000 The WG should produce one single document, not two. This is pretty simple stuff here and we don't need 2 documents, each only 5 pages long. Indeed, I think it's sort of unfortunate that we have started out with two competing documents, for no good reason that I can see. Its not like the proposed approaches are different. Per previous mailing list discussion, the problem and solution are pretty straightforward. Let's ensure that one document gets published quickly. Thomas From rdroms.ietf@gmail.com Tue Oct 18 04:29:01 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E845B21F85BB for ; Tue, 18 Oct 2011 04:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MY5D4CIK+q4M for ; Tue, 18 Oct 2011 04:29:01 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5FADF21F85B9 for ; Tue, 18 Oct 2011 04:29:01 -0700 (PDT) Received: by pzk34 with SMTP id 34so1359245pzk.9 for ; Tue, 18 Oct 2011 04:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=KmqJHYG9skTU2KtQ1/ct+Hm+MKK6GGlpcqWBQx3s0rU=; b=KQJ8ra+l9gQ4hj44bkdzQCfkRfi5MtTc6Kd3Op4v4FZfMKphcc3YepGp5CVyIsqig4 iET44ell258dmXMPUbNC/rrPm4aGsrAAoT55c3/QsQx++UfpdtIn3Cg0LExRPjzU/fhx y4YelaJF8IN4sc1+4u9rWx8yZumqX3YyJBL7g= Received: by 10.68.23.35 with SMTP id j3mr4431385pbf.44.1318937340970; Tue, 18 Oct 2011 04:29:00 -0700 (PDT) Received: from [192.168.6.178] (ip-64-134-224-108.public.wayport.net. [64.134.224.108]) by mx.google.com with ESMTPS id z3sm6488832pbu.7.2011.10.18.04.28.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Oct 2011 04:28:59 -0700 (PDT) Subject: Re: Consensus call on adopting: draft-lynn-6man-6lobac References: <4E947777.1040507@innovationslab.net> <34E4F50CAFA10349A41E0756550084FB11D94CC0@PRVPEXVS04.corp.twcable.com> From: Ralph Droms Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (9A334) In-Reply-To: Message-Id: <8054ED0D-BA43-40E2-8BDE-579990BBD009@gmail.com> Date: Tue, 18 Oct 2011 04:28:32 -0700 To: "ipv6@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 11:29:02 -0000 In my opinion, this document is ready for WG adoption. - Ralph On Oct 18, 2011, at 12:12 AM, "Pascal Thubert (pthubert)" wrote: > +1 >=20 > Cheers, >=20 > Pascal >=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > George, Wes > Sent: mardi 11 octobre 2011 21:34 > To: Brian Haberman; IPv6 WG Mailing List > Subject: RE: Consensus call on adopting: draft-lynn-6man-6lobac >=20 > Support adoption >=20 > Thanks, >=20 > Wes >=20 >=20 >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf=20 >> Of Brian Haberman >> Sent: Tuesday, October 11, 2011 1:06 PM >> To: IPv6 WG Mailing List >> Subject: Consensus call on adopting: draft-lynn-6man-6lobac >>=20 >> All, >> This is a consensus call on adopting: >>=20 >> Title : Transmission of IPv6 over MS/TP Networks >> Author(s) : Kerry Lynn >> Jerry Martocci >> Carl Neilson >> Stuart Donaldson >> Filename : draft-lynn-6man-6lobac-02.txt >> Pages : 14 >> Date : 2011-10-10 >>=20 >> as a 6MAN working group document. Please state your opinion, positive >=20 >> or negative, on the mailing list or to the chairs. This consensus=20 >> call will end on October 25, 2011. >>=20 >> Regards, >> Brian & Bob >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject > to copyright belonging to Time Warner Cable. This E-mail is intended > solely for the use of the individual or entity to which it is addressed. > If you are not the intended recipient of this E-mail, you are hereby > notified that any dissemination, distribution, copying, or action taken > in relation to the contents of and attachments to this E-mail is > strictly prohibited and may be unlawful. If you have received this > E-mail in error, please notify the sender immediately and permanently > delete the original and any copy of this E-mail and any printout. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From shemant@cisco.com Tue Oct 18 08:28:11 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207C021F8BC3 for ; Tue, 18 Oct 2011 08:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BEu1SzBx0d7 for ; Tue, 18 Oct 2011 08:28:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 57BD121F8B8D for ; Tue, 18 Oct 2011 08:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1668; q=dns/txt; s=iport; t=1318951690; x=1320161290; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=l2r/M6wXBHHj6Sm4TTTs+t0viVaQJkF1X0vhF38utyc=; b=PkJRkx/lC/aUyilaBMhAs3SSfvo7Vuq/bhTyfd27F/He4m0zGBwOwtrt RsdvHJYmUOrPefI4Qy6XWPmbdOkHyTD9NYZJn4J1/lUq97WOcOlGVIJ5r ceMD+N0U1e8KS+LTbmutcvaiUwo+vi0WZSB6d5IxxzryW3rujzUkFi5vE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQAAIeanU6tJV2Y/2dsb2JhbABEmT6PMIEFgW4BAQEEEgEdCjQJAgwEAgEIEQQBAQsGFwEGAUUIAQgBAQQTCAESB4dmmDsBnnuHOmEEiAKRLoxB X-IronPort-AV: E=Sophos;i="4.69,365,1315180800"; d="scan'208";a="29249349" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 18 Oct 2011 15:28:09 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9IFS9Vs013090; Tue, 18 Oct 2011 15:28:09 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 10:28:09 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Date: Tue, 18 Oct 2011 10:28:08 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031309EF@XMB-RCD-109.cisco.com> In-Reply-To: <201110181014.p9IAEZ4p017059@cichlid.raleigh.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt Thread-Index: AcyNfvFUlqx1JjxFSqid1+G3xu0TLAAJ8svA References: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A436F@XMB-RCD-109.cisco.com> <4E98B7AE.9050103@forthnet.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303AC@XMB-RCD-109.cisco.com> <4E98C626.2060102@forthnetgroup.gr> <5B6B2B64C9FE2A489045EEEADDAFF2C3031303D6@XMB-RCD-109.cisco.com> <201110181014.p9IAEZ4p017059@cichlid.raleigh.ibm.com> From: "Hemant Singh (shemant)" To: "Thomas Narten" X-OriginalArrivalTime: 18 Oct 2011 15:28:09.0223 (UTC) FILETIME=[8A5D5170:01CC8DAA] Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 15:28:11 -0000 Thomas, Totally agree. Around the day I published our document, I contacted the Chairs of 6man and also contacted a v6ops Chair to discuss resolving the two documents. I and Wes would have totally worked with Rajiv to resolve the two documents issue. However, during last week Rajiv was out on PTO and this week he is away too. That is why closing the issue has taken time. The draft-asati-01 does not have a workable solution yet. See http://www.ietf.org/mail-archive/web/ipv6/current/msg14828.html The email in the URL above also proposes a path moving forward for one document in 6man. See other questions asked of the draft-asati that haven't been closed yet. http://www.ietf.org/mail-archive/web/v6ops/current/msg10411.html That is why we wrote our document because we need a solution ASAP for broadband network DAD loop back issues. =20 Hemant -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com]=20 Sent: Tuesday, October 18, 2011 6:15 AM To: Hemant Singh (shemant) Cc: Tassos Chatzithomaoglou; IPv6 WG Mailing List Subject: Re: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt The WG should produce one single document, not two. This is pretty simple stuff here and we don't need 2 documents, each only 5 pages long. Indeed, I think it's sort of unfortunate that we have started out with two competing documents, for no good reason that I can see. Its not like the proposed approaches are different. Per previous mailing list discussion, the problem and solution are pretty straightforward. Let's ensure that one document gets published quickly. Thomas From jari.arkko@piuha.net Tue Oct 18 11:29:52 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E7F21F8C16 for ; Tue, 18 Oct 2011 11:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zq23kwAhH2Wd for ; Tue, 18 Oct 2011 11:29:51 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 988C821F8BDB for ; Tue, 18 Oct 2011 11:29:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7AD542CEFF; Tue, 18 Oct 2011 21:29:39 +0300 (EEST) 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 aKg93R6zygDB; Tue, 18 Oct 2011 21:29:39 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DF2B92CE32; Tue, 18 Oct 2011 21:29:38 +0300 (EEST) Message-ID: <4E9DC592.6030208@piuha.net> Date: Tue, 18 Oct 2011 21:29:38 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: Donald Eastlake , Suresh Krishnan Subject: Re: Last Call: (Reserved IPv6 Interface Identifier for Proxy Mobile IPv6) to Informational RFC References: <20110729121436.14048.14658.idtracker@ietfa.amsl.com> <4E76DF0F.6020307@piuha.net> <4E76E29E.2000407@piuha.net> <4E7A607C.8000508@ericsson.com> <4E7BB45C.6000508@ericsson.com> <201109231221.p8NCLQug028871@cichlid.raleigh.ibm.com> <201109261357.p8QDvCKd006148@cichlid.raleigh.ibm.com> In-Reply-To: <201109261357.p8QDvCKd006148@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 18:29:52 -0000 The last call ended yesterday. We are fine with going ahead as proposed standard, but there were two other issues raised during discussion. 1. Possible draft to update RFC 5453 / 5342 to say that allocations in either one should not conflict with each other. I tend to agree with Thomas that we are unlikely to see much use of these registries and we should not worry too much about it. That being said, if Suresh finds enough time to write a draft on this I wouldn't mind shepherding it forward. In any case, it is a separate matter from Sri's draft. 2. Whether to allocate an EUI-64 from the IANA block and base the IID on that, or to allocate just a reserved value per RFC 5453. Collisions are extremely unlikely in either case. Personally, I'd prefer an EUI-64 based approach though, because collisions based on random addresses are then ruled out completely, and only manual or multiple MAG type collisions may occur. That is a personal preference though. But we need to choose. Are we going with the draft as is, or changing it to use EUI-64 allocation? I saw Suresh support this approach, Sri had questions (were those answered and what was your conclusion?), what about the rest of you? In any case, I'm sending the draft to the IESG review. Jari From mrw@lilacglade.org Tue Oct 18 11:45:42 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6310421F86C1 for ; Tue, 18 Oct 2011 11:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PxPQj5bB4va for ; Tue, 18 Oct 2011 11:45:42 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id F2D6B21F86B3 for ; Tue, 18 Oct 2011 11:45:41 -0700 (PDT) Received: from [192.168.1.197] (pool-71-184-169-63.bstnma.east.verizon.net [71.184.169.63]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id 8AF40202C9; Tue, 18 Oct 2011 14:46:52 -0400 (EDT) Subject: Re: Last Call: (Reserved IPv6 Interface Identifier for Proxy Mobile IPv6) to Informational RFC Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <4E9DC592.6030208@piuha.net> Date: Tue, 18 Oct 2011 14:45:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110729121436.14048.14658.idtracker@ietfa.amsl.com> <4E76DF0F.6020307@piuha.net> <4E76E29E.2000407@piuha.net> <4E7A607C.8000508@ericsson.com> <4E7BB45C.6000508@ericsson.com> <201109231221.p8NCLQug028871@cichlid.raleigh.ibm.com> <201109261357.p8QDvCKd006148@cichlid.raleigh.ibm.com> <4E9DC592.6030208@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1084) Cc: Donald Eastlake , IETF IPv6 Mailing List , Suresh Krishnan X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 18:45:42 -0000 On Oct 18, 2011, at 2:29 PM, Jari Arkko wrote: > 2. Whether to allocate an EUI-64 from the IANA block and base the IID = on that, or to allocate just a reserved value per RFC 5453. Collisions = are extremely unlikely in either case. Personally, I'd prefer an EUI-64 = based approach though, because collisions based on random addresses are = then ruled out completely, and only manual or multiple MAG type = collisions may occur. That is a personal preference though. But we need = to choose. Are we going with the draft as is, or changing it to use = EUI-64 allocation? I saw Suresh support this approach, Sri had questions = (were those answered and what was your conclusion?), what about the rest = of you? I would prefer that we use an EUI-64-based approach, but my opinion is = not strong enough to block the document for that reason, if others feel = strongly that we should use a reserved value from some other space. Margaret From suresh.krishnan@ericsson.com Tue Oct 18 20:52:29 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE77021F85A7 for ; Tue, 18 Oct 2011 20:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAFqXGFPDNHR for ; Tue, 18 Oct 2011 20:52:29 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id DFF6321F8593 for ; Tue, 18 Oct 2011 20:52:28 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9J3qMtD028295; Tue, 18 Oct 2011 22:52:23 -0500 Received: from [142.133.10.107] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 18 Oct 2011 23:52:17 -0400 Message-ID: <4E9E48BE.2030604@ericsson.com> Date: Tue, 18 Oct 2011 23:49:18 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Jari Arkko Subject: Re: Last Call: (Reserved IPv6 Interface Identifier for Proxy Mobile IPv6) to Informational RFC References: <20110729121436.14048.14658.idtracker@ietfa.amsl.com> <4E76DF0F.6020307@piuha.net> <4E76E29E.2000407@piuha.net> <4E7A607C.8000508@ericsson.com> <4E7BB45C.6000508@ericsson.com> <201109231221.p8NCLQug028871@cichlid.raleigh.ibm.com> <201109261357.p8QDvCKd006148@cichlid.raleigh.ibm.com> <4E9DC592.6030208@piuha.net> In-Reply-To: <4E9DC592.6030208@piuha.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Donald Eastlake , IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 03:52:30 -0000 Hi Jari, On 11-10-18 02:29 PM, Jari Arkko wrote: > The last call ended yesterday. We are fine with going ahead as proposed standard, but there were two other issues raised during discussion. > > 1. Possible draft to update RFC 5453 / 5342 to say that allocations in either one should not conflict with each other. I tend to agree with Thomas that we are unlikely to see much use of these registries and we should not worry too much about it. That being said, if Suresh finds enough time to write a draft on this I wouldn't mind shepherding it forward. In any case, it is a separate matter from Sri's draft. I think this would be relatively simple to fix. We just need to add a new range entry into the IID registry to mark all of IIDs based on the IANA block as reserved and point to RFC5342. I can do this pretty quickly once the draft submission reopens. > > 2. Whether to allocate an EUI-64 from the IANA block and base the IID on that, or to allocate just a reserved value per RFC 5453. Collisions are extremely unlikely in either case. Personally, I'd prefer an EUI-64 based approach though, because collisions based on random addresses are then ruled out completely, and only manual or multiple MAG type collisions may occur. That is a personal preference though. But we need to choose. Are we going with the draft as is, or changing it to use EUI-64 allocation? I saw Suresh support this approach, Sri had questions (were those answered and what was your conclusion?), what about the rest of you? I am personally fine with either approach. Thanks Suresh From washam.fan@gmail.com Thu Oct 20 06:47:30 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0275D21F8B9F; Thu, 20 Oct 2011 06:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVS-NqSilz5K; Thu, 20 Oct 2011 06:47:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0870B21F8B91; Thu, 20 Oct 2011 06:47:28 -0700 (PDT) Received: by wyh22 with SMTP id 22so3256976wyh.31 for ; Thu, 20 Oct 2011 06:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QLf2HyfUE/ttNjrGZItcoThsbEY3DO1QvhKLWcRPusc=; b=mQlMVJ+Iw5HtF/am4qZ5q5cRxszTY2UZ5NE/eMM9yCMdQ1stJgoPrOvsAYZWxrBNIF IAbJRAuxwuEY9Lz7CVW0d3b2ZRLkpPdDBt39IutzjMEVmNiSj+wGWqR4Upuphp7o0kgv rt+mObXDAZNzgsKphbXmW6Mbj3FZreIoovHNc= MIME-Version: 1.0 Received: by 10.216.82.136 with SMTP id o8mr1841213wee.31.1319118448185; Thu, 20 Oct 2011 06:47:28 -0700 (PDT) Received: by 10.216.85.4 with HTTP; Thu, 20 Oct 2011 06:47:28 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> References: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> Date: Thu, 20 Oct 2011 21:47:28 +0800 Message-ID: Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback From: Washam Fan To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, draft-asati-v6ops-dad-loopback@tools.ietf.org, ipv6@ietf.org, Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:47:30 -0000 Hi, Sorry for late response. Since NS(DAD) traverse the same link, couldn't we just use src MAC of the received NS(DAD) to identify if the NS is the one sent by the interface earlier? Am I missing something? THanks, washam 2011/10/11, Hemant Singh (shemant) : > Lorenzo, > > > > I realized that the looping back of ND messages, especially during DAD > is an issue that needs to be solved at a fundamental level in ND DAD. > Thus I and Wes Beebee came up with a new document for 6man that has no > need to sending probes and then also raising questions such as the ones > you raised as in what is the state of the address while the timer is > ticking. You were on the right track with some of your statement > below. There was some fun integrating with SEND and also some other > subtle issues. I think our document can be referenced as an automated > means in the draft-asati-v6ops-dad-loopback. See > > > > http://www.ietf.org/id/draft-hsingh-6man-enhanced-dad-00.txt > > > > Hemant > > > > > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Lorenzo Colitti > Sent: Monday, August 29, 2011 6:15 AM > To: Erik Kline > Cc: v6ops@ietf.org; draft-asati-v6ops-dad-loopback@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback > > > > On Mon, Aug 29, 2011 at 18:54, Erik Kline wrote: > > +1 to section 3.2, generally. > > > > This is definitely a useful problem to solve. I have personally had to > work around this situation more than once, sometimes by disabling DAD > completely on routers. > > > > A couple of points that the draft doesn't explain: > > - Why can't the node simply retry DAD without the nonce option? > > - How does the nonce option guarantee that the address is unique? Just > probabilistically, because the nonce would have to collide? > > - Why only send the nonce on the second (and subsequent?) messages? Why > not simply send out all NSes with nonces all the time? > > - What state is the address in while the timer is ticking? > > > > Also: in some cases this happens when buggy drivers (typically wifi > drivers) loop back the node's own multicast packets. This is a violation > of 802.11, but nobody notices since it doesn't affect IPv4. With your > proposed scheme, DAD would succeed, but the node would be continuously > receiving its own multicast packets. What happens in such situations? > > From gert@space.net Thu Oct 20 07:07:04 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B019621F8BF9 for ; Thu, 20 Oct 2011 07:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQbwDzeIiJ15 for ; Thu, 20 Oct 2011 07:07:04 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 12F3B21F8BF8 for ; Thu, 20 Oct 2011 07:07:03 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 4B79EF87C1 for ; Thu, 20 Oct 2011 16:07:01 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 29CFBF87C9 for ; Thu, 20 Oct 2011 16:07:01 +0200 (CEST) Received: (qmail 44623 invoked by uid 1007); 20 Oct 2011 16:07:01 +0200 Date: Thu, 20 Oct 2011 16:07:01 +0200 From: Gert Doering To: Washam Fan Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback Message-ID: <20111020140701.GO72014@Space.Net> References: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, ipv6@ietf.org, draft-asati-v6ops-dad-loopback@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:07:04 -0000 Hi, On Thu, Oct 20, 2011 at 09:47:28PM +0800, Washam Fan wrote: > Sorry for late response. > > Since NS(DAD) traverse the same link, couldn't we just use src MAC of > the received NS(DAD) to identify if the NS is the one sent by the > interface earlier? > > Am I missing something? Yes. Not all the world is Ethernet. We've seen this problem mostly on SDH/Sonet links, which are either HDLC or PPP encapsulated, and don't have MAC addresses in their frames. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From shemant@cisco.com Thu Oct 20 07:08:21 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C8C21F8C18; Thu, 20 Oct 2011 07:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.933 X-Spam-Level: X-Spam-Status: No, score=-5.933 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0SYHBBB6z4E; Thu, 20 Oct 2011 07:08:21 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3981421F8C09; Thu, 20 Oct 2011 07:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=987; q=dns/txt; s=iport; t=1319119701; x=1320329301; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=acvecoGan/QCkqSn1ImDIiH//lKi+W9KRZboVKp9EE4=; b=Szq5ErPnMGoWFSNMyT+h5IzfJv5iGuky0MX5FmzTnb/UrQuAyiTXsJ2T VLKKv/7aDo+KuKO9j5vXGDQyA+81Bx6kiRe28PM1snToiq+g2Qhkg9zKO HU0VD7Y4qjlT1fLPJYrcb/PGjxbf6s4ku0GoTzizkGZ/MVOhGUIXlxzzx 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQAAEoqoE6tJXG8/2dsb2JhbAA5CplYjz6BBYFuAQEBBBIBHQo/DAQCAQgRBAEBCwYXAQYBICUJCAEBBBMIGodmlzIBnjmEeoJOYQSIA5EwhH2HRQ X-IronPort-AV: E=Sophos;i="4.69,379,1315180800"; d="scan'208";a="29796086" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 20 Oct 2011 14:08:20 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9KE8KHc012925; Thu, 20 Oct 2011 14:08:20 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 09:08:20 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [v6ops] new draft: draft-asati-v6ops-dad-loopback Date: Thu, 20 Oct 2011 09:08:19 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD138@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] new draft: draft-asati-v6ops-dad-loopback Thread-Index: AcyPLs/lUaxLfScSSJWuXUql1TU4KQAAgIKw References: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Washam Fan" X-OriginalArrivalTime: 20 Oct 2011 14:08:20.0681 (UTC) FILETIME=[B8FF4B90:01CC8F31] Cc: v6ops@ietf.org, draft-asati-v6ops-dad-loopback@tools.ietf.org, ipv6@ietf.org, Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:08:22 -0000 Washam, -----Original Message----- From: Washam Fan [mailto:washam.fan@gmail.com]=20 Sent: Thursday, October 20, 2011 9:47 AM To: Hemant Singh (shemant) Cc: Lorenzo Colitti; Erik Kline; v6ops@ietf.org; draft-asati-v6ops-dad-loopback@tools.ietf.org; ipv6@ietf.org Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback >Since NS(DAD) traverse the same link, couldn't we just use src MAC of the received NS(DAD) to identify if the NS is the one sent by the interface earlier? No. Two nodes could almost simultaneously issue a NS(DAD) and both the nodes have the same mac-address and thus the situation is a DAD failure and not a looped back NS(DAD). I use the term of NS(DAD) to denote a NS issue for the purpose of DAD where the NS has a unspecified source address. That is why a nonce is needed and specified in a completed algorithm to detect looped back NS(DAD) messages in=20 http://tools.ietf.org/html/draft-hsingh-6man-enhanced-dad-01 Hemant From wesley.george@twcable.com Thu Oct 20 07:19:42 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9B321F8B85; Thu, 20 Oct 2011 07:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVVL8DpoO00x; Thu, 20 Oct 2011 07:19:42 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 51B7921F8B81; Thu, 20 Oct 2011 07:19:42 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,378,1315195200"; d="scan'208";a="272605290" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 20 Oct 2011 10:15:57 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Thu, 20 Oct 2011 10:19:30 -0400 From: "George, Wes" To: "Hemant Singh (shemant)" , Washam Fan Date: Thu, 20 Oct 2011 10:19:29 -0400 Subject: RE: [v6ops] new draft: draft-asati-v6ops-dad-loopback Thread-Topic: [v6ops] new draft: draft-asati-v6ops-dad-loopback Thread-Index: AcyPLs/lUaxLfScSSJWuXUql1TU4KQAAgIKwAACE9tA= Message-ID: References: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD138@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD138@XMB-RCD-109.cisco.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: "v6ops@ietf.org" , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:19:43 -0000 > a completed > algorithm to detect looped back NS(DAD) messages in > > http://tools.ietf.org/html/draft-hsingh-6man-enhanced-dad-01 > [WEG]] It is also worth noting that the authors of draft-asati are working = to incorporate some elements of that draft into the one that Hemant mention= s above, and a single draft will proceed within 6man - draft-asati will mos= t likely expire in silence :-) Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From shemant@cisco.com Thu Oct 20 07:32:25 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C189D21F8BF4; Thu, 20 Oct 2011 07:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.651, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SipgTdMqD-d; Thu, 20 Oct 2011 07:32:24 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5B421F8BDB; Thu, 20 Oct 2011 07:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1672; q=dns/txt; s=iport; t=1319121144; x=1320330744; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=KPuKN+gGFjGK1575rGcarsjKHjkOcS5SLLoCWu4DH88=; b=iLBbFlMuQLUfSG/MZmSTopmRNLEiW5HSrfrRyZOsVgHIIv9k7Gxhxkd2 R/wWbdL6WrlGPUvMEqkG/+XwQMwtawlFdvlNFEUhXdBFLcmdttalaUf+s C1cSi9wLvBAgKW8bUI7ST3gBkcIYpP6sKpT68Dyhpu5/CUnwyhtroJEwU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQAABIwoE6tJXHB/2dsb2JhbABDmViPPoEFgW4BAQEDARIBHQo4BwUHBAIBCBEEAQELBhcBBgFFCQgBAQQBEggah14IlzIBnjeHSGEEiAORMIxC X-IronPort-AV: E=Sophos;i="4.69,379,1315180800"; d="scan'208";a="29796921" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 20 Oct 2011 14:32:24 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9KEWOlc030604; Thu, 20 Oct 2011 14:32:24 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 09:32:23 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [v6ops] new draft: draft-asati-v6ops-dad-loopback Date: Thu, 20 Oct 2011 09:32:22 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD169@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] new draft: draft-asati-v6ops-dad-loopback Thread-Index: AcyPLs/lUaxLfScSSJWuXUql1TU4KQAAgIKwAACE9tAAAHmUYA== References: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD138@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "George, Wes" , "Washam Fan" X-OriginalArrivalTime: 20 Oct 2011 14:32:23.0954 (UTC) FILETIME=[15414720:01CC8F35] Cc: v6ops@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:32:25 -0000 WesG, Thanks for the update. Chairs of 6man, please expect us to present a merged document at the Taipei IETF. The asati and hsingh doc teams are working together to complete a single doc. We will try and publish the new merged copy in about a week. Regards, Hemant -----Original Message----- From: George, Wes [mailto:wesley.george@twcable.com]=20 Sent: Thursday, October 20, 2011 10:19 AM To: Hemant Singh (shemant); Washam Fan Cc: v6ops@ietf.org; ipv6@ietf.org Subject: RE: [v6ops] new draft: draft-asati-v6ops-dad-loopback > a completed > algorithm to detect looped back NS(DAD) messages in > > http://tools.ietf.org/html/draft-hsingh-6man-enhanced-dad-01 > [WEG]] It is also worth noting that the authors of draft-asati are working to incorporate some elements of that draft into the one that Hemant mentions above, and a single draft will proceed within 6man - draft-asati will most likely expire in silence :-) Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From rajiva@cisco.com Thu Oct 20 11:53:30 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1421F0C48; Thu, 20 Oct 2011 11:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwsTGc+2TNaF; Thu, 20 Oct 2011 11:53:29 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 68B6B1F0C44; Thu, 20 Oct 2011 11:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3566; q=dns/txt; s=iport; t=1319136809; x=1320346409; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=vvF5ColKPvXPHPnlzQynuNlnZVKRGN27wpJG4Heqj5M=; b=jhzS3CyDGm0t/EpGaJ1B5rl6vMl8GdncAPJ9F7dA4JoKNECvsPfnhAfa q43FP6pU+IlD9cIvfafRHqdhQqGr2y7V2wkL7VlzJEcv6ZFk88h32zHnK /NfewsyiJsW60U3/KEk7Djx8eu7rMX/4jwnKxeGvLh7DHDPox5RWVG1vk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQAAPVsoE6tJXHA/2dsb2JhbABBmVyPPoEFgW4BAQEDARIBHQo/BQcEAgEIEQQBAQEKBhcBBgFFCQgBAQQBEggah16XUQGeQYdIYQSIA5EwjEI X-IronPort-AV: E=Sophos;i="4.69,380,1315180800"; d="scan'208";a="29876101" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 20 Oct 2011 18:53:28 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9KIrSJ0017628; Thu, 20 Oct 2011 18:53:28 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 13:53:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [v6ops] new draft: draft-asati-v6ops-dad-loopback Date: Thu, 20 Oct 2011 13:53:27 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C063F415A@XMB-RCD-111.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] new draft: draft-asati-v6ops-dad-loopback Thread-Index: AcxmNKk5OsR2s8X4Toq0tm4Sfz7cwwh9e3mgAcsykNA= References: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> From: "Rajiv Asati (rajiva)" To: "Hemant Singh (shemant)" , "Lorenzo Colitti" , "Erik Kline" X-OriginalArrivalTime: 20 Oct 2011 18:53:28.0635 (UTC) FILETIME=[8E21E8B0:01CC8F59] X-Mailman-Approved-At: Thu, 20 Oct 2011 11:59:53 -0700 Cc: v6ops@ietf.org, draft-asati-v6ops-dad-loopback@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:53:30 -0000 Hi Lorenzo, Sorry about the delayed response (and thanks to Hemant for pointing this out). Pls see inline, > A couple of points that the draft doesn't explain: > =09 > - Why can't the node simply retry DAD without the nonce option? The node could simply do so, however, it wouldn't be able to differentiate between the looped message and spoofed message. Nonce usage significantly eliminates the possibility of a remote node sending the spoofed message, and causing the node to think that circuit being looped when it is not really. > - How does the nonce option guarantee that the address is unique? Just > probabilistically, because the nonce would have to collide? Nonce doesn't guarantee anything by itself, IMO. > - Why only send the nonce on the second (and subsequent?) messages? Why not > simply send out all NSes with nonces all the time? This is a good Q. The reason is that the Nonce usage requires the node to create and maintain the state for some time (t). It is useful when there is a loop, so the rationale was to first detect the _possibility_ of loop after the 1st receipt and confirm it with Nonce so as to keep IPv6 enabled. =20 Of course, the possibility of the remote node reflecting the same Nonce value in the spoofed message certainly exists, though it is remote. =20 The full-proof way to solve this is SeND, needless to say. > - What state is the address in while the timer is ticking? UP (or UP/Looped). > Also: in some cases this happens when buggy drivers (typically wifi drivers) > loop back the node's own multicast packets. This is a violation of 802.11, but > nobody notices since it doesn't affect IPv4. With your proposed scheme, DAD > would succeed, but the node would be continuously receiving its own multicast > packets. What happens in such situations? None of the proposals (including this one) stop the multicast packets from coming back. Simplest thing is to drop them, based on the Nonce value.=20 =09 Cheers, Rajiv > -----Original Message----- >=20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Lorenzo Colitti > Sent: Monday, August 29, 2011 6:15 AM > To: Erik Kline > Cc: v6ops@ietf.org; draft-asati-v6ops-dad-loopback@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback >=20 >=20 >=20 > On Mon, Aug 29, 2011 at 18:54, Erik Kline wrote: >=20 > +1 to section 3.2, generally. >=20 >=20 >=20 > This is definitely a useful problem to solve. I have personally had to work > around this situation more than once, sometimes by disabling DAD completely on > routers. >=20 >=20 >=20 > A couple of points that the draft doesn't explain: > =09 > - Why can't the node simply retry DAD without the nonce option? >=20 > - How does the nonce option guarantee that the address is unique? Just > probabilistically, because the nonce would have to collide? >=20 > - Why only send the nonce on the second (and subsequent?) messages? Why not > simply send out all NSes with nonces all the time? >=20 > - What state is the address in while the timer is ticking? >=20 >=20 >=20 > Also: in some cases this happens when buggy drivers (typically wifi drivers) > loop back the node's own multicast packets. This is a violation of 802.11, but > nobody notices since it doesn't affect IPv4. With your proposed scheme, DAD > would succeed, but the node would be continuously receiving its own multicast > packets. What happens in such situations? From washam.fan@gmail.com Thu Oct 20 20:07:13 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE1711E808F; Thu, 20 Oct 2011 20:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7xK4BhfrB+W; Thu, 20 Oct 2011 20:07:13 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2718411E807F; Thu, 20 Oct 2011 20:07:13 -0700 (PDT) Received: by yxj19 with SMTP id 19so4137154yxj.31 for ; Thu, 20 Oct 2011 20:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6Sf3Ql11e4xOVGBo/g4G8nrIw3oQPv8dPFCg9sNdxGo=; b=dk63sJEnHdgS4pepkx0EbMyfRk+oSbo8YN+GskpH3vO0uff2vE1B0tS1gIrNFjWNSf 6rf6pawRija/8SFJuOLDVl8uWNjAv2w8Omns1DfXocyjZ2jEyTzsFfbQ94uelOQoHj9u jwBAYDePT8Rb0UKpeKPkTGEgdH4UMUYfJ+5VM= MIME-Version: 1.0 Received: by 10.182.235.72 with SMTP id uk8mr701693obc.75.1319166432761; Thu, 20 Oct 2011 20:07:12 -0700 (PDT) Received: by 10.182.44.74 with HTTP; Thu, 20 Oct 2011 20:07:12 -0700 (PDT) In-Reply-To: <20111020140701.GO72014@Space.Net> References: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> <20111020140701.GO72014@Space.Net> Date: Fri, 21 Oct 2011 11:07:12 +0800 Message-ID: Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback From: Washam Fan To: Gert Doering Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, ipv6@ietf.org, draft-asati-v6ops-dad-loopback@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 03:07:13 -0000 Hi, 2011/10/20 Gert Doering : > Hi, > > On Thu, Oct 20, 2011 at 09:47:28PM +0800, Washam Fan wrote: >> Sorry for late response. >> >> Since NS(DAD) traverse the same link, couldn't we just use src MAC of >> the received NS(DAD) to identify if the NS is the one sent by the >> interface earlier? >> >> Am I missing something? > > Yes. =A0Not all the world is Ethernet. > > We've seen this problem mostly on SDH/Sonet links, which are either > HDLC or PPP encapsulated, and don't have MAC addresses in their frames. > Thanks Gert. Got your points. washam > Gert Doering > =A0 =A0 =A0 =A0-- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vorstand: Seba= stian v. Bomhard > Joseph-Dollinger-Bogen 14 =A0 =A0 =A0 =A0 =A0Aufsichtsratsvors.: A. Grund= ner-Culemann > D-80807 Muenchen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HRB: 136055 (AG Muen= chen) > Tel: +49 (89) 32356-444 =A0 =A0 =A0 =A0 =A0 =A0USt-IdNr.: DE813185279 > From washam.fan@gmail.com Thu Oct 20 20:11:18 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079EF21F852E; Thu, 20 Oct 2011 20:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpyrUyeFV1gp; Thu, 20 Oct 2011 20:11:17 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5AC21F846C; Thu, 20 Oct 2011 20:11:17 -0700 (PDT) Received: by gyh20 with SMTP id 20so4149911gyh.31 for ; Thu, 20 Oct 2011 20:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wTD9KChA8xP4VESafDdDPdObPjF9SCbQXnxbvog/vjM=; b=rovqEfl8Iw1Nxj874EKVAsvwp5sOIqb6eHhYtNBnoWY1bce0gOrR2KrqsFIMc1lnVv FQ/FhvNIyFz3/J/XCWkfttDvnGeGkUy9eVN2zlZkZpaR6O+W54KOWNRlz4bEO3asrGHo IbL/g9GeHMQu3VDexrXffeA0Do+wKA8PSqzLE= MIME-Version: 1.0 Received: by 10.182.115.38 with SMTP id jl6mr725409obb.35.1319166673756; Thu, 20 Oct 2011 20:11:13 -0700 (PDT) Received: by 10.182.44.74 with HTTP; Thu, 20 Oct 2011 20:11:13 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD138@XMB-RCD-109.cisco.com> References: <201108261355.p7QDt0r13136@ftpeng-update.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3030A3507@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3031FD138@XMB-RCD-109.cisco.com> Date: Fri, 21 Oct 2011 11:11:13 +0800 Message-ID: Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback From: Washam Fan To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, draft-asati-v6ops-dad-loopback@tools.ietf.org, ipv6@ietf.org, Lorenzo Colitti X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 03:11:18 -0000 Hi Hemant, 2011/10/20 Hemant Singh (shemant) : > Washam, > > -----Original Message----- > From: Washam Fan [mailto:washam.fan@gmail.com] > Sent: Thursday, October 20, 2011 9:47 AM > To: Hemant Singh (shemant) > Cc: Lorenzo Colitti; Erik Kline; v6ops@ietf.org; > draft-asati-v6ops-dad-loopback@tools.ietf.org; ipv6@ietf.org > Subject: Re: [v6ops] new draft: draft-asati-v6ops-dad-loopback > >>Since NS(DAD) traverse the same link, couldn't we just use src MAC of > the received NS(DAD) to identify if the NS is the one sent by the > interface earlier? > > No. =A0Two nodes could almost simultaneously issue a NS(DAD) and both the > nodes have the same mac-address and thus the situation is a DAD failure > and not a looped back NS(DAD). Good catch. Thanks. washam > I use the term of NS(DAD) to denote a NS > issue for the purpose of DAD where the NS has a unspecified source > address. =A0That is why a nonce is needed and specified in a completed > algorithm to detect looped back NS(DAD) messages in > > http://tools.ietf.org/html/draft-hsingh-6man-enhanced-dad-01 > > Hemant > From jmh@joelhalpern.com Fri Oct 21 07:44:28 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7379B21F8B54 for ; Fri, 21 Oct 2011 07:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o19aFgqM7t1n for ; Fri, 21 Oct 2011 07:44:28 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes-ipv6.tigertech.net [IPv6:2604:4f00::1:0:0:16]) by ietfa.amsl.com (Postfix) with ESMTP id 1219821F8B50 for ; Fri, 21 Oct 2011 07:44:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AF3A84300F7 for ; Fri, 21 Oct 2011 07:44:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 913774300A1 for ; Fri, 21 Oct 2011 07:44:27 -0700 (PDT) Message-ID: <4EA18547.1020301@joelhalpern.com> Date: Fri, 21 Oct 2011 10:44:23 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt References: <20111017211709.25002.16474.idtracker@ietfa.amsl.com> In-Reply-To: <20111017211709.25002.16474.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111017211709.25002.16474.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 14:44:28 -0000 I would like to call people's attention to the draft below. I would like to hear from folks as to what they think of this complement to some of the existing work on the ND based denial of service attack. I do not intend to present this at the WG meeting, as I would like a chance to hear from folks first. Yours, Joel -------- Original Message -------- Subject: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt Date: Mon, 17 Oct 2011 14:17:09 -0700 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mitigating Neighbor Discovery Based Denial of Service Attacks Author(s) : Joel M. Halpern Filename : draft-halpern-6man-nddos-mitigation-00.txt Pages : 6 Date : 2011-10-17 It has been observed that with the large space of IPv6 addresses within a subnet, remote attackers can send packets that saturate a rotuers ND cache, and potentially saturate a subnet with ND Soliciation messages as well. Some operational techniques and small protocol adjustments have been proposed that can help alleviate this problem. This draft proposes a slightly more drastic optional behavior for routers, which can nearly eliminate this problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigation-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigation-00.txt _______________________________________________ From bob.hinden@gmail.com Mon Oct 24 06:15:48 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE64A21F8797 for ; Mon, 24 Oct 2011 06:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.639 X-Spam-Level: X-Spam-Status: No, score=-101.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqXv3xacQrMj for ; Mon, 24 Oct 2011 06:15:48 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4021F84BA for ; Mon, 24 Oct 2011 06:15:48 -0700 (PDT) Received: by qyk34 with SMTP id 34so1855018qyk.10 for ; Mon, 24 Oct 2011 06:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=kLfvowrP1Lw4ptQfbP5FyI15N46C/ZmQIwUq1wW5nng=; b=fsw/1ooEambvC7Qgq1uYXdLkzCV3EL/tR6HCkZGQPrbybVKThK3v+wbb8LEjXv2ZTI w+bORcOvezKp3Mj2XCo1azYGQwS1Q4ObzMnA/NTKQxvkEQ4NhjCMyHkG02nZYS1T65T+ tpxiZhPqjOhWwu2RXi8eyHF9D64hNMXb88gb0= Received: by 10.182.109.1 with SMTP id ho1mr3253215obb.63.1319462146502; Mon, 24 Oct 2011 06:15:46 -0700 (PDT) Received: from [10.196.229.183] ([199.91.194.1]) by mx.google.com with ESMTPS id u5sm550563obd.2.2011.10.24.06.15.43 (version=SSLv3 cipher=OTHER); Mon, 24 Oct 2011 06:15:45 -0700 (PDT) Subject: Re: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4EA18547.1020301@joelhalpern.com> Date: Mon, 24 Oct 2011 13:15:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2DBC082F-77CE-4B37-8A14-FD8E5835CEBB@gmail.com> References: <20111017211709.25002.16474.idtracker@ietfa.amsl.com> <4EA18547.1020301@joelhalpern.com> To: Joel M. Halpern X-Mailer: Apple Mail (2.1084) Cc: "ipv6@ietf.org" , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 13:15:49 -0000 I think this is an interesting approach and encourage the w.g. to read = it and comment on the list. Bob On Oct 21, 2011, at 2:44 PM, Joel M. Halpern wrote: > I would like to call people's attention to the draft below. > I would like to hear from folks as to what they think of this = complement to some of the existing work on the ND based denial of = service attack. > I do not intend to present this at the WG meeting, as I would like a = chance to hear from folks first. >=20 > Yours, > Joel >=20 > -------- Original Message -------- > Subject: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt > Date: Mon, 17 Oct 2011 14:17:09 -0700 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Mitigating Neighbor Discovery Based Denial of = Service Attacks > Author(s) : Joel M. Halpern > Filename : draft-halpern-6man-nddos-mitigation-00.txt > Pages : 6 > Date : 2011-10-17 >=20 > It has been observed that with the large space of IPv6 addresses > within a subnet, remote attackers can send packets that saturate a > rotuers ND cache, and potentially saturate a subnet with ND > Soliciation messages as well. Some operational techniques and small > protocol adjustments have been proposed that can help alleviate this > problem. This draft proposes a slightly more drastic optional > behavior for routers, which can nearly eliminate this problem. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigation-00= .txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigation-00.= txt > _______________________________________________ >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From joelja@bogus.com Mon Oct 24 06:21:11 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F25421F85A8 for ; Mon, 24 Oct 2011 06:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHEbtAFQpcKI for ; Mon, 24 Oct 2011 06:21:11 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E225921F85AA for ; Mon, 24 Oct 2011 06:21:10 -0700 (PDT) Received: from Zorch.local (user-64-9-236-168.googlewifi.com [64.9.236.168]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p9ODL9qo096765 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 24 Oct 2011 13:21:10 GMT (envelope-from joelja@bogus.com) Message-ID: <4EA56645.3020400@bogus.com> Date: Mon, 24 Oct 2011 06:21:09 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt References: <20111017211709.25002.16474.idtracker@ietfa.amsl.com> <4EA18547.1020301@joelhalpern.com> In-Reply-To: <4EA18547.1020301@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 24 Oct 2011 13:21:10 +0000 (UTC) Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 13:21:11 -0000 On 10/21/11 07:44 , Joel M. Halpern wrote: > I would like to call people's attention to the draft below. > I would like to hear from folks as to what they think of this complement > to some of the existing work on the ND based denial of service attack. > I do not intend to present this at the WG meeting, as I would like a > chance to hear from folks first. > > Yours, > Joel > > -------- Original Message -------- > Subject: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt > Date: Mon, 17 Oct 2011 14:17:09 -0700 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Mitigating Neighbor Discovery Based Denial of > Service Attacks > Author(s) : Joel M. Halpern > Filename : draft-halpern-6man-nddos-mitigation-00.txt > Pages : 6 > Date : 2011-10-17 > > It has been observed that with the large space of IPv6 addresses > within a subnet, remote attackers can send packets that saturate a > rotuers ND cache, and potentially saturate a subnet with ND > Soliciation messages as well. Some operational techniques and small > protocol adjustments have been proposed that can help alleviate this > problem. This draft proposes a slightly more drastic optional > behavior for routers, which can nearly eliminate this problem. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigation-00.txt > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigation-00.txt > > _______________________________________________ > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From joelja@bogus.com Mon Oct 24 06:28:08 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54EB21F8C51 for ; Mon, 24 Oct 2011 06:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txKSraFkdZZM for ; Mon, 24 Oct 2011 06:28:08 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 33FD721F85F1 for ; Mon, 24 Oct 2011 06:28:08 -0700 (PDT) Received: from Zorch.local (user-64-9-236-168.googlewifi.com [64.9.236.168]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p9ODS62v096969 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 24 Oct 2011 13:28:07 GMT (envelope-from joelja@bogus.com) Message-ID: <4EA567E6.80701@bogus.com> Date: Mon, 24 Oct 2011 06:28:06 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt References: <20111017211709.25002.16474.idtracker@ietfa.amsl.com> <4EA18547.1020301@joelhalpern.com> <4EA56645.3020400@bogus.com> In-Reply-To: <4EA56645.3020400@bogus.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 24 Oct 2011 13:28:07 +0000 (UTC) Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 13:28:09 -0000 Sorry meant to actually reply. I'm curious, essentially what the implications are for interaction between an existing implimentation in a host, and an nd implimentation which no longer does discovery. On 10/24/11 06:21 , Joel jaeggli wrote: > On 10/21/11 07:44 , Joel M. Halpern wrote: >> I would like to call people's attention to the draft below. >> I would like to hear from folks as to what they think of this complement >> to some of the existing work on the ND based denial of service attack. >> I do not intend to present this at the WG meeting, as I would like a >> chance to hear from folks first. >> >> Yours, >> Joel >> >> -------- Original Message -------- >> Subject: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt >> Date: Mon, 17 Oct 2011 14:17:09 -0700 >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Mitigating Neighbor Discovery Based Denial of >> Service Attacks >> Author(s) : Joel M. Halpern >> Filename : draft-halpern-6man-nddos-mitigation-00.txt >> Pages : 6 >> Date : 2011-10-17 >> >> It has been observed that with the large space of IPv6 addresses >> within a subnet, remote attackers can send packets that saturate a >> rotuers ND cache, and potentially saturate a subnet with ND >> Soliciation messages as well. Some operational techniques and small >> protocol adjustments have been proposed that can help alleviate this >> problem. This draft proposes a slightly more drastic optional >> behavior for routers, which can nearly eliminate this problem. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigation-00.txt >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigation-00.txt >> >> _______________________________________________ >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From jmh@joelhalpern.com Mon Oct 24 06:34:24 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46F021F8D8B for ; Mon, 24 Oct 2011 06:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.879 X-Spam-Level: X-Spam-Status: No, score=-101.879 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOS8deCOISAM for ; Mon, 24 Oct 2011 06:34:24 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2397F21F8D8A for ; Mon, 24 Oct 2011 06:34:24 -0700 (PDT) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) by morbo.tigertech.net (Postfix) with ESMTP id AD70FCD069 for ; Mon, 24 Oct 2011 06:34:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 124A4361DDA; Mon, 24 Oct 2011 06:34:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-197.clppva.btas.verizon.net [71.161.52.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id 6418D361DD5; Mon, 24 Oct 2011 06:34:21 -0700 (PDT) Message-ID: <4EA5694E.50408@joelhalpern.com> Date: Mon, 24 Oct 2011 09:34:06 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Joel jaeggli Subject: Re: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt References: <20111017211709.25002.16474.idtracker@ietfa.amsl.com> <4EA18547.1020301@joelhalpern.com> <4EA56645.3020400@bogus.com> <4EA567E6.80701@bogus.com> In-Reply-To: <4EA567E6.80701@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 13:34:24 -0000 The purpose of the various exchange and triggering mechanism I describe in the last section are to enable the approach to be used before one has upgraded all the hosts on the subnet. With the RS retransmission to enable reliable discovery by the router, the rest probably become harmless but unimportant. Yours, Joel On 10/24/2011 9:28 AM, Joel jaeggli wrote: > Sorry meant to actually reply. > > I'm curious, essentially what the implications are for interaction > between an existing implimentation in a host, and an nd implimentation > which no longer does discovery. > > On 10/24/11 06:21 , Joel jaeggli wrote: >> On 10/21/11 07:44 , Joel M. Halpern wrote: >>> I would like to call people's attention to the draft below. >>> I would like to hear from folks as to what they think of this complement >>> to some of the existing work on the ND based denial of service attack. >>> I do not intend to present this at the WG meeting, as I would like a >>> chance to hear from folks first. >>> >>> Yours, >>> Joel >>> >>> -------- Original Message -------- >>> Subject: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt >>> Date: Mon, 17 Oct 2011 14:17:09 -0700 >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Mitigating Neighbor Discovery Based Denial of >>> Service Attacks >>> Author(s) : Joel M. Halpern >>> Filename : draft-halpern-6man-nddos-mitigation-00.txt >>> Pages : 6 >>> Date : 2011-10-17 >>> >>> It has been observed that with the large space of IPv6 addresses >>> within a subnet, remote attackers can send packets that saturate a >>> rotuers ND cache, and potentially saturate a subnet with ND >>> Soliciation messages as well. Some operational techniques and small >>> protocol adjustments have been proposed that can help alleviate this >>> problem. This draft proposes a slightly more drastic optional >>> behavior for routers, which can nearly eliminate this problem. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigation-00.txt >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigation-00.txt >>> >>> _______________________________________________ >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > From kerlyn2001@gmail.com Mon Oct 24 11:35:18 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F75B11E809D for ; Mon, 24 Oct 2011 11:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1pip-WniaVj for ; Mon, 24 Oct 2011 11:35:17 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43EAB11E808A for ; Mon, 24 Oct 2011 11:35:17 -0700 (PDT) Received: by eyg24 with SMTP id 24so6393622eyg.31 for ; Mon, 24 Oct 2011 11:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nTWv7SGTidavl8YGBa/ouxwSMVWtAztHjue3PHrrmrU=; b=YdmJ+RUgRPH44ZRfkMW74MhGFDXBntrxS0aak/EcUnHLP3faxNZ1n9LNaMNo3WLMFl mi09P2DQ8E2KkgyJG647TApyOSlzSH+UmhSnYKNexxlSZBEYQvi0itA0r1a0XnOfjl77 F18Q0xDdaaGOwyuQlBpQlfDCsD/JlmpM7LRyc= MIME-Version: 1.0 Received: by 10.14.7.145 with SMTP id 17mr2993392eep.158.1319481315244; Mon, 24 Oct 2011 11:35:15 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.14.96.13 with HTTP; Mon, 24 Oct 2011 11:35:15 -0700 (PDT) In-Reply-To: <4E94776D.5080908@innovationslab.net> References: <4E94776D.5080908@innovationslab.net> Date: Mon, 24 Oct 2011 14:35:15 -0400 X-Google-Sender-Auth: lAna0BIwp9iYVgd_GCmN6FQbgMU Message-ID: Subject: Re: Consensus call on adopting: draft-george-6man-3627-historic From: Kerry Lynn To: Brian Haberman Content-Type: multipart/alternative; boundary=00504502d417153bcf04b00faf19 Cc: IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 18:35:18 -0000 --00504502d417153bcf04b00faf19 Content-Type: text/plain; charset=ISO-8859-1 I support adoption of this draft as a 6MAN WG document. -K- On Tue, Oct 11, 2011 at 1:05 PM, Brian Haberman wrote: > All, > This is a consensus call on adopting: > > Title : RFC3627 to Historic status > Author(s) : Wesley George > Filename : draft-george-6man-3627-historic-01.txt > Pages : 4 > Date : 2011-10-10 > > as a 6MAN working group document. Please state your opinion, positive > or negative, on the mailing list or to the chairs. This consensus call > will end on October 25, 2011. > > Regards, > Brian & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --00504502d417153bcf04b00faf19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support adoption of this draft as a 6MAN WG document.

= -K-


On Tue, Oct 11, 2011 at 1:= 05 PM, Brian Haberman <brian@innovationslab.net> wrote:
All,
=A0 =A0 This is a consensus call on adopting:

=A0 =A0 Title =A0 =A0 : RFC3627 to Historic status
=A0 =A0 Author(s) : Wesley George
=A0 =A0 Filename =A0: draft-george-6man-3627-historic-01.txt
=A0 =A0 Pages =A0 =A0 : 4
=A0 =A0 Date =A0 =A0 =A0: 2011-10-10

as a 6MAN working group document. =A0Please state your opinion, positive or negative, on the mailing list or to the chairs. =A0This consensus call will end on October 25, 2011.

Regards,
Brian & Bob
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--00504502d417153bcf04b00faf19-- From huitema@microsoft.com Mon Oct 24 22:48:52 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA8411E810B for ; Mon, 24 Oct 2011 22:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZMhNNgsTHvk for ; Mon, 24 Oct 2011 22:48:51 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 856D211E80FE for ; Mon, 24 Oct 2011 22:48:51 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 24 Oct 2011 22:48:51 -0700 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.51]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0339.002; Mon, 24 Oct 2011 22:48:51 -0700 From: Christian Huitema To: "Joel M. Halpern" , Joel jaeggli Subject: RE: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt Thread-Topic: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt Thread-Index: AQHMj//7krWpbGv1w0+zkYtL2WAKa5WL9O6AgAAB8QCAAAGtAIAAmPsw Date: Tue, 25 Oct 2011 05:48:50 +0000 Message-ID: References: <20111017211709.25002.16474.idtracker@ietfa.amsl.com> <4EA18547.1020301@joelhalpern.com> <4EA56645.3020400@bogus.com> <4EA567E6.80701@bogus.com> <4EA5694E.50408@joelhalpern.com> In-Reply-To: <4EA5694E.50408@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 05:48:52 -0000 Joel, Your draft mentions that the router that just rebooted would send 0-sourced= solicitations to all the hosts that it knows about. What do you have in mi= nd, exactly? If the router rebooted, it does not know anything, right? Do y= ou mean to say, "each time it sees an incoming packet from a yet unknown lo= cal source, the router will send a solicitation?" Of course, there is a small issue with that. If there is a server on the lo= cal link, the server can remain silent for a long time, waiting for incomin= g connections. We probably need to allow an incoming TCP SYN to trigger an NS for the serv= er. Maybe with some rate control to protect against attacks. -- Christian Huitema -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Joe= l M. Halpern Sent: Monday, October 24, 2011 6:34 AM To: Joel jaeggli Cc: ipv6@ietf.org Subject: Re: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt The purpose of the various exchange and triggering mechanism I describe in = the last section are to enable the approach to be used before one has upgra= ded all the hosts on the subnet. With the RS retransmission to enable reli= able discovery by the router, the rest probably become harmless but unimpor= tant. Yours, Joel On 10/24/2011 9:28 AM, Joel jaeggli wrote: > Sorry meant to actually reply. > > I'm curious, essentially what the implications are for interaction=20 > between an existing implimentation in a host, and an nd implimentation=20 > which no longer does discovery. > > On 10/24/11 06:21 , Joel jaeggli wrote: >> On 10/21/11 07:44 , Joel M. Halpern wrote: >>> I would like to call people's attention to the draft below. >>> I would like to hear from folks as to what they think of this=20 >>> complement to some of the existing work on the ND based denial of servi= ce attack. >>> I do not intend to present this at the WG meeting, as I would like a=20 >>> chance to hear from folks first. >>> >>> Yours, >>> Joel >>> >>> -------- Original Message -------- >>> Subject: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt >>> Date: Mon, 17 Oct 2011 14:17:09 -0700 >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>> directories. >>> >>> Title : Mitigating Neighbor Discovery Based Denial of >>> Service Attacks >>> Author(s) : Joel M. Halpern >>> Filename : draft-halpern-6man-nddos-mitigation-00.txt >>> Pages : 6 >>> Date : 2011-10-17 >>> >>> It has been observed that with the large space of IPv6 addresses >>> within a subnet, remote attackers can send packets that saturate a >>> rotuers ND cache, and potentially saturate a subnet with ND >>> Soliciation messages as well. Some operational techniques and smal= l >>> protocol adjustments have been proposed that can help alleviate thi= s >>> problem. This draft proposes a slightly more drastic optional >>> behavior for routers, which can nearly eliminate this problem. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigat >>> ion-00.txt >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigati >>> on-00.txt >>> >>> _______________________________________________ >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative=20 >>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From arifumi@nttv6.net Tue Oct 25 04:27:43 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B083A21F8772 for ; Tue, 25 Oct 2011 04:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiBuATLF4m0k for ; Tue, 25 Oct 2011 04:27:43 -0700 (PDT) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id ED7BA21F8801 for ; Tue, 25 Oct 2011 04:27:42 -0700 (PDT) Received: from [127.0.0.1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id p9PBOn4h024226; Tue, 25 Oct 2011 20:24:49 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: Moving to WGLC 3484-bis? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: Date: Tue, 25 Oct 2011 20:24:58 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Philip Homburg X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter , 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 11:27:43 -0000 Hi, I'm catching up an old thread. On 2011/08/13, at 21:48, Philip Homburg wrote: > In your letter dated Sat, 13 Aug 2011 12:17:29 +0200 you wrote: >> I still think there's an issue with the suggested blanket global=20 >> treatment of IPv4 RFC1918 addresses. >>=20 >> Quote draft-ietf-6man-rfc3484-revise-04 "This issue can be fixed by = changing t >> he >> address scope of private IPv4 addresses to global." >>=20 >> IMVHO I think it is highly likely that over time this assumption will = not hold >> true: >> think end game when IPv6 native only networks are widely deployed and = CGN is t >> urned off. >> At that time there's still probably going to be many (local) NAT = boxes >> that advertise an IPv4 default route and serve RFC1918 DHCP addresses = to clien >> ts, >> but cannot provide global connectivity. >>=20 >> So whatever you assume about RFC1918 addresses has a good chance of = being inco >> rrect >> unless you can truly detect/confirm presence of global IPv4 = connectivity via N >> AT. >=20 > Ah, tricky. >=20 > For destination addresses we have 3 possibilities: v4-only, v6-only, = and > dual-stack. >=20 > Obviously, without global IPv4 connectivity, connecting to v4-only = destinations > is not going to work, no matter what you put in the policy table. = Connecting > to v6-only destinations doesn't involve v4, so that's not an issue = either. >=20 > For dual stack, connecting over v6 is preferred unless one v6 address = is=20 > 6to4 or teredo. Given that you are unlikely to have 6to4 or teredo in > that kind of environment, that's not going to be the local address. >=20 > So there is one remaining corner case. If the remote address is 6to4 = or > teredo, then the policy table will prefer IPv4. >=20 > I'm not sure it's worth making thing more complex just o handle this = corner > case. Philip, thank you for great considerations. I agree that the above corner case is the only situation where the broken IPv4 connectivity does some harm. I can imagine another case where IPv6 connection falling back to IPv4. However, when a connection falls back, it takes tens of seconds, so it is bad enough regardless of the existence of broken IPv4=20 connectivity. So, I think this is trivial. Ray, do you think 3484-bis should treat this issue of RFC1918 address scope ? From internet-drafts@ietf.org Tue Oct 25 05:10:34 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652A821F8AE9; Tue, 25 Oct 2011 05:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pobnceEo94C5; Tue, 25 Oct 2011 05:10:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA7721F8AAF; Tue, 25 Oct 2011 05:10:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-udpzero-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111025121025.23637.31604.idtracker@ietfa.amsl.com> Date: Tue, 25 Oct 2011 05:10:25 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 12:10:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : IPv6 UDP Checksum Considerations Author(s) : Godred Fairhurst Magnus Westerlund Filename : draft-ietf-6man-udpzero-04.txt Pages : 34 Date : 2011-10-25 This document examines the role of the UDP transport checksum when used with IPv6, as defined in RFC2460. It presents a summary of the trade-offs for evaluating the safety of updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value in the checksum field as an indication that no checksum is present. This method is compared with some other possibilities. The document also describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations. It concludes that UDP with a zero checksum in IPv6 can safely be used for this purpose, provided that this usage is governed by a set of constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-udpzero-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-udpzero-04.txt From v6ops@globis.net Tue Oct 25 05:58:09 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985FE21F8B34 for ; Tue, 25 Oct 2011 05:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4aN+F+5mazn for ; Tue, 25 Oct 2011 05:58:08 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id E912921F8B33 for ; Tue, 25 Oct 2011 05:58:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C44C2870098; Tue, 25 Oct 2011 14:58:06 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3AmzSiuehFP; Tue, 25 Oct 2011 14:58:01 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 4B69A87008A; Tue, 25 Oct 2011 14:58:01 +0200 (CEST) Message-ID: <4EA6B259.9010509@globis.net> Date: Tue, 25 Oct 2011 14:58:01 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Arifumi Matsumoto Subject: Re: Moving to WGLC 3484-bis? References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050700090401010606060301" Cc: 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 12:58:09 -0000 This is a multi-part message in MIME format. --------------050700090401010606060301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am learning that policy based selection is not easy, and I'm only responding to the 6man list because a reply was directly solicited. The answer for policy based selection to me is probably to go for further abstraction and have multiple classifiers and preference rules combined in a meta language that relates directly to the classifications and prioritization rules of 3484, rather than trying to stuff everything into one single table that is based on pattern-matching against address prefixes, and then hard coding preferences in a ruleset. e.g. a match rule of what constitutes a global address or not? What constitutes a deprecated address? What constitutes a public address or a temporary address? What constitutes native transport or not? What constitutes a preference? These match rules are not at all trivial, and not all characteristics and classifications used in RFC 3484 are suited to an approach based on pattern-matching source and destination address-prefixes alone e.g. protocol uses a tunnel rather than native transport, or protocol family provides global connectivity, are very difficult to express purely in terms of address prefixes. We can shoe-horn most current solutions in there today, but there are cracks and there's no guarantee at all that future transports or preference requirements will fit neatly into this scheme. What about the dollar cost of radio links whilst roaming internationally for example? These classifiers could then be combined in a meta language something akin to today's policy based routing and DSCP classification to generate the ordered list of connections to try. Downside is configuration flexibility leads to implementation complexity. But it might be less obscure in the long run when trying to predict results of table changes in advance. On the other hand, we might be wise simply to advise network managers not to override RFC3484 bis defaults. I readily admit that predicting RFC3484 behavior in advance does my head in sometimes. In a World of highly mobile devices with multiple interfaces, and bring your own devices, it's going to be tough to get the right policy on an end node that matches the network(s) it is currently connected to. Pretend you've already got RFC3484 bis AND communication of the RFC 3484 policy table via DHCPv6 in place. What happens when your smart phone is connected to 4G and Homenet? Whose RFC 3484 bis table do you believe? At least in a meta language based approach, you might be able to set a high preference for interfaces that cost less dollars (WiFi interfaces over 4g interfaces from your own provider over 4g interfaces from 3rd parties). All of which in turn might mean that the true answer for providing good connectivity to users might be to "try everything in parallel and see what works best for this particular app based on executing my local rules code" = Happy Eyeballs++ I don't think that I am expressing a concenus view, or giving you constructive edits to RFC 3484 bis, so I'll shut up now. Good luck and thanks for picking up this challenge. Arifumi Matsumoto wrote: > Hi, > > I'm catching up an old thread. > > On 2011/08/13, at 21:48, Philip Homburg wrote: > > >> In your letter dated Sat, 13 Aug 2011 12:17:29 +0200 you wrote: >> >>> I still think there's an issue with the suggested blanket global >>> treatment of IPv4 RFC1918 addresses. >>> >>> Quote draft-ietf-6man-rfc3484-revise-04 "This issue can be fixed by changing t >>> he >>> address scope of private IPv4 addresses to global." >>> >>> IMVHO I think it is highly likely that over time this assumption will not hold >>> true: >>> think end game when IPv6 native only networks are widely deployed and CGN is t >>> urned off. >>> At that time there's still probably going to be many (local) NAT boxes >>> that advertise an IPv4 default route and serve RFC1918 DHCP addresses to clien >>> ts, >>> but cannot provide global connectivity. >>> >>> So whatever you assume about RFC1918 addresses has a good chance of being inco >>> rrect >>> unless you can truly detect/confirm presence of global IPv4 connectivity via N >>> AT. >>> >> Ah, tricky. >> >> For destination addresses we have 3 possibilities: v4-only, v6-only, and >> dual-stack. >> >> Obviously, without global IPv4 connectivity, connecting to v4-only destinations >> is not going to work, no matter what you put in the policy table. Connecting >> to v6-only destinations doesn't involve v4, so that's not an issue either. >> >> For dual stack, connecting over v6 is preferred unless one v6 address is >> 6to4 or teredo. Given that you are unlikely to have 6to4 or teredo in >> that kind of environment, that's not going to be the local address. >> >> So there is one remaining corner case. If the remote address is 6to4 or >> teredo, then the policy table will prefer IPv4. >> >> I'm not sure it's worth making thing more complex just o handle this corner >> case. >> > > Philip, thank you for great considerations. > I agree that the above corner case is the only situation where > the broken IPv4 connectivity does some harm. > > I can imagine another case where IPv6 connection falling back to IPv4. > However, when a connection falls back, it takes tens of seconds, > so it is bad enough regardless of the existence of broken IPv4 > connectivity. So, I think this is trivial. > > Ray, do you think 3484-bis should treat this issue of RFC1918 address > scope ? > > --------------050700090401010606060301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am learning that policy based selection is not easy, and I'm only responding to the 6man list because a reply was directly solicited.

The answer for policy based selection to me is probably to go for further abstraction and have multiple classifiers and preference rules combined in a meta language that relates directly to the classifications and prioritization rules of 3484, rather than trying to stuff everything into one single table that is based on pattern-matching against address prefixes, and then hard coding preferences in a ruleset.

e.g. a match rule of what constitutes a global address or not? What constitutes a deprecated address? What constitutes a public address or a temporary address? What constitutes native transport or not? What constitutes a preference?

These match rules are not at all trivial, and not all characteristics and classifications used in RFC 3484 are suited to an approach based on pattern-matching source and destination address-prefixes alone e.g. protocol uses a tunnel rather than native transport, or protocol family provides global connectivity, are very difficult to express purely in terms of address prefixes. We can shoe-horn most current solutions in there today, but there are cracks and there's no guarantee at all that future transports or preference requirements will fit neatly into this scheme. What about the dollar cost of radio links whilst roaming internationally for example?
 
These classifiers could then be combined in a meta language something akin to today's policy based routing and DSCP classification to generate the ordered list of connections to try.

Downside is configuration flexibility leads to implementation complexity. But it might be less obscure in the long run when trying to predict results of table changes in advance.

On the other hand, we might be wise simply to advise network managers not to override RFC3484 bis defaults. I readily admit that predicting RFC3484 behavior in advance does my head in sometimes.

In a World of highly mobile devices with multiple interfaces, and bring your own devices, it's going to be tough to get the right policy on an end node that matches the network(s) it is currently connected to. Pretend you've already got RFC3484 bis AND communication of the RFC 3484 policy table via DHCPv6 in place. What happens when your smart phone is connected to 4G and Homenet? Whose RFC 3484 bis table do you believe? At least in a meta language based approach, you might be able to set a high preference for interfaces that cost less dollars (WiFi interfaces over 4g interfaces from your own provider over 4g interfaces from 3rd parties).

All of which in turn might mean that the true answer for providing good connectivity to users might be to "try everything in parallel and see what works best for this particular app based on executing my local rules code" = Happy Eyeballs++

I don't think that I am expressing a concenus view, or giving you constructive edits to RFC 3484 bis, so I'll shut up now.

Good luck and thanks for picking up this challenge.

Arifumi Matsumoto wrote: 
Hi,

I'm catching up an old thread.

On 2011/08/13, at 21:48, Philip Homburg wrote:

  
In your letter dated Sat, 13 Aug 2011 12:17:29 +0200 you wrote:
    
I still think there's an issue with the suggested blanket global 
treatment of IPv4 RFC1918 addresses.

Quote draft-ietf-6man-rfc3484-revise-04 "This issue can be fixed by changing t
he
address scope of private IPv4 addresses to global."

IMVHO I think it is highly likely that over time this assumption will not hold
true:
think end game when IPv6 native only networks are widely deployed and CGN is t
urned off.
At that time there's still probably going to be many (local) NAT boxes
that advertise an IPv4 default route and serve RFC1918 DHCP addresses to clien
ts,
but cannot provide global connectivity.

So whatever you assume about RFC1918 addresses has a good chance of being inco
rrect
unless you can truly detect/confirm presence of global IPv4 connectivity via N
AT.
      
Ah, tricky.

For destination addresses we have 3 possibilities: v4-only, v6-only, and
dual-stack.

Obviously, without global IPv4 connectivity, connecting to v4-only destinations
is not going to work, no matter what you put in the policy table. Connecting
to v6-only destinations doesn't involve v4, so that's not an issue either.

For dual stack, connecting over v6 is preferred unless one v6 address is 
6to4 or teredo. Given that you are unlikely to have 6to4 or teredo in
that kind of environment, that's not going to be the local address.

So there is one remaining corner case. If the remote address is 6to4 or
teredo, then the policy table will prefer IPv4.

I'm not sure it's worth making thing more complex just o handle this corner
case.
    

Philip, thank you for great considerations.
I agree that the above corner case is the only situation where
the broken IPv4 connectivity does some harm.

I can imagine another case where IPv6 connection falling back to IPv4.
However, when a connection falls back, it takes tens of seconds,
so it is bad enough regardless of the existence of broken IPv4 
connectivity. So, I think this is trivial.

Ray, do you think 3484-bis should treat this issue of RFC1918 address
scope ?

--------------050700090401010606060301-- From jmh@joelhalpern.com Tue Oct 25 07:32:46 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C150621F8B4A for ; Tue, 25 Oct 2011 07:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.986 X-Spam-Level: X-Spam-Status: No, score=-101.986 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcSHSmjVDlV8 for ; Tue, 25 Oct 2011 07:32:46 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 34E2821F8B3F for ; Tue, 25 Oct 2011 07:32:46 -0700 (PDT) Received: from maila1.tigertech.net (maila1.tigertech.net [208.80.4.151]) by morbo.tigertech.net (Postfix) with ESMTP id E479EA6435 for ; Tue, 25 Oct 2011 07:32:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila1.tigertech.net (Postfix) with ESMTP id 05A58361DC3; Tue, 25 Oct 2011 07:32:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila1.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-118.clppva.btas.verizon.net [71.161.52.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila1.tigertech.net (Postfix) with ESMTPSA id AFF2B361AB6; Tue, 25 Oct 2011 07:32:42 -0700 (PDT) Message-ID: <4EA6C888.6050008@joelhalpern.com> Date: Tue, 25 Oct 2011 10:32:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christian Huitema Subject: Re: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt References: <20111017211709.25002.16474.idtracker@ietfa.amsl.com> <4EA18547.1020301@joelhalpern.com> <4EA56645.3020400@bogus.com> <4EA567E6.80701@bogus.com> <4EA5694E.50408@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 14:32:46 -0000 Clarification first. The reboot case described is when there is more than one router on a subnet announcing a given prefix. In that case, when the new router comes up, the existing router will notice, and it will send the triggering messages. The new router does not have the data it needs to send the triggers. Yours, Joel On 10/25/2011 1:48 AM, Christian Huitema wrote: > Joel, > > Your draft mentions that the router that just rebooted would send 0-sourced solicitations to all the hosts that it knows about. What do you have in mind, exactly? If the router rebooted, it does not know anything, right? Do you mean to say, "each time it sees an incoming packet from a yet unknown local source, the router will send a solicitation?" > > Of course, there is a small issue with that. If there is a server on the local link, the server can remain silent for a long time, waiting for incoming connections. > > We probably need to allow an incoming TCP SYN to trigger an NS for the server. Maybe with some rate control to protect against attacks. > > -- Christian Huitema > > > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Monday, October 24, 2011 6:34 AM > To: Joel jaeggli > Cc: ipv6@ietf.org > Subject: Re: Fwd: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt > > The purpose of the various exchange and triggering mechanism I describe in the last section are to enable the approach to be used before one has upgraded all the hosts on the subnet. With the RS retransmission to enable reliable discovery by the router, the rest probably become harmless but unimportant. > > Yours, > Joel > > On 10/24/2011 9:28 AM, Joel jaeggli wrote: >> Sorry meant to actually reply. >> >> I'm curious, essentially what the implications are for interaction >> between an existing implimentation in a host, and an nd implimentation >> which no longer does discovery. >> >> On 10/24/11 06:21 , Joel jaeggli wrote: >>> On 10/21/11 07:44 , Joel M. Halpern wrote: >>>> I would like to call people's attention to the draft below. >>>> I would like to hear from folks as to what they think of this >>>> complement to some of the existing work on the ND based denial of service attack. >>>> I do not intend to present this at the WG meeting, as I would like a >>>> chance to hear from folks first. >>>> >>>> Yours, >>>> Joel >>>> >>>> -------- Original Message -------- >>>> Subject: I-D Action: draft-halpern-6man-nddos-mitigation-00.txt >>>> Date: Mon, 17 Oct 2011 14:17:09 -0700 >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> >>>> Title : Mitigating Neighbor Discovery Based Denial of >>>> Service Attacks >>>> Author(s) : Joel M. Halpern >>>> Filename : draft-halpern-6man-nddos-mitigation-00.txt >>>> Pages : 6 >>>> Date : 2011-10-17 >>>> >>>> It has been observed that with the large space of IPv6 addresses >>>> within a subnet, remote attackers can send packets that saturate a >>>> rotuers ND cache, and potentially saturate a subnet with ND >>>> Soliciation messages as well. Some operational techniques and small >>>> protocol adjustments have been proposed that can help alleviate this >>>> problem. This draft proposes a slightly more drastic optional >>>> behavior for routers, which can nearly eliminate this problem. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigat >>>> ion-00.txt >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-halpern-6man-nddos-mitigati >>>> on-00.txt >>>> >>>> _______________________________________________ >>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > From bob.hinden@gmail.com Wed Oct 26 02:34:47 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7796921F8B0C for ; Wed, 26 Oct 2011 02:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ned55VNbWTq for ; Wed, 26 Oct 2011 02:34:46 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC5B21F8AEE for ; Wed, 26 Oct 2011 02:34:46 -0700 (PDT) Received: by gyh20 with SMTP id 20so1631577gyh.31 for ; Wed, 26 Oct 2011 02:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=OEx9NYbE21pOb2GDqZofnaXazuhQ4VaxfebIl2W7440=; b=xj+FDCEbKDyV8ZW01Wv35lTV+i4Ryv2x1ZPmmGJWDpDi7S3uaNA9MeHKsIawunVCvq Q33UZcgzaDZg6RGXAsoI1wo0uALxg4Vao2u5O0tmjOdfwx9jW0DPyPXiDUodJ6CG1LDA UDl2kdxNWXH5j2A8rOx+jkEB00oGxLGaHmXWs= Received: by 10.68.72.33 with SMTP id a1mr6138347pbv.44.1319621685831; Wed, 26 Oct 2011 02:34:45 -0700 (PDT) Received: from [10.196.208.192] ([199.91.193.1]) by mx.google.com with ESMTPS id z3sm4350489pbu.7.2011.10.26.02.34.42 (version=SSLv3 cipher=OTHER); Wed, 26 Oct 2011 02:34:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) Subject: Fwd: Agenda requests for IETF 82 From: Bob Hinden Date: Wed, 26 Oct 2011 09:34:39 +0000 Content-Transfer-Encoding: 7bit Message-Id: <06F96C2B-1DB7-4146-9E38-1C6DDD46619E@gmail.com> References: <4E7B398E.3070205@innovationslab.net> To: "ipv6@ietf.org List" X-Mailer: Apple Mail (2.1084) Cc: Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 09:34:47 -0000 Any other requests? Bob & Brian Begin forwarded message: > From: Brian Haberman > Date: September 22, 2011 1:35:10 PM GMT > To: IPv6 WG Mailing List > Cc: 6man Chairs <6man-chairs@tools.ietf.org> > Subject: Agenda requests for IETF 82 > > All, > Scheduling and registration have opened for the 82nd IETF meeting. > The chairs are now accepting requests for agenda time during the 6MAN > WG slot. If you wish to present, please send the chairs: > > - Topic > - Presenter > - Time requested > - draft name > > As with previous meetings, we will give priority in the following order: > > 1. WG work items > 2. New topics actively being discussed on the mailing list > 3. New topics > > Please have these requests to the chairs NO LATER THAN 9:00pm UTC on > October 13, 2011. > > Regards, > Brian & Bob From brian@innovationslab.net Fri Oct 28 06:11:30 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF82221F8B84 for ; Fri, 28 Oct 2011 06:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2u8fJJrXLmW for ; Fri, 28 Oct 2011 06:11:30 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7D121F8B7F for ; Fri, 28 Oct 2011 06:11:30 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C5D0C8815D; Fri, 28 Oct 2011 06:11:29 -0700 (PDT) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 77FE5130006; Fri, 28 Oct 2011 06:11:28 -0700 (PDT) Message-ID: <4EAAA9FE.9030600@innovationslab.net> Date: Fri, 28 Oct 2011 09:11:26 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: Review requested: draft-ietf-mif-dhcpv6-route-option X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man-ads@tools.ietf.org, Bob Hinden , mif-chairs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 13:11:30 -0000 All, The MIF WG is currently defining a DHCPv6 option for defining routes (including default routes) on client nodes. Please review the draft and provide any feedback you have. http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 Regards, Brian From wbeebee@cisco.com Fri Oct 28 10:52:12 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F4521F8876 for ; Fri, 28 Oct 2011 10:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.633 X-Spam-Level: X-Spam-Status: No, score=-3.633 tagged_above=-999 required=5 tests=[AWL=0.899, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zevvPMkCabl0 for ; Fri, 28 Oct 2011 10:52:11 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AB4B221F84E1 for ; Fri, 28 Oct 2011 10:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=704; q=dns/txt; s=iport; t=1319824331; x=1321033931; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=teem4gs1/3doq3PPq0yKdB91we6bn8PcMSSuQIyrOFM=; b=hBdVYnJSJp0vA+9rZSgE0AOltB1uu09TkfK5nj9lJfll2fkPy2L/1ASU xY2BGyZKqdv8CcQQhvpQKa9T13CC1MjEvWrWQBXFIK3U0Jd/gDzZ0hgpw 7ei53MgMNEJ0HNn8/VOjrlU+lLVxkdOZ7qm3aLbuMAv/5W5qAFQYBmPBx A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosHADHrqk6tJXHB/2dsb2JhbABDqWMCgQWBcgEBAQECAQEBAQ8BJwIBMQsFDQEIbTABAQQBDQUih2AIlWIBnhSJAwSUDoU2iBuEKg X-IronPort-AV: E=Sophos;i="4.69,419,1315180800"; d="scan'208";a="31760945" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 28 Oct 2011 17:52:11 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9SHqBDi010429; Fri, 28 Oct 2011 17:52:11 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 12:52:10 -0500 Received: from 161.44.182.81 ([161.44.182.81]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Fri, 28 Oct 2011 17:52:10 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Fri, 28 Oct 2011 13:52:08 -0400 Subject: Re: Review requested: draft-ietf-mif-dhcpv6-route-option From: Wes Beebee To: Brian Haberman , IPv6 WG Mailing List Message-ID: Thread-Topic: Review requested: draft-ietf-mif-dhcpv6-route-option Thread-Index: AcyVmk+bd195XmQHlkOWpkVpD/E7nQ== In-Reply-To: <4EAAA9FE.9030600@innovationslab.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Oct 2011 17:52:10.0909 (UTC) FILETIME=[515774D0:01CC959A] Cc: 6man-ads@tools.ietf.org, Bob Hinden , mif-chairs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 17:52:12 -0000 What happens when both RA and DHCPv6 are configured? - Wes On 10/28/11 9:11 AM, "Brian Haberman" wrote: > All, > The MIF WG is currently defining a DHCPv6 option for defining > routes (including default routes) on client nodes. Please review the > draft and provide any feedback you have. > > http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 > > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From shemant@cisco.com Fri Oct 28 10:58:09 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E5721F8A35 for ; Fri, 28 Oct 2011 10:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.076 X-Spam-Level: X-Spam-Status: No, score=-6.076 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5hEg1uS2uAZ for ; Fri, 28 Oct 2011 10:58:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 603FE21F89BA for ; Fri, 28 Oct 2011 10:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1907; q=dns/txt; s=iport; t=1319824688; x=1321034288; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=eh8FP33bk+qBIkJDgQqo9QFJ4B0mWX8NhoQOD0D5ngU=; b=mNajCQ6gWxc5/KRLGLl/VFFR5Mkughp1aTZmAM4OmFMCNjg4zraoJ2jB 14egNvTLOny4G7u/sYLSx2GFSTECs21/BN3alMrS3v2scQKgwG18xybnV cH9iQS8WPjptDozbDSWWlebsk3CnIgpS3Da21GvPzfLk5gjvZSBC60cUp o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AALbsqk6tJXG+/2dsb2JhbABDmhOPUoEFgXIBAQEBAgEBAQEPAR0KNAsFBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHYAiVWwGeF4giYQSIBpE+jEc X-IronPort-AV: E=Sophos;i="4.69,419,1315180800"; d="scan'208";a="31773450" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 28 Oct 2011 17:58:08 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9SHw7I6015042; Fri, 28 Oct 2011 17:58:08 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 12:58:07 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Review requested: draft-ietf-mif-dhcpv6-route-option Date: Fri, 28 Oct 2011 12:58:06 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review requested: draft-ietf-mif-dhcpv6-route-option Thread-Index: AcyVmk+bd195XmQHlkOWpkVpD/E7nQAAGUOg References: <4EAAA9FE.9030600@innovationslab.net> From: "Hemant Singh (shemant)" To: "Wes Beebee (wbeebee)" , "Brian Haberman" , "IPv6 WG Mailing List" X-OriginalArrivalTime: 28 Oct 2011 17:58:07.0572 (UTC) FILETIME=[25EDE940:01CC959B] Cc: 6man-ads@tools.ietf.org, Bob Hinden , mif-chairs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 17:58:09 -0000 This is precisely the question that I and Bernie Volz asked a year or two back. Similarly when it was discussed to add a DNS option to the IPv6 ND RA when the DNS option was already supported by DHCPv6. The question was if the receiving node gets the same information from two different sources, which information wins? What if one information was fat-fingered at the SP provisioning system while the other was not? We should look at the RFC that added the DNS option to the RA and see if that RFC has a section regarding this question and we could copy that guidance. Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Wes Beebee (wbeebee) Sent: Friday, October 28, 2011 1:52 PM To: Brian Haberman; IPv6 WG Mailing List Cc: 6man-ads@tools.ietf.org; Bob Hinden; mif-chairs@tools.ietf.org Subject: Re: Review requested: draft-ietf-mif-dhcpv6-route-option What happens when both RA and DHCPv6 are configured? - Wes On 10/28/11 9:11 AM, "Brian Haberman" wrote: > All, > The MIF WG is currently defining a DHCPv6 option for defining > routes (including default routes) on client nodes. Please review the > draft and provide any feedback you have. >=20 > http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 >=20 > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From shemant@cisco.com Fri Oct 28 11:46:45 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EDE11E808C for ; Fri, 28 Oct 2011 11:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi14M9bTxqR9 for ; Fri, 28 Oct 2011 11:46:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4C811E8080 for ; Fri, 28 Oct 2011 11:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1773; q=dns/txt; s=iport; t=1319827604; x=1321037204; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zIIwLj2eIbL9ypLYMjdM1kcP5ybsaFqiIckB9SusfLA=; b=SjEZSg/bOPWN1cEhSLRsUjIuAvtAk7K2b6P57tj4Z6S/ngEPaTvwGeu+ laPzFssPzUk/0zs/01xaNDahK352tONu4U2W/O9rUwcgXT9Gx5emSvba2 37uwnNNvL6717l+J2Caz7T0gzdEXC/+59sNw2f+Kmi/wZra+B4s2WwTlY s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AAHD4qk6tJV2d/2dsb2JhbABDmhSPUoEFgXIBAQEBAgEBAQEPAR0KNAsFBwQCAQgRAwEBAQsGFwEGASYfCQgBAQQBEggah2AIlWoBnhMEiCJhBIgGkT6MRw X-IronPort-AV: E=Sophos;i="4.69,419,1315180800"; d="scan'208";a="31785517" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 28 Oct 2011 18:46:40 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9SIkdNZ003508; Fri, 28 Oct 2011 18:46:39 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Oct 2011 13:46:39 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Agenda requests for IETF 82 Date: Fri, 28 Oct 2011 13:46:38 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3032A7229@XMB-RCD-109.cisco.com> In-Reply-To: <06F96C2B-1DB7-4146-9E38-1C6DDD46619E@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda requests for IETF 82 Thread-Index: AcyTwoV2G5sI5ouwQVunOSC+3J+mnwB3sCxg References: <4E7B398E.3070205@innovationslab.net> <06F96C2B-1DB7-4146-9E38-1C6DDD46619E@gmail.com> From: "Hemant Singh (shemant)" To: "Bob Hinden" , X-OriginalArrivalTime: 28 Oct 2011 18:46:39.0482 (UTC) FILETIME=[ED901DA0:01CC95A1] Cc: Brian Haberman X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 18:46:45 -0000 Bob and Brian, Please give us a slot for Taipei to present the following document. Topic: Enhanced DAD (solving the reflected DAD and some other DAD related problems) Presenter: Hemant/Rajiv/Wes George Time requested: 5-10 minutes Draft name: draft-hsingh-6man-enhanced-dad-02 to 6man. Thanks, Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden Sent: Wednesday, October 26, 2011 5:35 AM To: ipv6@ietf.org List Cc: Brian Haberman; Bob Hinden Subject: Fwd: Agenda requests for IETF 82 Any other requests? Bob & Brian Begin forwarded message: > From: Brian Haberman > Date: September 22, 2011 1:35:10 PM GMT > To: IPv6 WG Mailing List > Cc: 6man Chairs <6man-chairs@tools.ietf.org> > Subject: Agenda requests for IETF 82 >=20 > All, > Scheduling and registration have opened for the 82nd IETF meeting. > The chairs are now accepting requests for agenda time during the 6MAN > WG slot. If you wish to present, please send the chairs: >=20 > - Topic > - Presenter > - Time requested > - draft name >=20 > As with previous meetings, we will give priority in the following order: >=20 > 1. WG work items > 2. New topics actively being discussed on the mailing list > 3. New topics >=20 > Please have these requests to the chairs NO LATER THAN 9:00pm UTC on > October 13, 2011. >=20 > Regards, > Brian & Bob -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From jari.arkko@piuha.net Sat Oct 29 10:48:07 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601CB21F854D for ; Sat, 29 Oct 2011 10:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq7qz5QWkAuS for ; Sat, 29 Oct 2011 10:48:06 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7A77621F84D3 for ; Sat, 29 Oct 2011 10:48:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C9C7A2CC44; Sat, 29 Oct 2011 20:48:05 +0300 (EEST) 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 vmn-SRPlpnrP; Sat, 29 Oct 2011 20:48:05 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 216BE2CC34; Sat, 29 Oct 2011 20:48:05 +0300 (EEST) Message-ID: <4EAC3C54.7000000@piuha.net> Date: Sat, 29 Oct 2011 20:48:04 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sri Gundavelli , Suresh Krishnan Subject: Re: Last Call: (Reserved IPv6 Interface Identifier for Proxy Mobile IPv6) to Informational RFC References: <20110729121436.14048.14658.idtracker@ietfa.amsl.com> <4E76DF0F.6020307@piuha.net> <4E76E29E.2000407@piuha.net> <4E7A607C.8000508@ericsson.com> <4E7BB45C.6000508@ericsson.com> <201109231221.p8NCLQug028871@cichlid.raleigh.ibm.com> <201109261357.p8QDvCKd006148@cichlid.raleigh.ibm.com> <4E9DC592.6030208@piuha.net> In-Reply-To: <4E9DC592.6030208@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPv6 Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 17:48:07 -0000 We did not get an exactly overwhelming number of responses, but it seems that those that cared (me and Margaret) seemed to prefer an EUI-64 approach. Sri, can you make that happen? Feel free to ask me or Suresh to help, if needed. Make a clear enough explanation in the document so that we can get IANA to understand also what they need to do in detail. I'm currently holding a Discuss on their behalf, because the current instructions were unclear. Can you make this happen by drafts deadline? Jari On 18.10.2011 21:29, Jari Arkko wrote: > The last call ended yesterday. We are fine with going ahead as proposed standard, but there were two other issues raised during discussion. > > 1. Possible draft to update RFC 5453 / 5342 to say that allocations in either one should not conflict with each other. I tend to agree with Thomas that we are unlikely to see much use of these registries and we should not worry too much about it. That being said, if Suresh finds enough time to write a draft on this I wouldn't mind shepherding it forward. In any case, it is a separate matter from Sri's draft. > > 2. Whether to allocate an EUI-64 from the IANA block and base the IID on that, or to allocate just a reserved value per RFC 5453. Collisions are extremely unlikely in either case. Personally, I'd prefer an EUI-64 based approach though, because collisions based on random addresses are then ruled out completely, and only manual or multiple MAG type collisions may occur. That is a personal preference though. But we need to choose. Are we going with the draft as is, or changing it to use EUI-64 allocation? I saw Suresh support this approach, Sri had questions (were those answered and what was your conclusion?), what about the rest of you? > > In any case, I'm sending the draft to the IESG review. > > Jari > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From alexandru.petrescu@gmail.com Sun Oct 30 09:33:34 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D08321F8A80 for ; Sun, 30 Oct 2011 09:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=-1.714, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOtz0TTNE9U8 for ; Sun, 30 Oct 2011 09:33:34 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 559B821F8A62 for ; Sun, 30 Oct 2011 09:33:29 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id D482894022A; Sun, 30 Oct 2011 17:33:19 +0100 (CET) Message-ID: <4EAD7C4E.1070406@gmail.com> Date: Sun, 30 Oct 2011 17:33:18 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Hemant Singh (shemant)" Subject: Re: Review requested: draft-ietf-mif-dhcpv6-route-option References: <4EAAA9FE.9030600@innovationslab.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3032A71C3@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 111030-0, 30/10/2011), Outbound message X-Antivirus-Status: Clean Cc: 6man-ads@tools.ietf.org, IPv6 WG Mailing List , Bob Hinden , Brian Haberman , mif-chairs@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 16:33:34 -0000 Le 28/10/2011 19:58, Hemant Singh (shemant) a écrit : > This is precisely the question that I and Bernie Volz asked a year or > two back. Similarly when it was discussed to add a DNS option to the > IPv6 ND RA when the DNS option was already supported by DHCPv6. The > question was if the receiving node gets the same information from two > different sources, which information wins? What if one information was > fat-fingered at the SP provisioning system while the other was not? We > should look at the RFC that added the DNS option to the RA and see if > that RFC has a section regarding this question and we could copy that > guidance. The DNS-in-RA case is RFC6106 "IPv6 RA DNS Options" right? That has a section saying: -both RA and DHCP could coexist and give the DNS and, -in case both are present then a list of DNS-related should be maintained and -that DNS obtained from DHCP takes precedence over that from RA. If I read it correctly. Then, in the case of DHCP route-option draft, in a similar manner, one would say that routes obtained from DHCP should be less priority when such routes were available from RA (the default route) or from routing protocols (e.g. OSPF). One particular aspect I am concerned about is the lifetime in the case of default routes. There seems to me RA offers a particular lifetime to the default route, whereas the DHCP route-option proposed mechanism in the route-option draft keeps lifetime differently (length, optionality, values). In this sense it seems logical that modifications to the route-option draft may be necessary for a clearer coexistence with existing protocols which offer routes and default routes. Alex PS: disclose: I am co-authoring an alternate draft for default route list option (drlo) with DHCP which does things differently than the DHCP route-option MIF WG item. > > Hemant > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Wes Beebee (wbeebee) > Sent: Friday, October 28, 2011 1:52 PM > To: Brian Haberman; IPv6 WG Mailing List > Cc: 6man-ads@tools.ietf.org; Bob Hinden; mif-chairs@tools.ietf.org > Subject: Re: Review requested: draft-ietf-mif-dhcpv6-route-option > > What happens when both RA and DHCPv6 are configured? > > - Wes > > On 10/28/11 9:11 AM, "Brian Haberman" wrote: > >> All, >> The MIF WG is currently defining a DHCPv6 option for defining >> routes (including default routes) on client nodes. Please review the >> draft and provide any feedback you have. >> >> http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03 >> >> Regards, >> Brian >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From internet-drafts@ietf.org Mon Oct 31 13:11:42 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A896D11E8201; Mon, 31 Oct 2011 13:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8D8cWJbY2-z; Mon, 31 Oct 2011 13:11:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEE311E81CC; Mon, 31 Oct 2011 13:11:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-lineid-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031201141.6012.77131.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 13:11:41 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:11:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : The Line Identification Destination Option Author(s) : Suresh Krishnan Alan Kavanagh Balazs Varga Sven Ooghe Erik Nordmark Filename : draft-ietf-6man-lineid-02.txt Pages : 14 Date : 2011-10-31 In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the Edge Router. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-lineid-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-lineid-02.txt From internet-drafts@ietf.org Mon Oct 31 13:27:18 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925D311E822C; Mon, 31 Oct 2011 13:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9AlBduGDXcK; Mon, 31 Oct 2011 13:27:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3066411E8225; Mon, 31 Oct 2011 13:27:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-exthdr-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031202718.23771.31876.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 13:27:18 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 20:27:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : An uniform format for IPv6 extension headers Author(s) : Suresh Krishnan Apple Inc. Erik Kline James Hoagland Manav Bhatia Filename : draft-ietf-6man-exthdr-05.txt Pages : 8 Date : 2011-10-31 In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternative extension mechanisms in IPv6. It also provides a format for defining new IPv6 extension headers that would allow implementations to process past unknown extension headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-exthdr-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-exthdr-05.txt From internet-drafts@ietf.org Mon Oct 31 16:52:08 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811161F0DAA; Mon, 31 Oct 2011 16:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygAtfmCrH5jF; Mon, 31 Oct 2011 16:52:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF6A1F0DA9; Mon, 31 Oct 2011 16:52:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-rfc3484-revise-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031235203.11203.64958.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 16:52:03 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:52:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Update to RFC 3484 Default Address Selection for IPv6 Author(s) : Arifumi Matsumoto Jun-ya Kato Tomohiro Fujisaki Tim Chown Filename : draft-ietf-6man-rfc3484-revise-05.txt Pages : 12 Date : 2011-10-31 RFC 3484 describes algorithms for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. This document specifies a set of updates that modify the algorithms and fix the known defects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rfc3484-revise-05.txt From internet-drafts@ietf.org Mon Oct 31 16:52:23 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 434E411E83FC; Mon, 31 Oct 2011 16:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dr-Dp9BNhJVC; Mon, 31 Oct 2011 16:52:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A339C11E83FE; Mon, 31 Oct 2011 16:52:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-addr-select-considerations-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031235222.10701.42050.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 16:52:22 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:52:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : Considerations for IPv6 Address Selection Policy Changes Author(s) : Tim Chown Arifumi Matsumoto Filename : draft-ietf-6man-addr-select-considerations-04.txt Pages : 19 Date : 2011-10-31 Where the source and/or destination node of an IPv6 communication is multi-addressed, a mechanism is required for the initiating node to select the most appropriate address pair for the communication. RFC 3484 (IPv6 Default Address Selection) [RFC3484] defines such a mechanism for nodes to perform source and destination address selection. While RFC3484 recognised the need for implementations to be able to change the policy table, it did not define how this could be achieved. Requirements have now emerged for administrators to be able to configure and potentially dynamically change RFC 3484 policy from a central control point, and for (nomadic) hosts to be able to obtain the policy for the network that they are currently attached to without manual user intervention. This text discusses considerations for such policy changes, including examples of cases where a change of policy is required, and the likely frequency of such policy changes. This text also includes some discussion on the need to also update RFC 3484, where default policies are currently defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-considerati= ons-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-addr-select-consideratio= ns-04.txt From internet-drafts@ietf.org Mon Oct 31 16:53:50 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5276011E83FE; Mon, 31 Oct 2011 16:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry-F6niU-36U; Mon, 31 Oct 2011 16:53:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57101F0DA9; Mon, 31 Oct 2011 16:53:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-udpchecksums-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031235349.12109.81306.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 16:53:49 -0700 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:53:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : UDP Checksums for Tunneled Packets Author(s) : Marshall Eubanks P.F. Chimento Filename : draft-ietf-6man-udpchecksums-01.txt Pages : 12 Date : 2011-10-31 This document provides an update of RFC 2460[RFC2460] in order to improve the performance of IPv6 in an increasingly important use case, the use of tunneling to carry new transport protocols. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for suitable tunneling protocol where header information is protected on the "inner" packet being carried. This relaxa= tion removes the overhead associated with the computation of UDP checksums on tunneled IPv6 packets and thereby improves the efficiency of the traversal of firewalls and other network middleware by such new protocols. We describe how the IPv6 UDP checksum requirement can be relaxed in the situation where the encapsulated packet itself contains a checksum, the limitations and risks of this approach, and provides restrictions on the use of this relaxation to mitigate these risks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-udpchecksums-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-udpchecksums-01.txt From nordmark@acm.org Mon Oct 31 18:37:27 2011 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448351F0CC6 for ; Mon, 31 Oct 2011 18:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Oci3w9sIzK2 for ; Mon, 31 Oct 2011 18:37:25 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD1C11E809B for ; Mon, 31 Oct 2011 18:37:04 -0700 (PDT) Received: from [10.0.1.13] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id pA11ass6004745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Oct 2011 18:36:55 -0700 Message-ID: <4EAF4D38.5040905@acm.org> Date: Mon, 31 Oct 2011 18:36:56 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ray Hunter Subject: Re: FW: New Version Notification for, draft-hsingh-6man-enhanced-dad-01.txt References: <4E9C58A5.80001@globis.net> In-Reply-To: <4E9C58A5.80001@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPv6 WG Mailing List , Philip Homburg , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 01:37:27 -0000 On 10/17/11 9:32 AM, Ray Hunter wrote: > Would therefore humbly suggest a minimum/ default / recommendation of an > 8 octet nonce option (minus the existing 16 pre-assigned bits) meaning > 48 bits available for the nonce field, with the option of using longer > 16 or 24 octet nonce options if an implementer feels there is higher > likelihood of encountering more than 2^24 nodes on the link (giving > respectively 16*8-16 = 112 bit nonce & 24*8-16 = 176 bit nonce) > > You may think this is far fetched for an upper bound on the number of > nodes on a single link, but you never know what will happen in the > future, and standards writers been caught out often enough in the past > when making statements like "16/24/32/56 bits will be enough." By > definition a longer (e.g. 16) octet nonce option is never going to > collide with a node using a shorter (e.g. 8) octet nonce option in the > case of DAD, so not everyone has to use the same nonce length IMHO. My understanding is that we only need to worry about the case with two hosts which have duplicate IPv6 addresses *and* send DAD probes in the same 1 second window, thus the probability might be a lot lower. I guess if there was a building-wide power failure and everything PC powers back on at the same time, then many could send DAD probes in the same one second window. But even in that case they wouldn't all do it in the same one second interval. And with more and more laptops and other battery powered devices, the large-scale coordinated power-on seems an unlikely case. Thus I think 48 bits of nonce is plenty; 2^24 nodes doing DAD probes in the same one second interval means you have other problems (such as packet loss). Regards, Erik