From bob.hinden@gmail.com Tue Sep 4 10:28:24 2012 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 D5C2321F866C for ; Tue, 4 Sep 2012 10:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUgbeFTpRxzT for ; Tue, 4 Sep 2012 10:28:24 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 671FF21F866A for ; Tue, 4 Sep 2012 10:28:24 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so9486414pbb.31 for ; Tue, 04 Sep 2012 10:28:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=39UxRAa/ScEtMR89MAZ0vQ+TSivhzznoBu2xqeJU0Vg=; b=okkrv1ARZEfmnz9c9hWZ+45SWK4GhpcBkJ/xQ8h/3M4FiH+IjORIaTyGoHA/SL5rpM nLhHrobyF4wm5CQWYjLd8kQNvM9A9/ggQcRYawIYIuItoSjlmOGerNzdLBeOHkWzrSoW YHttL4ZgvffhADN7a+mI/xXlqBbKwu2wieyh1VNq9HH6Wg/A/9JKvelCkQE6N/UrPZ00 hV7iuOQyjj1qssIVN9ha5M0wICdRmZE11Z74PKs9FaPsdojKkhZChoeIFjHDCMf4vP83 /LbaL2E1pGZjjswF17BpF9GECgCuWmfgzNBHsKme9RM28TSU6fyTj78otkoFWClh7ayS biBQ== Received: by 10.68.201.198 with SMTP id kc6mr47066867pbc.122.1346779704210; Tue, 04 Sep 2012 10:28:24 -0700 (PDT) Received: from [172.16.224.219] ([209.97.127.34]) by mx.google.com with ESMTPS id y11sm12596627pbv.66.2012.09.04.10.28.22 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 10:28:23 -0700 (PDT) From: Bob Hinden Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 6MAN WG Last Call: Date: Tue, 4 Sep 2012 10:28:24 -0700 Message-Id: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.com> To: "ipv6@ietf.org Mailing List" Mime-Version: 1.0 (Apple Message framework v1280) X-Mailer: Apple Mail (2.1280) Cc: 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: Tue, 04 Sep 2012 17:28:25 -0000 All, This message starts a two week 6MAN Working Group on advancing: Title : Neighbor Unreachability Detection is too = impatient Author(s) : Erik Nordmark Igor Gashinsky Filename : draft-ietf-6man-impatient-nud-02.txt Pages : 8 Date : 2012-07-31 http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02 as Proposed Standard. Substantive comments and statements of support = for advancing this document should be directed to the mailing list. = Editorial suggestions can be sent to the authors. This last call will = end on September 18, 2012. Regards, Ole Troan & Bob Hinden From internet-drafts@ietf.org Wed Sep 5 04:06:16 2012 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 055A321F86CE; Wed, 5 Sep 2012 04:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.272 X-Spam-Level: X-Spam-Status: No, score=-102.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLQY84qMJPxY; Wed, 5 Sep 2012 04:06:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DC821F869D; Wed, 5 Sep 2012 04:06:15 -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-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120905110615.4056.47221.idtracker@ietfa.amsl.com> Date: Wed, 05 Sep 2012 04:06: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, 05 Sep 2012 11:06:16 -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 IET= F. Title : UDP Checksums for Tunneled Packets Author(s) : Marshall Eubanks P.F. Chimento Magnus Westerlund Filename : draft-ietf-6man-udpchecksums-04.txt Pages : 12 Date : 2012-09-05 Abstract: This document provides an update of the Internet Protocol version 6 (IPv6) specification (RFC2460) to improve the performance of IPv6 in the use case when a tunnel protocol uses UDP with IPv6 to tunnel packets. 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 relaxation removes the overhead associated with the computation of UDP checksums on IPv6 packets used to carry tunnel protocols and thereby improves the efficiency of the traversal of firewalls and other network middleboxes by such 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 defines restrictions on the use of this relaxation to mitigate these risks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-udpchecksums-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Wed Sep 5 04:09:14 2012 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 0130021F8499 for ; Wed, 5 Sep 2012 04:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNU0omxzd-+L for ; Wed, 5 Sep 2012 04:09:13 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E858421F84D9 for ; Wed, 5 Sep 2012 04:09:12 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-df-504732d7cf18 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D9.A7.11467.7D237405; Wed, 5 Sep 2012 13:09:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Wed, 5 Sep 2012 13:09:11 +0200 Message-ID: <504732D7.2030308@ericsson.com> Date: Wed, 5 Sep 2012 13:09:11 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Re: I-D Action: draft-ietf-6man-udpchecksums-04.txt References: <20120905110615.4056.47221.idtracker@ietfa.amsl.com> In-Reply-To: <20120905110615.4056.47221.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3Vve6kXuAwabbFhYvz75ncmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxue9v9gKXotV3Nq6ir2BsUGoi5GTQ0LARGL5mTPsELaYxIV7 69m6GLk4hAROMUq8+DmRCcJZxijx+MI9VpAqXgFtib0b9jB3MXJwsAioSLS+jQQJswlYSNz8 0cgGYosKBEqsPvuRCaJcUOLkzCcsILaIgLLEjO5zYDXCAjYSGw9NBFssJOAgsff1c0YQm1PA UeL2t/1sEAdJSryZfBOsl1lAT2LK1RZGCFteonnrbGaIXm2JhqYO1gmMgrOQrJuFpGUWkpYF jMyrGIVzEzNz0ssN9VKLMpOLi/Pz9IpTNzECw/Lglt+6OxhPnRM5xCjNwaIkzsuVtN9fSCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+P0/9uK5vFLSMhenMjIKm5x6fPu1Zt/7+6t32qbcOC+ 1ezlnnvaVir/SYlc+uheC18cn/X0Pa0ONxyti7YdcRRZGRIzNf22NqtS/xmnS1subzNUqFHe +t4i76uZ3s2VT/tPne+SD9i5/iznPL4Z+n3LTkZ1Zyy+kLHYf4aq8gz+bINvF9z2bLihxFKc kWioxVxUnAgAeOG3wRkCAAA= 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, 05 Sep 2012 11:09:14 -0000 WG, This is a very minor update to resolve some nits the WG chairs noticed while preparing the publication request. Cheers Magnus On 2012-09-05 13:06, internet-drafts@ietf.org wrote: > > 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. > > Title : UDP Checksums for Tunneled Packets > Author(s) : Marshall Eubanks > P.F. Chimento > Magnus Westerlund > Filename : draft-ietf-6man-udpchecksums-04.txt > Pages : 12 > Date : 2012-09-05 > > Abstract: > This document provides an update of the Internet Protocol version 6 > (IPv6) specification (RFC2460) to improve the performance of IPv6 in > the use case when a tunnel protocol uses UDP with IPv6 to tunnel > packets. 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 relaxation removes the overhead associated with the computation > of UDP checksums on IPv6 packets used to carry tunnel protocols and > thereby improves the efficiency of the traversal of firewalls and > other network middleboxes by such 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 defines restrictions on the use of > this relaxation to mitigate these risks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-udpchecksums-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From bob.hinden@gmail.com Wed Sep 5 23:13:47 2012 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 724DD21F8526 for ; Wed, 5 Sep 2012 23:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhEzJSd+VKOl for ; Wed, 5 Sep 2012 23:13:47 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9EA021F8523 for ; Wed, 5 Sep 2012 23:13:46 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so811339wgb.13 for ; Wed, 05 Sep 2012 23:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HjBx3+3Cv3PM7DEgKfnBZ9clyo1FQJpzcPIxYqBh520=; b=BBCHknbVOeF2IVPV5bGQiksa3GEr9ule7o+uVnFoGoDvo+FVaEGEH8iH4bUv1k8bmC vv4QWipprwfSh5IFoAt3C7Vco5s6wvuTf0VHlttq3SEQZAqvfOM4tDNMk977KhybRYlE 87X42ABgM6KhT+eAUd2cHU/03F1REaY7fz36BJAI6aEJaRe4Cu/vH3HaoAgv7HCKx627 8jqzVHpGpzvzishUnWkzamSiO9KSAffRlxk/SSb2wSXL4K2qHXo1OZtOLEFNwPuaCd+e vTWu0fmVK9DHSTWZuuCW497/YcDLaPJ4fzYu+DhYGKZFSzvIf1noa0ZHZMmzPuciP/ir HTKw== Received: by 10.180.109.166 with SMTP id ht6mr2429521wib.11.1346912025750; Wed, 05 Sep 2012 23:13:45 -0700 (PDT) Received: from ?IPv6:2601:9:4080:10:d0c1:10e:9281:db8b? ([2601:9:4080:10:d0c1:10e:9281:db8b]) by mx.google.com with ESMTPS id t8sm2553202wiy.3.2012.09.05.23.13.40 (version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 23:13:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1280) Subject: Fwd: Help the NomCom: Nominations and Feedback From: Bob Hinden Date: Wed, 5 Sep 2012 23:13:38 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> To: "ipv6@ietf.org Mailing List" X-Mailer: Apple Mail (2.1280) Cc: 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: Thu, 06 Sep 2012 06:13:47 -0000 FYI Begin forwarded message: > From: NomCom Chair > Subject: Help the NomCom: Nominations and Feedback > Date: September 5, 2012 5:21:29 PM PDT > To: Working Group Chairs > > The IETF Nominations Committee (NomCom) is currently seeking > nominations for individuals to serve on the IESG, IAB, and IAOC. > Additionally, this is an announcement that the NomCom is seeking > feedback on individuals who have accepted nominations for IETF > leadership positions. > > It is very important to the NomCom process that we get input from a > broad spectrum of the community. Therefore, in case members of your > working group do not read the IETF announcement and discussion lists, > the NomCom would appreciate your help in disseminating the following > information. > > The NomCom website contains information about this year's NomCom > including the positions we are seeking to fill, and the qualifications > required for these positions: > > https://www.ietf.org/group/nomcom/2012/ > > The NomCom is accepting nominations until September 24. Nominations > for any position can be made using the following web tool: > > https://www.ietf.org/group/nomcom/2012/nominate > > Feedback about individuals who the NomCom is considering can be > providing using the following web tool: > > https://www.ietf.org/group/nomcom/2012/input > > The feedback tool provides a list of individuals who have agreed to be > considered for each position. We will be updating this list in the coming > weeks as more individuals accept nominations. > > Feedback provided to the NomCom is kept strictly confidential! > > Note that use of the NomCom web tools require an ietf.org (i.e., > datatracker) account. You can create an ietf.org account by visiting the > following URL: > > https://datatracker.ietf.org/accounts/create/ > > As an alternative to using the web tools, you can send email to the > NomCom at nomcom12@ietf.org to make a nomination or provide input to > the committee. > > Thank you for your help, > - Matt Lepinski > nomcom-chair@ietf.org From internet-drafts@ietf.org Thu Sep 6 08:19:07 2012 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 8046E21F8672; Thu, 6 Sep 2012 08:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNGabZSMA+Gi; Thu, 6 Sep 2012 08:19:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDEC21F8624; Thu, 6 Sep 2012 08:19:07 -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-enhanced-dad-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120906151907.3730.11108.idtracker@ietfa.amsl.com> Date: Thu, 06 Sep 2012 08:19:07 -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: Thu, 06 Sep 2012 15:19:07 -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 IET= F. Title : Enhanced Duplicate Address Detection Author(s) : Rajiv Asati Hemant Singh Wes Beebee Eli Dart Wes George Carlos Pignataro Filename : draft-ietf-6man-enhanced-dad-01.txt Pages : 11 Date : 2012-09-06 Abstract: Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) 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 includes mitigation techniques and then outlines the Enhanced DAD algorithm to automate detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks the document automates resolving a specific duplicate address conflict. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-dad There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-enhanced-dad-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Thu Sep 6 09:52:30 2012 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 1F6B321F8528; Thu, 6 Sep 2012 09:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JVqPXjj19yz; Thu, 6 Sep 2012 09:52:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4239E21F8534; Thu, 6 Sep 2012 09:52: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: Protocol Action: 'The Line Identification Destination Option' to Proposed Standard (draft-ietf-6man-lineid-08.txt) X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120906165229.2159.13690.idtracker@ietfa.amsl.com> Date: Thu, 06 Sep 2012 09:52:29 -0700 Cc: 6man chair <6man-chairs@tools.ietf.org>, 6man mailing list , RFC Editor 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, 06 Sep 2012 16:52:30 -0000 The IESG has approved the following document: - 'The Line Identification Destination Option' (draft-ietf-6man-lineid-08.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Brian Haberman and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-6man-lineid/ Technical Summary In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document defines 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. Working Group Summary It was difficult reaching a consensus on this document, hence the two w.g. last calls. This approach was requested by the Broad Band Forum. The issues were resolved by some changes in the document and an explicit statement on its applicability in a limited deployment environment. Document Quality This document has been reviewed by many people and the chairs believe there is agreement in the w.g. to move it forward. Significant reviews have been done by Wojciech Dec and Ran Atkinson. Personnel Bob Hinden is the Document Shepherd. Brian Haberman is the Responsible Area Director. From joelja@bogus.com Thu Sep 6 19:12:22 2012 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 8FE5421F841D for ; Thu, 6 Sep 2012 19:12:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI4AXM3GDysy for ; Thu, 6 Sep 2012 19:12:22 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0F84921F841B for ; Thu, 6 Sep 2012 19:12:22 -0700 (PDT) Received: from joels-MacBook-Air.local (50-0-150-57.dsl.static.sonic.net [50.0.150.57]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q872CJGr037172 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 7 Sep 2012 02:12:20 GMT (envelope-from joelja@bogus.com) Message-ID: <50495803.9000306@bogus.com> Date: Thu, 06 Sep 2012 19:12:19 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120821 Thunderbird/15.0 MIME-Version: 1.0 To: Bob Hinden Subject: Re: 6MAN WG Last Call: References: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.com> In-Reply-To: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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]); Fri, 07 Sep 2012 02:12:20 +0000 (UTC) Cc: "ipv6@ietf.org 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, 07 Sep 2012 02:12:22 -0000 I think this is an important change, and I think our work on the problem side of the things underscores that. As a contributor I am in favor of advancing this document. That said I'd also like to hear from implementers that this is a reasonable fix with few if any negative consequences (something I believe to be the case). joel On 9/4/12 10:28 AM, Bob Hinden wrote: > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Neighbor Unreachability Detection is too impatient > Author(s) : Erik Nordmark > Igor Gashinsky > Filename : draft-ietf-6man-impatient-nud-02.txt > Pages : 8 > Date : 2012-07-31 > > http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02 > > as Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on September 18, 2012. > > Regards, > Ole Troan & Bob Hinden > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From randy@psg.com Fri Sep 7 03:26:29 2012 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 93F7021F87C9 for ; Fri, 7 Sep 2012 03:26:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnYyOgVBkToT for ; Fri, 7 Sep 2012 03:26:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 432C121F87C8 for ; Fri, 7 Sep 2012 03:26:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T9vlc-000LpG-0T; Fri, 07 Sep 2012 10:26:28 +0000 Date: Fri, 07 Sep 2012 19:27:32 +0900 Message-ID: From: Randy Bush To: Bob Hinden Subject: Re: 6MAN WG Last Call: In-Reply-To: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.com> References: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "ipv6@ietf.org 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, 07 Sep 2012 10:26:29 -0000 have read. support. randy From v6ops@globis.net Sat Sep 8 04:18:46 2012 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 CC44121F8691 for ; Sat, 8 Sep 2012 04:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XkPsVfrsJDG for ; Sat, 8 Sep 2012 04:18:46 -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 CC30621F867C for ; Sat, 8 Sep 2012 04:18:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B2E608700B1; Sat, 8 Sep 2012 13:18:29 +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 HeVnlmIbLOyj; Sat, 8 Sep 2012 13:18:00 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 221E8870071; Sat, 8 Sep 2012 13:18:00 +0200 (CEST) Message-ID: <504B2961.5060605@globis.net> Date: Sat, 08 Sep 2012 13:17:53 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: draft-ietf-6man-enhanced-dad@tools.ietf.org Subject: I-D Action: draft-ietf-6man-enhanced-dad-01.txt Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 08 Sep 2012 11:18:46 -0000 I have read this draft, and think this work is important. Some dumb questions for your consideration: Since the (tentative) IID and DAD operation is address and interface specific; as well as the nonce, should the node also remember on which interface the NS(DAD) was sent, and also for which (tentative) address? Should the node generate a separate nonce per instance of the DAD algorithm, or per interface initialisation? [DAD may be performed multiple times for initialising a single interface, and these may run in parallel if there are multiple prefixes per interface, or if temporary addresses are in use as well as SLAAC and DHCPv6...] Section 4.3 says "an interface on the node" What should a receiver do if a node receives its own NS(DAD) on another interface other than the source interface which is performing DAD? [use case: two L3 interfaces on one node connected to one common L2 link, where one interface re-initialises or wants to use a new temporary address and thus performs DAD. That isn't a loopback condition or error condition at all if that NS(DAD) packet is received on the other interface.] I think the text in section 4.3 could do with some clarification on sending and receiving interfaces. There are high availability situations that intentionally cause collisions of IID and a virtual IPv6 address [e.g. HSRP IPv6]. Do these need to be explicitly excluded from this draft? Or is that someone else's problem? [There is a table on the relevant manufacturers website labelled Table 19 "HSRP and IPv6 ND Addresses " which shows when the virtual MAC/ Virtual IPv6 is used for messages. AFAIK DAD is never performed on the virtual address, as prevention of duplicate addresses is handled in the HSRP protocol itself] There are high availability cases where multiple NICs are connected in parallel [Teaming]. Does this require any special treatment? Or simply a clarification that DAD is performed on the resulting virtual NIC interface or LACP bundle rather, than individual physical links? Or is this plain obvious? When is it safe for a node to garbage collect the stored nonce? When should a node garbage collect the stored nonce [e.g. to cover equipment moves and interface re-patching]? Once DAD completes? Regards, RayH > 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. > > Title : Enhanced Duplicate Address Detection > Author(s) : Rajiv Asati > Hemant Singh > Wes Beebee > Eli Dart > Wes George > Carlos Pignataro > Filename : draft-ietf-6man-enhanced-dad-01.txt > Pages : 11 > Date :2012-09-06 > > Abstract: > Appendix A of the IPv6 Duplicate Address Detection (DAD) document in > RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 > does not settle on one specific automated means to detect loopback of > Neighbor Discovery (ND of RFC 4861) 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 > includes mitigation techniques and then outlines the Enhanced DAD > algorithm to automate detection of looped back IPv6 ND messages used > by DAD. For network loopback tests, the Enhanced DAD algorithm > allows IPv6 to self-heal after a loopback is placed and removed. > Further, for certain access networks the document automates resolving > a specific duplicate address conflict. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-enhanced-dad > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-enhanced-dad-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From shemant@cisco.com Sat Sep 8 14:44:40 2012 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 416C121F84DA for ; Sat, 8 Sep 2012 14:44:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkMCE6BWn+EK for ; Sat, 8 Sep 2012 14:44:39 -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 9055721F84D9 for ; Sat, 8 Sep 2012 14:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1681; q=dns/txt; s=iport; t=1347140679; x=1348350279; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gBL3TV7JURabbouI13m6tOhJAxtyLgpRKdVRBTvBWVo=; b=ac2ux72XbwCJPVkfhb1mary6q8/nw8Iq86NCkHuk5kAO8c3y5CbLahRs HjmVRFTaUF/8Lee31KTLVWXsUI7LnTcd4g/lLrgFmDM5wlo93JVneyOgL x+WhQqZficDPflyZyYXeQ4H/7JN8c11Uz54jfN+PDZgWKSWxU4lsxxmJl A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABi7S1CtJXG//2dsb2JhbABFu1OBB4IgAQEBBBIBJzQLDAQCAQgOAwQBAQsUCQcyFAkIAgQBDQUIGodumwSfHIsThVZgA6QTgWeCZoFj X-IronPort-AV: E=Sophos;i="4.80,392,1344211200"; d="scan'208";a="116662624" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 08 Sep 2012 21:44:39 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q88LidFk009087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Sep 2012 21:44:39 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Sat, 8 Sep 2012 16:44:38 -0500 From: "Hemant Singh (shemant)" To: Ray Hunter , "draft-ietf-6man-enhanced-dad@tools.ietf.org" Subject: RE: I-D Action: draft-ietf-6man-enhanced-dad-01.txt Thread-Topic: I-D Action: draft-ietf-6man-enhanced-dad-01.txt Thread-Index: AQHNjbO8RVNJOyJbNUmsXyxWVlLVe5eA8RvQ Date: Sat, 8 Sep 2012 21:44:37 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89083623@xmb-rcd-x06.cisco.com> References: <504B2961.5060605@globis.net> In-Reply-To: <504B2961.5060605@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.246.129] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19172.001 x-tm-as-result: No--29.712300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Sat, 08 Sep 2012 21:44:40 -0000 Ray, Appreciate the review. I will send another email to reply to your question= s related to use cases. Other questions have been addressed below. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ray= Hunter Sent: Saturday, September 08, 2012 7:18 AM To: draft-ietf-6man-enhanced-dad@tools.ietf.org Cc: 6man Mailing List Subject: I-D Action: draft-ietf-6man-enhanced-dad-01.txt >Since the (tentative) IID and DAD operation is address and interface=20 >specific; as well as the nonce, should the node also remember on which=20 >interface the NS(DAD) was sent, and also for which (tentative) address? Yes. Note RFC 4862 is interface-specific for DAD of each IPv6 address used= by the interface and RFC 4861 is also interface-specific for the ND protoc= ol.=20 >Should the node generate a separate nonce per instance of the DAD=20 >algorithm, or per interface initialisation? Anytime DAD is performed by a network interface for an IPv6 address, a sepa= rate nonce is generated. The reason is because, by definition, a nonce is = used only once and the interface has to perform DAD for each IPv6 address u= sed by the interface. Our document is using the nonce defined by RFC 3971.= See section 2 of RFC 3971 and the definition of the "Nonce" term on page = 5. Other sections in RFC 3971 has additional details on the Nonce Option. >When is it safe for a node to garbage collect the stored nonce? >When should a node garbage collect the stored nonce [e.g. to cover=20 >equipment moves and interface re-patching]? >Once DAD completes? Once DAD completes. Regards, Hemant From shemant@cisco.com Sun Sep 9 05:33:23 2012 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 9F24F21F84D1 for ; Sun, 9 Sep 2012 05:33:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twb1ZQRf34qC for ; Sun, 9 Sep 2012 05:33:22 -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 D2D7F21F849D for ; Sun, 9 Sep 2012 05:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2783; q=dns/txt; s=iport; t=1347194003; x=1348403603; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eomMbH4vbgiBnXNVKV0ToZPc+ihb+WaSUnjya6ueyCY=; b=OkL1stLewoB19/ZeYYHxU6fAEbwnYnUTCSOLpM2sLF2DYvzBrjHQKIiy q+lMBT5vF9pFnLU04Ea0fhUBL3UxDIJpRNTLmWhkL9RFUfqQiXZFtsPbg elV80xLhgJ2uFrC6Zp8W8KCyeuQ4OIyWjf/qOE1QlJ0+EumKm7Nk3JUPk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALGLTFCtJV2b/2dsb2JhbABFu1OBB4IgAQEBBBIBJzQLDAQCAQgOAwQBAQsUCQcyFAkIAgQBDQUIGodumnqeeIsThVZgA6QTgWeCZoFaIw X-IronPort-AV: E=Sophos;i="4.80,394,1344211200"; d="scan'208";a="119732643" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 09 Sep 2012 12:33:21 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q89CXKc6030812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Sep 2012 12:33:20 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Sun, 9 Sep 2012 07:33:20 -0500 From: "Hemant Singh (shemant)" To: Ray Hunter , "draft-ietf-6man-enhanced-dad@tools.ietf.org" Subject: RE: I-D Action: draft-ietf-6man-enhanced-dad-01.txt Thread-Topic: I-D Action: draft-ietf-6man-enhanced-dad-01.txt Thread-Index: AQHNjbO8RVNJOyJbNUmsXyxWVlLVe5eBF0ew Date: Sun, 9 Sep 2012 12:33:19 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8908381D@xmb-rcd-x06.cisco.com> References: <504B2961.5060605@globis.net> In-Reply-To: <504B2961.5060605@globis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.250.33] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19172.005 x-tm-as-result: No--36.188800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Sun, 09 Sep 2012 12:33:23 -0000 Ray, Please see responses below for the use cases you raised. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ray= Hunter Sent: Saturday, September 08, 2012 7:18 AM To: draft-ietf-6man-enhanced-dad@tools.ietf.org Cc: 6man Mailing List Subject: I-D Action: draft-ietf-6man-enhanced-dad-01.txt >What should a receiver do if a node receives its own NS(DAD) on another=20 >interface other than the source interface which is performing DAD? >[use case: two L3 interfaces on one node connected to one common L2=20 >link, where one interface re-initialises or wants to use a new temporary=20 >address and thus performs DAD. That isn't a loopback condition or error=20 >condition at all if that NS(DAD) packet is received on the other interface= .] >I think the text in section 4.3 could do with some clarification on=20 >sending and receiving interfaces. For your use case, the issue won't happen during DAD for the global IPv6 ad= dress assigned to a L3 interface. A node won't be able to configure two se= parate interfaces with the same IPv6 global address. The two L3 interfaces = have different IPv6 global address(es) and for global address(es) each L3 i= nterface is a separate link-local domain. It's only for the link-local add= ress that the two L3 interfaces may share one link-local domain. Say, the = two L3 interfaces are int1 and int2. Then if int1 issues a NS(DAD) for the= link-local address, and an identical NS(DAD) is received on int2 the imple= mentation has to deal with DAD duplicates for all interfaces in the same li= nk-local domain. >There are high availability situations that intentionally cause=20 >collisions of IID and a virtual IPv6 address [e.g. HSRP IPv6]. >Do these need to be explicitly excluded from this draft? Or is that=20 >someone else's problem? >[There is a table on the relevant manufacturers website labelled Table=20 >19 "HSRP and IPv6 ND Addresses " which shows when the virtual MAC/=20 >Virtual IPv6 is used for messages. AFAIK DAD is never performed on the=20 >virtual address, as prevention of duplicate addresses is handled in the=20 >HSRP protocol itself] > >There are high availability cases where multiple NICs are connected in=20 >parallel [Teaming]. >Does this require any special treatment? Or simply a clarification that=20 >DAD is performed on the resulting virtual NIC interface or LACP bundle=20 >rather, than individual physical links? Or is this plain obvious? I think it's obvious. The manufacturer has also included documentation hig= hlighting which IPv6 set of addresses are skipped for DAD. Note, there are= other networks where DAD is disabled such as a point-to-point links. Regards, Hemant From v6ops@globis.net Sun Sep 9 11:32:10 2012 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 D263E21F8549 for ; Sun, 9 Sep 2012 11:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30m53gVOBVU2 for ; Sun, 9 Sep 2012 11:32:10 -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 BA6ED21F84FC for ; Sun, 9 Sep 2012 11:32:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2D5DD870069; Sun, 9 Sep 2012 20:31:53 +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 g3JoPLUwmFO4; Sun, 9 Sep 2012 20:31:24 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id ECFF7870056; Sun, 9 Sep 2012 20:31:23 +0200 (CEST) Message-ID: <504CE075.5070105@globis.net> Date: Sun, 09 Sep 2012 20:31:17 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: "Hemant Singh (shemant)" Subject: Re: I-D Action: draft-ietf-6man-enhanced-dad-01.txt References: <504B2961.5060605@globis.net> <75B6FA9F576969419E42BECB86CB1B8908381D@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8908381D@xmb-rcd-x06.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-6man-enhanced-dad@tools.ietf.org" , 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: Sun, 09 Sep 2012 18:32:10 -0000 Humbly suggest you read Section 4.3 one more time to double check that the text reflects what you mean. I never claimed the two interfaces would have the same address. Say Interface 2 is a stable interface. Interface 1 generates a new temporary address and performs DAD on it. The node remembers Interface 1's address is tentative, and the nonce that was sent. So one interpretation of the current text for me is that if Interface 2 receives a NS(DAD) for interface1's address (which is in tentative or optimistic state) then the node should generate a system management message. All I'm saying is that IMVHO it isn't entirely clear from the current text whether the filtering action is performed at node level, or locally per interface, or per (tentative) address. IMHO the filtering action should only be applied if all 3 of the following constraints match: 1) the received nonce in the NS(DAD) message matches a saved nonce, and 2) the interface that received the NS(DAD) message is the same interface which was used to send this nonce (and associated NS(DAD) message), and 3) the (tentative) address in the received NS(DAD) message matches the (tentative) address associated with this receiving interface. Then you have a loopback. And I think the text could be improved to make that clear. Equally if a nonce is truly a nonce, then can't the nonce also be garbage collected immediately from local storage as soon as the first NS(DAD) loopback packet is received i.e. when the received NS(DAD) message is dropped? Is there really a need to always wait for DAD to complete in that case? regards, RayH > Hemant Singh (shemant) > 9 September 2012 14:33 > Ray, > > Please see responses below for the use cases you raised. > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ray Hunter > Sent: Saturday, September 08, 2012 7:18 AM > To: draft-ietf-6man-enhanced-dad@tools.ietf.org > Cc: 6man Mailing List > Subject: I-D Action: draft-ietf-6man-enhanced-dad-01.txt > > >> What should a receiver do if a node receives its own NS(DAD) on another >> interface other than the source interface which is performing DAD? >> [use case: two L3 interfaces on one node connected to one common L2 >> link, where one interface re-initialises or wants to use a new temporary >> address and thus performs DAD. That isn't a loopback condition or error >> condition at all if that NS(DAD) packet is received on the other interface.] > >> I think the text in section 4.3 could do with some clarification on >> sending and receiving interfaces. > > For your use case, the issue won't happen during DAD for the global IPv6 address assigned to a L3 interface. A node won't be able to configure two separate interfaces with the same IPv6 global address. The two L3 interfaces have different IPv6 global address(es) and for global address(es) each L3 interface is a separate link-local domain. It's only for the link-local address that the two L3 interfaces may share one link-local domain. Say, the two L3 interfaces are int1 and int2. Then if int1 issues a NS(DAD) for the link-local address, and an identical NS(DAD) is received on int2 the implementation has to deal with DAD duplicates for all interfaces in the same link-local domain. > >> There are high availability situations that intentionally cause >> collisions of IID and a virtual IPv6 address [e.g. HSRP IPv6]. >> Do these need to be explicitly excluded from this draft? Or is that >> someone else's problem? >> [There is a table on the relevant manufacturers website labelled Table >> 19 "HSRP and IPv6 ND Addresses " which shows when the virtual MAC/ >> Virtual IPv6 is used for messages. AFAIK DAD is never performed on the >> virtual address, as prevention of duplicate addresses is handled in the >> HSRP protocol itself] >> >> There are high availability cases where multiple NICs are connected in >> parallel [Teaming]. >> Does this require any special treatment? Or simply a clarification that >> DAD is performed on the resulting virtual NIC interface or LACP bundle >> rather, than individual physical links? Or is this plain obvious? > > I think it's obvious. The manufacturer has also included documentation highlighting which IPv6 set of addresses are skipped for DAD. Note, there are other networks where DAD is disabled such as a point-to-point links. > > Regards, > > Hemant > Ray Hunter > 8 September 2012 13:17 > I have read this draft, and think this work is important. > > Some dumb questions for your consideration: > > Since the (tentative) IID and DAD operation is address and interface > specific; as well as the nonce, should the node also remember on which > interface the NS(DAD) was sent, and also for which (tentative) address? > > Should the node generate a separate nonce per instance of the DAD > algorithm, or per interface initialisation? > [DAD may be performed multiple times for initialising a single > interface, and these may run in parallel if there are multiple > prefixes per interface, or if temporary addresses are in use as well > as SLAAC and DHCPv6...] > > Section 4.3 says "an interface on the node" > > What should a receiver do if a node receives its own NS(DAD) on > another interface other than the source interface which is performing > DAD? > [use case: two L3 interfaces on one node connected to one common L2 > link, where one interface re-initialises or wants to use a new > temporary address and thus performs DAD. That isn't a loopback > condition or error condition at all if that NS(DAD) packet is received > on the other interface.] > > I think the text in section 4.3 could do with some clarification on > sending and receiving interfaces. > > There are high availability situations that intentionally cause > collisions of IID and a virtual IPv6 address [e.g. HSRP IPv6]. > Do these need to be explicitly excluded from this draft? Or is that > someone else's problem? > [There is a table on the relevant manufacturers website labelled Table > 19 "HSRP and IPv6 ND Addresses " which shows when the virtual MAC/ > Virtual IPv6 is used for messages. AFAIK DAD is never performed on the > virtual address, as prevention of duplicate addresses is handled in > the HSRP protocol itself] > > There are high availability cases where multiple NICs are connected in > parallel [Teaming]. > Does this require any special treatment? Or simply a clarification > that DAD is performed on the resulting virtual NIC interface or LACP > bundle rather, than individual physical links? Or is this plain obvious? > > When is it safe for a node to garbage collect the stored nonce? > When should a node garbage collect the stored nonce [e.g. to cover > equipment moves and interface re-patching]? > Once DAD completes? > > Regards, > RayH > > ------------------------------------------------------------------------ From shemant@cisco.com Sun Sep 9 14:43:52 2012 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 2D78A21F85A3 for ; Sun, 9 Sep 2012 14:43:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhzclnUD+-4C for ; Sun, 9 Sep 2012 14:43:50 -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 30E7821F846B for ; Sun, 9 Sep 2012 14:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2877; q=dns/txt; s=iport; t=1347227030; x=1348436630; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rUfy9+choOU/+4bjPbh6fizF9VLqmPTOGB6P2RnpyYo=; b=ZyLF2ieRTZkurxWpKM8TMKkWYsSNclC/uB3AiUZmM1PEfkF5Hj3p3Bqi qtdkF8cqy2yhXRJHePuiohuY65zQi+TvagpLlq6HWHwTbAhk7mxfIl2Sc 1v0msJUw/jBH9mrRDGxhDSXirGRTpM/sCCuDpYypDBMUmFkkUlPlyOExn 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANsMTVCtJV2Z/2dsb2JhbABEu1KBB4IgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBAESCBqHbguaep8EixOFVmADkXSEfY0igWeCZg X-IronPort-AV: E=Sophos;i="4.80,126,1344211200"; d="scan'208";a="119797915" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 09 Sep 2012 21:43:49 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q89Lhnvd019968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Sep 2012 21:43:49 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Sun, 9 Sep 2012 16:43:48 -0500 From: "Hemant Singh (shemant)" To: Bob Hinden , "ipv6@ietf.org Mailing List" Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHNisK5DZOcX6rKA0q9Ezb3VNxj2JeCjeKQ Date: Sun, 9 Sep 2012 21:43:48 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890838A7@xmb-rcd-x06.cisco.com> References: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.com> In-Reply-To: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.121] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19174.001 x-tm-as-result: No--35.041700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No 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: Sun, 09 Sep 2012 21:43:52 -0000 I support this document - it's important work and the document is really cl= ose to ship to the IESG.=20 I thought this document should be on Standards Track but the document does = not say anything about the Intended Status of the document. Please fix tha= t so that document includes Intended Status. Additionally, if the document= is on Standards Track, do we have at least one implementation of the proto= col changes covered in the document? Or the protocol changes are deemed mi= nor and one does not need at least one implementation?=20 Comments included below. COMMENTS: 1. In the first paragraph of the Protocol Update section, please replace "= route" by "router". At least all of RFC 4861 works with a default router n= ot a default route. 2. I think the following text in the Protocol Update section can be removed= because the text is redundant with RFC 4861. [The UNREACHABLE state is conceptual and not a required part of this specification. A node merely needs to satisfy the externally observable behavior of this specification.] Editorial comments: 1. In the first paragraph of the Introduction section, please add a space b= etween the two words shown below. [reachable.The]. 2. In the Protocol Update section, change "Cache Entry as any time" to=20 "Cache Entry at any time" In the same section change "no IPv6 packets" To "no IPv6 packet" 3. In the Example Algorithm section, do we need to change "An Implementation" to "An implementation"? 4. In the Security Considerations section, "belived" is misspelled. Regards, Hemant -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob= Hinden Sent: Tuesday, September 04, 2012 1:28 PM To: ipv6@ietf.org Mailing List Cc: Bob Hinden Subject: 6MAN WG Last Call: All, This message starts a two week 6MAN Working Group on advancing: Title : Neighbor Unreachability Detection is too impatient Author(s) : Erik Nordmark Igor Gashinsky Filename : draft-ietf-6man-impatient-nud-02.txt Pages : 8 Date : 2012-07-31 http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02 as Proposed Standard. Substantive comments and statements of support for a= dvancing this document should be directed to the mailing list. Editorial s= uggestions can be sent to the authors. This last call will end on Septembe= r 18, 2012. Regards, Ole Troan & Bob Hinden -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From internet-drafts@ietf.org Mon Sep 10 09:25:00 2012 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 0101021F8755; Mon, 10 Sep 2012 09:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlTXr2-LaKRs; Mon, 10 Sep 2012 09:24:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7A421F8718; Mon, 10 Sep 2012 09:24:58 -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-uri-zoneid-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120910162458.29387.74364.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2012 09:24:58 -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, 10 Sep 2012 16:25:00 -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 IET= F. Title : Representing IPv6 Zone Identifiers in Address Literals a= nd Uniform Resource Identifiers Author(s) : Brian Carpenter Robert M. Hinden Filename : draft-ietf-6man-uri-zoneid-03.txt Pages : 9 Date : 2012-09-10 Abstract: This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates RFC 3986 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-uri-zoneid-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Mon Sep 10 09:31:47 2012 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 4AD9221E803C for ; Mon, 10 Sep 2012 09:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.642 X-Spam-Level: X-Spam-Status: No, score=-101.642 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-kzCp9fOhQI for ; Mon, 10 Sep 2012 09:31:46 -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 8B22A21E8037 for ; Mon, 10 Sep 2012 09:31:46 -0700 (PDT) Received: by eaai11 with SMTP id i11so1019958eaa.31 for ; Mon, 10 Sep 2012 09:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=EXz0+t7HKjUuA5y6ss2/FecqROeOMaa+YAnToEsYK70=; b=QjOIpXnkw98ztPTX4snfTi/eWiAl96GVdMyHgHRgbZb7h1xsHFkHRsUKEEAQIOlqZb PsQ8rmcfJfCOneIruiqrshC3PFLXX6ifLOGxijIPycwI8r5FHJq7XVtyp+SWvFFvx2Rl ariAZKhOk4rm+/LjMTfotOeBbtdCu2WFQF5ezqwRfMZtSofLPkUsQf5+oP+gNK/uQPQ/ bctHnj3EvpzEXfpxeBnQFwcOCvy+4zCerbrNgeE/pMxDUqi1Egy66djW0pZPtK5jxHlR B4gZHzw1gOuZj0NZaH5WbTn8WviE73ML2VDaqZm/tsWssVxq39vpMoSYPLjhbc9n3jNb oBrg== Received: by 10.14.218.134 with SMTP id k6mr20722008eep.14.1347294705720; Mon, 10 Sep 2012 09:31:45 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-175.as13285.net. [2.102.218.175]) by mx.google.com with ESMTPS id r45sm39533081eem.6.2012.09.10.09.31.44 (version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 09:31:44 -0700 (PDT) Message-ID: <504E15F0.40801@gmail.com> Date: Mon, 10 Sep 2012 17:31:44 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-03.txt] 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: Mon, 10 Sep 2012 16:31:47 -0000 The authors believe that this version meets Ole's proposed consensus at http://www.ietf.org/mail-archive/web/ipv6/current/msg16258.html (Note: the final point in the proposed consensus "interface names may themselves have to escaped (non-roman or [] characters)" isn't mentioned in the text, but follows from the ABNF rules.) Brian + Bob -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-uri-zoneid-03.txt Date: Mon, 10 Sep 2012 09:24:58 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ipv6@ietf.org 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. Title : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers Author(s) : Brian Carpenter Robert M. Hinden Filename : draft-ietf-6man-uri-zoneid-03.txt Pages : 9 Date : 2012-09-10 Abstract: This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates RFC 3986 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-uri-zoneid-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From wesley.george@twcable.com Mon Sep 10 10:55:12 2012 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 2116521E8051 for ; Mon, 10 Sep 2012 10:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptbuqcvpu6Ju for ; Mon, 10 Sep 2012 10:55:11 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9640021E8041 for ; Mon, 10 Sep 2012 10:55:11 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,398,1344225600"; d="scan'208";a="418394936" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 10 Sep 2012 13:54:57 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 10 Sep 2012 13:55:08 -0400 From: "George, Wes" To: Bob Hinden , "ipv6@ietf.org Mailing List" Date: Mon, 10 Sep 2012 13:55:07 -0400 Subject: RE: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: Ac2Kws141hCxUGmyRW2Ck+83C69N/wEuo9QQ Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592304E7B092@PRVPEXVS15.corp.twcable.com> References: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.com> In-Reply-To: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.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 Sep 2012 17:55:12 -0000 Read and support. Thanks, Wes > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Bob Hinden > Sent: Tuesday, September 04, 2012 1:28 PM > To: ipv6@ietf.org Mailing List > Cc: Bob Hinden > Subject: 6MAN WG Last Call: > > All, > > This message starts a two week 6MAN Working Group on advancing: > > Title : Neighbor Unreachability Detection is too > impatient > Author(s) : Erik Nordmark > Igor Gashinsky > Filename : draft-ietf-6man-impatient-nud-02.txt > Pages : 8 > Date : 2012-07-31 > > http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02 > > as Proposed Standard. Substantive comments and statements of support > for advancing this document should be directed to the mailing list. > Editorial suggestions can be sent to the authors. This last call will > end on September 18, 2012. > > Regards, > Ole Troan & Bob Hinden > > > -------------------------------------------------------------------- > 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 wwwrun@rfc-editor.org Mon Sep 10 17:18:54 2012 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 602F521F873A; Mon, 10 Sep 2012 17:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.374 X-Spam-Level: X-Spam-Status: No, score=-101.374 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-mgipc6H0Zq; Mon, 10 Sep 2012 17:18:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id EA2C821F8737; Mon, 10 Sep 2012 17:18:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DDAE8B1E00C; Mon, 10 Sep 2012 17:15:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 6724 on Default Address Selection for Internet Protocol Version 6 (IPv6) From: rfc-editor@rfc-editor.org Message-Id: <20120911001549.DDAE8B1E00C@rfc-editor.org> Date: Mon, 10 Sep 2012 17:15:49 -0700 (PDT) Cc: ipv6@ietf.org, rfc-editor@rfc-editor.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 Sep 2012 00:18:54 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6724 Title: Default Address Selection for Internet Protocol Version 6 (IPv6) Author: D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown Status: Standards Track Stream: IETF Date: September 2012 Mailbox: dthaler@microsoft.com, richdr@microsoft.com, arifumi@nttv6.net, tjc@ecs.soton.ac.uk Pages: 32 Characters: 74407 Obsoletes: RFC3484 I-D Tag: draft-ietf-6man-rfc3484bis-06.txt URL: http://www.rfc-editor.org/rfc/rfc6724.txt This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa. Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK] This document is a product of the IPv6 Maintenance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From bob.hinden@gmail.com Mon Sep 10 23:39:33 2012 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 98BF021F8566 for ; Mon, 10 Sep 2012 23:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHJTggEt6fel for ; Mon, 10 Sep 2012 23:39:33 -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 CB01221F856D for ; Mon, 10 Sep 2012 23:39:32 -0700 (PDT) Received: by eaai11 with SMTP id i11so64001eaa.31 for ; Mon, 10 Sep 2012 23:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3Rdug5Ltv2SvilaLSWoYWcIKdjZywOyyr+/37pro9k8=; b=nsd4L8PmBsOurxLo8hr6FFDQrRtXIOyEJJSbVq6ZyD9ASGzP924RQOhGTUAKUHY3V3 zI6aTZTeSgK64zvt5dnu0pDHdktWDJpHuZ/WqC7VRsXn+LWhRkktA+LhJ0mtC3LGZUUD G9qURZ6kYSf/UR/koQW2d2h2PO5AwkSKEri5JdcIaJmbHpDZBqJjtDSEMi7SIcG7P7n6 W5TlITavGoky7Co1Aa1dDOEFqySWun9N3rNK1wswoJkgHPvOJ9xPcTwLuOYHDnbyQU1f ofogOkZymOV9buAz2BY+VF8cgDpU5OPZIoUXVj09oBI0hTsya1xeGcln9bY+OJfWsFOs 7nqQ== Received: by 10.14.202.71 with SMTP id c47mr23879775eeo.42.1347345570119; Mon, 10 Sep 2012 23:39:30 -0700 (PDT) Received: from [172.24.251.175] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPS id a7sm44142221eep.14.2012.09.10.23.39.23 (version=SSLv3 cipher=OTHER); Mon, 10 Sep 2012 23:39:28 -0700 (PDT) Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-03.txt] Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <504E15F0.40801@gmail.com> Date: Tue, 11 Sep 2012 09:39:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5A0F639E-0C33-4BAD-BFED-FD929CBE53E1@gmail.com> References: <504E15F0.40801@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1280) Cc: 6man , 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: Tue, 11 Sep 2012 06:39:33 -0000 On Sep 10, 2012, at 7:31 PM, Brian E Carpenter wrote: > The authors believe that this version meets Ole's proposed consensus = at > http://www.ietf.org/mail-archive/web/ipv6/current/msg16258.html >=20 > (Note: the final point in the proposed consensus "interface names may > themselves have to escaped (non-roman or [] characters)" isn't = mentioned > in the text, but follows from the ABNF rules.) The text does include: If an operating system uses any other characters in zone or interface identifiers that are not in the "unreserved" character set, they MUST be escaped with a "%" sign according to RFC 3986. This was in the earlier versions of the draft and I think it covers this = case. Bob >=20 > Brian + Bob >=20 > -------- Original Message -------- > Subject: I-D Action: draft-ietf-6man-uri-zoneid-03.txt > Date: Mon, 10 Sep 2012 09:24:58 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: ipv6@ietf.org >=20 >=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 : Representing IPv6 Zone Identifiers in Address = Literals and Uniform Resource Identifiers > Author(s) : Brian Carpenter > Robert M. Hinden > Filename : draft-ietf-6man-uri-zoneid-03.txt > Pages : 9 > Date : 2012-09-10 >=20 > Abstract: > This document describes how the Zone Identifier of an IPv6 scoped > address can be represented in a literal IPv6 address and in a = Uniform > Resource Identifier that includes such a literal address. It = updates > RFC 3986 accordingly. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-uri-zoneid-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From ichiroumakino@gmail.com Tue Sep 11 05:22:04 2012 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 ABC4B21F87E8 for ; Tue, 11 Sep 2012 05:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odKhsefntW9g for ; Tue, 11 Sep 2012 05:22:04 -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 CEB2521F87E3 for ; Tue, 11 Sep 2012 05:22:03 -0700 (PDT) Received: by eaai11 with SMTP id i11so253815eaa.31 for ; Tue, 11 Sep 2012 05:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:subject:date:message-id:to:mime-version :x-mailer; bh=AWJiub7g0TfnW0Zocb0NqSQAu3NxunV1/PfU0xDhW0A=; b=EfKlg/0g7OlbCOzUWxM2f/ROA1K1iUhEBz6a/8SGK5SfhCk4JAMQs1iQVRwtOneQnH 0+ApEZKR378V4oOMuyrGwEeOWsDBFPHe9AXpT/7/pO3OEPEkKKSrGwocrxEs6rtxX4ro o2pXZtf7jH8J0+na2uezFjfmDJ2TWmrNKpgj2HO8gHwYC9LKTajMyXp5/rGniX2yDR7g JN3WtDIGNpzyanxbTIWQMhHsBaEO3pZzKMRQRlexd73X+tCKS8+qFRC8lc/fRCO7Y8Qz ywjX67rtnMWortEXpbJqHeDnswg73DYhk0w0dOjGCZ3dvBdQdO1KyfXFiI+y5EknJ7d8 PIgA== Received: by 10.14.172.193 with SMTP id t41mr25370115eel.25.1347366123066; Tue, 11 Sep 2012 05:22:03 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-145.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e7sm46677535eep.2.2012.09.11.05.22.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Sep 2012 05:22:02 -0700 (PDT) Sender: Ole Troan From: =?iso-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/signed; boundary="Apple-Mail=_9C3357CB-4F12-483E-8EA6-27EF9E383D17"; protocol="application/pkcs7-signature"; micalg=sha1 Subject: Adopting draft-krishnan-6man-resilient-rs Date: Tue, 11 Sep 2012 14:21:58 +0200 Message-Id: <1DD43EE0-A900-42A6-94FE-563542953210@employees.org> To: "ipv6@ietf.org 6man" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) 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 Sep 2012 12:22:04 -0000 --Apple-Mail=_9C3357CB-4F12-483E-8EA6-27EF9E383D17 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii All, There was consensus in the room for adopting this document in Vancouver. This starts a 1-week call to confirm that consensus on the mailing list Title : Packet loss resiliency for Router Solicitations Author(s) : S. Krishnan, D. Anipko, D. Thaler Filename : draft-krishnan-6man-resilient-rs-01 Pages : 5 Date : 2012-07-16 as a 6MAN WG document. Please state your opinion if you object to on making this draft a WG draft either on the mailing list or to the chairs. This call will end 2012-09-18. Best regards, Bob & Ole --Apple-Mail=_9C3357CB-4F12-483E-8EA6-27EF9E383D17 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTExMTIyMTU5WjAjBgkqhkiG9w0BCQQxFgQUT/KQW/XhgRIUO6xG NzxtbJIlCxAwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAfBsd7j2c1dQPNhIAyEdQ ic98zPgvF5pEcrqMUQJovtOgMcM23PH+fYTd6/iu+KAAyrgmtJL9XWb0Pz1cqEQVGdQ+/l9nH0DK Y5BaPUxK0HHqW7RWte1ls6z+pLPl4VzKdPQowgApNMdKAQ5R8jl7zOvLjBiZr1tQWFJ3EnHmOzQy zEHByTGcdbFq3Op2JHVwvNu8yrYOmSFEoRknMtmLWD/mMqRfVUr1kdUhoFzKUpLVIBnYhhiWO2yb TGCjOP59QdpONiSHSx/j4CP5c49TyDWUQvBXFqRpurl2BIfT4CJZ/3q7YAuHFwu8ftbocDHHSZSe 2I447ZwLCxeGT9F+wwAAAAAAAA== --Apple-Mail=_9C3357CB-4F12-483E-8EA6-27EF9E383D17-- From wwwrun@rfc-editor.org Wed Sep 12 02:07:20 2012 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 4FAB021F863C for ; Wed, 12 Sep 2012 02:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.7 X-Spam-Level: X-Spam-Status: No, score=-101.7 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSkAob3Rw6qh for ; Wed, 12 Sep 2012 02:07:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5C621F861E for ; Wed, 12 Sep 2012 02:07:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DE90DB1E002; Wed, 12 Sep 2012 02:03:57 -0700 (PDT) To: dthaler@microsoft.com, richdr@microsoft.com, arifumi@nttv6.net, tjc@ecs.soton.ac.uk, rdroms.ietf@gmail.com, brian@innovationslab.net, bob.hinden@gmail.com, otroan@employees.org Subject: [Technical Errata Reported] RFC6724 (3343) From: RFC Errata System Message-Id: <20120912090358.DE90DB1E002@rfc-editor.org> Date: Wed, 12 Sep 2012 02:03:57 -0700 (PDT) Cc: bortzmeyer+rfc@nic.fr, ipv6@ietf.org, rfc-editor@rfc-editor.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 Sep 2012 09:07:20 -0000 The following errata report has been submitted for RFC6724, "Default Address Selection for Internet Protocol Version 6 (IPv6)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6724&eid=3343 -------------------------------------- Type: Technical Reported by: Stephane Bortzmeyer Section: 10.1 Original Text ------------- Destination: 2001:db8:1::1 Candidate Source Addresses: 2001:db8:3::1 or fe80::1 Result: 2001:db8::1 (prefer appropriate scope) Corrected Text -------------- Destination: 2001:db8:1::1 Candidate Source Addresses: 2001:db8:3::1 or fe80::1 Result: 2001:db8:3::1 (prefer appropriate scope) Notes ----- 2001:db8::1 is not even in the candidate set. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6724 (draft-ietf-6man-rfc3484bis-06) -------------------------------------- Title : Default Address Selection for Internet Protocol Version 6 (IPv6) Publication Date : September 2012 Author(s) : D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown Category : PROPOSED STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Sep 12 02:14:19 2012 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 35B5121F863C for ; Wed, 12 Sep 2012 02:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.72 X-Spam-Level: X-Spam-Status: No, score=-101.72 tagged_above=-999 required=5 tests=[AWL=0.880, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaG2CT+nwFZZ for ; Wed, 12 Sep 2012 02:14:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id CF0FA21F8624 for ; Wed, 12 Sep 2012 02:14:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B58BCB1E002; Wed, 12 Sep 2012 02:11:09 -0700 (PDT) To: dthaler@microsoft.com, richdr@microsoft.com, arifumi@nttv6.net, tjc@ecs.soton.ac.uk, rdroms.ietf@gmail.com, brian@innovationslab.net, bob.hinden@gmail.com, otroan@employees.org Subject: [Editorial Errata Reported] RFC6724 (3344) From: RFC Errata System Message-Id: <20120912091109.B58BCB1E002@rfc-editor.org> Date: Wed, 12 Sep 2012 02:11:09 -0700 (PDT) Cc: bortzmeyer+rfc@nic.fr, ipv6@ietf.org, rfc-editor@rfc-editor.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 Sep 2012 09:14:19 -0000 The following errata report has been submitted for RFC6724, "Default Address Selection for Internet Protocol Version 6 (IPv6)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6724&eid=3344 -------------------------------------- Type: Editorial Reported by: Stephane Bortzmeyer Section: 10.1 Original Text ------------- Destination: 2001:db8:1::1 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2 Result: 2001:db8:1:::2 (longest matching prefix) Corrected Text -------------- Destination: 2001:db8:1::1 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2 Result: 2001:db8:1::2 (longest matching prefix) Notes ----- Invalid IPv6 syntax Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6724 (draft-ietf-6man-rfc3484bis-06) -------------------------------------- Title : Default Address Selection for Internet Protocol Version 6 (IPv6) Publication Date : September 2012 Author(s) : D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown Category : PROPOSED STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From Tina.Tsou.Zouting@huawei.com Thu Sep 13 22:32:11 2012 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 1382A21F870B for ; Thu, 13 Sep 2012 22:32:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JxnGl4yKvpt for ; Thu, 13 Sep 2012 22:32:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8C12821F8705 for ; Thu, 13 Sep 2012 22:32:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKQ69139; Fri, 14 Sep 2012 05:32:08 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 06:31:16 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 06:31:31 +0100 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.159]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 13 Sep 2012 22:31:25 -0700 From: Tina TSOU To: Bob Hinden , 6man Subject: Re: 6MAN WG Last Call: Thread-Topic: 6MAN WG Last Call: Thread-Index: AQHNisMFeumV7vhsv0+Q43In5d3xVZeEWqaAgASUFJyAANw2gP//k+dQ Date: Fri, 14 Sep 2012 05:31:25 +0000 Message-ID: References: <72907536-3B88-4E29-87EA-562A8DAD3A85@gmail.com>, <2671C6CDFBB59E47B64C10B3E0BD592304E7B092@PRVPEXVS15.corp.twcable.com> , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-impatient-nud@tools.ietf.org" , "nordmark@cisco.com" , Igor Gashinsky 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 Sep 2012 05:32:11 -0000 Here u go. Tina On Sep 13, 2012, at 9:58 PM, "Bob Hinden" wrote: > Tina, >=20 > Please copy the w.g. mailing list when you comment on drafts in w.g. last= call. It's good that the whole working group sees the comments and discus= sion. >=20 > Thanks, > Bob >=20 > On Sep 14, 2012, at 1:50 AM, Tina TSOU wrote: >=20 >> Hi Erik and Igor, >>=20 >> The draft is well explained in regards to the case when there is no alte= rnative default router in the lest of default routers. >>=20 >> I wanted some clarification in the content below: >>=20 >> In the draft, >> The recommended behavior is to have 5 attempts, with timing spacing >> of 0 (initial request), 1 second later, 3 seconds later, then 9, and >> then 27, and switch to UNREACHABLE after 3 transmissions, which >> represents:-------after the initial request, we transmit a packet after= 1 sec, then another after 3 seconds, then another after 9 seconds and fina= lly after 27 secs right? >>=20 >> MAX_UNICAST_SOLICIT=3D5----This would imply 5 attempts? >>=20 >> RETRANS_TIMER=3D1 (default) >>=20 >> BACKOFF_MULTIPLE=3D3 >>=20 >> MARK_UNREACHABLE=3D3------Do we mark it unreachable after 9 secs OR = 4 secs 0r 27 secs? >> After marking unreachable, multicast NS will be send instead of Unicast = NS right? >>=20 >> Since there will be 5 attempts, would it imply it will wait 27 seconds b= efore declaring it unreachable? >>=20 >> I look forward hearing from you. >>=20 >> Tina >>=20 >> On Sep 10, 2012, at 10:55 AM, "George, Wes" = wrote: >>=20 >>> Read and support. >>>=20 >>> Thanks, >>>=20 >>> Wes >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf O= f >>>> Bob Hinden >>>> Sent: Tuesday, September 04, 2012 1:28 PM >>>> To: ipv6@ietf.org Mailing List >>>> Cc: Bob Hinden >>>> Subject: 6MAN WG Last Call: >>>>=20 >>>> All, >>>>=20 >>>> This message starts a two week 6MAN Working Group on advancing: >>>>=20 >>>> Title : Neighbor Unreachability Detection is too >>>> impatient >>>> Author(s) : Erik Nordmark >>>> Igor Gashinsky >>>> Filename : draft-ietf-6man-impatient-nud-02.txt >>>> Pages : 8 >>>> Date : 2012-07-31 >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02 >>>>=20 >>>> as Proposed Standard. Substantive comments and statements of support >>>> for advancing this document should be directed to the mailing list. >>>> Editorial suggestions can be sent to the authors. This last call will >>>> end on September 18, 2012. >>>>=20 >>>> Regards, >>>> Ole Troan & Bob Hinden >>>>=20 >>>>=20 >>>> -------------------------------------------------------------------- >>>> 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 pr= oprietary information, which is privileged, confidential, or subject to cop= yright belonging to Time Warner Cable. This E-mail is intended solely for t= he 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 di= ssemination, distribution, copying, or action taken in relation to the cont= ents of and attachments to this E-mail is strictly prohibited and may be un= lawful. 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-mai= l and any printout. >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >=20 From ichiroumakino@gmail.com Fri Sep 14 00:08:32 2012 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 68BEF21F8600 for ; Fri, 14 Sep 2012 00:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVL5qnJC18-7 for ; Fri, 14 Sep 2012 00:08:31 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10B3221F85F3 for ; Fri, 14 Sep 2012 00:08:30 -0700 (PDT) Received: by eekb45 with SMTP id b45so2347499eek.31 for ; Fri, 14 Sep 2012 00:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:subject:date:message-id:to:mime-version :x-mailer; bh=1PAXhcB01cNCr5z5VVaCzCx+/ZsFWiwhWETpETKuflU=; b=nfUndeXPorT+fl6vXEvWheVu3ukSYKocc/aXoJceQu5MJUFGe9e/mXO4zlrqtglaRQ mqUwhT6bEbTXRgFw++vcVKu77RIDjDr3L1ylLS3EZe368mtRm9I3Kqcww5n3RifJnil5 uewxM+AhnTw66ggjfOafZjzt2Jf6RFGUxp1ZWZP6Esivrpzmc07qpX/OyRFwKGTkjQ4V jjNt0ahqNaJs/PGIZg+QDmn78ONmLtbq/97yT8ncCmLPhiDKGQdEooENm4Kq4XH+uc6C nhbp9CPnqRxBqtUlnk+jjrvBoj7A6xDUCNgb3ULR4K7K/HuAcZuxWdosnpza4+wWmTjh p1TQ== Received: by 10.14.211.3 with SMTP id v3mr2086896eeo.43.1347606510235; Fri, 14 Sep 2012 00:08:30 -0700 (PDT) Received: from dhcp-lys01-vla250-10-147-112-145.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e7sm1730578eep.2.2012.09.14.00.08.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Sep 2012 00:08:28 -0700 (PDT) Sender: Ole Troan From: =?iso-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/signed; boundary="Apple-Mail=_C4CED807-4570-4DC2-A02F-578FEE06B471"; protocol="application/pkcs7-signature"; micalg=sha1 Subject: Document status Date: Fri, 14 Sep 2012 09:08:30 +0200 Message-Id: To: "ipv6@ietf.org 6man" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) 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 Sep 2012 07:08:32 -0000 --Apple-Mail=_C4CED807-4570-4DC2-A02F-578FEE06B471 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii all, fyi: the chairs have just requested the IESG to publish: draft-ietf-6man-udpchecksums-04 draft-ietf-6man-udpzero-06 document status of all our working group documents are available here: https://datatracker.ietf.org/wg/6man/ upcoming document actions are: - WGLC of draft-ietf-6man-addr-select-opt (awaiting new revision) - WGLC of draft-ietf-6man-enhanced-dad (awaiting new revision) - Advancement of draft-ietf-6man-uri-zoneid-03 to the IESG Regards, Ole & Bob --Apple-Mail=_C4CED807-4570-4DC2-A02F-578FEE06B471 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTE0MDcwODMxWjAjBgkqhkiG9w0BCQQxFgQU/I9uXnOCdOY6TQiH Zx2SJ2iu/jEwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAO28nakijdArKZMt6A3bi CmF3Jc/cxOd/gIBmUYB0RjfPrlSGMjsZNkA0yV+ANwff7hZSrQGBV6s3ia8M9F0KtSXkwgyDDnp9 HgZ5oq6EK/sm792SYQ2UeZnytKBE4wERCq616YRBEuUAhFixcNpMNHh7NTfvOuYm4tt0zuvt9t02 M8Dk+Ai9LE0aLavk1WmOb0MiDHPI9H2ONGhUQFVwqI/N4o/Sq+QyCLD7x2E6hAF5CYtVZxgHEhcv P7Q9TkET/siNXoI34/cUfPkuBTsNwYGc8/TzAiMEzPv0JRhuzMb5HkyQMwFDqxkMsaK7ImNjCdeb RSKYwaLWItYd1AKhOQAAAAAAAA== --Apple-Mail=_C4CED807-4570-4DC2-A02F-578FEE06B471-- From shemant@cisco.com Fri Sep 14 15:34:15 2012 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 9F3BC21F84EB for ; Fri, 14 Sep 2012 15:34:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdeaJQps1o+Q for ; Fri, 14 Sep 2012 15:34:15 -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 E8A0F21F84E2 for ; Fri, 14 Sep 2012 15:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2714; q=dns/txt; s=iport; t=1347662055; x=1348871655; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=rjVcrew10ok62jiev9dCI/dySSr7nHYWICaOm+jNPr0=; b=DUVgGIRW/TZjKmL9VvIqstED8PwgKBI4XuEOW65WLuSOFFDak9ixHaIF sDhibLqRAW63lKOHqD9UWUiS3Y7EDyODiH+OfQ0+IzNKckXE8gA8apOQi h5DQ62L5PjhEkjB3dTElLgkngjS0Lz4nXgDbgZQiB22deJDo3n8p1G0UG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHewU1CtJXG9/2dsb2JhbABFvAqBB4IgAQEBBBIBJ0sGAQgRBAEBCxQJORQHAQEFBQQTCAEZh2sLmVeBKKAYix8ahW5gA6QZgWmCZoFjNA X-IronPort-AV: E=Sophos;i="4.80,424,1344211200"; d="scan'208";a="121832904" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 14 Sep 2012 22:33:56 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8EMXuSC013410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Sep 2012 22:33:56 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Fri, 14 Sep 2012 17:33:56 -0500 From: "Hemant Singh (shemant)" To: "ipv6@ietf.org Mailing List" Subject: FW: I-D Action: draft-ietf-6man-enhanced-dad-01.txt Thread-Topic: I-D Action: draft-ietf-6man-enhanced-dad-01.txt Thread-Index: AQHNjbPCRVNJOyJbNUmsXyxWVlLVe5eCaIaAgABkBICAAs/F6oAEupVggAAfZ8A= Date: Fri, 14 Sep 2012 22:33:55 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B8908A581@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.254.128] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004 x-tm-as-result: No--28.846800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No 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: Fri, 14 Sep 2012 22:34:15 -0000 I thought it's prudent to also include the 6man mailer in my reply to Tina. Regards, Hemant -----Original Message----- From: Hemant Singh (shemant)=20 Sent: Friday, September 14, 2012 4:56 PM To: Tina TSOU; draft-ietf-6man-enhanced-dad@tools.ietf.org Cc: 6man-chairs@tools.ietf.org Subject: RE: I-D Action: draft-ietf-6man-enhanced-dad-01.txt Tina, Humble apologies for the delayed reply. Please see below.=20 -----Original Message----- From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]=20 Sent: Tuesday, September 11, 2012 4:27 PM To: draft-ietf-6man-enhanced-dad@tools.ietf.org Cc: 6man-chairs@tools.ietf.org Subject: Re: I-D Action: draft-ietf-6man-enhanced-dad-01.txt >The draft proposes the use of Enhanced DAD Algorithm for detecting looped = back NS ( DAD) message. It suggests the use of Nonce option in the SEND >me= ssage. Considering that two router might generate the same nonce, would it= be preferable to have unique nonce id? Since the nonce option is of 6 >byt= es, the problem of two ipv6 nodes generating same random nonce option would= be to most extent rectified.=20 =20 Do you really think a 6 bytes number has a chance of collision? It's very = less likely. Besides, the Enhanced DAD algorithm has no problem for your u= se case. Each router interface processes a looped back DAD if one is loope= d back. =20 >Moreover depending on the number of interfaces running IPv6, would each in= terface have its own nonce number used for DAD? Or does the IPv6 node maint= ain >one common nonce for all its interfaces running IPv6? =20 Please see the above question answered in the 6man mailer. Each interface = uses a nonce per IPv6 address used by the interface. http://www.ietf.org/mail-archive/web/ipv6/current/msg16298.html >Moreover, the enhanced DAD algorithm is to enabled on both sides of the in= terfaces right?=20 Same as RFC 4862. Whatever side of an interface RFC 4862 works on, the Enh= anced DAD also does the same. Our document hasn't said anything to the con= trary. >If the nonce option does not match, and the target address is same ( genui= ne duplicate address), the interface will be disabled? So would this be >au= tomated or manual intervention would be required for disabling the interfac= e? Automated disabling would be preferred considering the increase in the >= number of routers. Would Enhanced DAD support automated disabling? If so, i= n all cases or specific cases? =20 See section 5 of the document where automated actions are recommended for a= ccess networks. Thus cable and DSL access networks will benefit with the a= utomated action. =20 Thanks and regards, Hemant From fgont@si6networks.com Fri Sep 14 16:42:22 2012 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 74F1A21F84D5 for ; Fri, 14 Sep 2012 16:42:22 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yik66Gs2NowV for ; Fri, 14 Sep 2012 16:42:22 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id E590321F84B6 for ; Fri, 14 Sep 2012 16:42:21 -0700 (PDT) Received: from [186.134.45.26] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TCfWY-0007PX-S2; Sat, 15 Sep 2012 01:42:15 +0200 Message-ID: <5053BF57.1000901@si6networks.com> Date: Fri, 14 Sep 2012 20:35:51 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Subject: Re: Document status References: In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org 6man" 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 Sep 2012 23:42:22 -0000 Hi, Ole, On 09/14/2012 04:08 AM, Ole Trøan wrote: > upcoming document actions are: > - WGLC of draft-ietf-6man-addr-select-opt (awaiting new revision) > - WGLC of draft-ietf-6man-enhanced-dad (awaiting new revision) > - Advancement of draft-ietf-6man-uri-zoneid-03 to the IESG My take is that draft-ietf-6man-nd-extension-headers is ready for WGLC, too. Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian@innovationslab.net Tue Sep 18 08:03:25 2012 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 B333521E80D3 for ; Tue, 18 Sep 2012 08:03:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXHEURnQIRRh for ; Tue, 18 Sep 2012 08:03:25 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 522D421E80D2 for ; Tue, 18 Sep 2012 08:03:25 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 2E0E38814B; Tue, 18 Sep 2012 08:03:25 -0700 (PDT) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A871D140039; Tue, 18 Sep 2012 08:03:24 -0700 (PDT) Message-ID: <50588D39.5050200@innovationslab.net> Date: Tue, 18 Sep 2012 11:03:21 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: 6man WG , 6man Chairs <6man-chairs@tools.ietf.org>, draft-ietf-6man-udpchecksums@tools.ietf.org, draft-ietf-6man-udpzero@tools.ietf.org Subject: UDP Checksum drafts 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: Tue, 18 Sep 2012 15:03:25 -0000 All, I have completed my AD review of the two UDP checksum zero drafts and think they are in good shape. I will be starting the IETF Last Call shortly. Regards, Brian From iesg-secretary@ietf.org Tue Sep 18 09:55:53 2012 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 D865A21E80EF; Tue, 18 Sep 2012 09:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfNpXbp5L32l; Tue, 18 Sep 2012 09:55:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC82F21F8606; Tue, 18 Sep 2012 09:55:52 -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: (UDP Checksums for Tunneled Packets) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120918165552.13842.12442.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2012 09:55:52 -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: Tue, 18 Sep 2012 16:55:54 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'UDP Checksums for Tunneled Packets' as 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 2012-10-02. 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 This document provides an update of the Internet Protocol version 6 (IPv6) specification (RFC2460) to improve the performance of IPv6 in the use case when a tunnel protocol uses UDP with IPv6 to tunnel packets. 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 relaxation removes the overhead associated with the computation of UDP checksums on IPv6 packets used to carry tunnel protocols and thereby improves the efficiency of the traversal of firewalls and other network middleboxes by such 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 defines restrictions on the use of this relaxation to mitigate these risks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue Sep 18 09:57:23 2012 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 253C821E80FA; Tue, 18 Sep 2012 09:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a82Qe5kIgnot; Tue, 18 Sep 2012 09:57:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B973A21E80DF; Tue, 18 Sep 2012 09:57:22 -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: (IPv6 UDP Checksum Considerations) to Informational RFC X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120918165722.15510.3695.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2012 09:57:22 -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: Tue, 18 Sep 2012 16:57:23 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'IPv6 UDP Checksum Considerations' as Informational RFC 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 2012-10-02. 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 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Wed Sep 19 05:08:23 2012 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 06EEB21F8713; Wed, 19 Sep 2012 05:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5gVju-Q379Z; Wed, 19 Sep 2012 05:08:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FEB21F86E1; Wed, 19 Sep 2012 05:08: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-dad-proxy-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120919120822.24221.58112.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 05:08: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: Wed, 19 Sep 2012 12:08: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 IET= F. Title : Duplicate Address Detection Proxy Author(s) : Fabio Costa Xavier Pougnard Hongyu Li Filename : draft-ietf-6man-dad-proxy-05.txt Pages : 14 Date : 2012-09-19 Abstract: The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-dad-proxy-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-dad-proxy-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Wed Sep 19 08:16:51 2012 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 EEB8821F870B; Wed, 19 Sep 2012 08:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AhdPXY1d4py; Wed, 19 Sep 2012 08:16:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A85921F8650; Wed, 19 Sep 2012 08:16:50 -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: (Duplicate Address Detection Proxy) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120919151650.20312.79812.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 08:16:50 -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: Wed, 19 Sep 2012 15:16:51 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Duplicate Address Detection Proxy' as 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 2012-10-03. 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 document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-dad-proxy/ballot/ No IPR declarations have been submitted directly on this I-D. From joelja@bogus.com Thu Sep 20 14:13:35 2012 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 875A121E8093; Thu, 20 Sep 2012 14:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdhKaIgpSJEQ; Thu, 20 Sep 2012 14:13:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A9ED221E805F; Thu, 20 Sep 2012 14:13:28 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8KLDR93074793 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 20 Sep 2012 21:13:27 GMT (envelope-from joelja@bogus.com) Message-ID: <505B86F1.6020602@bogus.com> Date: Thu, 20 Sep 2012 14:13:21 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120828 Thunderbird/16.0 MIME-Version: 1.0 To: IPv6 Ops WG , "ipv6@ietf.org 6man" Subject: FWD: I-D Action: draft-gashinsky-6man-v6nd-enhance-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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]); Thu, 20 Sep 2012 21:13:27 +0000 (UTC) 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 Sep 2012 21:13:35 -0000 Greetings, On the heals of work on draft-ietf-6man-impatient-nud-02 and rfc 6583 the authors have decided to take a lot at their proposal for gratuitous neighbor advertisement. We believe that this approach has the potential to ameliorate some problems experienced today in large broadcast domains where control plane processors may spend a significant chunk of their cpu cycles mananging NDP even under normal circumstances. There is some real world experience of meltdowns not caused by deliberate DOS that we ascribe to the current handling of NDP so we'd like to see some additional effort in this area. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Neighbor Discovery Enhancement for DOS mititgation Author(s) : Warren Kumari Filename : draft-gashinsky-6man-v6nd-enhance-01.txt Pages : 10 Date : 2012-09-20 Abstract: In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery can be vulnerable to denial of service attacks whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools that scan networks for inventory and other purposes. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes a modification to the [RFC4861] neighbor discovery protocol aimed at improving the resilience of the neighbor discovery process. We call this process Gratuitous neighbor discovery and it derives inspiration in part from analogous IPv4 gratuitous ARP implementation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-gashinsky-6man-v6nd-enhance There's also a htmlized version available at: http://tools.ietf.org/html/draft-gashinsky-6man-v6nd-enhance-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-gashinsky-6man-v6nd-enhance-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From osmankh@yahoo.com Fri Sep 21 00:04:17 2012 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 4804621F86B3 for ; Fri, 21 Sep 2012 00:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1xHKuXZhaUe for ; Fri, 21 Sep 2012 00:04:01 -0700 (PDT) Received: from nm14-vm0.bullet.mail.ne1.yahoo.com (nm14-vm0.bullet.mail.ne1.yahoo.com [98.138.91.52]) by ietfa.amsl.com (Postfix) with SMTP id 3C65311E808A for ; Fri, 21 Sep 2012 00:03:57 -0700 (PDT) Received: from [98.138.90.49] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 21 Sep 2012 07:03:54 -0000 Received: from [98.138.89.233] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 21 Sep 2012 07:03:54 -0000 Received: from [127.0.0.1] by omp1048.mail.ne1.yahoo.com with NNFMP; 21 Sep 2012 07:03:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 66477.4601.bm@omp1048.mail.ne1.yahoo.com Received: (qmail 54393 invoked by uid 60001); 21 Sep 2012 07:03:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348211034; bh=xnxH0pPj0ziUAJtMN0k+f8UmOX9M71lEvrht7wvpFfA=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=wyydK5mueXbQMCmrtak5mXGwrQrQB4fxZSxr6SmDTe/QtODVdyAl4+Z7dxg2UUb5hNQEpcLDZjdbj+Qg7YBUsOxQTt46Vav1LgWOG1dTgb04vBpmci3tv+coJumUSN5NIn06SJ/xIelMSyiUGjpRre8E2OiEPVPYmzBdPlzWsZA= 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; b=SmioJ2+1vmlZDrpri5ZAnaOuN2P3XYwXG3EZv2YE7+E+OiYlsu6I/9+ellcJy6wsaGWIdBhCQ1rHQ3KO2kUxRz6JH3u+qcUol2cCtz0RVqYrzF1YCv7Yjo1QaHYVVYr60uHY7c8aAhAKLvHWTuy5VCsgzVmoiq0Ir7GGiJWDlfc=; X-YMail-OSG: IJEgj2YVM1kdz1Sx30QTJhLEwWuDwO0j1CDltES5MwRxyAn HJes8mdED24.gD596znGwpFTv.ydMx0t34OPpLdG.SlMTXZTax7YGU4artp9 bh25ZXVXlOvWOMQEooegAJBZKdJtKDghvNoeRUMWnRR8X3OIW69kbmdyPxA2 QrW.uk1kVjuPbT6FtQBXA9BWynBOLJnfpd8vHTTIbLZ4hKBh8m6YCY13UT09 EKCWc0Lmw.tUCsb_jL7VwQoImn9GmVDH9phfc1NpOvnzdOvNr.861.HnIQBH 5EoYMZrRlHvPe6Ny.I9DtwgX0L8KrMaNSMDSK8nrnurCaBdic03a84YSeEXq mi4CuFNMp059T1XJVe71USJhCXnh5EQ0ZmgJzkOpUeovspoblQcPlVlZtiCL U7CSrLkAL9fOS0RzIXjLwKO8ZIi69qV5XZ27W0PbhV8RxkHeNpOTGgnIZdZj 9ydKt68TDoulDOqFu0A-- Received: from [203.94.155.226] by web126005.mail.ne1.yahoo.com via HTTP; Fri, 21 Sep 2012 00:03:53 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.416 Message-ID: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> Date: Fri, 21 Sep 2012 00:03:53 -0700 (PDT) From: Usman Latif Subject: IPv6 address assignment for strictly point-to-point links and Device Loopbacks To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1833503604-2009576388-1348211033=:52674" X-Mailman-Approved-At: Fri, 21 Sep 2012 00:31:42 -0700 Cc: bob.hinden@gmail.com 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 Sep 2012 07:06:50 -0000 --1833503604-2009576388-1348211033=:52674 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, =A0 I am one of the many Network Engineers/architects that are today on the ver= ge of assigning IPv6 addressing in their core networks. There=A0are two points that I would like to open a debate on and really loo= king for some substantial reasoning and logic on. =A0 And the points are:=20 =A0 Q1: "What is the IETF best-practice / recommendation for assigning IPv6 add= ressing to strictly point-to-point links where we know there will never be = more than one device on each end of the link for the foreseeable future" =A0 Q2: "What is the IETF best practice / recommendation for assigning IPv6 add= ressing for Loopback interfaces on routers" I have gone through some RFCs (RFC 4291, RFC 5375, RFC 3627, RFC 3177 / 617= 7 and RFC 6164) =A0 As a network engineer with IPv4 and some IPv6 background, I am inclined to = use /127 addressing on strictly point to point links and /128 for Loopbacks= - but after discussion with peers in the industry have learnt that althoug= h the recommendations are to use /127 for p2p and /128 for Loopbacks, its b= etter to reserve the whole /64 for each p2p inter-router link. =A0 There are conflicting recommendations and are not giving me the right direc= tion e.g.: RFC 4291 states: "For all unicast addresses, except those that start with t= he binary value 000, Interface IDs are required to be 64 bits long and to b= e constructed in Modified EUI-64 format." =A0 RFC 5375 states: "126-bit subnet prefixes are typically used for point-to-p= oint links similar to a the IPv4 address-conservative /30 allocation for po= int-to-point links.=A0 The usage of this subnet address length does not lea= d to any considerations beyond those discussed earlier in this section, par= ticularly those related to the 'u' and 'g' bits (see B.2.4.) For /128 assignment..... it is recommended to take the 'u' and 'g' bits int= o consideration and to make sure that there is no overlap with any of the f= ollowing well-known addresses: =A0=A0 o=A0 Subnet Router Anycast Address =A0=A0 o=A0 Reserved Subnet Anycast Address =A0=A0 o=A0 Addresses used by Embedded-RP =A0=A0 o=A0 ISATAP Addresses" =A0 My main concern is the following: =A0 Some standards "assume" that the lower-order 64-bits of an IPv6 address are= reserved for host addresses (following from an EUI-64 format) and you see = some specific addresses in those lower order 64 bits reserved for specific = purposes (router anycast, embedded IPv6 RP, ISATAP etc). This gives indicat= ion that in future if vendors continue on with this assumption of 64 bits h= ost space and dont take into account that there may be deployments out ther= e where operators / carriers have chosen to use /126 or /127s on their p2p = inter-router links from the same /64 subnets=A0- this could lead to major i= ssues for both the operators and their end-customers. =A0 I suppose bodies like IETF all need to ensure that there are definitive gui= delines around addressing architectures so that future implementations of p= rocotol stacks and features donot overlap with bits in the IPv6 address spa= ce that could potentially be used on p2p inter-router links (i.e. there cou= ld be address assignments done based on subnet prefixes longer than /64 on = p2p links) and obviously if some implementation in future uses the bits fro= m that space, it would become a big challenge for operators and their custo= mers to re-address their p2p inter-router links. =A0 In summary we need clear guidelines on the following: - For IPv6 implementation on strictly p2p (inter-router links) and for devi= ce Loopbacks, we can use /127 and /128 respectively but are required to res= erve the whole=A0corresponding /64 for each of the p2p links (and loopbacks= ) i.e. a seperate /64 needs to be reserved for each p2p and loopback. OR - For IPv6 implementation on strictly p2p (inter-router links) and for devi= ce Loopbacks, we can use /127 and /128 respectively and are NOT reuqired to= reserve the whole corresponding /64 for each of the p2p links (and loopbac= ks) i.e. for example multiple p2p links can be assigned /127 from the same = /64 - this has implication that any future implementation of protocol/stack= needs to be careful not to "assume" and=A0reserve some or all of the=A0low= er-64 bits in IPv6 address for its implementation. =A0 =A0 Thanks Usman Email: osmankh@yahoo.com =A0 --1833503604-2009576388-1348211033=:52674 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
 
I am one of the many Network Engineers/architects that are today on th= e verge of assigning IPv6 addressing in their core networks.
There are two points that I would like to open a debate on and re= ally looking for some substantial reasoning and logic on.
 
And the points are:
 
Q1: "What is the IETF best-practice / recommendation for assigning IPv= 6 addressing to strictly point-to-point links where we know there will neve= r be more than one device on each end of the link for the foreseeable futur= e"
 
Q2: "What is the IETF best practice / recommendation for assigning IPv= 6 addressing for Loopback interfaces on routers"
I have gone through some RFCs (RFC 4291, RFC 5375, RFC 3627, RFC 3177 = / 6177 and RFC 6164)
 
As a network engineer with IPv4 and some IPv6 background, I am incline= d to use /127 addressing on strictly point to point links and /128 for Loop= backs - but after discussion with peers in the industry have learnt that al= though the recommendations are to use /127 for p2p and /128 for Loopbacks, = its better to reserve the whole /64 for each p2p inter-router link.
 
There are conflicting recommendations and are not giving me the right = direction e.g.:
RFC 4291 states: "For all unicast addresses, except those that start w= ith the binary value 000, Interface IDs are required to be 64 bits long and= to be constructed in Modified EUI-64 format."
 
RFC 5375 states= : "126-bit subnet prefixes are typically used for point-to-point links simi= lar to a the IPv4 address-conservative /30 allocation for point-to-point li= nks.  The usage of this subnet address length does not lead to any con= siderations beyond those discussed earlier in this section, particularly th= ose related to the 'u' and 'g' bits (see B.2.4.)
For /128 assignment....= . it is recommended to take the 'u' and 'g' bits into consideration and to = make sure that there is no overlap with any of the following well-known add= resses:
   o  Subnet Router Anycast Address
   o  Reserved Subnet Anycast Address
   o  Addresses used by Embedded-RP
   o  ISATAP Addresses"
 
My main concern is= the following:
 
Some standards "assume" that the lower-order 64-bits of an IPv6 addres= s are reserved for host addresses (following from an EUI-64 format) and you= see some specific addresses in those lower order 64 bits reserved for spec= ific purposes (router anycast, embedded IPv6 RP, ISATAP etc). This gives in= dication that in future if vendors continue on with this assumption of 64 b= its host space and dont take into account that there may be deployments out= there where operators / carriers have chosen to use /126 or /127s on their= p2p inter-router links from the same /64 subnets - this could lead to= major issues for both the operators and their end-customers.
 
= I suppose bodies like IETF all need to ensure that there are definitive gui= delines around addressing architectures so that future implementations of p= rocotol stacks and features donot overlap with bits in the IPv6 address spa= ce that could potentially be used on p2p inter-router links (i.e. there could be address assignments done based on subnet prefixes longer th= an /64 on p2p links) and obviously if some implementation in future uses th= e bits from that space, it would become a big challenge for operators and t= heir customers to re-address their p2p inter-router links.
 
In = summary we need clear guidelines on the following:

- For IPv6 implem= entation on strictly p2p (inter-router links) and for device Loopbacks, we = can use /127 and /128 respectively but are required to reserve the whole&nb= sp;corresponding /64 for each of the p2p links (and loopbacks) i.e. a seper= ate /64 needs to be reserved for each p2p and loopback.

OR

- = For IPv6 implementation on strictly p2p (inter-router links) and for device= Loopbacks, we can use /127 and /128 respectively and are NOT reuqired to r= eserve the whole corresponding /64 for each of the p2p links (and loopbacks= ) i.e. for example multiple p2p links can be assigned /127 from the same /64 - this has implication that any future implementation of protocol= /stack needs to be careful not to "assume" and reserve some or all of = the lower-64 bits in IPv6 address for its implementation.
 
 
Thanks
Usman
--1833503604-2009576388-1348211033=:52674-- From internet-drafts@ietf.org Fri Sep 21 04:08:35 2012 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 CB5FA21F8783; Fri, 21 Sep 2012 04:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhA4b5Il9JkL; Fri, 21 Sep 2012 04:08:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DE421F8734; Fri, 21 Sep 2012 04:08:35 -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-opt-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120921110835.27684.1581.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 04:08:35 -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: Fri, 21 Sep 2012 11:08:35 -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 IET= F. Title : Distributing Address Selection Policy using DHCPv6 Author(s) : Arifumi Matsumoto Tomohiro Fujisaki Tim Chown Filename : draft-ietf-6man-addr-select-opt-06.txt Pages : 10 Date : 2012-09-21 Abstract: RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 6724 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus control the address selection behavior of nodes in their site. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-addr-select-opt-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Sep 21 06:37:11 2012 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 6665721F881B; Fri, 21 Sep 2012 06:37:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7txC0h1praNX; Fri, 21 Sep 2012 06:37:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E061A21F87F2; Fri, 21 Sep 2012 06:37:10 -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-uri-zoneid-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120921133710.18778.66640.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 06:37:10 -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: Fri, 21 Sep 2012 13:37:11 -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 IET= F. Title : Representing IPv6 Zone Identifiers in Address Literals a= nd Uniform Resource Identifiers Author(s) : Brian Carpenter Stuart Cheshire Robert M. Hinden Filename : draft-ietf-6man-uri-zoneid-04.txt Pages : 9 Date : 2012-09-21 Abstract: This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates RFC 3986 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-uri-zoneid-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Fri Sep 21 06:40:13 2012 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 62CCC21F870B for ; Fri, 21 Sep 2012 06:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBCmGGfwZ943 for ; Fri, 21 Sep 2012 06:40:12 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B91A621F8705 for ; Fri, 21 Sep 2012 06:40:12 -0700 (PDT) Received: by iec9 with SMTP id 9so6214369iec.31 for ; Fri, 21 Sep 2012 06:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=yPS6caTWje+o5tpZPPjxZS1UnxTAt7c6RBWbyDAcx7A=; b=Nu33w+Ry5DOdoh/ZU4YHn45GcKQK/tjOnbAOxaM3+4bEFUUlXY+AxpbqF+BgPLtdvH 1El5VdAc+FzghpQXYtS9TTmAVu40YoVYskx3PHyTLh1uV2dFGwb8tw5E+t2VMtvPZ3lD BeIdUtYyuBcR84ZY/04cW8mEhP8MznLMQt+fyUrZy72ZdkAVdbg9lEr3yazWR0btI39F Im87aoC0FG0XaCSZU6bIuVqRLKATcJ+4t6tMLwUORHzzvCKN+B4Oiw5i03VnCa2KC2ev OSBjHxV1a7cfxo/zk1Yj4W8dcTBp7KKyxocObgRIALfL6Q0Nda8e4pk7B5xBSPGowUDi gAVg== Received: by 10.43.9.3 with SMTP id ou3mr3908419icb.14.1348234812100; Fri, 21 Sep 2012 06:40:12 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id ce10sm1645245igb.1.2012.09.21.06.40.09 (version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 06:40:10 -0700 (PDT) Message-ID: <505C6E42.80709@gmail.com> Date: Fri, 21 Sep 2012 14:40:18 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-04.txt] 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: Fri, 21 Sep 2012 13:40:13 -0000 This quick update adds Stuart Cheshire as a co-author, since he proposed the final compromise. Ole, over to you. Brian -------- Original Message -------- Subject: I-D Action: draft-ietf-6man-uri-zoneid-04.txt Date: Fri, 21 Sep 2012 06:37:10 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: ipv6@ietf.org 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. Title : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers Author(s) : Brian Carpenter Stuart Cheshire Robert M. Hinden Filename : draft-ietf-6man-uri-zoneid-04.txt Pages : 9 Date : 2012-09-21 Abstract: This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address. It updates RFC 3986 accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-uri-zoneid-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From osmankh@yahoo.com Fri Sep 21 07:16:11 2012 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 B8FDD21F883A for ; Fri, 21 Sep 2012 07:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t+KjkAnjbTJ for ; Fri, 21 Sep 2012 07:16:10 -0700 (PDT) Received: from nm18-vm0.bullet.mail.ac4.yahoo.com (nm18-vm0.bullet.mail.ac4.yahoo.com [98.139.53.210]) by ietfa.amsl.com (Postfix) with SMTP id 7CEFF21F8831 for ; Fri, 21 Sep 2012 07:16:10 -0700 (PDT) Received: from [98.139.52.189] by nm18.bullet.mail.ac4.yahoo.com with NNFMP; 21 Sep 2012 14:16:07 -0000 Received: from [98.139.52.139] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 21 Sep 2012 14:16:07 -0000 Received: from [127.0.0.1] by omp1022.mail.ac4.yahoo.com with NNFMP; 21 Sep 2012 14:16:07 -0000 X-Yahoo-Newman-Id: 349646.37327.bm@omp1022.mail.ac4.yahoo.com Received: (qmail 3287 invoked from network); 21 Sep 2012 14:16:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=XtMv/UL1jVWK/kLGGLN1nfx/OmsiyO8WJ91zzL+mOE0c1j/rWshdTzo68QkYfQx8fLGhRttoNDViSXJy8AQdkB/N/MRelPbai/iATYG0xM23kEMYGNtzDbyne5l2kA+no2GhpB+ZsECJxqcpF9n+g2ub19gWw5Ujm2sxQe25AGg= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348236967; bh=nKIbnmhQMIfAlyCdlZ9VxETUqAoOZwP5J93i9Rsc3ns=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=LsxLsKUdluJTk7CmPkZ4hVBbu6TyWg+YZ257AiohWMgaGO/ndVyUtkXVMejfLvEMWajw2y1OFNCZGiegXTJdIQoFk9Qr/HFsYpttPsgY/7Bic1lxP1eEj2RWca50K0VnVCM2UfSqTX/BkbvBc9kHADe73YCqdEAd6OO4mROBJ1c= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: m_V6OfkVM1kVsWreTmYegmNQFtXsHhQGJf.DGIvSDWsCJFM bBk9isUurT_uJP1GyNwe26FGCoXAKHbri1cNG6GkOrx2mo9rNhDqY5eanThm sNKCPPhaYqN5VUeqTd0AOZOfTLattz2X6M.HpDgx0DuVXH7Gu3SFMmdcN9JC alJGjG6KFVWrIURYiXFr4byLFVhu2vemjGa0TDoUY1GgtrId2ldMuig5HKzw caFokbLLD7HDJe2W5Js2xBP0oKBPOw.4CB6_l2G7CucHjH3tueFRb86DjkRB srAsvZe9n7mi8Mm.pQzd4k1Z3fWHb5MyOGPScGjx46kYABWbU13xa8ms3INr IGBe_diI5GkWiHsyjYrWrAcAhQqXdTjrLnYTNZClvfKAaQ.tnHo33Owtslk7 DUq53xpKvv9mUnFH9RxEagUTJ6Fqvk30ibWNltxelmrGCBGmfLov31RA- X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- Received: from [192.168.1.66] (osmankh@27.32.72.22 with xymcookie) by smtp116-mob.biz.mail.ac4.yahoo.com with SMTP; 21 Sep 2012 07:16:06 -0700 PDT References: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-553D030C-3F71-452D-911A-6CDC18E80D36 Content-Transfer-Encoding: 7bit Message-Id: <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.com> X-Mailer: iPhone Mail (9B206) From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Date: Sat, 22 Sep 2012 00:16:04 +1000 To: "trejrco@gmail.com" 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: Fri, 21 Sep 2012 14:16:11 -0000 --Apple-Mail-553D030C-3F71-452D-911A-6CDC18E80D36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the feedback. I just want to confirm something. You wrote:=20 "If you choose to do this, it is further recommended that you reserve the en= tire /64 so that - if needed in the future - you can expand this configurati= on _without_ a major renumbering event." This is the essence of what I want the IETF to put in one of its address rec= ommendation RFCs because I have yet to see an RFC that says when you assign a= /127 to a p2p link, you should/must reserve the whole parent /64 for that p= 2p link also. Without this stated clearly there is likely to be some instances where reade= rs interpret it the wrong way and end up assigning multiple p2p links with /= 127 subnets from a single given /64 and end up having to re-address their ne= twork in future when/if future standards use lower order 64 bits for special= purposes. Also you didn't talk about loopbacks at all. IMO any single loopback although a /128 should also have the whole parent /6= 4 assigned to it because the issues with not doing that are pretty much the s= ame as for p2p links What do you think? Regards, Usman Sent from my iPhone On 21/09/2012, at 10:02 PM, TJ wrote: > Right - effectively, the standard says the best answer is to use /64s ever= ywhere. FWLIW, I agree :). >=20 > WRT Point-to-point links (only, any multi-access link REALLY should be a /= 64): For those that insist on using something else, it is loosely accepted t= hat a /127 can work (as long as the platform doesn't do the Subnet Router An= ycast ridiculousness). This has the benefit of leaving no unused addresses o= n link and avoiding a potential ping-pong attack. If you choose to do this,= it is further recommended that you reserve the entire /64 so that - if need= ed in the future - you can expand this configuration _without_ a major renum= bering event. >=20 >=20 > HTH! > /TJ >=20 >=20 > On Fri, Sep 21, 2012 at 3:03 AM, Usman Latif wrote: > Hi, > =20 > I am one of the many Network Engineers/architects that are today on the ve= rge of assigning IPv6 addressing in their core networks. > There are two points that I would like to open a debate on and really look= ing for some substantial reasoning and logic on. > =20 > And the points are: > =20 > Q1: "What is the IETF best-practice / recommendation for assigning IPv6 ad= dressing to strictly point-to-point links where we know there will never be m= ore than one device on each end of the link for the foreseeable future" > =20 > Q2: "What is the IETF best practice / recommendation for assigning IPv6 ad= dressing for Loopback interfaces on routers" > I have gone through some RFCs (RFC 4291, RFC 5375, RFC 3627, RFC 3177 / 61= 77 and RFC 6164) > =20 > As a network engineer with IPv4 and some IPv6 background, I am inclined to= use /127 addressing on strictly point to point links and /128 for Loopbacks= - but after discussion with peers in the industry have learnt that although= the recommendations are to use /127 for p2p and /128 for Loopbacks, its bet= ter to reserve the whole /64 for each p2p inter-router link. > =20 > There are conflicting recommendations and are not giving me the right dire= ction e.g.: > RFC 4291 states: "For all unicast addresses, except those that start with t= he binary value 000, Interface IDs are required to be 64 bits long and to be= constructed in Modified EUI-64 format." > =20 > RFC 5375 states: "126-bit subnet prefixes are typically used for point-to-= point links similar to a the IPv4 address-conservative /30 allocation for po= int-to-point links. The usage of this subnet address length does not lead t= o any considerations beyond those discussed earlier in this section, particu= larly those related to the 'u' and 'g' bits (see B.2.4.) > For /128 assignment..... it is recommended to take the 'u' and 'g' bits in= to consideration and to make sure that there is no overlap with any of the f= ollowing well-known addresses: > o Subnet Router Anycast Address > o Reserved Subnet Anycast Address > o Addresses used by Embedded-RP > o ISATAP Addresses" > =20 > My main concern is the following: > =20 > Some standards "assume" that the lower-order 64-bits of an IPv6 address ar= e reserved for host addresses (following from an EUI-64 format) and you see s= ome specific addresses in those lower order 64 bits reserved for specific pu= rposes (router anycast, embedded IPv6 RP, ISATAP etc). This gives indication= that in future if vendors continue on with this assumption of 64 bits host s= pace and dont take into account that there may be deployments out there wher= e operators / carriers have chosen to use /126 or /127s on their p2p inter-r= outer links from the same /64 subnets - this could lead to major issues for b= oth the operators and their end-customers. > =20 > I suppose bodies like IETF all need to ensure that there are definitive gu= idelines around addressing architectures so that future implementations of p= rocotol stacks and features donot overlap with bits in the IPv6 address spac= e that could potentially be used on p2p inter-router links (i.e. there could= be address assignments done based on subnet prefixes longer than /64 on p2p= links) and obviously if some implementation in future uses the bits from th= at space, it would become a big challenge for operators and their customers t= o re-address their p2p inter-router links. > =20 > In summary we need clear guidelines on the following: >=20 > - For IPv6 implementation on strictly p2p (inter-router links) and for dev= ice Loopbacks, we can use /127 and /128 respectively but are required to res= erve the whole corresponding /64 for each of the p2p links (and loopbacks) i= .e. a seperate /64 needs to be reserved for each p2p and loopback. >=20 > OR >=20 > - For IPv6 implementation on strictly p2p (inter-router links) and for dev= ice Loopbacks, we can use /127 and /128 respectively and are NOT reuqired to= reserve the whole corresponding /64 for each of the p2p links (and loopback= s) i.e. for example multiple p2p links can be assigned /127 from the same /6= 4 - this has implication that any future implementation of protocol/stack ne= eds to be careful not to "assume" and reserve some or all of the lower-64 bi= ts in IPv6 address for its implementation. > =20 > =20 > Thanks > Usman > Email: osmankh@yahoo.com > =20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 --Apple-Mail-553D030C-3F71-452D-911A-6CDC18E80D36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks for the feedba= ck.
I just want to confirm something.

You= wrote: 
"If you choose to do this, it is further recommended t= hat you reserve the entire /64 so that - if needed in the future - you can e= xpand this configuration _without_ a major renumbering event."
<= div>This is the essence of what I want the IETF to put i= n one of its address recommendation RFCs because I have yet to see an RFC th= at says when you assign a /127 to a p2p link, you should/must reserve the wh= ole parent /64 for that p2p link also.

Witho= ut this stated clearly there is likely to be some instances where readers in= terpret it the wrong way and end up assigning multiple p2p links with /127 s= ubnets from a single given /64 and end up having to re-address their network= in future when/if future standards use lower order 64 bits for special purp= oses.

Also you didn't talk about loopbacks at all.<= /div>

IMO any single loopback although a /128 should also= have the whole parent /64 assigned to it because the issues with not doing t= hat are pretty much the same as for p2p links

What d= o you think?

Regards,
Usman
Sent from my iPhone

On 21/09/2012, at 10:02 PM, TJ= <trejrco@gmail.com> wrote:
Right - e= ffectively, the standard says the best answer is to use /64s everywhere. &nb= sp;FWLIW, I agree :).

WRT Point-to-point links (only, any= multi-access link REALLY should be a /64): For those that insist on using s= omething else, it is loosely accepted that a /127 can work (as long as the p= latform doesn't do the Subnet Router Anycast ridiculousness).  This has= the benefit of leaving no unused addresses on link and avoiding a potential= ping-pong attack.  If you choose to do this, it is further recommended= that you reserve the entire /64 so that - if needed in the future - you can= expand this configuration _without_ a major renumbering event.


HTH!
/TJ


On Fri, Sep 21, 2012 at 3:03 AM, Usman La= tif <osmankh@yahoo.com> wrote:
Hi,
 
I am one of the many Network Engineers/architects that are today on the= verge of assigning IPv6 addressing in their core networks.
There are two points that I would like to open a debate on and rea= lly looking for some substantial reasoning and logic on.
 
And the points are:
 
Q1: "What is the IETF best-practice / recommendation for assigning IPv6= addressing to strictly point-to-point links where we know there will never b= e more than one device on each end of the link for the foreseeable future"
 
Q2: "What is the IETF best practice / recommendation for assigning IPv6= addressing for Loopback interfaces on routers"
I have gone through some RFCs (RFC 4291, RFC 5375, RFC 3627, RFC 3177 /= 6177 and RFC 6164)
 
As a network engineer with IPv4 and some IPv6 background, I am inclined= to use /127 addressing on strictly point to point links and /128 for Loopba= cks - but after discussion with peers in the industry have learnt that altho= ugh the recommendations are to use /127 for p2p and /128 for Loopbacks, its b= etter to reserve the whole /64 for each p2p inter-router link.
 
There are conflicting recommendations and are not giving me the right d= irection e.g.:
RFC 4291 states: "For all unicast addresses, except those that start wi= th the binary value 000, Interface IDs are required to be 64 bits long and t= o be constructed in Modified EUI-64 format."
 
RFC 5375 states: "= 126-bit subnet prefixes are typically used for point-to-point links similar t= o a the IPv4 address-conservative /30 allocation for point-to-point links.&n= bsp; The usage of this subnet address length does not lead to any considerat= ions beyond those discussed earlier in this section, particularly those rela= ted to the 'u' and 'g' bits (see B.2.4.)
For /128 assignment..... it is recommended to take the 'u' and 'g' bits into= consideration and to make sure that there is no overlap with any of the fol= lowing well-known addresses:
   o  Subnet Router Anycast Address
   o  Reserved Subnet Anycast Address
   o  Addresses used by Embedded-RP
   o  ISATAP Addresses"
 
My main concern is t= he following:
 
Some standards "assume" that the lower-order 64-bits of an IPv6 address= are reserved for host addresses (following from an EUI-64 format) and you s= ee some specific addresses in those lower order 64 bits reserved for specifi= c purposes (router anycast, embedded IPv6 RP, ISATAP etc). This gives indica= tion that in future if vendors continue on with this assumption of 64 bits h= ost space and dont take into account that there may be deployments out there= where operators / carriers have chosen to use /126 or /127s on their p2p in= ter-router links from the same /64 subnets - this could lead to major i= ssues for both the operators and their end-customers.
 
I suppose bodies like IETF all need to ensure that there are defin= itive guidelines around addressing architectures so that future implementati= ons of procotol stacks and features donot overlap with bits in the IPv6 addr= ess space that could potentially be used on p2p inter-router links (i.e. there could be address assignments done based on subnet prefixes longer tha= n /64 on p2p links) and obviously if some implementation in future uses the b= its from that space, it would become a big challenge for operators and their= customers to re-address their p2p inter-router links.
 
In summary we need clear guidelines on the following:

- For= IPv6 implementation on strictly p2p (inter-router links) and for device Loo= pbacks, we can use /127 and /128 respectively but are required to reserve th= e whole corresponding /64 for each of the p2p links (and loopbacks) i.e= . a seperate /64 needs to be reserved for each p2p and loopback.

OR

- For IPv6 implementation on strictly p2p (inter-router links)= and for device Loopbacks, we can use /127 and /128 respectively and are NOT= reuqired to reserve the whole corresponding /64 for each of the p2p links (= and loopbacks) i.e. for example multiple p2p links can be assigned /127 from= the same /64 - this has implication that any future implementation of protocol/= stack needs to be careful not to "assume" and reserve some or all of th= e lower-64 bits in IPv6 address for its implementation.
 
 
Thanks
Usman
 

-----------------------------= ---------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


= --Apple-Mail-553D030C-3F71-452D-911A-6CDC18E80D36-- From trejrco@gmail.com Fri Sep 21 07:30:13 2012 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 C52FF21F8688 for ; Fri, 21 Sep 2012 07:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFL+JvcNMYEp for ; Fri, 21 Sep 2012 07:30:13 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC8A821F85F7 for ; Fri, 21 Sep 2012 07:30:05 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so949267wgb.13 for ; Fri, 21 Sep 2012 07:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=4dbdAqtkG1GyUREkYvyLdB0RS54xJkQJB5rSWAiuEX0=; b=pxs5mlP/+jUVELLentSIvzpLnJQAPsfV/gXoKc0h2TWK/wZSEMikkLVa2K6SUmp+cX 2vRcGveIa1eat/8ukr5NdYiSaWPTEAuGxev2zwCqmjLQqjR2TLh/GyntsGjAOiphqnY7 z0PFSPfaGS6N/2HZBs7iIt4psYKwXJf8ZdDQqKN1jnzibSS8KlqrzK0AZFpzdMaFgv6h l5uxDs8IiTLDqvjQTjedkzAwAd7zTioondMHAWz+zvkzFtmpXVl9/N9M0dRHdRFZYtAv op4jkT20R8j+72nb5T8ITJlqgYDXd7s+F/re1iq128TlKBXsl6UV/7hxDWHMGiQLA/zA RfnA== Received: by 10.180.8.40 with SMTP id o8mr4903468wia.9.1348237804850; Fri, 21 Sep 2012 07:30:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.28.161 with HTTP; Fri, 21 Sep 2012 07:29:44 -0700 (PDT) In-Reply-To: <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.com> References: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.com> From: TJ Date: Fri, 21 Sep 2012 10:29:44 -0400 Message-ID: Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks To: "ipv6@ietf.org" Content-Type: multipart/alternative; boundary=bcaec555503c6e4e3b04ca371316 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: trejrco@gmail.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:30:13 -0000 --bcaec555503c6e4e3b04ca371316 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 21, 2012 at 10:16 AM, Usman Latif wrote: > Thanks for the feedback. > I just want to confirm something. > > You wrote: > "If you choose to do this, it is further recommended that you reserve the > entire /64 so that - if needed in the future - you can expand this > configuration _without_ a major renumbering event." > > This is the essence of what I want the IETF to put in one of its address > recommendation RFCs because I have yet to see an RFC that says when you > assign a /127 to a p2p link, you should/must reserve the whole parent /64 > for that p2p link also. > > Without this stated clearly there is likely to be some instances where > readers interpret it the wrong way and end up assigning multiple p2p links > with /127 subnets from a single given /64 and end up having to re-address > their network in future when/if future standards use lower order 64 bits > for special purposes. > Right, each PtP link should have it's own /64 assigned. It should also be so-configured, but if you choose to alter that something else (e.g. - a /127) may be configured. But with that specific /64 still reserved per PtP link! > Also you didn't talk about loopbacks at all. > > IMO any single loopback although a /128 should also have the whole parent > /64 assigned to it because the issues with not doing that are pretty much > the same as for p2p links > Correct, in fact - I intentionally excluded them :). I would say a single /64 per site (or whatever demarcation / term you choose to use) should be reserved for the purpose of assigning /128s to loopbacks. Not a /64 per loopback, a /64 per ~site to cover all of the loopbacks within that ~site. *I presume 18BB loopback addresses per ~site is sufficient? ;)* /TJ --bcaec555503c6e4e3b04ca371316 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 21, 2012 at 10:16 AM, Usman Latif <osmankh@yahoo.com> wrote:
Thanks for the feedback.
I jus= t want to confirm something.

You= wrote:=A0
"If you choose to do this, it is further re= commended that you reserve the entire /64 so that - if needed in the future= - you can expand this configuration _without_ a major renumbering event.&q= uot;

This is the essence of what I = want the IETF to put in one of its address recommendation RFCs because I ha= ve yet to see an RFC that says when you assign a /127 to a p2p link, you sh= ould/must reserve the whole parent /64 for that p2p link also.

Without this stated clearly there is likely to be some = instances where readers interpret it the wrong way and end up assigning mul= tiple p2p links with /127 subnets from a single given /64 and end up having= to re-address their network in future when/if future standards use lower o= rder 64 bits for special purposes.

Right, each PtP link should ha= ve it's own /64 assigned. =A0
It should also be so-configured= , but if you choose to alter that something else (e.g. - a /127) may be con= figured. =A0
But with that specific /64 still reserved per PtP link!

=
=A0
Also you didn't talk about loopbacks at all.

<= div>IMO any single loopback although a /128 should also have the whole pare= nt /64 assigned to it because the issues with not doing that are pretty muc= h the same as for p2p links

Correct, in fact - I intention= ally excluded them :).
I would say a single /64 per site (or what= ever demarcation / term you choose to use) should be reserved for the purpo= se of assigning /128s to loopbacks. =A0Not a /64 per loopback, a /64 per ~s= ite to cover all of the loopbacks within that ~site. =A0
I presume 18BB loopback addresses per ~site is sufficient? ;)
<= div>

/TJ
--bcaec555503c6e4e3b04ca371316-- From wesley.george@twcable.com Fri Sep 21 12:24:44 2012 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 3286121E8042 for ; Fri, 21 Sep 2012 12:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7sjsqNoJ-3o for ; Fri, 21 Sep 2012 12:24:43 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4C62D21E8039 for ; Fri, 21 Sep 2012 12:24:42 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.80,464,1344225600"; d="scan'208";a="424094864" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 Sep 2012 15:22:32 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Fri, 21 Sep 2012 15:23:19 -0400 From: "George, Wes" To: Usman Latif , "trejrco@gmail.com" Date: Fri, 21 Sep 2012 15:23:18 -0400 Subject: RE: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Thread-Topic: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Thread-Index: Ac2YA8FEcJugmX3FQcCrRj1OrHI1LgAGPN4A Message-ID: <2671C6CDFBB59E47B64C10B3E0BD59235F961497@PRVPEXVS15.corp.twcable.com> References: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.com> In-Reply-To: <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.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 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: Fri, 21 Sep 2012 19:24:44 -0000 UmVzcG9uZGluZyB0byAgYSBjb3VwbGUgb2YgZGlmZmVyZW50IHRoaW5ncyBiZWxvdyBpbmxpbmUg d2l0aCBbV0VHXQ0KDQpGcm9tOiBpcHY2LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHY2LWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBVc21hbiBMYXRpZg0KPj4iSWYgeW91IGNob29z ZSB0byBkbyB0aGlzLCBpdCBpcyBmdXJ0aGVyIHJlY29tbWVuZGVkIHRoYXQgeW91IHJlc2VydmUg dGhlIGVudGlyZSAvNjQgc28gdGhhdCAtIGlmIG5lZWRlZCBpbiB0aGUgZnV0dXJlIC0geW91IGNh biBleHBhbmQgdGhpcyBjb25maWd1cmF0aW9uIF93aXRob3V0XyBhIG1ham9yIHJlbnVtYmVyaW5n IGV2ZW50LiINCg0KW1dFR10gSeKAmW0gbm90IHN1cmUgdGhhdCByZW51bWJlcmluZyBQMlAgbGlu a3MgaXMgY29tcGFyYXRpdmVseSBoYXJkZXIgdGhhbiBjaGFuZ2luZyB0aGUgc3VibmV0IG1hc2ss IG5vciB3b3VsZCBJIGNoYXJhY3Rlcml6ZSBvbmUgYXMgYSBtYWpvciByZW51bWJlcmluZyBldmVu dCBhbmQgdGhlIG90aGVyIG5vdC4gWW91IHN0aWxsIGhhdmUgdG8gdG91Y2ggYWxsIGxpbmtzLCBh bGwgZGV2aWNlcywgdGhlIG9ubHkgZGlmZmVyZW5jZSB3b3VsZCBiZSBmb3IgdGhpbmdzIHRoYXQg YXJlIGNvbmZpZ3VyZWQgdG8gdXNlIHRoZSBsaW5rIElQIHRvIGNvbW11bmljYXRlIHdpdGggdGhl IHJvdXRlciwgYW5kIGEgbG90IG9mIHRob3NlIGNhbiBiZSBtYW5hZ2VkIHVzaW5nIG1ha2UgYmVm b3JlIGJyZWFrIHByb3Zpc2lvbmluZy4gIFRoZXJlIGFyZSBzZXZlcmFsIElFVEYgZG9jdW1lbnRz IChhbmQgYSB3aG9sZSBXRykgY292ZXJpbmcgaG93IHRvIG1hbmFnZSByZW51bWJlcmluZyBpbiBh IG1vcmUgcGFpbmxlc3MgZmFzaGlvbiwgYW5kIHRoaXMgaXMgb25lIHRoYXQgaXMgcHJldHR5IHN0 cmFpZ2h0Zm9yd2FyZC4NCg0KPj5UaGlzIGlzIHRoZSBlc3NlbmNlIG9mIHdoYXQgSSB3YW50IHRo ZSBJRVRGIHRvIHB1dCBpbiBvbmUgb2YgaXRzIGFkZHJlc3MgcmVjb21tZW5kYXRpb24gUkZDcyBi ZWNhdXNlIEkgaGF2ZSB5ZXQgdG8gc2VlIGFuIFJGQyB0aGF0IHNheXMgd2hlbiB5b3UgYXNzaWdu IGEgLzEyNyB0byBhIHAycCBsaW5rLCB5b3Ugc2hvdWxkL211c3QgcmVzZXJ2ZSB0aGUgd2hvbGUg cGFyZW50IC82NCBmb3IgdGhhdCBwMnAgbGluayBhbHNvLg0KDQpbV0VHXSBJIHRoaW5rIHRoYXQg cGFydCBvZiB0aGUgcmVhc29uIHlvdSBoYXZlbuKAmXQgc2VlbiB0aGF0IFJGQyBpcyB0aGF0IHRo ZXJl4oCZcyBhbiBhcmd1bWVudCB0byBiZSBtYWRlIHRvIHRoZSBjb250cmFyeSBhcyB3ZWxsIOKA kyB0aGVyZeKAmXMgc29tZSB2YWx1ZSBmcm9tIGEgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50IGFu ZCBvcGVyYXRpb25hbCBwZXJzcGVjdGl2ZSBpbiBiZWluZyBhYmxlIHRvIHVzZSBvbmUgbGluZSBv ZiBjb25maWcgdG8gbWFuYWdlIHRoaW5ncyBsaWtlIHJvdXRlIGFnZ3JlZ2F0aW9uLCBmaWx0cmF0 aW9uLCBtYW5hZ2VtZW50IHRvb2xzIGFjY2VzcywgYWNjZXNzIGxpc3RzLCBldGMuICBZZXMsIHlv dSBjYW4gZG8gdGhhdCB3aXRoIGEgbGFyZ2VyIGJsb2NrIChlLmcuIGFsbG9jYXRlIHRoZSB0b3Ag LzQ4IG9mIHlvdXIgLzMyIGZvciBpbmZyYXN0cnVjdHVyZSkgYnV0IHRoYXQgYWRkcyBhIGxvdCBv ZiBhZGRyZXNzZXMgdG8gYmUgcGVybWl0dGVkIHRocm91Z2ggdGhlIGZpbHRlcnMgdGhhdCBzaW1w bHkgYXJlbuKAmXQgbmVjZXNzYXJ5IG5vciB3aWxsIGV2ZXIgYmUgdXNlZCwgYW5kIGV4cG9zZXMg eW91IHRvIG90aGVyIGF0dGFjayB2ZWN0b3JzIGluIGEgd2F5IHRoYXQgaXNu4oCZdCBuZWNlc3Nh cmlseSBqdXN0aWZpYWJsZSwgYXQgbGVhc3QgSU1PLiBUaGlzIGlzIHZlcnkgbXVjaCBhIGNhc2Ug b2YgWU1NViwgc28gSeKAmW0gbm90IHN1cmUgdGhhdCDigJxyZXNlcnZlIHRoZSB3aG9sZSAvNjQg Zm9yIGVhY2ggLzEyN+KAnSBpcyB1bml2ZXJzYWxseSBzb21ldGhpbmcgd2UgY291bGQgb3Igc2hv dWxkIHJlY29tbWVuZCwgZXNwZWNpYWxseSBpZiBpdOKAmXMgbWFpbmx5IGEg4oCcanVzdCBpbiBj YXNlLCB5b3UgbmV2ZXIga25vdyB3aGF0IGNyYXppbmVzcyB0aG9zZSBwcm90b2NvbCB3b25rcyBp biBJRVRGIG1pZ2h0IGNvbWUgdXAgd2l0aCB0aGF0IHdvdWxkIGJyZWFrIGl0IGluIHRoZSBmdXR1 cmUuLi5tdW1ibGUgbXVtYmxl4oCm4oCdIGtpbmQgb2YgcmVhc29uLg0KDQo+PldpdGhvdXQgdGhp cyBzdGF0ZWQgY2xlYXJseSB0aGVyZSBpcyBsaWtlbHkgdG8gYmUgc29tZSBpbnN0YW5jZXMgd2hl cmUgcmVhZGVycyBpbnRlcnByZXQgaXQgdGhlIHdyb25nIHdheSBhbmQgZW5kIHVwIGFzc2lnbmlu ZyBtdWx0aXBsZSBwMnAgbGlua3Mgd2l0aCAvMTI3IHN1Ym5ldHMgZnJvbSBhIHNpbmdsZSBnaXZl biAvNjQgYW5kIGVuZCB1cCBoYXZpbmcgdG8gcmUtYWRkcmVzcyB0aGVpciBuZXR3b3JrIGluIGZ1 dHVyZSB3aGVuL2lmIGZ1dHVyZSBzdGFuZGFyZHMgdXNlIGxvd2VyIG9yZGVyIDY0IGJpdHMgZm9y IHNwZWNpYWwgcHVycG9zZXMuDQoNCltXRUddIEdpdmVuIHRoZSBmYWN0IHRoYXQgdGhlcmUgaXMg YSBzdGFuZGFyZCB0aGF0IGRvY3VtZW50cyB0aGUgdXNlIG9mIGEgLzEyNyBmb3IgUDJQIGxpbmtz ICg2MTY0KSwgZnV0dXJlIHN0YW5kYXJkcyBjYW7igJl0IHVzZSBsb3dlciBvcmRlciA2NCBiaXRz IGZvciBzcGVjaWFsIHB1cnBvc2VzIHdpdGhvdXQgY29uc2lkZXJpbmcgdGhlIHBvdGVudGlhbCBp bXBhY3QgdG8gdGhpcyBzdGFuZGFyZCwgYW5kIGV2ZW4gaWYgdGhlIHN0YW5kYXJkIGRpZG7igJl0 IGV4aXN0LCB0aGUgZXhpc3RpbmcgaW5zdGFsbGVkIGJhc2UgY2Fubm90IGJlIGlnbm9yZWQgaW4g Z29vZCBjb25zY2llbmNlLiBUaGUgcXVlc3Rpb24gdG8gYXNrIGhlcmUgaXMgd2hhdCBwcm9ibGVt IHdl4oCZZCBiZSB0cnlpbmcgdG8gc29sdmUgd2l0aCDigJxmdXR1cmUgc3RhbmRhcmRzIHRoYXQg dXNlIGxvd2VyLW9yZGVyIDY0IGJpdHMgZm9yIHNwZWNpYWwgcHVycG9zZXPigJ0gdGhhdCB3b3Vs ZCBtYWtlIHN1cHBvcnRpbmcgaXQgbmVjZXNzYXJ5IG9uIFAyUCBsaW5rcyB3aGVyZSB0aGUgSVAg YWRkcmVzcyBhc3NpZ25lZCBvZnRlbiBkb2VzbuKAmXQgZXZlbiBtYXR0ZXIgZXhjZXB0IGZvciBk aWFnbm9zdGljcz8gSW4gbWFueSBjYXNlcywgdGhlIFAyUCBsaW5rIG5laXRoZXIgc291cmNlcyBu b3IgcmVjZWl2ZXMgdHJhZmZpYyBleGNlcHQgdGhlIG9kZCBJQ01QIHJlc3BvbnNlLCBhbmQgZXZl biB0aGF0IHR5cGUgb2YgdHJhZmZpYyBjb3VsZCBiZSBjb25maWd1cmVkIHRvIHVzZSB0aGUgbG9v cGJhY2sgKHNlZSBhbHNvIGlwIHVubnVtYmVyZWQpLiBTb21lIGNhcnJpZXJzIGRvbuKAmXQgZXZl biBwdXQgdGhvc2UgbGlua3MgaW4gdGhlaXIgSUdQIGZvciBzZWN1cml0eSByZWFzb25zLiBUbyB1 bmRlcnNjb3JlIHRoZSByZWxhdGl2ZSB1bmltcG9ydGFuY2Ugb2YgdGhlIFAyUCBsaW5rIGFkZHJl c3MsIHRoZXJlIGFyZSBldmVuIGRpc2N1c3Npb25zIGhhcHBlbmluZyB3aXRoaW4gSUVURiByaWdo dCBub3cgYWJvdXQgdXNpbmcgVUxBIHNwYWNlIGZvciBQMlAgaW50ZXJuYWwgbGlua3MuIChOb3Rl OiBJ4oCZbSBqdXN0IG5vdGluZyB0aGF0IHRoZSBkaXNjdXNzaW9uIGlzIGhhcHBlbmluZywgbm90 IGVuZG9yc2luZyBpdCkuIE5vdCBhbGwgaW1wbGVtZW50YXRpb25zIGZpdCB0aGlzIG1vZGVsLCBi dXQgSSB0aGluayB0aGUgcmlzayBvZiB0aGUgbmVlZCBmb3IgYSByZW51bWJlciBpbiB0aGlzIGNh c2UgaXMgYmVpbmcgb3ZlcnNvbGQgc29tZXdoYXQuIFRoZSByZWFsaXR5IGlzIHRoYXQgZmV3IG9m IHVzIGFyZSBnb2luZyB0byBnZXQgdGhlIG51bWJlcmluZyBwbGFuIDEwMCUgcmlnaHQgdGhlIGZp cnN0IHRpbWUsIG5vIG1hdHRlciBob3cgc21hcnQgd2UgdHJ5IHRvIGJlIGluIHRoZSB3YXkgdGhh dCB3ZSBmdXR1cmUtcHJvb2Ygb3VyIGFsbG9jYXRpb24gcGxhbiwgYmVjYXVzZSB0aGVyZeKAmXMg bm8gb25lIHNpemUgZml0cyBhbGwgc29sdXRpb24uIFdlIGNhbiB0YWxrIGFib3V0IGJlc3QgcHJh Y3RpY2UgYmFzZWQgb24gd2hhdCB3ZSBrbm93IHRvZGF5LCBidXQgYW55dGhpbmcgbW9yZSBpcyBq dXN0IGVkdWNhdGVkIGd1ZXNzaW5nLCBhbmQgbXkgOCBiYWxsIGlzIG5vIGJldHRlciB0aGFuIGFu eW9uZSBlbHNl4oCZcy4NCg0KT24gMjEvMDkvMjAxMiwgYXQgMTA6MDIgUE0sIFRKIDx0cmVqcmNv QGdtYWlsLmNvbT4gd3JvdGU6DQo+PldSVCBQb2ludC10by1wb2ludCBsaW5rcyAob25seSwgYW55 IG11bHRpLWFjY2VzcyBsaW5rIFJFQUxMWSBzaG91bGQgYmUgYSAvNjQpOiBGb3IgdGhvc2UgdGhh dCBpbnNpc3Qgb24gdXNpbmcgc29tZXRoaW5nIGVsc2UsIGl0IGlzIGxvb3NlbHkgYWNjZXB0ZWQg dGhhdCBhIC8xMjcgY2FuIHdvcmsNCg0KW1dFR10gTGV04oCZcyBiZSBjbGVhci4gUkZDIDYxNjQg aXMgYSBwcm9kdWN0IG9mIElFVEYgY29uc2Vuc3VzIGFuZCBhIHByb3Bvc2VkIHN0YW5kYXJkLCBh bmQgdGhlIHJlYXNvbiB0aGF0IGl0IHdhcyBwdXNoZWQgZm9yd2FyZCBhbmQgdGhlIHByZXZpb3Vz IGd1aWRhbmNlIHdhcyBhbWVuZGVkIHdhcyB0aGF0IG11bHRpcGxlIGxhcmdlIG9wZXJhdG9ycyBj YW1lIGZvcndhcmQgYW5kIHNhaWQg4oCcdGhpcyBpcyB3aGF0IHdl4oCZcmUgKmFscmVhZHkqIGRv aW5nLCB5b3XigJlyZSB3ZWxjb21lIHRvIGJlIHdyb25nLCBvciB5b3UgY2FuIHVwZGF0ZSB5b3Vy IGd1aWRhbmNlLuKAnSBUaGF04oCZcyBub3Qg4oCcbG9vc2VseSBhY2NlcHRlZOKAnS4gSeKAmW0g bm90IHNheWluZyB0aGF0IGl04oCZcyB1bml2ZXJzYWxseSBzdXBwb3J0ZWQgYnkgYWxsIElQdjYg c3RhY2tzLCBub3IgdGhhdCBjb25zZW5zdXMgPSB1bmFuaW1vdXMgYWdyZWVtZW50LCBidXQgaXTi gJlzIG5vdCBhIGNvcm5lci1jYXNlIGhhY2sgZWl0aGVyLg0KDQpUaGFua3MNCldlcyBHZW9yZ2UN Cg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGlt ZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVn ZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRp bWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1 c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91 IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9u LCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9m IGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5 IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkg cHJpbnRvdXQuDQo= From trejrco@gmail.com Fri Sep 21 12:45:10 2012 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 534D921F869E for ; Fri, 21 Sep 2012 12:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0RRoy+ZiDVq for ; Fri, 21 Sep 2012 12:45:08 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7692021F869D for ; Fri, 21 Sep 2012 12:45:08 -0700 (PDT) Received: by wibhi8 with SMTP id hi8so2023476wib.13 for ; Fri, 21 Sep 2012 12:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=EShv+nLpRRH5rGQp07xKaILBFaCQVn7A3EpLKq0gCnU=; b=Jydviw5oyx8KYd2cnzdjO9vHtcbozV0MXJ/eB2HShNB6dvTBzdDpvbzrC6uypGy+x0 eAWVlPsC5cPRCCajCNwLuNMF8kVHGsYmP3ycdAhjvpeoXiGzsSLTtnloRY/LBKSzSacV N2KMcex0mO7wXfovZ6PKXaLI591VsAjGrn/a1ufwtHpONHlG4eBTHTaW+YAWBOf27GAy 6IxbgVdv619mN4t+drK1sSLZdEH3zcQVHntQHZtTRaJWnUCx+v+PDwGXaWOj8MKhrYnp hK0RrHrAv4EzK8O4dE5lSjQawAvYtFV4T59e+JElGnX+3ikyK4rhC4W8n7Z/GLVadX9q 6osg== Received: by 10.180.104.197 with SMTP id gg5mr6359519wib.9.1348256707567; Fri, 21 Sep 2012 12:45:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.28.161 with HTTP; Fri, 21 Sep 2012 12:44:46 -0700 (PDT) In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59235F961497@PRVPEXVS15.corp.twcable.com> References: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.com> <2671C6CDFBB59E47B64C10B3E0BD59235F961497@PRVPEXVS15.corp.twcable.com> From: TJ Date: Fri, 21 Sep 2012 15:44:46 -0400 Message-ID: Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks To: IETF IPv6 Content-Type: multipart/alternative; boundary=f46d041825bc1edf3804ca3b7a55 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: trejrco@gmail.com List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 19:45:10 -0000 --f46d041825bc1edf3804ca3b7a55 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Sep 21, 2012 at 3:23 PM, George, Wes wro= te: > Responding to a couple of different things below inline with [WEG] > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Usman Latif > >>"If you choose to do this, it is further recommended that you reserve > the entire /64 so that - if needed in the future - you can expand this > configuration _without_ a major renumbering event." > > [WEG] I=92m not sure that renumbering P2P links is comparatively harder t= han > changing the subnet mask, nor would I characterize one as a major > renumbering event and the other not. You still have to touch all links, a= ll > devices, the only difference would be for things that are configured to u= se > the link IP to communicate with the router, and a lot of those can be > managed using make before break provisioning. There are several IETF > documents (and a whole WG) covering how to manage renumbering in a more > painless fashion, and this is one that is pretty straightforward. > Indeed; however - if your addressing plan needs to be redone to accommodate the renumbering there may be no small amount of pain involved. > >>This is the essence of what I want the IETF to put in one of its addres= s > recommendation RFCs because I have yet to see an RFC that says when you > assign a /127 to a p2p link, you should/must reserve the whole parent /64 > for that p2p link also. > > [WEG] I think that part of the reason you haven=92t seen that RFC is that > there=92s an argument to be made to the contrary as well =96 there=92s so= me value > from a configuration management and operational perspective in being able > to use one line of config to manage things like route aggregation, > filtration, management tools access, access lists, etc. Yes, you can do > that with a larger block (e.g. allocate the top /48 of your /32 for > infrastructure) but that adds a lot of addresses to be permitted through > the filters that simply aren=92t necessary nor will ever be used, and exp= oses > you to other attack vectors in a way that isn=92t necessarily justifiable= , at > least IMO. This is very much a case of YMMV, so I=92m not sure that =93re= serve > the whole /64 for each /127=94 is universally something we could or shoul= d > recommend, especially if it=92s mainly a =93just in case, you never know = what > craziness those protocol wonks in IETF might come up with that would brea= k > it in the future...mumble mumble=85=94 kind of reason. > While I do not set out to tell anyone how they must run their network, I do embrace the idea of minimizing future problems / rework ... :) > >>Without this stated clearly there is likely to be some instances where > readers interpret it the wrong way and end up assigning multiple p2p link= s > with /127 subnets from a single given /64 and end up having to re-address > their network in future when/if future standards use lower order 64 bits > for special purposes. > > [WEG] Given the fact that there is a standard that documents the use of a > /127 for P2P links (6164), future standards can=92t use lower order 64 bi= ts > for special purposes without considering the potential impact to this > standard, and even if the standard didn=92t exist, the existing installed > base cannot be ignored in good conscience. The question to ask here is wh= at > problem we=92d be trying to solve with =93future standards that use lower= -order > 64 bits for special purposes=94 that would make supporting it necessary o= n > P2P links where the IP address assigned often doesn=92t even matter excep= t > for diagnostics? In many cases, the P2P link neither sources nor receives > traffic except the odd ICMP response, and even that type of traffic could > be configured to use the loopback (see also ip unnumbered). Some carriers > don=92t even put those links in their IGP for security reasons. To unders= core > the relative unimportance of the P2P link address, there are even > discussions happening within IETF right now about using ULA space for P2P > internal links. (Note: I=92m just noting that the discussion is happening= , > not endorsing it). Not all implementations fit this model, but I think th= e > risk of the need for a renumber in this case is being oversold somewhat. > The reality is that few of us are going to get the numbering plan 100% > right the first time, no matter how smart we try to be in the way that we > future-proof our allocation plan, because there=92s no one size fits all > solution. We can talk about best practice based on what we know today, bu= t > anything more is just educated guessing, and my 8 ball is no better than > anyone else=92s. > Again, agreed - but if I can, with relative ease, mitigate a potential source of that problem I'll take it :). > On 21/09/2012, at 10:02 PM, TJ wrote: > >>WRT Point-to-point links (only, any multi-access link REALLY should be = a > /64): For those that insist on using something else, it is loosely accept= ed > that a /127 can work > > [WEG] Let=92s be clear. RFC 6164 is a product of IETF consensus and a > proposed standard, and the reason that it was pushed forward and the > previous guidance was amended was that multiple large operators came > forward and said =93this is what we=92re *already* doing, you=92re welcom= e to be > wrong, or you can update your guidance.=94 That=92s not =93loosely accept= ed=94. I=92m > not saying that it=92s universally supported by all IPv6 stacks, nor that > consensus =3D unanimous agreement, but it=92s not a corner-case hack eith= er. > Fair point - other values for PrefLen have been proposed/mentioned over the years (/112 and /126 come to mind). Just that, IMHO, if you aren't using a /64 a /127 is the next best thing ... I'm always interested in hearing additional justifications / deployment drivers :). /TJ --f46d041825bc1edf3804ca3b7a55 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Sep 21, 2012 at 3:23 PM, George, Wes <wesley.george@twcab= le.com> wrote:
Responding to =A0a couple of different things below inline with [WEG]

From: ipv6-bounces@ietf.org [m= ailto:ipv6-bounces@ietf.org] O= n Behalf Of Usman Latif
>>"If you choose to do this, it is further rec= ommended that you reserve the entire /64 so that - if needed in the future = - you can expand this configuration _without_ a major renumbering event.&qu= ot;

[WEG] I=92m not sure that renumbering P2P links is comparatively hard= er than changing the subnet mask, nor would I characterize one as a major r= enumbering event and the other not. You still have to touch all links, all = devices, the only difference would be for things that are configured to use= the link IP to communicate with the router, and a lot of those can be mana= ged using make before break provisioning. =A0There are several IETF documen= ts (and a whole WG) covering how to manage renumbering in a more painless f= ashion, and this is one that is pretty straightforward.

Indeed; however - if your addressing plan = needs to be redone to=A0accommodate=A0the renumbering there may be no small= amount of pain involved.


=A0
=
>>This is the essence of what I want the IETF to pu= t in one of its address recommendation RFCs because I have yet to see an RF= C that says when you assign a /127 to a p2p link, you should/must reserve t= he whole parent /64 for that p2p link also.

[WEG] I think that part of the reason you haven=92t seen that RFC is = that there=92s an argument to be made to the contrary as well =96 there=92s= some value from a configuration management and operational perspective in = being able to use one line of config to manage things like route aggregatio= n, filtration, management tools access, access lists, etc. =A0Yes, you can = do that with a larger block (e.g. allocate the top /48 of your /32 for infr= astructure) but that adds a lot of addresses to be permitted through the fi= lters that simply aren=92t necessary nor will ever be used, and exposes you= to other attack vectors in a way that isn=92t necessarily justifiable, at = least IMO. This is very much a case of YMMV, so I=92m not sure that =93rese= rve the whole /64 for each /127=94 is universally something we could or sho= uld recommend, especially if it=92s mainly a =93just in case, you never kno= w what craziness those protocol wonks in IETF might come up with that would= break it in the future...mumble mumble=85=94 kind of reason.

While I do not set out to tell anyone how = they must run their network, I do embrace the idea of minimizing future pro= blems / rework ... :)

=A0
>>Without this stated clearly there is likely to be= some instances where readers interpret it the wrong way and end up assigni= ng multiple p2p links with /127 subnets from a single given /64 and end up = having to re-address their network in future when/if future standards use l= ower order 64 bits for special purposes.

[WEG] Given the fact that there is a standard that documents the use = of a /127 for P2P links (6164), future standards can=92t use lower order 64= bits for special purposes without considering the potential impact to this= standard, and even if the standard didn=92t exist, the existing installed = base cannot be ignored in good conscience. The question to ask here is what= problem we=92d be trying to solve with =93future standards that use lower-= order 64 bits for special purposes=94 that would make supporting it necessa= ry on P2P links where the IP address assigned often doesn=92t even matter e= xcept for diagnostics? In many cases, the P2P link neither sources nor rece= ives traffic except the odd ICMP response, and even that type of traffic co= uld be configured to use the loopback (see also ip unnumbered). Some carrie= rs don=92t even put those links in their IGP for security reasons. To under= score the relative unimportance of the P2P link address, there are even dis= cussions happening within IETF right now about using ULA space for P2P inte= rnal links. (Note: I=92m just noting that the discussion is happening, not = endorsing it). Not all implementations fit this model, but I think the risk= of the need for a renumber in this case is being oversold somewhat. The re= ality is that few of us are going to get the numbering plan 100% right the = first time, no matter how smart we try to be in the way that we future-proo= f our allocation plan, because there=92s no one size fits all solution. We = can talk about best practice based on what we know today, but anything more= is just educated guessing, and my 8 ball is no better than anyone else=92s= .

Again, agreed - but if I can, with relativ= e ease, mitigate a potential source of that problem I'll take it :).

=A0
On 21/09/2012, at 10:02 PM, TJ <trejrco@gmail.com> wrote:
>>WRT Point-to-point links (only, any multi-a= ccess link REALLY should be a /64): For those that insist on using somethin= g else, it is loosely accepted that a /127 can work

[WEG] Let=92s be clear. RFC 6164 is a product of IETF consensus and a= proposed standard, and the reason that it was pushed forward and the previ= ous guidance was amended was that multiple large operators came forward and= said =93this is what we=92re *already* doing, you=92re welcome to be wrong= , or you can update your guidance.=94 That=92s not =93loosely accepted=94. = I=92m not saying that it=92s universally supported by all IPv6 stacks, nor = that consensus =3D unanimous agreement, but it=92s not a corner-case hack e= ither.

Fair point - other values for PrefLen have= been proposed/mentioned over the years =A0(/112 and /126 come to mind). = =A0
Just that, IMHO, if you aren't using a /64 a /127 is the = next best thing ... I'm always interested in hearing additional=A0justi= fications=A0/ deployment drivers :).


/TJ
--f46d041825bc1edf3804ca3b7a55-- From osmankh@yahoo.com Fri Sep 21 14:35:37 2012 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 4803921E808D for ; Fri, 21 Sep 2012 14:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-IMOwsvO+ZI for ; Fri, 21 Sep 2012 14:35:36 -0700 (PDT) Received: from nm27-vm4.bullet.mail.ne1.yahoo.com (nm27-vm4.bullet.mail.ne1.yahoo.com [98.138.91.187]) by ietfa.amsl.com (Postfix) with SMTP id 4181F21E803A for ; Fri, 21 Sep 2012 14:35:36 -0700 (PDT) Received: from [98.138.90.50] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 21 Sep 2012 21:35:30 -0000 Received: from [98.138.89.171] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 21 Sep 2012 21:35:30 -0000 Received: from [127.0.0.1] by omp1027.mail.ne1.yahoo.com with NNFMP; 21 Sep 2012 21:35:30 -0000 X-Yahoo-Newman-Id: 957223.31317.bm@omp1027.mail.ne1.yahoo.com Received: (qmail 38010 invoked from network); 21 Sep 2012 21:35:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=riLwFAtJb4iGpnK2CL/ZbE3UVPZlOUTEalWqc8YmNEC03ZhsDfQxcGm6QOFYJCdsGIfB0SuxZfp1yczevmvpdQXIFtXnpZ2Nqgz+pcO5J+bTG5QnsVsjkjKbv9+Yigp2DKEAkY09jgE4Bbp7an9ibgqsINrluaZjRgpQWh12jaQ= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348263330; bh=6Qh/pJOQDtjXQ8b4vj5wwTsmagCMMEWvdCxLgAnj/hA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=xHy7nnCVNu6I1pzSrClNt0zbs628zv4zfwp+7cJrClFmx8iWD4eNEUZRke7cS8oVjZ8LOSpvle/n9r0bdoEXpidTzVL+Aq4o4eYyZM3khJtHDDfo+0dNJrS4ixt1HpcTIyj66Q7+5D2bYblVAb702WL3VKHEZ40UUfDYcM5Fu+8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: dQ2.B74VM1nnHIOVh9tDxyVJNpAfG3_Vwa1FRfX.xm.9rhb qhZko9TQvUjD0GGEf5RyZgpjqy0QTYGNeSMPUjWuyUP1uTy3pdc0y3COFT4D RlNk9.1rbMSPh3xIOpu3IKTCPX9g6HdVoN4D5q8jLt9DgmEg8Co3_wqWLCac 8QnUVXNgWxJO_RKc2OgKKxKWOCVBnDKGe1Cnycxhd6mpgee.EX8dyjyhnQBO xMv_R7wFidke6fOi78zs6F36imka54qM70ENpL6JEu9zDwcCZPaVRiuXqrQE VeY574RJMHQ5FIdk8YREVnf3amKIwlZ0bIyKnwuA9JU3jwgE5PLC2IPcrTxc Yg4qgo_UdXjkmz_tS.jX24W5ybrWPa8MnXfLreHv3iDDnMiTvh668NgpK6lq 4Bg29669sMmJA.u1nU8SwPuBpWpdgezIJAkJL1an6gswruqGyEUWj_CLBC0s ra21l X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- Received: from [192.168.1.66] (osmankh@27.32.72.22 with xymcookie) by smtp116-mob.biz.mail.ne1.yahoo.com with SMTP; 21 Sep 2012 14:35:30 -0700 PDT References: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.com> <2671C6CDFBB59E47B64C10B3E0BD59235F961497@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59235F961497@PRVPEXVS15.corp.twcable.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9B206) From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Date: Sat, 22 Sep 2012 07:35:26 +1000 To: "George, Wes" 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: Fri, 21 Sep 2012 21:35:37 -0000 Thanks Wes for the feedback. Some points I'd like to further comment on: i. You mentioned that a re-address event is no different from re-masking the= links-=20 this is true to an extent but I think changing subnet mask would still be re= latively easier to manage than having to re-address all links and loopback i= nterfaces. If we can think of an alternative to re-masking, I am open to con= sider and talk about it. I think the impact is considerable and obviously different people may have d= ifferent views on the extent of impact. Note: having to renumber loopbacks that have been assigned /128 from the sam= e /64 e.g. is an even bigger risk because protocol adjacencies and a lot of c= ontrol plane peering relationships are bound to it Also as a service provider, the impact may not just be limited to the SP bac= kbone but also the SP's end-customers which which means there will be politi= cal and legal issues arising out of SP wanting its customers to renumber e.g= PE-CE links where the SP may have used /127s from the same /64 block So IMO the impact is significant! ii. You also mentioned that IP address on p2p links don't matter and that th= e risk is being oversold. I think not all implementations have p2p links with local significance only a= nd also a router may not need to advertise the p2p link to its routing peers= but it would still pose a problem if the router is in the forwarding path o= f packets destined to/from addresses that conflict with specially assigned a= ddresses (current/future) using lower-64 bits of the v6 address space. Again= the loopbacks need to be considered here too for the same reason mentioned a= bove. iii. You raised a point around RFC 6164 that future implementations would ne= ed to take it into consideration and in good conscience existing implementat= ions that have used /127 or similar on p2p links from the same /64 block can= not be ignored. I agree to this point but I think if a new RRC or even the existing RFC 6164= mentions this explicitly that a carrier may or may not have /127 from the s= ame /64 block, it would cover all bases and ensure that we don't end up in a= ny controversy in future. Regards, Usman Sent from my iPhone On 22/09/2012, at 5:23 AM, "George, Wes" wrote: > Responding to a couple of different things below inline with [WEG] >=20 > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Us= man Latif >>> "If you choose to do this, it is further recommended that you reserve th= e entire /64 so that - if needed in the future - you can expand this configu= ration _without_ a major renumbering event." >=20 > [WEG] I=E2=80=99m not sure that renumbering P2P links is comparatively har= der than changing the subnet mask, nor would I characterize one as a major r= enumbering event and the other not. You still have to touch all links, all d= evices, the only difference would be for things that are configured to use t= he link IP to communicate with the router, and a lot of those can be managed= using make before break provisioning. There are several IETF documents (an= d a whole WG) covering how to manage renumbering in a more painless fashion,= and this is one that is pretty straightforward. >=20 >>> This is the essence of what I want the IETF to put in one of its address= recommendation RFCs because I have yet to see an RFC that says when you ass= ign a /127 to a p2p link, you should/must reserve the whole parent /64 for t= hat p2p link also. >=20 > [WEG] I think that part of the reason you haven=E2=80=99t seen that RFC is= that there=E2=80=99s an argument to be made to the contrary as well =E2=80=93= there=E2=80=99s some value from a configuration management and operational p= erspective in being able to use one line of config to manage things like rou= te aggregation, filtration, management tools access, access lists, etc. Yes= , you can do that with a larger block (e.g. allocate the top /48 of your /32= for infrastructure) but that adds a lot of addresses to be permitted throug= h the filters that simply aren=E2=80=99t necessary nor will ever be used, an= d exposes you to other attack vectors in a way that isn=E2=80=99t necessaril= y justifiable, at least IMO. This is very much a case of YMMV, so I=E2=80=99= m not sure that =E2=80=9Creserve the whole /64 for each /127=E2=80=9D is uni= versally something we could or should recommend, especially if it=E2=80=99s m= ainly a =E2=80=9Cjust in case, you never know what craziness those protocol w= onks in IETF might come up with that would break it in the future...mumble m= umble=E2=80=A6=E2=80=9D kind of reason. >=20 >>> Without this stated clearly there is likely to be some instances where r= eaders interpret it the wrong way and end up assigning multiple p2p links wi= th /127 subnets from a single given /64 and end up having to re-address thei= r network in future when/if future standards use lower order 64 bits for spe= cial purposes. >=20 > [WEG] Given the fact that there is a standard that documents the use of a /= 127 for P2P links (6164), future standards can=E2=80=99t use lower order 64 b= its for special purposes without considering the potential impact to this st= andard, and even if the standard didn=E2=80=99t exist, the existing installe= d base cannot be ignored in good conscience. The question to ask here is wha= t problem we=E2=80=99d be trying to solve with =E2=80=9Cfuture standards tha= t use lower-order 64 bits for special purposes=E2=80=9D that would make supp= orting it necessary on P2P links where the IP address assigned often doesn=E2= =80=99t even matter except for diagnostics? In many cases, the P2P link neit= her sources nor receives traffic except the odd ICMP response, and even that= type of traffic could be configured to use the loopback (see also ip unnumb= ered). Some carriers don=E2=80=99t even put those links in their IGP for sec= urity reasons. To underscore the relative unimportance of the P2P link addre= ss, there are even discussions happening within IETF right now about using U= LA space for P2P internal links. (Note: I=E2=80=99m just noting that the dis= cussion is happening, not endorsing it). Not all implementations fit this mo= del, but I think the risk of the need for a renumber in this case is being o= versold somewhat. The reality is that few of us are going to get the numberi= ng plan 100% right the first time, no matter how smart we try to be in the w= ay that we future-proof our allocation plan, because there=E2=80=99s no one s= ize fits all solution. We can talk about best practice based on what we know= today, but anything more is just educated guessing, and my 8 ball is no bet= ter than anyone else=E2=80=99s. >=20 > On 21/09/2012, at 10:02 PM, TJ wrote: >>> WRT Point-to-point links (only, any multi-access link REALLY should be a= /64): For those that insist on using something else, it is loosely accepted= that a /127 can work >=20 > [WEG] Let=E2=80=99s be clear. RFC 6164 is a product of IETF consensus and a= proposed standard, and the reason that it was pushed forward and the previo= us guidance was amended was that multiple large operators came forward and s= aid =E2=80=9Cthis is what we=E2=80=99re *already* doing, you=E2=80=99re welc= ome to be wrong, or you can update your guidance.=E2=80=9D That=E2=80=99s no= t =E2=80=9Cloosely accepted=E2=80=9D. I=E2=80=99m not saying that it=E2=80=99= s universally supported by all IPv6 stacks, nor that consensus =3D unanimous= agreement, but it=E2=80=99s not a corner-case hack either. >=20 > Thanks > Wes George >=20 > This E-mail and any of its attachments may contain Time Warner Cable propr= ietary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the us= e of the individual or entity to which it is addressed. If you are not the i= ntended recipient of this E-mail, you are hereby notified that any dissemina= tion, distribution, copying, or action taken in relation to the contents of a= nd 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 immediatel= y and permanently delete the original and any copy of this E-mail and any pr= intout. From brian.e.carpenter@gmail.com Fri Sep 21 16:06:01 2012 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 C26E021E8096 for ; Fri, 21 Sep 2012 16:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcmFnGF+8w4r for ; Fri, 21 Sep 2012 16:06:01 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 218F621E8092 for ; Fri, 21 Sep 2012 16:06:01 -0700 (PDT) Received: by iec9 with SMTP id 9so7618766iec.31 for ; Fri, 21 Sep 2012 16:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8GU9H74E1j/LgYhJnWMN+kjoPOAvh0c+tO5sMyNBkU0=; b=OIIpXY5axRvv/5RAymNbx/afoNvpHeLSzoxswsaSzL8P+W5EUY2HrXQGBR6UecOuvS /4CVoTC99503kqTmYOlecuh7MKfzDM5Zxvtnb7EnsI7jajbyMN7X/Jj+nCi9TQhHBLHt cEVAOaGX/0RD/estRiiRRg9qlOl4i5rfmVfIM2dBHnmZEr8Mm/WGRk1nyWbxGuuSzkvN EzOtvJXmb2CA7854YhZKzdIIn81J5xCLTRAQLX8xc7YjJ44zEk5yRCZ6ZzIFdOlUPbBc +ZLKNASetBnVwpiISK4jBM4/FLrWQkvOoao3rjh6qmTEA6TZIBLlykc5hayAqlPFia3o tr/A== Received: by 10.50.190.197 with SMTP id gs5mr315254igc.32.1348268760313; Fri, 21 Sep 2012 16:06:00 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id uq6sm176611igb.14.2012.09.21.16.05.59 (version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 16:05:59 -0700 (PDT) Message-ID: <505CF2DC.3050401@gmail.com> Date: Sat, 22 Sep 2012 00:06:04 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks References: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.com> <2671C6CDFBB59E47B64C10B3E0BD59235F961497@PRVPEXVS15.corp.twcable.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Fri, 21 Sep 2012 23:06:01 -0000 On 21/09/2012 22:35, Usman Latif wrote: > Thanks Wes for the feedback. ... >>>> Without this stated clearly there is likely to be some instances where readers interpret it the wrong way and end up assigning multiple p2p links with /127 subnets from a single given /64 and end up having to re-address their network in future when/if future standards use lower order 64 bits for special purposes. >> [WEG] Given the fact that there is a standard that documents the use of a /127 for P2P links (6164), Wes, I think that statement is even a bit weak, since 6164 actually says: "assuming that a number of point-to-point links will be numbered out of a single /64 prefix:" so it is very clear: it is allowed by the standard to share a /64 among however many pt2pt links the operator cares to. This is *not* a wrong interpretation. As you say, any future work will need to take account of this. Brian From joelja@bogus.com Fri Sep 21 17:28:48 2012 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 01DCD21F8501 for ; Fri, 21 Sep 2012 17:28:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZSWRZ7K+Tcr for ; Fri, 21 Sep 2012 17:28:47 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 870E221F84D7 for ; Fri, 21 Sep 2012 17:28:47 -0700 (PDT) Received: from joels-MacBook-Air.local (50-0-150-57.dsl.static.sonic.net [50.0.150.57]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8M0Siui091379 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 22 Sep 2012 00:28:45 GMT (envelope-from joelja@bogus.com) Message-ID: <505D063C.5000705@bogus.com> Date: Fri, 21 Sep 2012 17:28:44 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120828 Thunderbird/16.0 MIME-Version: 1.0 To: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks References: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> In-Reply-To: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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]); Sat, 22 Sep 2012 00:28:45 +0000 (UTC) Cc: bob.hinden@gmail.com, 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: Sat, 22 Sep 2012 00:28:48 -0000 On 9/21/12 12:03 AM, Usman Latif wrote: > > > > I suppose bodies like IETF all need to ensure that there are > definitive guidelines around addressing architectures so that future > implementations of procotol stacks and features donot overlap with > bits in the IPv6 address space that could potentially be used on p2p > inter-router links (i.e. there could be address assignments done based > on subnet prefixes longer than /64 on p2p links) and obviously if some > implementation in future uses the bits from that space, it would > become a big challenge for operators and their customers to re-address > their p2p inter-router links. > As an implementer you have to assume the existence of prefixes longer than /64 if not, loopback addresses which are /128s would not exist. in point of fact regarding /127s we have. http://tools.ietf.org/html/rfc6164 which is about as authoritative as anything gets. From rajiva@cisco.com Fri Sep 21 17:28:48 2012 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 7CA7721E8049 for ; Fri, 21 Sep 2012 17:28:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1OvlH7ZJlHO for ; Fri, 21 Sep 2012 17:28:47 -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 D2FD921F84FE for ; Fri, 21 Sep 2012 17:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1918; q=dns/txt; s=iport; t=1348273728; x=1349483328; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lU/tbQUqzLmrT7HLhhFB2DY9DN/VjRkeWgaKFrlcHG8=; b=OrpKwQFQBgJD8pxVPwis0morC4TnSJX+0frD6G/9eCo7wB4gUlhfG96A Z5t+2LS67/5GNBMzFkBUMo1Hr1dKDU3BO65hsuWoxV8yTtfCsH4/KRO9Y 1OBAwotdadsMlfYSvqlT2G0rtR1iGH/abcuAhhILkBclfxKD95xAjj0wK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAUFXVCtJV2c/2dsb2JhbABFviGBCIIgAQEBAwEBAQEPASc0CwULAgEIGBUJECEGCyUCBA4FIodRAwkGC5kZljUNiU8EijpignqCTGADkjOBXIFVixiDIYFpgmc X-IronPort-AV: E=Sophos;i="4.80,465,1344211200"; d="scan'208";a="124169013" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 22 Sep 2012 00:28:47 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8M0Sll4031611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Sep 2012 00:28:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Fri, 21 Sep 2012 19:28:47 -0500 From: "Rajiv Asati (rajiva)" To: Brian E Carpenter Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Thread-Topic: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Thread-Index: AQHNmAO3spi6Jg7nwUCAWUNapdgAY5eVgOYAgAAk6gCAABlTAP//w0p/ Date: Sat, 22 Sep 2012 00:28:46 +0000 Message-ID: References: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.com> <2671C6CDFBB59E47B64C10B3E0BD59235F961497@PRVPEXVS15.corp.twcable.com> , <505CF2DC.3050401@gmail.com> In-Reply-To: <505CF2DC.3050401@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--41.725800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Usman Latif , "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: Sat, 22 Sep 2012 00:28:48 -0000 Indeed, and I see a sheer wastage in blocking the entire /64 whose one /127= is used on p2p links.=20 There are many deployments that already assign bunch of /64 (or lower) pref= ixes per hierarchy and encode bunch of useful info in 72-96 and then assign= thousands of /127s out of each /96 (or encode ipv4 loopbak address in it t= o get /128 loopback) to thousand of network infrastructure devices.=20 This has pros and cons, but the point is that this should be a deployment c= hoice, not a standard mandate. Cheers, Rajiv Sent from my Phone On Sep 21, 2012, at 7:06 PM, "Brian E Carpenter" wrote: > On 21/09/2012 22:35, Usman Latif wrote: >> Thanks Wes for the feedback. >=20 > ... >>>>> Without this stated clearly there is likely to be some instances wher= e readers interpret it the wrong way and end up assigning multiple p2p link= s with /127 subnets from a single given /64 and end up having to re-address= their network in future when/if future standards use lower order 64 bits f= or special purposes. >>> [WEG] Given the fact that there is a standard that documents the use of= a /127 for P2P links (6164),=20 >=20 > Wes, I think that statement is even a bit weak, since 6164 actually says: >=20 > "assuming that a number of point-to-point links will be numbered out of a= single /64 prefix:" >=20 > so it is very clear: it is allowed by the standard to share a /64 among > however many pt2pt links the operator cares to. This is *not* a wrong > interpretation. >=20 > As you say, any future work will need to take account of this. >=20 > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From osmankh@yahoo.com Sat Sep 22 06:37:46 2012 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 7A54321F865E for ; Sat, 22 Sep 2012 06:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kpGuY3-LH2v for ; Sat, 22 Sep 2012 06:37:45 -0700 (PDT) Received: from nm32-vm0.bullet.mail.ne1.yahoo.com (nm32-vm0.bullet.mail.ne1.yahoo.com [98.138.229.48]) by ietfa.amsl.com (Postfix) with SMTP id 1814721F8624 for ; Sat, 22 Sep 2012 06:37:44 -0700 (PDT) Received: from [98.138.90.57] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 22 Sep 2012 13:37:34 -0000 Received: from [98.138.88.236] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 22 Sep 2012 13:37:34 -0000 Received: from [127.0.0.1] by omp1036.mail.ne1.yahoo.com with NNFMP; 22 Sep 2012 13:37:34 -0000 X-Yahoo-Newman-Id: 80908.71159.bm@omp1036.mail.ne1.yahoo.com Received: (qmail 57621 invoked from network); 22 Sep 2012 13:37:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=haU5o4kw2v/71WJ9X0pZPFn7b1Tgn+ThOQqJA37+NLDs9HFtXrELu3u4Md38DB7nIYoKsO3NVSFsr/FSWqV+eLI1CGjjXU6Yk6reYIFhVwf3kozRB9E7kCsUavQpriykfDl/6KlGhqzP8Nbn51DkhrPBIR3JSnqY5B3oyi6nxyc= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348321053; bh=s8/5gByMPYxBjKsc/vSq7WAWhcfR+7byLizq16K6E3U=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=I7rKOYaHjsbzhRDo+p7UG/xz/M/eQNotnJxn2iBn451ohLxvL9Be+bSJmhYir/6ML/9KdvklhFdsoN4dFwGtRHnQZy/YoZmgtxsi4KDmZCCe8Zh+/7I89cENHUc/nYqOvk4pQTpCepCkaZW6/tZFoj2ep7KHHvN+gQtetOHHl1M= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: I1IEb2gVM1mqkuNbcJtkIpMm2aIkV0fMKmVFPzXlyZTwiW5 Mpu6rP5l4WHKMCMIRQdskzuWzQIE5IukWBZBk28ilAVMPitMHmpHNuQ61jx5 jt1CpJYoeS_Fd2JcsEOVoRFTAq0qRA5IU..O9I9Ii6oQq3osIHvUewEk3Qkb 9CVMDzsnmL1Z4k_rU85fJwj8fMI6wu9JS42C7k1xTN5PNTqGGy7dytYFeGTm WEUzUh9G9fBCeYLz8ovlb9.UeulrtoAiQwYedGgzU1sszWe3b9fqwMurXTwa lL8IwF2QjmnrS2MTMRZiViLbQTnHHJNGrmBRKut.tm.lGDpGv4mP5AKhsIx9 GOHAmohSdw0HBs0Xfx_Wtc2jSK7elHQzRr79j4I5B_kqEMoQmM8ArvwxSA.2 Djy3PKohlZbn0t.ulyAgFWdCB_hM2y5GDPe_NGifE32n.S9T3F3AWQVPr0b2 kYKcf X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- Received: from [192.168.1.66] (osmankh@27.32.72.22 with xymcookie) by smtp104-mob.biz.mail.ne1.yahoo.com with SMTP; 22 Sep 2012 06:37:32 -0700 PDT References: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.com> <2671C6CDFBB59E47B64C10B3E0BD59235F961497@PRVPEXVS15.corp.twcable.com> <505CF2DC.3050401@gmail.com> <984B69E6-CBB4-4CD2-B624-D2F5B98E73B2@yahoo.com> In-Reply-To: <984B69E6-CBB4-4CD2-B624-D2F5B98E73B2@yahoo.com> Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-C72C504F-AC61-4CBE-BE56-CFCE825EBB34 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (9B206) From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Date: Sat, 22 Sep 2012 23:37:29 +1000 To: "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: Sat, 22 Sep 2012 13:37:46 -0000 --Apple-Mail-C72C504F-AC61-4CBE-BE56-CFCE825EBB34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Forgot to include IPv6 group email in my last email (below) Further to that, RFC 6164 states in the same statement that: "When assigning and using any /127 prefixes, the following considerations=20= apply. Some addresses have special meanings, in particular addresses=20 corresponding to reserved anycast addresses. When assigning prefixes=20 (and addresses) to links, care should be taken to ensure that addresses=20 reserved for such purposes aren't inadvertently assigned and used as=20 unicast addresses. Otherwise, nodes may receive packets that they are=20 not intended to receive. Specifically, assuming that a number of point-to-po= int=20 links will be numbered out of a single /64 prefix:=20 (a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be assigne= d=20 as unicast addresses, to avoid colliding with the Subnet-Router anycast addr= ess=20 (b) Addresses in which the rightmost 64 bits are assigned the highest 128 va= lues=20 (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: ffff) SHOULD NOT be used as un= icast addresses,=20 to avoid colliding with reserved subnet anycast addresses" One question that comes up here is that why did RFC 6164 exclude additional recommendations that were stated in RFC 5375 which stated: "it is recommended to take the 'u' and 'g' bits into consideration and to ma= ke sure that there is no overlap with any of the following well-known addres= ses: o Subnet Router Anycast Address o Reserved Subnet Anycast Address o Addresses used by Embedded-RP o ISATAP Addresses" So should one only care about excluding reserved addresses as per RFC 6164 o= r should we also care about reserving addresses as per RFC 5375? 5375 seems to have more special addresses covered and is also a hint that in= the hindsight there could be more special addresses in future using bits in= lower 64-bit portion of v6 address(?) I wonder if it's possible to leave portions of lower 64 bits in v6 address f= or special purposes (both EUI-64 and non EUI-64) so that we get best of both= worlds i.e. leave room open for future development and assignment of specia= l addresses using portions in lower 64 bits reserved for this purpose and at= the same time allowing users to tap into the lower 64 bit address space for= general address assignment purposes using portions that are not reserved fo= r this purposes... Regards, Usman Sent from my iPhone On 22/09/2012, at 12:35 PM, Usman Latif wrote: > Thanks Brian, your email clears a lot of ambiguity. > So I presume it's safe to use /127s on different p2p links from the same /= 64 subnet. (as per 6164) > This pretty much means that the second statement in my first email would b= e the final outcome - i.e. >=20 > - For IPv6 implementation on strictly p2p (inter-router links) and for dev= ice Loopbacks, we can use /127 and /128 respectively and are NOT reuqired to= reserve the whole corresponding /64 for each of the p2p links (and loopback= s) i.e. for example multiple p2p links can be assigned /127 from the same /6= 4 - this has implication that any future implementation of protocol/stack ne= eds to be careful not to "assume" and reserve some or all of the lower-64 bi= ts in IPv6 address for its implementation. >=20 > Pls note that there is still a mindset out there (call it being apprehensi= ve or being overly cautious) - after speaking with peers in the telco carrie= r space, they are still assigning /127s and reserving whole /64s for each p2= p link separately - this was the basis of my original discussion that we nee= d to "break this myth and be clear and conclusive that operators/carriers et= c or for that matter whoever is implementing v6 addressing on p2p links or l= oopbacks is not required to reserve a whole /64 for each of them separately a= nd its completely a matter of choice whether they choose to assign /127 from= the same /64 or keep separate /64 for each instance of p2p link or loopback= s etc" >=20 > Regards, > Usman >=20 > Sent from my iPhone >=20 > On 22/09/2012, at 9:06 AM, Brian E Carpenter = wrote: >=20 >> On 21/09/2012 22:35, Usman Latif wrote: >>> Thanks Wes for the feedback. >>=20 >> ... >>>>>> Without this stated clearly there is likely to be some instances wher= e readers interpret it the wrong way and end up assigning multiple p2p links= with /127 subnets from a single given /64 and end up having to re-address t= heir network in future when/if future standards use lower order 64 bits for s= pecial purposes. >>>> [WEG] Given the fact that there is a standard that documents the use of= a /127 for P2P links (6164),=20 >>=20 >> Wes, I think that statement is even a bit weak, since 6164 actually says:= >>=20 >> "assuming that a number of point-to-point links will be numbered out of a= single /64 prefix:" >>=20 >> so it is very clear: it is allowed by the standard to share a /64 among >> however many pt2pt links the operator cares to. This is *not* a wrong >> interpretation. >>=20 >> As you say, any future work will need to take account of this. >>=20 >> Brian >=20 --Apple-Mail-C72C504F-AC61-4CBE-BE56-CFCE825EBB34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Forgot to include IPv= 6 group email in my last email (below)
Further to that, RFC 6164 s= tates in the same statement that:

"When assigning a= nd using any /127 prefixes, the following considerations 
apply. Some addresses have special meanings, in particular addresses 
corresponding to reserved anyc= ast addresses. When assigning prefixes 
(and addresses) to links, c= are should be taken to ensure that addresses 
reserved for such pu= rposes aren't inadvertently assigned and used as 
unicast addresse= s. Otherwise, nodes may receive packets that they are 
not intended= to receive. Specifically, assuming that a number of point-to-point 
=
 (a) Addr= esses with all zeros in the rightmost 64 bits SHOULD NOT be assigned 
as unicast addresses, to avoid collid= ing with the Subnet-Router anycast address 
(b) Addresses i= n which the rightmost 64 bits are assigned the highest 128 values 
(i.e., ffff:ffff:ffff:ff7f t= o ffff:ffff:ffff: ffff) SHOULD NOT be used as unicast addresses, 
to avoid colliding with reserved subnet anycast addresses"
<= span class=3D"Apple-style-span" style=3D"-webkit-tap-highlight-color: rgba(2= 6, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.= 230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);">
One question that comes up here is that why did RFC 6164 exc= lude
additional recommendations that were stated in RFC 5375 w= hich stated:

"it is recommended to= take the 'u' and 'g' bits into consideration and to make sure that there is= no overlap with any of the following well-known addresses:
 =   o  Subnet Router Anycast Address
   o  R= eserved Subnet Anycast Address
   o  Addresses used= by Embedded-RP
   o  ISATAP Addresses"
<= br>
So should one only care about excluding reserved addresses as p= er RFC 6164 or should we also care about reserving addresses as per RFC 5375= ?

5375 seems to have more special addresses covered= and is also a hint that in the hindsight there could be more special addres= ses in future using bits in lower 64-bit portion of v6 address(?)
=
I wonder if it's possible to leave portions of lower 64 bits i= n v6 address for special purposes (both EUI-64 and non EUI-64) so that we ge= t best of both worlds i.e. leave room open for future development and assign= ment of special addresses using portions in lower 64 bits reserved for this p= urpose and at the same time allowing users to tap into the lower 64 bit addr= ess space for general address assignment purposes using portions that are no= t reserved for this purposes...

Regards,
= Usman

Sent from my iPhone

On 22/= 09/2012, at 12:35 PM, Usman Latif <o= smankh@yahoo.com> wrote:

Thanks Brian, your email clears a lot of ambiguity.<= br>So I presume it's safe to use /127s on different p2p links from the= same /64 subnet. (as per 6164)
This pretty much means that t= he second statement in my first email would be the final outcome - i.e.

- For IPv6 implementation on strictly p2p (inte= r-router links) and for device Loopbacks, we can use /127 and /128 respectiv= ely and are NOT reuqired to reserve the whole corresponding /64 for each of t= he p2p links (and loopbacks) i.e. for example multiple p2p links can be assi= gned /127 from the same /64 - this has implication that any future implement= ation of protocol/stack needs to be careful not to "assume" and reserve some= or all of the lower-64 bits in IPv6 address for its implementation.<= br>
Pls note that there is still a mindset out there (= call it being apprehensive or being overly cautious) - after speaking with p= eers in the telco carrier space, they are still assigning /127s and reservin= g whole /64s for each p2p link separately - this was the basis of my origina= l discussion that we need to "break this myth and be clear and conclusive th= at operators/carriers etc or for that matter whoever is implementing v6 addr= essing on p2p links or loopbacks is not required to reserve a whole /64 for e= ach of them separately and its completely a matter of choice whether they ch= oose to assign /127 from the same /64 or keep separate /64 for each instance= of p2p link or loopbacks etc"

Regards,
Usman

Sent from my iPhone

On 22/09/2012, at 9:06 AM, Brian E Carpenter &l= t;brian.e.carpenter@gmail.com= > wrote:

O= n 21/09/2012 22:35, Usman Latif wrote:
Thanks Wes for the feedback.

=
...
Without this stated c= learly there is likely to be some instances where readers interpret it the w= rong way and end up assigning multiple p2p links with /127 subnets from a si= ngle given /64 and end up having to re-address their network in future when/= if future standards use lower order 64 bits for special purposes.
=
[WE= G] Given the fact that there is a standard that documents the use of a /127 f= or P2P links (6164),

Wes, I think that statement is even a bit weak, since 6164 actually s= ays:

"assuming that a number of point-to-= point links will be numbered out of a single /64 prefix:"

so it is very clear: it is allowed by the standard to share= a /64 among
however m= any pt2pt links the operator cares to. This is *not* a wrong
interpretation.

As you say, any future work will need to take account of this.<= /span>

Brian

= --Apple-Mail-C72C504F-AC61-4CBE-BE56-CFCE825EBB34-- From osmankh@yahoo.com Mon Sep 24 18:30:14 2012 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 C7E0B1F0CAF for ; Mon, 24 Sep 2012 18:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGP8fd6VM8xj for ; Mon, 24 Sep 2012 18:30:13 -0700 (PDT) Received: from nm25-vm4.bullet.mail.ne1.yahoo.com (nm25-vm4.bullet.mail.ne1.yahoo.com [98.138.91.185]) by ietfa.amsl.com (Postfix) with SMTP id 9200C1F0CA8 for ; Mon, 24 Sep 2012 18:30:13 -0700 (PDT) Received: from [98.138.226.177] by nm25.bullet.mail.ne1.yahoo.com with NNFMP; 25 Sep 2012 01:30:09 -0000 Received: from [98.138.89.246] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 25 Sep 2012 01:30:09 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 25 Sep 2012 01:30:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 338999.69759.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 55236 invoked by uid 60001); 25 Sep 2012 01:30:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348536609; bh=C9NfSMGp6jIzzCm3EkDpcvvtz8/yLyRuP5dLTxBUcWE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=II4vugZhyjQukb2SFGtlKjBR8X5spso8cA3kmZVb7YYZfYrmoZFa+9mPE2FL8wFtHI3s1diqpPTr/bMd0TftpOxxT6EctL4L5AIXHZsx9CaYJq1kuXwqkhRRqfpNjs2PgzbzBfBvRM+jrfTlT1xQvfY5KKK7zlJ2Zks6zBhkhHA= 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:MIME-Version:Content-Type; b=5TirCGqlgPPM1J32qAlVKB3r648B1hzzluZGXtA91cUa7wUK9zyDzrbf1r3KMfCyrAS4t4Y3rlCXT6rFEhstuo3Dkgt7B1FYowwme7BF1YzoPHah18whgBw5PLDpdSS2hOAIRhBMO8LF3fg5Fk1Gna76ryvDhJqiLZK0FNCG7xs=; X-YMail-OSG: e7dG4_wVM1km_YYfwH8zSo9iLCmliROhpmLlcYWrsmiHTGO QwDypmC0y51Po8IHaERN6iVqWhhxBn4mfRNp_UXn42LwLAMkOqTSFPJLKgv6 EheHm9SdkPQlDT85YH19_6eR5HId7qflZ_5baclNUkHIy_Nih_ryIwXya.Co qBwlbsvVWsMw1EsBvatMcCXLvETlsjAblETMJSQaZumci5DpbfbL6D.4xUGF pK6ZX4g02gyiIaxOQoVjJcKOEeu64dKRpr43ZRPGXt31.qYXSCMedDQJvun4 IxPz7AoABOouB5zJKOxa54X4S5AFDy7BUtgzcu6k6w.N0qavFNgQSlGQaQHy d2X8x.X7zjfJ96dkTtTzxSl_haauQZ2XyAwXHZ1L2E.rdRhgXLA90REk910c aumRgWDxmkwASrizdh0eIG7jEXsLs7Ij_f8NnGJeflXjVkPlzMXnKt9FO4q3 zgwnVzPYccAdgAGYKi0nqbjL0bB0V3GnoW_HXXQ4WY5pTkr5rFIYKT_pvPDa 7y7N6ckQzG3L2tK1KvoZe0I.D8Y2umc8DfqAFcogX3jrux9VQhw4ljxjgszv r1Ql2HNs0qOjHTRhtVDtPYZBt071TwFImMhW.b.QFoxYq9wFO3jZgm3cvDg- - Received: from [203.94.155.226] by web126004.mail.ne1.yahoo.com via HTTP; Mon, 24 Sep 2012 18:30:09 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.434 Message-ID: <1348536609.37841.YahooMailClassic@web126004.mail.ne1.yahoo.com> Date: Mon, 24 Sep 2012 18:30:09 -0700 (PDT) From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks To: ipv6@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1688457910-719174945-1348536609=:37841" 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 Sep 2012 01:30:14 -0000 --1688457910-719174945-1348536609=:37841 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable To summarize the whole discussion and clarify the last points: RFC 3627 discouraged use of /127 and most RFCs up until RFC 5375 recommende= d using /64 even on p2p inter-router links. RFC 6164 recommends using /127 on p2p links - however there is no explicit = recommendation for /128 on device Loopbacks (e.g. for peering establishment= etc) The specific statement in RFC 6164 states that while using /127, care shoul= d be taken not to use following reserved address: (a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be assigne= d=A0 as unicast addresses, to avoid colliding with the Subnet-Router anycast add= ress=A0 (b) Addresses in which the rightmost 64 bits are assigned the highest 128 v= alues=A0 (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: ffff) SHOULD NOT be used as u= nicast addresses,=A0 to avoid colliding with reserved subnet anycast addresses Whereas the RFC 5375 recommended not to use the following: it is recommended to take the 'u' and 'g' bits into consideration and to ma= ke sure that there is no overlap with any of the following well-known addre= sses: =A0=A0 o=A0 Subnet Router Anycast Address =A0=A0 o=A0 Reserved Subnet Anycast Address =A0=A0 o=A0 Addresses used by Embedded-RP =A0=A0 o=A0 ISATAP Addresses =A0 So the questions that come out of the above discussion are: - What are the recommendations for device Loopbacks and what reserved addre= ss ranges need to be considered by network operators while using /128s for = Loopbacks (should these be followed based on RFC 5357?) - Which recommendations out of RFC 5375 and RFC 6164 should be followed by = network operators while using /127s for inter-router point-to-point links =A0 =A0 I (like many other engineers) would be looking for some feedback on=A0the a= bove two points to get a clear guideline for p2p and loopback addressing =A0 =A0 Regards Usman =A0 --- On Sat, 22/9/12, Usman Latif wrote: From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and = Device Loopbacks To: "ipv6@ietf.org" Cc: "Brian E Carpenter" Received: Saturday, 22 September, 2012, 6:07 PM Forgot to include IPv6 group email in my last email (below) Further to that, RFC 6164 states in the same statement that: "When assigning and using any /127 prefixes, the following=A0considerations= =A0 apply. Some addresses have special meanings, in particular addresses=A0 corresponding to reserved anycast addresses. When assigning prefixes=A0 (and addresses) to links, care should be taken to ensure that addresses=A0 reserved for such purposes aren't inadvertently assigned and used as=A0 unicast addresses. Otherwise, nodes may receive packets that they are=A0 not intended to receive. Specifically, assuming that a number of point-to-p= oint=A0 links will be numbered out of a single /64 prefix:=A0 =A0(a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be assi= gned=A0 as unicast addresses, to avoid colliding with the Subnet-Router anycast add= ress=A0 (b) Addresses in which the rightmost 64 bits are assigned the highest 128 v= alues=A0 (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: ffff) SHOULD NOT be used as u= nicast addresses,=A0 to avoid colliding with reserved subnet anycast addresses" One question that comes up here is that why did RFC 6164 exclude additional recommendations that were stated in RFC 5375 which stated: "it is recommended to take the 'u' and 'g' bits into consideration and to m= ake sure that there is no overlap with any of the following well-known addr= esses: =A0=A0 o=A0 Subnet Router Anycast Address =A0=A0 o=A0 Reserved Subnet Anycast Address =A0=A0 o=A0 Addresses used by Embedded-RP =A0=A0 o=A0 ISATAP Addresses" So should one only care about excluding reserved addresses as per RFC 6164 = or should we also care about reserving addresses as per RFC 5375? 5375 seems to have more special addresses covered and is also a hint that i= n the hindsight there could be more special addresses in future using bits = in lower 64-bit portion of v6 address(?) I wonder if it's possible to leave portions of lower 64 bits in v6 address = for special purposes (both EUI-64 and non EUI-64) so that we get best of bo= th worlds i.e. leave room open for future development and assignment of spe= cial addresses using portions in lower 64 bits reserved for this purpose an= d at the same time allowing users to tap into the lower 64 bit address spac= e for general address assignment purposes using portions that are not reser= ved for this purposes... Regards, Usman Sent from my iPhone On 22/09/2012, at 12:35 PM, Usman Latif wrote: On 22/09/2012, at 9:06 AM, Brian E Carpenter = wrote: On 21/09/2012 22:35, Usman Latif wrote: Thanks Wes for the feedback. ... Without this stated clearly there is likely to be some instances where read= ers interpret it the wrong way and end up assigning multiple p2p links with= /127 subnets from a single given /64 and end up having to re-address their= network in future when/if future standards use lower order 64 bits for spe= cial purposes. [WEG] Given the fact that there is a standard that documents the use of a /= 127 for P2P links (6164),=20 Wes, I think that statement is even a bit weak, since 6164 actually says: "assuming that a number of point-to-point links will be numbered out of a s= ingle /64 prefix:" so it is very clear: it is allowed by the standard to share a /64 among however many pt2pt links the operator cares to. This is *not* a wrong interpretation. As you say, any future work will need to take account of this. Brian --1688457910-719174945-1348536609=:37841 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
To summarize the whole discussion and clarify the last points:

= RFC 3627 discouraged use of /127 and most RFCs up until RFC 5375 recommende= d using /64 even on p2p inter-router links.

RFC 6164 recommends usin= g /127 on p2p links - however there is no explicit recommendation for /128 = on device Loopbacks (e.g. for peering establishment etc)

The specifi= c statement in RFC 6164 states that while using /127, care should be taken = not to use following reserved address:

(a) Addresses with all zeros in the rightmost 64 bits SHOULD = NOT be assigned 
as unicast addresses, to av= oid colliding with the Subnet-Router anycast address 
(b) Addresses in which the = rightmost 64 bits are assigned the highest 128 values 
(i.e., ffff:ffff:ffff:ff7f = to ffff:ffff:ffff: ffff) SHOULD NOT be used as unicast addresses, 
to avoid colliding with res= erved subnet anycast addresses

Whereas the RFC 5375 recommended not = to use the following:

it is recommended to take the 'u' and 'g' bits into consideration and = to make sure that there is no overlap with any of the following well-known = addresses:
   o  Subnet Router Anycast Address
   o  Reserved Subnet Anycast Address
   o  Addresses used by Embedded-RP
   o  ISATAP Addresses
 
So the questions that come out of the above discussion are:

- W= hat are the recommendations for device Loopbacks and what reserved address = ranges need to be considered by network operators while using /128s for Loo= pbacks (should these be followed based on RFC 5357?)

- Which recomme= ndations out of RFC 5375 and RFC 6164 should be followed by network operato= rs while using /127s for inter-router point-to-point links
 
 
I (like many other engineers) would be looking for some feedback on&nb= sp;the above two points to get a clear guideline for p2p and loopback addre= ssing
 
 
Regards
Usman
 


--- On Sat, 22/9/12, Usman Latif <osmankh@yaho= o.com> wrote:

From: Usman Latif <osmankh@yahoo.com>
Su= bject: Re: IPv6 address assignment for strictly point-to-point links and De= vice Loopbacks
To: "ipv6@ietf.org" <ipv6@ietf.org>
Cc: "Brian E= Carpenter" <brian.e.carpenter@gmail.com>
Received: Saturday, 22 S= eptember, 2012, 6:07 PM

Forgot to include IPv6 group email in my last email (below)
Further to that, RFC 6164 states in the same statement that:

"When assigning and using any /127 prefixes, the following considerations 
apply. Some addresses have = special meanings, in particular addresses 
corresponding to reserved a= nycast addresses. When assigning prefixes 
(and addresses) to links, c= are should be taken to ensure that addresses 
reserved for such purposes = aren't inadvertently assigned and used as 
unicast addresses. Otherwis= e, nodes may receive packets that they are 
not intended to receive. Sp= ecifically, assuming that a number of point-to-point 
links will be numbered out = of a single /64 prefix: 
 (a) Addresses with al= l zeros in the rightmost 64 bits SHOULD NOT be assigned 
as unicast addresses, to av= oid colliding with the Subnet-Router anycast address 
(b) Addresses in which the = rightmost 64 bits are assigned the highest 128 values 
(i.e., ffff:ffff:ffff:ff7f = to ffff:ffff:ffff: ffff) SHOULD NOT be used as unicast addresses, 
to avoid colliding with res= erved subnet anycast addresses"

One question that comes up = here is that why did RFC 6164 exclude
additional recommendations = that were stated in RFC 5375 which stated:

"it is recommended t= o take the 'u' and 'g' bits into consideration and to make sure that there = is no overlap with any of the following well-known addresses:
   o  Subnet Router Anycast Address
   o  Reserved Subnet Anycast Address
   o  Addresses used by Embedded-RP
   o  ISATAP Addresses"

So should one only care about excluding reserved addresses as per RFC = 6164 or should we also care about reserving addresses as per RFC 5375?

5375 seems to have more special addresses covered and is also a hint t= hat in the hindsight there could be more special addresses in future using = bits in lower 64-bit portion of v6 address(?)

I wonder if it's possible to leave portions of lower 64 bits in v6 add= ress for special purposes (both EUI-64 and non EUI-64) so that we get best = of both worlds i.e. leave room open for future development and assignment o= f special addresses using portions in lower 64 bits reserved for this purpo= se and at the same time allowing users to tap into the lower 64 bit address= space for general address assignment purposes using portions that are not = reserved for this purposes...

Regards,
Usman

Sent from my= iPhone

On 22/09/2012, at 12:35 PM, Usman Latif <osmankh@yahoo.com> wrote:


On 22/09/2012, at 9:06 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:=

On 21/09/2012 22:35, Usman Latif wrote:
Thanks Wes for the feedback.

...
Without this stated clearly there is likely= to be some instances where readers interpret it the wrong way and end up a= ssigning multiple p2p links with /127 subnets from a single given /64 and e= nd up having to re-address their network in future when/if future standards= use lower order 64 bits for special purposes.
[WEG] Given the fact that there is a standa= rd that documents the use of a /127 for P2P links (6164),

Wes, I think that statement is even a bit w= eak, since 6164 actually says:

"assuming that a number of point-to-point l= inks will be numbered out of a single /64 prefix:"

so it is very clear: it is allowed by the s= tandard to share a /64 among
however many pt2pt links the operator cares= to. This is *not* a wrong
interpretation.

As you say, any future work will need to ta= ke account of this.

Brian
<= BR>
=
--1688457910-719174945-1348536609=:37841-- From rja.lists@gmail.com Tue Sep 25 08:01:34 2012 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 C0BF11F042A for ; Tue, 25 Sep 2012 08:01:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqyzBInUfAK4 for ; Tue, 25 Sep 2012 08:01:34 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61FBF1F0C7F for ; Tue, 25 Sep 2012 08:01:33 -0700 (PDT) Received: by qcac10 with SMTP id c10so6239596qca.31 for ; Tue, 25 Sep 2012 08:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=oPVDRNhCTkM2uzg6X8vNjJubqmj7nQooLQr6S2xclMY=; b=wVsnWNMWMWuK6fuYjcyqQsv+lFYicxVuOqugL4K7Tx/EObbXysDgzCvmIoTwhIHNdA 912FfS5oWCPbVpe7zhxA3b2/VbkjdpOv/aWVEBvcZwq14k1qmMXmIoBuVl3agjuRFAVx bJbBkhKYbB5OcdNqwRI08fBxKQ1vEhbkcrGzKmSlo8CMybDK/WV6X/MsWxT+wGXQZ9Y7 oZGdAeD0yRglwlvgfaXux3xmfGTiN+330YjAmW9xhM6fMkZo31zP9zufFL9U9oSkx8Gk EEMroZw0Tz6Fks5w5dm4FJtjNK++pbLHaPRUMl25AD4GNObtrJsxa+KS9H6Pb9XKpPXs pLVg== Received: by 10.224.184.133 with SMTP id ck5mr40338375qab.42.1348585292873; Tue, 25 Sep 2012 08:01:32 -0700 (PDT) Received: from [10.30.20.13] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id fy1sm1041214qab.10.2012.09.25.08.01.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 08:01:32 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: IPv6 updates & related RA-Guard document Date: Tue, 25 Sep 2012 11:01:30 -0400 Message-Id: <09ABA7A7-8FDE-43AA-B2E6-C4C501995C53@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) 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 Sep 2012 15:01:34 -0000 Hi, Work on the RA-Guard specification in another IETF WG drove the creation of two I-Ds currently in this WG: - draft-ietf-6man-nd-extension-headers - draft-ietf-6man-oversized-header-chain The RA Guard work in the other IETF WG is currently *blocked* pending the 6MAN WG approving the 2 I-Ds above. In turn, the RA Guard work is a high priority for all kinds of network operators (i.e. not just ISPs), because it provides practical risk reduction and risk mitigation for a real-world operational security issue. RA Guard implementers can't really move forward until the RA Guard I-D is approved by the other WG -- which I believe is at present blocked on the 2 I-Ds at top being approved by the 6MAN WG. My understanding is that the technical content in these 2 IPv6 Spec update I-Ds has been presented more than once. Further, the drafts have been around long enough that active 6MAN WG participants already should have read them. I am a bit confused about where we stand with these today, so I have two questions: - Where does the 6MAN WG stand with these two drafts ? - How can we move them forward (soon -- i.e. BEFORE the next IETF in-person meeting), so that the other active IETF work (i.e. RA-Guard) can be unblocked ? - Can these go into WG Last Call now ? Thanks, Ran From randy@psg.com Tue Sep 25 09:52:54 2012 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 BF2FF21F8943 for ; Tue, 25 Sep 2012 09:52:53 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFjCinMEpR1L for ; Tue, 25 Sep 2012 09:52:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 7F42C21F8932 for ; Tue, 25 Sep 2012 09:52:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TGYNP-000Dvf-7m; Tue, 25 Sep 2012 16:52:51 +0000 Date: Tue, 25 Sep 2012 18:52:50 +0200 Message-ID: From: Randy Bush To: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks In-Reply-To: References: <1348211033.52674.YahooMailClassic@web126005.mail.ne1.yahoo.com> <0BB03569-6F5F-43AC-9012-C82C85A43C00@yahoo.com> <2671C6CDFBB59E47B64C10B3E0BD59235F961497@PRVPEXVS15.corp.twcable.com> <505CF2DC.3050401@gmail.com> <984B69E6-CBB4-4CD2-B624-D2F5B98E73B2@yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII 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 Sep 2012 16:52:54 -0000 perhaps we learned some things over time? randy From osmankh@yahoo.com Tue Sep 25 21:00:38 2012 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 576501F0CE5 for ; Tue, 25 Sep 2012 21:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz3pFSEMbMXo for ; Tue, 25 Sep 2012 21:00:37 -0700 (PDT) Received: from nm12-vm1.bullet.mail.ne1.yahoo.com (nm12-vm1.bullet.mail.ne1.yahoo.com [98.138.91.41]) by ietfa.amsl.com (Postfix) with SMTP id B31E91F0CD3 for ; Tue, 25 Sep 2012 21:00:36 -0700 (PDT) Received: from [98.138.226.177] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 26 Sep 2012 04:00:32 -0000 Received: from [98.138.89.163] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 26 Sep 2012 04:00:32 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 26 Sep 2012 04:00:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 735534.10397.bm@omp1019.mail.ne1.yahoo.com Received: (qmail 46989 invoked by uid 60001); 26 Sep 2012 04:00:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348632032; bh=mw+qW6RiwdBlYO8oFCfrnqD4WBJt0J+Wf3RESwZ63Yc=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=1De5OIzX/ybLwGkAxtKueoKjFNGVNbSSWVOJJ7sMJ4zY65dRv/E00uOPuD9oGxmHrdLVowix+9jzSwcn7isLtB82OfXMXBPaRYJ5R6yoFFz1lQBPyBZQXIRvJp+mgOYZdDJt8M9C7YgaJo2Cm+PkauVxNnFtrfaqCcHoOWaoj+E= 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; b=Dy8WzFy6DYyFaMIJqKbOqtKyyUy2FIBI/txEfHaIZw02BYjWln9WE69gVWauF5h4IJO82wlnATZ4kBt+q8Xs877Cgt4x34uzZZgRWMUDcHch2qi/YktMwI5Ws0e+V7Jvh3cag8NcAlQWxhK0SPD7wPsUjCpzjPvRI+GuePrk1PA=; X-YMail-OSG: svZTmmcVM1msVaUli9UBN_2DpjJLUpLaehHvFJJ.F9W7Ju1 q7eTbbIAeQKHo4dcj6PX32kZhm_oNycIvdngtAL5cqconJgjCr7TiI5M8cv7 assjAPq.GK8dUkmEj54gW3AevZOyRIQV4EtUQ5SqpsqeJJl2182k9hO8G2y4 wZPubRzR8OIfGsIG4e5P4UM3NIUnDTZ3ZxPSZM9ZrA03DNjbyAx9SALa12_p I0Js7KLpAwReBRochMD1ddlaH0VXQOzds6nNKbUdij4r3hsco.ZZ6ZmZQK__ aa1Ytt52yIOb4I7N6lFUGCQxySOXce2QlxQPjp9_YU5kePGrcFoKC3idocnK 6_LZFLijGp3lTJ1NTOodB_Rr.NyBaFduPtTN1aNReqZYPah4f0V6JhR8AaOt 287AMi3zVMn.ic2b4jy6CnGdwESyuqXH_YAYuXQx8n96wdlDmxoRfugA50y. LWZU.sddfiOmlys8ZIBn5_A2wK9xLzaX3zNyGGEqPm3zb7psQUu7oQIJC53P TBiP.NUmdwLbQDWRI6kkyueIFNeSqlXmR5Q279GcWJw5mO1grHwWEZ51wgFs 1DUbL9gUuvo0QbghwIi9w0M8BOiHYPI.Fjw0ujD_ahvwRq6V7c0C4 Received: from [203.94.155.226] by web126005.mail.ne1.yahoo.com via HTTP; Tue, 25 Sep 2012 21:00:32 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.434 Message-ID: <1348632032.36928.YahooMailClassic@web126005.mail.ne1.yahoo.com> Date: Tue, 25 Sep 2012 21:00:32 -0700 (PDT) From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks To: Randy Bush MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1833503604-1481248262-1348632032=:36928" 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, 26 Sep 2012 04:00:38 -0000 --1833503604-1481248262-1348632032=:36928 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Based on the response i have received so far it appears that there are stil= l gaps in our approach towards IPv6 addressing (maybe the original way the = stack was written also is not ideal - but lets not go there and try to find= the best way out with what we've got) IMO RFC 6164 although being very authoritative and direct about use of /127= (from the same /64) on each p2p link is not giving us any insight into oth= er current (or future) reserved addresses that were explained in more detai= l in RFC 5375 so in doing that RFC 6164 is raising doubts in our minds abou= t using /127 (from the same /64) for p2p router links and also there is no = talk in RFC 6164 about use of /128 loopbacks and what cautions are needed t= here - whereas we saw that in RFC 5375 (although informational only) there = was a more comprehensive discussion around use of shorter length prefixes f= or p2p links and loopbacks The motivations for RFC 6164 can also be debated here e.g: Ping-Pong issue is dealt with RFC 4443 Neighbor Cache exhaustion on p2p links=A0can be controlled if we use filter= s to restrict a router to perform ND for only the known IP on the far-end o= f the p2p link or a similar mechanism that provides control over creating n= eighbor cache only for the known IP on the farend (although this would requ= ire some additional config overhead but is worth considering) Also there are so many other scenarios where this would still pose an issue= wherever we have /64 assigned so better to provide a more holistic solutio= n than to only consider router p2p links only. Also its a good idea to encompass recommendations for p2p and loopbacks (an= d for that matter any assignment where prefix length is going beyond /64 in= to smaller subnets) into one standard track because the cautions and potent= ial overlap issues that may exist for a /127 would pretty much be similar f= or /128 or any prefix that goes into the lower-64 bit territory... =A0 One=A0major concern I have with using /127 and /128 on p2p and loopbacks re= spectively is that we need to be careful that there are existing (ISATAP et= c) and potentially future implementations that would use/reserve bits in th= e lower 64 bits -so unless we set aside bit boundaries in the lower 64 bits= , we are likely to overlap with these... which is why if we use /127 with a= whole /64 reserved for the p2p subnet, then it should be okay but if /127 = or /128s are numbered from the same /64 consecutively, then obviously its l= ikely that the reserved bits used by other implementations would overlap. W= hen this happens, any scenario where the router (which has this overlap) is= =A0SRC/DST of=A0packets would be confused whether to interpret those lower-= 64 bits as simple global unicast prefix or try to treat the lower-64 bits i= n a different way (according to the protocol implementation which is using = that bit pattern). Pls let me know if there is work being done in this space... Regards Usman =A0 On 26/09/2012, at 2:52 AM, Randy Bush wrote: perhaps we learned some things over time? randy From:=A0Usman Latif Date:=A025 September 2012 11:30:09 AM AEST To:=A0ipv6@ietf.org Subject:=A0Re: IPv6 address assignment for strictly point-to-point links an= d Device Loopbacks To summarize the whole discussion and clarify the last points: RFC 3627 discouraged use of /127 and most RFCs up until RFC 5375 recommende= d using /64 even on p2p inter-router links. RFC 6164 recommends using /127 on p2p links - however there is no explicit = recommendation for /128 on device Loopbacks (e.g. for peering establishment= etc) The specific statement in RFC 6164 states that while using /127, care shoul= d be taken not to use following reserved address: (a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be assigne= d=A0 as unicast addresses, to avoid colliding with the Subnet-Router anycast add= ress=A0 (b) Addresses in which the rightmost 64 bits are assigned the highest 128 v= alues=A0 (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: ffff) SHOULD NOT be used as u= nicast addresses,=A0 to avoid colliding with reserved subnet anycast addresses Whereas the RFC 5375 recommended not to use the following: it is recommended to take the 'u' and 'g' bits into consideration and to ma= ke sure that there is no overlap with any of the following well-known addre= sses: =A0=A0 o=A0 Subnet Router Anycast Address =A0=A0 o=A0 Reserved Subnet Anycast Address =A0=A0 o=A0 Addresses used by Embedded-RP =A0=A0 o=A0 ISATAP Addresses =A0 So the questions that come out of the above discussion are: - What are the recommendations for device Loopbacks and what reserved addre= ss ranges need to be considered by network operators while using /128s for = Loopbacks (should these be followed based on RFC 5357?) - Which recommendations out of RFC 5375 and RFC 6164 should be followed by = network operators while using /127s for inter-router point-to-point links =A0 =A0 I (like many other engineers) would be looking for some feedback on=A0the a= bove two points to get a clear guideline for p2p and loopback addressing =A0 =A0 Regards Usman =A0 --- On=A0Sat, 22/9/12, Usman Latif=A0=A0wrote: From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and = Device Loopbacks To: "ipv6@ietf.org" Cc: "Brian E Carpenter" Received: Saturday, 22 September, 2012, 6:07 PM Forgot to include IPv6 group email in my last email (below) Further to that, RFC 6164 states in the same statement that: "When assigning and using any /127 prefixes, the following=A0considerations= =A0 apply. Some addresses have special meanings, in particular addresses=A0 corresponding to reserved anycast addresses. When assigning prefixes=A0 (and addresses) to links, care should be taken to ensure that addresses=A0 reserved for such purposes aren't inadvertently assigned and used as=A0 unicast addresses. Otherwise, nodes may receive packets that they are=A0 not intended to receive. Specifically, assuming that a number of point-to-p= oint=A0 links will be numbered out of a single /64 prefix:=A0 =A0(a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be assi= gned=A0 as unicast addresses, to avoid colliding with the Subnet-Router anycast add= ress=A0 (b) Addresses in which the rightmost 64 bits are assigned the highest 128 v= alues=A0 (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff: ffff) SHOULD NOT be used as u= nicast addresses,=A0 to avoid colliding with reserved subnet anycast addresses" One question that comes up here is that why did RFC 6164 exclude additional recommendations that were stated in RFC 5375 which stated: "it is recommended to take the 'u' and 'g' bits into consideration and to m= ake sure that there is no overlap with any of the following well-known addr= esses: =A0=A0 o=A0 Subnet Router Anycast Address =A0=A0 o=A0 Reserved Subnet Anycast Address =A0=A0 o=A0 Addresses used by Embedded-RP =A0=A0 o=A0 ISATAP Addresses" So should one only care about excluding reserved addresses as per RFC 6164 = or should we also care about reserving addresses as per RFC 5375? 5375 seems to have more special addresses covered and is also a hint that i= n the hindsight there could be more special addresses in future using bits = in lower 64-bit portion of v6 address(?) I wonder if it's possible to leave portions of lower 64 bits in v6 address = for special purposes (both EUI-64 and non EUI-64) so that we get best of bo= th worlds i.e. leave room open for future development and assignment of spe= cial addresses using portions in lower 64 bits reserved for this purpose an= d at the same time allowing users to tap into the lower 64 bit address spac= e for general address assignment purposes using portions that are not reser= ved for this purposes... Regards, Usman Sent from my iPhone On 22/09/2012, at 12:35 PM, Usman Latif wrote: On 22/09/2012, at 9:06 AM, Brian E Carpenter = wrote: On 21/09/2012 22:35, Usman Latif wrote: Thanks Wes for the feedback. ... Without this stated clearly there is likely to be some instances where read= ers interpret it the wrong way and end up assigning multiple p2p links with= /127 subnets from a single given /64 and end up having to re-address their= network in future when/if future standards use lower order 64 bits for spe= cial purposes. [WEG] Given the fact that there is a standard that documents the use of a /= 127 for P2P links (6164),=A0 Wes, I think that statement is even a bit weak, since 6164 actually says: "assuming that a number of point-to-point links will be numbered out of a s= ingle /64 prefix:" so it is very clear: it is allowed by the standard to share a /64 among however many pt2pt links the operator cares to. This is *not* a wrong interpretation. As you say, any future work will need to take account of this. Brian --1833503604-1481248262-1348632032=:36928 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Based on the response i have received so far it appears that there are= still gaps in our approach towards IPv6 addressing (maybe the original way= the stack was written also is not ideal - but lets not go there and try to= find the best way out with what we've got)

IMO RFC 6164 although being very authoritative and direct about use of= /127 (from the same /64) on each p2p link is not giving us any insight int= o other current (or future) reserved addresses that were explained in more = detail in RFC 5375 so in doing that RFC 6164 is raising doubts in our minds= about using /127 (from the same /64) for p2p router links and also there i= s no talk in RFC 6164 about use of /128 loopbacks and what cautions are nee= ded there - whereas we saw that in RFC 5375 (although informational only) t= here was a more comprehensive discussion around use of shorter length prefi= xes for p2p links and loopbacks

The motivations for RFC 6164 can also be debated here e.g:

Ping-Pong issue is dealt with RFC 4443

Neighbor Cache exhaustion on p2p links can be controlled if we us= e filters to restrict a router to perform ND for only the known IP on the f= ar-end of the p2p link or a similar mechanism that provides control over cr= eating neighbor cache only for the known IP on the farend (although this wo= uld require some additional config overhead but is worth considering)

Also there are so many other scenarios where this would still pose an = issue wherever we have /64 assigned so better to provide a more holistic so= lution than to only consider router p2p links only.

Also its a good idea to encompass recommendations for p2p and loopback= s (and for that matter any assignment where prefix length is going beyond /= 64 into smaller subnets) into one standard track because the cautions and p= otential overlap issues that may exist for a /127 would pretty much be simi= lar for /128 or any prefix that goes into the lower-64 bit territory...
 
One major concern I have with using /127 and /128 on p2p and loop= backs respectively is that we need to be careful that there are existing (I= SATAP etc) and potentially future implementations that would use/reserve bi= ts in the lower 64 bits -so unless we set aside bit boundaries in the lower= 64 bits, we are likely to overlap with these... which is why if we use /12= 7 with a whole /64 reserved for the p2p subnet, then it should be okay but = if /127 or /128s are numbered from the same /64 consecutively, then obvious= ly its likely that the reserved bits used by other implementations would ov= erlap. When this happens, any scenario where the router (which has this ove= rlap) is SRC/DST of packets would be confused whether to interpre= t those lower-64 bits as simple global unicast prefix or try to treat the l= ower-64 bits in a different way (according to the protocol implementation w= hich is using that bit pattern).

Pls let me know if there is work being done in this space...

Regards
Usman
 


On 26/09/2012, at 2:52 AM, Randy Bush <randy@psg.com> wrote:

perhaps we learned some things over time?

randy


From: Usman Latif <os= mankh@yahoo.com>
Date: 25 September 2012 11:30:09 AM = AEST
To: ipv6@ietf.org
= Subject: Re: IPv6 address assignment for strictly point-to-p= oint links and Device Loopbacks

<= /TBODY>
To summarize the whole discussion and clarify the last points:

= RFC 3627 discouraged use of /127 and most RFCs up until RFC 5375 recommende= d using /64 even on p2p inter-router links.

RFC 6164 recommends usin= g /127 on p2p links - however there is no explicit recommendation for /128 = on device Loopbacks (e.g. for peering establishment etc)

The specifi= c statement in RFC 6164 states that while using /127, care should be taken = not to use following reserved address:

(a) Addresses with all zeros in the rightmost 64 bits SHOULD= NOT be assigned 
as unicast addresses, to a= void colliding with the Subnet-Router anycast address 
(b) Addresses in which the= rightmost 64 bits are assigned the highest 128 values 
(i.e., ffff:ffff:ffff:ff7f= to ffff:ffff:ffff: ffff) SHOULD NOT be used as unicast addresses, 
to avoid colliding with re= served subnet anycast addresses

Whereas the RFC 5375 recommended not= to use the following:

it is recommended to take the 'u' and 'g' bits into consideration and = to make sure that there is no overlap with any of the following well-known = addresses:
   o  Subnet Router Anycast Address
   o  Reserved Subnet Anycast Address
   o  Addresses used by Embedded-RP
   o  ISATAP Addresses
 
So the questions that come out of the above discussion are:

- W= hat are the recommendations for device Loopbacks and what reserved address = ranges need to be considered by network operators while using /128s for Loo= pbacks (should these be followed based on RFC 5357?)

- Which recomme= ndations out of RFC 5375 and RFC 6164 should be followed by network operato= rs while using /127s for inter-router point-to-point links
 
 
I (like many other engineers) would be looking for some feedback on&nb= sp;the above two points to get a clear guideline for p2p and loopback addre= ssing
 
 
Regards
Usman
 


--- On Sat, 22/9/12, Usman Latif <osmankh@yahoo.com> wrote:

From: Usman Latif <osmankh@yahoo.com>
Subject: Re: IPv6 address assignment fo= r strictly point-to-point links and Device Loopbacks
To: "ipv6@ietf.org" <ipv6@i= etf.org>
Cc: "Brian E Carpenter" <brian.e.carpenter@gmail.com>
Received: Saturday, = 22 September, 2012, 6:07 PM

Forgot to include IPv6 group email in my last email (below)
Further to that, RFC 6164 states in the same statement that:

"When assigning and using any /127 prefixes, the following considerations 
apply. Some addresses have= special meanings, in particular addresses 
corresponding to reserved = anycast addresses. When assigning prefixes 
(and addresses) to links, = care should be taken to ensure that addresses 
reserved for such purposes= aren't inadvertently assigned and used as 
unicast addresses. Otherwi= se, nodes may receive packets that they are 
not intended to receive. S= pecifically, assuming that a number of point-to-point 
links will be numbered out= of a single /64 prefix: 
 (a) Addresses with a= ll zeros in the rightmost 64 bits SHOULD NOT be assigned 
as unicast addresses, to a= void colliding with the Subnet-Router anycast address 
(b) Addresses in which the= rightmost 64 bits are assigned the highest 128 values 
(i.e., ffff:ffff:ffff:ff7f= to ffff:ffff:ffff: ffff) SHOULD NOT be used as unicast addresses, 
to avoid colliding with re= served subnet anycast addresses"

One question that comes up= here is that why did RFC 6164 exclude
additional recommendations= that were stated in RFC 5375 which stated:

"it is recommended = to take the 'u' and 'g' bits into consideration and to make sure that there= is no overlap with any of the following well-known addresses:
   o  Subnet Router Anycast Address
   o  Reserved Subnet Anycast Address
   o  Addresses used by Embedded-RP
   o  ISATAP Addresses"

So should one only care about excluding reserved addresses as per RFC = 6164 or should we also care about reserving addresses as per RFC 5375?

5375 seems to have more special addresses covered and is also a hint t= hat in the hindsight there could be more special addresses in future using = bits in lower 64-bit portion of v6 address(?)

I wonder if it's possible to leave portions of lower 64 bits in v6 add= ress for special purposes (both EUI-64 and non EUI-64) so that we get best = of both worlds i.e. leave room open for future development and assignment o= f special addresses using portions in lower 64 bits reserved for this purpo= se and at the same time allowing users to tap into the lower 64 bit address= space for general address assignment purposes using portions that are not = reserved for this purposes...

Regards,
Usman

Sent from my= iPhone

On 22/09/2012, at 12:35 PM, Usman Latif <osmankh@yahoo.com> wrote:


On 22/09/2012, at 9:06 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:=

On 21/09/2012 22:35, Usman Latif wrote:
Thanks Wes for the feedback.

...
Without this stated clearly there is likely= to be some instances where readers interpret it the wrong way and end up a= ssigning multiple p2p links with /127 subnets from a single given /64 and e= nd up having to re-address their network in future when/if future standards= use lower order 64 bits for special purposes.
[WEG] Given the fact that there is a standa= rd that documents the use of a /127 for P2P links (6164), 
<= /BLOCKQUOTE>

Wes, I think that statement is even a bit w= eak, since 6164 actually says:

"assuming that a number of point-to-point l= inks will be numbered out of a single /64 prefix:"

so it is very clear: it is allowed by the s= tandard to share a /64 among
however many pt2pt links the operator cares= to. This is *not* a wrong
interpretation.

As you say, any future work will need to ta= ke account of this.

Brian
--1833503604-1481248262-1348632032=:36928-- From sthaug@nethelp.no Tue Sep 25 21:40:30 2012 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 579AC21F867B for ; Tue, 25 Sep 2012 21:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqVQFVTcZB6l for ; Tue, 25 Sep 2012 21:40:29 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 6538721F867E for ; Tue, 25 Sep 2012 21:40:28 -0700 (PDT) Received: (qmail 26040 invoked from network); 26 Sep 2012 04:40:26 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 26 Sep 2012 04:40:26 -0000 Date: Wed, 26 Sep 2012 06:40:26 +0200 (CEST) Message-Id: <20120926.064026.74728234.sthaug@nethelp.no> To: osmankh@yahoo.com Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks From: sthaug@nethelp.no In-Reply-To: <1348632032.36928.YahooMailClassic@web126005.mail.ne1.yahoo.com> References: <1348632032.36928.YahooMailClassic@web126005.mail.ne1.yahoo.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii 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: Wed, 26 Sep 2012 04:40:30 -0000 > IMO RFC 6164 although being very authoritative and direct about use of /127 (from the same /64) on each p2p link is not giving us any insight into other current (or future) reserved addresses that were explained in more detail in RFC 5375 so in doing that RFC 6164 is raising doubts in our minds about using /127 (from the same /64) for p2p router links and also there is no talk in RFC 6164 about use of /128 loopbacks and what cautions are needed there - whereas we saw that in RFC 5375 (although informational only) there was a more comprehensive discussion around use of shorter length prefixes for p2p links and loopbacks *You* may feel that RFC 6164 is raising doubt. I don't. I'm glad to see an RFC that fills a needed hole, and clearly describes something which is already used by service providers (including my employer). Steinar Haug, Nethelp consulting, sthaug@nethelp.no From mohacsi@niif.hu Wed Sep 26 00:41:27 2012 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 09B3B21F87E3 for ; Wed, 26 Sep 2012 00:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWxJYXBUAEMG for ; Wed, 26 Sep 2012 00:41:26 -0700 (PDT) Received: from strudel.ki.iif.hu (strudel.ki.iif.hu [IPv6:2001:738:0:411:20f:1fff:fe6e:ec1e]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8AF21F867C for ; Wed, 26 Sep 2012 00:41:25 -0700 (PDT) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by strudel.ki.iif.hu (Postfix) with ESMTP id 6F6AD389; Wed, 26 Sep 2012 09:41:24 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from strudel.ki.iif.hu ([IPv6:::ffff:193.6.222.244]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id mzxqPon2kjrP; Wed, 26 Sep 2012 09:41:21 +0200 (CEST) Received: by strudel.ki.iif.hu (Postfix, from userid 9002) id 08A663A3; Wed, 26 Sep 2012 09:41:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by strudel.ki.iif.hu (Postfix) with ESMTP id 014F4389; Wed, 26 Sep 2012 09:41:20 +0200 (CEST) Date: Wed, 26 Sep 2012 09:41:20 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@strudel.ki.iif.hu To: RJ Atkinson Subject: Re: IPv6 updates & related RA-Guard document In-Reply-To: <09ABA7A7-8FDE-43AA-B2E6-C4C501995C53@gmail.com> Message-ID: References: <09ABA7A7-8FDE-43AA-B2E6-C4C501995C53@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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, 26 Sep 2012 07:41:27 -0000 On Tue, 25 Sep 2012, RJ Atkinson wrote: > Hi, > > Work on the RA-Guard specification in another IETF WG > drove the creation of two I-Ds currently in this WG: > - draft-ietf-6man-nd-extension-headers > - draft-ietf-6man-oversized-header-chain > > The RA Guard work in the other IETF WG is currently > *blocked* pending the 6MAN WG approving the 2 I-Ds above. > > In turn, the RA Guard work is a high priority for all kinds > of network operators (i.e. not just ISPs), because it provides > practical risk reduction and risk mitigation for a real-world > operational security issue. > > RA Guard implementers can't really move forward until the > RA Guard I-D is approved by the other WG -- which I believe > is at present blocked on the 2 I-Ds at top being approved > by the 6MAN WG. > > My understanding is that the technical content in these > 2 IPv6 Spec update I-Ds has been presented more than once. > > Further, the drafts have been around long enough that active > 6MAN WG participants already should have read them. > > I am a bit confused about where we stand with these today, > so I have two questions: > > - Where does the 6MAN WG stand with these two drafts ? > > - How can we move them forward (soon -- i.e. BEFORE the > next IETF in-person meeting), so that the other active > IETF work (i.e. RA-Guard) can be unblocked ? RA-guard work mostly done at v6ops. http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-08 http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-04 Probably drafts should be circulated on v6ops mailing list and have support from there. > > - Can these go into WG Last Call now ? > > Thanks, > > Ran > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From otroan@employees.org Wed Sep 26 01:36:16 2012 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 C041421F845B for ; Wed, 26 Sep 2012 01:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qTcvEX+uGbK for ; Wed, 26 Sep 2012 01:36:16 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 235B421F8455 for ; Wed, 26 Sep 2012 01:36:16 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 96D0A5E10; Wed, 26 Sep 2012 01:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=G0krfStPk9S442FaZxw8P mEkl5E=; b=tGz876L6vRAKQ4jPR+lu0T6jdVdI2p+QxPxupEKQ3JaGEpv7TnEjK to/qK7Sn7ESyaNnVsZ7UHCHd48/AZfPpVgrtRTrSGon1ZMPAPMb89GA9ncNea9qp 4lpPpPv2pM8F4TL2bXhNVcg1mjtvLT6CRDV7ZUzFMrY+CAqJZgLkMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=AZvo4MlMC29XWV2 M173/oumEiiEmUoy7N2iRE90+8UZQraJMFSta8STAB91lTkgcjNepL60VBL69QSR 28V8cBUHlOWDT8m0BHj2/J59019O1xR7/I1Sllz0APIKz0WZHsno9bxPYw9Yce7g Nmff3hsN95l7JWffvHVfIt1S8oZ4= Received: from dhcp-lys01-vla250-10-147-112-179.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 791A55D91; Wed, 26 Sep 2012 01:36:14 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_ACA9C84F-371B-4742-9B2F-E07FF25CFEDD"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <1348632032.36928.YahooMailClassic@web126005.mail.ne1.yahoo.com> Date: Wed, 26 Sep 2012 10:36:11 +0200 Message-Id: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> References: <1348632032.36928.YahooMailClassic@web126005.mail.ne1.yahoo.com> To: Usman Latif X-Mailer: Apple Mail (2.1498) 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, 26 Sep 2012 08:36:16 -0000 --Apple-Mail=_ACA9C84F-371B-4742-9B2F-E07FF25CFEDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > Also its a good idea to encompass recommendations for p2p and = loopbacks (and for that matter any assignment where prefix length is = going beyond /64 into smaller subnets) into one standard track because = the cautions and potential overlap issues that may exist for a /127 = would pretty much be similar for /128 or any prefix that goes into the = lower-64 bit territory... > One major concern I have with using /127 and /128 on p2p and loopbacks = respectively is that we need to be careful that there are existing = (ISATAP etc) and potentially future implementations that would = use/reserve bits in the lower 64 bits -so unless we set aside bit = boundaries in the lower 64 bits, we are likely to overlap with these... = which is why if we use /127 with a whole /64 reserved for the p2p = subnet, then it should be okay but if /127 or /128s are numbered from = the same /64 consecutively, then obviously its likely that the reserved = bits used by other implementations would overlap. When this happens, any = scenario where the router (which has this overlap) is SRC/DST of packets = would be confused whether to interpret those lower-64 bits as simple = global unicast prefix or try to treat the lower-64 bits in a different = way (according to the protocol implementation which is using that bit = pattern). a few general points: - the 64 bit boundary is a "policy". implementations should handle any = prefix length. implementations should, and as far as I know do, consider all bits in = the address as transparent. - a loopback interface using a /128 cannot by definition overlap with = anything else.=20 - for a point to point link the operator should know if there = applications at either of two end points requiring the use of reserved addresses, if so the link must use a /64 otherwise /127 is = fine. these are operational choices, and I don't see a need to change IPv6 = addressing architecture or protocol specifications. cheers, Ole= --Apple-Mail=_ACA9C84F-371B-4742-9B2F-E07FF25CFEDD Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTI2MDgzNjEyWjAjBgkqhkiG9w0BCQQxFgQU3vQVjlOijLGojIOm z1KGywaAYFkwggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAgqNoeFMdfmZdTDrRkMO9 S3VdwI2mEfOwhm6sE+BBLXl/a+WL1lIZ/t4MpyDCwEWbZDohT5X6QoEd1+FrOATG4jzxvdVUZ/OS Y0mCzaRFwjLZdnuD0nx5Dhxkh/4DozsgMvzUxzbe/KjwccKkjcs0Gk7SksZO17uePzr0TknHNbzr ryb6zaUqHM+VQD7C94/QeiowxyJV13I/IIUw418xAb3STBWMTIIRAWGpy4f5Fzc+l/CEglBVc1Gm iZv7Rh85TYYCRHdqBAOK0PReIAL2AqJzUqgV4e+Ie4xrnfme0rIECIH/wTe8jEiOMmJz4KPPNSvw QcbdsvFjjoti3HmIbgAAAAAAAA== --Apple-Mail=_ACA9C84F-371B-4742-9B2F-E07FF25CFEDD-- From fgont@si6networks.com Wed Sep 26 06:14:46 2012 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 9C8F321F8699 for ; Wed, 26 Sep 2012 06:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1luYCLtdrtE for ; Wed, 26 Sep 2012 06:14:46 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 05A2F21F8625 for ; Wed, 26 Sep 2012 06:14:46 -0700 (PDT) Received: from 88.160-241-81.adsl-dyn.isp.belgacom.be ([81.241.160.88] helo=[10.0.0.83]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TGrRo-0006Ti-ST; Wed, 26 Sep 2012 15:14:40 +0200 Message-ID: <5062FFC0.7010108@si6networks.com> Date: Wed, 26 Sep 2012 15:14:40 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Mohacsi Janos Subject: Re: IPv6 updates & related RA-Guard document References: <09ABA7A7-8FDE-43AA-B2E6-C4C501995C53@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, RJ Atkinson 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 Sep 2012 13:14:46 -0000 On 09/26/2012 09:41 AM, Mohacsi Janos wrote: > RA-guard work mostly done at v6ops. > http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-08 > http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-04 draft-ietf-v6ops-ra-guard-implementation cannot be published as RFC because of normative references to draft-ietf-6man-nd-extension-headers and draft-ietf-6man-oversized header chains. i.e., the 6man drafts need to be published as RFCs along or before draft-ietf-v6ops-ra-guard-implementation. FWIW, my take is that the aforementioned two 6man documents are ready for WGLC. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rja.lists@gmail.com Wed Sep 26 06:43:14 2012 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 7BA5321F8794 for ; Wed, 26 Sep 2012 06:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-xQ9ieBs8Al for ; Wed, 26 Sep 2012 06:43:14 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id DB7D621F8792 for ; Wed, 26 Sep 2012 06:43:13 -0700 (PDT) Received: by qabj40 with SMTP id j40so1151016qab.10 for ; Wed, 26 Sep 2012 06:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=dzFiXEPZG8E9h0WNkMS9+C75rcBDSRKrGQb5jDCaSjg=; b=fJpZc9cFUn+kmHlVUKCgNC2EhCaQMUDVSLlKqaX2EQG7tcEArKX9JUOAeLOSQpvq/6 d3LFqVsluBAh2PB7pBymZOa92wyP4AKdiZS02iy4BfEEDaoxFw4iM0HDbFlYR5ctXYoy BD/P67RMg+V8VJ0aXqlNYc/GuC3N3gorEwYuuOMTaiAnHyz2mS/qO1qtTnLo5FSRj0ou Pkb5h0UoSxdrUXePcMgwJeDeHnU7RUxvIL0hmDQ07P/pnqNPr0za9Sx4xEgZD9guri54 dS7OsYyhYK4y/8o+e6koMEJRrNDXx+WKWT86zUEUJdEyOHlfyzEJiyjG3m2zwX83h5aM bzfw== Received: by 10.224.209.8 with SMTP id ge8mr2243230qab.0.1348666993423; Wed, 26 Sep 2012 06:43:13 -0700 (PDT) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id ck11sm4793821qab.17.2012.09.26.06.43.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Sep 2012 06:43:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) Subject: Re: IPv6 updates & related RA-Guard document From: RJ Atkinson In-Reply-To: Date: Wed, 26 Sep 2012 09:43:10 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3AD20224-EBC3-463C-9433-4015BBC67EF9@gmail.com> References: <09ABA7A7-8FDE-43AA-B2E6-C4C501995C53@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1278) 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 Sep 2012 13:43:14 -0000 On 26 Sep 2012, at 03:41 , Mohacsi Janos wrote: > RA-guard work mostly done at v6ops. > http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-08 > http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-04 > > Probably drafts should be circulated on v6ops mailing list > and have support from there. IETF v6ops WG Charter does not include updates to the IPv6 specifications. Quoting from this WG Charter: "Specifying any protocols or transition mechanisms is out of scope of the WG." IETF 6MAN WG Charter DOES include updates to the IPv6 specifications, again quoting from this WG Charter: "The working group will address protocol limitations/issues discovered during deployment and operation." This is why the draft-*-ra-guard-* documents (quoted above) belong in the IETF v6ops WG, while the 2 different I-Ds that I mentioned belong here in the IETF 6MAN WG. Now, in practice, the 2 draft-ietf-6man-* I-Ds that I mentioned before already have been reviewed by many folks in v6ops, as part of examining the RA Guard documents, and I believe there is broad support for these updates within v6ops. However, these 2 protocol specification updates are required to be handled by the IETF 6MAN WG, simply as a matter of the applicable IETF WG charters and usual IETF processes. Yours Ran From mohacsi@niif.hu Wed Sep 26 07:43:31 2012 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 8C5F821F86EC for ; Wed, 26 Sep 2012 07:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.446 X-Spam-Level: X-Spam-Status: No, score=0.446 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvfBBSdUbEfJ for ; Wed, 26 Sep 2012 07:43:31 -0700 (PDT) Received: from strudel.ki.iif.hu (strudel.ki.iif.hu [IPv6:2001:738:0:411:20f:1fff:fe6e:ec1e]) by ietfa.amsl.com (Postfix) with ESMTP id F35BB21F86E5 for ; Wed, 26 Sep 2012 07:43:30 -0700 (PDT) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by strudel.ki.iif.hu (Postfix) with ESMTP id 97240D0; Wed, 26 Sep 2012 16:43:29 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from strudel.ki.iif.hu ([IPv6:::ffff:193.6.222.244]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id JAQi688fwPeI; Wed, 26 Sep 2012 16:43:23 +0200 (CEST) Received: by strudel.ki.iif.hu (Postfix, from userid 9002) id 129193BC; Wed, 26 Sep 2012 16:43:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by strudel.ki.iif.hu (Postfix) with ESMTP id 0993BD0; Wed, 26 Sep 2012 16:43:23 +0200 (CEST) Date: Wed, 26 Sep 2012 16:43:23 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@strudel.ki.iif.hu To: RJ Atkinson Subject: Re: IPv6 updates & related RA-Guard document In-Reply-To: <3AD20224-EBC3-463C-9433-4015BBC67EF9@gmail.com> Message-ID: References: <09ABA7A7-8FDE-43AA-B2E6-C4C501995C53@gmail.com> <3AD20224-EBC3-463C-9433-4015BBC67EF9@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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, 26 Sep 2012 14:43:31 -0000 On Wed, 26 Sep 2012, RJ Atkinson wrote: > > On 26 Sep 2012, at 03:41 , Mohacsi Janos wrote: >> RA-guard work mostly done at v6ops. >> http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-08 >> http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-04 >> >> Probably drafts should be circulated on v6ops mailing list >> and have support from there. > > IETF v6ops WG Charter does not include updates to the > IPv6 specifications. Quoting from this WG Charter: > "Specifying any protocols or transition > mechanisms is out of scope of the WG." > > IETF 6MAN WG Charter DOES include updates to the > IPv6 specifications, again quoting from this WG Charter: > "The working group will address protocol limitations/issues > discovered during deployment and operation." > > This is why the draft-*-ra-guard-* documents (quoted above) > belong in the IETF v6ops WG, while the 2 different I-Ds > that I mentioned belong here in the IETF 6MAN WG. > > Now, in practice, the 2 draft-ietf-6man-* I-Ds that I mentioned > before already have been reviewed by many folks in v6ops, > as part of examining the RA Guard documents, and I believe > there is broad support for these updates within v6ops. > However, these 2 protocol specification updates are required > to be handled by the IETF 6MAN WG, simply as a matter > of the applicable IETF WG charters and usual IETF processes. The situation must be clear for everybody now. I fully support WGLC for 2 draft-ietf-6man-* I-Ds to move forward. Best Regards, Janos Mohacsi From steenjj@gmail.com Wed Sep 26 07:44:23 2012 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 A429721F884D for ; Wed, 26 Sep 2012 07:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4W6WlG8f-rh for ; Wed, 26 Sep 2012 07:44:23 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9D5F21F885D for ; Wed, 26 Sep 2012 07:44:22 -0700 (PDT) Received: by qaec10 with SMTP id c10so5378681qae.10 for ; Wed, 26 Sep 2012 07:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=87BjBlAWF0nSDlWJXayn7DpQTl9UDN7cej0epKlyMYo=; b=BblilTr72eDqCib7f/YsFacYAOuDVmRTOysTviOyziy0OntZZ4iyD6e4l6cMBToQAq 4FqtAuuyUpEP9QOuIlAAzm9Mca1leBMKZQS5LRKGthUMtuYmKnsbzmvqAB1uCz8WBcQO grAMf1Brst/fwSJ6o6SgkZt5Yyma9hk2SDFHPYw90zhi1toyh1f/uF0QTyCjagJLNyPo 5tQ9vhKUBXpoev/KsJzJ8p31nhuzvIaFhfBHtGgMWRIITNOnMNu9GIRoP6z2E0do5/eK +Ldu1/HPL/8kF+PGA2R4wrtIDMNhv53izjxVjQwZNEv6Ch3HlQXl1gj2+FnYS2GsQjOh 68CQ== Received: by 10.229.136.79 with SMTP id q15mr466253qct.123.1348670662354; Wed, 26 Sep 2012 07:44:22 -0700 (PDT) Received: from [10.132.43.232] (mobile-198-228-193-165.mycingular.net. [198.228.193.165]) by mx.google.com with ESMTPS id ck11sm4961481qab.17.2012.09.26.07.44.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Sep 2012 07:44:21 -0700 (PDT) References: <1348632032.36928.YahooMailClassic@web126005.mail.ne1.yahoo.com> <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> In-Reply-To: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9B206) From: Jon Steen Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Date: Wed, 26 Sep 2012 10:44:13 -0400 To: =?utf-8?Q?Ole_Tr=C3=B8an?= Cc: Usman Latif , "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, 26 Sep 2012 14:44:23 -0000 Some vendors are permitting the use of the link local interface address to b= e used in next hop routing there for negating the need to us additional unic= ast addresses on P2P links. When using routing protocols of OSPFv3 and BGP, I= have used /128 loopback global unicast and configured advertisements for ag= gregated prefixes between a /32 and /64 with policy based routing. This has m= inimized the potential for overlap and has also allowed the routing tables t= o be much smaller. Has anyone else tried this approach? V/R Jon Steen On Sep 26, 2012, at 4:36 AM, Ole Tr=C3=B8an wrote: >> Also its a good idea to encompass recommendations for p2p and loopbacks (= and for that matter any assignment where prefix length is going beyond /64 i= nto smaller subnets) into one standard track because the cautions and potent= ial overlap issues that may exist for a /127 would pretty much be similar fo= r /128 or any prefix that goes into the lower-64 bit territory... >=20 >> One major concern I have with using /127 and /128 on p2p and loopbacks re= spectively is that we need to be careful that there are existing (ISATAP etc= ) and potentially future implementations that would use/reserve bits in the l= ower 64 bits -so unless we set aside bit boundaries in the lower 64 bits, we= are likely to overlap with these... which is why if we use /127 with a whol= e /64 reserved for the p2p subnet, then it should be okay but if /127 or /12= 8s are numbered from the same /64 consecutively, then obviously its likely t= hat the reserved bits used by other implementations would overlap. When this= happens, any scenario where the router (which has this overlap) is SRC/DST o= f packets would be confused whether to interpret those lower-64 bits as simp= le global unicast prefix or try to treat the lower-64 bits in a different wa= y (according to the protocol implementation which is using that bit pattern)= . >=20 > a few general points: > - the 64 bit boundary is a "policy". implementations should handle any pre= fix length. > implementations should, and as far as I know do, consider all bits in th= e address as transparent. > - a loopback interface using a /128 cannot by definition overlap with anyt= hing else.=20 > - for a point to point link the operator should know if there applications= at either of two end points requiring the use of > reserved addresses, if so the link must use a /64 otherwise /127 is fine= . >=20 > these are operational choices, and I don't see a need to change IPv6 addre= ssing architecture or protocol specifications. >=20 > cheers, > Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From osmankh@yahoo.com Wed Sep 26 17:08:10 2012 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 3664F21F8610 for ; Wed, 26 Sep 2012 17:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDE+VCNEzTUo for ; Wed, 26 Sep 2012 17:08:09 -0700 (PDT) Received: from nm39-vm5.bullet.mail.ne1.yahoo.com (nm39-vm5.bullet.mail.ne1.yahoo.com [98.138.229.165]) by ietfa.amsl.com (Postfix) with SMTP id 4BD8A21F85F7 for ; Wed, 26 Sep 2012 17:08:09 -0700 (PDT) Received: from [98.138.226.176] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 00:08:06 -0000 Received: from [98.138.87.11] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 00:08:06 -0000 Received: from [127.0.0.1] by omp1011.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 00:08:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 268429.38449.bm@omp1011.mail.ne1.yahoo.com Received: (qmail 61288 invoked by uid 60001); 27 Sep 2012 00:08:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348704486; bh=/1pb2I4O5HKf1fiaR5sQbRbhN15Db9xdRgNiB2KO9Ew=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RkavkoDwKMB2ZmljdTy2zs9i87gBZjTAGbvEysN2j5OYj7yNu9jEZ4HjUnYhqxxm61laf5oBix3sQwoN42eJ7iDElOk3cXLJX1GD0CvcHEJxKbjAoXYmRMCYttEQGaq00qzrwVpu7Mhn4E9oOd3wDF8w9BzVPlhf6of5qTHKTFE= 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; b=onoxUchN6Y8MkydIL2R5sndSGD/Zh5BtkycOlz8opTeSIiwYLqNC4QJVEVmnoaznTTa00zR07celZPNOEvcW/eWo29GWujdvXqaLEFSOtmjpi1P1kqyMHK2ncRpZNvx92cs0tGE8tSdzpcflYd4uizzkKoeI4WJORTjLrO8a/sY=; X-YMail-OSG: aMjiNCMVM1kc87UFjOoKWgStEwbBaQV5Mfbz1.2q3JFagzJ hvUf.iBbzDaluvopJGgVce6MhqHbL7nYxGcwZlB9i9H0KmpVT.ztSucrM7QN xjFtdLtuysCwrWLafqvZpAoSmyMKURGI.vgYj4qocuu21sAJuc5ucw7lHIRQ P1GdkG9y9_ksmpQzsFevPOM6.Jxh3su4ROnOm7uSUuBUYkbqqARrRnBXYdB9 hdN03Lr0PlrrhQTovHAPxE52b3khcWwzH8z_R6LO.XB.odr3kSEdQrI0xBny SYgSHFgU2M4R_96KwBKFV_KpDLBWn3cIDmAqfNiLh7ZVtPh9VSCx6gu.DmRG 6Io0.rbcepaFRtLDkiPUi2pe2BzIwJ_uy0BM9tQmq2cT1xIhRZjimDUfvFNf jd9Hqx7Mih_6nqGTnJhHkAjkiW6ozkc8wzDCFy.lHwqUsygDF..9pQHdsmVy vYadQ4lAh0zuQ8qXMFfXA3._iqNFMat8ScLwUhCo0I1ZNyKPWIOScQ0gGrxW RUWi8itnckkWWvQ-- Received: from [203.94.155.226] by web126005.mail.ne1.yahoo.com via HTTP; Wed, 26 Sep 2012 17:08:06 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.434 Message-ID: <1348704486.49402.YahooMailClassic@web126005.mail.ne1.yahoo.com> Date: Wed, 26 Sep 2012 17:08:06 -0700 (PDT) From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks To: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1833503604-188053447-1348704486=:49402" 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: Thu, 27 Sep 2012 00:08:10 -0000 --1833503604-188053447-1348704486=:49402 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I am not trying to stir up a debate over something that only "I" feel =A0 There is clearly two set of recommendations over the same addressing scenar= io which I am only trying to clarify with the IETF community. RFC 6164 has recommendations that do not encompass all the recommendations = that were put forward in RFC 5375 So although when RFC 6547 moved the RFC 3627 to historical status, it compl= etely ignored that RFC 5375 has additional recommendations for the same /12= 7 and /128 addressing scenarios. What I am now trying to clarify is - should we consider recommendations in = RFC 5375 (section B.2) as obsolete ?=20 When the two set of recommendations for /127 assignment=A0i.e. one coming f= rom RFC 6164 and the other coming from RFC 5375 are competing with each oth= er, should we ignore those in 5375 and only comply with 6164 For those who feel that manual (and consecutive) assignment of /127 for p2p= links from the same /64=A0or /128 for loopbacks from the same /64 subnet i= s not going to cause any overlap - I would recommend to read section B.2 of= RFC 5375 and then provide some comments afterwards. =A0 =A0 Regards, Usman --- On Wed, 26/9/12, Ole Tr=F8an wrote: From: Ole Tr=F8an Subject: Re: IPv6 address assignment for strictly point-to-point links and = Device Loopbacks To: "Usman Latif" Cc: "Randy Bush" , "ipv6@ietf.org" Received: Wednesday, 26 September, 2012, 1:06 PM > Also its a good idea to encompass recommendations for p2p and loopbacks (= and for that matter any assignment where prefix length is going beyond /64 = into smaller subnets) into one standard track because the cautions and pote= ntial overlap issues that may exist for a /127 would pretty much be similar= for /128 or any prefix that goes into the lower-64 bit territory... > One major concern I have with using /127 and /128 on p2p and loopbacks re= spectively is that we need to be careful that there are existing (ISATAP et= c) and potentially future implementations that would use/reserve bits in th= e lower 64 bits -so unless we set aside bit boundaries in the lower 64 bits= , we are likely to overlap with these... which is why if we use /127 with a= whole /64 reserved for the p2p subnet, then it should be okay but if /127 = or /128s are numbered from the same /64 consecutively, then obviously its l= ikely that the reserved bits used by other implementations would overlap. W= hen this happens, any scenario where the router (which has this overlap) is= SRC/DST of packets would be confused whether to interpret those lower-64 b= its as simple global unicast prefix or try to treat the lower-64 bits in a = different way (according to the protocol implementation which is using that= bit pattern). a few general points: - the 64 bit boundary is a "policy". implementations should handle any pref= ix length. =A0=A0=A0implementations should, and as far as I know do, consider all bits= in the address as transparent. - a loopback interface using a /128 cannot by definition overlap with anyth= ing else.=20 - for a point to point link the operator should know if there applications = at either of two end points requiring the use of =A0=A0=A0reserved addresses, if so the link must use a /64 otherwise /127 i= s fine. these are operational choices, and I don't see a need to change IPv6 addres= sing architecture or protocol specifications. cheers, Ole --1833503604-188053447-1348704486=:49402 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I am not trying to stir up a debate over= something that only "I" feel
 
There is clearly two set of recommendations over the same addressing s= cenario which I am only trying to clarify with the IETF community.
RFC 6164 has recommendations that do not encompass all the recommendat= ions that were put forward in RFC 5375

So although when RFC 6547 mov= ed the RFC 3627 to historical status, it completely ignored that RFC 5375 h= as additional recommendations for the same /127 and /128 addressing scenari= os.

What I am now trying to clarify is - should we consider recommen= dations in RFC 5375 (section B.2) as obsolete ?

When the two set of= recommendations for /127 assignment i.e. one coming from RFC 6164 and= the other coming from RFC 5375 are competing with each other, should we ig= nore those in 5375 and only comply with 6164
For those who feel that manual (and consecutive) assignment of /127 fo= r p2p links from the same /64 or /128 for loopbacks from the same /64 = subnet is not going to cause any overlap - I would recommend to read sectio= n B.2 of RFC 5375 and then provide some comments afterwards.
 
 
Regards,
Usman


--- On Wed, 26/9/12, Ole Tr=F8an <otroan@emp= loyees.org> wrote:

From: Ole Tr=F8an <otroan@employees.org>Subject: Re: IPv6 address assignment for strictly point-to-point links and= Device Loopbacks
To: "Usman Latif" <osmankh@yahoo.com>
Cc: "Ra= ndy Bush" <randy@psg.com>, "ipv6@ietf.org" <ipv6@ietf.org>
R= eceived: Wednesday, 26 September, 2012, 1:06 PM

> Also its a good idea to encompass recommendatio= ns for p2p and loopbacks (and for that matter any assignment where prefix l= ength is going beyond /64 into smaller subnets) into one standard track bec= ause the cautions and potential overlap issues that may exist for a /127 wo= uld pretty much be similar for /128 or any prefix that goes into the lower-= 64 bit territory...

> One major concern I have with using /127 an= d /128 on p2p and loopbacks respectively is that we need to be careful that= there are existing (ISATAP etc) and potentially future implementations tha= t would use/reserve bits in the lower 64 bits -so unless we set aside bit b= oundaries in the lower 64 bits, we are likely to overlap with these... whic= h is why if we use /127 with a whole /64 reserved for the p2p subnet, then = it should be okay but if /127 or /128s are numbered from the same /64 conse= cutively, then obviously its likely that the reserved bits used by other implementations would overlap. When this happens, any scenario where= the router (which has this overlap) is SRC/DST of packets would be confuse= d whether to interpret those lower-64 bits as simple global unicast prefix = or try to treat the lower-64 bits in a different way (according to the prot= ocol implementation which is using that bit pattern).

a few general = points:
- the 64 bit boundary is a "policy". implementations should hand= le any prefix length.
   implementations should, and as f= ar as I know do, consider all bits in the address as transparent.
- a lo= opback interface using a /128 cannot by definition overlap with anything el= se.
- for a point to point link the operator should know if there appli= cations at either of two end points requiring the use of
  &nb= sp;reserved addresses, if so the link must use a /64 otherwise /127 is fine= .

these are operational choices, and I don't see a need to change IPv6 addressing architecture or protocol specifications.

che= ers,
Ole
--1833503604-188053447-1348704486=:49402-- From sm@resistor.net Wed Sep 26 17:26:28 2012 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 19A4F21F8615 for ; Wed, 26 Sep 2012 17:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1T+JIClG3H0 for ; Wed, 26 Sep 2012 17:26:27 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 007B721F8602 for ; Wed, 26 Sep 2012 17:26:26 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q8R0QKYP000050; Wed, 26 Sep 2012 17:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1348705585; bh=m45Efc7HbfctkpzlUIvyrbQcnUxCDghMbsi2lRkuN6k=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jB0GagGyDR0sJh67fKSY90IINzjq4JLPftsKvzxK8jZxV5+ziVNNHwuRB0vvPSgF7 BkD5zV6nKIqGmlZC8xTNdcYc8at1Skqupw4h+2MKHUHnIpsnZ0ksi+dlbXvOSrMLxn bCjVYJzP2drMoxm5YEJmGhovdD1w/SNAP7lFFYYo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1348705585; i=@resistor.net; bh=m45Efc7HbfctkpzlUIvyrbQcnUxCDghMbsi2lRkuN6k=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=j7gXA83bJcPPIxG+M2VbnJSUJ7K6lbimFJQAflJejfrXlEg4Pw+GHXhDLJ76fBm7L iwMbSDWKxU6lXX2/4uPjs3AeRKVyoilCDiin2QdYOGFWXORsWPJFz8H2PwyZo7upiX DnyJUXLR3dq/Zrxqcio47B4p9kV4zT8IuT6uigPk= Message-Id: <6.2.5.6.2.20120926171836.0a702c28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 26 Sep 2012 17:22:38 -0700 To: Usman Latif From: SM Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks In-Reply-To: <1348704486.49402.YahooMailClassic@web126005.mail.ne1.yahoo .com> References: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> <1348704486.49402.YahooMailClassic@web126005.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: Thu, 27 Sep 2012 00:26:28 -0000 Hi Usman, At 17:08 26-09-2012, Usman Latif wrote: >There is clearly two set of recommendations over the same addressing >scenario which I am only trying to clarify with the IETF community. >RFC 6164 has recommendations that do not encompass all the >recommendations that were put forward in RFC 5375 > >So although when RFC 6547 moved the RFC 3627 to historical status, >it completely ignored that RFC 5375 has additional recommendations >for the same /127 and /128 addressing scenarios. > >What I am now trying to clarify is - should we consider >recommendations in RFC 5375 (section B.2) as obsolete ? See http://www.ietf.org/mail-archive/web/v6ops/current/msg13685.html Regards, -sm From osmankh@yahoo.com Wed Sep 26 18:03:32 2012 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 A81CC21F8443 for ; Wed, 26 Sep 2012 18:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nWYJoonFxdT for ; Wed, 26 Sep 2012 18:03:32 -0700 (PDT) Received: from nm29-vm0.bullet.mail.ne1.yahoo.com (nm29-vm0.bullet.mail.ne1.yahoo.com [98.138.91.43]) by ietfa.amsl.com (Postfix) with SMTP id D6F1721F8441 for ; Wed, 26 Sep 2012 18:03:31 -0700 (PDT) Received: from [98.138.90.54] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 01:03:20 -0000 Received: from [98.138.89.254] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 01:03:20 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 01:03:20 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 565528.6291.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 27082 invoked by uid 60001); 27 Sep 2012 01:03:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348707800; bh=wlPaWPluEcq4R27ZK0vKbbpF25KdXCWbni+mcs1GS1k=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iDQHVQmmMAvXVCLrK6USwvCb1/ATIdeTpnzSb4lfb+AGsI6Hv1pUsINPhYcfaNrdCYdSXyfF+zslW2UajjEQ+VMYWFe6mtiOwcrN7vyVBcoasqloDsvPIIEdVgEkoDfh1ZqI2J3dJFvWSRxxESrE23pXvYqbl/fI+KZIVow3sIY= 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; b=EmGj2jWDeBdOaoQAsvg6+535Hg4YgSl08sqGqF6XrEbtjE326prbB/Y031SqXHVB6eXLC3nGR5gpS6yixONIWOvzv5lEUBNX30YJfsvhubbI3IeJhqyRVyrLptRwTko2qVvfB3PVQxN5iD2YTzISnQFxsDwemGQxhLNQyAevehs=; X-YMail-OSG: B24jlgkVM1nbr5Bn9YPoUyu1umP_25uQ_ARb5dwsfortRCD POLalt6ChyQOe41mosvVw8bHeLsdE03AryvSV7qTY_DZuAS7NRo1wP_Ii4f6 kKMLKd.aqCbdnMISHoPEQfIJEXEoVCE6hpH4mWhXo9xZZ.aoPkyI0RkFRKDo g43TnXkhFsZmYM0SwTvZ_77HibiqOWLCR4PXDv_x23JE0DMq6JSs1DxCLzUb M9cuuRg9eeIujHtStPIE0WV0YLe7TWLIMI49_sacZQ53Y2pe.ui4h6zi2zoA 8klz6y676nKofz2j6vqU4hWBS3_9VcGlJxmc0v.5CExKGDqbEH4P0kxwGYk1 GQ5fa9WluFBUnfawqp_.bugNfFDD.9t1..1E0Ctjzh8C2bzOmuQ3AoYvWT11 Xv9DO.UO1rx6.HOUDxsi.8GMss5JdKFd37FY9GqBckqcVj1BjCVS3ekMXxt0 KKFrgJj3VrMPpwA.aWpG5qUOIO9C_l5.DFjYkhkkvNrLmJ4fc05_rOc.8Byd ZKXg8Wb0u Received: from [203.94.155.226] by web126003.mail.ne1.yahoo.com via HTTP; Wed, 26 Sep 2012 18:03:19 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.434 Message-ID: <1348707799.26800.YahooMailClassic@web126003.mail.ne1.yahoo.com> Date: Wed, 26 Sep 2012 18:03:19 -0700 (PDT) From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks To: SM In-Reply-To: <6.2.5.6.2.20120926171836.0a702c28@resistor.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1134493521-1300443015-1348707799=:26800" 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: Thu, 27 Sep 2012 01:03:32 -0000 ---1134493521-1300443015-1348707799=:26800 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, =A0 I am still confused - And I'll try to explain my confusion. While we can still go ahead and say recommendations on /127 that exist in s= ection B.2.2 of RFC 5375 no longer hold true and the recommendations on /12= 7 that exist in RFC 6164 prevail over 5375 The above is fine - but if you read RFC 5375 section B.2 in detail, it talk= s about all prefix lengths above /64 and encompasses /128 for loopbacks in = its recommendations as well (section B.2.3) - whereas RFC 6164 does NOT tal= k about addressing for loopback interfaces at all What is even more confusing is that if you consider the recommendations for= /128 as per RFC 5375 as TRUE, then you go back into a loop thinking that t= here should be no discrimination between /127 or /128 because RFC 5375 talk= s about "overlap" and restricts / cautions us about reserved bits that shou= ld not be used for /128 assignments and uses the same recommendation for /1= 27 Question: How can those reserved bits NOT be a problem for /127 assignments= but a problem for /128 assignments? This is why I think if (for whatever reason which I am still trying to dige= st) we have decided to use /127 without considering reserved bits for IEEE = or other protocols, we need to provide similar or atleast some recommendati= ons for /128 on loopbacks=A0that sit inline with what we have recommended i= n RFC 6164 - otherwise the confusion still exists !! =A0 I hope I am able to convey my confusion correctly... and this is shared by = many peers in the industry that I have spoken to... hence the reason in pra= ctice although they are assigning /127 on p2p links, they are still reservi= ng the whole parent /64 for each p2p link seperately...... =A0 =A0 Regards Usman --- On Thu, 27/9/12, SM wrote: From: SM Subject: Re: IPv6 address assignment for strictly point-to-point links and = Device Loopbacks To: "Usman Latif" Cc: ipv6@ietf.org Received: Thursday, 27 September, 2012, 4:52 AM Hi Usman, At 17:08 26-09-2012, Usman Latif wrote: > There is clearly two set of recommendations over the same addressing scen= ario which I am only trying to clarify with the IETF community. > RFC 6164 has recommendations that do not encompass all the recommendation= s that were put forward in RFC 5375 >=20 > So although when RFC 6547 moved the RFC 3627 to historical status, it com= pletely ignored that RFC 5375 has additional recommendations for the same /= 127 and /128 addressing scenarios. >=20 > What I am now trying to clarify is - should we consider recommendations i= n RFC 5375 (section B.2) as obsolete ? See http://www.ietf.org/mail-archive/web/v6ops/current/msg13685.html Regards, -sm=20 ---1134493521-1300443015-1348707799=:26800 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable ---1134493521-1300443015-1348707799=:26800-- From randy@psg.com Wed Sep 26 21:47:46 2012 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 4F3BB21F866A for ; Wed, 26 Sep 2012 21:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Em6HIJJcddSj for ; Wed, 26 Sep 2012 21:47:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D074721F8666 for ; Wed, 26 Sep 2012 21:47:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TH60l-000Jyl-IO; Thu, 27 Sep 2012 04:47:43 +0000 Date: Thu, 27 Sep 2012 06:47:42 +0200 Message-ID: From: Randy Bush To: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks In-Reply-To: <1348704486.49402.YahooMailClassic@web126005.mail.ne1.yahoo.com> References: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> <1348704486.49402.YahooMailClassic@web126005.mail.ne1.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII 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: Thu, 27 Sep 2012 04:47:46 -0000 > There is clearly two set of recommendations over the same addressing > scenario which I am only trying to clarify with the IETF community. no. but please go do whatever you want in your network and stop trying to stir a long cold pot randy From joelja@bogus.com Wed Sep 26 22:10:29 2012 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 C42A421F8669 for ; Wed, 26 Sep 2012 22:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4Oykt7l+juA for ; Wed, 26 Sep 2012 22:10:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5B20521F8670 for ; Wed, 26 Sep 2012 22:10:28 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8R5APGP065066 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 27 Sep 2012 05:10:26 GMT (envelope-from joelja@bogus.com) Message-ID: <5063DFC1.407@bogus.com> Date: Wed, 26 Sep 2012 22:10:25 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: Randy Bush Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks References: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> <1348704486.49402.YahooMailClassic@web126005.mail.ne1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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]); Thu, 27 Sep 2012 05:10:27 +0000 (UTC) Cc: Usman Latif , "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, 27 Sep 2012 05:10:29 -0000 On 9/26/12 9:47 PM, Randy Bush wrote: >> There is clearly two set of recommendations over the same addressing >> scenario which I am only trying to clarify with the IETF community. There aren't really. The world moved on from 3627 and the scenario described in 6164 represents both observed reality and expectations. > no. but please go do whatever you want in your network and stop trying > to stir a long cold pot > > randy > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From osmankh@yahoo.com Wed Sep 26 22:51:43 2012 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 777B321F8639 for ; Wed, 26 Sep 2012 22:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYllX8-RoWrv for ; Wed, 26 Sep 2012 22:51:43 -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 D35C321F8629 for ; Wed, 26 Sep 2012 22:51:42 -0700 (PDT) Received: from [98.138.226.180] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 05:51:39 -0000 Received: from [98.138.88.235] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 05:51:39 -0000 Received: from [127.0.0.1] by omp1035.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 05:51:39 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 699320.94429.bm@omp1035.mail.ne1.yahoo.com Received: (qmail 13473 invoked by uid 60001); 27 Sep 2012 05:51:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348725099; bh=Ji3EQazPd29ukitIRHNOHB0uSmUcyUr7LKugWjjHZ8M=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Kv4sH5f5WYSjkZYGm8hz8KBjYdE03vx0zNk4pj3gapk8MadUeil+gawSlz963A33f8TAH/UqcZsogPA+lEcTHwp9Xu3+srR88XB17d2fi6kTp6sgozbibdoWG6a0r3HodEE6hG8urc5/hsYnk6b+dENzFNsxzqrwGsQWUbikUnc= 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; b=Ovb3raQlcyne3iQ9Mm0BnMsFkZHGv0xmyM3OwDy44cuoBt9mnCqFpOpKDP693kOZYKoQZ7bEE/hfT/lXfDznhEDasHJAyx/5zegmjaAHuApfNqr0i8fyF4Sc9dXZXv2KR/tzNdEQsnqLoDjXfKK9rlvz63cBOthD3xl9HTaRA5c=; X-YMail-OSG: Mi2w7r4VM1kKshTpmwmCttYtbTrQuan9xlNI_JAq1JA.MN5 vq7rdV1i_PL5WTksbRW1_Mck2oRF7lVJeEK_3aXz3I3.ip2o5.Fp3F_cJSeI h62Dgnqk8pcGy7wGyIdfi.J.fea6wV93atc14BZ_teywoq4tSjIUOghRJiQV ipqMQeriuc2duVkRhvxgXI0.Mc6ADu6mJmICYEUWvxOBTA1ICEoWGh66AFh0 0PkNQHorxOKkd88evPo2nLwP.SNBqSGR4W0I2jZ76LByu5Zq2JFXqtl9jePw CVvWt2v38uq4YJ7WoHjz5qgYrsTqb.v9.8WUm5p7UUic6ks4qGWRyeFtNrqI xEKQXoI2FRKyA1TTXf3pWygvqKjp8w0nNJQ0lThib.G2EmC1UjtK1nefIjuT KGZKqmMGzI847Zk0dujmvsgeV6XaWVaaixy7nLH15yEYCC_W0ZFn_OmRZe7g bmVveWZze.LLHnIXBoVgBH.rfu5TLWPzBF05hkSLKbEsZOnSHdneIKb_Bi_z eJbL1yD164Bvm0A-- Received: from [203.94.155.226] by web126002.mail.ne1.yahoo.com via HTTP; Wed, 26 Sep 2012 22:51:39 PDT X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.121.434 Message-ID: <1348725099.51734.YahooMailClassic@web126002.mail.ne1.yahoo.com> Date: Wed, 26 Sep 2012 22:51:39 -0700 (PDT) From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks To: Randy Bush In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1915680061-1517217935-1348725099=:51734" 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: Thu, 27 Sep 2012 05:51:43 -0000 ---1915680061-1517217935-1348725099=:51734 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --- On Thu, 27/9/12, Randy Bush wrote: From: Randy Bush Subject: Re: IPv6 address assignment for strictly point-to-point links and = Device Loopbacks To: "Usman Latif" Cc: "Ole Tr=F8an" , "ipv6@ietf.org" Received: Thursday, 27 September, 2012, 9:17 AM > There is clearly two set of recommendations over the same addressing > scenario which I am only trying to clarify with the IETF community. no.=A0 but please go do whatever you want in your network and stop trying to stir a long cold pot randy =A0 I would only if I owned the whole internet :) If you have links to any previous discussions / blogs on this long cold pot= , pls point me to them so I can convince myself that both 5375 and 6164 hav= e same recommendations for /127 (and /128) =A0 Usman ---1915680061-1517217935-1348725099=:51734 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
 
I am still confused - And I'll try to explain my confusion.

Whi= le we can still go ahead and say recommendations on /127 that exist in sect= ion B.2.2 of RFC 5375 no longer hold true and the recommendations on /127 t= hat exist in RFC 6164 prevail over 5375

The above is fine - but if y= ou read RFC 5375 section B.2 in detail, it talks about all prefix lengths a= bove /64 and encompasses /128 for loopbacks in its recommendations as well = (section B.2.3) - whereas RFC 6164 does NOT talk about addressing for loopb= ack interfaces at all

What is even more confusing is that if you con= sider the recommendations for /128 as per RFC 5375 as TRUE, then you go bac= k into a loop thinking that there should be no discrimination between /127 = or /128 because RFC 5375 talks about "overlap" and restricts / cautions us = about reserved bits that should not be used for /128 assignments and uses t= he same recommendation for /127

Question: How can those reserved bits NOT be a problem for /127 assignments but a problem for /128= assignments?

This is why I think if (for whatever reason which I am= still trying to digest) we have decided to use /127 without considering re= served bits for IEEE or other protocols, we need to provide similar or atle= ast some recommendations for /128 on loopbacks that sit inline with wh= at we have recommended in RFC 6164 - otherwise the confusion still exists != !
 
I hope I am able to convey my confusion correctly... and this is share= d by many peers in the industry that I have spoken to... hence the reason i= n practice although they are assigning /127 on p2p links, they are still re= serving the whole parent /64 for each p2p link seperately......
 
 
Regards
Usman


--- On Thu, 27/9/12, SM <sm@resistor.net> = wrote:

From: SM <sm@resistor.net>
Subject: Re: = IPv6 address assignment for strictly point-to-point links and Device Loopba= cks
To: "Usman Latif" <osmankh@yahoo.com>
Cc: ipv6@ietf.org
= Received: Thursday, 27 September, 2012, 4:52 AM

Hi Usman,
At 17:08 26-09-2012, Usman Latif wrote:=
> There is clearly two set of recommendations over the same addressi= ng scenario which I am only trying to clarify with the IETF community.
&= gt; RFC 6164 has recommendations that do not encompass all the recommendati= ons that were put forward in RFC 5375
>
> So although when RFC= 6547 moved the RFC 3627 to historical status, it completely ignored that R= FC 5375 has additional recommendations for the same /127 and /128 addressin= g scenarios.
>
> What I am now trying to clarify is - should w= e consider recommendations in RFC 5375 (section B.2) as obsolete ?

S= ee http://www.ietf.org/mail-archive/web/v6ops/current/msg= 13685.html

Regards,
-sm

--- On Thu, 27/9/12, Randy Bush <= ;randy@psg.com> wrote:

From: Randy Bush <randy@psg.com>
Subject= : Re: IPv6 address assignment for strictly point-to-point links and Device = Loopbacks
To: "Usman Latif" <osmankh@yahoo.com>
Cc: "Ole Tr=F8a= n" <otroan@employees.org>, "ipv6@ietf.org" <ipv6@ietf.org>
R= eceived: Thursday, 27 September, 2012, 9:17 AM

> There is clearly two set of recommendations ove= r the same addressing
> scenario which I am only trying to clarify wi= th the IETF community.

no.  but please go do whatever you want = in your network and stop trying
to stir a long cold pot

randy
=
 
I would only if I owned the whole internet :)
If you have links to any previous discussions / blog= s on this long cold pot, pls point me to them so I can convince myself that= both 5375 and 6164 have same recommendations for /127 (and /128)
 
Usman
---1915680061-1517217935-1348725099=:51734-- From xuyunmail@gmail.com Wed Sep 26 23:48:23 2012 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 69A5C21F841C for ; Wed, 26 Sep 2012 23:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-A9f+l9z2qD for ; Wed, 26 Sep 2012 23:48:23 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id CE02921F841A for ; Wed, 26 Sep 2012 23:48:22 -0700 (PDT) Received: by qabj40 with SMTP id j40so1872918qab.10 for ; Wed, 26 Sep 2012 23:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tffs5fb7WMjRbC3cemUPY8K7Y+2uTGT5IrOlEIO3s9c=; b=Fu5uNXPUGX/kXomMWoyrzz4y3ffpdsKRCYeDOmIn4IDYxiujRnYbUaJZILjkPLJ/nD X0qM9Llf4B5DAG9ez/+4cldvi3lCIPEJEzheWARJEb2j8aXj0OjfOs7js+n1KOL6anSC UiQOmderyQ8BKtggBGSED810s1Pz75PPPl9OrKq6AO9lR6MCUdQaTFQxHPwdKRLhZKC3 Oazt2G0vVjx0slbDhw9isOjHBlOkteIuoNrvuNcC1qKrl6PwncJL0u5IgkQSwNRrSwyX N/Hkl5xy2vi1pz5RoANIXctmx3p/o8bx8xukSMHMicey5NZet1wUvVZ8IZYHHqj5R0Vi bFNw== MIME-Version: 1.0 Received: by 10.224.223.13 with SMTP id ii13mr7460008qab.68.1348728502281; Wed, 26 Sep 2012 23:48:22 -0700 (PDT) Received: by 10.49.96.105 with HTTP; Wed, 26 Sep 2012 23:48:22 -0700 (PDT) In-Reply-To: <5063DFC1.407@bogus.com> References: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> <1348704486.49402.YahooMailClassic@web126005.mail.ne1.yahoo.com> <5063DFC1.407@bogus.com> Date: Thu, 27 Sep 2012 16:48:22 +1000 Message-ID: Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks From: George Xu To: joel jaeggli Content-Type: multipart/alternative; boundary=20cf3074b47e46e4b804caa9536f Cc: Usman Latif , "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, 27 Sep 2012 06:48:23 -0000 --20cf3074b47e46e4b804caa9536f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 27, 2012 at 3:10 PM, joel jaeggli wrote: > On 9/26/12 9:47 PM, Randy Bush wrote: > >> There is clearly two set of recommendations over the same addressing >>> scenario which I am only trying to clarify with the IETF community. >>> >> There aren't really. The world moved on from 3627 and the scenario > described in 6164 represents both observed reality and expectations. > > The confusion aired from Usman is also with me. The potential address overlap in lower-64 bit space while assigning prefix longer than /64 (in RFC5375) seems to me a valid concern.I am wondering if the community regarded these potential address overlaps are no longer of concerns at all while RFC 6164 was published. George --20cf3074b47e46e4b804caa9536f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 27, 2012 at 3:10 PM, joe= l jaeggli <joelja@bogus.com> wrote:
On 9/26/12 9:47 PM, Randy Bush wrote:
There is clearly two set of recommendations over the same addressing
scenario which I am only trying to clarify with the IETF community.
There aren't really. The world moved on from 3627 and the scenario desc= ribed in 6164 represents both observed reality and expectations.
<= br>

The confusion aired from Usman is also w= ith me.

The potential=20 address overlap in lower-64 bit space while assigning prefix longer than /64 (in RFC5375) seems to me a valid concern.I am wondering if the communi= ty regarded these potential address overlaps are no longer of concerns at a= ll while RFC 6164 was published.

George=A0
--20cf3074b47e46e4b804caa9536f-- From randy@psg.com Thu Sep 27 00:10:36 2012 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 2E9D621F86DA for ; Thu, 27 Sep 2012 00:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9ustmMnhkWm for ; Thu, 27 Sep 2012 00:10:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C5D1021F86D9 for ; Thu, 27 Sep 2012 00:10:35 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TH8Ez-000KCs-9s; Thu, 27 Sep 2012 07:10:33 +0000 Date: Thu, 27 Sep 2012 09:10:32 +0200 Message-ID: From: Randy Bush To: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks In-Reply-To: <1348725099.51734.YahooMailClassic@web126002.mail.ne1.yahoo.com> References: <1348725099.51734.YahooMailClassic@web126002.mail.ne1.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII 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: Thu, 27 Sep 2012 07:10:36 -0000 > If you have links to any previous discussions / blogs on this long > cold pot, pls point me to them so I can convince myself that both 5375 > and 6164 have same recommendations for /127 (and /128) go read the discussion on 6164 we do not care what you do in your network. we do care that you blabber on the list while there is work to be done. randy From osmankh@yahoo.com Thu Sep 27 00:56:34 2012 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 DC87D21F8692 for ; Thu, 27 Sep 2012 00:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OceO6e1enj46 for ; Thu, 27 Sep 2012 00:56:34 -0700 (PDT) Received: from nm14-vm0.bullet.mail.sp2.yahoo.com (nm14-vm0.bullet.mail.sp2.yahoo.com [98.139.91.246]) by ietfa.amsl.com (Postfix) with SMTP id 8601F21F8679 for ; Thu, 27 Sep 2012 00:56:34 -0700 (PDT) Received: from [98.139.91.65] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 27 Sep 2012 07:56:26 -0000 Received: from [72.30.22.38] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 27 Sep 2012 07:56:26 -0000 Received: from [127.0.0.1] by omp1068.mail.sp2.yahoo.com with NNFMP; 27 Sep 2012 07:56:25 -0000 X-Yahoo-Newman-Id: 957700.18449.bm@omp1068.mail.sp2.yahoo.com Received: (qmail 89723 invoked from network); 27 Sep 2012 07:56:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=dopi9561QxHgP/y3Ut1EHfyJVDdsNV7NNYUb67aDD4GrowkOkU+wdPal4a9Ns5zmPtEc4A1INI13v9wcKbHWpkCE8ezS9wvrYfRoClc+Y6trzbYz2c9OjaN2bvUk8trBONFZCmBNuXdyezEVYjjuh5l6bxn6R6BHeVv1ZIb1k3g= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348732585; bh=gvH3/pEchqlecsiHRMhoX+4HqABpRxXc53hVlHYLKBY=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=DHYLfa10WsUMnKubrdAEIkl9GGU4LujboEXowAz0BMFmT23lYtgUoS369J5D36wDNDCZDV+UealTOAc5WqRUi9RW1Shcw0MS+onzNq9//DF9KTLWV47sQT4bB5iasYn9J4D+4ZOVrnnK6iPmSBS3TfIgHgY753ACiRaFe09UsgA= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: z.DbjWkVM1lOY..aOhau3ADSwuACd31S6LL8nfjhGj.dD0k dPFwy2Vkg.eM.9dCdfSjX9nuek1BcszdNeT9x4Pn6GtUF2Zj5M1CvKsh2KcJ yYHPJrS0CegL9B8u.2R3z4acR4w5oBxn4EIH4I.NS5dDn61mJzfnihabKyGV dDeXsWfeOIuNVxd05rVBLTLIjfNh4gzy07ypgTNEohQXdLpE3_F9hH9LkAVs KmCtY3Y22TiZw9SxL1HjYPizGsDQfCXcEH4uJ.yRlunvPHAPaBsduNxKU0eB eHvTKexuR9qVPebltcEoCDB3..UcZEvBUPagrSoIcab5n9nrQd6bPR44gVAp TcnNJCaQYk5rHqfhIxeCGWGIEM52vvJZ3t.on9MLDUSBzReBLalzzePDTaSZ Vf7m3KxD3XH.fo7_F_DAKDDyLGgaVhBQZQYBj_JQe.UIZdN76gQTg9m38mEX iIWfnDV.mfawoLCjVUeZ54vIq1g-- X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- Received: from [10.46.130.4] (osmankh@49.176.98.205 with xymcookie) by smtp118-mob.biz.mail.gq1.yahoo.com with SMTP; 27 Sep 2012 00:56:25 -0700 PDT References: <1348725099.51734.YahooMailClassic@web126002.mail.ne1.yahoo.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Date: Thu, 27 Sep 2012 17:56:19 +1000 To: Randy Bush 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: Thu, 27 Sep 2012 07:56:35 -0000 Sorry i didn't realize that you own this list - my apologies If you really have work to do pls disregard my emails instead of responding w= ith meaningless emails that are not helping either of us... On 27/09/2012, at 5:10 PM, Randy Bush wrote: >> If you have links to any previous discussions / blogs on this long >> cold pot, pls point me to them so I can convince myself that both 5375 >> and 6164 have same recommendations for /127 (and /128) >=20 > go read the discussion on 6164 >=20 > we do not care what you do in your network. we do care that you blabber > on the list while there is work to be done. >=20 > randy From randy@psg.com Thu Sep 27 00:57:35 2012 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 3CA9921F86E1 for ; Thu, 27 Sep 2012 00:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVYoXxgoPcUJ for ; Thu, 27 Sep 2012 00:57:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id CF9D921F86D0 for ; Thu, 27 Sep 2012 00:57:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TH8yT-000KHk-AQ; Thu, 27 Sep 2012 07:57:33 +0000 Date: Thu, 27 Sep 2012 09:57:32 +0200 Message-ID: From: Randy Bush To: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks In-Reply-To: References: <1348725099.51734.YahooMailClassic@web126002.mail.ne1.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII 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: Thu, 27 Sep 2012 07:57:35 -0000 > Sorry i didn't realize that you own this list - my apologies > If you really have work to do pls disregard my emails instead of > responding with meaningless emails that are not helping either of > us... From osmankh@yahoo.com Thu Sep 27 04:44:04 2012 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 DBBFE21F84D5 for ; Thu, 27 Sep 2012 04:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQEgczyr5+rt for ; Thu, 27 Sep 2012 04:44:04 -0700 (PDT) Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) by ietfa.amsl.com (Postfix) with SMTP id 025F321F84CE for ; Thu, 27 Sep 2012 04:44:03 -0700 (PDT) Received: from [98.139.212.145] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 27 Sep 2012 11:43:56 -0000 Received: from [98.139.212.235] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 27 Sep 2012 11:43:56 -0000 Received: from [127.0.0.1] by omp1044.mail.bf1.yahoo.com with NNFMP; 27 Sep 2012 11:43:56 -0000 X-Yahoo-Newman-Id: 142891.82555.bm@omp1044.mail.bf1.yahoo.com Received: (qmail 40670 invoked from network); 27 Sep 2012 11:43:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=V3EIumTmMqWlZZYNKvc9pt/aY8RAjqz+wn8AGhWyAH6rsiTN2uTmpa5/Oir5JBDU9ePfSgKcTXHENX14ieTfyFejuNLtcQZrqIHJThkP0kXWW8UOc4jEUuX7xbAKe/ouyyQdOfGaKSB3Xd+0EIDHNQxEpJykQrapf7x5tV2u7SM= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348746236; bh=2xxL/7gL21fT6MFUy5sVZa+AvF2JKxAngBaH0qk/yNQ=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=f0a6rxEH7J9rc/XD/sIlaepMgw/hdCVcj212qDAnA46F56q25ZLE39Ewl6dkVBKPS8to6jPA5PR2Ih2yMgo5+2bwDirvfvsn1nIdY1rz5sC0k+nS2gZjc+tzZ5g1rMQRV8ffy+Ppf+2mQr3aykbM1QLfZlrYG4Z7DO/NHgx6doc= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: HIUhopsVM1lnrzqdgEVNB8ZfqZEXgwN14CekMD2lN4VK9bW 8rJiu5GPyKUbMsqLlvG_DBoUTQ9I.u4gUJ3_B1vlOeOsyxcuRAyz_WfzkwxS ftCg65sKaXvK7xqwpROLRek1c6PzwfDe11VkDPpyhUP54ABn.UwyC4UMFrGz dxBT6O9MmXky62DD86JGsBHKTX8.Et.IewwCXScIczgMfkNNb7aaggZd8mBH niiGLdtiP8ayhVIdPggSG4zbZQlFJh185NGRbIRnmFQUGLKqYyFeXqZjXySb SqyT1R3XSpCeVfZqm1B3JL2rjiQLeOy0azLyzAtkZbSvhjLbp6b9QkDlvGkm wdy2M.dOGIjwiW_Yxt7DT6LQk4gyul2HargiPxH9rF9DFFnTEsad0QGhdAiY rS.CP7PQ6N7BmfKO5Y7w85Oxn_PcRk7kAQx7ITceiyBbYosvYTvRh39W5tuG iKEOz X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- Received: from [192.168.1.66] (osmankh@27.32.72.22 with xymcookie) by smtp110-mob.biz.mail.bf1.yahoo.com with SMTP; 27 Sep 2012 04:43:55 -0700 PDT References: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> <1348704486.49402.YahooMailClassic@web126005.mail.ne1.yahoo.com> <5063DFC1.407@bogus.com> In-Reply-To: <5063DFC1.407@bogus.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Date: Thu, 27 Sep 2012 21:43:52 +1000 To: joel jaeggli 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: Thu, 27 Sep 2012 11:44:05 -0000 Hi Joel, RFC 6164 overriding 3627 seems logical However, I am looking more from perspective of 5375 Also If one has to "go read the discussion on 6164" to understand it - this i= s itself an indication that 6164 has not done a good job of providing a conc= lusive recommendation on use of prefixes with subnet lengths longer than /64= If 6164 was going to override recommendations of 5375, the least one would e= xpect is the RFC 6164 to document the reasons why it felt that the additiona= l considerations provided in section B.2.4 B.2.6 and B.2.7 of RFC5375 are t= o be ignored or don't hold true anymore- this reasoning should have been mad= e part of the RFC6164... Instead the 6164 provided reasons around ping-pong issue and neighbor cache i= ssue - both of which appear weak as one is resolved thru 4443 and the other c= an be resolved thru feature enhancements in the neighbor caching process... Usman On 27/09/2012, at 3:10 PM, joel jaeggli wrote: > On 9/26/12 9:47 PM, Randy Bush wrote: >>> There is clearly two set of recommendations over the same addressing >>> scenario which I am only trying to clarify with the IETF community. > There aren't really. The world moved on from 3627 and the scenario describ= ed in 6164 represents both observed reality and expectations. >> no. but please go do whatever you want in your network and stop trying >> to stir a long cold pot >>=20 >> randy >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 From brian.e.carpenter@gmail.com Thu Sep 27 06:12:06 2012 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 1CF2721F853D for ; Thu, 27 Sep 2012 06:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj8bYSjMDvRQ for ; Thu, 27 Sep 2012 06:12:05 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 95B6A21F851C for ; Thu, 27 Sep 2012 06:12:05 -0700 (PDT) Received: by iec9 with SMTP id 9so4963319iec.31 for ; Thu, 27 Sep 2012 06:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Clhh3dmqMWVymT4V3aH2icUWZ6MS3H20DwJakg7jAi4=; b=LXEURm+LwdVWZoSFaGNq2MBxB1gfP9vmmchMsPC4RTSJstPRB7RuLB3pq9PElwSNmC N/X6iiDDVG9imw7jQ3Ak83CjGwzGpyETXPybLaY8vr17sRGEqcQzFxOICyxgnL4EV3B+ WzjzFxTLU3HUwnU8qjK5i5Ze5+ebV4nczu27KwHifefFJyNmpPSyeB5WvzAPLb8bSvvy 7OwmI3bwLg9Okjhxbw3CsHDryye63ywqNIZvdC9HZTL5WpDrnuS3PqgMdDPRn5eveq6l BxmwcefgICR7v2iBO4NoIFiFXspgFQPTAf0a5Qx1gGh1lliY5UOGoJZLv7EyE/z/jYXy 2ykQ== Received: by 10.50.5.180 with SMTP id t20mr3561407igt.31.1348751525198; Thu, 27 Sep 2012 06:12:05 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id aa4sm12649346igc.15.2012.09.27.06.12.00 (version=SSLv3 cipher=OTHER); Thu, 27 Sep 2012 06:12:00 -0700 (PDT) Message-ID: <506450AA.90305@gmail.com> Date: Thu, 27 Sep 2012 14:12:10 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks References: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> <1348704486.49402.YahooMailClassic@web126005.mail.ne1.yahoo.com> <5063DFC1.407@bogus.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Thu, 27 Sep 2012 13:12:06 -0000 Usman, On 27/09/2012 12:43, Usman Latif wrote: > Hi Joel, > > RFC 6164 overriding 3627 seems logical > However, I am looking more from perspective of 5375 RFC 5375 is an Informational document. You are at liberty to read it or not, and to make use of it or not. RFC 6164 is a Standards track document. It is of course a voluntary standard like all IETF standards, but if you claim to implement it, it clearly preempts an older Informational document such as RFC 5375. As SM reminded us, it was probably a mistake that RFC 6164 didn't formally update RFC 5375, but so what? There are many minor inconsistencies between RFCs. Please don't lose any sleep over it. As long as you aren't accidentally running SLAAC on a pt2pt link, none of this matters, as far as I can see. Brian P.S. I am now adding this thread to my "ietf-silly-subj" filter. From osmankh@yahoo.com Thu Sep 27 10:38:08 2012 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 5094A21F8569 for ; Thu, 27 Sep 2012 10:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoxUY0qSKbMJ for ; Thu, 27 Sep 2012 10:38:07 -0700 (PDT) Received: from nm6-vm4.bullet.mail.ne1.yahoo.com (nm6-vm4.bullet.mail.ne1.yahoo.com [98.138.91.166]) by ietfa.amsl.com (Postfix) with SMTP id B74E721F855D for ; Thu, 27 Sep 2012 10:38:07 -0700 (PDT) Received: from [98.138.90.56] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 17:38:04 -0000 Received: from [98.138.89.160] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 17:38:04 -0000 Received: from [127.0.0.1] by omp1016.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 17:38:04 -0000 X-Yahoo-Newman-Id: 677999.27920.bm@omp1016.mail.ne1.yahoo.com Received: (qmail 21798 invoked from network); 27 Sep 2012 17:38:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=Rok7p2UmR9x/3/PwZnRIepIUgNyExZcCCUKamhAHHPtVjrS2Ctu2V9d+DrnlZ+FFIkDW5kVBysch5xur78kuDfNblJPZk3fmZ5wrO0K2rLe50Ea5tbFMABewjX7GSR4FKL+tEuFfTuyc08bOKAfbsuN/atVfqVwEiS4dKRXIkiM= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348767484; bh=1E+mHVMUaRB678/RmHaKjBuAozt7noEVmUGon7a44O0=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=zz13Mxn0JEQ53qYf1BEiQaceA14xa02byYvX11q2McrqPaw7pUVSTsK3Tb++zLusbEGFClmHDaW6Lk38AAXgQo465gxxXDGPtA5g+LLq80pIM+VugqlliSRkttdy6G9AiwF95d9v39NdnYGDVFeujg3TLF0KkrP5qsC6dnFSSVs= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: bCzsePEVM1kxHKeHYX5McyDroEazAwsi7Vy8kOmRk9oeyb9 za4wzkPRFqcsMQVOiLKp9qbPnoIP.gUQcP8xC3yqG00tti2uP2SGhNs3H3Cg yzlY_zN2YAtJtkgLIr3M.p2MuojrASAJfzchDG1jNykp9z8Y7AbudZ3GKCGF SOziF3EfyeHkKGDihI5WrwOhCVvcimlRsPbJOXRmvDhbxYNuGYA3kxhI_yZl fjZDtax0sacfn9X.vhhyWrMoHSreMfOaPvWzCF4EVn94NdEUa9bH8809QqnZ SeXxIu7op5HzdBrghrKab.hw.xdvo2D9tUwa9qE3ef9qVB97onKFO66DZJKt UC0Uc7tT4pR_BTQlQP6S5LOmQ_arGTPoiJ2lbm1vnjyAcy.ykSSbLv8kFKBI j4YIGYJ._Htu4pDUCeJuAJWui.3dalcd_eYR_FehYlBYZCge2wh1O.YCEoMR Yus1B X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- Received: from [192.168.1.66] (osmankh@27.32.72.22 with xymcookie) by smtp105-mob.biz.mail.ne1.yahoo.com with SMTP; 27 Sep 2012 17:38:04 +0000 UTC References: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> <1348704486.49402.YahooMailClassic@web126005.mail.ne1.yahoo.com> <5063DFC1.407@bogus.com> <506450AA.90305@gmail.com> In-Reply-To: <506450AA.90305@gmail.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9467057F-773B-43DB-8719-AC9AEEF2DA7D@yahoo.com> X-Mailer: iPhone Mail (9B206) From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Date: Fri, 28 Sep 2012 03:38:00 +1000 To: Brian E Carpenter 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: Thu, 27 Sep 2012 17:38:08 -0000 I'll conclude on the following points: i. The only guidance that's out there today for device loopbacks (whether in= formational or standards track) is 5375 -because 6164 (whether voluntarily o= r involuntarily) chose not to provide any considerations for /128 loopbacks ii. A reader following considerations of /128 from 5375 is led to also consi= der B.2.4 B.2.6 and B.2.7 for any prefixes where the subnet length is longe= r than /64 iii. If 6164 overrides any previous RFCs, IMO it should provide some reasoni= ng of why it no longer felt that the sections B.2.4. B.2.6 and B.2.7 of 5375= should be considered Sent from my iPhone On 27/09/2012, at 11:12 PM, Brian E Carpenter w= rote: > Usman, >=20 > On 27/09/2012 12:43, Usman Latif wrote: >> Hi Joel, >>=20 >> RFC 6164 overriding 3627 seems logical >> However, I am looking more from perspective of 5375 >=20 > RFC 5375 is an Informational document. You are at liberty to read it or no= t, > and to make use of it or not. >=20 > RFC 6164 is a Standards track document. It is of course a voluntary standa= rd > like all IETF standards, but if you claim to implement it, it clearly pree= mpts > an older Informational document such as RFC 5375. >=20 > As SM reminded us, it was probably a mistake that RFC 6164 didn't formally= > update RFC 5375, but so what? There are many minor inconsistencies between= > RFCs. Please don't lose any sleep over it. As long as you aren't accidenta= lly > running SLAAC on a pt2pt link, none of this matters, as far as I can see. >=20 > Brian >=20 > P.S. I am now adding this thread to my "ietf-silly-subj" filter. From osmankh@yahoo.com Thu Sep 27 14:39:13 2012 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 44C8521F8594 for ; Thu, 27 Sep 2012 14:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lteV3jnx-hvY for ; Thu, 27 Sep 2012 14:39:12 -0700 (PDT) Received: from nm3.bullet.mail.ne1.yahoo.com (nm3.bullet.mail.ne1.yahoo.com [98.138.90.66]) by ietfa.amsl.com (Postfix) with SMTP id 3C52A21F8582 for ; Thu, 27 Sep 2012 14:39:12 -0700 (PDT) Received: from [98.138.90.50] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 21:39:07 -0000 Received: from [98.138.226.163] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 21:39:07 -0000 Received: from [127.0.0.1] by omp1064.mail.ne1.yahoo.com with NNFMP; 27 Sep 2012 21:39:07 -0000 X-Yahoo-Newman-Id: 242697.4072.bm@omp1064.mail.ne1.yahoo.com Received: (qmail 51665 invoked from network); 27 Sep 2012 21:39:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=6swwaFNg48UtU+Ka/LPADA2OQVkVykRjc4CIyQH5Z0BcV1uco1bnYNr3zgctji3eMEO34P9eQhJ9++taQZqyzXtuweh7Fg0c4EP5lMItp2o3geJ3K45APdpsSniPhNUNc8xwjzoQ0IZjJwBOMyYPSr14y4QaOnX3C8dMDo2j4NE= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348781946; bh=pPu/wCTfO/SYE/uOoce0ivu9iZ4G/N8lXRX8Gg6Nmjw=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=rTlA6mNa2UppS7K5aidrg+Ej15qSK8N+yrP0huzz4SC3UB0AsFUGfpNfeV1NC34tDnUbE4aGzmlnWLcsRpH3vQAHiqUboaO5oi/sGt+YFIWKXMnofrTzvw1uaUJfNHLZD3CsHsB+ed8yfRkgP4aZGhq5llr6NejQ377fDHGA8z0= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1G7AXGQVM1llOOSxr2pc5yWrKpWojC0Xy.1HYjsKTZEAfzx 5Xwfy2.XwAFU3L3osbHlBYx2Rp3vpKD_ohTJo6j6eOc.aj4IKT96FV9eq4RQ vRfP1Td7qrn2BpDJ7b6htKKXsp98GmbkdtyOCOF9cxLa8A1_bxX6GyGF0kXA olI2FbiBR8xIMPzm2Hi_vAsvjA._8BngQHEwyezRunQNtSv7DzG.T08d9rzE uNwTTOntFf2pNNWiTmfjJdleHfS1yUnkXJpf2sVESo3SyIE46i7PunAwGgvM _oKx_GQ.vZTtvMnZybdpi5Jv19TCOVwPM0Azk_uOTQwCcDC9ClNOGaJXfAVh V0vwtnqAlcrro4AU2_8p1jLNtLDsb4g_aULx5gAtpMOYMks30YE15uGbJeQ2 AmDeVyXw8tIxTAlj3efFy.Rw.uLubz9guhYbGoyquHZNW.ZypjWPCR0boHBY xE7q3CEc- X-Yahoo-SMTP: RUL5CFuswBD02LFE5KfPCwZifSs- Received: from [10.4.103.201] (osmankh@49.176.100.84 with xymcookie) by smtp104-mob.biz.mail.gq1.yahoo.com with SMTP; 27 Sep 2012 14:39:06 -0700 PDT References: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> <1348704486.49402.YahooMailClassic@web126005.mail.ne1.yahoo.com> <5063DFC1.407@bogus.com> <506450AA.90305@gmail.com> <9467057F-773B-43DB-8719-AC9AEEF2DA7D@yahoo.com> In-Reply-To: <9467057F-773B-43DB-8719-AC9AEEF2DA7D@yahoo.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (9B206) From: Usman Latif Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Date: Fri, 28 Sep 2012 07:39:00 +1000 To: Usman Latif 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: Thu, 27 Sep 2012 21:39:13 -0000 (Hopefully) my last email on this topic: - Not only has RFC 6164 failed to properly update RFC 5375 with any reasonin= g provided for 5375 section(s) B.2.xx - It has also defied and failed to update RFC 4291 which says (section 2.5.1= ) - "For all unicast addresses, except those that start with binary value 00= 0, interface IDs are required to be 64 bits long" - IMO 6164 seems to be justifying actions of those deployments where ppl hav= e simply gone ahead and deployed /127s without properly doing their homework= on v6 addressing - This has put a constraint on greenfield deployments where we are in a posi= tion to implement /64s but are now having to deal with a compromise for exis= ting deployments - We are fine to follow 6164, but since RFCs come and go, if tomorrow the ap= plications demand specific use of interface identifiers in the lower 64-bit s= pace, and you folks send out a new RFC to override 6164, then we'll be requi= red to re-address our network - then "I Will Come Back To Haunt You Guys - i= f I am alive" :) Pls don't take me the wrong way, I have read many RFCs and think you have do= ne a great job buy I was never confused the way I am now after successively g= oing through 3627, 4291, 5375 and now 6164.... Regards, Usman Sent from my iPhone On 28/09/2012, at 3:38 AM, Usman Latif wrote: > I'll conclude on the following points: >=20 > i. The only guidance that's out there today for device loopbacks (whether i= nformational or standards track) is 5375 -because 6164 (whether voluntarily o= r involuntarily) chose not to provide any considerations for /128 loopbacks >=20 > ii. A reader following considerations of /128 from 5375 is led to also con= sider B.2.4 B.2.6 and B.2.7 for any prefixes where the subnet length is lon= ger than /64 >=20 > iii. If 6164 overrides any previous RFCs, IMO it should provide some reaso= ning of why it no longer felt that the sections B.2.4. B.2.6 and B.2.7 of 53= 75 should be considered >=20 >=20 >=20 > Sent from my iPhone >=20 > On 27/09/2012, at 11:12 PM, Brian E Carpenter wrote: >=20 >> Usman, >>=20 >> On 27/09/2012 12:43, Usman Latif wrote: >>> Hi Joel, >>>=20 >>> RFC 6164 overriding 3627 seems logical >>> However, I am looking more from perspective of 5375 >>=20 >> RFC 5375 is an Informational document. You are at liberty to read it or n= ot, >> and to make use of it or not. >>=20 >> RFC 6164 is a Standards track document. It is of course a voluntary stand= ard >> like all IETF standards, but if you claim to implement it, it clearly pre= empts >> an older Informational document such as RFC 5375. >>=20 >> As SM reminded us, it was probably a mistake that RFC 6164 didn't formall= y >> update RFC 5375, but so what? There are many minor inconsistencies betwee= n >> RFCs. Please don't lose any sleep over it. As long as you aren't accident= ally >> running SLAAC on a pt2pt link, none of this matters, as far as I can see.= >>=20 >> Brian >>=20 >> P.S. I am now adding this thread to my "ietf-silly-subj" filter. >=20 From evyncke@cisco.com Sat Sep 29 02:26:28 2012 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 9D44721F858F for ; Sat, 29 Sep 2012 02:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x86-1VquXlfn for ; Sat, 29 Sep 2012 02:26:27 -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 9BD2D21F857A for ; Sat, 29 Sep 2012 02:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5062; q=dns/txt; s=iport; t=1348910787; x=1350120387; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yzdXsapUXWxzf3ahy/qUrPJMPWj6H/uhsgbA0JMN08Y=; b=TVmfzIdWafdpBdG5TjowDuFqEJqi1gdtK13tKWq9CAf4caw/+p4WgDf3 dTUn4MggHn1QSaTwn/kPSgkNkAm/Obz/yNrVQWlhDkp1D8IrqiqReH6+T yMtJOAcgrq8+w9Eo3nUFQEVqRyaWHLZQCIFSi0qY37qhXF0k5YZ28iMss M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFu9ZlCtJV2c/2dsb2JhbABFhgu3KnyBCIIgAQEBBAEBAQ8BEBE6CwwEAgEIEQEDAQEBAgIGHQMCAgIlCxQBAgYIAgQOBQgah2MLmTeNG5JrgSGJfoU5MmADln6NLYFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,507,1344211200"; d="scan'208";a="126621913" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 29 Sep 2012 09:26:27 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8T9QRFf008820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Sep 2012 09:26:27 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Sat, 29 Sep 2012 04:26:26 -0500 From: "Eric Vyncke (evyncke)" To: Jon Steen Subject: RE: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Thread-Topic: IPv6 address assignment for strictly point-to-point links and Device Loopbacks Thread-Index: AQHNm5t5Zp7Pa1Uu3EOQ2IghPq2KW5ecoJGAgABm1ICABAoP4A== Date: Sat, 29 Sep 2012 09:26:25 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E111838FA3@xmb-aln-x02.cisco.com> References: <1348632032.36928.YahooMailClassic@web126005.mail.ne1.yahoo.com> <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.105.146] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19220.001 x-tm-as-result: No--57.498100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "Michael Behringer \(mbehring\)" 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 Sep 2012 09:26:28 -0000 U2VlIGFsc286IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3BzZWMtbGxh LW9ubHktMDEgd2hpY2ggaGFzIGJlZW4gZGlzY3Vzc2VkIHRvZGF5IGF0IHRoZSBMYXJnZSBJbnRl cmltIE1lZXRpbmcNCg0KLcOpcmljDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogaXB2Ni1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSm9uDQo+IFN0ZWVuDQo+IFNlbnQ6IG1lcmNyZWRpIDI2IHNlcHRlbWJy ZSAyMDEyIDE2OjQ0DQo+IFRvOiBPbGUgVHLDuGFuDQo+IENjOiBVc21hbiBMYXRpZjsgaXB2NkBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogSVB2NiBhZGRyZXNzIGFzc2lnbm1lbnQgZm9yIHN0cmlj dGx5IHBvaW50LXRvLXBvaW50IGxpbmtzIGFuZA0KPiBEZXZpY2UgTG9vcGJhY2tzDQo+IA0KPiBT b21lIHZlbmRvcnMgYXJlIHBlcm1pdHRpbmcgdGhlIHVzZSBvZiB0aGUgbGluayBsb2NhbCBpbnRl cmZhY2UgYWRkcmVzcyB0byBiZQ0KPiB1c2VkIGluIG5leHQgaG9wIHJvdXRpbmcgdGhlcmUgZm9y IG5lZ2F0aW5nIHRoZSBuZWVkIHRvIHVzIGFkZGl0aW9uYWwgdW5pY2FzdA0KPiBhZGRyZXNzZXMg b24gUDJQIGxpbmtzLiBXaGVuIHVzaW5nIHJvdXRpbmcgcHJvdG9jb2xzIG9mIE9TUEZ2MyBhbmQg QkdQLCBJDQo+IGhhdmUgdXNlZCAvMTI4IGxvb3BiYWNrIGdsb2JhbCB1bmljYXN0IGFuZCBjb25m aWd1cmVkIGFkdmVydGlzZW1lbnRzIGZvcg0KPiBhZ2dyZWdhdGVkIHByZWZpeGVzIGJldHdlZW4g YSAvMzIgYW5kIC82NCB3aXRoIHBvbGljeSBiYXNlZCByb3V0aW5nLiBUaGlzIGhhcw0KPiBtaW5p bWl6ZWQgdGhlIHBvdGVudGlhbCBmb3Igb3ZlcmxhcCBhbmQgaGFzIGFsc28gYWxsb3dlZCB0aGUg cm91dGluZyB0YWJsZXMNCj4gdG8gYmUgbXVjaCBzbWFsbGVyLiAgSGFzIGFueW9uZSBlbHNlIHRy aWVkIHRoaXMgYXBwcm9hY2g/DQo+IA0KPiBWL1INCj4gDQo+IEpvbiBTdGVlbg0KPiANCj4gT24g U2VwIDI2LCAyMDEyLCBhdCA0OjM2IEFNLCBPbGUgVHLDuGFuIDxvdHJvYW5AZW1wbG95ZWVzLm9y Zz4gd3JvdGU6DQo+IA0KPiA+PiBBbHNvIGl0cyBhIGdvb2QgaWRlYSB0byBlbmNvbXBhc3MgcmVj b21tZW5kYXRpb25zIGZvciBwMnAgYW5kIGxvb3BiYWNrcw0KPiAoYW5kIGZvciB0aGF0IG1hdHRl ciBhbnkgYXNzaWdubWVudCB3aGVyZSBwcmVmaXggbGVuZ3RoIGlzIGdvaW5nIGJleW9uZCAvNjQN Cj4gaW50byBzbWFsbGVyIHN1Ym5ldHMpIGludG8gb25lIHN0YW5kYXJkIHRyYWNrIGJlY2F1c2Ug dGhlIGNhdXRpb25zIGFuZA0KPiBwb3RlbnRpYWwgb3ZlcmxhcCBpc3N1ZXMgdGhhdCBtYXkgZXhp c3QgZm9yIGEgLzEyNyB3b3VsZCBwcmV0dHkgbXVjaCBiZQ0KPiBzaW1pbGFyIGZvciAvMTI4IG9y IGFueSBwcmVmaXggdGhhdCBnb2VzIGludG8gdGhlIGxvd2VyLTY0IGJpdCB0ZXJyaXRvcnkuLi4N Cj4gPg0KPiA+PiBPbmUgbWFqb3IgY29uY2VybiBJIGhhdmUgd2l0aCB1c2luZyAvMTI3IGFuZCAv MTI4IG9uIHAycCBhbmQgbG9vcGJhY2tzDQo+IHJlc3BlY3RpdmVseSBpcyB0aGF0IHdlIG5lZWQg dG8gYmUgY2FyZWZ1bCB0aGF0IHRoZXJlIGFyZSBleGlzdGluZyAoSVNBVEFQDQo+IGV0YykgYW5k IHBvdGVudGlhbGx5IGZ1dHVyZSBpbXBsZW1lbnRhdGlvbnMgdGhhdCB3b3VsZCB1c2UvcmVzZXJ2 ZSBiaXRzIGluDQo+IHRoZSBsb3dlciA2NCBiaXRzIC1zbyB1bmxlc3Mgd2Ugc2V0IGFzaWRlIGJp dCBib3VuZGFyaWVzIGluIHRoZSBsb3dlciA2NA0KPiBiaXRzLCB3ZSBhcmUgbGlrZWx5IHRvIG92 ZXJsYXAgd2l0aCB0aGVzZS4uLiB3aGljaCBpcyB3aHkgaWYgd2UgdXNlIC8xMjcgd2l0aA0KPiBh IHdob2xlIC82NCByZXNlcnZlZCBmb3IgdGhlIHAycCBzdWJuZXQsIHRoZW4gaXQgc2hvdWxkIGJl IG9rYXkgYnV0IGlmIC8xMjcNCj4gb3IgLzEyOHMgYXJlIG51bWJlcmVkIGZyb20gdGhlIHNhbWUg LzY0IGNvbnNlY3V0aXZlbHksIHRoZW4gb2J2aW91c2x5IGl0cw0KPiBsaWtlbHkgdGhhdCB0aGUg cmVzZXJ2ZWQgYml0cyB1c2VkIGJ5IG90aGVyIGltcGxlbWVudGF0aW9ucyB3b3VsZCBvdmVybGFw Lg0KPiBXaGVuIHRoaXMgaGFwcGVucywgYW55IHNjZW5hcmlvIHdoZXJlIHRoZSByb3V0ZXIgKHdo aWNoIGhhcyB0aGlzIG92ZXJsYXApIGlzDQo+IFNSQy9EU1Qgb2YgcGFja2V0cyB3b3VsZCBiZSBj b25mdXNlZCB3aGV0aGVyIHRvIGludGVycHJldCB0aG9zZSBsb3dlci02NCBiaXRzDQo+IGFzIHNp bXBsZSBnbG9iYWwgdW5pY2FzdCBwcmVmaXggb3IgdHJ5IHRvIHRyZWF0IHRoZSBsb3dlci02NCBi aXRzIGluIGENCj4gZGlmZmVyZW50IHdheSAoYWNjb3JkaW5nIHRvIHRoZSBwcm90b2NvbCBpbXBs ZW1lbnRhdGlvbiB3aGljaCBpcyB1c2luZyB0aGF0DQo+IGJpdCBwYXR0ZXJuKS4NCj4gPg0KPiA+ IGEgZmV3IGdlbmVyYWwgcG9pbnRzOg0KPiA+IC0gdGhlIDY0IGJpdCBib3VuZGFyeSBpcyBhICJw b2xpY3kiLiBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIGhhbmRsZSBhbnkNCj4gcHJlZml4IGxlbmd0 aC4NCj4gPiAgIGltcGxlbWVudGF0aW9ucyBzaG91bGQsIGFuZCBhcyBmYXIgYXMgSSBrbm93IGRv LCBjb25zaWRlciBhbGwgYml0cyBpbiB0aGUNCj4gYWRkcmVzcyBhcyB0cmFuc3BhcmVudC4NCj4g PiAtIGEgbG9vcGJhY2sgaW50ZXJmYWNlIHVzaW5nIGEgLzEyOCBjYW5ub3QgYnkgZGVmaW5pdGlv biBvdmVybGFwIHdpdGgNCj4gYW55dGhpbmcgZWxzZS4NCj4gPiAtIGZvciBhIHBvaW50IHRvIHBv aW50IGxpbmsgdGhlIG9wZXJhdG9yIHNob3VsZCBrbm93IGlmIHRoZXJlIGFwcGxpY2F0aW9ucw0K PiBhdCBlaXRoZXIgb2YgdHdvIGVuZCBwb2ludHMgcmVxdWlyaW5nIHRoZSB1c2Ugb2YNCj4gPiAg IHJlc2VydmVkIGFkZHJlc3NlcywgaWYgc28gdGhlIGxpbmsgbXVzdCB1c2UgYSAvNjQgb3RoZXJ3 aXNlIC8xMjcgaXMgZmluZS4NCj4gPg0KPiA+IHRoZXNlIGFyZSBvcGVyYXRpb25hbCBjaG9pY2Vz LCBhbmQgSSBkb24ndCBzZWUgYSBuZWVkIHRvIGNoYW5nZSBJUHY2DQo+IGFkZHJlc3NpbmcgYXJj aGl0ZWN0dXJlIG9yIHByb3RvY29sIHNwZWNpZmljYXRpb25zLg0KPiA+DQo+ID4gY2hlZXJzLA0K PiA+IE9sZQ0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFp bGluZyBsaXN0DQo+ID4gaXB2NkBpZXRmLm9yZw0KPiA+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3Rz OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From sthaug@nethelp.no Sat Sep 29 03:09:08 2012 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 EE55321F8476 for ; Sat, 29 Sep 2012 03:09:07 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng4VI6XQ0X6R for ; Sat, 29 Sep 2012 03:09:07 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 7358521F8470 for ; Sat, 29 Sep 2012 03:09:06 -0700 (PDT) Received: (qmail 67394 invoked from network); 29 Sep 2012 10:09:04 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 29 Sep 2012 10:09:04 -0000 Date: Sat, 29 Sep 2012 12:09:04 +0200 (CEST) Message-Id: <20120929.120904.74687641.sthaug@nethelp.no> To: evyncke@cisco.com Subject: Re: IPv6 address assignment for strictly point-to-point links and Device Loopbacks From: sthaug@nethelp.no In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E111838FA3@xmb-aln-x02.cisco.com> References: <3C3333E3-9F4A-4522-94BD-F92B72C8B9A6@employees.org> <97EB7536A2B2C549846804BBF3FD47E111838FA3@xmb-aln-x02.cisco.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii 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: Sat, 29 Sep 2012 10:09:08 -0000 > See also: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-01 which has been discussed today at the Large Interim Meeting Minor point about this draft: To me there's a contradiction between 2.1 "These link-local addresses SHOULD be hard-coded to prevent the change of EUI-64 addresses when changing of MAC address" and 2.2 "Lower configuration complexity: LLAs require no specific configuration" Steinar Haug, Nethelp consulting, sthaug@nethelp.no