From brian@innovationslab.net Wed Jan 2 08:17:03 2013 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 688C321F8615 for ; Wed, 2 Jan 2013 08:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 dzVRyUF5PEAe for ; Wed, 2 Jan 2013 08:17:02 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id B6D3F21F85FE for ; Wed, 2 Jan 2013 08:17:02 -0800 (PST) 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 AAF0188162; Wed, 2 Jan 2013 08:17:02 -0800 (PST) Received: from clemson.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 579BE130019; Wed, 2 Jan 2013 08:17:02 -0800 (PST) Message-ID: <50E45D7D.8060300@innovationslab.net> Date: Wed, 02 Jan 2013 11:17:01 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Fernando Gont Subject: Re: I-D Action: draft-ietf-6man-ipv6-atomic-fragments-03.txt References: <20121229191431.4571.21706.idtracker@ietfa.amsl.com> <50DF4305.7040904@si6networks.com> In-Reply-To: <50DF4305.7040904@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 16:17:03 -0000 I have requested the start of an IETF Last Call for this document. Regards, Brian On 12/29/12 2:22 PM, Fernando Gont wrote: > Hi, Brian, > > I've rev'ed this document according to our recent email exchange. > > Should we progress this document now? > > Thanks, and Happy New Year! > Fernando > > > > > On 12/29/2012 04:14 PM, 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 : Processing of IPv6 "atomic" fragments >> Author(s) : Fernando Gont >> Filename : draft-ietf-6man-ipv6-atomic-fragments-03.txt >> Pages : 14 >> Date : 2012-12-29 >> >> Abstract: >> The IPv6 specification allows packets to contain a Fragment Header >> without the packet being actually fragmented into multiple pieces (we >> refer to these packets as "atomic fragments"). Such packets >> typically result from hosts that have received an ICMPv6 "Packet Too >> Big" error message that advertises a "Next-Hop MTU" smaller than 1280 >> bytes, and are currently processed by some implementations as >> "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error >> messages an attacker can cause hosts to employ "atomic fragments", >> and then launch any fragmentation-based attacks against such traffic. >> This document discusses the generation of the aforementioned "atomic >> fragments", the corresponding security implications, and formally >> updates RFC 2460 and RFC 5722 such that fragmentation-based attack >> vectors against traffic employing "atomic fragments" are completely >> eliminated. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-6man-ipv6-atomic-fragments-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-atomic-fragments-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 iesg-secretary@ietf.org Wed Jan 2 09:03:09 2013 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 5656221F86BE; Wed, 2 Jan 2013 09:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 K4aKcsDw5NdO; Wed, 2 Jan 2013 09:03:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B5221F850D; Wed, 2 Jan 2013 09:03:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Processing of IPv6 "atomic" fragments) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130102170308.23202.41467.idtracker@ietfa.amsl.com> Date: Wed, 02 Jan 2013 09:03:08 -0800 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, 02 Jan 2013 17:03:09 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Processing of IPv6 "atomic" fragments' 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 2013-01-16. 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 IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets typically result from hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a "Next-Hop MTU" smaller than 1280 bytes, and are currently processed by some implementations as "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error messages an attacker can cause hosts to employ "atomic fragments", and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned "atomic fragments", the corresponding security implications, and formally updates RFC 2460 and RFC 5722 such that fragmentation-based attack vectors against traffic employing "atomic fragments" are completely eliminated. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/ballot/ No IPR declarations have been submitted directly on this I-D. From ietf@rozanak.com Thu Jan 3 15:14:41 2013 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 6CF0B21F8DD0 for ; Thu, 3 Jan 2013 15:14:41 -0800 (PST) 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 X3LctwzWFTIa for ; Thu, 3 Jan 2013 15:14:41 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id D163C21F8D51 for ; Thu, 3 Jan 2013 15:14:40 -0800 (PST) Received: from kopoli (g225034069.adsl.alicedsl.de [92.225.34.69]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MPlgA-1Tujk71sTy-005D2d; Thu, 03 Jan 2013 18:14:39 -0500 From: "Hosnieh Rafiee" To: Subject: Call for comments on draft-rafiee-6man-ssas-00.txt Date: Fri, 4 Jan 2013 00:14:34 +0100 Message-ID: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3qBjubrheh5C8XRaicccIyEVKaog== Content-Language: en-us X-Provags-ID: V02:K0:Uo6bKD1dA7w2ZtZIoVnZpjde8dCY6s69K0ysJydKQ5Z 6SK4E1QT4KVudM0jyTG0t+QAUkeMWJVWQ0DEeCPytcrWgRQQP0 XrafFxXdiC11yiFCwn+KRzWspp23koFOo4dLnXuMxrlWu5N7O5 urSJoNVKb8aRLGzmll3cwQQH+SYW/9vXqQHeOfLirMl/0B6YbJ oorUJfXjhccoj5CBiZpGXsvZm5hYPb6AieZT6TrWwJH9BShY1S GCRIDExdHMc9+yfhrkep8YnMLQD5B0CFmWMRCszIgYY01bQVHt S3JjqlCOrE+bpDaHl5KviuC0Y3A/CtPvzrSHeK2MzVzACzT2Dz 8Zj6qz0umgBcV6AtZdUY= 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, 03 Jan 2013 23:14:41 -0000 Dear All, This draft addresses the following problem: Unfortunately the existing drafts do not consider the integration of = security and privacy for the generation of the Interface ID (IID). This = draft tries to offer a solution to this problem while at the same time = considering the generation and verification times and complexity of the = existing algorithms. Please take a look. Comments are greatly = appreciated. Thank you, Hosnieh Filename: draft-rafiee-6man-ssas Revision: 00 Title: A Simple Secure Addressing Generation Scheme for IPv6 = AutoConfiguration (SSAS) Creation date: 2013-01-02 WG ID: Individual Submission Number of pages: 13 URL: = http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-00.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas Htmlized: http://tools.ietf.org/html/draft-rafiee-6man-ssas-00 Abstract: The default method for IPv6 address generation uses two unique manufacturer IDs that are assigned by the IEEE Standards Association [1] (section 2.5.1 RFC-4291) [RFC4291]. This means that a node will always have the same Interface ID (IID) whenever it connects to a new network. Because the node's IP address does not change, the node is vulnerable to privacy related attacks. To address this issue, there are currently two mechanisms in use to randomize the IID, Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy Extension [RFC4941]. The problem with the former approach is the computational cost involved for the IID generation. The problem with the latter approach is that it lacks security. This document offers a new algorithm for use in the generation of the IID while, at the same time, securing the node against some types of attack, such as IP spoofing. These attacks are prevented with the addition of a signature to the Neighbor Discovery messages (NDP). From v6ops@globis.net Sat Jan 5 02:29:59 2013 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 E436521F86D9 for ; Sat, 5 Jan 2013 02:29:59 -0800 (PST) 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 QlL4+5bP3mJ9 for ; Sat, 5 Jan 2013 02:29:59 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id CEF6621F86D6 for ; Sat, 5 Jan 2013 02:29:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8C3B2870106; Sat, 5 Jan 2013 11:24:41 +0100 (CET) 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 LKLXECl65gjM; Sat, 5 Jan 2013 11:24:08 +0100 (CET) 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 D79C5870042; Sat, 5 Jan 2013 11:24:07 +0100 (CET) Message-ID: <50E7FF41.50100@globis.net> Date: Sat, 05 Jan 2013 11:24:01 +0100 From: Ray Hunter User-Agent: Postbox 3.0.6 (Macintosh/20121022) MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Last Call: (Processing of IPv6 "atomic" fragments) to Proposed Standard References: <20130102170308.23202.41467.idtracker@ietfa.amsl.com> In-Reply-To: <20130102170308.23202.41467.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont 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, 05 Jan 2013 10:30:00 -0000 I have read this draft and support it, as it provides a valuable security update to IPv6. Nits: s/A received "atomic fragments" should be "reassembled" from the contents of that sole fragment./ Each received "atomic fragment" should be individually "reassembled" from the contents of that sole fragment./ /Many implementations fail to perform validation checks on the received ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and [RFC5927]./ Although RFC4443 is a standard track document, none of the language in Section 5.2 contains RFC2119 keywords. RFC5927 is informational. You may consider this a separate but related issue to atomic fragments, but does validation checking of ICMPv6 messages need to be addressed further in your current ID? I think your current ID stands alone whether these validation checks are performed or not. Are we then really justified in chastising implementors who ignore these recommendations by somehow implying they've 'failed'? Suggested alternative s/Many implementations fail to/Many implementations do not/ regards, RayH The IESG wrote: > The IESG has received a request from the IPv6 Maintenance WG (6man) to > consider the following document: > - 'Processing of IPv6 "atomic" fragments' > 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 2013-01-16. 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 IPv6 specification allows packets to contain a Fragment Header > without the packet being actually fragmented into multiple pieces (we > refer to these packets as "atomic fragments"). Such packets > typically result from hosts that have received an ICMPv6 "Packet Too > Big" error message that advertises a "Next-Hop MTU" smaller than 1280 > bytes, and are currently processed by some implementations as > "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error > messages an attacker can cause hosts to employ "atomic fragments", > and then launch any fragmentation-based attacks against such traffic. > This document discusses the generation of the aforementioned "atomic > fragments", the corresponding security implications, and formally > updates RFC 2460 and RFC 5722 such that fragmentation-based attack > vectors against traffic employing "atomic fragments" are completely > eliminated. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > From v6ops@globis.net Sat Jan 5 08:48:02 2013 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 2001121F857A for ; Sat, 5 Jan 2013 08:48:02 -0800 (PST) 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 xvJJZMMopMeE for ; Sat, 5 Jan 2013 08:48:01 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id B206521F856D for ; Sat, 5 Jan 2013 08:48:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0BD388700F6; Sat, 5 Jan 2013 17:42:44 +0100 (CET) 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 nrWJhBsrRv5l; Sat, 5 Jan 2013 17:42:10 +0100 (CET) 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 4357B870042; Sat, 5 Jan 2013 17:42:10 +0100 (CET) Message-ID: <50E857DC.7050608@globis.net> Date: Sat, 05 Jan 2013 17:42:04 +0100 From: Ray Hunter User-Agent: Postbox 3.0.6 (Macintosh/20121022) MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt References: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> In-Reply-To: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> Content-Type: text/plain; charset=ISO-8859-1 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, 05 Jan 2013 16:48:02 -0000 I have read this draft. Following all IMVHO. The claim in Section 3.1 that replay attacks are avoided by having a timestamp window of 10 minutes seems rather exaggerated. 10 minutes is an eternity in some computer networks. If I was an attacker, I would be happy to wait and detect the 10 minute window when I could cause disruption. That may be enough time to do serious damage in some systems. The claim in section 3.2 that DoS attacks are avoided by rate limiting NDP messages also seems rather exaggerated. How would a rate filter know in advance which messages to discard without processing all of the SSAS signatures? Overloading of the NDP mechanism could still potentially cause nodes to time out their caches, and/or prevent new peerings from forming. And including encryption in NDP may actually make it easier to overload the NDP process rather than harder (because the defender has to do relatively more work than the attacker in the situation where encryption is employed compared to if there was no encryption). The claim in the Security Considerations of /the probability of an attacker finding the same value is 0.00016, a very small value./ would seem to be a bit exaggerated. This seems to ignore birthday attacks. And especially since it appears from the text that the consequence of making this match is that the information leaked to the attacker directly relates to 32 bits of the private key. Is that a correct reading? There are many LANs containing many thousands of nodes, and as an attacker I'd be happy to passively monitor long term if it meant I could glean (significant portions of) one public key (that did not rotate very often and once discovered would potentially be extremely useful). The recommendation of a /maximum of 2 days/ for public key times ignores the practical need in many systems for very long lived sessions, and the difficulty of securely rotating public keys on distributed systems. In summary, I am currently unconvinced whether this ID as it stands significantly moves the state of the art forward compared to existing mechanisms. regards, RayH Hosnieh Rafiee wrote: > Dear All, > > This draft addresses the following problem: > Unfortunately the existing drafts do not consider the integration of security and privacy for the generation of the Interface ID (IID). This draft tries to offer a solution to this problem while at the same time considering the generation and verification times and complexity of the existing algorithms. Please take a look. Comments are greatly appreciated. > Thank you, > Hosnieh > > > > Filename: draft-rafiee-6man-ssas > Revision: 00 > Title: A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration (SSAS) > Creation date: 2013-01-02 > WG ID: Individual Submission > Number of pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-00.txt > Status: http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas > Htmlized: http://tools.ietf.org/html/draft-rafiee-6man-ssas-00 > > > Abstract: > The default method for IPv6 address generation uses two unique > manufacturer IDs that are assigned by the IEEE Standards Association > [1] (section 2.5.1 RFC-4291) [RFC4291]. This means that a node will > always have the same Interface ID (IID) whenever it connects to a new > network. Because the node's IP address does not change, the node is > vulnerable to privacy related attacks. To address this issue, there > are currently two mechanisms in use to randomize the IID, > Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy > Extension [RFC4941]. The problem with the former approach is the > computational cost involved for the IID generation. The problem with > the latter approach is that it lacks security. This document offers a > new algorithm for use in the generation of the IID while, at the same > time, securing the node against some types of attack, such as IP > spoofing. These attacks are prevented with the addition of a > signature to the Neighbor Discovery messages (NDP). > > > From ietf@rozanak.com Sat Jan 5 11:45:56 2013 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 AF00321F846E for ; Sat, 5 Jan 2013 11:45:56 -0800 (PST) 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 OIQciHqd9McE for ; Sat, 5 Jan 2013 11:45:55 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 93B9821F843E for ; Sat, 5 Jan 2013 11:45:55 -0800 (PST) Received: from kopoli (g225034002.adsl.alicedsl.de [92.225.34.2]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LpbaA-1TOJ8f1Y0M-00fWuV; Sat, 05 Jan 2013 14:45:11 -0500 From: "Hosnieh Rafiee" To: "'Ray Hunter'" References: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> <50E857DC.7050608@globis.net> In-Reply-To: <50E857DC.7050608@globis.net> Subject: RE: Call for comments on draft-rafiee-6man-ssas-00.txt Date: Sat, 5 Jan 2013 20:45:03 +0100 Message-ID: <000601cdeb7d$2b768780$82639680$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI7ECCw5lZJtuTcH4KW/U5riPTnyQE+wFeXl1bJSYA= Content-Language: en-us X-Provags-ID: V02:K0:z6NzQXdNZlhFqVLOn6Loqqc9Cc2nw5EA56kbTyqRMxo s2MqYqQ+RMCS2HrZUGWTX+oODu0H6nHVpcSAYIMxQXS3B7j8Y+ abzZPq04ancyJFRCpz2+m60nB862wgzB80YbRperJ+gbZXeBmt B5DfMH3GhM9U5zFmXRH21yZfstgBW/yQDY0lcdNIuXPxxoPkXG Fd+keVli+9TT5GsAfAJsoWdPDjkj4DQAKdJeYWuDcZgFZy5SdM Y0nFPhZ1CjV9Y8TscAM7AGl+Y65seV2BLgEzJ2uhzKMhQoy2yi EcEZQ+ugRDFTZ5H0oTk3WoRYmauINo/qeEMfbgjAbgXvtr0QjM Nq0r5Ty/289PfL7+BU5s= 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, 05 Jan 2013 19:45:56 -0000 Dear Ray, Thanks a lot for your careful review. My responses to your concerns follow: >The claim in Section 3.1 that replay attacks are avoided by having a timestamp window of 10 minutes seems rather exaggerated. >10 minutes is an eternity in some computer networks. If I was an attacker, I would be happy to wait and detect the 10 minute window when I could cause disruption. That may be enough time to do >serious damage in some systems. I considered the worst case scenario where a network might have a very high delay rate. I will investigate further to determinate an appropriate time to use. >The claim in section 3.2 that DoS attacks are avoided by rate limiting NDP messages also seems rather exaggerated. >How would a rate filter know in advance which messages to discard without processing all of the SSAS signatures? Only the source IP address needs to be checked. If the receiver receives several NA messages in a short period of time (seconds) with this IP address, then the future messages would be discarded. An additional option would be to specify the number of messages a node can receive per minute. This number would be dependent on the CPU power (how many messages this node can handle per minute so that the other operation of this node are not affected, because the verification time is usually fixed.) >The claim in the Security Considerations of /the probability of an attacker finding the same value is 0.00016, a very small value./ would seem to be a bit exaggerated. This seems to ignore birthday >attacks. And especially since it appears from the text that the consequence of making this match is that the information leaked to the attacker directly relates to 32 bits of the private key. Is that a >correct reading? Actually the attacker would need to generate a public key that has 4 sequential bytes (starting from a specific part of the public key (specific index)) matching those in IP address. It is not feasible or very likely that an attacker would try to find the private key for this node because, in this case, he would need to do a brute force attack against the 1024-bit key in order to find the matching number to that private key. This option is not really viable because this public key is just valid for a certain period of time and will then change. The birthday attack would also be difficult because, again, the attacker would need to generate a public key and not just 32 sequential bits. What he generated would have to match the bits starting from its specific index in order to match the 32 bits of the IP address. To summarize, the attacker would need to generate a 1024 bit public key where the 32 sequential bits start at a specific point in order to match the IP address. The mathematical proof that I used depicts the very worst case scenario where we are just matching 32 against 32. What also needs to be considered is what the probability is of a public key matching a private key while at the same time matching the specific sequential 32 bits of this public key while also matching the 32 last most bits of IP address. > There are many LANs containing many thousands of nodes, and as an attacker I'd be happy to passively monitor long term if it meant I could glean (significant portions of) one public key (that did >not rotate very often and once discovered would potentially be extremely useful). In order to avoid the use of an index of 1 (not rotate often issue) as the starting index of public key, I will change that section to this: If the second byte of a partial ID is greater than the size of the public key array in bytes, minus 4, then choose that byte and shift its contents 2 bits to the right (the first two bits will be zero) and consider this number the starting index of the public key array of bytes. This ensures that the value of that byte will be less than 124. >The recommendation of a /maximum of 2 days/ for public key times ignores the practical need in many systems for very long lived sessions, and the difficulty of securely rotating public keys on >distributed systems. If we choose 20 days, the probability would be 0.001609325408935546875 and that is still a small value. The value of two was chosen as an average life time. I also explained in the draft that it is recommended to generate public/private keys on the fly. This means that the implementation of the SSAS algorithm will do a better job of supporting automatic key generation without increasing administration tasks. As stated in other RFCs, the old IP address will still be valid for the current session, but will not be valid for the start of new sessions. The status of this old IP address should be changed to deprecated. I will add this to the draft to clarify the lifetime of the IP address. If there is any further questions or concerns, I will be happy to answer them. Thank you, Hosnieh -----Original Message----- From: Ray Hunter [mailto:v6ops@globis.net] Sent: Saturday, January 05, 2013 5:42 PM To: Hosnieh Rafiee Cc: ipv6@ietf.org Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt I have read this draft. Following all IMVHO. The claim in Section 3.1 that replay attacks are avoided by having a timestamp window of 10 minutes seems rather exaggerated. 10 minutes is an eternity in some computer networks. If I was an attacker, I would be happy to wait and detect the 10 minute window when I could cause disruption. That may be enough time to do serious damage in some systems. The claim in section 3.2 that DoS attacks are avoided by rate limiting NDP messages also seems rather exaggerated. How would a rate filter know in advance which messages to discard without processing all of the SSAS signatures? Overloading of the NDP mechanism could still potentially cause nodes to time out their caches, and/or prevent new peerings from forming. And including encryption in NDP may actually make it easier to overload the NDP process rather than harder (because the defender has to do relatively more work than the attacker in the situation where encryption is employed compared to if there was no encryption). The claim in the Security Considerations of /the probability of an attacker finding the same value is 0.00016, a very small value./ would seem to be a bit exaggerated. This seems to ignore birthday attacks. And especially since it appears from the text that the consequence of making this match is that the information leaked to the attacker directly relates to 32 bits of the private key. Is that a correct reading? There are many LANs containing many thousands of nodes, and as an attacker I'd be happy to passively monitor long term if it meant I could glean (significant portions of) one public key (that did not rotate very often and once discovered would potentially be extremely useful). The recommendation of a /maximum of 2 days/ for public key times ignores the practical need in many systems for very long lived sessions, and the difficulty of securely rotating public keys on distributed systems. In summary, I am currently unconvinced whether this ID as it stands significantly moves the state of the art forward compared to existing mechanisms. regards, RayH Hosnieh Rafiee wrote: > Dear All, > > This draft addresses the following problem: > Unfortunately the existing drafts do not consider the integration of security and privacy for the generation of the Interface ID (IID). This draft tries to offer a solution to this problem while at the same time considering the generation and verification times and complexity of the existing algorithms. Please take a look. Comments are greatly appreciated. > Thank you, > Hosnieh > > > > Filename: draft-rafiee-6man-ssas > Revision: 00 > Title: A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration (SSAS) > Creation date: 2013-01-02 > WG ID: Individual Submission > Number of pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-00.txt > Status: http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas > Htmlized: http://tools.ietf.org/html/draft-rafiee-6man-ssas-00 > > > Abstract: > The default method for IPv6 address generation uses two unique > manufacturer IDs that are assigned by the IEEE Standards Association > [1] (section 2.5.1 RFC-4291) [RFC4291]. This means that a node will > always have the same Interface ID (IID) whenever it connects to a new > network. Because the node's IP address does not change, the node is > vulnerable to privacy related attacks. To address this issue, there > are currently two mechanisms in use to randomize the IID, > Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy > Extension [RFC4941]. The problem with the former approach is the > computational cost involved for the IID generation. The problem with > the latter approach is that it lacks security. This document offers a > new algorithm for use in the generation of the IID while, at the same > time, securing the node against some types of attack, such as IP > spoofing. These attacks are prevented with the addition of a > signature to the Neighbor Discovery messages (NDP). > > > From fgont@si6networks.com Sat Jan 5 14:32:45 2013 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 B46E921F8548 for ; Sat, 5 Jan 2013 14:32:45 -0800 (PST) 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 Fkt6oluaj8ZR for ; Sat, 5 Jan 2013 14:32:45 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id E5D4D21F8541 for ; Sat, 5 Jan 2013 14:32:44 -0800 (PST) Received: from [186.134.46.60] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TrcHT-0004L7-Ew; Sat, 05 Jan 2013 23:31:58 +0100 Message-ID: <50E8A9D4.60800@si6networks.com> Date: Sat, 05 Jan 2013 19:31:48 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt References: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> In-Reply-To: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 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, 05 Jan 2013 22:32:45 -0000 Hosnieh, I've reviewed the I-D till Section 3 (didn't get into 3.1)... but it looks like the I-D got some things wrong.... Please see in-line... > Abstract > > The default method for IPv6 address generation uses two unique > manufacturer IDs that are assigned by the IEEE Standards Association > [1] (section 2.5.1 RFC-4291) [RFC4291]. What are the two IDs assigned by the IEEE? > This means that a node will > always have the same Interface ID (IID) whenever it connects to a new > network. Because the node's IP address does not change, the node is > vulnerable to privacy related attacks. The IP address does change. It's only the IID part that usually doesn't. > To address this issue, there > are currently two mechanisms in use to randomize the IID, > Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy > Extension [RFC4941]. This is incorrect. CGAs are meant to solve a different problem. Privacy Addresses do (partially) mitigate this issue. > The problem with the former approach is the > computational cost involved for the IID generation. No. The problem with CGAs are: * IPRs * Requirement for a PKI with SEND (which is where CGAs are used) * Small ROI (complexity to implement, complexity to deploy, small number of implementations)... all to solve a problem we have lived with in the IPv4 world for years... and unless you solve other problems (e.g., unsecured DNS), it doesn't make much sense to bother with SEND. > The problem with > the latter approach is that it lacks security. This document offers a > new algorithm for use in the generation of the IID while, at the same > time, securing the node against some types of attack, such as IP > spoofing. These attacks are prevented with the addition of a > signature to the Neighbor Discovery messages (NDP). If you just sign the NDP messages, you're not mitigating spoofing -- how would a non-local host authenticate the packet, if the signatures are in NDP messages (which are only local)? > 1. Introduction > > IPv6 addresses consist of two parts; the subnet prefix, which is the Global routing prefix, subnet ID, Interface ID (in the case of GUAs, of course) > which is the 64 rightmost bits of IPv6 address. The IEEE Standards > Association [1] (section 2.5.1 RFC-4291) [RFC4291] offered a standard > for the generation of the IPv6 Interface IDs (IID). The IEEE does not standardize IPv6. > They are > generated by the concatenation of an Extended Unique Identifier > (EUI-64) with an Organizationally Unique Identifier (OUI), EUI-64 includes the OUI. > both of > which are assigned by the IEEE Registration Authority (IEEE RA). For > example, if a manufacturer's OUI-36 hexadecimal value is > 00-5A-D1-02-3, and the manufacture hexadecimal value for the > extension identifier for a given component is 4-42-61-71, The latter is assigned by the vendor, not by the IEEE. > EUI-64 value generated from these two numbers will be > 00-5A-D1-02-34-42-61-71. There are two mechanisms used to randomize > the IID; CGA [RFC3972] and Privacy Extension [RFC4941]. Please clarify what you mean by "randomize". > 3. Problem Statement > > The drawback to the IEEE Standards Association approach for the > generation of the IID is one of privacy. That's an *IETF* approach, not IEEE's. > The main problem with the privacy extension mechanism, when using the > first approach, as explained in section 3.2.1 RFC-4941 [RFC4941] , > i.e., using stable storage, is the lack of a provision for use of a > security mechanism. Not sure what you mean by "lack of a provision for use of a security mechanism.". > A Privacy extension can prevent attacks related > to privacy issues, We have already gone through this one: Privacy addresses only *partially* mitigate host-tracking attacks. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ietf@rozanak.com Sat Jan 5 14:44:34 2013 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 12BB921F84E8 for ; Sat, 5 Jan 2013 14:44:34 -0800 (PST) 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 auW0ZvHSH60y for ; Sat, 5 Jan 2013 14:44:33 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2C77221F84E6 for ; Sat, 5 Jan 2013 14:44:33 -0800 (PST) Received: from kopoli (g225034002.adsl.alicedsl.de [92.225.34.2]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LzKe1-1Swc3F32vp-014HtF; Sat, 05 Jan 2013 17:44:20 -0500 From: "Hosnieh Rafiee" To: "'Fernando Gont'" References: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> <50E8A9D4.60800@si6networks.com> In-Reply-To: <50E8A9D4.60800@si6networks.com> Subject: RE: Call for comments on draft-rafiee-6man-ssas-00.txt Date: Sat, 5 Jan 2013 23:44:13 +0100 Message-ID: <000901cdeb96$32887d80$97997880$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI7ECCw5lZJtuTcH4KW/U5riPTnyQLGGXo7l0ra4jA= Content-Language: en-us X-Provags-ID: V02:K0:h7bRuOxOxL0fDf1CCD28yVK/MntP8TIUIcnRzULxW7O d8u3Vy3Usm9aNApeRXYjXkdYn4Tm/GPwWtE6a/PL3pEMLuDHzs XbejVe7jvbl5wHK85kNP5e3dJYzakfOoLXj90BGTv7Ht4lbWjf IvZX4MkERIB1RBcFCkqhACpWBXJuK4hrChmN/ZVNAqdDbn8636 LAqxoZ64Nk685HcsliRL/UAsCueY7dM1Xpzbq7RNgU2U2dZ1U5 Czr/Hccihh75sPrtbOyAudIRj3Rt84L8tBIIlcWQR3wGcMbL0H 2VdJyrAFwkkwPYvl6JIUY1plSfIyYBo44Dsp15ljTEpIW9ohra AqosqSIj6CAWPWltCO4Y= 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, 05 Jan 2013 22:44:34 -0000 Thanks for your comments. -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com] Sent: Saturday, January 05, 2013 11:32 PM To: Hosnieh Rafiee Cc: ipv6@ietf.org Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt Hosnieh, I've reviewed the I-D till Section 3 (didn't get into 3.1)... but it looks like the I-D got some things wrong.... Please see in-line... > Abstract > > The default method for IPv6 address generation uses two unique > manufacturer IDs that are assigned by the IEEE Standards Association > [1] (section 2.5.1 RFC-4291) [RFC4291]. What are the two IDs assigned by the IEEE? > This means that a node will > always have the same Interface ID (IID) whenever it connects to a new > network. Because the node's IP address does not change, the node is > vulnerable to privacy related attacks. The IP address does change. It's only the IID part that usually doesn't. > To address this issue, there > are currently two mechanisms in use to randomize the IID, > Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy > Extension [RFC4941]. This is incorrect. CGAs are meant to solve a different problem. Privacy Addresses do (partially) mitigate this issue. > The problem with the former approach is the > computational cost involved for the IID generation. No. The problem with CGAs are: * IPRs * Requirement for a PKI with SEND (which is where CGAs are used) * Small ROI (complexity to implement, complexity to deploy, small number of implementations)... all to solve a problem we have lived with in the IPv4 world for years... and unless you solve other problems (e.g., unsecured DNS), it doesn't make much sense to bother with SEND. > The problem with > the latter approach is that it lacks security. This document offers a > new algorithm for use in the generation of the IID while, at the same > time, securing the node against some types of attack, such as IP > spoofing. These attacks are prevented with the addition of a > signature to the Neighbor Discovery messages (NDP). If you just sign the NDP messages, you're not mitigating spoofing -- how would a non-local host authenticate the packet, if the signatures are in NDP messages (which are only local)? > 1. Introduction > > IPv6 addresses consist of two parts; the subnet prefix, which is > the Global routing prefix, subnet ID, Interface ID (in the case of GUAs, of course) > which is the 64 rightmost bits of IPv6 address. The IEEE Standards > Association [1] (section 2.5.1 RFC-4291) [RFC4291] offered a standard > for the generation of the IPv6 Interface IDs (IID). The IEEE does not standardize IPv6. > They are > generated by the concatenation of an Extended Unique Identifier > (EUI-64) with an Organizationally Unique Identifier (OUI), EUI-64 includes the OUI. > both of > which are assigned by the IEEE Registration Authority (IEEE RA). For > example, if a manufacturer's OUI-36 hexadecimal value is > 00-5A-D1-02-3, and the manufacture hexadecimal value for the > extension identifier for a given component is 4-42-61-71, The latter is assigned by the vendor, not by the IEEE. > EUI-64 value generated from these two numbers will be > 00-5A-D1-02-34-42-61-71. There are two mechanisms used to randomize > the IID; CGA [RFC3972] and Privacy Extension [RFC4941]. Please clarify what you mean by "randomize". > 3. Problem Statement > > The drawback to the IEEE Standards Association approach for the > generation of the IID is one of privacy. That's an *IETF* approach, not IEEE's. > The main problem with the privacy extension mechanism, when using the > first approach, as explained in section 3.2.1 RFC-4941 [RFC4941] , > i.e., using stable storage, is the lack of a provision for use of a > security mechanism. Not sure what you mean by "lack of a provision for use of a security mechanism.". > A Privacy extension can prevent attacks related > to privacy issues, We have already gone through this one: Privacy addresses only *partially* mitigate host-tracking attacks. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Sat Jan 5 14:57:25 2013 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 31B4321F8203 for ; Sat, 5 Jan 2013 14:57:25 -0800 (PST) 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 p64PPvh7JUGR for ; Sat, 5 Jan 2013 14:57:24 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 82D5C21F8551 for ; Sat, 5 Jan 2013 14:57:24 -0800 (PST) Received: from [186.134.46.60] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Trcg2-0004vN-PX; Sat, 05 Jan 2013 23:57:20 +0100 Message-ID: <50E8AF5D.4060101@si6networks.com> Date: Sat, 05 Jan 2013 19:55:25 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ray Hunter Subject: Re: Last Call: (Processing of IPv6 "atomic" fragments) to Proposed Standard References: <20130102170308.23202.41467.idtracker@ietfa.amsl.com> <50E7FF41.50100@globis.net> In-Reply-To: <50E7FF41.50100@globis.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 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, 05 Jan 2013 22:57:25 -0000 Hi, Ray, Thanks so much for your feedback! Please find my comments in-line... On 01/05/2013 07:24 AM, Ray Hunter wrote: > I have read this draft and support it, as it provides a valuable > security update to IPv6. Thanks! > Nits: > > s/A received "atomic fragments" should be "reassembled" from the > contents of that sole fragment./ > Each received "atomic fragment" should be individually "reassembled" > from the contents of that sole fragment./ Will apply this change to the next rev. > /Many implementations fail to perform validation checks on the received > ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and > [RFC5927]./ > > Although RFC4443 is a standard track document, none of the language in > Section 5.2 contains RFC2119 keywords. > RFC5927 is informational. > > You may consider this a separate but related issue to atomic fragments, > but does validation checking of ICMPv6 messages need to be addressed > further in your current ID? What I've tried to note with the above comment is how trivial it is to trigger the use of IPv6 atomic fragments. > I think your current ID stands alone whether these validation checks are performed or not. Agreed. But what I've tried to stress is that it is trivial to make any connection employ atomic fragments -- hence it's not that the only target of atomic-fragment attacks are those connections already employed atomic fragments or fragmentation: it's trivial to trigger the use of such fragments, and then perform a fragmentation-based attack... > Are we then really justified in chastising implementors who ignore these > recommendations by somehow implying they've 'failed'? > Suggested alternative s/Many implementations fail to/Many > implementations do not/ I'm fine with your proposed text. Should the resulting text then be: "Many implementations do not perform validation checks on the received ICMPv6 error messages as recommended in Section 5.2 of [RFC4443] and [RFC5927]" ? Or can this be read as "they do not perform these validation checks, as RFC4443 and RFC5927 recommend *not* to do so"? (English as second language here) 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 v6ops@globis.net Sat Jan 5 23:45:07 2013 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 ACAA221F8831 for ; Sat, 5 Jan 2013 23:45:07 -0800 (PST) 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 1Itlil7SQnrp for ; Sat, 5 Jan 2013 23:45:06 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7891C21F881C for ; Sat, 5 Jan 2013 23:45:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3C5418700DD; Sun, 6 Jan 2013 08:39:49 +0100 (CET) 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 ffTTRasv7Izc; Sun, 6 Jan 2013 08:39:28 +0100 (CET) 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 207CF87007B; Sun, 6 Jan 2013 08:39:28 +0100 (CET) Message-ID: <50E92A29.8030602@globis.net> Date: Sun, 06 Jan 2013 08:39:21 +0100 From: Ray Hunter User-Agent: Postbox 3.0.6 (Macintosh/20121022) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Last Call: (Processing of IPv6 "atomic" fragments) to Proposed Standard References: <20130102170308.23202.41467.idtracker@ietfa.amsl.com> <50E7FF41.50100@globis.net> <50E8AF5D.4060101@si6networks.com> In-Reply-To: <50E8AF5D.4060101@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 06 Jan 2013 07:45:07 -0000 inline. > Fernando Gont > 5 January 2013 23:55 > Hi, Ray, > > Thanks so much for your feedback! Please find my comments in-line... > > > On 01/05/2013 07:24 AM, Ray Hunter wrote: >> I have read this draft and support it, as it provides a valuable >> security update to IPv6. > > Thanks! > > >> Nits: >> >> s/A received "atomic fragments" should be "reassembled" from the >> contents of that sole fragment./ >> Each received "atomic fragment" should be individually "reassembled" >> from the contents of that sole fragment./ > > Will apply this change to the next rev. > Ack. > >> /Many implementations fail to perform validation checks on the received >> ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and >> [RFC5927]./ >> >> Although RFC4443 is a standard track document, none of the language in >> Section 5.2 contains RFC2119 keywords. >> RFC5927 is informational. >> >> You may consider this a separate but related issue to atomic fragments, >> but does validation checking of ICMPv6 messages need to be addressed >> further in your current ID? > > What I've tried to note with the above comment is how trivial it is to > trigger the use of IPv6 atomic fragments. > Agreed it's trivial. Do you consider the existence of atomic fragments to be harmful per se? Or just the fact that they can adversely affect re-assembly at a host, and thus can be used as an attack vector on the destination host? Given the potential adverse effects on middleware boxes such as firewalls, I'm thinking you consider them harmful per se. >> I think your current ID stands alone whether these validation checks are performed or not. > > Agreed. But what I've tried to stress is that it is trivial to make any > connection employ atomic fragments -- hence it's not that the only > target of atomic-fragment attacks are those connections already employed > atomic fragments or fragmentation: it's trivial to trigger the use of > such fragments, and then perform a fragmentation-based attack... > Understood. But if we consider atomic fragments to be harmful per se, what concrete advice can we give implementors in a SHOULD clause in this ID on how to process received ICMPv6 Packet Too Big messages in order to make triggering atomic fragments less trivial? If we haven't got any advice on how to stop them being triggered, we can't really moan that it's trivial to trigger them. PMTUD is currently pretty fundamental for correct operation of IPv6. Re-reading RFC1981, it's tough to see what more anyone can sensibly do in a lightweight implementation. >> Are we then really justified in chastising implementors who ignore these >> recommendations by somehow implying they've 'failed'? >> Suggested alternative s/Many implementations fail to/Many >> implementations do not/ > > I'm fine with your proposed text. Should the resulting text then be: > > "Many implementations do not perform validation checks on the received > ICMPv6 error messages as recommended in Section 5.2 of [RFC4443] and > [RFC5927]" Yes, the version above. > ? > > Or can this be read as "they do not perform these validation checks, as > RFC4443 and RFC5927 recommend *not* to do so"? (English as second > language here) > > Thanks! > > Best regards, > Ray Hunter > 5 January 2013 11:24 > I have read this draft and support it, as it provides a valuable > security update to IPv6. > > Nits: > > s/A received "atomic fragments" should be "reassembled" from the > contents of that sole fragment./ > Each received "atomic fragment" should be individually "reassembled" > from the contents of that sole fragment./ > > > > /Many implementations fail to perform validation checks on the received > ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and > [RFC5927]./ > > Although RFC4443 is a standard track document, none of the language in > Section 5.2 contains RFC2119 keywords. > RFC5927 is informational. > > You may consider this a separate but related issue to atomic fragments, > but does validation checking of ICMPv6 messages need to be addressed > further in your current ID? I think your current ID stands alone whether > these validation checks are performed or not. > > Are we then really justified in chastising implementors who ignore these > recommendations by somehow implying they've 'failed'? > Suggested alternative s/Many implementations fail to/Many > implementations do not/ > > regards, > RayH > > ------------------------------------------------------------------------ From jeremy.duncan@salientfed.com Sun Jan 6 08:30:08 2013 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 6045B21F8561 for ; Sun, 6 Jan 2013 08:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, TRACKER_ID=2.003] 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 mesjujZC-Bod for ; Sun, 6 Jan 2013 08:30:07 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id AFA7D21F851E for ; Sun, 6 Jan 2013 08:30:06 -0800 (PST) Received: from mail107-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Sun, 6 Jan 2013 16:30:05 +0000 Received: from mail107-va3 (localhost [127.0.0.1]) by mail107-va3-R.bigfish.com (Postfix) with ESMTP id 6A4EA160223; Sun, 6 Jan 2013 16:30:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371Id6eah542I1432I4015I62a3Izz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh1033ILz2fh2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h17ej1155h) Received-SPF: pass (mail107-va3: domain of salientfed.com designates 157.56.236.101 as permitted sender) client-ip=157.56.236.101; envelope-from=jeremy.duncan@salientfed.com; helo=BY2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail107-va3 (localhost.localdomain [127.0.0.1]) by mail107-va3 (MessageSwitch) id 1357489803399969_27485; Sun, 6 Jan 2013 16:30:03 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.250]) by mail107-va3.bigfish.com (Postfix) with ESMTP id 540FE200B3; Sun, 6 Jan 2013 16:30:03 +0000 (UTC) Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 6 Jan 2013 16:30:03 +0000 Received: from BY2PRD0510MB366.namprd05.prod.outlook.com ([169.254.5.143]) by BY2PRD0510HT003.namprd05.prod.outlook.com ([10.255.84.38]) with mapi id 14.16.0245.002; Sun, 6 Jan 2013 16:30:01 +0000 From: "Duncan, Richard (Jeremy)" To: Hosnieh Rafiee Subject: RE: Call for comments on draft-rafiee-6man-ssas-00.txt Thread-Topic: Call for comments on draft-rafiee-6man-ssas-00.txt Thread-Index: Ac3qBjubrheh5C8XRaicccIyEVKaogBjjdYAAABvBIAAJTkJdQ== Date: Sun, 6 Jan 2013 16:30:01 +0000 Message-ID: References: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> <50E8A9D4.60800@si6networks.com>, <000901cdeb96$32887d80$97997880$@rozanak.com> In-Reply-To: <000901cdeb96$32887d80$97997880$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [::] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: salientfed.com X-Mailman-Approved-At: Sun, 06 Jan 2013 08:41:48 -0800 Cc: 'Fernando Gont' , "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: Sun, 06 Jan 2013 16:30:08 -0000 Dr. Rafiee- In reading your ID, I didn't see a mechanism for ensuring a central certifi= cation authority like in PKI (eg a CA) like used in SeND/CGA. How can host= s trust the signed NDP messages? Or is this ID meant to be another option = to CGA not necessarily a replacement for SeND? 010100110110010101101101011100000110010101110010001000000100011001101001 Jeremy Duncan Senior Director, IPv6 Network Architect Salient Federal Solutions, Inc. (Now including SGIS & Command Information I= nc.) 4000 Legato Road, Suite 600 Fairfax, VA 22033 Google Voice: 540.440.1193 jeremy.duncan@salientfed.com Hosnieh Rafiee wrote: Thanks for your comments. -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com] Sent: Saturday, January 05, 2013 11:32 PM To: Hosnieh Rafiee Cc: ipv6@ietf.org Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt Hosnieh, I've reviewed the I-D till Section 3 (didn't get into 3.1)... but it looks like the I-D got some things wrong.... Please see in-line... > Abstract > > The default method for IPv6 address generation uses two unique > manufacturer IDs that are assigned by the IEEE Standards Association > [1] (section 2.5.1 RFC-4291) [RFC4291]. What are the two IDs assigned by the IEEE? > This means that a node will > always have the same Interface ID (IID) whenever it connects to a new > network. Because the node's IP address does not change, the node is > vulnerable to privacy related attacks. The IP address does change. It's only the IID part that usually doesn't. > To address this issue, there > are currently two mechanisms in use to randomize the IID, > Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy > Extension [RFC4941]. This is incorrect. CGAs are meant to solve a different problem. Privacy Addresses do (partially) mitigate this issue. > The problem with the former approach is the > computational cost involved for the IID generation. No. The problem with CGAs are: * IPRs * Requirement for a PKI with SEND (which is where CGAs are used) * Small ROI (complexity to implement, complexity to deploy, small number of implementations)... all to solve a problem we have lived with in the IPv4 world for years... and unless you solve other problems (e.g., unsecure= d DNS), it doesn't make much sense to bother with SEND. > The problem with > the latter approach is that it lacks security. This document offers a > new algorithm for use in the generation of the IID while, at the same > time, securing the node against some types of attack, such as IP > spoofing. These attacks are prevented with the addition of a > signature to the Neighbor Discovery messages (NDP). If you just sign the NDP messages, you're not mitigating spoofing -- how would a non-local host authenticate the packet, if the signatures are in ND= P messages (which are only local)? > 1. Introduction > > IPv6 addresses consist of two parts; the subnet prefix, which is > the Global routing prefix, subnet ID, Interface ID (in the case of GUAs, of course) > which is the 64 rightmost bits of IPv6 address. The IEEE Standards > Association [1] (section 2.5.1 RFC-4291) [RFC4291] offered a standard > for the generation of the IPv6 Interface IDs (IID). The IEEE does not standardize IPv6. > They are > generated by the concatenation of an Extended Unique Identifier > (EUI-64) with an Organizationally Unique Identifier (OUI), EUI-64 includes the OUI. > both of > which are assigned by the IEEE Registration Authority (IEEE RA). For > example, if a manufacturer's OUI-36 hexadecimal value is > 00-5A-D1-02-3, and the manufacture hexadecimal value for the > extension identifier for a given component is 4-42-61-71, The latter is assigned by the vendor, not by the IEEE. > EUI-64 value generated from these two numbers will be > 00-5A-D1-02-34-42-61-71. There are two mechanisms used to randomize > the IID; CGA [RFC3972] and Privacy Extension [RFC4941]. Please clarify what you mean by "randomize". > 3. Problem Statement > > The drawback to the IEEE Standards Association approach for the > generation of the IID is one of privacy. That's an *IETF* approach, not IEEE's. > The main problem with the privacy extension mechanism, when using the > first approach, as explained in section 3.2.1 RFC-4941 [RFC4941] , > i.e., using stable storage, is the lack of a provision for use of a > security mechanism. Not sure what you mean by "lack of a provision for use of a security mechanism.". > A Privacy extension can prevent attacks related > to privacy issues, We have already gone through this one: Privacy addresses only *partially* mitigate host-tracking attacks. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ietf@rozanak.com Sun Jan 6 09:02:32 2013 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 3E97821F84D9 for ; Sun, 6 Jan 2013 09:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_00=-2.599, TRACKER_ID=2.003] 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 1fA3vXND0GRo for ; Sun, 6 Jan 2013 09:02:31 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id B546721F84D3 for ; Sun, 6 Jan 2013 09:02:30 -0800 (PST) Received: from kopoli (g225033246.adsl.alicedsl.de [92.225.33.246]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M5dE8-1T3EwS1hTk-00xP3E; Sun, 06 Jan 2013 12:02:29 -0500 From: "Hosnieh Rafiee" To: "'Duncan, Richard \(Jeremy\)'" References: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> <50E8A9D4.60800@si6networks.com>, <000901cdeb96$32887d80$97997880$@rozanak.com> In-Reply-To: Subject: RE: Call for comments on draft-rafiee-6man-ssas-00.txt Date: Sun, 6 Jan 2013 18:02:19 +0100 Message-ID: <000501cdec2f$9ac03c00$d040b400$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI7ECCw5lZJtuTcH4KW/U5riPTnyQLGGXo7Ah3jw8wCDZY34pcqqcQA Content-Language: en-us X-Provags-ID: V02:K0:nwMcMvJbr/dt8sw/WjdaF10yQDtQ+CWM7CY6aZiLMWM 5bbaQxeYKJbcsmG9v0Z32mW+w9mgxl9sDBcZuHvIsvTjU2vW0B vXoDK8+q4jKZUwx9A4WN+OC77lREoWzHpBmBxjwuzgj7hDp7Nk J7quQqAByYJHnr//LEciI/frhoy0cSI9zJXzpoS2xPX9VAaW5V jlmR+pGC9XSc2PQnP7bjD8EKTwvrgBMuh4YiD/lAfQygD1IPD1 2iyrEJNHflsdm5qXD9EAsB+F/eV+2V2/hg4phZWK/g5Vfgri84 +sdetbq/HOPkuYU1Kk11joYXyoZ/a3h98ORbb9ATefmYXo+g2I dazSiLC6y0BJbNx9iLfk= 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: Sun, 06 Jan 2013 17:02:32 -0000 Dear Jeremy, Thank you so much for your review and your question. >In reading your ID, I didn't see a mechanism for ensuring a central certification authority like in PKI (eg a CA) like used in SeND/CGA. How can hosts trust the signed NDP messages? Or is this ID >meant to be another option to CGA not necessarily a replacement for SeND? This mechanism will be used as a replacement for CGA because it is faster, but not for SEND. Usually, for a client, it is enough to just validate address ownership. As you know, like CGA, this mechanism will validate address ownership, but uses fewer steps to accomplish this. This means that a node cannot steal another nodes' IP address because address ownership would need to be proven by verifying the signature and also because a part of his address is his public key. But for nodes, it is important to ensure that a node claiming to be a router is really a router and not an attacker (preventing all nodes from claiming to be a router). In this case, as I explained in the security consideration section of the draft, other RFCs explaining how to use certificates and trusted authorities may be used. An example would be RFC 6494. Thank you, Hosnieh -----Original Message----- From: Duncan, Richard (Jeremy) [mailto:jeremy.duncan@salientfed.com] Sent: Sunday, January 06, 2013 5:30 PM To: Hosnieh Rafiee Cc: 'Fernando Gont'; ipv6@ietf.org Subject: RE: Call for comments on draft-rafiee-6man-ssas-00.txt Dr. Rafiee- In reading your ID, I didn't see a mechanism for ensuring a central certification authority like in PKI (eg a CA) like used in SeND/CGA. How can hosts trust the signed NDP messages? Or is this ID meant to be another option to CGA not necessarily a replacement for SeND? 010100110110010101101101011100000110010101110010001000000100011001101001 Jeremy Duncan Senior Director, IPv6 Network Architect Salient Federal Solutions, Inc. (Now including SGIS & Command Information Inc.) 4000 Legato Road, Suite 600 Fairfax, VA 22033 Google Voice: 540.440.1193 jeremy.duncan@salientfed.com Hosnieh Rafiee wrote: Thanks for your comments. -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com] Sent: Saturday, January 05, 2013 11:32 PM To: Hosnieh Rafiee Cc: ipv6@ietf.org Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt Hosnieh, I've reviewed the I-D till Section 3 (didn't get into 3.1)... but it looks like the I-D got some things wrong.... Please see in-line... > Abstract > > The default method for IPv6 address generation uses two unique > manufacturer IDs that are assigned by the IEEE Standards Association > [1] (section 2.5.1 RFC-4291) [RFC4291]. What are the two IDs assigned by the IEEE? > This means that a node will > always have the same Interface ID (IID) whenever it connects to a new > network. Because the node's IP address does not change, the node is > vulnerable to privacy related attacks. The IP address does change. It's only the IID part that usually doesn't. > To address this issue, there > are currently two mechanisms in use to randomize the IID, > Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy > Extension [RFC4941]. This is incorrect. CGAs are meant to solve a different problem. Privacy Addresses do (partially) mitigate this issue. > The problem with the former approach is the > computational cost involved for the IID generation. No. The problem with CGAs are: * IPRs * Requirement for a PKI with SEND (which is where CGAs are used) * Small ROI (complexity to implement, complexity to deploy, small number of implementations)... all to solve a problem we have lived with in the IPv4 world for years... and unless you solve other problems (e.g., unsecured DNS), it doesn't make much sense to bother with SEND. > The problem with > the latter approach is that it lacks security. This document offers a > new algorithm for use in the generation of the IID while, at the same > time, securing the node against some types of attack, such as IP > spoofing. These attacks are prevented with the addition of a > signature to the Neighbor Discovery messages (NDP). If you just sign the NDP messages, you're not mitigating spoofing -- how would a non-local host authenticate the packet, if the signatures are in NDP messages (which are only local)? > 1. Introduction > > IPv6 addresses consist of two parts; the subnet prefix, which is > the Global routing prefix, subnet ID, Interface ID (in the case of GUAs, of course) > which is the 64 rightmost bits of IPv6 address. The IEEE Standards > Association [1] (section 2.5.1 RFC-4291) [RFC4291] offered a standard > for the generation of the IPv6 Interface IDs (IID). The IEEE does not standardize IPv6. > They are > generated by the concatenation of an Extended Unique Identifier > (EUI-64) with an Organizationally Unique Identifier (OUI), EUI-64 includes the OUI. > both of > which are assigned by the IEEE Registration Authority (IEEE RA). For > example, if a manufacturer's OUI-36 hexadecimal value is > 00-5A-D1-02-3, and the manufacture hexadecimal value for the > extension identifier for a given component is 4-42-61-71, The latter is assigned by the vendor, not by the IEEE. > EUI-64 value generated from these two numbers will be > 00-5A-D1-02-34-42-61-71. There are two mechanisms used to randomize > the IID; CGA [RFC3972] and Privacy Extension [RFC4941]. Please clarify what you mean by "randomize". > 3. Problem Statement > > The drawback to the IEEE Standards Association approach for the > generation of the IID is one of privacy. That's an *IETF* approach, not IEEE's. > The main problem with the privacy extension mechanism, when using the > first approach, as explained in section 3.2.1 RFC-4941 [RFC4941] , > i.e., using stable storage, is the lack of a provision for use of a > security mechanism. Not sure what you mean by "lack of a provision for use of a security mechanism.". > A Privacy extension can prevent attacks related > to privacy issues, We have already gone through this one: Privacy addresses only *partially* mitigate host-tracking attacks. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From ietf@rozanak.com Sun Jan 6 12:39:43 2013 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 6772921F84BC for ; Sun, 6 Jan 2013 12:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 3VQ1GSJarH20 for ; Sun, 6 Jan 2013 12:39:42 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6097E21F84BB for ; Sun, 6 Jan 2013 12:39:42 -0800 (PST) Received: from kopoli (g225033246.adsl.alicedsl.de [92.225.33.246]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MDRDR-1TmAep47DR-00GpXe; Sun, 06 Jan 2013 15:39:41 -0500 From: "Hosnieh Rafiee" To: "Al-Sadeh, Ahmad" References: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com>, <000d01cdeab7$f627a340$e276e9c0$@rozanak.com> In-Reply-To: Subject: RE: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt Date: Sun, 6 Jan 2013 21:39:26 +0100 Message-ID: <000601cdec4d$f1bacac0$d5306040$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI7ECCw5lZJtuTcH4KW/U5riPTnyQEkjZ/TAZAWzjGXTM+OMA== Content-Language: en-us X-Provags-ID: V02:K0:dOPKJoF2rWSjRt0bvqEdDpRHdVd+xB0vBvj0sIX8t4o GoVuTPgBSwRcR33yg1yXOdcpRtamezm2EqcJaZSR0E9pwRltlh G/whj4Bca/G8uV5f5dg5WOyVmYFoFg2SJNNLmR9FNwYVDE7dDL Pqd1ay6JZIBFpTbKKiaK/8xnLvJpL/ihtZF0hn2U3RS5s13isQ nIbhy29DLNMQhNMirixwc1dV9OthL4XkPsyyfvgWO++anC59Hh azxnATmEisAKwYK8uWkPuXueMjSwQ5+b9Zvrifg+6gs23dCvt2 M98fYkfFaN04EryPjl4gYMpDrDg9u9ea12K96nsnxeOGeu9S8P 8xS9WKMe9PGw04aFZBZ8= 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: Sun, 06 Jan 2013 20:39:43 -0000 Dear Ahmad, Thank you so much for your comments. >SEND already offers what you are looking for. It has the Timestamp and the Signature options which are attached to the DNP messages. As I explained in my last email to Jeremy, It just updates SEND and does not replace it. It updates SEND because of the signature contents. I also explained in the draft that we used the same timestamp as is used in SEND. >I agree with the claim that CGA is compute intensive, but one can use Sec=0 or 1. In this case the computation of the CGA (SEND) would be equivalent to the complexity of your approach. I compared it with both sec value 0 and sec value 1. I did not consider sec value higher because it is not really feasible in practice that someone wait for 2 or 3 hours to days to generate an address. CGA for 1 it is 600 times more. For zero it is about 10 to 20 times more. The computation of this algorithm is faster than that for CGA and also the verification process is much faster. In the verification process you do not need to do all the CGA generation processing in reverse in order to verify it. With CGA you also have to include the verification time for the signature even though we say we use a sec value of 0 this is not considered in the verification process. For CGA you also need to include an extra 17 bytes of options (modifier and collision count) in the packet, but with SSAS the packet size would be less. Thank you, Hosnieh -----Original Message----- From: Al-Sadeh, Ahmad [mailto:Ahmad.AlSadeh@hpi.uni-potsdam.de] Sent: Sunday, January 06, 2013 9:10 PM To: Hosnieh Rafiee; cga-ext@ietf.org Cc: ipv6@ietf.org Subject: RE: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt Hosnieh, I have read your draft. And I have the following comments. SEND already offers what you are looking for. It has the Timestamp and the Signature options which are attached to the DNP messages. So, the new benefits of your approach are not clear to me. I agree with the claim that CGA is compute intensive, but one can use Sec=0 or 1. In this case the computation of the CGA (SEND) would be equivalent to the complexity of your approach. Therefore the enhancements that are proposed to protect the user privacy by setting a lifetime for the generated address (e.g. 2 days) or generating the key pairs by CGA code can be directly applied to the CGA and SEND implementation without significant change to proposed standard. In Section 5, ". it provides proof of address ownership at a speed that is about 600 times faster than that of the CGA algorithm." For which Sec value this comparison was done? Regards, Ahmad AlSadeh ________________________________ From: cga-ext-bounces@ietf.org [cga-ext-bounces@ietf.org] On Behalf Of Hosnieh Rafiee [ietf@rozanak.com] Sent: 04 January 2013 21:13 To: cga-ext@ietf.org Subject: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt Dear All, This draft addresses the following problem: Unfortunately the existing drafts do not consider the integration of security and privacy for the generation of the Interface ID (IID). This draft tries to offer a solution to this problem while at the same time considering the generation and verification times and complexity of the existing algorithms. Please take a look. Comments are greatly appreciated. Thank you, Hosnieh Filename: draft-rafiee-6man-ssas Revision: 00 Title: A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration (SSAS) Creation date: 2013-01-02 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-00.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas Htmlized: http://tools.ietf.org/html/draft-rafiee-6man-ssas-00 Abstract: The default method for IPv6 address generation uses two unique manufacturer IDs that are assigned by the IEEE Standards Association [1] (section 2.5.1 RFC-4291) [RFC4291]. This means that a node will always have the same Interface ID (IID) whenever it connects to a new network. Because the node's IP address does not change, the node is vulnerable to privacy related attacks. To address this issue, there are currently two mechanisms in use to randomize the IID, Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy Extension [RFC4941]. The problem with the former approach is the computational cost involved for the IID generation. The problem with the latter approach is that it lacks security. This document offers a new algorithm for use in the generation of the IID while, at the same time, securing the node against some types of attack, such as IP spoofing. These attacks are prevented with the addition of a signature to the Neighbor Discovery messages (NDP). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From v6ops@globis.net Mon Jan 7 03:50:41 2013 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 51E6321F8432 for ; Mon, 7 Jan 2013 03:50:39 -0800 (PST) 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 TdNZYBDdkoJy for ; Mon, 7 Jan 2013 03:50:38 -0800 (PST) Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8640A21F874C for ; Mon, 7 Jan 2013 03:50:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BC2F38700DD; Mon, 7 Jan 2013 12:40:20 +0100 (CET) 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 GnR-UtmqfqzZ; Mon, 7 Jan 2013 12:39:51 +0100 (CET) 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 19A79870043; Mon, 7 Jan 2013 12:39:51 +0100 (CET) Message-ID: <50EAB400.2010502@globis.net> Date: Mon, 07 Jan 2013 12:39:44 +0100 From: Ray Hunter User-Agent: Postbox 3.0.6 (Macintosh/20121022) MIME-Version: 1.0 To: Hosnieh Rafiee Subject: Re: RE: Call for comments on draft-rafiee-6man-ssas-00.txt References: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> <50E8A9D4.60800@si6networks.com>, <000901cdeb96$32887d80$97997880$@rozanak.com> <000501cdec2f$9ac03c00$d040b400$@rozanak.com> In-Reply-To: <000501cdec2f$9ac03c00$d040b400$@rozanak.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'Duncan, Richard \(Jeremy\)'" , 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, 07 Jan 2013 11:50:41 -0000 inline. Hosnieh Rafiee wrote: > Dear Jeremy, > Thank you so much for your review and your question. > >> In reading your ID, I didn't see a mechanism for ensuring a central > certification authority like in PKI (eg a CA) like used in SeND/CGA. How > can hosts trust the signed NDP messages? Or is this ID >meant to be another > option to CGA not necessarily a replacement for SeND? > > This mechanism will be used as a replacement for CGA because it is faster, > but not for SEND. Usually, for a client, it is enough to just validate > address ownership. As you know, like CGA, this mechanism will validate > address ownership, but uses fewer steps to accomplish this. This means that > a node cannot steal another nodes' IP address because address ownership > would need to be proven by verifying the signature and also because a part > of his address is his public key. A rather exaggerated claim IHMO. You may have tied a L2 address to an IPv6 address via NDP, but L2 addresses are generally not tightly coupled to nodes. An attacker could let NDP complete normally (including any signatures/authorizations you like) and then target/corrupt/overload the L2 MAC forwarding table so they can insert (unsigned) spoof traffic packets and receive any replies in promiscuous mode. You'd probably need to additionally deploy some form of NDP snooping and first hop security on your L2 switches to prevent that class of attack on wired networks. On wireless networks you don't even have that option. > But for nodes, it is important to ensure > that a node claiming to be a router is really a router and not an attacker > (preventing all nodes from claiming to be a router). In this case, as I > explained in the security consideration section of the draft, other RFCs > explaining how to use certificates and trusted authorities may be used. An > example would be RFC 6494. > > Thank you, > Hosnieh > > > -----Original Message----- > From: Duncan, Richard (Jeremy) [mailto:jeremy.duncan@salientfed.com] > Sent: Sunday, January 06, 2013 5:30 PM > To: Hosnieh Rafiee > Cc: 'Fernando Gont'; ipv6@ietf.org > Subject: RE: Call for comments on draft-rafiee-6man-ssas-00.txt > > Dr. Rafiee- > > In reading your ID, I didn't see a mechanism for ensuring a central > certification authority like in PKI (eg a CA) like used in SeND/CGA. How > can hosts trust the signed NDP messages? Or is this ID meant to be another > option to CGA not necessarily a replacement for SeND? > > > > 010100110110010101101101011100000110010101110010001000000100011001101001 > > Jeremy Duncan > Senior Director, IPv6 Network Architect > Salient Federal Solutions, Inc. (Now including SGIS & Command Information > Inc.) > 4000 Legato Road, Suite 600 > Fairfax, VA 22033 > Google Voice: 540.440.1193 > jeremy.duncan@salientfed.com > > Hosnieh Rafiee wrote: > > > Thanks for your comments. > > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com] > Sent: Saturday, January 05, 2013 11:32 PM > To: Hosnieh Rafiee > Cc: ipv6@ietf.org > Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt > > Hosnieh, > > I've reviewed the I-D till Section 3 (didn't get into 3.1)... but it looks > like the I-D got some things wrong.... > > Please see in-line... > > >> Abstract >> >> The default method for IPv6 address generation uses two unique >> manufacturer IDs that are assigned by the IEEE Standards Association >> [1] (section 2.5.1 RFC-4291) [RFC4291]. > > What are the two IDs assigned by the IEEE? > > > >> This means that a node will >> always have the same Interface ID (IID) whenever it connects to a new >> network. Because the node's IP address does not change, the node is >> vulnerable to privacy related attacks. > > The IP address does change. It's only the IID part that usually doesn't. > > > >> To address this issue, there >> are currently two mechanisms in use to randomize the IID, >> Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy >> Extension [RFC4941]. > > This is incorrect. CGAs are meant to solve a different problem. Privacy > Addresses do (partially) mitigate this issue. > > > >> The problem with the former approach is the >> computational cost involved for the IID generation. > > No. The problem with CGAs are: > > * IPRs > > * Requirement for a PKI with SEND (which is where CGAs are used) > > * Small ROI (complexity to implement, complexity to deploy, small number of > implementations)... all to solve a problem we have lived with in the > IPv4 world for years... and unless you solve other problems (e.g., unsecured > DNS), it doesn't make much sense to bother with SEND. > > > >> The problem with >> the latter approach is that it lacks security. This document offers a >> new algorithm for use in the generation of the IID while, at the same >> time, securing the node against some types of attack, such as IP >> spoofing. These attacks are prevented with the addition of a >> signature to the Neighbor Discovery messages (NDP). > > If you just sign the NDP messages, you're not mitigating spoofing -- how > would a non-local host authenticate the packet, if the signatures are in NDP > messages (which are only local)? > > >> 1. Introduction >> >> IPv6 addresses consist of two parts; the subnet prefix, which is >> the > > Global routing prefix, subnet ID, Interface ID > > (in the case of GUAs, of course) > > > >> which is the 64 rightmost bits of IPv6 address. The IEEE Standards >> Association [1] (section 2.5.1 RFC-4291) [RFC4291] offered a standard >> for the generation of the IPv6 Interface IDs (IID). > > The IEEE does not standardize IPv6. > > >> They are >> generated by the concatenation of an Extended Unique Identifier >> (EUI-64) with an Organizationally Unique Identifier (OUI), > > EUI-64 includes the OUI. > > >> both of >> which are assigned by the IEEE Registration Authority (IEEE RA). For >> example, if a manufacturer's OUI-36 hexadecimal value is >> 00-5A-D1-02-3, and the manufacture hexadecimal value for the >> extension identifier for a given component is 4-42-61-71, > > The latter is assigned by the vendor, not by the IEEE. > > > >> EUI-64 value generated from these two numbers will be >> 00-5A-D1-02-34-42-61-71. There are two mechanisms used to randomize >> the IID; CGA [RFC3972] and Privacy Extension [RFC4941]. > > Please clarify what you mean by "randomize". > > >> 3. Problem Statement >> >> The drawback to the IEEE Standards Association approach for the >> generation of the IID is one of privacy. > > That's an *IETF* approach, not IEEE's. > > > >> The main problem with the privacy extension mechanism, when using the >> first approach, as explained in section 3.2.1 RFC-4941 [RFC4941] , >> i.e., using stable storage, is the lack of a provision for use of a >> security mechanism. > > Not sure what you mean by "lack of a provision for use of a security > mechanism.". > > > >> A Privacy extension can prevent attacks related >> to privacy issues, > > We have already gone through this one: Privacy addresses only > *partially* mitigate host-tracking attacks. > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > From Ahmad.AlSadeh@hpi.uni-potsdam.de Sun Jan 6 12:09:29 2013 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 CCB4E21F859C; Sun, 6 Jan 2013 12:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 vmdslolbzLEW; Sun, 6 Jan 2013 12:09:29 -0800 (PST) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id EBE5B21F859B; Sun, 6 Jan 2013 12:09:28 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id 0EA5CD2C8E; Sun, 6 Jan 2013 21:09:26 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Sun, 6 Jan 2013 21:09:25 +0100 From: "Al-Sadeh, Ahmad" To: Hosnieh Rafiee , "cga-ext@ietf.org" Content-Class: urn:content-classes:message Date: Sun, 6 Jan 2013 21:09:53 +0100 Subject: RE: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt Thread-Topic: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt Thread-Index: AQI7ECCw5lZJtuTcH4KW/U5riPTnyZdfT5EQgAMhrjeAAAIU+A== Message-ID: References: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com>, <000d01cdeab7$f627a340$e276e9c0$@rozanak.com> In-Reply-To: <000d01cdeab7$f627a340$e276e9c0$@rozanak.com> Accept-Language: en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-GB x-mimectl: Produced By Microsoft Exchange V8.3.105.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 07 Jan 2013 08:20:39 -0800 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: Sun, 06 Jan 2013 20:09:30 -0000 Hosnieh, I have read your draft. And I have the following comments. SEND already offers what you are looking for. It has the Timestamp and the = Signature options which are attached to the DNP messages. So, the new benef= its of your approach are not clear to me. I agree with the claim that CGA is compute intensive, but one can use Sec= =3D0 or 1. In this case the computation of the CGA (SEND) would be equivale= nt to the complexity of your approach. Therefore the enhancements that are= proposed to protect the user privacy by setting a lifetime for the generat= ed address (e.g. 2 days) or generating the key pairs by CGA code can be dir= ectly applied to the CGA and SEND implementation without significant change= to proposed standard. In Section 5, =93=85 it provides proof of address ownership at a speed that= is about 600 times faster than that of the CGA algorithm.=94 For which Sec value this comparison was done? Regards, Ahmad AlSadeh ________________________________ From: cga-ext-bounces@ietf.org [cga-ext-bounces@ietf.org] On Behalf Of Hosn= ieh Rafiee [ietf@rozanak.com] Sent: 04 January 2013 21:13 To: cga-ext@ietf.org Subject: [CGA-EXT] Call for comments on draft-rafiee-6man-ssas-00.txt Dear All, This draft addresses the following problem: Unfortunately the existing drafts do not consider the integration of security and privacy for the generation of the Interface ID (IID). This draft tries to offer a solution to this problem while at the same time considering the generation and verification times and complexity of the existing algorithms. Please take a look. Comments are greatly appreciated. Thank you, Hosnieh Filename: draft-rafiee-6man-ssas Revision: 00 Title: A Simple Secure Addressing Generation Scheme for IPv6 AutoConfiguration (SSAS) Creation date: 2013-01-02 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-00.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas Htmlized: http://tools.ietf.org/html/draft-rafiee-6man-ssas-00 Abstract: The default method for IPv6 address generation uses two unique manufacturer IDs that are assigned by the IEEE Standards Association [1] (section 2.5.1 RFC-4291) [RFC4291]. This means that a node will always have the same Interface ID (IID) whenever it connects to a new network. Because the node's IP address does not change, the node is vulnerable to privacy related attacks. To address this issue, there are currently two mechanisms in use to randomize the IID, Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy Extension [RFC4941]. The problem with the former approach is the computational cost involved for the IID generation. The problem with the latter approach is that it lacks security. This document offers a new algorithm for use in the generation of the IID while, at the same time, securing the node against some types of attack, such as IP spoofing. These attacks are prevented with the addition of a signature to the Neighbor Discovery messages (NDP). -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From ietf@rozanak.com Mon Jan 7 08:24:41 2013 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 2BA8511E809C for ; Mon, 7 Jan 2013 08:24:41 -0800 (PST) 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 zdQSqOZQZjSO for ; Mon, 7 Jan 2013 08:24:39 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5073E11E80AD for ; Mon, 7 Jan 2013 08:24:39 -0800 (PST) Received: from oxuslxltgw05.lxa.perfora.net (oxuslxltgw05.lxa.perfora.net [172.19.206.7]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MOxrj-1TxS182OJj-006F4w; Mon, 07 Jan 2013 11:23:53 -0500 Date: Mon, 7 Jan 2013 11:23:53 -0500 (EST) From: Hosnieh To: Ray Hunter Message-ID: <2097659677.720628.1357575833618.JavaMail.open-xchange@email.1and1.com> In-Reply-To: <50EAB400.2010502@globis.net> References: <000001cdea08$1a37e0c0$4ea7a240$@rozanak.com> <50E8A9D4.60800@si6networks.com>, <000901cdeb96$32887d80$97997880$@rozanak.com> <000501cdec2f$9ac03c00$d040b400$@rozanak.com> <50EAB400.2010502@globis.net> Subject: Re: RE: Call for comments on draft-rafiee-6man-ssas-00.txt MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_720627_1614284530.1357575833563" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v6.20.7-Rev4 X-Provags-ID: V02:K0:4Ll4LedCYeqNidNd6b7H1gDRw1NEjyvDp6Ud0pXuTlV aYxpy49PEkH5a+dlm1OQPwqSlmNA1+P3uUAn8vpMDQ0wLoQ1Wi rAQuZl8yHIxyebO7oxmx4cOEUiQ+JnohP4rRRuPMpEe2XiEpLq vy26I0xMTqC8KDxAGuFhGtojtmVDrcShoa3N9FmTWqwA5tcVO6 Mk2Sot95+Y6Ft8cy4SIb2Ztl88cT+uTEonkX+wza2jmnzZIwLq KwIqihd67YW7AfsT3ZB7BB77NAK2ysJ3r9rVGPOTuCbhgk2WJl oMH0Vglh3LJPt+kUHGtubnsBDf78SCTd1LhOOENxJuHRdBnkRw 500DG+M65Z8JX790/+2viAp/tvceNrsSua8P8MkaMbidvAfCQz s7h5473aX3EfgN6MAJ2afKrdffMIiglnpWCpbSCHs8f3JyO/Fh Bqu7y Cc: jeremy.duncan@salientfed.com, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Hosnieh List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:24:41 -0000 ------=_Part_720627_1614284530.1357575833563 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear Ray, Thank you again. >A rather exaggerated claim IHMO. You may have tied a L2 address to an >IPv6 address via NDP, but L2 addresses are generally not tightly coupled to >nodes. An attacker could let NDP complete normally (including any >signatures/authorizations you like) and then >target/corrupt/overload the >L2 MAC forwarding table so they can insert (unsigned) spoof traffic packets and >receive any replies in promiscuous mode. You'd probably need to additionally >deploy some form of NDP snooping and first >hop security on your L2 switches to >prevent that class of attack on wired networks. On wireless networks you don't >even have that option. A further enhancement might be to add a MAC address to the signature. But if the attack is in layer 2 rather than IP layer, I believe that this attack will also occur using CGA because the purpose is the same as what we proposed here, but with longer processing time. As you said, there is a need for monitoring the system for snooping NDP. By the way, about 10 minutes for timestamp which was a topic of discussion in our last email. The replay attack is still not possible because of the other steps present in the verification process. An example of such a step is the checking of the public key with his own public key. Thank you, Hosnieh On January 7, 2013 at 6:39 AM Ray Hunter wrote: > inline. > > Hosnieh Rafiee wrote: > > Dear Jeremy, > > Thank you so much for your review and your question. > > > >> In reading your ID, I didn't see a mechanism for ensuring a central > > certification authority like in PKI (eg a CA) like used in SeND/CGA. How > > can hosts trust the signed NDP messages? Or is this ID >meant to be another > > option to CGA not necessarily a replacement for SeND? > > > > This mechanism will be used as a replacement for CGA because it is faster, > > but not for SEND. Usually, for a client, it is enough to just validate > > address ownership. As you know, like CGA, this mechanism will validate > > address ownership, but uses fewer steps to accomplish this. This means that > > a node cannot steal another nodes' IP address because address ownership > > would need to be proven by verifying the signature and also because a part > > of his address is his public key. > A rather exaggerated claim IHMO. You may have tied a L2 address to an > IPv6 address via NDP, but L2 addresses are generally not tightly coupled > to nodes. An attacker could let NDP complete normally (including any > signatures/authorizations you like) and then target/corrupt/overload the > L2 MAC forwarding table so they can insert (unsigned) spoof traffic > packets and receive any replies in promiscuous mode. You'd probably > need to additionally deploy some form of NDP snooping and first hop > security on your L2 switches to prevent that class of attack on wired > networks. On wireless networks you don't even have that option. > > > But for nodes, it is important to ensure > > that a node claiming to be a router is really a router and not an attacker > > (preventing all nodes from claiming to be a router). In this case, as I > > explained in the security consideration section of the draft, other RFCs > > explaining how to use certificates and trusted authorities may be used. An > > example would be RFC 6494. > > > > Thank you, > > Hosnieh > > > > > > -----Original Message----- > > From: Duncan, Richard (Jeremy) [mailto:jeremy.duncan@salientfed.com] > > Sent: Sunday, January 06, 2013 5:30 PM > > To: Hosnieh Rafiee > > Cc: 'Fernando Gont'; ipv6@ietf.org > > Subject: RE: Call for comments on draft-rafiee-6man-ssas-00.txt > > > > Dr. Rafiee- > > > > In reading your ID, I didn't see a mechanism for ensuring a central > > certification authority like in PKI (eg a CA) like used in SeND/CGA. How > > can hosts trust the signed NDP messages? Or is this ID meant to be another > > option to CGA not necessarily a replacement for SeND? > > > > > > > > 010100110110010101101101011100000110010101110010001000000100011001101001 > > > > Jeremy Duncan > > Senior Director, IPv6 Network Architect > > Salient Federal Solutions, Inc. (Now including SGIS & Command Information > > Inc.) > > 4000 Legato Road, Suite 600 > > Fairfax, VA 22033 > > Google Voice: 540.440.1193 > > jeremy.duncan@salientfed.com > > > > Hosnieh Rafiee wrote: > > > > > > Thanks for your comments. > > > > -----Original Message----- > > From: Fernando Gont [mailto:fgont@si6networks.com] > > Sent: Saturday, January 05, 2013 11:32 PM > > To: Hosnieh Rafiee > > Cc: ipv6@ietf.org > > Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt > > > > Hosnieh, > > > > I've reviewed the I-D till Section 3 (didn't get into 3.1)... but it looks > > like the I-D got some things wrong.... > > > > Please see in-line... > > > > > >> Abstract > >> > >> The default method for IPv6 address generation uses two unique > >> manufacturer IDs that are assigned by the IEEE Standards Association > >> [1] (section 2.5.1 RFC-4291) [RFC4291]. > > > > What are the two IDs assigned by the IEEE? > > > > > > > >> This means that a node will > >> always have the same Interface ID (IID) whenever it connects to a new > >> network. Because the node's IP address does not change, the node is > >> vulnerable to privacy related attacks. > > > > The IP address does change. It's only the IID part that usually doesn't. > > > > > > > >> To address this issue, there > >> are currently two mechanisms in use to randomize the IID, > >> Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy > >> Extension [RFC4941]. > > > > This is incorrect. CGAs are meant to solve a different problem. Privacy > > Addresses do (partially) mitigate this issue. > > > > > > > >> The problem with the former approach is the > >> computational cost involved for the IID generation. > > > > No. The problem with CGAs are: > > > > * IPRs > > > > * Requirement for a PKI with SEND (which is where CGAs are used) > > > > * Small ROI (complexity to implement, complexity to deploy, small number of > > implementations)... all to solve a problem we have lived with in the > > IPv4 world for years... and unless you solve other problems (e.g., unsecured > > DNS), it doesn't make much sense to bother with SEND. > > > > > > > >> The problem with > >> the latter approach is that it lacks security. This document offers a > >> new algorithm for use in the generation of the IID while, at the same > >> time, securing the node against some types of attack, such as IP > >> spoofing. These attacks are prevented with the addition of a > >> signature to the Neighbor Discovery messages (NDP). > > > > If you just sign the NDP messages, you're not mitigating spoofing -- how > > would a non-local host authenticate the packet, if the signatures are in NDP > > messages (which are only local)? > > > > > >> 1. Introduction > >> > >> IPv6 addresses consist of two parts; the subnet prefix, which is > >> the > > > > Global routing prefix, subnet ID, Interface ID > > > > (in the case of GUAs, of course) > > > > > > > >> which is the 64 rightmost bits of IPv6 address. The IEEE Standards > >> Association [1] (section 2.5.1 RFC-4291) [RFC4291] offered a standard > >> for the generation of the IPv6 Interface IDs (IID). > > > > The IEEE does not standardize IPv6. > > > > > >> They are > >> generated by the concatenation of an Extended Unique Identifier > >> (EUI-64) with an Organizationally Unique Identifier (OUI), > > > > EUI-64 includes the OUI. > > > > > >> both of > >> which are assigned by the IEEE Registration Authority (IEEE RA). For > >> example, if a manufacturer's OUI-36 hexadecimal value is > >> 00-5A-D1-02-3, and the manufacture hexadecimal value for the > >> extension identifier for a given component is 4-42-61-71, > > > > The latter is assigned by the vendor, not by the IEEE. > > > > > > > >> EUI-64 value generated from these two numbers will be > >> 00-5A-D1-02-34-42-61-71. There are two mechanisms used to randomize > >> the IID; CGA [RFC3972] and Privacy Extension [RFC4941]. > > > > Please clarify what you mean by "randomize". > > > > > >> 3. Problem Statement > >> > >> The drawback to the IEEE Standards Association approach for the > >> generation of the IID is one of privacy. > > > > That's an *IETF* approach, not IEEE's. > > > > > > > >> The main problem with the privacy extension mechanism, when using the > >> first approach, as explained in section 3.2.1 RFC-4941 [RFC4941] , > >> i.e., using stable storage, is the lack of a provision for use of a > >> security mechanism. > > > > Not sure what you mean by "lack of a provision for use of a security > > mechanism.". > > > > > > > >> A Privacy extension can prevent attacks related > >> to privacy issues, > > > > We have already gone through this one: Privacy addresses only > > *partially* mitigate host-tracking attacks. > > > > Thanks, > > -- > > Fernando Gont > > SI6 Networks > > e-mail: fgont@si6networks.com > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > > > ------=_Part_720627_1614284530.1357575833563 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Dear Ray,

 

Thank you again.

 

>A rather exaggerated claim IHMO. You may have tied a L2 address to an

>IPv6 address via NDP, but L2 addresses are generally not tightly coupled to nodes. An attacker could let NDP complete normally (including any signatures/authorizations you like) and then >target/corrupt/overload the

>L2 MAC forwarding table so they can insert (unsigned) spoof traffic packets and receive any replies in promiscuous mode.  You'd probably need to additionally deploy some form of NDP snooping and first >hop security on your L2 switches to prevent that class of attack on wired networks. On wireless networks you don't even have that option.

 

A further enhancement might be to add a MAC address to the signature. But if the attack is in layer 2 rather than IP layer, I believe that this attack will also occur using CGA because the purpose is the same as what we proposed here, but with longer processing time. As you said, there is a need for monitoring the system for snooping NDP.

 

By the way, about 10 minutes for timestamp which was a topic of discussion in our last email. The replay attack is still not possible because of the other steps present in the verification process. An example of such a step is the checking of the public key with his own public key.

 

Thank you,

Hosnieh


On January 7, 2013 at 6:39 AM Ray Hunter <v6ops@globis.net> wrote:
> inline.
>
> Hosnieh Rafiee wrote:
> > Dear Jeremy,
> > Thank you so much for your review and your question.
> >
> >> In reading your ID, I didn't see a mechanism for ensuring a central
> > certification authority like in PKI (eg a CA) like used in SeND/CGA. How
> > can hosts trust the signed NDP messages? Or is this ID >meant to be another
> > option to CGA not necessarily a replacement for SeND?
> >
> > This mechanism will be used as a replacement for CGA because it is faster,
> > but not for SEND. Usually, for a client, it is enough to just validate
> > address ownership. As you know, like CGA, this mechanism will validate
> > address ownership, but uses fewer steps to accomplish this. This means that
> > a node cannot steal another nodes' IP address because address ownership
> > would need to be proven by verifying the signature and also because a part
> > of his address is his public key.
> A rather exaggerated claim IHMO. You may have tied a L2 address to an
> IPv6 address via NDP, but L2 addresses are generally not tightly coupled
> to nodes. An attacker could let NDP complete normally (including any
> signatures/authorizations you like) and then target/corrupt/overload the
> L2 MAC forwarding table so they can insert (unsigned) spoof traffic
> packets and receive any replies in promiscuous mode. You'd probably
> need to additionally deploy some form of NDP snooping and first hop
> security on your L2 switches to prevent that class of attack on wired
> networks. On wireless networks you don't even have that option.
>
> > But for nodes, it is important to ensure
> > that a node claiming to be a router is really a router and not an attacker
> > (preventing all nodes from claiming to be a router). In this case, as I
> > explained in the security consideration section of the draft, other RFCs
> > explaining how to use certificates and trusted authorities may be used. An
> > example would be RFC 6494.
> >
> > Thank you,
> > Hosnieh
> >
> >
> > -----Original Message-----
> > From: Duncan, Richard (Jeremy) [mailto:jeremy.duncan@salientfed.com]
> > Sent: Sunday, January 06, 2013 5:30 PM
> > To: Hosnieh Rafiee
> > Cc: 'Fernando Gont'; ipv6@ietf.org
> > Subject: RE: Call for comments on draft-rafiee-6man-ssas-00.txt
> >
> > Dr. Rafiee-
> >
> > In reading your ID, I didn't see a mechanism for ensuring a central
> > certification authority like in PKI (eg a CA) like used in SeND/CGA. How
> > can hosts trust the signed NDP messages? Or is this ID meant to be another
> > option to CGA not necessarily a replacement for SeND?
> >
> >
> >
> > 010100110110010101101101011100000110010101110010001000000100011001101001
> >
> > Jeremy Duncan
> > Senior Director, IPv6 Network Architect
> > Salient Federal Solutions, Inc. (Now including SGIS & Command Information
> > Inc.)
> > 4000 Legato Road, Suite 600
> > Fairfax, VA 22033
> > Google Voice: 540.440.1193
> > jeremy.duncan@salientfed.com
> >
> > Hosnieh Rafiee <ietf@rozanak.com> wrote:
> >
> >
> > Thanks for your comments.
> >
> > -----Original Message-----
> > From: Fernando Gont [mailto:fgont@si6networks.com]
> > Sent: Saturday, January 05, 2013 11:32 PM
> > To: Hosnieh Rafiee
> > Cc: ipv6@ietf.org
> > Subject: Re: Call for comments on draft-rafiee-6man-ssas-00.txt
> >
> > Hosnieh,
> >
> > I've reviewed the I-D till Section 3 (didn't get into 3.1)... but it looks
> > like the I-D got some things wrong....
> >
> > Please see in-line...
> >
> >
> >> Abstract
> >>
> >> The default method for IPv6 address generation uses two unique
> >> manufacturer IDs that are assigned by the IEEE Standards Association
> >> [1] (section 2.5.1 RFC-4291) [RFC4291].
> >
> > What are the two IDs assigned by the IEEE?
> >
> >
> >
> >> This means that a node will
> >> always have the same Interface ID (IID) whenever it connects to a new
> >> network. Because the node's IP address does not change, the node is
> >> vulnerable to privacy related attacks.
> >
> > The IP address does change. It's only the IID part that usually doesn't.
> >
> >
> >
> >> To address this issue, there
> >> are currently two mechanisms in use to randomize the IID,
> >> Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy
> >> Extension [RFC4941].
> >
> > This is incorrect. CGAs are meant to solve a different problem. Privacy
> > Addresses do (partially) mitigate this issue.
> >
> >
> >
> >> The problem with the former approach is the
> >> computational cost involved for the IID generation.
> >
> > No. The problem with CGAs are:
> >
> > * IPRs
> >
> > * Requirement for a PKI with SEND (which is where CGAs are used)
> >
> > * Small ROI (complexity to implement, complexity to deploy, small number of
> > implementations)... all to solve a problem we have lived with in the
> > IPv4 world for years... and unless you solve other problems (e.g., unsecured
> > DNS), it doesn't make much sense to bother with SEND.
> >
> >
> >
> >> The problem with
> >> the latter approach is that it lacks security. This document offers a
> >> new algorithm for use in the generation of the IID while, at the same
> >> time, securing the node against some types of attack, such as IP
> >> spoofing. These attacks are prevented with the addition of a
> >> signature to the Neighbor Discovery messages (NDP).
> >
> > If you just sign the NDP messages, you're not mitigating spoofing -- how
> > would a non-local host authenticate the packet, if the signatures are in NDP
> > messages (which are only local)?
> >
> >
> >> 1. Introduction
> >>
> >> IPv6 addresses consist of two parts; the subnet prefix, which is
> >> the
> >
> > Global routing prefix, subnet ID, Interface ID
> >
> > (in the case of GUAs, of course)
> >
> >
> >
> >> which is the 64 rightmost bits of IPv6 address. The IEEE Standards
> >> Association [1] (section 2.5.1 RFC-4291) [RFC4291] offered a standard
> >> for the generation of the IPv6 Interface IDs (IID).
> >
> > The IEEE does not standardize IPv6.
> >
> >
> >> They are
> >> generated by the concatenation of an Extended Unique Identifier
> >> (EUI-64) with an Organizationally Unique Identifier (OUI),
> >
> > EUI-64 includes the OUI.
> >
> >
> >> both of
> >> which are assigned by the IEEE Registration Authority (IEEE RA). For
> >> example, if a manufacturer's OUI-36 hexadecimal value is
> >> 00-5A-D1-02-3, and the manufacture hexadecimal value for the
> >> extension identifier for a given component is 4-42-61-71,
> >
> > The latter is assigned by the vendor, not by the IEEE.
> >
> >
> >
> >> EUI-64 value generated from these two numbers will be
> >> 00-5A-D1-02-34-42-61-71. There are two mechanisms used to randomize
> >> the IID; CGA [RFC3972] and Privacy Extension [RFC4941].
> >
> > Please clarify what you mean by "randomize".
> >
> >
> >> 3. Problem Statement
> >>
> >> The drawback to the IEEE Standards Association approach for the
> >> generation of the IID is one of privacy.
> >
> > That's an *IETF* approach, not IEEE's.
> >
> >
> >
> >> The main problem with the privacy extension mechanism, when using the
> >> first approach, as explained in section 3.2.1 RFC-4941 [RFC4941] ,
> >> i.e., using stable storage, is the lack of a provision for use of a
> >> security mechanism.
> >
> > Not sure what you mean by "lack of a provision for use of a security
> > mechanism.".
> >
> >
> >
> >> A Privacy extension can prevent attacks related
> >> to privacy issues,
> >
> > We have already gone through this one: Privacy addresses only
> > *partially* mitigate host-tracking attacks.
> >
> > Thanks,
> > --
> > Fernando Gont
> > SI6 Networks
> > e-mail: fgont@si6networks.com
> > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> >
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> >
> >
------=_Part_720627_1614284530.1357575833563-- From iesg-secretary@ietf.org Mon Jan 7 11:52:15 2013 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 4BB7421F8A41; Mon, 7 Jan 2013 11:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.344 X-Spam-Level: X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 AMH3jy77UScF; Mon, 7 Jan 2013 11:52:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D6E21F88C4; Mon, 7 Jan 2013 11:52:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers' to Proposed Standard (draft-ietf-6man-uri-zoneid-06.txt) X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130107195214.21351.54883.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2013 11:52:14 -0800 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: Mon, 07 Jan 2013 19:52:15 -0000 The IESG has approved the following document: - 'Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers' (draft-ietf-6man-uri-zoneid-06.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-uri-zoneid/ Technical Summary: 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. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? As outlined in Appendix A of the document, the working group considered many alternatives, and the document went through several iterations as a result of consensus evolving. Of particular interest may be that creating a new separator ("-") that would not conflict with URI escaping was considered and rejected. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Dave Thaler from Microsoft and Stuart Chesire from Apple, made significant reviews and jointly proposed text that would later reach consensus. Personnel: Ole Troan is the Document Shepherd. Brian Haberman is the Responsible Area Director. From fgont@si6networks.com Tue Jan 8 23:05:00 2013 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 3B81321F872C for ; Tue, 8 Jan 2013 23:05:00 -0800 (PST) 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 lsrJVF45CcFF for ; Tue, 8 Jan 2013 23:04:59 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 13F0821F867B for ; Tue, 8 Jan 2013 23:04:58 -0800 (PST) Received: from [186.134.12.154] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TspiA-00067P-Pc; Wed, 09 Jan 2013 08:04:31 +0100 Message-ID: <50ED1678.5010608@si6networks.com> Date: Wed, 09 Jan 2013 04:04:24 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ray Hunter Subject: Re: Last Call: (Processing of IPv6 "atomic" fragments) to Proposed Standard References: <20130102170308.23202.41467.idtracker@ietfa.amsl.com> <50E7FF41.50100@globis.net> <50E8AF5D.4060101@si6networks.com> <50E92A29.8030602@globis.net> In-Reply-To: <50E92A29.8030602@globis.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 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, 09 Jan 2013 07:05:00 -0000 Hi, Ray, >>> /Many implementations fail to perform validation checks on the received >>> ICMPv6 error messages, as recommended in Section 5.2 of [RFC4443] and >>> [RFC5927]./ >>> >>> Although RFC4443 is a standard track document, none of the language in >>> Section 5.2 contains RFC2119 keywords. >>> RFC5927 is informational. >>> >>> You may consider this a separate but related issue to atomic fragments, >>> but does validation checking of ICMPv6 messages need to be addressed >>> further in your current ID? >> >> What I've tried to note with the above comment is how trivial it is to >> trigger the use of IPv6 atomic fragments. >> > Agreed it's trivial. > > Do you consider the existence of atomic fragments to be harmful per se? No, I don't (as long as v6 implementations implement this spec). Atomic fragments, when processed as specified in draft-ietf-6man-ipv6-atomic-fragments-03.txt, behave exactly as unfragmented traffic (modulo the need to remove the Frag header, of course). > Or just the fact that they can adversely affect re-assembly at a host, > and thus can be used as an attack vector on the destination host? Exactly. The problem is that some implementations try to reassemble the atomic fragments with other existing fragments -- i.e., the flaw is in the reassembly process, rather than in the atomic fragments themselves. > Given the potential adverse effects on middleware boxes such as > firewalls, I'm thinking you consider them harmful per se. Of all the fragmentation cases, the atomic fragment case is the last I would worry about. (the worst being draft-ietf-6man-oversized-header-chain). That said, v6 fragmentation as a whole is probably going to have a very hard time, unless we were to enforce very tight constraints (e.g. "the whole header chain should be present in the first, say, 512 bytes") -- but at the time this wg did not even buy the requirement of the header chain to be in the first 1280 bytes (that's how we gor to the current requirement of "the complete header chain must be present in the first fragment). >>> I think your current ID stands alone whether these validation checks are performed or not. >> >> Agreed. But what I've tried to stress is that it is trivial to make any >> connection employ atomic fragments -- hence it's not that the only >> target of atomic-fragment attacks are those connections already employed >> atomic fragments or fragmentation: it's trivial to trigger the use of >> such fragments, and then perform a fragmentation-based attack... >> > Understood. > > But if we consider atomic fragments to be harmful per se, Atomic fragments are not harmful per-se, since they can be processes as unfragmented traffic. *Real* fragmented traffic could be deemed as harmful, though. (or as "unlikely to survive the Internet", if you prefer ;-) ). > what concrete > advice can we give implementors in a SHOULD clause in this ID on how to > process received ICMPv6 Packet Too Big messages in order to make > triggering atomic fragments less trivial? What should be done is validate ICMPv6 PTB according to: 1) the embedded payload, and, 2) progress on the connection (actually, you're probably good enough even doing just the later). The idea behind "2)" is simple: If you get an ICMPv6 PTB, it's because your packets are being dropped (as a consequence of using a packet size that is too large). So if the ICMPv6 PTB refers to e.g. a TCP connection, you could just queue the received ICMPv6 PTB, and only honour it when/if theres a TCP timeout at the TCP layer. FWIW: 1) I implemented this on OpenBSD years ago, and the patch was ported to NetBSD -- so both OSes have been employing this for years. 2) This approach is documented in RFC5927. Now, if you wonder how things are the way they are specs-wise, my take is: 1) RFC5927 went informational because it was done in TCP in the 2004- timeframe. (was plagged by neverending nitpicking non-sensiscal discussions which were out of touch with running code). 2) RFC4443 somehow assumed that RFC1122 had to apply to ICMPv6 in the same way it applied to ICMP(v4) -- hence the validation of ICMPv6 PTB was not included as mandatory (fair enough... they either had to downref RFC5927, or incorporate half of that RFC into RFC4443) So, with that state of affairs with ICMPv6 PTB validation, sloppy processing of atomic-fragments (which draft-ietf-6man-ipv6-atomic-fragments-03.txt fixes), and sloppy Frag ID generators in many iplementations (and we at the ietf/a wg not doing something about it, yet), we have v6 implementations that...mm.. suck big time :-) in this area. > If we haven't got any advice on how to stop them being triggered, we > can't really moan that it's trivial to trigger them. PMTUD is currently > pretty fundamental for correct operation of IPv6. Re-reading RFC1981, > it's tough to see what more anyone can sensibly do in a lightweight > implementation. See Section 4 and Section 7 of RFC 5927. One might argue that this wg might want to produce some version of RFC 5927 for ICMPv6, which doesn't focus on any specific upper-layer protocol (i.e., doesn't focus on TCP attacks). 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 fernando@gont.com.ar Fri Jan 11 05:27:10 2013 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 BE13921F86FF for ; Fri, 11 Jan 2013 05:27:10 -0800 (PST) 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=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 tzd5fL+qbfg9 for ; Fri, 11 Jan 2013 05:27:10 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1409B21F86F6 for ; Fri, 11 Jan 2013 05:27:08 -0800 (PST) Received: from [186.134.30.167] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Ttecm-0002uT-LU; Fri, 11 Jan 2013 14:26:20 +0100 Message-ID: <50EFD855.6070203@gont.com.ar> Date: Fri, 11 Jan 2013 06:16:05 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Fernando Gont Subject: Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-02.txt References: <20121230011537.2800.39239.idtracker@ietfa.amsl.com> <50DF964A.5000504@si6networks.com> In-Reply-To: <50DF964A.5000504@si6networks.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 13:27:10 -0000 Bob & Ole, Ping? Thanks, Fernando On 12/29/2012 10:18 PM, Fernando Gont wrote: > Folks, > > I've rev'ed the document according to our recent email exchange. > > Should we ship the document now? > > Thanks, and have a Happy New Year! > > Best regards, > Fernando > > > > > On 12/29/2012 10:15 PM, 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 : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) >> Author(s) : Fernando Gont >> Filename : draft-ietf-6man-stable-privacy-addresses-02.txt >> Pages : 18 >> Date : 2012-12-29 >> >> Abstract: >> This document specifies a method for generating IPv6 Interface >> Identifiers to be used with IPv6 Stateless Address Autoconfiguration >> (SLAAC), such that addresses configured using this method are stable >> within each subnet, but the Interface Identifier changes when hosts >> move from one network to another. The aforementioned method is meant >> to be an alternative to generating Interface Identifiers based on >> IEEE identifiers, such that the benefits of stable addresses can be >> achieved without sacrificing the privacy of users. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-02 >> >> >> 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 >> -------------------------------------------------------------------- >> > > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fgont@si6networks.com Fri Jan 11 07:34:20 2013 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 56CB521F873D for ; Fri, 11 Jan 2013 07:34:20 -0800 (PST) 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 k0Bjcm5v0QmW for ; Fri, 11 Jan 2013 07:34:19 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id B473E21F8738 for ; Fri, 11 Jan 2013 07:34:19 -0800 (PST) Received: from [186.134.32.129] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TtgcE-0005vv-8r; Fri, 11 Jan 2013 16:33:54 +0100 Message-ID: <50F030DB.2040008@si6networks.com> Date: Fri, 11 Jan 2013 12:33:47 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org> Subject: Security Issues with Predictable Frag IDs (draft-gont-6man-predictable-fragment-id) X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 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, 11 Jan 2013 15:34:20 -0000 Folks, draft-gont-6man-predictable-fragment-id has been around for a while. It was presented for the first time at the IETF 83 (Paris), and revised according to the comments received. It was then presented at IETF 84 (Vancouver)... but the working group was never polled for WG adoption. At IETF 84, some folks argued that it would be great to have a general document that discussed the issue of "predictable IDs" in general... but quite a few folks also noted (both on-list and at the mike8 that that wouldn't relieve us from updating RFC2460 as appropriate. Meanwhile, we still have vulnerable implementations, and we have implementers taking the advice in this *individual* I-D, which IMO should be a wg item to represent the wg view on this topic. May I ask for the wg to be formally polled about adoption of this document as a wg item? I'm not sure why this hasn't happened in the last 10 months or so. 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 fgont@si6networks.com Fri Jan 11 08:49:13 2013 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 BF25021F8838 for ; Fri, 11 Jan 2013 08:49:13 -0800 (PST) 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 inMAueBDw1oi for ; Fri, 11 Jan 2013 08:49:13 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id A1C9121F8809 for ; Fri, 11 Jan 2013 08:49:12 -0800 (PST) Received: from [186.134.32.129] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Tthmf-0007ke-TA; Fri, 11 Jan 2013 17:48:46 +0100 Message-ID: <50F04265.2040302@si6networks.com> Date: Fri, 11 Jan 2013 13:48:37 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: IPv6 smurf amplifiers (draft-gont-6man-ipv6-smurf-amplifier-01.txt) References: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> In-Reply-To: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 X-Forwarded-Message-Id: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 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, 11 Jan 2013 16:49:14 -0000 Folks, We have published a revision of our I-D entitled "Security Implications of IPv6 options of Type 10xxxxxx", about IPv6 smurf amplifiers. The I-D is available at: . Any comments will be very appreciated. Thanks! Best regards, Fernando -------- Original Message -------- From: - Fri Jan 11 13:40:47 2013 From: internet-drafts@ietf.org To: fgont@si6networks.com Cc: liushucheng@huawei.com Subject: New Version Notification for draft-gont-6man-ipv6-smurf-amplifier-01.txt Message-ID: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> Date: Fri, 11 Jan 2013 08:40:12 -0800 A new version of I-D, draft-gont-6man-ipv6-smurf-amplifier-01.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-6man-ipv6-smurf-amplifier Revision: 01 Title: Security Implications of IPv6 options of Type 10xxxxxx Creation date: 2013-01-11 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-smurf-amplifier-01.txt Status: http://datatracker.ietf.org/doc/draft-gont-6man-ipv6-smurf-amplifier Htmlized: http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-gont-6man-ipv6-smurf-amplifier-01 Abstract: When an IPv6 node processing an IPv6 packet does not support an IPv6 option whose two-highest-order bits of the Option Type are '10', it is required to respond with an ICMPv6 Parameter Problem error message, even if the Destination Address of the packet was a multicast address. This feature provides an amplification vector, opening the door to an IPv6 version of the 'Smurf' Denial-of-Service (DoS) attack found in IPv4 networks. This document discusses the security implications of the aforementioned options, and formally updates RFC 2460 such that this attack vector is eliminated. Additionally, it describes a number of operational mitigations that could be deployed against this attack vector. The IETF Secretariat From otroan@employees.org Mon Jan 14 00:10:52 2013 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 D81D721F888B for ; Mon, 14 Jan 2013 00:10:52 -0800 (PST) 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 LDiAm8WxDt2f for ; Mon, 14 Jan 2013 00:10:52 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0F91D21F888A for ; Mon, 14 Jan 2013 00:10:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAS981CQ/khN/2dsb2JhbABEg2u6ERZzgh4BAQEDAQEBATc0CwUHBAsOAwMBAi8nKAgGEwmICgYHBbN2kE1hA5JYhE+PLYJ2 X-IronPort-AV: E=Sophos;i="4.84,466,1355097600"; d="scan'208";a="149348256" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 14 Jan 2013 08:10:50 +0000 Received: from dhcp-lys02-vla252-10-147-116-45.cisco.com (dhcp-lys02-vla252-10-147-116-45.cisco.com [10.147.116.45]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0E8AnD0004692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Jan 2013 08:10:49 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: IPv6 smurf amplifiers (draft-gont-6man-ipv6-smurf-amplifier-01.txt) From: Ole Troan In-Reply-To: <50F04265.2040302@si6networks.com> Date: Mon, 14 Jan 2013 09:10:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <66B727E0-6620-48F6-94CC-905F24F9EF9B@employees.org> References: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> <50F04265.2040302@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1499) 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, 14 Jan 2013 08:10:53 -0000 Fernando, et al, > We have published a revision of our I-D entitled "Security = Implications > of IPv6 options of Type 10xxxxxx", about IPv6 smurf amplifiers. >=20 > The I-D is available at: > = . >=20 > Any comments will be very appreciated. isn't this attack covered already inRFC4443, section 5.2 bullet 5? cheers, Ole > -------- Original Message -------- > From: - Fri Jan 11 13:40:47 2013 > From: internet-drafts@ietf.org > To: fgont@si6networks.com > Cc: liushucheng@huawei.com > Subject: New Version Notification for > draft-gont-6man-ipv6-smurf-amplifier-01.txt > Message-ID: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> > Date: Fri, 11 Jan 2013 08:40:12 -0800 >=20 >=20 > A new version of I-D, draft-gont-6man-ipv6-smurf-amplifier-01.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. >=20 > Filename: draft-gont-6man-ipv6-smurf-amplifier > Revision: 01 > Title: Security Implications of IPv6 options of Type = 10xxxxxx > Creation date: 2013-01-11 > WG ID: Individual Submission > Number of pages: 9 > URL: > = http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-smurf-amplifier-0= 1.txt > Status: > http://datatracker.ietf.org/doc/draft-gont-6man-ipv6-smurf-amplifier > Htmlized: > http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-01 > Diff: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-6man-ipv6-smurf-amplifier-01= >=20 > Abstract: > When an IPv6 node processing an IPv6 packet does not support an IPv6 > option whose two-highest-order bits of the Option Type are '10', it > is required to respond with an ICMPv6 Parameter Problem error > message, even if the Destination Address of the packet was a > multicast address. This feature provides an amplification vector, > opening the door to an IPv6 version of the 'Smurf' Denial-of-Service > (DoS) attack found in IPv4 networks. This document discusses the > security implications of the aforementioned options, and formally > updates RFC 2460 such that this attack vector is eliminated. > Additionally, it describes a number of operational mitigations that > could be deployed against this attack vector. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian@innovationslab.net Mon Jan 14 07:09:57 2013 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 73ECB21F8AC3 for ; Mon, 14 Jan 2013 07:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 AFYyd+y6NGEV for ; Mon, 14 Jan 2013 07:09:56 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id E185A21F8AD8 for ; Mon, 14 Jan 2013 07:09:56 -0800 (PST) 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 C038588153; Mon, 14 Jan 2013 07:09:56 -0800 (PST) Received: from 1025265105.rude1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 4F306130019; Mon, 14 Jan 2013 07:09:56 -0800 (PST) Message-ID: <50F41FCC.5020701@innovationslab.net> Date: Mon, 14 Jan 2013 10:10:04 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: draft-ietf-6man-nd-extension-headers@tools.ietf.org, 6man Chairs <6man-chairs@tools.ietf.org>, 6man WG Subject: AD Review: draft-ietf-6man-nd-extension-headers 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: Mon, 14 Jan 2013 15:09:57 -0000 All, I have completed my AD evaluation of draft-ietf-6man-nd-extension-headers. The following comments need to be addressed prior to progressing this draft to IETF Last Call. 1. The first sentence of the Abstract appears to be a remnant of when this draft discussed Extension Headers in general. It should be updated to focus on the use of fragmentation within NDP messages. 2. The first sentence of the Introduction is a bit misleading. NDP is specified in 4861. RFC 4862 specifies SLAAC. They are two different things, so I am not sure why 4862 is getting put into this statement. 3. The Intro also contains rudimentary discussion of existing tools for monitoring/protecting NDP traffic. It would be good to also discuss the KAME rafixd tool, as it as similar capabilities. 4. It would also be useful to discuss if there are limitations on simply blocking fragmented NDP traffic. Since this traffic is limited to a single L-2 link, dropping fragments may be a simple mechanism for dealing with fragmentation-based attacks. Regards, Brian From fgont@si6networks.com Mon Jan 14 11:14:15 2013 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 4CF9F21F8B25 for ; Mon, 14 Jan 2013 11:14:15 -0800 (PST) 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 IAaVpo+FAh7D for ; Mon, 14 Jan 2013 11:14:10 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 797A621F8B1A for ; Mon, 14 Jan 2013 11:14:09 -0800 (PST) Received: from [186.134.32.129] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TupTT-00014U-MQ; Mon, 14 Jan 2013 20:13:36 +0100 Message-ID: <50F458D8.8090605@si6networks.com> Date: Mon, 14 Jan 2013 16:13:28 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ole Troan Subject: Re: IPv6 smurf amplifiers (draft-gont-6man-ipv6-smurf-amplifier-01.txt) References: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> <50F04265.2040302@si6networks.com> <66B727E0-6620-48F6-94CC-905F24F9EF9B@employees.org> In-Reply-To: <66B727E0-6620-48F6-94CC-905F24F9EF9B@employees.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 19:14:15 -0000 Hi, Ole, On 01/14/2013 05:10 AM, Ole Troan wrote: >> We have published a revision of our I-D entitled "Security Implications >> of IPv6 options of Type 10xxxxxx", about IPv6 smurf amplifiers. >> >> The I-D is available at: >> . >> >> Any comments will be very appreciated. > > isn't this attack covered already inRFC4443, section 5.2 bullet 5? No. The following text in Section 4.2 of RFC 2460 overrides what's in RFC 4443: 10 - discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. That's why RFC 2460 needs to be updated. FWIW, all implementations I've tested so far behave as specified in RFC 2460, and hence can be leveraged as smurf amplifiers. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Fred.L.Templin@boeing.com Mon Jan 14 11:31:16 2013 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 77E8E21F8B08 for ; Mon, 14 Jan 2013 11:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.142 X-Spam-Level: X-Spam-Status: No, score=-1.142 tagged_above=-999 required=5 tests=[AWL=1.457, 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 XwCyEZ+ougjx for ; Mon, 14 Jan 2013 11:31:15 -0800 (PST) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id CBF1C21F8B02 for ; Mon, 14 Jan 2013 11:31:15 -0800 (PST) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r0EJVawY013159 for ; Mon, 14 Jan 2013 11:31:36 -0800 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r0EJVZ1U013139 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 14 Jan 2013 11:31:35 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 14 Jan 2013 11:31:13 -0800 From: "Templin, Fred L" To: Fernando Gont Date: Mon, 14 Jan 2013 11:31:12 -0800 Subject: RE: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments Thread-Topic: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments Thread-Index: Ac3fOWQChZ8jLjXdTji8iJs5oGVzqATU6jRA Message-ID: References: <50CA2508.1030003@innovationslab.net> <50CF402E.80706@si6networks.com> <50D09AAE.6000601@innovationslab.net> <50D0CB40.5070103@si6networks.com> <50D3EF04.4060004@si6networks.com> In-Reply-To: <50D3EF04.4060004@si6networks.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-TM-AS-MML: No Cc: "draft-ietf-6man-ipv6-atomic-fragments@tools.ietf.org" , 6man WG 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, 14 Jan 2013 19:31:16 -0000 Hello Fernando, > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com] > Sent: Thursday, December 20, 2012 9:09 PM > To: Templin, Fred L > Cc: draft-ietf-6man-ipv6-atomic-fragments@tools.ietf.org; 6man WG > Subject: Re: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments >=20 > On 12/20/2012 03:04 PM, Templin, Fred L wrote: > >> On 12/18/2012 04:13 PM, Templin, Fred L wrote: > >>> I have a question about this document. Is a middlebox permitted > >>> to fragment an "atomic" fragment before forwarding the packet > >>> on to the next hop? If not, why not - after all, that's why the > >>> host inserted the fragment header in the first place. > >> > >> My take is that an *IPv6* middle-box is not permitted to fragment the > >> packet. The IPv6/IPv4 translator is, from an IPv6 point of view, a > >> host/end-point/end-system (that's where the v6 world ends for that > >> packet). > > > > On further thought, I don't fully accept the notion that the > > translator is a host/end-point/end-system. >=20 > From the pov of the IPv6 network that's where the packet "ends". >=20 >=20 > > The IPv6 host provides > > the translator with an Identification value, and that value carries > > forward into the IPv4 world. So, while the IPv6 packet itself does > > not carry forward, IPv6 information does. >=20 > Yes and no -- e.g., you cannot use the full 32-bit Frag ID. >=20 >=20 >=20 > >> As to the "why not", I'd guess the reason is "only IPv6 hosts fragment > >> packets" > > > > I think there would need to be an asterisk next to that statement > > saying that IPv6/IPv4 translators are exempt from this requirement. > > And, if the translator can be exempt then so also should an IPv6 > > middlebox that connects to a link that would otherwise be obliged > > to perform burdensome link adaptation. >=20 > This does not only apply to tunnels. One could think of some radio > devices, embedded systems, etc., for which an adaptation layer would > possible be overkill. -- So you're idea sounds, at least in principle, > sensible to me. >=20 > I will review your I-D and will come back with some feedback. I was wondering if you have had a chance to look at my document on "IPv6 Path MTU Updates" yet: https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag/ I have posted a new version since we spoke last, which clarifies a number of points and now speaks more generically about links that perform link adaptation rather than just about tunnels. I would welcome your comments on the document. Thanks - Fred fred.l.templin@boeing.com > Thanks! >=20 > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 From fgont@si6networks.com Mon Jan 14 11:39:17 2013 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 C2BD321F8AE5 for ; Mon, 14 Jan 2013 11:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 7af6Z3TLz1yI for ; Mon, 14 Jan 2013 11:39:17 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id E464F21F8AD4 for ; Mon, 14 Jan 2013 11:39:16 -0800 (PST) Received: from [186.134.32.129] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TupsB-0001kf-Da; Mon, 14 Jan 2013 20:39:07 +0100 Message-ID: <50F45ED4.9030209@si6networks.com> Date: Mon, 14 Jan 2013 16:39:00 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Templin, Fred L" Subject: draft-generic-6man-tunfrag (was: Re: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments) References: <50CA2508.1030003@innovationslab.net> <50CF402E.80706@si6networks.com> <50D09AAE.6000601@innovationslab.net> <50D0CB40.5070103@si6networks.com> <50D3EF04.4060004@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man WG 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, 14 Jan 2013 19:39:17 -0000 On 01/14/2013 04:31 PM, Templin, Fred L wrote: >> I will review your I-D and will come back with some feedback. > > I was wondering if you have had a chance to look at my document > on "IPv6 Path MTU Updates" yet: > > https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag/ > > I have posted a new version since we spoke last, which clarifies > a number of points and now speaks more generically about links > that perform link adaptation rather than just about tunnels. I > would welcome your comments on the document. My apologies -- I promise I'll post my feedback no later than the next couple of days. 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 internet-drafts@ietf.org Mon Jan 14 12:01:04 2013 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 21B4C21F8B69; Mon, 14 Jan 2013 12:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 qsW3EWdZ3ra9; Mon, 14 Jan 2013 12:01:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E262521F8B63; Mon, 14 Jan 2013 12:01:00 -0800 (PST) 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-nd-extension-headers-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130114200100.1265.96392.idtracker@ietfa.amsl.com> Date: Mon, 14 Jan 2013 12:01:00 -0800 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, 14 Jan 2013 20:01:04 -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 : Security Implications of IPv6 Fragmentation with IPv6 Ne= ighbor Discovery Author(s) : Fernando Gont Filename : draft-ietf-6man-nd-extension-headers-03.txt Pages : 13 Date : 2013-01-14 Abstract: This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective counter-measures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND), and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be prevented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-nd-extension-headers There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-nd-extension-headers-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-nd-extension-headers-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fgont@si6networks.com Mon Jan 14 12:01:46 2013 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 34BD821F8B37 for ; Mon, 14 Jan 2013 12:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 USapG+wYMkVd for ; Mon, 14 Jan 2013 12:01:45 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE2821F8B34 for ; Mon, 14 Jan 2013 12:01:45 -0800 (PST) Received: from [186.134.32.129] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TuqDu-0002M1-4Y; Mon, 14 Jan 2013 21:01:34 +0100 Message-ID: <50F46413.1000207@si6networks.com> Date: Mon, 14 Jan 2013 17:01:23 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Brian Haberman Subject: Re: AD Review: draft-ietf-6man-nd-extension-headers References: <50F41FCC.5020701@innovationslab.net> In-Reply-To: <50F41FCC.5020701@innovationslab.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, draft-ietf-6man-nd-extension-headers@tools.ietf.org, 6man WG 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, 14 Jan 2013 20:01:46 -0000 Hi, Brian, Meta-comment: All proposed changes have been applied, and the rev'ed draft has been posted -- readt for IETF LC? More comments in-line... On 01/14/2013 12:10 PM, Brian Haberman wrote: > All, > I have completed my AD evaluation of > draft-ietf-6man-nd-extension-headers. The following comments need to be > addressed prior to progressing this draft to IETF Last Call. > > 1. The first sentence of the Abstract appears to be a remnant of when > this draft discussed Extension Headers in general. It should be updated > to focus on the use of fragmentation within NDP messages. Fixed. > 2. The first sentence of the Introduction is a bit misleading. NDP is > specified in 4861. RFC 4862 specifies SLAAC. They are two different > things, so I am not sure why 4862 is getting put into this statement. Fixed. > 3. The Intro also contains rudimentary discussion of existing tools for > monitoring/protecting NDP traffic. It would be good to also discuss the > KAME rafixd tool, as it as similar capabilities. I've added rafixd.. although the list wasn't meant to be exhaustive -- for instance, all of the listed "tools" can be fooled by employing extension headers and/or fragmentation... > 4. It would also be useful to discuss if there are limitations on simply > blocking fragmented NDP traffic. Please see draft-ietf-6man-oversized-header-chain (and the figures in draft-ietf-v6ops-ra-guard-implementation). Short story: with the current specs, you might not be able to tell whether a packet is NDP or not -- hence your policy ends up being "drop fragmented v6 traffic" (draft-ietf-v6ops-ra-guard-implementation is "as good as it can get" for this specific case) > Since this traffic is limited to a > single L-2 link, dropping fragments may be a simple mechanism for > dealing with fragmentation-based attacks. The current packet structure is a nightmare for any device willing to perform any sort of inspection. So at the very least you need to process the entire IPv6 header chain -- and some devices cannot even do this. 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 simon.perreault@viagenie.ca Tue Jan 15 02:11:33 2013 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 0466721F884B for ; Tue, 15 Jan 2013 02:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=1.629, BAYES_00=-2.599, NO_RELAYS=-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 X0250WXkQ7+v for ; Tue, 15 Jan 2013 02:11:22 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8534F21F8844 for ; Tue, 15 Jan 2013 02:11:22 -0800 (PST) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:f454:37f3:6ead:1220]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AE6FE40397 for ; Tue, 15 Jan 2013 05:11:21 -0500 (EST) Message-ID: <50F52B78.4060701@viagenie.ca> Date: Tue, 15 Jan 2013 11:12:08 +0100 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: IPv6 smurf amplifiers (draft-gont-6man-ipv6-smurf-amplifier-01.txt) References: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> <50F04265.2040302@si6networks.com> <66B727E0-6620-48F6-94CC-905F24F9EF9B@employees.org> <50F458D8.8090605@si6networks.com> In-Reply-To: <50F458D8.8090605@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 15 Jan 2013 10:11:33 -0000 Le 2013-01-14 20:13, Fernando Gont a écrit : > No. The following text in Section 4.2 of RFC 2460 overrides what's in > RFC 4443: An earlier RFC can't "override" a later RFC. The later RFC wins. > FWIW, all implementations I've tested so far behave as specified in RFC > 2460, and hence can be leveraged as smurf amplifiers. That's a different (and better IMHO) reason why publishing something new could be useful. Simon From iesg-secretary@ietf.org Tue Jan 15 07:41:23 2013 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 07CB121F86FD; Tue, 15 Jan 2013 07:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 R5Qv25Iao1bA; Tue, 15 Jan 2013 07:41:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8357721F8635; Tue, 15 Jan 2013 07:41:22 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery) to Proposed Standard X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130115154122.15617.50856.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 07:41:22 -0800 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, 15 Jan 2013 15:41:23 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery' 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 2013-01-29. 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 analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective counter-measures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND), and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be prevented. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-nd-extension-headers/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-nd-extension-headers/ballot/ No IPR declarations have been submitted directly on this I-D. From fgont@si6networks.com Tue Jan 15 13:53:44 2013 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 C625B21F8514 for ; Tue, 15 Jan 2013 13:53:44 -0800 (PST) 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 SVlE8v5umo3A for ; Tue, 15 Jan 2013 13:53:44 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFC921F84F9 for ; Tue, 15 Jan 2013 13:53:42 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TvER2-0006mq-ML; Tue, 15 Jan 2013 22:53:16 +0100 Message-ID: <50F5CFA2.6040008@si6networks.com> Date: Tue, 15 Jan 2013 18:52:34 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ole Troan Subject: Re: IPv6 smurf amplifiers (draft-gont-6man-ipv6-smurf-amplifier-01.txt) References: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> <50F04265.2040302@si6networks.com> <66B727E0-6620-48F6-94CC-905F24F9EF9B@employees.org> <50F458D8.8090605@si6networks.com> In-Reply-To: <50F458D8.8090605@si6networks.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 21:53:44 -0000 Hi, Ole, On 01/14/2013 04:13 PM, Fernando Gont wrote: > > On 01/14/2013 05:10 AM, Ole Troan wrote: >>> We have published a revision of our I-D entitled "Security Implications >>> of IPv6 options of Type 10xxxxxx", about IPv6 smurf amplifiers. >>> >>> The I-D is available at: >>> . >>> >>> Any comments will be very appreciated. >> >> isn't this attack covered already inRFC4443, section 5.2 bullet 5? BTW, bullet "e)" in Section 2.4 (page 6) of RFC 4443 says: (e.3) A packet destined to an IPv6 multicast address. (There are two exceptions to this rule: (1) the Packet Too Big Message (Section 3.2) to allow Path MTU discovery to work for IPv6 multicast, and (2) the Parameter Problem Message, Code 2 (Section 3.4) reporting an unrecognized IPv6 option (see Section 4.2 of [IPv6]) that has the Option Type highest- order two bits set to 10). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Jan 15 13:58:16 2013 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 47A9611E80BA for ; Tue, 15 Jan 2013 13:58:16 -0800 (PST) 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 akGXLpVeNOsk for ; Tue, 15 Jan 2013 13:58:15 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id A3F8721F84DB for ; Tue, 15 Jan 2013 13:58:15 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TvEVo-0006u4-HS; Tue, 15 Jan 2013 22:57:53 +0100 Message-ID: <50F5D0C7.6000900@si6networks.com> Date: Tue, 15 Jan 2013 18:57:27 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Simon Perreault Subject: Re: IPv6 smurf amplifiers (draft-gont-6man-ipv6-smurf-amplifier-01.txt) References: <20130111164012.4921.69654.idtracker@ietfa.amsl.com> <50F04265.2040302@si6networks.com> <66B727E0-6620-48F6-94CC-905F24F9EF9B@employees.org> <50F458D8.8090605@si6networks.com> <50F52B78.4060701@viagenie.ca> In-Reply-To: <50F52B78.4060701@viagenie.ca> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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, 15 Jan 2013 21:58:16 -0000 Hi, Simon, On 01/15/2013 07:12 AM, Simon Perreault wrote: > Le 2013-01-14 20:13, Fernando Gont a écrit : >> No. The following text in Section 4.2 of RFC 2460 overrides what's in >> RFC 4443: > > An earlier RFC can't "override" a later RFC. The later RFC wins. I agree that my phrasing was sloppy (at best -- the combination of English as non-native language + no sleep never helps). However, I'd say that a "later" RFC that does not formally update an earlier RFC does not override anything. In any case, both RFC 2460 and RFC 4443 agree on this point. As I've just noted to Ole, BTW, bullet "e)" in Section 2.4 (page 6) of RFC 4443 says: (e.3) A packet destined to an IPv6 multicast address. (There are two exceptions to this rule: (1) the Packet Too Big Message (Section 3.2) to allow Path MTU discovery to work for IPv6 multicast, and (2) the Parameter Problem Message, Code 2 (Section 3.4) reporting an unrecognized IPv6 option (see Section 4.2 of [IPv6]) that has the Option Type highest- order two bits set to 10). So I should probably note this in the I-D, and add RFC4443 to the RFCs that need to be updated. Thoughts? >> FWIW, all implementations I've tested so far behave as specified in RFC >> 2460, and hence can be leveraged as smurf amplifiers. > > That's a different (and better IMHO) reason why publishing something new > could be useful. In this case, since the RFCs are in agreement, I'm not sure if it would add anything to comment that "all popular implementations behave as specified in this RFCs". But I could include such a note if deemed appropriate. Thoughts? Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From internet-drafts@ietf.org Tue Jan 15 20:46:19 2013 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 1FCDC11E8108; Tue, 15 Jan 2013 20:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 ho5Kzp0y8-DX; Tue, 15 Jan 2013 20:46:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9417D11E8102; Tue, 15 Jan 2013 20:46:18 -0800 (PST) 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-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130116044618.617.50605.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 20:46:18 -0800 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, 16 Jan 2013 04:46:19 -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-08.txt Pages : 10 Date : 2013-01-15 Abstract: RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-addr-select-opt-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Wed Jan 16 06:54:12 2013 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 345EC21F8959 for ; Wed, 16 Jan 2013 06:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 xw3ncDIU7ImO for ; Wed, 16 Jan 2013 06:54:11 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 757C121F88EF for ; Wed, 16 Jan 2013 06:54:11 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 7D9452DC7D5; Wed, 16 Jan 2013 15:54:10 +0100 (CET) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 39F7035C076; Wed, 16 Jan 2013 15:54:10 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 16 Jan 2013 15:54:09 +0100 From: To: "ipv6@ietf.org" Date: Wed, 16 Jan 2013 15:54:08 +0100 Subject: draft-boucadair-6man-multicast-addr-arch-update-00 Thread-Topic: draft-boucadair-6man-multicast-addr-arch-update-00 Thread-Index: Ac3z4u1053StVGtNRLeZmhwqb5q3XgAFedOA Message-ID: <94C682931C08B048B7A8645303FDC9F36EA601E4BC@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.1.16.113630 Cc: Brian Haberman , Stig Venaas 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, 16 Jan 2013 14:54:12 -0000 Dear all, We submitted this short draft to update some existing IPv6 multicast RFCs; = especially to extend the definition of some reserved bits.=20 Comments are more than welcome.=20 Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : mercredi 16 janvier 2013 13:13 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-boucadair-6man-multicast-addr-arch-update-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Updates to the IPv6 Multicast Addressing Architecture Author(s) : Mohamed Boucadair Stig Venaas Filename : draft-boucadair-6man-multicast-addr-arch-update-00.txt Pages : 5 Date : 2013-01-16 Abstract: This document updates the IPv6 multicast addressing architecture by defining the 17-20 reserved bits as generic flag bits. The document provides also some clarifications related to the use of these flag bits. This document updates RFC 3956, RFC 3306, RFC 4607 and RFC 4291. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-6man-multicast-addr-arch-u= pdate There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-6man-multicast-addr-arch-update-= 00 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 magnus.westerlund@ericsson.com Thu Jan 17 02:28:00 2013 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 AFD4221F8783 for ; Thu, 17 Jan 2013 02:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.100, 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 6GcRnr06+xEP for ; Thu, 17 Jan 2013 02:28:00 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8FB21F8798 for ; Thu, 17 Jan 2013 02:27:59 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-3d-50f7d22d914a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EE.01.10459.D22D7F05; Thu, 17 Jan 2013 11:27:58 +0100 (CET) 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.279.1; Thu, 17 Jan 2013 11:27:57 +0100 Message-ID: <50F7D22C.1010002@ericsson.com> Date: Thu, 17 Jan 2013 11:27:56 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: 6MAN WG Last Call: References: <50C7D7BA.3020904@joelhalpern.com> <50C843D5.2040606@ericsson.com> In-Reply-To: <50C843D5.2040606@ericsson.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvja7epe8BBteauSy2vt/HZvHy7Hsm i4+n3jA5MHvsnHWX3WPJkp9MHuemfGcMYI7isklJzcksSy3St0vgynj/ejpbwSGeiq2zf7A3 ME7h6mLk5JAQMJE4dvUKC4QtJnHh3no2EFtI4CSjxIKfUl2MXED2ckaJv2uOgSV4BbQljny8 xQRiswioSnyaNI0RxGYTsJC4+aMRrEZUIFhiw8FVTBD1ghInZz4BWyAiYCbxcMJ+sBpmgRyJ iSumgNUIC7hKbFhxDWpxvcSOE4vYQWxOAR2Jv0vuAtkcQMeJS6x5wwHRqicx5WoLI4QtL9G8 dTYzRKu2RENTB+sERqFZSDbPQtIyC0nLAkbmVYzsuYmZOenlhpsYgcF7cMtv3R2Mp86JHGKU 5mBREucNc70QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoExTHr3i8gNVz4fasq/Fbalr6Kd rWnt/XvhC5da18z8bWb8+KN6g3fA80URt+/dEuV//W2eqfiGYN097RMfvii6xR5vXqLqeOFm kYlH7npXrUu1Gk2GXGf1LRez2PjHXnwT8/CYmL/8rA+6MjJ/VfZssDhQuPxt2QeDNxoW789N O8VZdUZv25w8JZbijERDLeai4kQAfkqSuSwCAAA= Cc: Bob Hinden , IPv6 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: Thu, 17 Jan 2013 10:28:00 -0000 On 2012-12-12 09:44, Magnus Westerlund wrote: > Thanks for the Review, > > On 2012-12-12 02:02, Joel M. Halpern wrote: >> This (and the companion document draft-ietf-6man-udpzero) seem ready for >> publication to me. >> >> I do have a minor questions. It is sufficiently minor that if necessary >> it may be ignored so publication can proceed. >> >> I section 5, bullet 3 talks about "tunnel protocol will not >> significantly increase the rate of corruption of the inner packet", and >> then talks about needing to use additional integrity verification if >> there is a risk of such increased corruption. My question is, what kind >> of encapsulating protocol would or could, by its nature, create such a >> risk? It is not at all clear to me what a protocol designer should be >> watching for. > > The one think we have determined could cause increased corruption is > tunnels that fragment. That is discussed in the document in Section > 3.1.5 but not explicitly linked to this bullet. To make it clear we are not planing to make any changes to UDPZERO-08 to address this comment. Objections? Cheers 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 internet-drafts@ietf.org Thu Jan 17 02:50:40 2013 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 4B71521F84E7; Thu, 17 Jan 2013 02:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 LofYGOVqwIps; Thu, 17 Jan 2013 02:50:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FA421F8933; Thu, 17 Jan 2013 02:50:35 -0800 (PST) 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-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130117105035.4018.37947.idtracker@ietfa.amsl.com> Date: Thu, 17 Jan 2013 02:50:35 -0800 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, 17 Jan 2013 10:50:40 -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 : IPv6 and UDP Checksums for Tunneled Packets Author(s) : Marshall Eubanks AmericaFree.TV LLC P.F. Chimento Magnus Westerlund Filename : draft-ietf-6man-udpchecksums-07.txt Pages : 12 Date : 2013-01-17 Abstract: This document provides an update of the Internet Protocol version 6 (IPv6) specification (RFC2460) to improve the performance in the use case where a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for any suitable tunnel 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. The specification describes how the IPv6 UDP checksum requirement can be relaxed for the situation where the encapsulated packet itself contains a checksum. The limitations and risks of this approach are described, and restrictions specified on the use of the method. 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-udpchecksums-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jmh@joelhalpern.com Thu Jan 17 07:40:53 2013 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 42F7021F8688 for ; Thu, 17 Jan 2013 07:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTH7cgTTXKGr for ; Thu, 17 Jan 2013 07:40:52 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D7B9C21F8667 for ; Thu, 17 Jan 2013 07:40:52 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id D9A27A6829 for ; Thu, 17 Jan 2013 07:40:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 210331C04D7; Thu, 17 Jan 2013 07:40:51 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-134-125.clppva.east.verizon.net [70.106.134.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2F4161C0780; Thu, 17 Jan 2013 07:40:50 -0800 (PST) Message-ID: <50F81B7E.9010103@joelhalpern.com> Date: Thu, 17 Jan 2013 10:40:46 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Magnus Westerlund Subject: Re: 6MAN WG Last Call: References: <50C7D7BA.3020904@joelhalpern.com> <50C843D5.2040606@ericsson.com> <50F7D22C.1010002@ericsson.com> In-Reply-To: <50F7D22C.1010002@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Bob Hinden , IPv6 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: Thu, 17 Jan 2013 15:40:53 -0000 Understood. No objection from here. Yours, Joel On 1/17/2013 5:27 AM, Magnus Westerlund wrote: > On 2012-12-12 09:44, Magnus Westerlund wrote: >> Thanks for the Review, >> >> On 2012-12-12 02:02, Joel M. Halpern wrote: >>> This (and the companion document draft-ietf-6man-udpzero) seem ready for >>> publication to me. >>> >>> I do have a minor questions. It is sufficiently minor that if necessary >>> it may be ignored so publication can proceed. >>> >>> I section 5, bullet 3 talks about "tunnel protocol will not >>> significantly increase the rate of corruption of the inner packet", and >>> then talks about needing to use additional integrity verification if >>> there is a risk of such increased corruption. My question is, what kind >>> of encapsulating protocol would or could, by its nature, create such a >>> risk? It is not at all clear to me what a protocol designer should be >>> watching for. >> >> The one think we have determined could cause increased corruption is >> tunnels that fragment. That is discussed in the document in Section >> 3.1.5 but not explicitly linked to this bullet. > > To make it clear we are not planing to make any changes to UDPZERO-08 to > address this comment. Objections? > > Cheers > > 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 fgont@si6networks.com Thu Jan 17 10:12:11 2013 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 12B8A21F87FD for ; Thu, 17 Jan 2013 10:12:11 -0800 (PST) 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 9BAwjujNFMOx for ; Thu, 17 Jan 2013 10:12:07 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id DC60F21F87D4 for ; Thu, 17 Jan 2013 10:12:06 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Tvtw8-0005lk-Jd; Thu, 17 Jan 2013 19:11:36 +0100 Message-ID: <50F83ECA.8030803@si6networks.com> Date: Thu, 17 Jan 2013 15:11:22 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Fernando Gont Subject: Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-02.txt References: <20121230011537.2800.39239.idtracker@ietfa.amsl.com> <50DF964A.5000504@si6networks.com> <50EFD855.6070203@gont.com.ar> In-Reply-To: <50EFD855.6070203@gont.com.ar> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:12:11 -0000 Folks, Is the I-D ready to ship? It has been weeks since I posted the last rev. My understanding is that this I-D is ready to ship (after the clarifications I made on-list, and the tweaks I made to the I-D). But if there's any remaining bit, I'd like to know. But if the RTTs for these exchanges get so long, it's becomes even harder to follow the discussions. I'm aware that there are folks working on implementations of this I-D, and it'd be great to progress this I-D sooner than later. Thanks! Best regards, Fernando On 01/11/2013 06:16 AM, Fernando Gont wrote: > Bob & Ole, > > Ping? > > Thanks, > Fernando > > > > > On 12/29/2012 10:18 PM, Fernando Gont wrote: >> Folks, >> >> I've rev'ed the document according to our recent email exchange. >> >> Should we ship the document now? >> >> Thanks, and have a Happy New Year! >> >> Best regards, >> Fernando >> >> >> >> >> On 12/29/2012 10:15 PM, 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 : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) >>> Author(s) : Fernando Gont >>> Filename : draft-ietf-6man-stable-privacy-addresses-02.txt >>> Pages : 18 >>> Date : 2012-12-29 >>> >>> Abstract: >>> This document specifies a method for generating IPv6 Interface >>> Identifiers to be used with IPv6 Stateless Address Autoconfiguration >>> (SLAAC), such that addresses configured using this method are stable >>> within each subnet, but the Interface Identifier changes when hosts >>> move from one network to another. The aforementioned method is meant >>> to be an alternative to generating Interface Identifiers based on >>> IEEE identifiers, such that the benefits of stable addresses can be >>> achieved without sacrificing the privacy of users. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-02 >>> >>> >>> 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 >>> -------------------------------------------------------------------- >>> >> >> > > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Tina.Tsou.Zouting@huawei.com Thu Jan 17 14:42:55 2013 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 A456D21F8510 for ; Thu, 17 Jan 2013 14:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhXIDepdsgGP for ; Thu, 17 Jan 2013 14:42:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A54F421F850B for ; Thu, 17 Jan 2013 14:42:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOW54394; Thu, 17 Jan 2013 22:42:52 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 Jan 2013 22:42:37 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Jan 2013 06:42:52 +0800 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.4]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 17 Jan 2013 14:42:47 -0800 From: Tina TSOU To: "mohamed.boucadair@orange.com" , "ipv6@ietf.org" Subject: RE: draft-boucadair-6man-multicast-addr-arch-update-00 Thread-Topic: draft-boucadair-6man-multicast-addr-arch-update-00 Thread-Index: Ac3z4u1053StVGtNRLeZmhwqb5q3XgAFedOAAEK3xeA= Date: Thu, 17 Jan 2013 22:42:47 +0000 Message-ID: References: <94C682931C08B048B7A8645303FDC9F36EA601E4BC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EA601E4BC@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.96] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Stig Venaas 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, 17 Jan 2013 22:42:55 -0000 RGVhciBNZWQgYW5kIFN0aWcsDQpJIHRlY2huaWNhbGx5IHN1cHBvcnQgdGhpcyBkcmFmdC4NClRo ZSBuZXdseSBkZWZpbmVkIGZsZ3MgZmllbGQgaGFzIHRoZSBzYW1lIGZpZWxkIG5hbWUgaW4gb2xk IEFkZHJlc3NpbmcgQXJjaGl0ZWN0dXJlLiBJIHdvdWxkIHN1Z2dlc3QgcmVuYW1pbmcgbmV3bHkg ZGVmaW5lZCBmbGdzIGZpZWxkLg0KDQpUaGFuayB5b3UsDQpUaW5hDQoNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpp cHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tDQo+IFNlbnQ6IDIwMTPlubQx5pyIMTbml6UgNjo1NA0KPiBUbzogaXB2NkBpZXRm Lm9yZw0KPiBDYzogQnJpYW4gSGFiZXJtYW47IFN0aWcgVmVuYWFzDQo+IFN1YmplY3Q6IGRyYWZ0 LWJvdWNhZGFpci02bWFuLW11bHRpY2FzdC1hZGRyLWFyY2gtdXBkYXRlLTAwDQo+IA0KPiBEZWFy IGFsbCwNCj4gDQo+IFdlIHN1Ym1pdHRlZCB0aGlzIHNob3J0IGRyYWZ0IHRvIHVwZGF0ZSBzb21l IGV4aXN0aW5nIElQdjYgbXVsdGljYXN0IFJGQ3M7DQo+IGVzcGVjaWFsbHkgdG8gZXh0ZW5kIHRo ZSBkZWZpbml0aW9uIG9mIHNvbWUgcmVzZXJ2ZWQgYml0cy4NCj4gDQo+IENvbW1lbnRzIGFyZSBt b3JlIHRoYW4gd2VsY29tZS4NCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0KPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gRGUgOiBpLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXQ0KPiBEZSBsYSBwYXJ0IGRlIGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBFbnZvecOpIDogbWVyY3JlZGkgMTYgamFudmllciAyMDEz DQo+IDEzOjEzIMOAIDogaS1kLWFubm91bmNlQGlldGYub3JnIE9iamV0IDogSS1EIEFjdGlvbjog ZHJhZnQtYm91Y2FkYWlyLTZtYW4tDQo+IG11bHRpY2FzdC1hZGRyLWFyY2gtdXBkYXRlLTAwLnR4 dA0KPiANCj4gDQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lIEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4NCj4gDQo+IA0KPiAJVGl0bGUg ICAgICAgICAgIDogVXBkYXRlcyB0byB0aGUgSVB2NiBNdWx0aWNhc3QgQWRkcmVzc2luZw0KPiBB cmNoaXRlY3R1cmUNCj4gCUF1dGhvcihzKSAgICAgICA6IE1vaGFtZWQgQm91Y2FkYWlyDQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgU3RpZyBWZW5hYXMNCj4gCUZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWJvdWNhZGFpci02bWFuLW11bHRpY2FzdC1hZGRyLWFyY2gtdXBkYXRlLQ0KPiAwMC50 eHQNCj4gCVBhZ2VzICAgICAgICAgICA6IDUNCj4gCURhdGUgICAgICAgICAgICA6IDIwMTMtMDEt MTYNCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgdGhlIElQdjYg bXVsdGljYXN0IGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlIGJ5DQo+ICAgIGRlZmluaW5nIHRoZSAx Ny0yMCByZXNlcnZlZCBiaXRzIGFzIGdlbmVyaWMgZmxhZyBiaXRzLiAgVGhlIGRvY3VtZW50DQo+ ICAgIHByb3ZpZGVzIGFsc28gc29tZSBjbGFyaWZpY2F0aW9ucyByZWxhdGVkIHRvIHRoZSB1c2Ug b2YgdGhlc2UgZmxhZw0KPiAgICBiaXRzLg0KPiANCj4gICAgVGhpcyBkb2N1bWVudCB1cGRhdGVz IFJGQyAzOTU2LCBSRkMgMzMwNiwgUkZDIDQ2MDcgYW5kIFJGQyA0MjkxLg0KPiANCj4gDQo+IA0K PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm91Y2FkYWlyLTZtYW4tbXVs dGljYXN0LWFkZHItDQo+IGFyY2gtdXBkYXRlDQo+IA0KPiBUaGVyZSdzIGFsc28gYSBodG1saXpl ZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtYm91Y2FkYWlyLTZtYW4tbXVsdGljYXN0LWFkZHItYXJjaC0NCj4gdXBkYXRlLTAwDQo+IA0K PiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSS1ELUFubm91bmNl IG1haWxpbmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJhZnQgZGly ZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3INCj4gZnRwOi8vZnRw LmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJ UHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5p c3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0K From internet-drafts@ietf.org Sat Jan 19 05:37:15 2013 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 6225321F861A; Sat, 19 Jan 2013 05:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 x9+2mF3Vzf3Z; Sat, 19 Jan 2013 05:37:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D680321F862E; Sat, 19 Jan 2013 05:37:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-udpzero-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130119133714.7010.1622.idtracker@ietfa.amsl.com> Date: Sat, 19 Jan 2013 05:37:14 -0800 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, 19 Jan 2013 13:37:15 -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 : Applicability Statement for the use of IPv6 UDP Datagram= s with Zero Checksums Author(s) : Godred Fairhurst Magnus Westerlund Filename : draft-ietf-6man-udpzero-09.txt Pages : 37 Date : 2013-01-19 Abstract: This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations and examines the role of the IPv6 UDP transport checksum. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that updates use of the UDP checksum with IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-udpzero-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-udpzero-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From achatz@forthnetgroup.gr Sat Jan 19 14:50:22 2013 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 5071821F8722 for ; Sat, 19 Jan 2013 14:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.641 X-Spam-Level: X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 tFH85eaVQATp for ; Sat, 19 Jan 2013 14:50:21 -0800 (PST) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8FE21F86D5 for ; Sat, 19 Jan 2013 14:50:17 -0800 (PST) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0JMoFNF004760; Sun, 20 Jan 2013 00:50:15 +0200 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0JMoFDw012386; Sun, 20 Jan 2013 00:50:15 +0200 Received: from [192.168.1.2] (178.128.180.208.dsl.dyn.forthnet.gr [178.128.180.208]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0JMo4mx029807; Sun, 20 Jan 2013 00:50:05 +0200 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <50FB2316.2050703@forthnetgroup.gr> Date: Sun, 20 Jan 2013 00:49:58 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15 MIME-Version: 1.0 To: Fernando Gont , ipv6@ietf.org Subject: Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-02.txt References: <20121230011537.2800.39239.idtracker@ietfa.amsl.com> <50DF964A.5000504@si6networks.com> <50EFD855.6070203@gont.com.ar> <50F83ECA.8030803@si6networks.com> In-Reply-To: <50F83ECA.8030803@si6networks.com> X-Enigmail-Version: 1.5 Content-Type: text/html; charset=UTF-8 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: Sat, 19 Jan 2013 22:50:22 -0000
Hi Fernando,

I would like to make some last comments about your draft, which i fully support.

First of all, i would like to see a reference to cases where the prefix doesn't change too often (since this is recommended by many people for various deployments, i.e. residential dsl) due to mostly renumbering issues. In this case, Privacy Extensions seem to offer an advantage in terms of host tracking.

Also, it would be good to include some examples of IIDs produced by an implementation of the proposed algorithm, taking into account various scenarios with common parameters.

Lastly, in a comment i had made back in March 2012 regarding your draft and source address selection, and now looking at current rfc6724 i can see the following:

   Rule 7: Prefer temporary addresses.
   If SA is a temporary address and SB is a public address, then prefer
   SA.  Similarly, if SB is a temporary address and SA is a public
   address, then prefer SB.

Although the implementations must provide a mechanism allowing an application to reverse this, if the above is the default behavior meaning that if privacy extensions are enabled, temporary addresses will have preference over your stable addresses, then i think the following 2 paragraphs don't apply anymore in your draft. Please correct me if i'm wrong.

On the other hand, in scenarios in which "Privacy
   Extensions" are employed, implementation of the mechanism described
   in this document would mitigate host-scanning attacks and also
   mitigate correlation of host activities.

On the other hand, in the case of hosts employing "Privacy
   Extensions", the method specified in this document would prevent host
   scanning attacks and correlation of node activities across networks
   (see Appendix A).



...and some editorial comments...

The resulting interface identifiers remain constant/stable for
      each prefix used with SLAAC within each subnet.  That is, the
      algorithm generates the same interface identifier when configuring
      an address belonging to the same prefix within the same subnet.
within the same subnet. => within the same subnet (assuming parameters defined in Section 3 remain the same).

 2.  The Interface Identifier is finally obtained by taking the
       leftmost 64 bits of the RID value computed in the previous step,
       and and setting bit 6 (the leftmost bit is numbered 0) to zero.
and and => and


The resulting Interface
       Identifier should be compared against a list of reserved
       interface identifiers and to those already employed in an address
       of the same network interface and the same network prefix.  In
       the event that an unacceptable identifier has been generated,
       this situation should be handled in the same way as the case of
       duplicate addresses
employed in an address of the same network interface and the same network prefix = > employed in an address of another host through the same local network interface and using the same network prefix
In the event that an unacceptable identifier has been generated => In the event that such an identifier has been generated

Also if "a list of reserved identifiers" refers to http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml, then it should probably be "the list of...".
Unless, we assume everyone is allowed to use its own list of reserved identifiers.

In the event that a DAD conflict cannot be solved (possibly after
   trying a number of different addresses), address configuration would
   fail.  In those scenarios, nodes MUST NOT automatically fall back to
   employing other algorithms for generating interface identifiers.
Shouldn't an error message be logged somewhere?

This document does not require the use of any specific PRF for the
   function F() above, since the choice of such PRF is usually a trade-
   off between a number of properties (processing requirements, ease of
   implementation, possible intellectual property rights, etc.), and
   since the best possible choice for F() might be different for
   different types of devices (e.g. embedded systems vs. regular
   servers) and might possibly change over time.
and might possibly change over time => it might possibly change over time 

since it would mitigate host-
   tracking vectors still present when privacy addresses are used
   (Appendix A,
(Appendix A, => (Appendix A), 


--
Tassos
Fernando Gont wrote on 17/1/2013 20:11:
Folks,

Is the I-D ready to ship?

It has been weeks since I posted the last rev. My understanding is that
this I-D is ready to ship (after the clarifications I made on-list, and
the tweaks I made to the I-D). But if there's any remaining bit, I'd
like to know. But if the RTTs for these exchanges get so long, it's
becomes even harder to follow the discussions.

I'm aware that there are folks working on implementations of this I-D,
and it'd be great to progress this I-D sooner than later.

Thanks!

Best regards,
Fernando




On 01/11/2013 06:16 AM, Fernando Gont wrote:

Bob & Ole,

Ping?

Thanks,
Fernando




On 12/29/2012 10:18 PM, Fernando Gont wrote:

Folks,

I've rev'ed the document according to our recent email exchange.

Should we ship the document now?

Thanks, and have a Happy New Year!

Best regards,
Fernando




On 12/29/2012 10:15 PM, 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           : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)
	Author(s)       : Fernando Gont
	Filename        : draft-ietf-6man-stable-privacy-addresses-02.txt
	Pages           : 18
	Date            : 2012-12-29

Abstract:
   This document specifies a method for generating IPv6 Interface
   Identifiers to be used with IPv6 Stateless Address Autoconfiguration
   (SLAAC), such that addresses configured using this method are stable
   within each subnet, but the Interface Identifier changes when hosts
   move from one network to another.  The aforementioned method is meant
   to be an alternative to generating Interface Identifiers based on
   IEEE identifiers, such that the benefits of stable addresses can be
   achieved without sacrificing the privacy of users.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-02


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 fgont@si6networks.com Sat Jan 19 17:01:22 2013 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 1BBCC21F846B for ; Sat, 19 Jan 2013 17:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 wQalXCBOXIQe for ; Sat, 19 Jan 2013 17:01:21 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id BA06521F8442 for ; Sat, 19 Jan 2013 17:01:20 -0800 (PST) Received: from [186.134.7.196] (helo=[192.168.123.121]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TwjHI-0003c7-PA; Sun, 20 Jan 2013 02:00:53 +0100 Message-ID: <50FB41B9.3060404@si6networks.com> Date: Sat, 19 Jan 2013 22:00:41 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Tassos Chatzithomaoglou Subject: Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-02.txt References: <20121230011537.2800.39239.idtracker@ietfa.amsl.com> <50DF964A.5000504@si6networks.com> <50EFD855.6070203@gont.com.ar> <50F83ECA.8030803@si6networks.com> <50FB2316.2050703@forthnetgroup.gr> In-Reply-To: <50FB2316.2050703@forthnetgroup.gr> X-Enigmail-Version: 1.4.6 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: Sun, 20 Jan 2013 01:01:22 -0000 Hi, Tassos, On 01/19/2013 07:49 PM, Tassos Chatzithomaoglou wrote: > > First of all, i would like to see a reference to cases where the prefix > doesn't change too often (since this is recommended by many people for > various deployments, i.e. residential dsl) due to mostly renumbering > issues. In this case, Privacy Extensions seem to offer an advantage in > terms of host tracking. This document notes that for the most part, stable-privacy-addresses are orthogonal to temporary addresses. That aside, the main issue with host tracking is when a host moves from one network to another. If you talk about correlation of host activities within the same network, then the benefits may be debatable. e.g., if you have a single host behind a router, then the use of privacy addresses makes no differences. > Also, it would be good to include some examples of IIDs produced by an > implementation of the proposed algorithm, taking into account various > scenarios with common parameters. You mean something like what's in slide 21 of ? > Lastly, in a comment i had made back in March 2012 regarding your draft > and source address selection, and now looking at current rfc6724 i can > see the following: > > Rule 7: Prefer temporary addresses. > If SA is a temporary address and SB is a public address, then prefer > SA. Similarly, if SB is a temporary address and SA is a public > address, then prefer SB. > > Although the implementations must provide a mechanism allowing an > application to reverse this, if the above is the default behavior > meaning that if privacy extensions are enabled, temporary addresses will > have preference over your stable addresses, then i think the following 2 > paragraphs don't apply anymore in your draft. Please correct me if i'm > wrong. > > On the other hand, in scenarios in which "Privacy > Extensions" are employed, implementation of the mechanism described > in this document would mitigate host-scanning attacks and also > mitigate correlation of host activities. They would mitigate host-scanning because they eliminate the remaining predictable addresses. OTOH, they would mitigate host-tracking, since they eliminate IIDs that are constant across networks. > On the other hand, in the case of hosts employing "Privacy > Extensions", the method specified in this document would prevent host > scanning attacks For this one, same as above. > and correlation of node activities across networks > (see Appendix A ). This is correct. If anything, the only thing that might still be possible is correlation of activities of hosts that belong to the same network. However, as noted above, it is debatable the extent to which privacy addresses help in this area (please see the corresponding references in the I-D). > ...and some editorial comments... > > The resulting interface identifiers remain constant/stable for > each prefix used with SLAAC within each subnet. That is, the > algorithm generates the same interface identifier when configuring > an address belonging to the same prefix within the same subnet. > > within the same subnet. => within the same subnet (assuming parameters > defined in Section 3 remain the same). Should we really make this explicit? --If you change the network parameters (prefix and/or network_id), you can probably argue that, from a "logical" point of view, it's a different network. > 2. The Interface Identifier is finally obtained by taking the > leftmost 64 bits of the RID value computed in the previous step, > and and setting bit 6 (the leftmost bit is numbered 0) to zero. > > and and => and Good grief! - Fixed! > The resulting Interface > Identifier should be compared against a list of reserved > interface identifiers and to those already employed in an address > of the same network interface and the same network prefix. In > the event that an unacceptable identifier has been generated, > this situation should be handled in the same way as the case of > duplicate addresses > > employed in an address of the same network interface and the same > network prefix = > employed in an address of another host through the > same local network interface and using the same network prefix No. This is the job of DAD. > Also if "a list of reserved identifiers" refers to > http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml, > then it should probably be "the list of...". Really good point. I will add a reference to this registry. Thanks! > Unless, we assume everyone is allowed to use its own list of reserved > identifiers. > > In the event that a DAD conflict cannot be solved (possibly after > trying a number of different addresses), address configuration would > fail. In those scenarios, nodes MUST NOT automatically fall back to > employing other algorithms for generating interface identifiers. > > Shouldn't an error message be logged somewhere? I wouldn't oppose to this -- however, this is probably "out of scope", since DAD failures should also be logged when they happen for addresses generated with other algorithms. (i.e., IMHO, this requirement should be in a DAD specification, rather than here). > This document does not require the use of any specific PRF for the > function F() above, since the choice of such PRF is usually a trade- > off between a number of properties (processing requirements, ease of > implementation, possible intellectual property rights, etc.), and > since the best possible choice for F() might be different for > different types of devices (e.g. embedded systems vs. regular > servers) and might possibly change over time. > > and might possibly change over time => it might possibly change over time Isn't the subject implicit? > > since it would mitigate host- > tracking vectors still present when privacy addresses are used > (Appendix A, > > (Appendix A, => (Appendix A), Fixed. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From achatz@forthnetgroup.gr Sun Jan 20 02:15:58 2013 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 EAAB521F8505 for ; Sun, 20 Jan 2013 02:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[AWL=0.979, 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 mKfl1iJAtl6F for ; Sun, 20 Jan 2013 02:15:57 -0800 (PST) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7E88021F84F0 for ; Sun, 20 Jan 2013 02:15:56 -0800 (PST) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0KAFtdd027055; Sun, 20 Jan 2013 12:15:55 +0200 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0KAFtd3016326; Sun, 20 Jan 2013 12:15:55 +0200 Received: from [192.168.1.2] (178.128.174.19.dsl.dyn.forthnet.gr [178.128.174.19]) (authenticated bits=0) by MX-IN-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id r0KAFqU9009355; Sun, 20 Jan 2013 12:15:54 +0200 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <50FBC3D8.20603@forthnetgroup.gr> Date: Sun, 20 Jan 2013 12:15:52 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 SeaMonkey/2.15 MIME-Version: 1.0 To: Fernando Gont Subject: Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-02.txt References: <20121230011537.2800.39239.idtracker@ietfa.amsl.com> <50DF964A.5000504@si6networks.com> <50EFD855.6070203@gont.com.ar> <50F83ECA.8030803@si6networks.com> <50FB2316.2050703@forthnetgroup.gr> <50FB41B9.3060404@si6networks.com> In-Reply-To: <50FB41B9.3060404@si6networks.com> X-Enigmail-Version: 1.5 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: Sun, 20 Jan 2013 10:15:59 -0000 Fernando Gont wrote on 20/1/2013 03:00: > Hi, Tassos, > > On 01/19/2013 07:49 PM, Tassos Chatzithomaoglou wrote: >> First of all, i would like to see a reference to cases where the prefix >> doesn't change too often (since this is recommended by many people for >> various deployments, i.e. residential dsl) due to mostly renumbering >> issues. In this case, Privacy Extensions seem to offer an advantage in >> terms of host tracking. > This document notes that for the most part, stable-privacy-addresses are > orthogonal to temporary addresses. > > That aside, the main issue with host tracking is when a host moves from > one network to another. If you talk about correlation of host activities > within the same network, then the benefits may be debatable. e.g., if > you have a single host behind a router, then the use of privacy > addresses makes no differences. > > Can you please elaborate more on the last sentence? I can have 2 (or more) hosts within the same network, each one belonging to a different person/floor/family/etc. With temporary addresses i cannot (easily) track each one, while with stable addresses i can. >> Also, it would be good to include some examples of IIDs produced by an >> implementation of the proposed algorithm, taking into account various >> scenarios with common parameters. > You mean something like what's in slide 21 of > ? > If i understand correctly, those are EUI-64 IIDs. I was hoping to include some stable IIDs like the ones generated by the described algorithm, for various combinations of parameters (prefixes, networks, etc). >> Lastly, in a comment i had made back in March 2012 regarding your draft >> and source address selection, and now looking at current rfc6724 i can >> see the following: >> >> Rule 7: Prefer temporary addresses. >> If SA is a temporary address and SB is a public address, then prefer >> SA. Similarly, if SB is a temporary address and SA is a public >> address, then prefer SB. >> >> Although the implementations must provide a mechanism allowing an >> application to reverse this, if the above is the default behavior >> meaning that if privacy extensions are enabled, temporary addresses will >> have preference over your stable addresses, then i think the following 2 >> paragraphs don't apply anymore in your draft. Please correct me if i'm >> wrong. >> >> On the other hand, in scenarios in which "Privacy >> Extensions" are employed, implementation of the mechanism described >> in this document would mitigate host-scanning attacks and also >> mitigate correlation of host activities. > They would mitigate host-scanning because they eliminate the remaining > predictable addresses. OTOH, they would mitigate host-tracking, since > they eliminate IIDs that are constant across networks. > > >> On the other hand, in the case of hosts employing "Privacy >> Extensions", the method specified in this document would prevent host >> scanning attacks > For this one, same as above. > >> and correlation of node activities across networks >> (see Appendix A ). > This is correct. If anything, the only thing that might still be > possible is correlation of activities of hosts that belong to the same > network. However, as noted above, it is debatable the extent to which > privacy addresses help in this area (please see the corresponding > references in the I-D). > I see you already describe that in your doc, so i'm ok. > >> ...and some editorial comments... >> >> The resulting interface identifiers remain constant/stable for >> each prefix used with SLAAC within each subnet. That is, the >> algorithm generates the same interface identifier when configuring >> an address belonging to the same prefix within the same subnet. >> >> within the same subnet. => within the same subnet (assuming parameters >> defined in Section 3 remain the same). > Should we really make this explicit? --If you change the network > parameters (prefix and/or network_id), you can probably argue that, from > a "logical" point of view, it's a different network. > > What happens if i reboot/power-off-on the host or if i manually change the secret key? > >> The resulting Interface >> Identifier should be compared against a list of reserved >> interface identifiers and to those already employed in an address >> of the same network interface and the same network prefix. In >> the event that an unacceptable identifier has been generated, >> this situation should be handled in the same way as the case of >> duplicate addresses >> >> employed in an address of the same network interface and the same >> network prefix = > employed in an address of another host through the >> same local network interface and using the same network prefix > No. This is the job of DAD. > The way it's written, i seems like you expect to have the same host generate more than one stable IIDs for the same interface/prefix. If that's the case, then i don't think DAD will have any effect, unless a multicast loop-back is in effect. And in that case, DAD doesn't consider this a duplicate address. >> Unless, we assume everyone is allowed to use its own list of reserved >> identifiers. >> >> In the event that a DAD conflict cannot be solved (possibly after >> trying a number of different addresses), address configuration would >> fail. In those scenarios, nodes MUST NOT automatically fall back to >> employing other algorithms for generating interface identifiers. >> >> Shouldn't an error message be logged somewhere? > I wouldn't oppose to this -- however, this is probably "out of scope", > since DAD failures should also be logged when they happen for addresses > generated with other algorithms. (i.e., IMHO, this requirement should > be in a DAD specification, rather than here). > > Agree (DAD already logs this). >> This document does not require the use of any specific PRF for the >> function F() above, since the choice of such PRF is usually a trade- >> off between a number of properties (processing requirements, ease of >> implementation, possible intellectual property rights, etc.), and >> since the best possible choice for F() might be different for >> different types of devices (e.g. embedded systems vs. regular >> servers) and might possibly change over time. >> >> and might possibly change over time => it might possibly change over time > Isn't the subject implicit? > Ok. Thanks, Tassos From internet-drafts@ietf.org Mon Jan 21 05:37:16 2013 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 0A04F21F8600; Mon, 21 Jan 2013 05:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=-0.130, 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 bNx-zSKEnDFB; Mon, 21 Jan 2013 05:37:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F69D21F867E; Mon, 21 Jan 2013 05:37:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-udpzero-10.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130121133715.25231.27592.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2013 05:37:15 -0800 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, 21 Jan 2013 13:37: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 : Applicability Statement for the use of IPv6 UDP Datagram= s with Zero Checksums Author(s) : Godred Fairhurst Magnus Westerlund Filename : draft-ietf-6man-udpzero-10.txt Pages : 38 Date : 2013-01-21 Abstract: This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations and examines the role of the IPv6 UDP transport checksum. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that updates use of the UDP checksum with IPv6. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-udpzero There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-6man-udpzero-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-udpzero-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gorry@erg.abdn.ac.uk Mon Jan 21 05:55:26 2013 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 E518921F84A1 for ; Mon, 21 Jan 2013 05:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.34 X-Spam-Level: X-Spam-Status: No, score=-102.34 tagged_above=-999 required=5 tests=[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 OCmBkmLfRlUV for ; Mon, 21 Jan 2013 05:55:26 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 174A621F8487 for <6man@ietf.org>; Mon, 21 Jan 2013 05:55:23 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 1C6C52B4438; Mon, 21 Jan 2013 13:55:22 +0000 (GMT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 187EA2B4278; Mon, 21 Jan 2013 13:55:20 +0000 (GMT) Message-ID: <50FD48C7.1060409@erg.abdn.ac.uk> Date: Mon, 21 Jan 2013 13:55:19 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: 6man@ietf.org Subject: Re: New Version Notification for draft-ietf-6man-udpzero-10.txt References: <20130121133715.25231.596.idtracker@ietfa.amsl.com> In-Reply-To: <20130121133715.25231.596.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 21 Jan 2013 06:57:35 -0800 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 13:55:27 -0000 Magnus and I updated the draft below to align this revision to the work on the related RFC 2460 update. Note of apology - I submitted an interim (rev-09) over the weekend with an unintended merging of bullets 5,6,7 in section 5. This revision -10 corrects this, by reapplying my edits to rev -08 for this section. A diff of the latest rev with rev -08 used in the LC is available here: http://www.erg.abdn.ac.uk/~gorry/ietf/draft-ietf-6man-diff-08-10.html We think this includes the work needed for this draft after the Last Call. Best wishes, Gorry & Magnus On 21/01/2013 13:37, internet-drafts@ietf.org wrote: > > A new version of I-D, draft-ietf-6man-udpzero-10.txt > has been successfully submitted by Godred Fairhurst and posted to the > IETF repository. > > Filename: draft-ietf-6man-udpzero > Revision: 10 > Title: Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums > Creation date: 2013-01-21 > WG ID: 6man > Number of pages: 38 > URL: http://www.ietf.org/internet-drafts/draft-ietf-6man-udpzero-10.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero > Htmlized: http://tools.ietf.org/html/draft-ietf-6man-udpzero-10 > Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-udpzero-10 > > Abstract: > This document provides an applicability statement for the use of UDP > transport checksums with IPv6. It defines recommendations and > requirements for the use of IPv6 UDP datagrams with a zero UDP > checksum. It describes the issues and design principles that need to > be considered when UDP is used with IPv6 to support tunnel > encapsulations and examines the role of the IPv6 UDP transport > checksum. An appendix presents a summary of the trade-offs that were > considered in evaluating the safety of the update to RFC 2460 that > updates use of the UDP checksum with IPv6. > > > > > The IETF Secretariat > From despres.remi@laposte.net Mon Jan 21 08:19:50 2013 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 EA63A21F8475 for ; Mon, 21 Jan 2013 08:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 0kM5y7L0t5Vh for ; Mon, 21 Jan 2013 08:19:50 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id C4D5821F8444 for ; Mon, 21 Jan 2013 08:19:49 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id 097AB700016D; Mon, 21 Jan 2013 17:19:48 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2421.sfr.fr (SMTP Server) with ESMTP id B598B7000178; Mon, 21 Jan 2013 17:19:47 +0100 (CET) X-SFR-UUID: 20130121161947743.B598B7000178@msfrf2421.sfr.fr From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= Subject: 4rd IID range & IPv6 addressing architecture Date: Mon, 21 Jan 2013 17:19:49 +0100 Message-Id: To: Bob Hinden Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 6man 6man-wg 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, 21 Jan 2013 16:19:51 -0000 Hi, Bob, The discussion on whether the proposed 4rd IID range is "compatible with = the IPv6 addressing architecture" has apparently come to a standstill. Yet an answer of 6man to Softwire is expected. A. To help making a WG decision, here are key points that, in my = understanding, emerged from the discussion. (a) Ray Hunter has provided a reference to RFC5342 which confirms that, = in RFC 4291 compliant addresses, u=3Dg=3D1 is "currently unused" = (www.ietf.org/mail-archive/web/ipv6/current/msg16890.html). 4rd = addresses, which have u=3Dg=3D1, therefore cannot conflict with current = addresses of the IPv6 addressing architecture. (In particular, they = don't conflict with those of RFC6740 ILNP.) (b) Brian Carpenter pointed out that a 16-bit prefix would be sufficient = for 4rd, taking less IID space than the currently proposed 8-bit prefix. = This being acknowledged, the 0x0300 prefix can without problem replace = the 0x03 prefix. (This doesn't change the 4rd specification which = already has a 0x00 after 0x03.) With this prefix, the reserved range = uses only 1/2^14 of the unused set of IIDs having u=3Dg=3D1 is reserved. = This leaves plenty of space for future uses of IIDs having u=3D1 (future = uses explicitly envisaged in RFC 4291).=20 (c) Jouni Korhonen pointed out that there is already an IANA registry = for reserved IID ranges, and Simon Perreault gave the correct pointer to = it = (http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xml= ). (d) Suresh Krishnan pointed out that, according to RFC 5453, this = registry is so far reserved for standard-track RFCs, the reason being = "to minimize disruption to existing implementations". Although 4rd has = been purposely designed so that it cannot disturb any existing = implementation (precisely by using a currently unused IID range), the = proposed 4rd range can be endorsed by IANA only if an RFC updates RFC = 5453, explaining why a 4rd IID range can be safely assigned despite its = experimental status.=20 - If agreed on the principle, and if no one else volunteers, I can be = available to propose a draft to this effect. (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of = IIDs having u=3Dg=3D1 is reserved. This leaves plenty of space for = future uses of IIDs having u=3D1, as explicitly expected in RFC 4291.=20 =20 With this, 6man can IMHO answer that Softwire can proceed with 4rd, = provided: - the 16-bit IID prefix 0x0300 replaces the current 0x03 - it is understood that IANA won't register this IID range before a 6man = RFC permits it for this experimental-track RFC. =20 No technically founded objection remains AFAIK, but if any one still = holds it has of course to be expressed and discussed. B. For those who are interested in a detailed summary of objections that = were made, and have been answered, here is what I noted: (i) If IETF uses u=3Dg=3D1 in some unicast addresses, IEEE would have to = be involved.=20 - Because 4rd IIDs are never to be used in any MAC-layer addresses. IEEE = isn't concerned. (j) 4rd could work without a reserved range. - As discussed in Softwire, reserving an IID range is key to satisfy the = objective that "4rd IPv6 addresses are recognizable by CEs without any = interference with the choice of subnet prefixes in CE sites". (k) An IID range using the IANA OUI with u=3D1 and g=3D0 would have been = sufficient. - As discussed in Softwire, this wouldn't have left enough IID bits to = contain the IPv4 address and the 16-bit CNP, which are both needed in = 4rd. (l) A 4rd-specific destination header could have been used instead of an = IID-range. - An extra header would have defeated the 4rd objective that its = "tunnel packets are valid IPv6 packets for all layer-4 protocols that = use the same checksum algorithm as TCP". (m) With a "reserved /64 on the customers delegated prefix for the sole = use of 4rd",and 4rd nodes protecting "all possible 4rd interface-ids = using DAD", a reserved range could have been avoided. - This wouldn't work for IID assignments made before 4rd activation, = while 4rd is designed to cover this case too. (Note also that 4rd = implementations can add, on their LAN sides, exclusion of all addresses = having the 4rd IID prefix. Although this isn't strictly needed, this can = permit early detection of some erroneous manual configurations, and is = easy to do due to the 4rd IID prefix being a constant. (n) 4rd would fail if a customer link has two 4rd CEs. - After discussion, no issue on this has been kept in Softwire. Best regards, RD From ietf@rozanak.com Mon Jan 21 15:56:38 2013 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 A27DB21F8853; Mon, 21 Jan 2013 15:56:38 -0800 (PST) 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 rYUna4YRuzZS; Mon, 21 Jan 2013 15:56:38 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3CF21F884C; Mon, 21 Jan 2013 15:56:38 -0800 (PST) Received: from kopoli (g225040193.adsl.alicedsl.de [92.225.40.193]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LmK8A-1TOede3lOE-00ZGkh; Mon, 21 Jan 2013 18:56:34 -0500 From: "Hosnieh Rafiee" To: "Ray Hunter" , "'Duncan, Richard \(Jeremy\)'" , "Fernando Gont" , "'Al-Sadeh, Ahmad'" , "Roque Gagliano \(rogaglia\)" Subject: Call for comments on draft-rafiee-6man-ssas-01.txt Date: Tue, 22 Jan 2013 00:56:20 +0100 Message-ID: <000101cdf832$ef9b5480$ced1fd80$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac34Mm/A07P7NjLJTCeC5Jyh13oWOQ== Content-Language: en-us X-Provags-ID: V02:K0:193UQz0g5JUVYzdnRWWwmMB0RNWDFMfWcvl8OXvzW6Q hry2C+rOBHaGQzXuy51Q2EWoHtZafYgjEnwykTEjOufnneUk9x wlNGVwukb18Wc9zb/b7iT/2vRmGKaWPCA/WlABFVblCAkZjoCD 7TGpVMMqMmfw7AyMIqrGCAPoVqfDlF4jxzWFAR7q5S7RWPU+5f EL1jACiV7NrhVMjB/2FrY45C8x9lM//458pAOB2fbvpgnr2U67 wfXVvqgfnMn2IEWl3/lbSdUQF6VNJ0HYuNG0Usgd+72nNGjRfu IEnvpp23YA7wX6smyB4sQqk/oLY8ceERW/okruIfYoNDUgmQB3 hs1WwL3AIwAdA5h+wM9I= Cc: cga-ext@ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 23:56:38 -0000 Dear all, I have considered your comments and updated our draft rfc accordingly. = Feel free to add further comments. Thank you, Hosnieh Filename: draft-rafiee-6man-ssas Revision: 01 Title: A Simple Secure Addressing Generation Scheme for IPv6 = AutoConfiguration (SSAS) Creation date: 2013-01-21 WG ID: Individual Submission Number of pages: 15 URL: = http://www.ietf.org/internet-drafts/draft-rafiee-6man-ssas-01.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-6man-ssas Htmlized: http://tools.ietf.org/html/draft-rafiee-6man-ssas-01 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-rafiee-6man-ssas-01 Abstract: The default method for IPv6 address generation uses a organitionally unique identifier assigned by the IEEE Standards Association and the extension identifier by the hardware manufacturer [1] (section 2.5.1 RFC-4291) [RFC4291]. This means that a node will always have the same Interface ID (IID) whenever it connects to a new network. Because the node's IP address does not change, the node is vulnerable to privacy related attacks. To address this issue, there are currently two mechanisms in use to randomize the IID, Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy Extension [RFC4941]. The problem with the former approach is the computational cost involved for the IID generation and verification. The problem with the latter approach is that it lacks security and offers only partial protection to the node against privacy related attacks. This document offers a new algorithm for use in the generation of the IID while, at the same time, securing the node against some types of attack, like IP spoofing. These attacks are prevented by the addition of a signature to the messages sent over the network and by directly using a public key in the IP address. = =20 The IETF Secretariat From fgont@si6networks.com Mon Jan 21 17:29:58 2013 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 F0ADE21F848B for ; Mon, 21 Jan 2013 17:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 rJUDnH8mdyYs for ; Mon, 21 Jan 2013 17:29:58 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id F2EAA21F8450 for ; Mon, 21 Jan 2013 17:29:57 -0800 (PST) Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TxSg0-0006wN-Lg; Tue, 22 Jan 2013 02:29:25 +0100 Message-ID: <50FCC0FC.708@si6networks.com> Date: Mon, 21 Jan 2013 01:15:56 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Tassos Chatzithomaoglou Subject: Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-02.txt References: <20121230011537.2800.39239.idtracker@ietfa.amsl.com> <50DF964A.5000504@si6networks.com> <50EFD855.6070203@gont.com.ar> <50F83ECA.8030803@si6networks.com> <50FB2316.2050703@forthnetgroup.gr> <50FB41B9.3060404@si6networks.com> <50FBC3D8.20603@forthnetgroup.gr> In-Reply-To: <50FBC3D8.20603@forthnetgroup.gr> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 01:29:59 -0000 Hi, Tassos, On 01/20/2013 07:15 AM, Tassos Chatzithomaoglou wrote: >> On 01/19/2013 07:49 PM, Tassos Chatzithomaoglou wrote: >>> First of all, i would like to see a reference to cases where the prefix >>> doesn't change too often (since this is recommended by many people for >>> various deployments, i.e. residential dsl) due to mostly renumbering >>> issues. In this case, Privacy Extensions seem to offer an advantage in >>> terms of host tracking. >> This document notes that for the most part, stable-privacy-addresses are >> orthogonal to temporary addresses. >> >> That aside, the main issue with host tracking is when a host moves from >> one network to another. If you talk about correlation of host activities >> within the same network, then the benefits may be debatable. e.g., if >> you have a single host behind a router, then the use of privacy >> addresses makes no differences. >> > Can you please elaborate more on the last sentence? > I can have 2 (or more) hosts within the same network, each one belonging to a different > person/floor/family/etc. With temporary addresses i cannot (easily) track each one, while > with stable addresses i can. Simple example: let's say there are two hosts within a subnet, and that the lifetime of each temp address is 10 hours. Let's say that Host 1 was bootstrapped at time=0h, while Host 2 was bootstrapped at time=5hs. Let's say that at time=5h: Host 1: 2001:db8::1 Host 2: 2001:db8::5 Let's say that at time 10h, I start seeing the following addresses: 2001:db8::7 2001:db8::5 (i.e., one of the addresses is the same, and there's a new address) It wouldn't be hard to infer that 2001:db8::7 (i.e., Host 1 has changed its temp address). >>> Also, it would be good to include some examples of IIDs produced by an >>> implementation of the proposed algorithm, taking into account various >>> scenarios with common parameters. >> You mean something like what's in slide 21 of >> ? >> > If i understand correctly, those are EUI-64 IIDs. Note: EUI-64 != MAC address. draft-ietf6man-stable-privacy-addresses is said to generate Modified EUI64-format addresses, because it sets the global/local unicast/multicast bits as appropriate. > I was hoping to include some stable IIDs like the ones generated by the described > algorithm, for various combinations of parameters (prefixes, networks, etc). They are going to be random, so... except for the example I referenced above (in the slideware), I'm not sure how they'd be of help. (the example from the slideware tries to illustrate that addresses are constant within a subnet, but *not* across networks). >>> ...and some editorial comments... >>> >>> The resulting interface identifiers remain constant/stable for >>> each prefix used with SLAAC within each subnet. That is, the >>> algorithm generates the same interface identifier when configuring >>> an address belonging to the same prefix within the same subnet. >>> >>> within the same subnet. => within the same subnet (assuming parameters >>> defined in Section 3 remain the same). >> Should we really make this explicit? --If you change the network >> parameters (prefix and/or network_id), you can probably argue that, from >> a "logical" point of view, it's a different network. >> > What happens if i reboot/power-off-on the host or if i manually change the secret key? The secret is supposed to be constant. So it should be stored in non-volatile memory (i.e., nothing special would happen across reboots). OTOH, if you manually change the secret, of course the corresponding addresses would change. For instance, that's why two hosts (employing the same OS) would generate different addresses: because they will employ different secrets. >>> The resulting Interface >>> Identifier should be compared against a list of reserved >>> interface identifiers and to those already employed in an address >>> of the same network interface and the same network prefix. In >>> the event that an unacceptable identifier has been generated, >>> this situation should be handled in the same way as the case of >>> duplicate addresses >>> >>> employed in an address of the same network interface and the same >>> network prefix = > employed in an address of another host through the >>> same local network interface and using the same network prefix >> No. This is the job of DAD. >> > The way it's written, i seems like you expect to have the same host generate more than one > stable IIDs for the same interface/prefix. No. I just consider the case that the host might be using e.g. temporary addresses. Simply put, the aforementioned text is meant to catch cases in which the algorithm generated an IID that is already in use, or that is reserved. However, the case of *addresses* that are duplicate is handled by DAD -- since that's part of SLAAC itself. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From mohamed.boucadair@orange.com Tue Jan 22 00:47:31 2013 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 B145F21F8780 for ; Tue, 22 Jan 2013 00:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 rK8FKsqYNpRa for ; Tue, 22 Jan 2013 00:47:30 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 194AB21F8775 for ; Tue, 22 Jan 2013 00:47:29 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7B2E018C27D; Tue, 22 Jan 2013 09:47:28 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D75332380AC; Tue, 22 Jan 2013 09:47:27 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Tue, 22 Jan 2013 09:47:27 +0100 From: To: Tina TSOU , "ipv6@ietf.org" Date: Tue, 22 Jan 2013 09:47:26 +0100 Subject: RE: draft-boucadair-6man-multicast-addr-arch-update-00 Thread-Topic: draft-boucadair-6man-multicast-addr-arch-update-00 Thread-Index: Ac3z4u1053StVGtNRLeZmhwqb5q3XgAFedOAAEK3xeAA3gSUgA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EA71A6871@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EA601E4BC@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: Stig Venaas 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, 22 Jan 2013 08:47:31 -0000 RGVhciBUaW5hLA0KDQpUaGFuayB5b3UgZm9yIHJldmlld2luZyB0aGUgZHJhZnQgYW5kIGZvciB5 b3VyIHN1cHBvcnQuIA0KDQpUaGUgZHJhZnQgZG9lcyBvbmx5IGV4dGVuZCB0aGUgZGVmaW5pdGlv biBvZiBhbHJlYWR5IHJlc2VydmVkIGJpdHMgdG8gYmUgYWxzbyB0cmVhdGVkIGFzIGZsYWdzLiBJ biBhZGRpdGlvbiwgdGhlIGRyYWZ0IHByb3ZpZGVzIHNvbWUgY2xhcmlmaWNhdGlvbnMgZm9yIHRo ZSB1c2Ugb2YgZmxhZyBiaXRzIChpbmNsdWRpbmcgYm90aCB0aGUgb2xkIGFuZCB0aGUgZXh0ZW5k ZWQgb25lcykuIFRoZSByZWNvbW1lbmRhdGlvbiBza2V0Y2hlZCBpbiB0aGUgZHJhZnQgYXBwbGll cyBmb3IgYWxsIGZsYWcgYml0cyAoaW5jbHVkaW5nIHRoZSBuZXdseSBkZWZpbmVkIG9uZXMpLiBB cyBzdWNoLCB3ZSBkb24ndCBzZWUgdGhlIG5lZWQgdG8gdXNlIGEgZGlmZmVyZW50IG5hbWUgdG8g cmVmZXIgdG8gdGhlIG5ld2x5IGRlZmluZWQgZmxhZyBiaXRzLiANCg0KUGxlYXNlIGxldCBtZSBr bm93IGlmIHRoaXMgYW5zd2VycyB0byB5b3VyIGNvbmNlcm4gYWJvdXQgdGhlIG5hbWUuIA0KDQpD aGVlcnMsDQpNZWQgIA0KDQo+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+RGUgOiBUaW5h IFRTT1UgW21haWx0bzpUaW5hLlRzb3UuWm91dGluZ0BodWF3ZWkuY29tXSANCj5FbnZvecOpIDog amV1ZGkgMTcgamFudmllciAyMDEzIDIzOjQzDQo+w4AgOiBCT1VDQURBSVIgTW9oYW1lZCBPTE5D L09MTjsgaXB2NkBpZXRmLm9yZw0KPkNjIDogU3RpZyBWZW5hYXMNCj5PYmpldCA6IFJFOiBkcmFm dC1ib3VjYWRhaXItNm1hbi1tdWx0aWNhc3QtYWRkci1hcmNoLXVwZGF0ZS0wMA0KPg0KPkRlYXIg TWVkIGFuZCBTdGlnLA0KPkkgdGVjaG5pY2FsbHkgc3VwcG9ydCB0aGlzIGRyYWZ0Lg0KPlRoZSBu ZXdseSBkZWZpbmVkIGZsZ3MgZmllbGQgaGFzIHRoZSBzYW1lIGZpZWxkIG5hbWUgaW4gb2xkIA0K PkFkZHJlc3NpbmcgQXJjaGl0ZWN0dXJlLiBJIHdvdWxkIHN1Z2dlc3QgcmVuYW1pbmcgbmV3bHkg DQo+ZGVmaW5lZCBmbGdzIGZpZWxkLg0KPg0KPlRoYW5rIHlvdSwNCj5UaW5hDQo+DQo+DQo+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogaXB2Ni1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSANCj5PbiBCZWhhbGYgT2YNCj4+IG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4+IFNlbnQ6IDIwMTPlubQx5pyIMTbml6UgNjo1NA0K Pj4gVG86IGlwdjZAaWV0Zi5vcmcNCj4+IENjOiBCcmlhbiBIYWJlcm1hbjsgU3RpZyBWZW5hYXMN Cj4+IFN1YmplY3Q6IGRyYWZ0LWJvdWNhZGFpci02bWFuLW11bHRpY2FzdC1hZGRyLWFyY2gtdXBk YXRlLTAwDQo+PiANCj4+IERlYXIgYWxsLA0KPj4gDQo+PiBXZSBzdWJtaXR0ZWQgdGhpcyBzaG9y dCBkcmFmdCB0byB1cGRhdGUgc29tZSBleGlzdGluZyBJUHY2IA0KPm11bHRpY2FzdCBSRkNzOw0K Pj4gZXNwZWNpYWxseSB0byBleHRlbmQgdGhlIGRlZmluaXRpb24gb2Ygc29tZSByZXNlcnZlZCBi aXRzLg0KPj4gDQo+PiBDb21tZW50cyBhcmUgbW9yZSB0aGFuIHdlbGNvbWUuDQo+PiANCj4+IENo ZWVycywNCj4+IE1lZA0KPj4gDQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+IERl IDogaS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmcgDQo+W21haWx0bzppLWQtYW5ub3VuY2Ut Ym91bmNlc0BpZXRmLm9yZ10NCj4+IERlIGxhIHBhcnQgZGUgaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIEVudm95w6kgOiBtZXJjcmVkaSAxNiANCj5qYW52aWVyIDIwMTMNCj4+IDEzOjEzIMOAIDog aS1kLWFubm91bmNlQGlldGYub3JnIE9iamV0IDogSS1EIEFjdGlvbjogDQo+ZHJhZnQtYm91Y2Fk YWlyLTZtYW4tDQo+PiBtdWx0aWNhc3QtYWRkci1hcmNoLXVwZGF0ZS0wMC50eHQNCj4+IA0KPj4g DQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ bnRlcm5ldC1EcmFmdHMNCj4+IGRpcmVjdG9yaWVzLg0KPj4gDQo+PiANCj4+IAlUaXRsZSAgICAg ICAgICAgOiBVcGRhdGVzIHRvIHRoZSBJUHY2IE11bHRpY2FzdCBBZGRyZXNzaW5nDQo+PiBBcmNo aXRlY3R1cmUNCj4+IAlBdXRob3IocykgICAgICAgOiBNb2hhbWVkIEJvdWNhZGFpcg0KPj4gICAg ICAgICAgICAgICAgICAgICAgICAgICBTdGlnIFZlbmFhcw0KPj4gCUZpbGVuYW1lICAgICAgICA6 IA0KPmRyYWZ0LWJvdWNhZGFpci02bWFuLW11bHRpY2FzdC1hZGRyLWFyY2gtdXBkYXRlLQ0KPj4g MDAudHh0DQo+PiAJUGFnZXMgICAgICAgICAgIDogNQ0KPj4gCURhdGUgICAgICAgICAgICA6IDIw MTMtMDEtMTYNCj4+IA0KPj4gQWJzdHJhY3Q6DQo+PiAgICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMg dGhlIElQdjYgbXVsdGljYXN0IGFkZHJlc3NpbmcgDQo+YXJjaGl0ZWN0dXJlIGJ5DQo+PiAgICBk ZWZpbmluZyB0aGUgMTctMjAgcmVzZXJ2ZWQgYml0cyBhcyBnZW5lcmljIGZsYWcgYml0cy4gIA0K PlRoZSBkb2N1bWVudA0KPj4gICAgcHJvdmlkZXMgYWxzbyBzb21lIGNsYXJpZmljYXRpb25zIHJl bGF0ZWQgdG8gdGhlIHVzZSBvZiB0aGVzZSBmbGFnDQo+PiAgICBiaXRzLg0KPj4gDQo+PiAgICBU aGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDIDM5NTYsIFJGQyAzMzA2LCBSRkMgNDYwNyBhbmQgUkZD IDQyOTEuDQo+PiANCj4+IA0KPj4gDQo+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWJvdWNhZGFpci02bWFuLW11bHRpY2FzdC1hZGRyLQ0KPj4gYXJjaC11cGRhdGUNCj4+ IA0KPj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+PiBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItNm1hbi1tdWx0aWNhc3Qt YWRkci1hcmNoLQ0KPj4gdXBkYXRlLTAwDQo+PiANCj4+IA0KPj4gSW50ZXJuZXQtRHJhZnRzIGFy ZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4gZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4+IEkt RC1Bbm5vdW5jZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pLWQtYW5ub3VuY2UNCj4+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8v d3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yDQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8x c2hhZG93LXNpdGVzLnR4dA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IElFVEYgSVB2NiB3b3JraW5nIGdy b3VwIG1haWxpbmcgbGlzdA0KPj4gaXB2NkBpZXRmLm9yZw0KPj4gQWRtaW5pc3RyYXRpdmUgUmVx dWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4= From Tina.Tsou.Zouting@huawei.com Tue Jan 22 09:27:50 2013 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 0D19D21F87FF for ; Tue, 22 Jan 2013 09:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTMOl1Z+ngHc for ; Tue, 22 Jan 2013 09:27:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C585D21F87B2 for ; Tue, 22 Jan 2013 09:27:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANT87986; Tue, 22 Jan 2013 17:27:46 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 22 Jan 2013 17:27:35 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 22 Jan 2013 17:27:45 +0000 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.4]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.007; Tue, 22 Jan 2013 09:27:39 -0800 From: Tina TSOU To: "mohamed.boucadair@orange.com" Subject: Re: draft-boucadair-6man-multicast-addr-arch-update-00 Thread-Topic: draft-boucadair-6man-multicast-addr-arch-update-00 Thread-Index: Ac3z4u1053StVGtNRLeZmhwqb5q3XgAFedOAAEK3xeAA3gSUgAASf//f Date: Tue, 22 Jan 2013 17:27:37 +0000 Message-ID: <8D9194A8-EF11-4239-BD51-19D6344159D5@huawei.com> References: <94C682931C08B048B7A8645303FDC9F36EA601E4BC@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36EA71A6871@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EA71A6871@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipv6@ietf.org" , Stig Venaas 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, 22 Jan 2013 17:27:50 -0000 RGVhciBNZWQsDQpPSywgdGhhdCBhbnN3ZXJzIG15IGNvbmNlcm4uDQoNClRoYW5rIHlvdSwNClRp bmENCg0KT24gSmFuIDIyLCAyMDEzLCBhdCAxMjo0NyBBTSwgIm1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20iIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCg0KPiBEZWFy IFRpbmEsDQo+IA0KPiBUaGFuayB5b3UgZm9yIHJldmlld2luZyB0aGUgZHJhZnQgYW5kIGZvciB5 b3VyIHN1cHBvcnQuIA0KPiANCj4gVGhlIGRyYWZ0IGRvZXMgb25seSBleHRlbmQgdGhlIGRlZmlu aXRpb24gb2YgYWxyZWFkeSByZXNlcnZlZCBiaXRzIHRvIGJlIGFsc28gdHJlYXRlZCBhcyBmbGFn cy4gSW4gYWRkaXRpb24sIHRoZSBkcmFmdCBwcm92aWRlcyBzb21lIGNsYXJpZmljYXRpb25zIGZv ciB0aGUgdXNlIG9mIGZsYWcgYml0cyAoaW5jbHVkaW5nIGJvdGggdGhlIG9sZCBhbmQgdGhlIGV4 dGVuZGVkIG9uZXMpLiBUaGUgcmVjb21tZW5kYXRpb24gc2tldGNoZWQgaW4gdGhlIGRyYWZ0IGFw cGxpZXMgZm9yIGFsbCBmbGFnIGJpdHMgKGluY2x1ZGluZyB0aGUgbmV3bHkgZGVmaW5lZCBvbmVz KS4gQXMgc3VjaCwgd2UgZG9uJ3Qgc2VlIHRoZSBuZWVkIHRvIHVzZSBhIGRpZmZlcmVudCBuYW1l IHRvIHJlZmVyIHRvIHRoZSBuZXdseSBkZWZpbmVkIGZsYWcgYml0cy4gDQo+IA0KPiBQbGVhc2Ug bGV0IG1lIGtub3cgaWYgdGhpcyBhbnN3ZXJzIHRvIHlvdXIgY29uY2VybiBhYm91dCB0aGUgbmFt ZS4gDQo+IA0KPiBDaGVlcnMsDQo+IE1lZCAgDQo+IA0KPj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2lu ZS0tLS0tDQo+PiBEZSA6IFRpbmEgVFNPVSBbbWFpbHRvOlRpbmEuVHNvdS5ab3V0aW5nQGh1YXdl aS5jb21dIA0KPj4gRW52b3nDqSA6IGpldWRpIDE3IGphbnZpZXIgMjAxMyAyMzo0Mw0KPj4gw4Ag OiBCT1VDQURBSVIgTW9oYW1lZCBPTE5DL09MTjsgaXB2NkBpZXRmLm9yZw0KPj4gQ2MgOiBTdGln IFZlbmFhcw0KPj4gT2JqZXQgOiBSRTogZHJhZnQtYm91Y2FkYWlyLTZtYW4tbXVsdGljYXN0LWFk ZHItYXJjaC11cGRhdGUtMDANCj4+IA0KPj4gRGVhciBNZWQgYW5kIFN0aWcsDQo+PiBJIHRlY2hu aWNhbGx5IHN1cHBvcnQgdGhpcyBkcmFmdC4NCj4+IFRoZSBuZXdseSBkZWZpbmVkIGZsZ3MgZmll bGQgaGFzIHRoZSBzYW1lIGZpZWxkIG5hbWUgaW4gb2xkIA0KPj4gQWRkcmVzc2luZyBBcmNoaXRl Y3R1cmUuIEkgd291bGQgc3VnZ2VzdCByZW5hbWluZyBuZXdseSANCj4+IGRlZmluZWQgZmxncyBm aWVsZC4NCj4+IA0KPj4gVGhhbmsgeW91LA0KPj4gVGluYQ0KPj4gDQo+PiANCj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IGlwdjYtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gDQo+PiBPbiBCZWhhbGYgT2YNCj4+PiBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tDQo+Pj4gU2VudDogMjAxM+W5tDHmnIgxNuaXpSA2OjU0DQo+ Pj4gVG86IGlwdjZAaWV0Zi5vcmcNCj4+PiBDYzogQnJpYW4gSGFiZXJtYW47IFN0aWcgVmVuYWFz DQo+Pj4gU3ViamVjdDogZHJhZnQtYm91Y2FkYWlyLTZtYW4tbXVsdGljYXN0LWFkZHItYXJjaC11 cGRhdGUtMDANCj4+PiANCj4+PiBEZWFyIGFsbCwNCj4+PiANCj4+PiBXZSBzdWJtaXR0ZWQgdGhp cyBzaG9ydCBkcmFmdCB0byB1cGRhdGUgc29tZSBleGlzdGluZyBJUHY2IA0KPj4gbXVsdGljYXN0 IFJGQ3M7DQo+Pj4gZXNwZWNpYWxseSB0byBleHRlbmQgdGhlIGRlZmluaXRpb24gb2Ygc29tZSBy ZXNlcnZlZCBiaXRzLg0KPj4+IA0KPj4+IENvbW1lbnRzIGFyZSBtb3JlIHRoYW4gd2VsY29tZS4N Cj4+PiANCj4+PiBDaGVlcnMsDQo+Pj4gTWVkDQo+Pj4gDQo+Pj4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+Pj4gRGUgOiBpLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZyANCj4+IFtt YWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddDQo+Pj4gRGUgbGEgcGFydCBkZSBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgRW52b3nDqSA6IG1lcmNyZWRpIDE2IA0KPj4gamFudmll ciAyMDEzDQo+Pj4gMTM6MTMgw4AgOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcgT2JqZXQgOiBJLUQg QWN0aW9uOiANCj4+IGRyYWZ0LWJvdWNhZGFpci02bWFuLQ0KPj4+IG11bHRpY2FzdC1hZGRyLWFy Y2gtdXBkYXRlLTAwLnR4dA0KPj4+IA0KPj4+IA0KPj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj4+IGRpcmVjdG9y aWVzLg0KPj4+IA0KPj4+IA0KPj4+ICAgIFRpdGxlICAgICAgICAgICA6IFVwZGF0ZXMgdG8gdGhl IElQdjYgTXVsdGljYXN0IEFkZHJlc3NpbmcNCj4+PiBBcmNoaXRlY3R1cmUNCj4+PiAgICBBdXRo b3IocykgICAgICAgOiBNb2hhbWVkIEJvdWNhZGFpcg0KPj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICBTdGlnIFZlbmFhcw0KPj4+ICAgIEZpbGVuYW1lICAgICAgICA6IA0KPj4gZHJhZnQtYm91 Y2FkYWlyLTZtYW4tbXVsdGljYXN0LWFkZHItYXJjaC11cGRhdGUtDQo+Pj4gMDAudHh0DQo+Pj4g ICAgUGFnZXMgICAgICAgICAgIDogNQ0KPj4+ICAgIERhdGUgICAgICAgICAgICA6IDIwMTMtMDEt MTYNCj4+PiANCj4+PiBBYnN0cmFjdDoNCj4+PiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyB0aGUg SVB2NiBtdWx0aWNhc3QgYWRkcmVzc2luZyANCj4+IGFyY2hpdGVjdHVyZSBieQ0KPj4+ICAgZGVm aW5pbmcgdGhlIDE3LTIwIHJlc2VydmVkIGJpdHMgYXMgZ2VuZXJpYyBmbGFnIGJpdHMuICANCj4+ IFRoZSBkb2N1bWVudA0KPj4+ICAgcHJvdmlkZXMgYWxzbyBzb21lIGNsYXJpZmljYXRpb25zIHJl bGF0ZWQgdG8gdGhlIHVzZSBvZiB0aGVzZSBmbGFnDQo+Pj4gICBiaXRzLg0KPj4+IA0KPj4+ICAg VGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQyAzOTU2LCBSRkMgMzMwNiwgUkZDIDQ2MDcgYW5kIFJG QyA0MjkxLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWJvdWNhZGFpci02bWFuLW11bHRpY2FzdC1hZGRyLQ0KPj4+IGFyY2gtdXBk YXRlDQo+Pj4gDQo+Pj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUg YXQ6DQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91Y2FkYWlyLTZtYW4t bXVsdGljYXN0LWFkZHItYXJjaC0NCj4+PiB1cGRhdGUtMDANCj4+PiANCj4+PiANCj4+PiBJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+Pj4g ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+PiANCj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEktRC1Bbm5vdW5jZSBt YWlsaW5nIGxpc3QNCj4+PiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPj4+IEludGVybmV0LURyYWZ0 IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yDQo+Pj4gZnRw Oi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4+IGlwdjZAaWV0Zi5v cmcNCj4+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHY2DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From pkern@simplex.0x539.de Wed Jan 23 13:06:01 2013 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 E121B21F8807 for ; Wed, 23 Jan 2013 13:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 tEOTaDporTRZ for ; Wed, 23 Jan 2013 13:06:01 -0800 (PST) Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 584B621F8804 for ; Wed, 23 Jan 2013 13:06:00 -0800 (PST) Received: from hub.kern.lc ([2a01:4f8:101:2fff:2:0:ffff:1]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Ty7WA-0000L9-6j for ipv6@ietf.org; Wed, 23 Jan 2013 22:05:58 +0100 Received: from [2001:470:720c:0:7d97:28ce:9b3f:a4c9] (helo=simplex.lan.home.philkern.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Ty7WB-0004ly-0y for ipv6@ietf.org; Wed, 23 Jan 2013 22:05:59 +0100 Received: from pkern by simplex.lan.home.philkern.de with local (Exim 4.80) (envelope-from ) id 1Ty7W9-0003js-VJ for ipv6@ietf.org; Wed, 23 Jan 2013 22:05:58 +0100 Date: Wed, 23 Jan 2013 22:05:57 +0100 From: Philipp Kern To: ipv6@ietf.org Subject: RFC6724/RFC3484bis: Destination selection not considering well-known NAT64 prefix Message-ID: <20130123210557.GA10474@simplex.0x539.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt" Content-Disposition: inline Organization: 0x539 dev group User-Agent: Mutt/1.5.21 (2010-09-15) 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, 23 Jan 2013 21:19:09 -0000 --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, was it a deliberate ommission that RFC6724 does not mention a precedence value for the well-known NAT64 prefix 64:ff9b::/96? If a host has both IPv4 and IPv6 configured it should probably use the native IPv4 connectivity to connect to the target instead of the translated IPv6-to-IPv4 access. Especially if the DNS64 server is adding AAAA records unconditionally because it cannot know if the client is actually dual stack. Neither should the client be forced to resort to IPv4 for DNS resolution to make this clear. RFC6146 specifying both NAT64 and its well-known prefix is also on the Standards Track, so it seems fair that it should be incorporated into a RFC6724bis, I think. Kind regards Philipp Kern --pf9I7BMVVzbSWLtt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJRAFC1AAoJEERuJUU10FbsXCEIAKCfgBPR+16y1WlTsdB7ueQt O+0wp/QI/gu15fuHQxvAhV5OfsS8THSQ+NbaSQSYbOedIqpf6A++k5gHOP7+6djc C4l6vBDv8n4hhbnN7Wb1m3tbk7JcOcWWx3LcXnexfsqHucd4jv9yYTJbY6qoBtnx Ixd1GdDrtq6IA8CqZ8JdOZF/PGsbj43CfdJjbRszzh3MxWNTMYYxCwzM/2gSDu+4 BfF2ENTjycpva5TdaDzaPb/M9uZSjdwfMXPn0kFGPSELmiWCvxFtiL6I2FPiuyex 5IlWm0/i2rJDKIMdbC/GGtzNK6CnfgjUeuRSfwAvRkHlNDQNKbDXOjdE78Bta6Y= =iS5b -----END PGP SIGNATURE----- --pf9I7BMVVzbSWLtt-- From allison.mankin@gmail.com Wed Jan 23 16:33:09 2013 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 7BB6521F8514; Wed, 23 Jan 2013 16:33:09 -0800 (PST) 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, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, NO_RELAYS=-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 fUaCyM34Ilna; Wed, 23 Jan 2013 16:33:08 -0800 (PST) Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 44A8A21F84E6; Wed, 23 Jan 2013 16:33:07 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id ds1so3117wgb.4 for ; Wed, 23 Jan 2013 16:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=oOSJIe4Zj5NhP7YIEeJskF2y/E6qqjM1SAYnfQHb0+g=; b=hp7hBPfqizDe0QCYlkQoQhJDW9t1O0eISF2NPVBCf9Zle77yvFkznAmPUVJHd8VXpY pZGVNrHnO7t9nRPDog+IViB+Gq0oUOys30IhcCrggwtTqDcqUOITG/5Foe8pYQTog/8e bKvens1f0h4GFGXQm+hfrFLlL3P/bf5lxylYq4MnmQoq6Nuzlz9tx1N2waZKyFYw6oMt cUt55DdBYrZ746C+koC4jXcYOMJJX4cer3BnJmJ9/Hh4NGAsIo6vSQEAngFhQ8Rj6Rbp PObIBgVhKauCtPMSMfyo7Tfy3HsVj7K55AAA+FIsbPz9MboVmiS9DqkcQZV6/Wpr4QRF bp9w== MIME-Version: 1.0 X-Received: by 10.194.20.231 with SMTP id q7mr55939wje.44.1358987586383; Wed, 23 Jan 2013 16:33:06 -0800 (PST) Received: by 10.217.80.2 with HTTP; Wed, 23 Jan 2013 16:33:06 -0800 (PST) Date: Wed, 23 Jan 2013 19:33:06 -0500 Message-ID: Subject: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03 From: Allison Mankin To: IETF Discuss Content-Type: multipart/alternative; boundary=047d7b451208572fd404d3fdf429 X-Mailman-Approved-At: Wed, 23 Jan 2013 22:00:37 -0800 Cc: 6man@ietf.org, Transport Area , Allison Mankin , Transport Directorate 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, 24 Jan 2013 00:33:09 -0000 --047d7b451208572fd404d3fdf429 Content-Type: text/plain; charset=ISO-8859-1 Transport Directorate review of https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. Please always CC tsv-dir@ietf.org if you reply to or forward this review. Summary ------------- This draft is on the right track but has issues, described in the review, that call for a bigger picture. In addition to reading the draft, I read over the documents it references, and I also read through the AD Review thread about the 02 version of the draft, on the 6man mailing list. It is clearly valuable to call the community's attention to the "atomic fragment" in IPv6. This is an IPv6 datagram that is not actually fragmented, but has a Fragmentation Header (with an offset of 0 and the M bit set to 0). It seems the atomic fragment in IPv6 arose to accommodate translation gateways with MTUs of less than 1280 (the IPv6 minimum) on the IPv4 side [1]. The problem is that you can force a sender to generate atomic fragments instead of normal packets from an off-path node, if the sender doesn't filter ICMPv6 much. I've tried to make a schematic of the problem and solution described by the draft. A is the IPv6 sender that either does not or cannot filter incoming ICMPv6 very well and that chooses Fragmentation IDs in a predictable way when it must fragment. E is a blind attacker (or collaborating blind attackers), not on path/in the middle for A. B is the destination for A's traffic. B initially doesn't distinguish between atomic fragments and normal fragments. However, B has implemented another solution [2], RFC 5722, which requires that IPv6 fragments be dropped silently if they overlap (have the same IDs and carry material from the same offset+fragment length). ORIGINAL ATTACK --------------------------- T0 A to B: v6-dgram ---> T1 E to A: ICMPv6 Too Big (MTU<1280) T2 A to B: switch to v6-atomic-fragment, ID=X, Offset=0 T3 E to B: blind-inserted overlapping v6-fragment, ID=X, Offset=0 T4 B: A's T2 data should have gotten through. But E's T3 fragment forces silent drop. DRAFT'S SOLUTION ----------------------------- The draft says that B MUST process atomic fragments "in isolation", not in relation to the fragment queue. Further discussion in next section. T'0-T'3: same as T0-T3 above. T'4 B: receive and process A's atomic fragment, with no regard to E's insertion. RESIDUAL RISK? ------------------------- In the AD Review thread, Brian Haberman asks the "WG if the solution actually creates an attack vector on receiving hosts." A roll-up of the several-message exchange between Haberman and Fernando Gont, the draft author, can be found in http://www.ietf.org/mail-archive/web/ipv6/current/msg16807.html. From a Transport point of view, I agree that there could be a new attack vector on the receivers. Consider first that E successfully got a spoofed fragment onto B's fragment queue. What if E turns that fragment into an atomic fragment. Post-mitigation, E's datagram no longer causes A's datagram to be blocked, but does the processing of E's atomic fragment "in isolation" introduce a greater chance than before that E's datagram can pass from B successfully to the ULP? It depends on what processing an atomic fragment "in isolation" means specifically. The draft says this: A host that receives an IPv6 packet which includes a Fragment Header with the "Fragment Offset" equal to 0 and the "M" bit equal to 0 MUST process such packet in isolation from any other packets/ fragments, even if such packets/fragments contain the same set {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}. A received "atomic fragments" should be "reassembled" from the contents of that sole fragment. And this: Additionally, if any fragments with the same set {IPV6 Source Address, IPv6 Destination Address, Fragment Identification} are present in the fragment reassembly queue when the atomic fragment is received, such fragments MUST NOT be discarded upon receipt of the "colliding" IPv6 atomic fragment, since IPv6 atomic fragments MUST NOT interfere with "normal" fragmented traffic. So now a receiver is forced to process an atomic datagram even if there are overlapping fragments already there on the fragmentation queue. NEW ATTACK VECTOR --------------------------------- T"0 A to B: v6-dgram ---> T"1 E to A: ICMPv6 Too Big (MTU<1280) T"2 A to B: switch to v6-atomic-fragment, ID=X, Offset=0 T"2a B: deliver A's datagram to ULP T"3 E to B: blind-inserted overlapping v6-atomic-fragment, ID=X, Offset=0 T"3a B: deliver E's overlapping datagram to ULP T"4: B: TCP attack mitigated by RFC 5722 looks possible again [see Note 3]. Conclusion --------------- There's an interesting table in the draft showing which sending stacks can be tricked into switching to v6-atomic-fragments and which receiving ones can be tricked into dropping them due to fragment overlap. Another way of looking at this table is that a lot of stacks need to be less predictable and more suspicious of spoofing traffic. The present draft is pragmatic/empirical and is interested in fixing a problem that exists (it can be brought on). But I wonder if it would be better to embed the discussion of atomic fragments and fragment overlap in a larger picture, a collected set of best practices against spoofers (of ICMPv6, of IPv6 fragments or otherwise). In the larger context, I agree that what's in this draft has a part - on its own, not sure it stands. Notes --------- [1] (Digression) I'd love to call for a Law of Kludges that says that if you are gatewaying two protocols, the one that is older should always be the one that graciously accepts the kludges; I'm not deeply enough into this all to understand why the gateway's IPv4 side needs the IPv6 side to supply it with a Fragmentation header - why it couldn't create fragments into IPv4 independent of the original IPv6? [2] To a point problem... [3] In RFC 5722, the crux of why B has to drop overlapping IPv6 fragments is these paragraphs: The TCP header has the following values of the flags: S(YN)=1 and A(CK)=1. This may make an inspecting stateful firewall think that it is a response packet for a connection request initiated from the trusted side of the firewall. Hence, it will allow the fragment to pass. It will also allow the following fragments with the same Fragment Identification value in the fragment header to pass through. A malicious node can form a second fragment with a TCP header that changes the flags and sets S(YN)=1 and A(CK)=0. This can change the packet on the receiving end to consider the packet as a connection request instead of a response. By doing this, the malicious node has bypassed the firewall's access control to initiate a connection request to a node protected by a firewall. --047d7b451208572fd404d3fdf429 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Transport Directorate review of https://datatrack= er.ietf.org/doc/draft-ietf-6man-ipv6-atomic-fragments

I've r= eviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised.=A0 Please always CC tsv-dir@ietf.org if you=20 reply to or forward this review.

Summary
-------------
This draft is on the right track but ha= s issues, described in the review, that call for a bigger picture.

I= n addition to reading the draft, I read over the documents it references, a= nd I also read through the AD Review thread about the 02 version of the dra= ft, on the 6man mailing list.

It is clearly valuable to call the community's attention to the &qu= ot;atomic fragment" in IPv6.=A0 This is an IPv6 datagram that is not a= ctually fragmented, but has a Fragmentation Header (with an offset of 0 and= the M bit set to 0).=A0 It seems the atomic fragment in IPv6 arose to acco= mmodate translation gateways with MTUs of less than 1280 (the IPv6 minimum)= on the IPv4 side [1].=A0 The problem is that you can force a sender to gen= erate atomic fragments instead of normal packets from an off-path node, if = the sender doesn't filter ICMPv6 much.=A0

I've tried to make a schematic of the problem and solution describe= d by the draft.

A is the IPv6 sender that either does not or cannot= filter incoming ICMPv6 very well and that chooses Fragmentation IDs in a p= redictable way when it must fragment.

E is a blind attacker (or collaborating blind attackers), not on path/i= n the middle for A.

B is the destination for A's traffic.=A0 B = initially doesn't distinguish between atomic fragments and normal fragm= ents.=A0 However, B has implemented another solution [2], RFC 5722, which r= equires that IPv6 fragments be dropped silently if they overlap (have the s= ame IDs and carry material from the same offset+fragment length).

ORIGINAL ATTACK
---------------------------
=A0
T0=A0=A0 A to= B: =A0=A0 v6-dgram --->

T1=A0 E to A:=A0=A0=A0 ICMPv6 Too Big (= MTU<1280)

T2=A0 A to B:=A0=A0=A0=A0 switch to v6-atomic-fragment,= ID=3DX, Offset=3D0

T3=A0 E to B:=A0=A0=A0=A0 blind-inserted overlap= ping v6-fragment, ID=3DX, Offset=3D0

T4=A0 B:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A's T2 data should hav= e gotten through.=A0 But E's T3 fragment forces silent drop.=A0
DRAFT'S SOLUTION
-----------------------------
The draft says th= at B MUST process atomic fragments "in isolation", not in relatio= n to the fragment queue.=A0 Further discussion in next section.

T'0-T'3:=A0=A0=A0=A0=A0=A0=A0=A0=A0 same as T0-T3 above.
T'4 B:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 receive and process A's= atomic fragment, with no regard to E's insertion.

RESIDUAL RISK= ?
-------------------------
In the AD Review thread, Brian Haberman a= sks the "WG=A0 if the solution actually creates an attack vector on re= ceiving hosts." A roll-up of the several-message exchange between Habe= rman and Fernando Gont, the draft author, can be found in http://www.ietf.= org/mail-archive/web/ipv6/current/msg16807.html.=A0=A0 From a Transport= point of view, I agree that there could be a new attack vector on the rece= ivers.

Consider first that E successfully got a spoofed fragment onto B's = fragment queue.=A0 What if E turns that fragment into an atomic fragment. P= ost-mitigation, E's datagram no longer causes A's datagram to be bl= ocked, but does the processing of E's atomic fragment "in isolatio= n" introduce a greater chance than before that E's datagram can pa= ss from B successfully to the ULP?=A0

It depends on what processing an atomic fragment "in isolation&quo= t; means specifically.=A0 The draft says this:

      A host that receives an IPv6 packet which includes a Fragment
      Header with the "Fragment Offset" equal to 0 and the "=
M" bit equal
      to 0 MUST process such packet in isolation from any other packets/
      fragments, even if such packets/fragments contain the same set
      {IPv6 Source Address, IPv6 Destination Address, Fragment
      Identification}.  A received "atomic fragments" should be
      "reassembled" from the contents of that sole fragment.
<=
/pre>And this:
      Additionally, if any fragmen=
ts with the same set {IPV6 Source
      Address, IPv6 Destination Address, Fragment Identification} are
      present in the fragment reassembly queue when the atomic fragment
      is received, such fragments MUST NOT be discarded upon receipt of
      the "colliding" IPv6 atomic fragment, since IPv6 atomic fra=
gments
      MUST NOT interfere with "normal" fragmented traffic.
<=
br>So now a receiver is forced to process an atomic datagram even if there =
are overlapping fragments already there on the fragmentation queue.=A0 


NEW ATTACK VECTOR
---------------------------------
T"0=A0=
=A0 A to B: =A0=A0 v6-dgram ---> 

T"1=A0 E to A:=A0=A0=A0 IC=
MPv6 Too Big (MTU<1280)

T"2=A0 A to B:=A0=A0=A0=A0 switch to=
 v6-atomic-fragment, ID=3DX, Offset=3D0

T"2a B:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 deliver A's datagram to ULP =


T"3=A0 E to B:=A0=A0=A0=A0 blind-inserted overlapping v6-atomi=
c-fragment, ID=3DX, Offset=3D0
T"3a B: =A0 =A0 =A0 =A0 =A0 deliver =
E's overlapping datagram to ULP


T"4:=A0 B: =A0 =A0 =A0 =A0 =A0 TCP attack mitigated by RFC 5722 looks =
possible again [see Note 3].=A0 

Conclusion
--------------- 
T=
here's an interesting table in the draft showing which sending stacks c=
an be tricked into switching to v6-atomic-fragments and which receiving one=
s can be tricked into dropping them due to fragment overlap.=A0 Another way=
 of looking at this table is that a lot of stacks need to be less predictab=
le and more suspicious of spoofing traffic.=A0 The present draft is pragmat=
ic/empirical and is interested in fixing a problem that exists (it can be b=
rought on).=A0 But I wonder if it would be better to embed the discussion o=
f atomic fragments and fragment overlap in a larger picture, a collected se=
t of best practices against spoofers (of ICMPv6, of IPv6 fragments or other=
wise).=A0 In the larger context, I agree that what's in this draft has =
a part - on its own, not sure it stands.=A0 


Notes
---------
[1] (Digression) I'd love to call for a Law o=
f Kludges that says that if you are=20
gatewaying two protocols, the one that is older should always be the one
 that graciously accepts the kludges; I'm not deeply enough into this=
=20
all to understand why the gateway's IPv4 side needs the IPv6 side to=20
supply it with a Fragmentation header - why it couldn't create fragment=
s into=20
IPv4 independent of the original IPv6? 

[2] To a point problem...
[3] In RFC 5722, the crux of why B has to drop overlapping IPv6 fragme=
nts is these paragraphs:
   The TCP header has the following values=
 of the flags: S(YN)=3D1 and
   A(CK)=3D1.  This may make an inspecting stateful firewall think that it
   is a response packet for a connection request initiated from the
   trusted side of the firewall.  Hence, it will allow the fragment to
   pass.  It will also allow the following fragments with the same
   Fragment Identification value in the fragment header to pass through.

   A malicious node can form a second fragment with a TCP header that
   changes the flags and sets S(YN)=3D1 and A(CK)=3D0.  This can change the
   packet on the receiving end to consider the packet as a connection
   request instead of a response.  By doing this, the malicious node has
   bypassed the firewall's access control to initiate a connection
   request to a node protected by a firewall.




--047d7b451208572fd404d3fdf429--

From fgont@si6networks.com  Wed Jan 23 22:58:46 2013
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 ABCF721F8834; Wed, 23 Jan 2013 22:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.051
X-Spam-Level: 
X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_21=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 7LzeFZnAJJRJ; Wed, 23 Jan 2013 22:58:46 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 654C521F8843; Wed, 23 Jan 2013 22:58:28 -0800 (PST)
Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TyGlQ-00046C-D8; Thu, 24 Jan 2013 07:58:22 +0100
Message-ID: <5100DB84.6060000@si6networks.com>
Date: Thu, 24 Jan 2013 03:58:12 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Allison Mankin 
Subject: Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
References: 
In-Reply-To: 
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 23 Jan 2013 23:24:28 -0800
Cc: 6man@ietf.org, Transport Area , IETF Discuss , Transport Directorate 
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, 24 Jan 2013 06:58:46 -0000

Hi, Allison,

Thanks so much for your feedback! -- Please find my comments in-line....

On 01/23/2013 09:33 PM, Allison Mankin wrote:
> It is clearly valuable to call the community's attention to the "atomic
> fragment" in IPv6.  This is an IPv6 datagram that is not actually
> fragmented, but has a Fragmentation Header (with an offset of 0 and the
> M bit set to 0).  It seems the atomic fragment in IPv6 arose to
> accommodate translation gateways with MTUs of less than 1280 (the IPv6
> minimum) on the IPv4 side [1].  The problem is that you can force a
> sender to generate atomic fragments instead of normal packets from an
> off-path node, if the sender doesn't filter ICMPv6 much. 

Note:

1) It's not a problem at all if you process atomic fragments as indicated.

2) You cannot filter ICMPv6 as appropriate: The ICMPv6 payload can
always contain less information than needed to validate the ICMP error
messages.



> A is the IPv6 sender that either does not or cannot filter incoming
> ICMPv6 very well and that chooses Fragmentation IDs in a predictable way
> when it must fragment.
> 
> E is a blind attacker (or collaborating blind attackers), not on path/in
> the middle for A.
> 
> B is the destination for A's traffic.  B initially doesn't distinguish
> between atomic fragments and normal fragments.  However, B has
> implemented another solution [2], RFC 5722, which requires that IPv6
> fragments be dropped silently if they overlap (have the same IDs and
> carry material from the same offset+fragment length).

FWIW, RFC5722 is a solution to the "firewall evasion by overlapping
fragments", but in this case can be of help for DoS purposes.


> 
> ORIGINAL ATTACK
> ---------------------------
[....]

FWIW, the scenario you sketched is 100% correct.



> RESIDUAL RISK?
> -------------------------
[....]
> So now a receiver is forced to process an atomic datagram even if there
> are overlapping fragments already there on the fragmentation queue. 
> 
> NEW ATTACK VECTOR
> ---------------------------------
> T"0   A to B:    v6-dgram --->
> 
> T"1  E to A:    ICMPv6 Too Big (MTU<1280)
> 
> T"2  A to B:     switch to v6-atomic-fragment, ID=X, Offset=0
> T"2a B:           deliver A's datagram to ULP
> 
> T"3  E to B:     blind-inserted overlapping v6-atomic-fragment, ID=X,
> Offset=0
> T"3a B:           deliver E's overlapping datagram to ULP
> 
> T"4:  B:           TCP attack mitigated by RFC 5722 looks possible again
> [see Note 3]. 

I fail to see why this scenario could be seen as an example of an attack
RFC 5722 avoids.

Simply put, what draft-ietf-6man-ipv6-atomic-fragments-03 says is: "an
atomic fragment is not really a fragment, but rather a complete packet
that just happens to have a Frag Header -- hence, process it as such".

RFC 5722 is meant to prevent attacks in which you can fool a firewall by
sending overlapping fragments: the fragment allows the first fragment,
but then a second fragment (which looks harmless) overwrites the initial
fragment such that the reassembled packet becomes an "attack packet".

Atomic fragments do not fall in that category: A firewall has all the
knowledge it needs to decide whether to filter (or not) what's in the
atomic fragment. And if the firewall allowed the atomic fragment, that's
exactly how the fragment is going t be delivered to the ULP.



> Conclusion
> ---------------
> There's an interesting table in the draft showing which sending stacks
> can be tricked into switching to v6-atomic-fragments and which receiving
> ones can be tricked into dropping them due to fragment overlap.  Another
> way of looking at this table is that a lot of stacks need to be less
> predictable and more suspicious of spoofing traffic.  The present draft
> is pragmatic/empirical and is interested in fixing a problem that exists
> (it can be brought on).  But I wonder if it would be better to embed the
> discussion of atomic fragments and fragment overlap in a larger picture,
> a collected set of best practices against spoofers (of ICMPv6, of IPv6
> fragments or otherwise).

In this particular case, there's a specific standard that needs to be
updated, and existing software relying on the feature (atomic fragments)
that we're improving.

I'm not sure what kind of document you have in mind... but my personal
experience says that being able to tackle isolated problems separately
(rather than work on a large document that tries to address a plethora
of issues) is (by far) more doable.

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 simon.perreault@viagenie.ca  Thu Jan 24 01:49:16 2013
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 16D6A21F8589 for ; Thu, 24 Jan 2013 01:49:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 DcC0gbOsL8Yq for ; Thu, 24 Jan 2013 01:49:15 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB1321F8584 for ; Thu, 24 Jan 2013 01:49:15 -0800 (PST)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4008:ad5e:13e3:3f75:3e52]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DD4714042E for ; Thu, 24 Jan 2013 04:49:14 -0500 (EST)
Message-ID: <510103CC.1020709@viagenie.ca>
Date: Thu, 24 Jan 2013 10:50:04 +0100
From: Simon Perreault 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: RFC6724/RFC3484bis: Destination selection not considering well-known NAT64 prefix
References: <20130123210557.GA10474@simplex.0x539.de>
In-Reply-To: <20130123210557.GA10474@simplex.0x539.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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, 24 Jan 2013 09:49:16 -0000

Le 2013-01-23 22:05, Philipp Kern a écrit :
> was it a deliberate ommission that RFC6724 does not mention a precedence value
> for the well-known NAT64 prefix 64:ff9b::/96?
>
> If a host has both IPv4 and IPv6 configured it should probably use the native
> IPv4 connectivity to connect to the target instead of the translated
> IPv6-to-IPv4 access.

This has been discussed in BEHAVE numerous times. The current consensus 
is: no, NAT64 is not "worse" than IPv4.

 From the host's point of view, you don't know that IPv4 is not NATed as 
well. You don't even know if it is "native": it could be provided by 
DS-Lite for all you know.

 From the operator's point of view, if you deploy a NAT64 in a 
dual-stack network, that probably means you *want* traffic to go over 
NAT64 rather than over IPv4. You probably want *less* native IPv4 
traffic in your network so that eventually you can make your network 
fully IPv6-only.

Simon

From pkern@simplex.0x539.de  Thu Jan 24 02:42:14 2013
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 DD80721F8949 for ; Thu, 24 Jan 2013 02:42:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 ZRtwC2Hvwrr2 for ; Thu, 24 Jan 2013 02:42:14 -0800 (PST)
Received: from stormwind.0x539.de (stormwind.0x539.de [IPv6:2a01:4f8:101:2fff:2:0:fee:1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E58621F8942 for ; Thu, 24 Jan 2013 02:42:13 -0800 (PST)
Received: from hub.kern.lc ([2a01:4f8:101:2fff:2:0:ffff:1]) by stormwind.0x539.de with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TyKG3-00065a-JR for ipv6@ietf.org; Thu, 24 Jan 2013 11:42:11 +0100
Received: from [2001:470:720c:0:e0b3:c1a7:5c22:7904] (helo=simplex.lan.home.philkern.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1TyKG4-0007Ws-7L for ipv6@ietf.org; Thu, 24 Jan 2013 11:42:12 +0100
Received: from pkern by simplex.lan.home.philkern.de with local (Exim 4.80) (envelope-from ) id 1TyKG3-0008Uh-3u for ipv6@ietf.org; Thu, 24 Jan 2013 11:42:11 +0100
Date: Thu, 24 Jan 2013 11:42:11 +0100
From: Philipp Kern 
To: ipv6@ietf.org
Subject: Re: RFC6724/RFC3484bis: Destination selection not considering well-known NAT64 prefix
Message-ID: <20130124104210.GA31334@simplex.0x539.de>
References: <20130123210557.GA10474@simplex.0x539.de> <510103CC.1020709@viagenie.ca>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5vNYLRcllDrimb99"
Content-Disposition: inline
In-Reply-To: <510103CC.1020709@viagenie.ca>
Organization: Fachschaft Mathematik / Informatik am Karlsruher Institut fuer Technologie (KIT)
User-Agent: Mutt/1.5.21 (2010-09-15)
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, 24 Jan 2013 10:42:15 -0000

--5vNYLRcllDrimb99
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Simon,

thanks for your reply and sorry to rehash an old topic. I appreciate any
pointers to mailing list discussions where this horse has already been
beaten to death. ;-)

am Thu, Jan 24, 2013 at 10:50:04AM +0100 hast du folgendes geschrieben:
> This has been discussed in BEHAVE numerous times. The current
> consensus is: no, NAT64 is not "worse" than IPv4.
>=20
> From the host's point of view, you don't know that IPv4 is not NATed
> as well. You don't even know if it is "native": it could be provided
> by DS-Lite for all you know.

True, but I still find that rather unlikely in the case the host has a
globally unique IPv4 address configured. It might make sense to
preference NAT64 over NAT44, but then you are most likely double
translating, too, if you do not have enough public IPv4 addresses on the
outside interface of the NAT64 gateway.

> From the operator's point of view, if you deploy a NAT64 in a
> dual-stack network, that probably means you *want* traffic to go
> over NAT64 rather than over IPv4. You probably want *less* native
> IPv4 traffic in your network so that eventually you can make your
> network fully IPv6-only.

In that particular case the host has to have IPv4 connectivity to
provide NAT64 services and it does not make sense to have the traffic
round-trip through userspace and NAT64 translation. But nothing prevents
me from adjusting gai.conf for this special case anyway.

I guess the question is why native IPv4 is deployed to a host. If it's
done to avoid translation costs you really don't want to use the NAT64
gateway instead. If it's to just cope with IPv4 literals and IPv4-only
applications then I accept your argument that the operator would like
people to use the NAT64 gateway. But again this seems only likely if you
get a private IP assigned that's guaranteed to be NAT'ed. These seem to
be two entirely different categories with the first one being more
likely in a service provider / hosting scenario.

Kind regards
Philipp Kern

--5vNYLRcllDrimb99
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJRARACAAoJEERuJUU10Fbsx7gIAIhGOWJVVY59rj9LtFRhqxnz
eWp+R3CSIpsqOkR+AzTuoZgaTKQgqyI1RrzKrDzhhn6jyUN+yV1c14E1wKIEkPbf
MPti59UgNAMAVJbEO5C5iOtACW4o9i9rPEa4tnWIyTAoMcPu9avuQF/vd9DzUThZ
XyLSgKg7D19IUizL8I/p1Ulg267rYB9w6Ie1YBRRWNEsfsV3d2MZyYiJDrGuou+3
h0Yo05kQHrz7wgWAcDTM4f4mP4vPCQRP6e0G9gg4ZG5xQjQeTcTtxvlNRDFTfZGx
3LKUsqAYZJBblWwylRjKZ2WEQm4d0EY4DQhhb00Q58MSlSkwjj3/mtkiFq0xdaw=
=yKPk
-----END PGP SIGNATURE-----

--5vNYLRcllDrimb99--

From simon.perreault@viagenie.ca  Thu Jan 24 02:46:48 2013
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 83BAB21F8445 for ; Thu, 24 Jan 2013 02:46:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 l35dmp0-am1r for ; Thu, 24 Jan 2013 02:46:48 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0AB21F8443 for ; Thu, 24 Jan 2013 02:46:48 -0800 (PST)
Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:c90c:4a03:ec7d:ee87]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 94BD34042F for ; Thu, 24 Jan 2013 05:46:47 -0500 (EST)
Message-ID: <51011149.7050105@viagenie.ca>
Date: Thu, 24 Jan 2013 11:47:37 +0100
From: Simon Perreault 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: RFC6724/RFC3484bis: Destination selection not considering well-known NAT64 prefix
References: <20130123210557.GA10474@simplex.0x539.de> <510103CC.1020709@viagenie.ca> <20130124104210.GA31334@simplex.0x539.de>
In-Reply-To: <20130124104210.GA31334@simplex.0x539.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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, 24 Jan 2013 10:46:48 -0000

Le 2013-01-24 11:42, Philipp Kern a écrit :
> thanks for your reply and sorry to rehash an old topic. I appreciate any
> pointers to mailing list discussions where this horse has already been
> beaten to death. ;-)

No time to grep the archives, sorry. But as you can already see from 
these few emails, it's not black and white. As long as it stays mostly 
grey, it makes sense IMHO to stay with the status quo: prefer IPv6 by 
default.

Simon

From xuxiaohu@huawei.com  Thu Jan 24 02:13:07 2013
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 C069221F8849 for ; Thu, 24 Jan 2013 02:13:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.788
X-Spam-Level: **
X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
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 yBuAmwQhsKgi for ; Thu, 24 Jan 2013 02:13:06 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2686521F8834 for ; Thu, 24 Jan 2013 02:13:04 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANV23174; Thu, 24 Jan 2013 10:13:04 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 24 Jan 2013 10:12:47 +0000
Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 24 Jan 2013 10:13:03 +0000
Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.166]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.007; Thu, 24 Jan 2013 18:12:55 +0800
From: Xuxiaohu 
To: Simon Perreault , "ipv6@ietf.org" 
Subject: =?gb2312?B?tPC4tDogUkZDNjcyNC9SRkMzNDg0YmlzOiBEZXN0aW5hdGlvbiBzZWxlY3Rp?= =?gb2312?Q?on_not_considering=09well-known_NAT64_prefix?=
Thread-Topic: RFC6724/RFC3484bis: Destination selection not considering well-known NAT64 prefix
Thread-Index: AQHN+hguOnSR4VTzJk+fO9enzNQ8T5hYP3FA
Date: Thu, 24 Jan 2013 10:12:55 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07597D97@szxeml525-mbx.china.huawei.com>
References: <20130123210557.GA10474@simplex.0x539.de> <510103CC.1020709@viagenie.ca>
In-Reply-To: <510103CC.1020709@viagenie.ca>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.130]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Thu, 24 Jan 2013 03:03:14 -0800
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, 24 Jan 2013 10:13:07 -0000

DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogaXB2Ni1ib3VuY2VzQGlldGYub3Jn
IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFNpbW9uDQo+IFBlcnJlYXVsdA0K
PiC3osvNyrG85DogMjAxM8TqMdTCMjTI1SAxNzo1MA0KPiDK1bz+yMs6IGlwdjZAaWV0Zi5vcmcN
Cj4g1vfM4jogUmU6IFJGQzY3MjQvUkZDMzQ4NGJpczogRGVzdGluYXRpb24gc2VsZWN0aW9uIG5v
dCBjb25zaWRlcmluZw0KPiB3ZWxsLWtub3duIE5BVDY0IHByZWZpeA0KPiANCj4gTGUgMjAxMy0w
MS0yMyAyMjowNSwgUGhpbGlwcCBLZXJuIGEgqKZjcml0IDoNCj4gPiB3YXMgaXQgYSBkZWxpYmVy
YXRlIG9tbWlzc2lvbiB0aGF0IFJGQzY3MjQgZG9lcyBub3QgbWVudGlvbiBhIHByZWNlZGVuY2UN
Cj4gdmFsdWUNCj4gPiBmb3IgdGhlIHdlbGwta25vd24gTkFUNjQgcHJlZml4IDY0OmZmOWI6Oi85
Nj8NCj4gPg0KPiA+IElmIGEgaG9zdCBoYXMgYm90aCBJUHY0IGFuZCBJUHY2IGNvbmZpZ3VyZWQg
aXQgc2hvdWxkIHByb2JhYmx5IHVzZSB0aGUgbmF0aXZlDQo+ID4gSVB2NCBjb25uZWN0aXZpdHkg
dG8gY29ubmVjdCB0byB0aGUgdGFyZ2V0IGluc3RlYWQgb2YgdGhlIHRyYW5zbGF0ZWQNCj4gPiBJ
UHY2LXRvLUlQdjQgYWNjZXNzLg0KPiANCj4gVGhpcyBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gQkVI
QVZFIG51bWVyb3VzIHRpbWVzLiBUaGUgY3VycmVudCBjb25zZW5zdXMNCj4gaXM6IG5vLCBOQVQ2
NCBpcyBub3QgIndvcnNlIiB0aGFuIElQdjQuDQoNCm5vdCB3b3JzZSB3aGVuIElQdjQgaXMgTkFU
ZWQsIGJ1dCB3b3JzZSB3aGVuIElQdjQgaXMgbmF0aXZlLg0KDQo+ICBGcm9tIHRoZSBob3N0J3Mg
cG9pbnQgb2YgdmlldywgeW91IGRvbid0IGtub3cgdGhhdCBJUHY0IGlzIG5vdCBOQVRlZCBhcw0K
PiB3ZWxsLiBZb3UgZG9uJ3QgZXZlbiBrbm93IGlmIGl0IGlzICJuYXRpdmUiOiBpdCBjb3VsZCBi
ZSBwcm92aWRlZCBieQ0KPiBEUy1MaXRlIGZvciBhbGwgeW91IGtub3cuDQoNCkJ1dCB0aGVyZSBk
b2VzIGV4aXN0IGEgcG9zc2liaWxpdHkgZm9yIHRoYXQgSVB2NCBvZiBiZWluZyBuYXRpdmUuDQoN
Cj4gIEZyb20gdGhlIG9wZXJhdG9yJ3MgcG9pbnQgb2YgdmlldywgaWYgeW91IGRlcGxveSBhIE5B
VDY0IGluIGENCj4gZHVhbC1zdGFjayBuZXR3b3JrLCB0aGF0IHByb2JhYmx5IG1lYW5zIHlvdSAq
d2FudCogdHJhZmZpYyB0byBnbyBvdmVyDQo+IE5BVDY0IHJhdGhlciB0aGFuIG92ZXIgSVB2NC4g
WW91IHByb2JhYmx5IHdhbnQgKmxlc3MqIG5hdGl2ZSBJUHY0DQo+IHRyYWZmaWMgaW4geW91ciBu
ZXR3b3JrIHNvIHRoYXQgZXZlbnR1YWxseSB5b3UgY2FuIG1ha2UgeW91ciBuZXR3b3JrDQo+IGZ1
bGx5IElQdjYtb25seS4NCg0KVGhpcyBpcyBqdXN0IG9uZSBwb3NzaWJpbGl0eS4gQW5vdGhlciBw
b3NzaWJpbGl0eSBpcyBqdXN0IHJldmVyc2UuDQoNClhpYW9odQ0KDQo+IFNpbW9uDQo+IC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGll
dGYub3JnDQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg==

From fgont@si6networks.com  Thu Jan 24 02:59:57 2013
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 4C34121F856C for ; Thu, 24 Jan 2013 02:59:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.334
X-Spam-Level: 
X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.265,  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 DllWUs6uOOL7 for ; Thu, 24 Jan 2013 02:59:56 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id ADC0A21F8552 for <6man@ietf.org>; Thu, 24 Jan 2013 02:59:56 -0800 (PST)
Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TyKX9-0001Qc-G0; Thu, 24 Jan 2013 11:59:51 +0100
Message-ID: <51011414.3010700@si6networks.com>
Date: Thu, 24 Jan 2013 07:59:32 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: 6man@ietf.org
Subject: Fwd: New Version Notification for draft-gont-6man-ipv6-smurf-amplifier-02.txt
References: <20130124102421.26195.78729.idtracker@ietfa.amsl.com>
In-Reply-To: <20130124102421.26195.78729.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.4.6
X-Forwarded-Message-Id: <20130124102421.26195.78729.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 24 Jan 2013 03:03:14 -0800
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, 24 Jan 2013 10:59:57 -0000

Folks,

FYI, we have updated our I-D in response to the recent discussion on the
mailing list.

The new rev is available at:


Any further comments will be greatly appreciated.

Thanks!

Best regards,
Fernando




-------- Original Message --------
From: internet-drafts@ietf.org
To: fgont@si6networks.com
Cc: liushucheng@huawei.com
Subject: New Version Notification for
draft-gont-6man-ipv6-smurf-amplifier-02.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 4.37
Message-ID: <20130124102421.26195.78729.idtracker@ietfa.amsl.com>
Date: Thu, 24 Jan 2013 02:24:21 -0800


A new version of I-D, draft-gont-6man-ipv6-smurf-amplifier-02.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Filename:	 draft-gont-6man-ipv6-smurf-amplifier
Revision:	 02
Title:		 Security Implications of IPv6 Options of Type 10xxxxxx
Creation date:	 2013-01-24
WG ID:		 Individual Submission
Number of pages: 11
URL:
http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-smurf-amplifier-02.txt
Status:
http://datatracker.ietf.org/doc/draft-gont-6man-ipv6-smurf-amplifier
Htmlized:
http://tools.ietf.org/html/draft-gont-6man-ipv6-smurf-amplifier-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gont-6man-ipv6-smurf-amplifier-02

Abstract:
   When an IPv6 node processing an IPv6 packet does not support an IPv6
   option whose two-highest-order bits of the Option Type are '10', it
   is required to respond with an ICMPv6 Parameter Problem error
   message, even if the Destination Address of the packet was a
   multicast address.  This feature provides an amplification vector,
   opening the door to an IPv6 version of the 'Smurf' Denial-of-Service
   (DoS) attack found in IPv4 networks.  This document discusses the
   security implications of the aforementioned options, and formally
   updates RFC 2460 and RFC 4443 such that this attack vector is
   eliminated.  Additionally, it describes a number of operational
   mitigations that could be deployed against this attack vector.





The IETF Secretariat





From touch@isi.edu  Thu Jan 24 11:35:36 2013
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 E2E1B11E80A5; Thu, 24 Jan 2013 11:35:36 -0800 (PST)
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 xGf7BgYgBWV8; Thu, 24 Jan 2013 11:35:36 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2375811E80A3; Thu, 24 Jan 2013 11:35:36 -0800 (PST)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r0OJZ5Ni006195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Jan 2013 11:35:05 -0800 (PST)
Message-ID: <51018CE9.3030700@isi.edu>
Date: Thu, 24 Jan 2013 11:35:05 -0800
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Allison Mankin 
Subject: Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Mailman-Approved-At: Thu, 24 Jan 2013 12:11:08 -0800
Cc: 6man@ietf.org, Transport Area , IETF Discuss , Transport Directorate 
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, 24 Jan 2013 19:35:37 -0000

FWIW, this document includes text that somewhat defeats the previous 
recommendations of TCPM regarding RFC5927.

RFC5927 includes specific text indicating that the techniques described 
are being documented, but that the TCP standard was NOT being changed to 
include those ICMP validation checks.

This document states that:

       Many implementations fail to perform validation checks on the
       received ICMPv6 error messages, as recommended in Section 5.2 of
       [RFC4443] and [RFC5927].

I.e., the second RFC does NOT recommend changes; it documents them. This 
document should be VERY carefully reviewed to ensure that it does not 
undo the previous TCPM concerns about these techniques.

Joe

From fgont@si6networks.com  Thu Jan 24 16:13:17 2013
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 470A621F850C; Thu, 24 Jan 2013 16:13:17 -0800 (PST)
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 MumQoqbCd5nj; Thu, 24 Jan 2013 16:13:16 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 84A2C21F84F6; Thu, 24 Jan 2013 16:13:04 -0800 (PST)
Received: from [190.174.155.31] (helo=[192.168.1.43]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TyWuD-0004gT-NB; Fri, 25 Jan 2013 01:12:30 +0100
Message-ID: <5101A671.4090906@si6networks.com>
Date: Thu, 24 Jan 2013 18:24:01 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Joe Touch 
Subject: Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
References:  <51018CE9.3030700@isi.edu>
In-Reply-To: <51018CE9.3030700@isi.edu>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 25 Jan 2013 00:13:29 -0800
Cc: Transport Directorate , 6man@ietf.org, Transport Area , Allison Mankin , IETF Discuss 
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, 25 Jan 2013 00:13:17 -0000

Joe,

On 01/24/2013 04:35 PM, Joe Touch wrote:
> FWIW, this document includes text that somewhat defeats the previous
> recommendations of TCPM regarding RFC5927.
> 
> RFC5927 includes specific text indicating that the techniques described
> are being documented, but that the TCP standard was NOT being changed to
> include those ICMP validation checks.
> 
> This document states that:
> 
>       Many implementations fail to perform validation checks on the
>       received ICMPv6 error messages, as recommended in Section 5.2 of
>       [RFC4443] and [RFC5927].

Are we fine if I remove "and [RFC5927]"? -- Because RFC4443 does
recommend that ICMPv6 messages be validated.


> I.e., the second RFC does NOT recommend changes; it documents them. This
> document should be VERY carefully reviewed to ensure that it does not
> undo the previous TCPM concerns about these techniques.

We can remove "and [RFC5927]" or change it to "...Section 5.2 of
[RFC4443] and documented in [RFC5927]"

Thoughts?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From touch@isi.edu  Thu Jan 24 16:19:59 2013
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 223CE11E809B; Thu, 24 Jan 2013 16:19:59 -0800 (PST)
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 LRlgpr+bZha3; Thu, 24 Jan 2013 16:19:58 -0800 (PST)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3659C11E8099; Thu, 24 Jan 2013 16:19:58 -0800 (PST)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r0P0JW5Q001300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Jan 2013 16:19:32 -0800 (PST)
Message-ID: <5101CF94.4070208@isi.edu>
Date: Thu, 24 Jan 2013 16:19:32 -0800
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Fernando Gont 
Subject: Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
References:  <51018CE9.3030700@isi.edu> <5101A671.4090906@si6networks.com>
In-Reply-To: <5101A671.4090906@si6networks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Mailman-Approved-At: Fri, 25 Jan 2013 00:13:29 -0800
Cc: Transport Directorate , 6man@ietf.org, Transport Area , Allison Mankin , IETF Discuss 
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, 25 Jan 2013 00:19:59 -0000

On 1/24/2013 1:24 PM, Fernando Gont wrote:
> Joe,
>
> On 01/24/2013 04:35 PM, Joe Touch wrote:
>> FWIW, this document includes text that somewhat defeats the previous
>> recommendations of TCPM regarding RFC5927.
>>
>> RFC5927 includes specific text indicating that the techniques described
>> are being documented, but that the TCP standard was NOT being changed to
>> include those ICMP validation checks.
>>
>> This document states that:
>>
>>        Many implementations fail to perform validation checks on the
>>        received ICMPv6 error messages, as recommended in Section 5.2 of
>>        [RFC4443] and [RFC5927].
>
> Are we fine if I remove "and [RFC5927]"? -- Because RFC4443 does
> recommend that ICMPv6 messages be validated.

Sure.

>> I.e., the second RFC does NOT recommend changes; it documents them. This
>> document should be VERY carefully reviewed to ensure that it does not
>> undo the previous TCPM concerns about these techniques.
>
> We can remove "and [RFC5927]" or change it to "...Section 5.2 of
> [RFC4443] and documented in [RFC5927]"

That might do it, but it would be useful if another pair of eyes would 
check.

Joe

>
> Thoughts?
>
> Thanks,
>

From allison.mankin@gmail.com  Thu Jan 24 17:57:12 2013
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 07B3721F841E; Thu, 24 Jan 2013 17:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 IBFDYnzhLFxn; Thu, 24 Jan 2013 17:57:11 -0800 (PST)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDCE21F841C; Thu, 24 Jan 2013 17:57:10 -0800 (PST)
Received: by mail-we0-f175.google.com with SMTP id x8so280795wey.20 for ; Thu, 24 Jan 2013 17:57:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nlQ4Qmr1wu1D9OA0xAn+Q6qhD2azDPtzYf5DoGo40KU=; b=YhKuEwnpWBWEMZjfp1RuacYlM4hA2rjMO8rJGc4UfK61UKtUehV8pBpnXb+LSWeP7a XK31/hLrakftde7TGSYEEXm2WQD0QPi13DaBlOaEEYvI46Funj69JZA2cpRj54LcMXEl IR+HAF/JBnPZQtKHhHqi+lEwhE0IL8bhoZLKUl+BU8T+Vl1ziXxQjFIgwF2cSS3jzVP4 LUlQ7b9xG30ageKdjPSrHVy3tSmPofCM3E3iRSyj8Fl7LABzJ4WjDaIXn3DOL64ji9pD al13sRQmTLCXnSXQfnPPw5u8CymCD74eLPBU6n0QaWm3jSyD7Ecqp7FIZzsSr1cs9ioK 56Xg==
MIME-Version: 1.0
X-Received: by 10.180.85.226 with SMTP id k2mr6022072wiz.34.1359079029735; Thu, 24 Jan 2013 17:57:09 -0800 (PST)
Received: by 10.217.80.2 with HTTP; Thu, 24 Jan 2013 17:57:09 -0800 (PST)
Received: by 10.217.80.2 with HTTP; Thu, 24 Jan 2013 17:57:09 -0800 (PST)
In-Reply-To: <5101CF94.4070208@isi.edu>
References:  <51018CE9.3030700@isi.edu> <5101A671.4090906@si6networks.com> <5101CF94.4070208@isi.edu>
Date: Thu, 24 Jan 2013 20:57:09 -0500
Message-ID: 
Subject: Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
From: Allison Mankin 
To: Joe Touch 
Content-Type: multipart/alternative; boundary=f46d04428230ca001204d4133e83
X-Mailman-Approved-At: Fri, 25 Jan 2013 00:13:29 -0800
Cc: Fernando Gont , 6man@ietf.org, Transport Area , IETF Discuss , Transport Directorate 
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, 25 Jan 2013 01:57:12 -0000

--f46d04428230ca001204d4133e83
Content-Type: text/plain; charset=ISO-8859-1

Joe and Fernando,

I just looked at how RFC 5297 is handled in the draft, to be that other
pair of eyes.

The first fix is right, to remove reference to RFC 5297 from that sentence
entirely.

Allison

On Jan 24, 2013 7:19 PM, "Joe Touch"  wrote:
>
>
>
> On 1/24/2013 1:24 PM, Fernando Gont wrote:
>>
>> Joe,
>>
>> On 01/24/2013 04:35 PM, Joe Touch wrote:
>>>
>>> FWIW, this document includes text that somewhat defeats the previous
>>> recommendations of TCPM regarding RFC5927.
>>>
>>> RFC5927 includes specific text indicating that the techniques described
>>> are being documented, but that the TCP standard was NOT being changed to
>>> include those ICMP validation checks.
>>>
>>> This document states that:
>>>
>>>        Many implementations fail to perform validation checks on the
>>>        received ICMPv6 error messages, as recommended in Section 5.2 of
>>>        [RFC4443] and [RFC5927].
>>
>>
>> Are we fine if I remove "and [RFC5927]"? -- Because RFC4443 does
>> recommend that ICMPv6 messages be validated.
>
>
> Sure.
>
>
>>> I.e., the second RFC does NOT recommend changes; it documents them. This
>>> document should be VERY carefully reviewed to ensure that it does not
>>> undo the previous TCPM concerns about these techniques.
>>
>>
>> We can remove "and [RFC5927]" or change it to "...Section 5.2 of
>> [RFC4443] and documented in [RFC5927]"
>
>
> That might do it, but it would be useful if another pair of eyes would
check.
>
> Joe
>
>>
>> Thoughts?
>>
>> Thanks,
>>

--f46d04428230ca001204d4133e83
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Joe and Fernando,


I just looked at how RFC 5297 is handled in the draft, to be that other =
pair of eyes.=A0=A0 


The first fix is right, to remove reference to RFC 5297 from that senten=
ce entirely. 


Allison


On Jan 24, 2013 7:19 PM, "Joe Touch" <touch@isi.edu> wrote:

>

>

>

> On 1/24/2013 1:24 PM, Fernando Gont wrote:

>>

>> Joe,

>>

>> On 01/24/2013 04:35 PM, Joe Touch wrote:

>>>

>>> FWIW, this document includes text that somewhat defeats the pr=
evious

>>> recommendations of TCPM regarding RFC5927.

>>>

>>> RFC5927 includes specific text indicating that the techniques =
described

>>> are being documented, but that the TCP standard was NOT being =
changed to

>>> include those ICMP validation checks.

>>>

>>> This document states that:

>>>

>>> =A0 =A0 =A0 =A0Many implementations fail to perform validation=
 checks on the

>>> =A0 =A0 =A0 =A0received ICMPv6 error messages, as recommended =
in Section 5.2 of

>>> =A0 =A0 =A0 =A0[RFC4443] and [RFC5927].

>>

>>

>> Are we fine if I remove "and [RFC5927]"? -- Because RFC4=
443 does

>> recommend that ICMPv6 messages be validated.

>

>

> Sure.

>

>

>>> I.e., the second RFC does NOT recommend changes; it documents =
them. This

>>> document should be VERY carefully reviewed to ensure that it d=
oes not

>>> undo the previous TCPM concerns about these techniques.

>>

>>

>> We can remove "and [RFC5927]" or change it to "...S=
ection 5.2 of

>> [RFC4443] and documented in [RFC5927]"

>

>

> That might do it, but it would be useful if another pair of eyes would=
 check.

>

> Joe

>

>>

>> Thoughts?

>>

>> Thanks,

>>




--f46d04428230ca001204d4133e83--

From touch@isi.edu  Thu Jan 24 17:59:39 2013
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 29FCC11E80DC; Thu, 24 Jan 2013 17:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level: 
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, 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 0lGKiHHsV0Hu; Thu, 24 Jan 2013 17:59:38 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9B64611E80D9; Thu, 24 Jan 2013 17:59:38 -0800 (PST)
Received: from [128.9.184.216] ([128.9.184.216]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r0P1x0pu026227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Jan 2013 17:59:02 -0800 (PST)
Message-ID: <5101E6E4.8080407@isi.edu>
Date: Thu, 24 Jan 2013 17:59:00 -0800
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Allison Mankin 
Subject: Re: TSV-DIR review of draft-ietf-6man-ipv6-atomic-fragments-03
References:  <51018CE9.3030700@isi.edu> <5101A671.4090906@si6networks.com> <5101CF94.4070208@isi.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Mailman-Approved-At: Fri, 25 Jan 2013 00:13:29 -0800
Cc: Fernando Gont , 6man@ietf.org, Transport Area , IETF Discuss , Transport Directorate 
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, 25 Jan 2013 01:59:39 -0000

Thanks - I wasn't positive about the second one. Glad to have it 
resolved quickly.

Joe

On 1/24/2013 5:57 PM, Allison Mankin wrote:
> Joe and Fernando,
>
> I just looked at how RFC 5297 is handled in the draft, to be that other
> pair of eyes.
>
> The first fix is right, to remove reference to RFC 5297 from that
> sentence entirely.
>
> Allison
>
> On Jan 24, 2013 7:19 PM, "Joe Touch"  > wrote:
>  >
>  >
>  >
>  > On 1/24/2013 1:24 PM, Fernando Gont wrote:
>  >>
>  >> Joe,
>  >>
>  >> On 01/24/2013 04:35 PM, Joe Touch wrote:
>  >>>
>  >>> FWIW, this document includes text that somewhat defeats the previous
>  >>> recommendations of TCPM regarding RFC5927.
>  >>>
>  >>> RFC5927 includes specific text indicating that the techniques described
>  >>> are being documented, but that the TCP standard was NOT being
> changed to
>  >>> include those ICMP validation checks.
>  >>>
>  >>> This document states that:
>  >>>
>  >>>        Many implementations fail to perform validation checks on the
>  >>>        received ICMPv6 error messages, as recommended in Section 5.2 of
>  >>>        [RFC4443] and [RFC5927].
>  >>
>  >>
>  >> Are we fine if I remove "and [RFC5927]"? -- Because RFC4443 does
>  >> recommend that ICMPv6 messages be validated.
>  >
>  >
>  > Sure.
>  >
>  >
>  >>> I.e., the second RFC does NOT recommend changes; it documents them.
> This
>  >>> document should be VERY carefully reviewed to ensure that it does not
>  >>> undo the previous TCPM concerns about these techniques.
>  >>
>  >>
>  >> We can remove "and [RFC5927]" or change it to "...Section 5.2 of
>  >> [RFC4443] and documented in [RFC5927]"
>  >
>  >
>  > That might do it, but it would be useful if another pair of eyes
> would check.
>  >
>  > Joe
>  >
>  >>
>  >> Thoughts?
>  >>
>  >> Thanks,
>  >>
>

From jiangsheng@huawei.com  Fri Jan 25 00:58:16 2013
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 94B4821F85CC for ; Fri, 25 Jan 2013 00:58:16 -0800 (PST)
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, MIME_8BIT_HEADER=0.3, 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 fTN1hhxSYiu6 for ; Fri, 25 Jan 2013 00:58:15 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A82FE21F88B4 for ; Fri, 25 Jan 2013 00:58:14 -0800 (PST)
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 APC24252; Fri, 25 Jan 2013 08:58:13 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 25 Jan 2013 08:57:50 +0000
Received: from SZXEML452-HUB.china.huawei.com (10.82.67.195) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 25 Jan 2013 08:58:09 +0000
Received: from szxeml545-mbx.china.huawei.com ([169.254.1.45]) by szxeml452-hub.china.huawei.com ([10.82.67.195]) with mapi id 14.01.0323.007; Fri, 25 Jan 2013 16:58:05 +0800
From: Sheng Jiang 
To: =?utf-8?B?UsOpbWkgRGVzcHLDqXM=?= , Bob Hinden 
Subject: RE: 4rd IID range & IPv6 addressing architecture
Thread-Topic: 4rd IID range & IPv6 addressing architecture
Thread-Index: AQHN9/MuVE+aa6euakG5Kkj6elsKlZhZvazQ
Date: Fri, 25 Jan 2013 08:58:04 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923A0001CE@szxeml545-mbx.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: 6man 6man-wg , Suresh Krishnan 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jan 2013 08:58:16 -0000

SGksIEJvYiBhbmQgNm1hbiwNCg0KV2UgZG8gbmVlZCBhbiBhbnN3ZXIgZnJvbSA2bWFuIHRvIG1v
dmUgZm9yd2FyZC4gU28gZmFyLCBpbiBteSB1bmRlcnN0YW5kaW5nLCA2bWFuIGhhcyBub3QgYW5z
d2VyZWQgdGhlIHJlcXVpcmVtZW50L3F1ZXN0aW9uIHJhaXNlZCBieSBzb2Z0d2lyZSBjaGFpci4N
Cg0KUGVyc29uYWxseSwgSSBzdXBwb3J0IHRoZSBwcm9wb3NhbCB0byByZXNlcnZlIGEgNHJkIElJ
RCByYW5nZSAod2UgY2FuIGhhdmUgbWF4IDE2IGZpeGVkIGJpdCBpbiBvcmRlciB0byByZWR1Y2Ug
dGhlIHJlc2VydmVkIHJhbmdlKS4gRm9yIHRoaXMgd2UgbmVlZCB0byB1cGRhdGUgUkZDIDU0NTMg
dG8gZW5hYmxlIElJRCByZXNlcnZhdGlvbiBmb3IgZXhwZXJpbWVudGFsIFJGQ3MuIFRoZSB2YWx1
ZSBvZiByZXNlcnZlZCA0cmQgSUlEIHJhbmdlIGNhbiBiZSBkaXNjdXNzZWQuIFRoZSBvbmx5IHJl
cXVpcmVtZW50IGlzIHRoZSB1bmlxdWVuZXNzLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoN
Cj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGlwdjYtYm91bmNlc0BpZXRmLm9y
ZyBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFINCj7DqW1pIERl
c3Byw6lzDQo+U2VudDogVHVlc2RheSwgSmFudWFyeSAyMiwgMjAxMyAxMjoyMCBBTQ0KPlRvOiBC
b2IgSGluZGVuDQo+Q2M6IDZtYW4gNm1hbi13Zw0KPlN1YmplY3Q6IDRyZCBJSUQgcmFuZ2UgJiBJ
UHY2IGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlDQo+DQo+SGksIEJvYiwNCj4NCj5UaGUgZGlzY3Vz
c2lvbiBvbiB3aGV0aGVyIHRoZSBwcm9wb3NlZCA0cmQgSUlEIHJhbmdlIGlzICJjb21wYXRpYmxl
IHdpdGggdGhlDQo+SVB2NiBhZGRyZXNzaW5nIGFyY2hpdGVjdHVyZSIgaGFzIGFwcGFyZW50bHkg
Y29tZSB0byBhIHN0YW5kc3RpbGwuDQo+WWV0IGFuIGFuc3dlciBvZiA2bWFuIHRvIFNvZnR3aXJl
IGlzIGV4cGVjdGVkLg0KPg0KPkEuIFRvIGhlbHAgbWFraW5nIGEgV0cgZGVjaXNpb24sIGhlcmUg
YXJlIGtleSBwb2ludHMgdGhhdCwgaW4gbXkNCj51bmRlcnN0YW5kaW5nLCBlbWVyZ2VkIGZyb20g
dGhlIGRpc2N1c3Npb24uDQo+DQo+KGEpIFJheSBIdW50ZXIgaGFzIHByb3ZpZGVkIGEgcmVmZXJl
bmNlIHRvIFJGQzUzNDIgd2hpY2ggY29uZmlybXMgdGhhdCwgaW4NCj5SRkMgNDI5MSBjb21wbGlh
bnQgYWRkcmVzc2VzLCB1PWc9MSBpcyAiY3VycmVudGx5IHVudXNlZCINCj4od3d3LmlldGYub3Jn
L21haWwtYXJjaGl2ZS93ZWIvaXB2Ni9jdXJyZW50L21zZzE2ODkwLmh0bWwpLiA0cmQgYWRkcmVz
c2VzLA0KPndoaWNoIGhhdmUgdT1nPTEsIHRoZXJlZm9yZSBjYW5ub3QgY29uZmxpY3Qgd2l0aCBj
dXJyZW50IGFkZHJlc3NlcyBvZiB0aGUNCj5JUHY2IGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlLiAo
SW4gcGFydGljdWxhciwgdGhleSBkb24ndCBjb25mbGljdCB3aXRoIHRob3NlIG9mDQo+UkZDNjc0
MCBJTE5QLikNCj4NCj4oYikgQnJpYW4gQ2FycGVudGVyIHBvaW50ZWQgb3V0IHRoYXQgYSAxNi1i
aXQgcHJlZml4IHdvdWxkIGJlIHN1ZmZpY2llbnQgZm9yIDRyZCwNCj50YWtpbmcgbGVzcyBJSUQg
c3BhY2UgdGhhbiB0aGUgY3VycmVudGx5IHByb3Bvc2VkIDgtYml0IHByZWZpeC4gVGhpcyBiZWlu
Zw0KPmFja25vd2xlZGdlZCwgdGhlIDB4MDMwMCBwcmVmaXggY2FuIHdpdGhvdXQgcHJvYmxlbSBy
ZXBsYWNlIHRoZSAweDAzIHByZWZpeC4NCj4oVGhpcyBkb2Vzbid0IGNoYW5nZSB0aGUgNHJkIHNw
ZWNpZmljYXRpb24gd2hpY2ggYWxyZWFkeSBoYXMgYSAweDAwIGFmdGVyDQo+MHgwMy4pIFdpdGgg
dGhpcyBwcmVmaXgsIHRoZSByZXNlcnZlZCByYW5nZSB1c2VzIG9ubHkgMS8yXjE0IG9mIHRoZSB1
bnVzZWQgc2V0DQo+b2YgSUlEcyBoYXZpbmcgdT1nPTEgaXMgcmVzZXJ2ZWQuIFRoaXMgbGVhdmVz
IHBsZW50eSBvZiBzcGFjZSBmb3IgZnV0dXJlIHVzZXMgb2YNCj5JSURzIGhhdmluZyB1PTEgKGZ1
dHVyZSB1c2VzIGV4cGxpY2l0bHkgZW52aXNhZ2VkIGluIFJGQyA0MjkxKS4NCj4NCj4oYykgSm91
bmkgS29yaG9uZW4gcG9pbnRlZCBvdXQgdGhhdCB0aGVyZSBpcyBhbHJlYWR5IGFuIElBTkEgcmVn
aXN0cnkgZm9yDQo+cmVzZXJ2ZWQgSUlEIHJhbmdlcywgYW5kIFNpbW9uIFBlcnJlYXVsdCBnYXZl
IHRoZSBjb3JyZWN0IHBvaW50ZXIgdG8gaXQNCj4oaHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25t
ZW50cy9pcHY2LWludGVyZmFjZS1pZHMvaXB2Ni1pbnRlcmZhY2UtaWRzLnhtbCkuDQo+DQo+KGQp
IFN1cmVzaCBLcmlzaG5hbiBwb2ludGVkIG91dCB0aGF0LCBhY2NvcmRpbmcgdG8gUkZDIDU0NTMs
IHRoaXMgcmVnaXN0cnkgaXMgc28NCj5mYXIgcmVzZXJ2ZWQgZm9yIHN0YW5kYXJkLXRyYWNrIFJG
Q3MsIHRoZSByZWFzb24gYmVpbmcgInRvIG1pbmltaXplIGRpc3J1cHRpb24NCj50byBleGlzdGlu
ZyBpbXBsZW1lbnRhdGlvbnMiLiBBbHRob3VnaCA0cmQgaGFzIGJlZW4gcHVycG9zZWx5IGRlc2ln
bmVkIHNvDQo+dGhhdCBpdCBjYW5ub3QgZGlzdHVyYiBhbnkgZXhpc3RpbmcgaW1wbGVtZW50YXRp
b24gKHByZWNpc2VseSBieSB1c2luZyBhDQo+Y3VycmVudGx5IHVudXNlZCBJSUQgcmFuZ2UpLCB0
aGUgcHJvcG9zZWQgNHJkIHJhbmdlIGNhbiBiZSBlbmRvcnNlZCBieSBJQU5BDQo+b25seSBpZiBh
biBSRkMgdXBkYXRlcyBSRkMgNTQ1MywgZXhwbGFpbmluZyB3aHkgYSA0cmQgSUlEIHJhbmdlIGNh
biBiZSBzYWZlbHkNCj5hc3NpZ25lZCBkZXNwaXRlIGl0cyBleHBlcmltZW50YWwgc3RhdHVzLg0K
Pi0gSWYgYWdyZWVkIG9uIHRoZSBwcmluY2lwbGUsIGFuZCBpZiBubyBvbmUgZWxzZSB2b2x1bnRl
ZXJzLCBJIGNhbiBiZSBhdmFpbGFibGUgdG8NCj5wcm9wb3NlIGEgZHJhZnQgdG8gdGhpcyBlZmZl
Y3QuDQo+DQo+KGUpIFdpdGggdGhlIDE2LWJpdCA0cmQgSUlEIHByZWZpeCwgb25seSAxLzJeMTQg
b2YgdGhlIHVudXNlZCBzZXQgb2YgSUlEcyBoYXZpbmcNCj51PWc9MSBpcyByZXNlcnZlZC4gVGhp
cyBsZWF2ZXMgcGxlbnR5IG9mIHNwYWNlIGZvciBmdXR1cmUgdXNlcyBvZiBJSURzIGhhdmluZw0K
PnU9MSwgYXMgZXhwbGljaXRseSBleHBlY3RlZCBpbiBSRkMgNDI5MS4NCj4NCj5XaXRoIHRoaXMs
IDZtYW4gY2FuIElNSE8gYW5zd2VyIHRoYXQgU29mdHdpcmUgY2FuIHByb2NlZWQgd2l0aCA0cmQs
DQo+cHJvdmlkZWQ6DQo+LSB0aGUgMTYtYml0IElJRCBwcmVmaXggMHgwMzAwIHJlcGxhY2VzIHRo
ZSBjdXJyZW50IDB4MDMNCj4tIGl0IGlzIHVuZGVyc3Rvb2QgdGhhdCBJQU5BIHdvbid0IHJlZ2lz
dGVyIHRoaXMgSUlEIHJhbmdlIGJlZm9yZSBhIDZtYW4gUkZDDQo+cGVybWl0cyBpdCBmb3IgdGhp
cyBleHBlcmltZW50YWwtdHJhY2sgUkZDLg0KPg0KPk5vIHRlY2huaWNhbGx5IGZvdW5kZWQgb2Jq
ZWN0aW9uIHJlbWFpbnMgQUZBSUssIGJ1dCBpZiBhbnkgb25lIHN0aWxsIGhvbGRzIGl0DQo+aGFz
IG9mIGNvdXJzZSB0byBiZSBleHByZXNzZWQgYW5kIGRpc2N1c3NlZC4NCj4NCj4NCj4NCj5CLiBG
b3IgdGhvc2Ugd2hvIGFyZSBpbnRlcmVzdGVkIGluIGEgZGV0YWlsZWQgc3VtbWFyeSBvZiBvYmpl
Y3Rpb25zIHRoYXQgd2VyZQ0KPm1hZGUsIGFuZCBoYXZlIGJlZW4gYW5zd2VyZWQsIGhlcmUgaXMg
d2hhdCBJIG5vdGVkOg0KPg0KPihpKSBJZiBJRVRGIHVzZXMgdT1nPTEgaW4gc29tZSB1bmljYXN0
IGFkZHJlc3NlcywgSUVFRSB3b3VsZCBoYXZlIHRvIGJlDQo+aW52b2x2ZWQuDQo+LSBCZWNhdXNl
IDRyZCBJSURzIGFyZSBuZXZlciB0byBiZSB1c2VkIGluIGFueSBNQUMtbGF5ZXIgYWRkcmVzc2Vz
LiBJRUVFIGlzbid0DQo+Y29uY2VybmVkLg0KPg0KPihqKSA0cmQgY291bGQgd29yayB3aXRob3V0
IGEgcmVzZXJ2ZWQgcmFuZ2UuDQo+LSBBcyBkaXNjdXNzZWQgaW4gU29mdHdpcmUsIHJlc2Vydmlu
ZyBhbiBJSUQgcmFuZ2UgaXMga2V5IHRvIHNhdGlzZnkgdGhlIG9iamVjdGl2ZQ0KPnRoYXQgIjRy
ZCBJUHY2IGFkZHJlc3NlcyBhcmUgcmVjb2duaXphYmxlIGJ5IENFcyB3aXRob3V0IGFueSBpbnRl
cmZlcmVuY2UNCj53aXRoIHRoZSBjaG9pY2Ugb2Ygc3VibmV0IHByZWZpeGVzIGluIENFIHNpdGVz
Ii4NCj4NCj4oaykgQW4gSUlEIHJhbmdlIHVzaW5nIHRoZSBJQU5BIE9VSSB3aXRoIHU9MSBhbmQg
Zz0wIHdvdWxkIGhhdmUgYmVlbg0KPnN1ZmZpY2llbnQuDQo+LSBBcyBkaXNjdXNzZWQgaW4gU29m
dHdpcmUsIHRoaXMgd291bGRuJ3QgaGF2ZSBsZWZ0IGVub3VnaCBJSUQgYml0cyB0byBjb250YWlu
DQo+dGhlIElQdjQgYWRkcmVzcyBhbmQgdGhlIDE2LWJpdCBDTlAsIHdoaWNoIGFyZSBib3RoIG5l
ZWRlZCBpbiA0cmQuDQo+DQo+KGwpIEEgNHJkLXNwZWNpZmljIGRlc3RpbmF0aW9uIGhlYWRlciBj
b3VsZCBoYXZlIGJlZW4gdXNlZCBpbnN0ZWFkIG9mIGFuDQo+SUlELXJhbmdlLg0KPi0gIEFuIGV4
dHJhIGhlYWRlciB3b3VsZCBoYXZlIGRlZmVhdGVkIHRoZSA0cmQgb2JqZWN0aXZlIHRoYXQgaXRz
ICJ0dW5uZWwNCj5wYWNrZXRzIGFyZSB2YWxpZCBJUHY2IHBhY2tldHMgZm9yIGFsbCBsYXllci00
IHByb3RvY29scyB0aGF0IHVzZSB0aGUgc2FtZQ0KPmNoZWNrc3VtIGFsZ29yaXRobSBhcyBUQ1Ai
Lg0KPg0KPihtKSBXaXRoIGEgInJlc2VydmVkIC82NCBvbiB0aGUgY3VzdG9tZXJzIGRlbGVnYXRl
ZCBwcmVmaXggZm9yIHRoZSBzb2xlIHVzZQ0KPm9mIDRyZCIsYW5kIDRyZCBub2RlcyBwcm90ZWN0
aW5nICJhbGwgcG9zc2libGUgNHJkIGludGVyZmFjZS1pZHMgdXNpbmcgREFEIiwgYQ0KPnJlc2Vy
dmVkIHJhbmdlIGNvdWxkIGhhdmUgYmVlbiBhdm9pZGVkLg0KPi0gVGhpcyB3b3VsZG4ndCB3b3Jr
IGZvciBJSUQgYXNzaWdubWVudHMgbWFkZSBiZWZvcmUgNHJkIGFjdGl2YXRpb24sIHdoaWxlDQo+
NHJkIGlzIGRlc2lnbmVkIHRvIGNvdmVyIHRoaXMgY2FzZSB0b28uIChOb3RlIGFsc28gdGhhdCA0
cmQgaW1wbGVtZW50YXRpb25zDQo+Y2FuIGFkZCwgb24gdGhlaXIgTEFOIHNpZGVzLCBleGNsdXNp
b24gb2YgYWxsIGFkZHJlc3NlcyBoYXZpbmcgdGhlIDRyZCBJSUQNCj5wcmVmaXguIEFsdGhvdWdo
IHRoaXMgaXNuJ3Qgc3RyaWN0bHkgbmVlZGVkLCB0aGlzIGNhbiBwZXJtaXQgZWFybHkgZGV0ZWN0
aW9uIG9mDQo+c29tZSBlcnJvbmVvdXMgbWFudWFsIGNvbmZpZ3VyYXRpb25zLCBhbmQgaXMgZWFz
eSB0byBkbyBkdWUgdG8gdGhlIDRyZCBJSUQNCj5wcmVmaXggYmVpbmcgYSBjb25zdGFudC4NCj4N
Cj4obikgNHJkIHdvdWxkIGZhaWwgaWYgYSBjdXN0b21lciBsaW5rIGhhcyB0d28gNHJkIENFcy4N
Cj4tIEFmdGVyIGRpc2N1c3Npb24sIG5vIGlzc3VlIG9uIHRoaXMgaGFzIGJlZW4ga2VwdCBpbiBT
b2Z0d2lyZS4NCj4NCj4NCj4NCj5CZXN0IHJlZ2FyZHMsDQo+UkQNCj4NCj4tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
PklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPmlwdjZAaWV0Zi5vcmcNCj5B
ZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9pcHY2DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg==

From dwing@cisco.com  Fri Jan 25 08:18:54 2013
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 F399321F8460 for ; Fri, 25 Jan 2013 08:18:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ve0J-gwH3zxx for ; Fri, 25 Jan 2013 08:18:53 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 56AA121F845D for ; Fri, 25 Jan 2013 08:18:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1930; q=dns/txt; s=iport; t=1359130733; x=1360340333; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=iHeI2NslRnWCE/zA/QLQtTMkQP8Fvg6l25a5dAn8Ra4=; b=KM0s9+5fJpX4XjA5igSnduEPysQK+FDe01M5zt1eC4NCLTaoCkbUyDu4 fRQctgmUJPuAzx3Z23Y8J4EVJhZPwIrVicWyRvnUGW1TqxVF5Jidae35t sCWDCIHMVbnOLVWJirEslVw8Bgn4rbjEG4U1XCvSmJDk/A9f/BxrC0wxz c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFABCwAlGrRDoJ/2dsb2JhbABEvlMWc4IeAQEBAwEBAQEFAmQQBwEDAgkRBAEBKAcZDh8JCAIEARILBYd5BQ2+QQSRPwOILDWFHYgPkEiDGA
X-IronPort-AV: E=Sophos;i="4.84,539,1355097600"; d="scan'208";a="69629117"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 25 Jan 2013 16:18:46 +0000
Received: from DWINGWS01 ([10.32.240.198]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0PGIkqB027908; Fri, 25 Jan 2013 16:18:46 GMT
From: "Dan Wing" 
To: "'Simon Perreault'" , 
References: <20130123210557.GA10474@simplex.0x539.de> <510103CC.1020709@viagenie.ca>
In-Reply-To: <510103CC.1020709@viagenie.ca>
Subject: RE: RFC6724/RFC3484bis: Destination selection not considering	well-known NAT64 prefix
Date: Fri, 25 Jan 2013 08:18:46 -0800
Message-ID: <05f801cdfb17$a6dec7d0$f49c5770$@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJimTRgrhcOPR5TuXhRFhhJf/HxsQEFKWVclyjTGxA=
Content-Language: en-us
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, 25 Jan 2013 16:18:54 -0000

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf =
Of
> Simon Perreault
> Sent: Thursday, January 24, 2013 1:50 AM
> To: ipv6@ietf.org
> Subject: Re: RFC6724/RFC3484bis: Destination selection not considering
> well-known NAT64 prefix
>=20
> Le 2013-01-23 22:05, Philipp Kern a =E9crit :
> > was it a deliberate ommission that RFC6724 does not mention a
> > precedence value for the well-known NAT64 prefix 64:ff9b::/96?
> >
> > If a host has both IPv4 and IPv6 configured it should probably use =
the
> > native
> > IPv4 connectivity to connect to the target instead of the translated
> > IPv6-to-IPv4 access.
>=20
> This has been discussed in BEHAVE numerous times. The current =
consensus
> is: no, NAT64 is not "worse" than IPv4.
>=20
>  From the host's point of view, you don't know that IPv4 is not NATed =
as
> well. You don't even know if it is "native": it could be provided by =
DS-
> Lite for all you know.
>=20
>  From the operator's point of view, if you deploy a NAT64 in a dual-
> stack network, that probably means you *want* traffic to go over
> NAT64 rather than over IPv4. You probably want *less* native IPv4
> traffic in your network so that eventually you can make your network
> fully IPv6-only.

And also, if the host only has special handling for the well-known
NAT64 prefix (64:ff9b::/96), that means networks that need to or decide
to deploy their own, site-specific NAT64 prefix will not benefit from
that special handling.  BEHAVE didn't want the well-known prefix to work
differently than a site-specific NAT64 prefix.

-d


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


From n@arifumi.net  Sun Jan 27 23:13:31 2013
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 BCFF021F8903 for ; Sun, 27 Jan 2013 23:13:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEwfymRVjJxq for ; Sun, 27 Jan 2013 23:13:30 -0800 (PST)
Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by ietfa.amsl.com (Postfix) with ESMTP id E5A5E21F8450 for ; Sun, 27 Jan 2013 23:13:27 -0800 (PST)
Received: by mail-ve0-f175.google.com with SMTP id db12so1130339veb.34 for ; Sun, 27 Jan 2013 23:13:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=Gl2BtXf0/ORjG8qQ9aq7EVAtVPmdMa8hzEVpsVr3Vi4=; b=FRlrtVMStw97wJqGjx+6w5mcmUYeI4B1yhpHE1X+Mj0KAM/giWd1Og0g+KU9nUY1An QZ286Y5FiBW9PvE0EwQ7BkOiOUFDwEnQNTNv6wlx/ncCqPwXyBA9hkJZ9JOPrKRzjdDm 01NqFM437njG6E7bxcpVedn4urIw5EdFUNy1ZhMhh5M1QxfBdaafdAqmOuVHJW7Kb3FV QBRA11gfQLopVlvuAzjk0mM9kU/cSqQSUz2yANT8wQ+j4C2DQuZz7f3JB4J38gGof659 xwBwnV03I15NXDEjH2yRKXTvBx07BCxFBLt1yjKiYPfk3JYdnN4p2DU0axXonRV4ujFk FEMQ==
MIME-Version: 1.0
X-Received: by 10.220.149.82 with SMTP id s18mr14042648vcv.14.1359357206886; Sun, 27 Jan 2013 23:13:26 -0800 (PST)
Sender: n@arifumi.net
Received: by 10.58.180.201 with HTTP; Sun, 27 Jan 2013 23:13:26 -0800 (PST)
X-Originating-IP: [222.147.76.182]
In-Reply-To: <05f801cdfb17$a6dec7d0$f49c5770$@cisco.com>
References: <20130123210557.GA10474@simplex.0x539.de> <510103CC.1020709@viagenie.ca> <05f801cdfb17$a6dec7d0$f49c5770$@cisco.com>
Date: Mon, 28 Jan 2013 16:13:26 +0900
X-Google-Sender-Auth: U3X7G8Sq1fq5BmTiAKQB76DqxMQ
Message-ID: 
Subject: Re: RFC6724/RFC3484bis: Destination selection not considering well-known NAT64 prefix
From: Arifumi Matsumoto 
To: Dan Wing 
Content-Type: multipart/alternative; boundary=f46d043d64a370772704d45403e9
X-Gm-Message-State: ALoCoQk4XLqTN+Kt9DaJiriVsWnuSxbfE3eX3N9MM5LDVSIYCttIzA1RZ9HEvdmZ6hGx8Wy9T/Mf
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: Mon, 28 Jan 2013 07:13:31 -0000

--f46d043d64a370772704d45403e9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

this issue was also discussed here in 6man.
Please refer to the following thread.
http://www.ietf.org/mail-archive/web/ipv6/current/msg13709.html

The result of the discussion was described in the past version of
the RFC 6724. But, it looks it was removed when it was re-structured.

Thanks.


2013/1/26 Dan Wing 

> > -----Original Message-----
> > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> > Simon Perreault
> > Sent: Thursday, January 24, 2013 1:50 AM
> > To: ipv6@ietf.org
> > Subject: Re: RFC6724/RFC3484bis: Destination selection not considering
> > well-known NAT64 prefix
> >
> > Le 2013-01-23 22:05, Philipp Kern a =E9crit :
> > > was it a deliberate ommission that RFC6724 does not mention a
> > > precedence value for the well-known NAT64 prefix 64:ff9b::/96?
> > >
> > > If a host has both IPv4 and IPv6 configured it should probably use th=
e
> > > native
> > > IPv4 connectivity to connect to the target instead of the translated
> > > IPv6-to-IPv4 access.
> >
> > This has been discussed in BEHAVE numerous times. The current consensus
> > is: no, NAT64 is not "worse" than IPv4.
> >
> >  From the host's point of view, you don't know that IPv4 is not NATed a=
s
> > well. You don't even know if it is "native": it could be provided by DS=
-
> > Lite for all you know.
> >
> >  From the operator's point of view, if you deploy a NAT64 in a dual-
> > stack network, that probably means you *want* traffic to go over
> > NAT64 rather than over IPv4. You probably want *less* native IPv4
> > traffic in your network so that eventually you can make your network
> > fully IPv6-only.
>
> And also, if the host only has special handling for the well-known
> NAT64 prefix (64:ff9b::/96), that means networks that need to or decide
> to deploy their own, site-specific NAT64 prefix will not benefit from
> that special handling.  BEHAVE didn't want the well-known prefix to work
> differently than a site-specific NAT64 prefix.
>
> -d
>
>
> > Simon
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

--f46d043d64a370772704d45403e9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi,

this issue was also discussed=
 here in 6man.
Please refer to the following thread.
<=
div style>http://www.ietf.org/mail-archive/web/ipv6/current/msg13709.html<=
/a>






2013/1/26 Dan Wing <dwing@cisco.com>


> -----Original Message-----

> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of

> Simon Perreault

> Sent: Thursday, January 24, 2013 1:50 AM

> To: ipv6@ietf.org

> Subject: Re: RFC6724/RFC3484bis: Destination selection not considering=


> well-known NAT64 prefix

>


> Le 2013-01-23 22:05, Philipp Kern a =E9crit :<=
br>
> > was it a deliberate ommission that RFC6724 does not mention a

> > precedence value for the well-known NAT64 prefix 64:ff9b::/96?
> >

> > If a host has both IPv4 and IPv6 configured it should probably us=
e the

> > native

> > IPv4 connectivity to connect to the target instead of the transla=
ted

> > IPv6-to-IPv4 access.

>

> This has been discussed in BEHAVE numerous times. The current consensu=
s

> is: no, NAT64 is not "worse" than IPv4.

>

> =A0From the host's point of view, you don't know that IPv4 is =
not NATed as

> well. You don't even know if it is "native": it could be=
 provided by DS-

> Lite for all you know.

>

> =A0From the operator's point of view, if you deploy a NAT64 in a d=
ual-

> stack network, that probably means you *want* traffic to go over

> NAT64 rather than over IPv4. You probably want *less* native IPv4

> traffic in your network so that eventually you can make your network
> fully IPv6-only.




And also, if the host only has special handling for the well-known
NAT64 prefix (64:ff9b::/96), that means networks that need to or decide

to deploy their own, site-specific NAT64 prefix will not benefit from

that special handling. =A0BEHAVE didn't want the well-known prefix to w=
ork

differently than a site-specific NAT64 prefix.



-d






> Simon

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list

> ipv6@ietf.org

> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<=
br>
> --------------------------------------------------------------------


--------------------------------------------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

--------------------------------------------------------------------





--f46d043d64a370772704d45403e9--

From wesley.george@twcable.com  Mon Jan 28 07:11:53 2013
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 1B44721F87AA for ; Mon, 28 Jan 2013 07:11:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.563
X-Spam-Level: 
X-Spam-Status: No, score=-0.563 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 incy4963vwj1 for ; Mon, 28 Jan 2013 07:11:52 -0800 (PST)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAA721F879A for ; Mon, 28 Jan 2013 07:11:52 -0800 (PST)
X-SENDER-IP: 10.136.163.10
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.84,551,1355115600"; d="scan'208";a="17626173"
Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 28 Jan 2013 10:10:29 -0500
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Mon, 28 Jan 2013 10:11:48 -0500
From: "George, Wes" 
To: Simon Perreault , "ipv6@ietf.org" 
Date: Mon, 28 Jan 2013 10:11:52 -0500
Subject: RE: RFC6724/RFC3484bis: Destination selection not considering well-known NAT64 prefix
Thread-Topic: RFC6724/RFC3484bis: Destination selection not considering well-known NAT64 prefix
Thread-Index: Ac36GC5+xjAj/LS9Q8OioPQ/GibEiADT/CCg
Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923033D1FE772@PRVPEXVS15.corp.twcable.com>
References: <20130123210557.GA10474@simplex.0x539.de> <510103CC.1020709@viagenie.ca>
In-Reply-To: <510103CC.1020709@viagenie.ca>
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, 28 Jan 2013 15:11:53 -0000

> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> Simon Perreault
> Sent: Thursday, January 24, 2013 4:50 AM
> To: ipv6@ietf.org
> Subject: Re: RFC6724/RFC3484bis: Destination selection not considering
> well-known NAT64 prefix
>
>  From the host's point of view, you don't know that IPv4 is not NATed as
> well. You don't even know if it is "native": it could be provided by DS-
> Lite for all you know.
>
>  From the operator's point of view, if you deploy a NAT64 in a dual-
> stack network, that probably means you *want* traffic to go over
> NAT64 rather than over IPv4. You probably want *less* native IPv4
> traffic in your network so that eventually you can make your network
> fully IPv6-only.

[WEG] We've been discussing this on and off in sunset4 as well, and I have =
started to come to the conclusion that it's unlikely that there will be a s=
ingle correct answer in all cases, and so the better thing is to work towar=
d tools that allow the ISP to give the host some guidance about which addre=
ss family to choose in different situations, or at least give the host some=
 of the missing information about when something is being NATted or otherwi=
se translated upstream so that it can make its own decision.
While any guidance of this nature should be focused on giving the end host =
the best possible service regardless of the intended destination or protoco=
l, it could take into consideration the costs of different translation mode=
ls (stateful vs stateless) the absence or presence of a set of ALGs for cer=
tain applications, etc. It's still useful to have default recommendations, =
these would likely be ways to optimize certain scenarios based on specific =
use cases where it's better to make a different choice than what is recomme=
nded in this document.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From Fred.L.Templin@boeing.com  Mon Jan 28 10:16:23 2013
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 CDC4021F8928 for ; Mon, 28 Jan 2013 10:16:23 -0800 (PST)
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 zfuqpEkWQOml for ; Mon, 28 Jan 2013 10:16:23 -0800 (PST)
Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4209B21F8783 for ; Mon, 28 Jan 2013 10:16:23 -0800 (PST)
Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id r0SIGM4K009693 for ; Mon, 28 Jan 2013 12:16:22 -0600
Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id r0SIGLcU009670 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 28 Jan 2013 12:16:22 -0600
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Mon, 28 Jan 2013 10:16:21 -0800
From: "Templin, Fred L" 
To: Fernando Gont 
Date: Mon, 28 Jan 2013 10:16:19 -0800
Subject: RE: draft-generic-6man-tunfrag (was: Re: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments)
Thread-Topic: draft-generic-6man-tunfrag (was: Re: AD Evaluation: draft-ietf-6man-ipv6-atomic-fragments)
Thread-Index: Ac3yjt0teuqM9d0/R5uQoaj1oGUUOAK9KGKw
Message-ID: 
References: <50CA2508.1030003@innovationslab.net> <50CF402E.80706@si6networks.com> <50D09AAE.6000601@innovationslab.net>  <50D0CB40.5070103@si6networks.com>  <50D3EF04.4060004@si6networks.com>  <50F45ED4.9030209@si6networks.com>
In-Reply-To: <50F45ED4.9030209@si6networks.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-TM-AS-MML: No
Cc: 6man WG 
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, 28 Jan 2013 18:16:23 -0000

Hi Fernado,

Any progress on this?

Thanks - Fred

> -----Original Message-----
> From: Fernando Gont [mailto:fgont@si6networks.com]
> Sent: Monday, January 14, 2013 11:39 AM
> To: Templin, Fred L
> Cc: 6man WG
> Subject: draft-generic-6man-tunfrag (was: Re: AD Evaluation: draft-ietf-
> 6man-ipv6-atomic-fragments)
>=20
> On 01/14/2013 04:31 PM, Templin, Fred L wrote:
> >> I will review your I-D and will come back with some feedback.
> >
> > I was wondering if you have had a chance to look at my document
> > on "IPv6 Path MTU Updates" yet:
> >
> > https://datatracker.ietf.org/doc/draft-generic-6man-tunfrag/
> >
> > I have posted a new version since we spoke last, which clarifies
> > a number of points and now speaks more generically about links
> > that perform link adaptation rather than just about tunnels. I
> > would welcome your comments on the document.
>=20
> My apologies -- I promise I'll post my feedback no later than the next
> couple of days.
>=20
> Thanks!
>=20
> Best regards,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>=20
>=20
>=20


From dwing@cisco.com  Mon Jan 28 15:06:04 2013
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 75C8F21E8034 for ; Mon, 28 Jan 2013 15:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.094
X-Spam-Level: 
X-Spam-Status: No, score=-109.094 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 co-7fID+Z3If for ; Mon, 28 Jan 2013 15:06:03 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9436C21E8030 for ; Mon, 28 Jan 2013 15:06:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5523; q=dns/txt; s=iport; t=1359414363; x=1360623963; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=LXihKE8W/Q38OgephLbmHGWtbAJ2Qdvk9QU6cl8jLbk=; b=PuOTo4cjCJ7T57fDntp9ObsD0Xzke5x+qejoXunM+J2rEjEfSsMsxdVt RuWHB6HtGUbb7/VIPIVcYk2qx6ujGU8NrLZg+ueNnpoisz1nONKiFvG8C +WoiOiD8zOuquyglUg1D+AB3ngCLo7DLLpvKhFB50FYZpheMaym3Km0IR g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAI0DB1GrRDoI/2dsb2JhbABEvlgWc4IeAQEBAwEBAQEFAmQLBQcBAwIJEQEDAQEoBxkOHwMGCAIEARIJAgWHewUNwCWNGoQLA4gsNYUdiA+QSIMYgU4
X-IronPort-AV: E=Sophos;i="4.84,555,1355097600"; d="scan'208";a="69918143"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 28 Jan 2013 23:06:03 +0000
Received: from DWINGWS01 ([10.32.240.198]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0SN629C026653; Mon, 28 Jan 2013 23:06:02 GMT
From: "Dan Wing" 
To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" , "'Bob Hinden'" 
References: 
In-Reply-To: 
Subject: RE: 4rd IID range & IPv6 addressing architecture
Date: Mon, 28 Jan 2013 15:06:02 -0800
Message-ID: <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJrM5MzC0MS5u2jjrYoKuDngmhZ6Zck78Dg
Content-Language: en-us
Cc: '6man 6man-wg' 
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, 28 Jan 2013 23:06:04 -0000

> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf =
Of
> R=E9mi Despr=E9s
> Sent: Monday, January 21, 2013 8:20 AM
> To: Bob Hinden
> Cc: 6man 6man-wg
> Subject: 4rd IID range & IPv6 addressing architecture
>=20
> Hi, Bob,
>=20
> The discussion on whether the proposed 4rd IID range is "compatible =
with
> the IPv6 addressing architecture" has apparently come to a standstill.
> Yet an answer of 6man to Softwire is expected.
>=20
> A. To help making a WG decision, here are key points that, in my
> understanding, emerged from the discussion.
>=20
> (a) Ray Hunter has provided a reference to RFC5342 which confirms =
that,
> in RFC 4291 compliant addresses, u=3Dg=3D1 is "currently unused"
> (www.ietf.org/mail-archive/web/ipv6/current/msg16890.html). 4rd
> addresses, which have u=3Dg=3D1, therefore cannot conflict with =
current
> addresses of the IPv6 addressing architecture. (In particular, they
> don't conflict with those of RFC6740 ILNP.)
>=20
> (b) Brian Carpenter pointed out that a 16-bit prefix would be =
sufficient
> for 4rd, taking less IID space than the currently proposed 8-bit =
prefix.
> This being acknowledged, the 0x0300 prefix can without problem replace
> the 0x03 prefix. (This doesn't change the 4rd specification which
> already has a 0x00 after 0x03.) With this prefix, the reserved range
> uses only 1/2^14 of the unused set of IIDs having u=3Dg=3D1 is =
reserved.
> This leaves plenty of space for future uses of IIDs having u=3D1 =
(future
> uses explicitly envisaged in RFC 4291).
>=20
> (c) Jouni Korhonen pointed out that there is already an IANA registry
> for reserved IID ranges, and Simon Perreault gave the correct pointer =
to
> it (http://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-
> ids.xml).
>=20
> (d) Suresh Krishnan pointed out that, according to RFC 5453, this
> registry is so far reserved for standard-track RFCs, the reason being
> "to minimize disruption to existing implementations". Although 4rd has
> been purposely designed so that it cannot disturb any existing
> implementation (precisely by using a currently unused IID range), the
> proposed 4rd range can be endorsed by IANA only if an RFC updates RFC
> 5453, explaining why a 4rd IID range can be safely assigned despite =
its
> experimental status.
> - If agreed on the principle, and if no one else volunteers, I can be
> available to propose a draft to this effect.

Seems reasonable.


> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
> IIDs having u=3Dg=3D1 is reserved. This leaves plenty of space for =
future
> uses of IIDs having u=3D1, as explicitly expected in RFC 4291.

That goes to the argument of (d), that it isn't harmful to assign
some space to 4rd.

-d


> With this, 6man can IMHO answer that Softwire can proceed with 4rd,
> provided:
> - the 16-bit IID prefix 0x0300 replaces the current 0x03
> - it is understood that IANA won't register this IID range before a =
6man
> RFC permits it for this experimental-track RFC.
>=20
> No technically founded objection remains AFAIK, but if any one still
> holds it has of course to be expressed and discussed.
>=20
>=20
>=20
> B. For those who are interested in a detailed summary of objections =
that
> were made, and have been answered, here is what I noted:
>=20
> (i) If IETF uses u=3Dg=3D1 in some unicast addresses, IEEE would have =
to be
> involved.
> - Because 4rd IIDs are never to be used in any MAC-layer addresses. =
IEEE
> isn't concerned.
>=20
> (j) 4rd could work without a reserved range.
> - As discussed in Softwire, reserving an IID range is key to satisfy =
the
> objective that "4rd IPv6 addresses are recognizable by CEs without any
> interference with the choice of subnet prefixes in CE sites".
>=20
> (k) An IID range using the IANA OUI with u=3D1 and g=3D0 would have =
been
> sufficient.
> - As discussed in Softwire, this wouldn't have left enough IID bits to
> contain the IPv4 address and the 16-bit CNP, which are both needed in
> 4rd.
>=20
> (l) A 4rd-specific destination header could have been used instead of =
an
> IID-range.
> -  An extra header would have defeated the 4rd objective that its
> "tunnel packets are valid IPv6 packets for all layer-4 protocols that
> use the same checksum algorithm as TCP".
>=20
> (m) With a "reserved /64 on the customers delegated prefix for the =
sole
> use of 4rd",and 4rd nodes protecting "all possible 4rd interface-ids
> using DAD", a reserved range could have been avoided.
> - This wouldn't work for IID assignments made before 4rd activation,
> while 4rd is designed to cover this case too. (Note also that 4rd
> implementations can add, on their LAN sides, exclusion of all =
addresses
> having the 4rd IID prefix. Although this isn't strictly needed, this =
can
> permit early detection of some erroneous manual configurations, and is
> easy to do due to the 4rd IID prefix being a constant.
>=20
> (n) 4rd would fail if a customer link has two 4rd CEs.
> - After discussion, no issue on this has been kept in Softwire.
>=20
>=20
>=20
> Best regards,
> RD
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From otroan@employees.org  Tue Jan 29 05:18:10 2013
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 611EA21F87CE for ; Tue, 29 Jan 2013 05:18:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.569
X-Spam-Level: 
X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 bPPsLyvqfFsf for ; Tue, 29 Jan 2013 05:18:10 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A8B6C21F87DF for ; Tue, 29 Jan 2013 05:18:09 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.84,559,1355097600"; d="scan'208";a="149897865"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 29 Jan 2013 13:18:09 +0000
Received: from dhcp-lys01-vla250-10-147-112-56.cisco.com (dhcp-lys01-vla250-10-147-112-56.cisco.com [10.147.112.56]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0TDI8a5019966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Jan 2013 13:18:08 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: Ole Troan 
In-Reply-To: <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>
Date: Tue, 29 Jan 2013 14:18:08 +0100
Content-Transfer-Encoding: 7bit
Message-Id: 
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>
To: Dan Wing 
X-Mailer: Apple Mail (2.1499)
Cc: '6man 6man-wg' , '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, 29 Jan 2013 13:18:10 -0000

[...]

>> - If agreed on the principle, and if no one else volunteers, I can be
>> available to propose a draft to this effect.
> 
> Seems reasonable.
> 
> 
>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>> IIDs having u=g=1 is reserved. This leaves plenty of space for future
>> uses of IIDs having u=1, as explicitly expected in RFC 4291.
> 
> That goes to the argument of (d), that it isn't harmful to assign
> some space to 4rd.

I still think we need to answer the question Brian raised.
should the interface-id have any encoded meaning?

cheers,
Ole

From sander@steffann.nl  Tue Jan 29 06:29:48 2013
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 2396321F886E for ; Tue, 29 Jan 2013 06:29:48 -0800 (PST)
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.001,  BAYES_00=-2.599, NO_RELAYS=-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 FMbMvRozljMK for ; Tue, 29 Jan 2013 06:29:46 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50321F8863 for ; Tue, 29 Jan 2013 06:29:46 -0800 (PST)
Received: from [IPv6:2a02:88fe:de30:1104:f413:1210:f9c1:b76f] (unknown [IPv6:2a02:88fe:de30:1104:f413:1210:f9c1:b76f]) by mail.sintact.nl (Postfix) with ESMTP id E37B12054; Tue, 29 Jan 2013 15:29:44 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: Sander Steffann 
In-Reply-To: 
Date: Tue, 29 Jan 2013 14:29:43 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AF2F1F1-487D-4D36-9863-722B1C417F69@steffann.nl>
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com> 
To: Ole Troan 
X-Mailer: Apple Mail (2.1499)
Cc: 'Bob Hinden' , '6man 6man-wg' 
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, 29 Jan 2013 14:29:48 -0000

Hi,

> I still think we need to answer the question Brian raised.
> should the interface-id have any encoded meaning?

I don't see any benefit of certain bits in the interface-id having =
special meanings, but that might be because of a lack of vision on my =
side :-)

- Sander


From brian.e.carpenter@gmail.com  Tue Jan 29 06:32:05 2013
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 A82F521F842F for ; Tue, 29 Jan 2013 06:32:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.422
X-Spam-Level: 
X-Spam-Status: No, score=-101.422 tagged_above=-999 required=5 tests=[AWL=0.269, 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 II30XGkd88fS for ; Tue, 29 Jan 2013 06:32:05 -0800 (PST)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id E8FE321F886E for ; Tue, 29 Jan 2013 06:32:04 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id hn17so2504173wib.6 for ; Tue, 29 Jan 2013 06:32:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AtCb5nbfrIg8QOOK4Mafjgsw+VpicmvOsgpqS6uWi7w=; b=T3jGl9b21uBmDwZmhYV16gX6nbVWofjP2Gxqg7F5oEwfJeZGSPOlUswV31lQK11d8I DcYrcAZqHcxcYnWpTvAqia0Jckr4foyoBPxE78mQ1878x+JdQrXuyBoioZn4FzWWLxRK A7th26ac0z0A/m2kOyVuslH61EBMGEK3NIkNNEAdkWFMaSZuHjXXRMWUmVnvF3UlYGei W5BHivtqIbLW+Pa6Mwq/DK/WdCe1V0W7VwL5SydMLT/6PKm516WoPMqu4oUXSi56Eu6h RyB2BGynaQu6C6hM1XVSyhqv7p4of9Lka2SySwp7g/gPFL/h/4oU3Tf3F0f7IjXR38ro Q/hA==
X-Received: by 10.194.109.10 with SMTP id ho10mr2883863wjb.16.1359469924058; Tue, 29 Jan 2013 06:32:04 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-217-172.as13285.net. [2.102.217.172]) by mx.google.com with ESMTPS id w5sm3337639wif.11.2013.01.29.06.32.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 06:32:02 -0800 (PST)
Message-ID: <5107DD67.1000502@gmail.com>
Date: Tue, 29 Jan 2013 14:32:07 +0000
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ole Troan 
Subject: Re: 4rd IID range & IPv6 addressing architecture
References: 	<02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: 'Bob Hinden' , '6man 6man-wg' 
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, 29 Jan 2013 14:32:05 -0000

On 29/01/2013 13:18, Ole Troan wrote:
> [...]
>=20
>>> - If agreed on the principle, and if no one else volunteers, I can be=

>>> available to propose a draft to this effect.
>> Seems reasonable.
>>
>>
>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>> IIDs having u=3Dg=3D1 is reserved. This leaves plenty of space for fu=
ture
>>> uses of IIDs having u=3D1, as explicitly expected in RFC 4291.
>> That goes to the argument of (d), that it isn't harmful to assign
>> some space to 4rd.
>=20
> I still think we need to answer the question Brian raised.
> should the interface-id have any encoded meaning?

That will not be done overnight. I've been thinking about it and
have some ideas about how to write a discussion draft, but it is
unfortuante to make the 4rd work queue behind us. Is there any risk
in doing as R=C3=A9mi suggested?

On 21/01/2013 16:19, R=C3=A9mi Despr=C3=A9s wrote:
=2E..
> With this, 6man can IMHO answer that Softwire can proceed with 4rd, pro=
vided:
> - the 16-bit IID prefix 0x0300 replaces the current 0x03
> - it is understood that IANA won't register this IID range before a 6ma=
n RFC permits it for this experimental-track RFC.

    Brian


From otroan@employees.org  Tue Jan 29 09:28:26 2013
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 00BEB21F8A30 for ; Tue, 29 Jan 2013 09:28:26 -0800 (PST)
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 pfoEKabzxH51 for ; Tue, 29 Jan 2013 09:28:25 -0800 (PST)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 751A221F8A06 for ; Tue, 29 Jan 2013 09:28:25 -0800 (PST)
Received: from otroan-mac.getinternet.no (cm-84.209.200.28.getinternet.no [84.209.200.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id E30245E14; Tue, 29 Jan 2013 09:28:23 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: Ole Troan 
In-Reply-To: <5107DD67.1000502@gmail.com>
Date: Tue, 29 Jan 2013 18:28:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 	<02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1499)
Cc: 'Bob Hinden' , '6man 6man-wg' 
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, 29 Jan 2013 17:28:26 -0000

Brian,

>>>> - If agreed on the principle, and if no one else volunteers, I can =
be
>>>> available to propose a draft to this effect.
>>> Seems reasonable.
>>>=20
>>>=20
>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set =
of
>>>> IIDs having u=3Dg=3D1 is reserved. This leaves plenty of space for =
future
>>>> uses of IIDs having u=3D1, as explicitly expected in RFC 4291.
>>> That goes to the argument of (d), that it isn't harmful to assign
>>> some space to 4rd.
>>=20
>> I still think we need to answer the question Brian raised.
>> should the interface-id have any encoded meaning?
>=20
> That will not be done overnight. I've been thinking about it and
> have some ideas about how to write a discussion draft, but it is
> unfortuante to make the 4rd work queue behind us. Is there any risk
> in doing as R=E9mi suggested?

it depends on what the expected meaning of a reservation is.
should all implementations treat the reserved part of the interface-id =
as martian,
and prohibit a user from configuring it for another purpose than 4rd?

or is it just a 'suggestion' for interface-id's that the 4rd mechanism =
can use, and the operator
deploying it will make sure there are no conflicts?

one of my concerns is that continuing to add the interface-id bits, is =
the opposite direction of where
I want us to go.

I wouldn't object to non-normative language in 4rd suggesting a =
interface-id to use, without
creating any expectation that new or existing IPv6 implementations have =
to change.

that said, 4rd will work perfectly well _without_ this reservation, so I =
don't buy the argument that
we're holding up the 4rd work.

cheers,
Ole


From randy@psg.com  Tue Jan 29 16:15:02 2013
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 C17C421F8873 for ; Tue, 29 Jan 2013 16:15:01 -0800 (PST)
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 1AcSGZLOK4GV for ; Tue, 29 Jan 2013 16:15:01 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4718321F885C for ; Tue, 29 Jan 2013 16:14:56 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U0LKJ-0008Fn-OF; Wed, 30 Jan 2013 00:14:56 +0000
Date: Wed, 30 Jan 2013 09:14:54 +0900
Message-ID: 
From: Randy Bush 
To: Ole Troan 
Subject: Re: 4rd IID range & IPv6 addressing architecture
In-Reply-To: 
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.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 Deployment Prevention 
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, 30 Jan 2013 00:15:02 -0000

> should the interface-id have any encoded meaning?

having spent a decade+ fighting to throw magic bits out of ipv6
addressing (remember tla?), i find this disturbing.

randy

From fgont@si6networks.com  Tue Jan 29 17:20:01 2013
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 3CECE21F888F for ; Tue, 29 Jan 2013 17:20:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.04
X-Spam-Level: 
X-Spam-Status: No, score=-3.04 tagged_above=-999 required=5 tests=[AWL=0.559,  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 nf3choT8xH-W for ; Tue, 29 Jan 2013 17:20:00 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5A221F8671 for ; Tue, 29 Jan 2013 17:19:57 -0800 (PST)
Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U0MKS-000779-SG; Wed, 30 Jan 2013 02:19:09 +0100
Message-ID: <510874C0.8070209@si6networks.com>
Date: Tue, 29 Jan 2013 22:17:52 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: Ole Troan 
Subject: Re: 4rd IID range & IPv6 addressing architecture
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com> 
In-Reply-To: 
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: 'Bob Hinden' , '6man 6man-wg' 
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, 30 Jan 2013 01:20:01 -0000

On 01/29/2013 10:18 AM, Ole Troan wrote:
> [...]
>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>> IIDs having u=g=1 is reserved. This leaves plenty of space for future
>>> uses of IIDs having u=1, as explicitly expected in RFC 4291.
>>
>> That goes to the argument of (d), that it isn't harmful to assign
>> some space to 4rd.
> 
> I still think we need to answer the question Brian raised.
> should the interface-id have any encoded meaning?

The only point having an encoding meaning is that, *in theory*, if you
have a Universal/Local bit, and you have a source of universal
identifiers, then you could tell beforehand that you're not going to
have address collisions. However,

* Practice indicates that "universal" identifiers are reused
(virtualization software being just one example). And when you find a
collision, you still need some other scheme to generate the IIDs (or
else, how are you going to solve the DAD failure).

* You'd need some coordination to separate the different namespaces
(that's why we stuff the fffe for IEEE Identifiers, right?)

* We must implement slaac anyway, so.. who cares about the
aforementioned uniqueness?

* Those universal identifiers bring patters, which are undesirable (see
e.g. draft-ietf-opsec-ipv6-host-scanning).

For the stable addresses, what we should be doing is replace the
IEEE-derived scheme with draft-ietf-6man-stable-privacy-addresses, and
be done with it. (probably eminating that of clearing the U bit in the
IID, though).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From internet-drafts@ietf.org  Tue Jan 29 17:42:01 2013
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 61ED421F8991; Tue, 29 Jan 2013 17:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 YeNDVeMGcCa1; Tue, 29 Jan 2013 17:42:00 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05A621F874E; Tue, 29 Jan 2013 17:42:00 -0800 (PST)
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-stable-privacy-addresses-03.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 4.37
Message-ID: <20130130014200.25208.35907.idtracker@ietfa.amsl.com>
Date: Tue, 29 Jan 2013 17:42:00 -0800
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, 30 Jan 2013 01:42:01 -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           : A method for Generating Stable Privacy-Enhanced Addresse=
s with IPv6 Stateless Address Autoconfiguration (SLAAC)
	Author(s)       : Fernando Gont
	Filename        : draft-ietf-6man-stable-privacy-addresses-03.txt
	Pages           : 18
	Date            : 2013-01-29

Abstract:
   This document specifies a method for generating IPv6 Interface
   Identifiers to be used with IPv6 Stateless Address Autoconfiguration
   (SLAAC), such that addresses configured using this method are stable
   within each subnet, but the Interface Identifier changes when hosts
   move from one network to another.  The aforementioned method is meant
   to be an alternative to generating Interface Identifiers based on
   IEEE identifiers, such that the benefits of stable addresses can be
   achieved without sacrificing the privacy of users.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-stable-privacy-addresses=
-03


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From fgont@si6networks.com  Tue Jan 29 17:51:33 2013
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 3964221F886D for ; Tue, 29 Jan 2013 17:51:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.133
X-Spam-Level: 
X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=0.466,  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 voGfjUfDDTaq for ; Tue, 29 Jan 2013 17:51:28 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id DE6F121F8696 for ; Tue, 29 Jan 2013 17:51:25 -0800 (PST)
Received: from 95-132-17-190.fibertel.com.ar ([190.17.132.95] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U0Mp7-0007vL-5H; Wed, 30 Jan 2013 02:51:19 +0100
Message-ID: <51087C12.7010907@si6networks.com>
Date: Tue, 29 Jan 2013 22:49:06 -0300
From: Fernando Gont 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>
Subject: Re: I-D Action: draft-ietf-6man-stable-privacy-addresses-03.txt
References: <20130130014200.25208.35907.idtracker@ietfa.amsl.com>
In-Reply-To: <20130130014200.25208.35907.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
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, 30 Jan 2013 01:51:33 -0000

Ole,

It's been a month since I received your last message regarding this I-D.

Can we ship this document now?

P.S.: This latest version addresses the feedback received from Tassos
(I've double-checked with him that his comments have been addressed).

Thanks,
Fernando




On 01/29/2013 10:42 PM, 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           : A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)
> 	Author(s)       : Fernando Gont
> 	Filename        : draft-ietf-6man-stable-privacy-addresses-03.txt
> 	Pages           : 18
> 	Date            : 2013-01-29
> 
> Abstract:
>    This document specifies a method for generating IPv6 Interface
>    Identifiers to be used with IPv6 Stateless Address Autoconfiguration
>    (SLAAC), such that addresses configured using this method are stable
>    within each subnet, but the Interface Identifier changes when hosts
>    move from one network to another.  The aforementioned method is meant
>    to be an alternative to generating Interface Identifiers based on
>    IEEE identifiers, such that the benefits of stable addresses can be
>    achieved without sacrificing the privacy of users.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-03
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-stable-privacy-addresses-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
> --------------------------------------------------------------------
> 


-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From despres.remi@laposte.net  Wed Jan 30 05:20:51 2013
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 B5BCE21F8A1C for ; Wed, 30 Jan 2013 05:20:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level: 
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.056,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 kURJ0LGUGNf5 for ; Wed, 30 Jan 2013 05:20:47 -0800 (PST)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4A521F8A0C for ; Wed, 30 Jan 2013 05:20:46 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 90E497000133; Wed, 30 Jan 2013 14:20:45 +0100 (CET)
Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 6BA8D700012F; Wed, 30 Jan 2013 14:20:45 +0100 (CET)
X-SFR-UUID: 20130130132045441.6BA8D700012F@msfrf2413.sfr.fr
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Wed, 30 Jan 2013 14:20:46 +0100
Message-Id: <4A473B97-DBDD-4008-A025-DA27CDB645A7@laposte.net>
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com> 
To: Ole Troan 
X-Mailer: Apple Mail (2.1499)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: '6man 6man-wg' , 'Bob Hinden' 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 13:20:51 -0000

2013-01-29  18:28, Ole Troan   :

...
>>> I still think we need to answer the question Brian raised.
>>> should the interface-id have any encoded meaning?
>>=20
>> That will not be done overnight. I've been thinking about it and
>> have some ideas about how to write a discussion draft, but it is
>> unfortuante to make the 4rd work queue behind us. Is there any risk
>> in doing as R=E9mi suggested?
>=20
> it depends on what the expected meaning of a reservation is.
> should all implementations treat the reserved part of the interface-id =
as martian,

No.

> and prohibit a user from configuring it for another purpose than 4rd?

Already done since, today, no RFC4291 unicast address may have u=3Dg=3D1 =
(a point confirmed during the discussion).=20

>=20
> or is it just a 'suggestion' for interface-id's that the 4rd mechanism =
can use, and the operator
> deploying it will make sure there are no conflicts?
>=20
> one of my concerns is that continuing to add the interface-id bits, is =
the opposite direction of where
> I want us to go.

Unless you want to modify RFC4291 without backward compatibility, I =
don't see why using an unused IID range having u=3D1 could be harmful.=20=

("The use of the universal/local bit in the Modified EUI-64 format =
identifier is to allow development of future technology that can take =
advantage of interface identifiers with universal scope").


> I wouldn't object to non-normative language in 4rd suggesting a =
interface-id to use, without
> creating any expectation that new or existing IPv6 implementations =
have to change.

On this, we agree: the fact that 4rd needs no change of existing IPv6 =
implementations that don't support is key.

The RFC that is needed to reserve a 4rd IID-range despite its being =
experimental is, in my understanding, the natural place to make this =
clear.


> that said, 4rd will work perfectly well _without_ this reservation, so =
I don't buy the argument that
> we're holding up the 4rd work.

As explained in various ways several times, reserving a currently unused =
IID range ensure that, when 4rd is activated in customer site, no =
renumbering of any RFC-compliant link or host is necessary. Without =
that, 4rd wouldn't be up to its objectives.

regards,
RD


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

From otroan@employees.org  Wed Jan 30 05:34:47 2013
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 6105E21F8AEA for ; Wed, 30 Jan 2013 05:34:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.51
X-Spam-Level: 
X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[AWL=-1.011,  BAYES_00=-2.599, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, 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 xI9Zbb2jLtgV for ; Wed, 30 Jan 2013 05:34:46 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFDE21F8A0C for ; Wed, 30 Jan 2013 05:34:46 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAP4fCVGQ/khL/2dsb2JhbABFvxIWc4IeAQEEAWcSEAsSNEkOBogeBsFOkClhA6ZYgng
X-IronPort-AV: E=Sophos;i="4.84,568,1355097600"; d="scan'208";a="80118207"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 30 Jan 2013 13:34:44 +0000
Received: from dhcp-lys02-vla252-10-147-116-47.cisco.com (dhcp-lys02-vla252-10-147-116-47.cisco.com [10.147.116.47]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0UDYi82008519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jan 2013 13:34:44 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: Ole Troan 
In-Reply-To: <4A473B97-DBDD-4008-A025-DA27CDB645A7@laposte.net>
Date: Wed, 30 Jan 2013 14:34:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <19C98DE3-361D-4875-86C3-15314B796A05@employees.org>
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <4A473B97-DBDD-4008-A025-DA27CDB645A7@laposte.net>
To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= 
X-Mailer: Apple Mail (2.1499)
Cc: '6man 6man-wg' , 'Bob Hinden' 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 13:34:47 -0000

Remi,

>>>> I still think we need to answer the question Brian raised.
>>>> should the interface-id have any encoded meaning?
>>>=20
>>> That will not be done overnight. I've been thinking about it and
>>> have some ideas about how to write a discussion draft, but it is
>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>> in doing as R=E9mi suggested?
>>=20
>> it depends on what the expected meaning of a reservation is.
>> should all implementations treat the reserved part of the =
interface-id as martian,
>=20
> No.
>=20
>> and prohibit a user from configuring it for another purpose than 4rd?
>=20
> Already done since, today, no RFC4291 unicast address may have u=3Dg=3D1=
 (a point confirmed during the discussion).=20

apologies for being a little flippant.
but that point isn't confirmed.

actually I'm using that space:

otroan@ubuntu:~/src/as$ ifconfig lo
lo        Link encap:Local Loopback =20
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: 2001:db8::ffff:0:0:1/64 Scope:Global
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:354 errors:0 dropped:0 overruns:0 frame:0
          TX packets:354 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0=20
          RX bytes:44161 (44.1 KB)  TX bytes:44161 (44.1 KB)

otroan@ubuntu:~/src/as$ sudo ip addr add 2001:db8:0000:0000:FFFF::1/64 =
dev lo

>> or is it just a 'suggestion' for interface-id's that the 4rd =
mechanism can use, and the operator
>> deploying it will make sure there are no conflicts?
>>=20
>> one of my concerns is that continuing to add the interface-id bits, =
is the opposite direction of where
>> I want us to go.
>=20
> Unless you want to modify RFC4291 without backward compatibility, I =
don't see why using an unused IID range having u=3D1 could be harmful.=20=

> ("The use of the universal/local bit in the Modified EUI-64 format =
identifier is to allow development of future technology that can take =
advantage of interface identifiers with universal scope").

yes, that technology is called ILNP. it does not require globally unique =
interface identifiers.
which in any case would have required some sort of registry.

>> I wouldn't object to non-normative language in 4rd suggesting a =
interface-id to use, without
>> creating any expectation that new or existing IPv6 implementations =
have to change.
>=20
> On this, we agree: the fact that 4rd needs no change of existing IPv6 =
implementations that don't support is key.
>=20
> The RFC that is needed to reserve a 4rd IID-range despite its being =
experimental is, in my understanding, the natural place to make this =
clear.

my argument is that you don't need a reservation.

>> that said, 4rd will work perfectly well _without_ this reservation, =
so I don't buy the argument that
>> we're holding up the 4rd work.
>=20
> As explained in various ways several times, reserving a currently =
unused IID range ensure that, when 4rd is activated in customer site, no =
renumbering of any RFC-compliant link or host is necessary. Without =
that, 4rd wouldn't be up to its objectives.

if we agree that the interface-id is just 64bits of nothingness, then =
there is no such thing as an unused IID space.
pick whatever you like for the 4rd IID, but your protocol needs to deal =
with collisions.

cheers,
Ole=

From sander@steffann.nl  Wed Jan 30 06:13:10 2013
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 4E49621F8AF4 for ; Wed, 30 Jan 2013 06:13:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-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 EHFo7M6OhFQS for ; Wed, 30 Jan 2013 06:13:09 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 4A73621F8AD0 for ; Wed, 30 Jan 2013 06:13:08 -0800 (PST)
Received: from [IPv6:2a02:88fe:de30:401:eca4:6c1:3035:613c] (unknown [IPv6:2a02:88fe:de30:401:eca4:6c1:3035:613c]) by mail.sintact.nl (Postfix) with ESMTP id F2E96201E; Wed, 30 Jan 2013 15:13:06 +0100 (CET)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: Sander Steffann 
In-Reply-To: <19C98DE3-361D-4875-86C3-15314B796A05@employees.org>
Date: Wed, 30 Jan 2013 14:13:01 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <4A473B97-DBDD-4008-A025-DA27CDB645A7@laposte.net> <19C98DE3-361D-4875-86C3-15314B796A05@employees.org>
To: Ole Troan 
X-Mailer: Apple Mail (2.1499)
Cc: 'Bob Hinden' , '6man 6man-wg' 
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, 30 Jan 2013 14:13:10 -0000

Hi,

> if we agree that the interface-id is just 64bits of nothingness, then =
there is no such thing as an unused IID space.
> pick whatever you like for the 4rd IID, but your protocol needs to =
deal with collisions.


Dealing with collisions is very probably necessary anyway (virtual =
machine cloning was already mentioned as a potential cause of =
conflicts). I think this is the right approach.

- Sander


From despres.remi@laposte.net  Wed Jan 30 06:32:28 2013
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 A742E21F84E9 for ; Wed, 30 Jan 2013 06:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level: 
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, 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 IPSPIThZOwVb for ; Wed, 30 Jan 2013 06:32:27 -0800 (PST)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9867A21F84BF for ; Wed, 30 Jan 2013 06:32:27 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 4CDA37000157; Wed, 30 Jan 2013 15:32:24 +0100 (CET)
Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 295C77000155; Wed, 30 Jan 2013 15:32:24 +0100 (CET)
X-SFR-UUID: 20130130143224169.295C77000155@msfrf2413.sfr.fr
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= 
In-Reply-To: <19C98DE3-361D-4875-86C3-15314B796A05@employees.org>
Date: Wed, 30 Jan 2013 15:32:25 +0100
Message-Id: 
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <4A473B97-DBDD-4008-A025-DA27CDB645A7@laposte.net> <19C98DE3-361D-4875-86C3-15314B796A05@employees.org>
To: Ole Troan 
X-Mailer: Apple Mail (2.1499)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: '6man 6man-wg' , 'Bob Hinden' 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 14:32:28 -0000

Le 2013-01-30 =E0 14:34, Ole Troan  a =E9crit :

> Remi,
>=20
>>>>> I still think we need to answer the question Brian raised.
>>>>> should the interface-id have any encoded meaning?
>>>>=20
>>>> That will not be done overnight. I've been thinking about it and
>>>> have some ideas about how to write a discussion draft, but it is
>>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>>> in doing as R=E9mi suggested?
>>>=20
>>> it depends on what the expected meaning of a reservation is.
>>> should all implementations treat the reserved part of the =
interface-id as martian,
>>=20
>> No.
>>=20
>>> and prohibit a user from configuring it for another purpose than =
4rd?
>>=20
>> Already done since, today, no RFC4291 unicast address may have u=3Dg=3D=
1 (a point confirmed during the discussion).=20
>=20
> apologies for being a little flippant.

Your apologies are welcome (see below).


> but that point isn't confirmed.
>=20
> actually I'm using that space:
>=20
> otroan@ubuntu:~/src/as$ ifconfig lo
> lo        Link encap:Local Loopback =20
>          inet addr:127.0.0.1  Mask:255.0.0.0
>          inet6 addr: 2001:db8::ffff:0:0:1/64 Scope:Global
>          inet6 addr: ::1/128 Scope:Host
>          UP LOOPBACK RUNNING  MTU:16436  Metric:1
>          RX packets:354 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:354 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:0=20
>          RX bytes:44161 (44.1 KB)  TX bytes:44161 (44.1 KB)
>=20
> otroan@ubuntu:~/src/as$ sudo ip addr add 2001:db8:0000:0000:FFFF::1/64 =
dev lo

Independently of the above details, address 2001:db8::ffff:0:0:1 isn't =
an RFC4269-compliant address! (My sentence was only about RFC4269 =
addresses.)=20

Incidentally:
- Note that the particular IID of this address has no conflict with the =
proposed 4rd IID range. It can coexist without any risk.
- Why don't you ask for reserving this IID for your particular =
application? This would eliminate the risk of someone else taking the =
same for another manual configuration (i.e. one that DAD doesn't  =
repair).


>>> or is it just a 'suggestion' for interface-id's that the 4rd =
mechanism can use, and the operator
>>> deploying it will make sure there are no conflicts?
>>>=20
>>> one of my concerns is that continuing to add the interface-id bits, =
is the opposite direction of where
>>> I want us to go.
>>=20
>> Unless you want to modify RFC4291 without backward compatibility, I =
don't see why using an unused IID range having u=3D1 could be harmful.=20=

>> ("The use of the universal/local bit in the Modified EUI-64 format =
identifier is to allow development of future technology that can take =
advantage of interface identifiers with universal scope").
>=20
> yes, that technology is called ILNP. it does not require globally =
unique interface identifiers.
> which in any case would have required some sort of registry.

ILNP, which has u=3D0.
Out of scope!

>=20
>>> I wouldn't object to non-normative language in 4rd suggesting a =
interface-id to use, without
>>> creating any expectation that new or existing IPv6 implementations =
have to change.
>>=20
>> On this, we agree: the fact that 4rd needs no change of existing IPv6 =
implementations that don't support is key.
>>=20
>> The RFC that is needed to reserve a 4rd IID-range despite its being =
experimental is, in my understanding, the natural place to make this =
clear.
>=20
> my argument is that you don't need a reservation.
>=20
>>> that said, 4rd will work perfectly well _without_ this reservation, =
so I don't buy the argument that
>>> we're holding up the 4rd work.
>>=20
>> As explained in various ways several times, reserving a currently =
unused IID range ensure that, when 4rd is activated in customer site, no =
renumbering of any RFC-compliant link or host is necessary. Without =
that, 4rd wouldn't be up to its objectives.
>=20
> if we agree that the interface-id is just 64bits of nothingness, then =
there is no such thing as an unused IID space.

We don't agree that what is in RFC 4291 should be ignored.
=20
> pick whatever you like for the 4rd IID, but your protocol needs to =
deal with collisions.

Not AFAIK, but since 4rd is intended to be experimental, this will be =
verified anyway.

If you have identified a detailed configuration which would suffer from =
collisions, I hope you will submit it to Softwire for the 6 4rd-draft =
authors to look at it.

Let me wonder when you will stop introducing in 6man new arguments =
against 4rd operation.


RD

=20

>=20
> cheers,
> Ole

From v6ops@globis.net  Wed Jan 30 08:04:54 2013
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 99A9621F88E2 for ; Wed, 30 Jan 2013 08:04:54 -0800 (PST)
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 uKqVnY90VruU for ; Wed, 30 Jan 2013 08:04:54 -0800 (PST)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id B4DB721F88CC for ; Wed, 30 Jan 2013 08:04:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id BF7838700EF; Wed, 30 Jan 2013 16:59:36 +0100 (CET)
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 Kz+Cap0nCn81; Wed, 30 Jan 2013 16:59:07 +0100 (CET)
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 AD2AA8700ED; Wed, 30 Jan 2013 16:59:07 +0100 (CET)
Message-ID: <51094345.4030503@globis.net>
Date: Wed, 30 Jan 2013 16:59:01 +0100
From: Ray Hunter 
User-Agent: Postbox 3.0.7 (Macintosh/20130119)
MIME-Version: 1.0
To: Ole Troan 
Subject: Re: Re: 4rd IID range & IPv6 addressing architecture
References: 	<02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: '6man 6man-wg' , 'Bob Hinden' 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jan 2013 16:04:54 -0000

inline.

Ole Troan wrote:
> Brian,
>
>>>>> - If agreed on the principle, and if no one else volunteers, I can be
>>>>> available to propose a draft to this effect.
>>>> Seems reasonable.
>>>>
>>>>
>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>>>> IIDs having u=1 is reserved. This leaves plenty of space for future
>>>>> uses of IIDs having u= as explicitly expected in RFC 4291.
>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>> some space to 4rd.
>>> I still think we need to answer the question Brian raised.
>>> should the interface-id have any encoded meaning?
>> That will not be done overnight. I've been thinking about it and
>> have some ideas about how to write a discussion draft, but it is
>> unfortuante to make the 4rd work queue behind us. Is there any risk
>> in doing as Rémi suggested?
>
> it depends on what the expected meaning of a reservation is.
> should all implementations treat the reserved part of the interface-id as martian,
> and prohibit a user from configuring it for another purpose than 4rd?
>
> or is it just a 'suggestion' for interface-id's that the 4rd mechanism can use, and the operator
> deploying it will make sure there are no conflicts?
my 2 cents.

If 4rd is truly experimental then indeed I think it's up to the
operators deploying it to ensure they choose a unique IID range within
the scope of where they are operating 4rd (between tunnel endpoints and
the tunnel gateway). My initial concerns were that this could cause harm
even in experimental form, but I've convinced myself that it shouldn't.
In this case I see no need for a hard global IID reservation, because at
the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC.

On the other hand, If 4rd is not truly experimental, or it's expected to
work universally across AS boundaries, I suspect the WG will have to
wait for an answer to Brian's question on whether structure within the
IID is desirable. I don't think there's any clear consensus so far on
that point (indeed there are some counter posts saying structure within
the IID is undesirable).

My own particular concern here is that there is a danger of creating a
precedent of a completely new class of IPv6 addressing by the back door
without this being fully and properly debated i.e. address ranges that
don't perform DAD, and that are associated directly with a certain
tunnel or transport protocol, and yet which are assigned within the
generic GUA space, but perhaps which overlap with other IPv6 prefix
spaces too.

e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
6to4 (2002::/16) being associated with 4rd IIDs?

e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
(both of which assume that bit-contiguous left-anchored IPv6 prefixes
map to transport protocols, not individual IID bits)?

These questions probably have little relevance to 4rd being deployed in
an experimental situation, and I think we should perhaps try to keep
them decoupled as far as possible.

> one of my concerns is that continuing to add the interface-id bits, is the opposite direction of where
> I want us to go.
>
> I wouldn't object to non-normative language in 4rd suggesting a interface-id to use, without
> creating any expectation that new or existing IPv6 implementations have to change.
>
> that said, 4rd will work perfectly well _without_ this reservation, so I don't buy the argument that
> we're holding up the 4rd work.
>
> cheers,
> Ole
>
>


From phdgang@gmail.com  Wed Jan 30 23:53:39 2013
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 CC60621F85C0 for ; Wed, 30 Jan 2013 23:53:39 -0800 (PST)
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 wMHsZEW0tBpZ for ; Wed, 30 Jan 2013 23:53:38 -0800 (PST)
Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEC221F8526 for ; Wed, 30 Jan 2013 23:53:38 -0800 (PST)
Received: by mail-qa0-f41.google.com with SMTP id hy16so2714043qab.14 for ; Wed, 30 Jan 2013 23:53:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=63H8CZbc2ulOx8O/Hxmvc5uc5qTOFEgVjJq3EuLxgMk=; b=Rg/ILPyDAjgsDJM1ysjLhmL5fQE4eDX/0A4t7bcWeFkd1kAQ66uyoVW6Hq/hsLrCld LXMmY53NQDV2LvL+bIIR0p1i7IAKJc8ddzo7Bk3gUB0m5lifgO2fWjs39Y0lB7abxCrD OYXvVumX6Yed+h+vz1OCZKdA15N6R45ALp2yI7n5mrLUYMpx+isAflVZJoQzgf+U6Xlr tcT/DE25+hASpejRUexuxGqgiBKsSeFhPDUVsXBcMRBVIIfkZJFgJq2yHcxVnZmQ3OMZ 1BohRaVAa3XoyyoLTdlIUZpW7p7byeh0w2klhkLRT9YoBm9h3pCaJqtWW9KoSQwUHiwq IKmw==
MIME-Version: 1.0
X-Received: by 10.229.201.200 with SMTP id fb8mr1893223qcb.122.1359618818087;  Wed, 30 Jan 2013 23:53:38 -0800 (PST)
Received: by 10.49.48.12 with HTTP; Wed, 30 Jan 2013 23:53:37 -0800 (PST)
In-Reply-To: <51094345.4030503@globis.net>
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <51094345.4030503@globis.net>
Date: Thu, 31 Jan 2013 15:53:37 +0800
Message-ID: 
Subject: Re: Re: 4rd IID range & IPv6 addressing architecture
From: GangChen 
To: Ray Hunter 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Bob Hinden , 6man 6man-wg 
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, 31 Jan 2013 07:53:39 -0000

2013/1/30, Ray Hunter :
> inline.
>
> Ole Troan wrote:
>> Brian,
>>
>>>>>> - If agreed on the principle, and if no one else volunteers, I can b=
e
>>>>>> available to propose a draft to this effect.
>>>>> Seems reasonable.
>>>>>
>>>>>
>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space for futur=
e
>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>> some space to 4rd.
>>>> I still think we need to answer the question Brian raised.
>>>> should the interface-id have any encoded meaning?
>>> That will not be done overnight. I've been thinking about it and
>>> have some ideas about how to write a discussion draft, but it is
>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>> in doing as R=E9mi suggested?
>>
>> it depends on what the expected meaning of a reservation is.
>> should all implementations treat the reserved part of the interface-id a=
s
>> martian,
>> and prohibit a user from configuring it for another purpose than 4rd?
>>
>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism c=
an
>> use, and the operator
>> deploying it will make sure there are no conflicts?
> my 2 cents.
>
> If 4rd is truly experimental then indeed I think it's up to the
> operators deploying it to ensure they choose a unique IID range within
> the scope of where they are operating 4rd (between tunnel endpoints and
> the tunnel gateway). My initial concerns were that this could cause harm
> even in experimental form, but I've convinced myself that it shouldn't.
> In this case I see no need for a hard global IID reservation, because at
> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with SLAAC.

Just some comments from operational views. I guess it's true operators
could avoid confliction with u=3D1 g=3D1 in near future. However, I
believe that is relative short-term guarantee with the condition of a
particular operational domain. The term of "experimental" is not
really mean "experimental" to a commercial network. It would be safe
for operations if there is legitimate registry to ensure there is no
need to renumbering. Therefore I prefer Remi's proposal (e) to grant
4rd 0x0300.

Best Regards

Gang


> On the other hand, If 4rd is not truly experimental, or it's expected to
> work universally across AS boundaries, I suspect the WG will have to
> wait for an answer to Brian's question on whether structure within the
> IID is desirable. I don't think there's any clear consensus so far on
> that point (indeed there are some counter posts saying structure within
> the IID is undesirable).
>
> My own particular concern here is that there is a danger of creating a
> precedent of a completely new class of IPv6 addressing by the back door
> without this being fully and properly debated i.e. address ranges that
> don't perform DAD, and that are associated directly with a certain
> tunnel or transport protocol, and yet which are assigned within the
> generic GUA space, but perhaps which overlap with other IPv6 prefix
> spaces too.
>
> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
> 6to4 (2002::/16) being associated with 4rd IIDs?
>
> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
> map to transport protocols, not individual IID bits)?
>
> These questions probably have little relevance to 4rd being deployed in
> an experimental situation, and I think we should perhaps try to keep
> them decoupled as far as possible.
>
>> one of my concerns is that continuing to add the interface-id bits, is t=
he
>> opposite direction of where
>> I want us to go.
>>
>> I wouldn't object to non-normative language in 4rd suggesting a
>> interface-id to use, without
>> creating any expectation that new or existing IPv6 implementations have =
to
>> change.
>>
>> that said, 4rd will work perfectly well _without_ this reservation, so I
>> don't buy the argument that
>> we're holding up the 4rd work.
>>
>> cheers,
>> Ole
>>
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

From v6ops@globis.net  Thu Jan 31 02:37:57 2013
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 6E61821F86A3 for ; Thu, 31 Jan 2013 02:37:57 -0800 (PST)
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 k-YoyxdEmQ1x for ; Thu, 31 Jan 2013 02:37:56 -0800 (PST)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id E6ABC21F86A1 for ; Thu, 31 Jan 2013 02:37:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4A2438700ED; Thu, 31 Jan 2013 11:27:38 +0100 (CET)
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 bqpsJvtLmHkT; Thu, 31 Jan 2013 11:27:05 +0100 (CET)
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 02D028700DE; Thu, 31 Jan 2013 11:27:05 +0100 (CET)
Message-ID: <510A46F3.5090407@globis.net>
Date: Thu, 31 Jan 2013 11:26:59 +0100
From: Ray Hunter 
User-Agent: Postbox 3.0.7 (Macintosh/20130119)
MIME-Version: 1.0
To: GangChen 
Subject: Re: 4rd IID range & IPv6 addressing architecture
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <51094345.4030503@globis.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: Bob Hinden , 6man 6man-wg 
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, 31 Jan 2013 10:37:57 -0000

> GangChen 
> 31 January 2013 08:53
> 2013/1/30, Ray Hunter :
>> inline.
>>
>> Ole Troan wrote:
>>> Brian,
>>>
>>>>>>> - If agreed on the principle, and if no one else volunteers, I can be
>>>>>>> available to propose a draft to this effect.
>>>>>> Seems reasonable.
>>>>>>
>>>>>>
>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>>>>>> IIDs having u=1 is reserved. This leaves plenty of space for future
>>>>>>> uses of IIDs having u= as explicitly expected in RFC 4291.
>>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>>> some space to 4rd.
>>>>> I still think we need to answer the question Brian raised.
>>>>> should the interface-id have any encoded meaning?
>>>> That will not be done overnight. I've been thinking about it and
>>>> have some ideas about how to write a discussion draft, but it is
>>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>>> in doing as Rémi suggested?
>>> it depends on what the expected meaning of a reservation is.
>>> should all implementations treat the reserved part of the interface-id as
>>> martian,
>>> and prohibit a user from configuring it for another purpose than 4rd?
>>>
>>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism can
>>> use, and the operator
>>> deploying it will make sure there are no conflicts?
>> my 2 cents.
>>
>> If 4rd is truly experimental then indeed I think it's up to the
>> operators deploying it to ensure they choose a unique IID range within
>> the scope of where they are operating 4rd (between tunnel endpoints and
>> the tunnel gateway). My initial concerns were that this could cause harm
>> even in experimental form, but I've convinced myself that it shouldn't.
>> In this case I see no need for a hard global IID reservation, because at
>> the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC.
>
> Just some comments from operational views. I guess it's true operators
> could avoid confliction with u=1 g=1 in near future. However, I
> believe that is relative short-term guarantee with the condition of a
> particular operational domain. The term of "experimental" is not
> really mean "experimental" to a commercial network. It would be safe
> for operations if there is legitimate registry to ensure there is no
> need to renumbering. Therefore I prefer Remi's proposal (e) to grant
> 4rd 0x0300.
>
> Best Regards
>
> Gang
>

I disagree.

See http://www.ietf.org/iesg/informational-vs-experimental.html

IMVHO "Experimental" means everything could change: including a need for
mass renumbering or equipment replacement.

Publication is "Subject only to editorial considerations and to
verification that there has been adequate coordination with the
standards process." No guarantees. The test I am currently applying when
reviewing this ID is whether the experiment is likely to cause harm.

I see no compelling reason at this time to define a global reservation
or an explicit IID structure in order for the experiment to be able to
proceed and succeed. On the other hand, adding a reservation and
structure to the IID at this time would likely impact other
implementations (e.g. packet classifiers) and existing documents and IDs
(e.g. address selection).

If you want 4rd to be "informational" or "standards track" I also think
that's worth discussing, but then I also think there's a lot more to
specify and discuss beyond the current ID.

>> On the other hand, If 4rd is not truly experimental, or it's expected to
>> work universally across AS boundaries, I suspect the WG will have to
>> wait for an answer to Brian's question on whether structure within the
>> IID is desirable. I don't think there's any clear consensus so far on
>> that point (indeed there are some counter posts saying structure within
>> the IID is undesirable).
>>
>> My own particular concern here is that there is a danger of creating a
>> precedent of a completely new class of IPv6 addressing by the back door
>> without this being fully and properly debated i.e. address ranges that
>> don't perform DAD, and that are associated directly with a certain
>> tunnel or transport protocol, and yet which are assigned within the
>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>> spaces too.
>>
>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>
>> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
>> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
>> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
>> map to transport protocols, not individual IID bits)?
>>
>> These questions probably have little relevance to 4rd being deployed in
>> an experimental situation, and I think we should perhaps try to keep
>> them decoupled as far as possible.
>>
>>> one of my concerns is that continuing to add the interface-id bits, is the
>>> opposite direction of where
>>> I want us to go.
>>>
>>> I wouldn't object to non-normative language in 4rd suggesting a
>>> interface-id to use, without
>>> creating any expectation that new or existing IPv6 implementations have to
>>> change.
>>>
>>> that said, 4rd will work perfectly well _without_ this reservation, so I
>>> don't buy the argument that
>>> we're holding up the 4rd work.
>>>
>>> cheers,
>>> Ole
>>>
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> Ray Hunter 
> 30 January 2013 16:59
> inline.
>
> Ole Troan wrote:
>> Brian,
>>
>>>>>> - If agreed on the principle, and if no one else volunteers, I can be
>>>>>> available to propose a draft to this effect.
>>>>> Seems reasonable.
>>>>>
>>>>>
>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>>>>> IIDs having u=1 is reserved. This leaves plenty of space for future
>>>>>> uses of IIDs having u= as explicitly expected in RFC 4291.
>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>> some space to 4rd.
>>>> I still think we need to answer the question Brian raised.
>>>> should the interface-id have any encoded meaning?
>>> That will not be done overnight. I've been thinking about it and
>>> have some ideas about how to write a discussion draft, but it is
>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>> in doing as Rémi suggested?
>> it depends on what the expected meaning of a reservation is.
>> should all implementations treat the reserved part of the interface-id as martian,
>> and prohibit a user from configuring it for another purpose than 4rd?
>>
>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism can use, and the operator
>> deploying it will make sure there are no conflicts?
> my 2 cents.
>
> If 4rd is truly experimental then indeed I think it's up to the
> operators deploying it to ensure they choose a unique IID range within
> the scope of where they are operating 4rd (between tunnel endpoints and
> the tunnel gateway). My initial concerns were that this could cause harm
> even in experimental form, but I've convinced myself that it shouldn't.
> In this case I see no need for a hard global IID reservation, because at
> the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC.
>
> On the other hand, If 4rd is not truly experimental, or it's expected to
> work universally across AS boundaries, I suspect the WG will have to
> wait for an answer to Brian's question on whether structure within the
> IID is desirable. I don't think there's any clear consensus so far on
> that point (indeed there are some counter posts saying structure within
> the IID is undesirable).
>
> My own particular concern here is that there is a danger of creating a
> precedent of a completely new class of IPv6 addressing by the back door
> without this being fully and properly debated i.e. address ranges that
> don't perform DAD, and that are associated directly with a certain
> tunnel or transport protocol, and yet which are assigned within the
> generic GUA space, but perhaps which overlap with other IPv6 prefix
> spaces too.
>
> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
> 6to4 (2002::/16) being associated with 4rd IIDs?
>
> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
> map to transport protocols, not individual IID bits)?
>
> These questions probably have little relevance to 4rd being deployed in
> an experimental situation, and I think we should perhaps try to keep
> them decoupled as far as possible.
>
>> one of my concerns is that continuing to add the interface-id bits, is the opposite direction of where
>> I want us to go.
>>
>> I wouldn't object to non-normative language in 4rd suggesting a interface-id to use, without
>> creating any expectation that new or existing IPv6 implementations have to change.
>>
>> that said, 4rd will work perfectly well _without_ this reservation, so I don't buy the argument that
>> we're holding up the 4rd work.
>>
>> cheers,
>> Ole
>>
>>
>
> ------------------------------------------------------------------------


From despres.remi@laposte.net  Thu Jan 31 02:38:57 2013
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 6529821F86AC for ; Thu, 31 Jan 2013 02:38:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.363
X-Spam-Level: 
X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.586,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 5tb3HoJhZ-OO for ; Thu, 31 Jan 2013 02:38:56 -0800 (PST)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7508021F8697 for ; Thu, 31 Jan 2013 02:38:56 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2107.sfr.fr (SMTP Server) with ESMTP id 59CFC70000D1; Thu, 31 Jan 2013 11:38:55 +0100 (CET)
Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2107.sfr.fr (SMTP Server) with ESMTP id B6CDD7000046; Thu, 31 Jan 2013 11:38:54 +0100 (CET)
X-SFR-UUID: 20130131103854748.B6CDD7000046@msfrf2107.sfr.fr
Subject: Re: 4rd IID range & IPv6 addressing architecture
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= 
In-Reply-To: <51094345.4030503@globis.net>
Date: Thu, 31 Jan 2013 11:38:54 +0100
Message-Id: <0E64F918-41FE-48B4-A57A-D6B40ABD962F@laposte.net>
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <51094345.4030503@globis.net>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1499)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Bob Hinden , 6man 6man-wg 
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, 31 Jan 2013 10:38:57 -0000

2013-01-30  16:59, Ray Hunter   :
...
> my 2 cents.
>=20
> If 4rd is truly experimental then indeed I think it's up to the
> operators deploying it to ensure they choose a unique IID range within
> the scope of where they are operating 4rd (between tunnel endpoints =
and
> the tunnel gateway).

This misses the point that 4rd IIDs are chosen to be collision-free with =
all possible IPv6 hosts that, in sites that use 4rd for IPv4, are =
configured with SLAAC (and therefore have to comply with RFC4291).=20
IIDs of these hosts are assigned independently of any knowledge that 4rd =
is used or not.

> My initial concerns were that this could cause harm
> even in experimental form, but I've convinced myself that it =
shouldn't.
> In this case I see no need for a hard global IID reservation, because =
at
> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with =
SLAAC.
>=20
> On the other hand, If 4rd is not truly experimental, or it's expected =
to
> work universally across AS boundaries, I suspect the WG will have to
> wait for an answer to Brian's question on whether structure within the
> IID is desirable. I don't think there's any clear consensus so far on
> that point

> (indeed there are some counter posts saying structure within
> the IID is undesirable).

OK, it is a fact that, *for some addresses that aren't concerned with =
SLAAC*, typically some manually configured addresses, the IID structure =
of RFC 4291 can be ignored. One example where it is actually ignored is =
in RFC 6164  which deals with /127 prefixes on inter-router links. =
(Incidentally, I have been an active supporter of this RFC, as Miya =
Kohno may remember.

But it is ALSO A FACT that *for IIDs that are used in SLAAC* there is =
some IID structure, the so called Modified EUI-64 format. (If u=3D0, =
other bits have no structure; if u=3D1, other bits must be based on IEEE =
link addresses. They then always have g=3D0, other combinations =
remaining available for future technologies.)
This structure is effectively used in OSes to automatically provide, by =
default, addresses that are stable in their environment. If MUST NOT be =
abandoned for addresses subject to SLAAC.

> My own particular concern here is that there is a danger of creating a
> precedent of a completely new class of IPv6 addressing by the back =
door
> without this being fully and properly debated i.e. address ranges that
> don't perform DAD, and that are associated directly with a certain
> tunnel or transport protocol, and yet which are assigned within the
> generic GUA space, but perhaps which overlap with other IPv6 prefix
> spaces too.
>=20
> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used =
by
> 6to4 (2002::/16) being associated with 4rd IIDs?

6to4 IIDs are ordinary unicast-address IIDs, subject to RFC 4291.=20
Consistency of the 4rd IID range with RFC 4291 therefore avoids any risk =
of conflict with 6to4.=20

> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
> map to transport protocols, not individual IID bits)?

4rd addresses are those of tunnel endpoints in BRs and CEs. They are =
therefore not concerned with Address selection policies that are needed =
for applications having to choose among several source and/or =
destinations.
 =20

>=20
> These questions probably have little relevance to 4rd being deployed =
in
> an experimental situation, and I think we should perhaps try to keep
> them decoupled as far as possible.

Reservation of an unused IID range among those of RFC4291 is in my =
understanding already decoupled from the above issues. This reservation =
would be as safe if 4rd would be on standard track instead of =
experimental.

Regards,
RD



>> one of my concerns is that continuing to add the interface-id bits, =
is the opposite direction of where
>> I want us to go.
>>=20
>> I wouldn't object to non-normative language in 4rd suggesting a =
interface-id to use, without
>> creating any expectation that new or existing IPv6 implementations =
have to change.
>>=20
>> that said, 4rd will work perfectly well _without_ this reservation, =
so I don't buy the argument that
>> we're holding up the 4rd work.
>>=20
>> cheers,
>> Ole
>>=20
>>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

From otroan@employees.org  Thu Jan 31 02:42:42 2013
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 A2D2621F85D2 for ; Thu, 31 Jan 2013 02:42:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.518
X-Spam-Level: 
X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 EQQlqff2dGK2 for ; Thu, 31 Jan 2013 02:42:41 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 277DA21F8441 for ; Thu, 31 Jan 2013 02:42:40 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EABpKClGQ/khR/2dsb2JhbABFvyAWc4IeAQEBAwEBAQFrCxALDgQGJwchBh8DDgYTCYd2AwkGDLgTDYlWjBSEF2EDkl6BXY0RhRKCeA
X-IronPort-AV: E=Sophos;i="4.84,575,1355097600"; d="scan'208";a="80142442"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 31 Jan 2013 10:42:28 +0000
Received: from dhcp-lys01-vla250-10-147-112-67.cisco.com (dhcp-lys01-vla250-10-147-112-67.cisco.com [10.147.112.67]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0VAgRB0020046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jan 2013 10:42:28 GMT
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: Ole Troan 
In-Reply-To: <510A46F3.5090407@globis.net>
Date: Thu, 31 Jan 2013 11:42:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <51094345.4030503@globis.net>  <510A46F3.5090407@globis.net>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1499)
Cc: Bob Hinden , 6man 6man-wg 
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, 31 Jan 2013 10:42:42 -0000

agree with what Ray says. that gives a path forward for 4rd without =
requiring us to settle the interface-id structure question.

cheers,
Ole


On Jan 31, 2013, at 11:26 , Ray Hunter  wrote:

>> GangChen 
>> 31 January 2013 08:53
>> 2013/1/30, Ray Hunter :
>>> inline.
>>>=20
>>> Ole Troan wrote:
>>>> Brian,
>>>>=20
>>>>>>>> - If agreed on the principle, and if no one else volunteers, I =
can be
>>>>>>>> available to propose a draft to this effect.
>>>>>>> Seems reasonable.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused =
set of
>>>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space for =
future
>>>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>>>> That goes to the argument of (d), that it isn't harmful to =
assign
>>>>>>> some space to 4rd.
>>>>>> I still think we need to answer the question Brian raised.
>>>>>> should the interface-id have any encoded meaning?
>>>>> That will not be done overnight. I've been thinking about it and
>>>>> have some ideas about how to write a discussion draft, but it is
>>>>> unfortuante to make the 4rd work queue behind us. Is there any =
risk
>>>>> in doing as R=E9mi suggested?
>>>> it depends on what the expected meaning of a reservation is.
>>>> should all implementations treat the reserved part of the =
interface-id as
>>>> martian,
>>>> and prohibit a user from configuring it for another purpose than =
4rd?
>>>>=20
>>>> or is it just a 'suggestion' for interface-id's that the 4rd =
mechanism can
>>>> use, and the operator
>>>> deploying it will make sure there are no conflicts?
>>> my 2 cents.
>>>=20
>>> If 4rd is truly experimental then indeed I think it's up to the
>>> operators deploying it to ensure they choose a unique IID range =
within
>>> the scope of where they are operating 4rd (between tunnel endpoints =
and
>>> the tunnel gateway). My initial concerns were that this could cause =
harm
>>> even in experimental form, but I've convinced myself that it =
shouldn't.
>>> In this case I see no need for a hard global IID reservation, =
because at
>>> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with =
SLAAC.
>>=20
>> Just some comments from operational views. I guess it's true =
operators
>> could avoid confliction with u=3D1 g=3D1 in near future. However, I
>> believe that is relative short-term guarantee with the condition of a
>> particular operational domain. The term of "experimental" is not
>> really mean "experimental" to a commercial network. It would be safe
>> for operations if there is legitimate registry to ensure there is no
>> need to renumbering. Therefore I prefer Remi's proposal (e) to grant
>> 4rd 0x0300.
>>=20
>> Best Regards
>>=20
>> Gang
>>=20
>=20
> I disagree.
>=20
> See http://www.ietf.org/iesg/informational-vs-experimental.html
>=20
> IMVHO "Experimental" means everything could change: including a need =
for
> mass renumbering or equipment replacement.
>=20
> Publication is "Subject only to editorial considerations and to
> verification that there has been adequate coordination with the
> standards process." No guarantees. The test I am currently applying =
when
> reviewing this ID is whether the experiment is likely to cause harm.
>=20
> I see no compelling reason at this time to define a global reservation
> or an explicit IID structure in order for the experiment to be able to
> proceed and succeed. On the other hand, adding a reservation and
> structure to the IID at this time would likely impact other
> implementations (e.g. packet classifiers) and existing documents and =
IDs
> (e.g. address selection).
>=20
> If you want 4rd to be "informational" or "standards track" I also =
think
> that's worth discussing, but then I also think there's a lot more to
> specify and discuss beyond the current ID.
>=20
>>> On the other hand, If 4rd is not truly experimental, or it's =
expected to
>>> work universally across AS boundaries, I suspect the WG will have to
>>> wait for an answer to Brian's question on whether structure within =
the
>>> IID is desirable. I don't think there's any clear consensus so far =
on
>>> that point (indeed there are some counter posts saying structure =
within
>>> the IID is undesirable).
>>>=20
>>> My own particular concern here is that there is a danger of creating =
a
>>> precedent of a completely new class of IPv6 addressing by the back =
door
>>> without this being fully and properly debated i.e. address ranges =
that
>>> don't perform DAD, and that are associated directly with a certain
>>> tunnel or transport protocol, and yet which are assigned within the
>>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>>> spaces too.
>>>=20
>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used =
by
>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>>=20
>>> e.g. 2 How would this new class of IID encoded =
ranges/tunnel/transport
>>> protocols interact with RFC6724 and =
draft-ietf-6man-addr-select-opt-08
>>> (both of which assume that bit-contiguous left-anchored IPv6 =
prefixes
>>> map to transport protocols, not individual IID bits)?
>>>=20
>>> These questions probably have little relevance to 4rd being deployed =
in
>>> an experimental situation, and I think we should perhaps try to keep
>>> them decoupled as far as possible.
>>>=20
>>>> one of my concerns is that continuing to add the interface-id bits, =
is the
>>>> opposite direction of where
>>>> I want us to go.
>>>>=20
>>>> I wouldn't object to non-normative language in 4rd suggesting a
>>>> interface-id to use, without
>>>> creating any expectation that new or existing IPv6 implementations =
have to
>>>> change.
>>>>=20
>>>> that said, 4rd will work perfectly well _without_ this reservation, =
so I
>>>> don't buy the argument that
>>>> we're holding up the 4rd work.
>>>>=20
>>>> cheers,
>>>> Ole
>>>>=20
>>>>=20
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>=20
>> Ray Hunter 
>> 30 January 2013 16:59
>> inline.
>>=20
>> Ole Troan wrote:
>>> Brian,
>>>=20
>>>>>>> - If agreed on the principle, and if no one else volunteers, I =
can be
>>>>>>> available to propose a draft to this effect.
>>>>>> Seems reasonable.
>>>>>>=20
>>>>>>=20
>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused =
set of
>>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space for =
future
>>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>>> some space to 4rd.
>>>>> I still think we need to answer the question Brian raised.
>>>>> should the interface-id have any encoded meaning?
>>>> That will not be done overnight. I've been thinking about it and
>>>> have some ideas about how to write a discussion draft, but it is
>>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>>> in doing as R=E9mi suggested?
>>> it depends on what the expected meaning of a reservation is.
>>> should all implementations treat the reserved part of the =
interface-id as martian,
>>> and prohibit a user from configuring it for another purpose than =
4rd?
>>>=20
>>> or is it just a 'suggestion' for interface-id's that the 4rd =
mechanism can use, and the operator
>>> deploying it will make sure there are no conflicts?
>> my 2 cents.
>>=20
>> If 4rd is truly experimental then indeed I think it's up to the
>> operators deploying it to ensure they choose a unique IID range =
within
>> the scope of where they are operating 4rd (between tunnel endpoints =
and
>> the tunnel gateway). My initial concerns were that this could cause =
harm
>> even in experimental form, but I've convinced myself that it =
shouldn't.
>> In this case I see no need for a hard global IID reservation, because =
at
>> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with =
SLAAC.
>>=20
>> On the other hand, If 4rd is not truly experimental, or it's expected =
to
>> work universally across AS boundaries, I suspect the WG will have to
>> wait for an answer to Brian's question on whether structure within =
the
>> IID is desirable. I don't think there's any clear consensus so far on
>> that point (indeed there are some counter posts saying structure =
within
>> the IID is undesirable).
>>=20
>> My own particular concern here is that there is a danger of creating =
a
>> precedent of a completely new class of IPv6 addressing by the back =
door
>> without this being fully and properly debated i.e. address ranges =
that
>> don't perform DAD, and that are associated directly with a certain
>> tunnel or transport protocol, and yet which are assigned within the
>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>> spaces too.
>>=20
>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used =
by
>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>=20
>> e.g. 2 How would this new class of IID encoded =
ranges/tunnel/transport
>> protocols interact with RFC6724 and =
draft-ietf-6man-addr-select-opt-08
>> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
>> map to transport protocols, not individual IID bits)?
>>=20
>> These questions probably have little relevance to 4rd being deployed =
in
>> an experimental situation, and I think we should perhaps try to keep
>> them decoupled as far as possible.
>>=20
>>> one of my concerns is that continuing to add the interface-id bits, =
is the opposite direction of where
>>> I want us to go.
>>>=20
>>> I wouldn't object to non-normative language in 4rd suggesting a =
interface-id to use, without
>>> creating any expectation that new or existing IPv6 implementations =
have to change.
>>>=20
>>> that said, 4rd will work perfectly well _without_ this reservation, =
so I don't buy the argument that
>>> we're holding up the 4rd work.
>>>=20
>>> cheers,
>>> Ole
>>>=20
>>>=20
>>=20
>> =
------------------------------------------------------------------------


From despres.remi@laposte.net  Thu Jan 31 03:08:21 2013
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 1F1DB21F8644 for ; Thu, 31 Jan 2013 03:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.39
X-Spam-Level: 
X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.559,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 wNLJc2sw1qba for ; Thu, 31 Jan 2013 03:08:20 -0800 (PST)
Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F35F21F83EF for ; Thu, 31 Jan 2013 03:08:20 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2107.sfr.fr (SMTP Server) with ESMTP id 5ED7370000E2; Thu, 31 Jan 2013 12:08:19 +0100 (CET)
Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2107.sfr.fr (SMTP Server) with ESMTP id 42EE570000E0; Thu, 31 Jan 2013 12:08:19 +0100 (CET)
X-SFR-UUID: 20130131110819274.42EE570000E0@msfrf2107.sfr.fr
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= 
In-Reply-To: <510A46F3.5090407@globis.net>
Date: Thu, 31 Jan 2013 12:08:19 +0100
Message-Id: <9F796593-F8A8-434B-A153-3114781696C8@laposte.net>
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <51094345.4030503@globis.net>  <510A46F3.5090407@globis.net>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1499)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: 6man 6man-wg , 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, 31 Jan 2013 11:08:21 -0000

2013-01-31  11:26, Ray Hunter  :

>> GangChen 
>>=20
...
>> Just some comments from operational views. I guess it's true =
operators
>> could avoid confliction with u=3D1 g=3D1 in near future. However, I
>> believe that is relative short-term guarantee with the condition of a
>> particular operational domain. The term of "experimental" is not
>> really mean "experimental" to a commercial network. It would be safe
>> for operations if there is legitimate registry to ensure there is no
>> need to renumbering. Therefore I prefer Remi's proposal (e) to grant
>> 4rd 0x0300.
>>=20
>> Best Regards
>>=20
>> Gang
>>=20
>=20
> I disagree.
>=20
> See http://www.ietf.org/iesg/informational-vs-experimental.html
>=20
> IMVHO "Experimental" means everything could change: including a need =
for
> mass renumbering or equipment replacement.
>=20
> Publication is "Subject only to editorial considerations and to
> verification that there has been adequate coordination with the
> standards process." No guarantees. The test I am currently applying =
when
> reviewing this ID is whether the experiment is likely to cause harm.
>=20
> I see no compelling reason at this time to define a global reservation
> or an explicit IID structure in order for the experiment to be able to
> proceed and succeed. On the other hand, adding a reservation and
> structure to the IID at this time would likely impact other
> implementations (e.g. packet classifiers) and existing documents and =
IDs
> (e.g. address selection).

Please see the answer on this point in my previous email to you.

> If you want 4rd to be "informational" or "standards track" I also =
think
> that's worth discussing,

"Experimental" or "standard" has been abundantly discussed in Softwire. =
"Experimental" is THE CONCLUSION, worth leaving as is.=20

The question to 6man is whether 6man confirms, or not, that the proposed =
IID-range reservation is compatible with the IPv6 addressing =
architecture (as found after a thorough study of the subject before =
proposing it).

> but then I also think there's a lot more to
> specify and discuss beyond the current ID.

Being more specific would clarify what you mean by this "lot more"=20
It should preferably be in Softwire if it doesn't concern 6man, or even =
be in a private discussion if you didn't follow previous work on the =
subject.=20
I will do my best to answer.


Regards,
RD

From v6ops@globis.net  Thu Jan 31 03:38:08 2013
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 567BE21F853E for ; Thu, 31 Jan 2013 03:38:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 jGYuwrVS02sh for ; Thu, 31 Jan 2013 03:38:07 -0800 (PST)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 18A7621F8496 for ; Thu, 31 Jan 2013 03:38:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 5FA158700ED; Thu, 31 Jan 2013 12:32:50 +0100 (CET)
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 o925CmJsilik; Thu, 31 Jan 2013 12:32:21 +0100 (CET)
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 24B9D870049; Thu, 31 Jan 2013 12:32:21 +0100 (CET)
Message-ID: <510A563F.1090906@globis.net>
Date: Thu, 31 Jan 2013 12:32:15 +0100
From: Ray Hunter 
User-Agent: Postbox 3.0.7 (Macintosh/20130119)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= 
Subject: Re: Re: 4rd IID range & IPv6 addressing architecture
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <51094345.4030503@globis.net> <0E64F918-41FE-48B4-A57A-D6B40ABD962F@laposte.net>
In-Reply-To: <0E64F918-41FE-48B4-A57A-D6B40ABD962F@laposte.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: 6man 6man-wg , 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, 31 Jan 2013 11:38:08 -0000

Rémi Després wrote:
> 2013-01-30  16:59, Ray Hunter   :
> ...
>> my 2 cents.
>>
>> If 4rd is truly experimental then indeed I think it's up to the
>> operators deploying it to ensure they choose a unique IID range within
>> the scope of where they are operating 4rd (between tunnel endpoints and
>> the tunnel gateway).
>
> This misses the point that 4rd IIDs are chosen to be collision-free with all possible IPv6 hosts that, in sites that use 4rd for IPv4, are configured with SLAAC (and therefore have to comply with RFC4291). 
> IIDs of these hosts are assigned independently of any knowledge that 4rd is used or not.
Understood. No new reservation is required. No new behaviour is required
of existing hosts.
>> My initial concerns were that this could cause harm
>> even in experimental form, but I've convinced myself that it shouldn't.
>> In this case I see no need for a hard global IID reservation, because at
>> the moment, u=g=1 isn't used for creating IID's for use with SLAAC.
>>
>> On the other hand, If 4rd is not truly experimental, or it's expected to
>> work universally across AS boundaries, I suspect the WG will have to
>> wait for an answer to Brian's question on whether structure within the
>> IID is desirable. I don't think there's any clear consensus so far on
>> that point
>
>> (indeed there are some counter posts saying structure within
>> the IID is undesirable).
>
> OK, it is a fact that, *for some addresses that aren't concerned with SLAAC*, typically some manually configured addresses, the IID structure of RFC 4291 can be ignored. One example where it is actually ignored is in RFC 6164  which deals with /127 prefixes on inter-router links. (Incidentally, I have been an active supporter of this RFC, as Miya Kohno may remember.
Understood.  People running 4rd have to ensure manually assigned
addresses avoid the 4rd range.
Making a global reservation or not will likely not significantly change
the impact of that.
> But it is ALSO A FACT that *for IIDs that are used in SLAAC* there is some IID structure, the so called Modified EUI-64 format. (If u= other bits have no structure; if u=1, other bits must be based on IEEE link addresses. They then always have g=0, other combinations remaining available for future technologies.)
> This structure is effectively used in OSes to automatically provide, by default, addresses that are stable in their environment. If MUST NOT be abandoned for addresses subject to SLAAC.
Understood. No new reservation is required. No new behaviour is required
of existing hosts. 
>> My own particular concern here is that there is a danger of creating a
>> precedent of a completely new class of IPv6 addressing by the back door
>> without this being fully and properly debated i.e. address ranges that
>> don't perform DAD, and that are associated directly with a certain
>> tunnel or transport protocol, and yet which are assigned within the
>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>> spaces too.
>>
>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
>> 6to4 (2002::/16) being associated with 4rd IIDs?
>
> 6to4 IIDs are ordinary unicast-address IIDs, subject to RFC 4291. 
> Consistency of the 4rd IID range with RFC 4291 therefore avoids any risk of conflict with 6to4. 
Right, so you're saying it's perfectly valid to combine a 64 bit 6to4
prefix with a 64 bit 4rd IID?

Won't anything that currently assumes 6to4 has exclusive use of
2002::/16 potentially have a problem, because actually the traffic isn't
really 6to4?
>> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
>> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
>> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
>> map to transport protocols, not individual IID bits)?
>
> 4rd addresses are those of tunnel endpoints in BRs and CEs. They are therefore not concerned with Address selection policies that are needed for applications having to choose among several source and/or destinations.
>   
So a CE router never sources or terminates an IPv4 or IPv6 session?

So a 4rd tunnel will never terminate on an end user device?

What about mobile phones and tablets attached to IPv6 only networks?
Wouldn't it be very attractive (and therefore likely) for them to act as
their own 4rd tunnel endpoint?

>
>> These questions probably have little relevance to 4rd being deployed in
>> an experimental situation, and I think we should perhaps try to keep
>> them decoupled as far as possible.
>
> Reservation of an unused IID range among those of RFC4291 is in my understanding already decoupled from the above issues. This reservation would be as safe if 4rd would be on standard track instead of experimental.
>
> Regards,
> RD
>
>
>
>>> one of my concerns is that continuing to add the interface-id bits, is the opposite direction of where
>>> I want us to go.
>>>
>>> I wouldn't object to non-normative language in 4rd suggesting a interface-id to use, without
>>> creating any expectation that new or existing IPv6 implementations have to change.
>>>
>>> that said, 4rd will work perfectly well _without_ this reservation, so I don't buy the argument that
>>> we're holding up the 4rd work.
>>>
>>> cheers,
>>> Ole
>>>
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>


From despres.remi@laposte.net  Thu Jan 31 06:17:28 2013
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 E6E2621F8503 for ; Thu, 31 Jan 2013 06:17:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.914
X-Spam-Level: 
X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.035,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 gIYmH8zVGVqA for ; Thu, 31 Jan 2013 06:17:28 -0800 (PST)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 03BC321F8442 for ; Thu, 31 Jan 2013 06:17:27 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 3C3CB700008F; Thu, 31 Jan 2013 15:17:26 +0100 (CET)
Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 166B27000089; Thu, 31 Jan 2013 15:17:25 +0100 (CET)
X-SFR-UUID: 20130131141726919.166B27000089@msfrf2206.sfr.fr
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= 
In-Reply-To: <510A563F.1090906@globis.net>
Date: Thu, 31 Jan 2013 15:17:24 +0100
Message-Id: <39C00F73-DF57-48A7-B803-5F6B8F79CAFC@laposte.net>
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <51094345.4030503@globis.net> <0E64F918-41FE-48B4-A57A-D6B40ABD962F@laposte.net> <510A563F.1090906@globis.net>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1499)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: 6man 6man-wg , 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, 31 Jan 2013 14:17:29 -0000

Ray,

Thanks for the acknowledgements of point that are now understood.
More clarification inline on others.

2013-01-31 12:32, Ray Hunter  :

> R=E9mi Despr=E9s wrote:
>> 2013-01-30  16:59, Ray Hunter   :
>> ...
>>> my 2 cents.
>>>=20
>>> If 4rd is truly experimental then indeed I think it's up to the
>>> operators deploying it to ensure they choose a unique IID range =
within
>>> the scope of where they are operating 4rd (between tunnel endpoints =
and
>>> the tunnel gateway).
>>=20
>> This misses the point that 4rd IIDs are chosen to be collision-free =
with all possible IPv6 hosts that, in sites that use 4rd for IPv4, are =
configured with SLAAC (and therefore have to comply with RFC4291).=20
>> IIDs of these hosts are assigned independently of any knowledge that =
4rd is used or not.
> Understood. No new reservation is required. No new behaviour is =
required
> of existing hosts.
>>> My initial concerns were that this could cause harm
>>> even in experimental form, but I've convinced myself that it =
shouldn't.
>>> In this case I see no need for a hard global IID reservation, =
because at
>>> the moment, u=3Dg=3D1 isn't used for creating IID's for use with =
SLAAC.
>>>=20
>>> On the other hand, If 4rd is not truly experimental, or it's =
expected to
>>> work universally across AS boundaries, I suspect the WG will have to
>>> wait for an answer to Brian's question on whether structure within =
the
>>> IID is desirable. I don't think there's any clear consensus so far =
on
>>> that point
>>=20
>>> (indeed there are some counter posts saying structure within
>>> the IID is undesirable).
>>=20
>> OK, it is a fact that, *for some addresses that aren't concerned with =
SLAAC*, typically some manually configured addresses, the IID structure =
of RFC 4291 can be ignored. One example where it is actually ignored is =
in RFC 6164  which deals with /127 prefixes on inter-router links. =
(Incidentally, I have been an active supporter of this RFC, as Miya =
Kohno may remember.
> Understood.  People running 4rd have to ensure manually assigned
> addresses avoid the 4rd range.
> Making a global reservation or not will likely not significantly =
change
> the impact of that.
>> But it is ALSO A FACT that *for IIDs that are used in SLAAC* there is =
some IID structure, the so called Modified EUI-64 format. (If u=3D other =
bits have no structure; if u=3D1, other bits must be based on IEEE link =
addresses. They then always have g=3D0, other combinations remaining =
available for future technologies.)
>> This structure is effectively used in OSes to automatically provide, =
by default, addresses that are stable in their environment. If MUST NOT =
be abandoned for addresses subject to SLAAC.
> Understood. No new reservation is required. No new behaviour is =
required
> of existing hosts.=20
>>> My own particular concern here is that there is a danger of creating =
a
>>> precedent of a completely new class of IPv6 addressing by the back =
door
>>> without this being fully and properly debated i.e. address ranges =
that
>>> don't perform DAD, and that are associated directly with a certain
>>> tunnel or transport protocol, and yet which are assigned within the
>>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>>> spaces too.
>>>=20
>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used =
by
>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>=20
>> 6to4 IIDs are ordinary unicast-address IIDs, subject to RFC 4291.=20
>> Consistency of the 4rd IID range with RFC 4291 therefore avoids any =
risk of conflict with 6to4.=20
> Right, so you're saying it's perfectly valid to combine a 64 bit 6to4
> prefix with a 64 bit 4rd IID?
>=20
> Won't anything that currently assumes 6to4 has exclusive use of
> 2002::/16 potentially have a problem, because actually the traffic =
isn't
> really 6to4?

6to4 is only a way to assign IPv6 PREFIXES.
IID constraints of RFC 4291 do apply to its IIDs, like with any other =
IPv6 prefix.
Nothing new concerning 6to4 in particular is therefore introduced by =
4rd.

>>> e.g. 2 How would this new class of IID encoded =
ranges/tunnel/transport
>>> protocols interact with RFC6724 and =
draft-ietf-6man-addr-select-opt-08
>>> (both of which assume that bit-contiguous left-anchored IPv6 =
prefixes
>>> map to transport protocols, not individual IID bits)?
>>=20
>> 4rd addresses are those of tunnel endpoints in BRs and CEs. They are =
therefore not concerned with Address selection policies that are needed =
for applications having to choose among several source and/or =
destinations.
>>=20
> So a CE router never sources or terminates an IPv4 or IPv6 session?
>=20
> So a 4rd tunnel will never terminate on an end user device?
>=20
> What about mobile phones and tablets attached to IPv6 only networks?

> Wouldn't it be very attractive (and therefore likely) for them to act =
as
> their own 4rd tunnel endpoint?

Very attractive indeed, and definitely a target (for 4rd as for MAP-E).

All incoming traffic having the 4rd destination address goes to the IPv6 =
interface of the CE function. It is then forwarded, in IPv4, to its IPv4 =
virtual interface.=20
Conversely, the CE function is the only one that may sends packets with =
the the 4rd IPv6 address as source.=20
Ref. http://www.ietf.org/proceedings/85/slides/slides-85-softwire-5.ppt

Regards,
RD



From despres.remi@laposte.net  Thu Jan 31 06:44:08 2013
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 C5D8A21F8583 for ; Thu, 31 Jan 2013 06:44:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level: 
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 KYOyQHH0jD7Z for ; Thu, 31 Jan 2013 06:44:07 -0800 (PST)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id 66E3D21F8589 for ; Thu, 31 Jan 2013 06:44:07 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 790F570000A3; Thu, 31 Jan 2013 15:44:06 +0100 (CET)
Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 5632C7000097; Thu, 31 Jan 2013 15:44:06 +0100 (CET)
X-SFR-UUID: 20130131144406353.5632C7000097@msfrf2206.sfr.fr
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= 
In-Reply-To: 
Date: Thu, 31 Jan 2013 15:44:05 +0100
Message-Id: <4A46CF39-7363-4923-9621-763781E7D875@laposte.net>
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <51094345.4030503@globis.net>  <510A46F3.5090407@globis.net> 
To: Ole Troan 
X-Mailer: Apple Mail (2.1499)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Ray Hunter , Bob Hinden , 6man 6man-wg 
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, 31 Jan 2013 14:44:09 -0000

2013-01-31  11:42, Ole Troan  :

> agree with what Ray says. that gives a path forward for 4rd without =
requiring us to settle the interface-id structure question.

Do you mean by this that "4rd will work perfectly well _without_ this =
reservation"?

- If not, please clarify what you mean.

- If yes, you forgot (once more!) that this reservation is what =
eliminates the risk of collisions with host addresses that, in 4rd =
sites, comply with RFC 4291. =20
In my understanding, Ray has now acknowledged this point.

RD



>=20
> cheers,
> Ole
>=20
>=20
> On Jan 31, 2013, at 11:26 , Ray Hunter  wrote:
>=20
>>> GangChen 
>>> 31 January 2013 08:53
>>> 2013/1/30, Ray Hunter :
>>>> inline.
>>>>=20
>>>> Ole Troan wrote:
>>>>> Brian,
>>>>>=20
>>>>>>>>> - If agreed on the principle, and if no one else volunteers, I =
can be
>>>>>>>>> available to propose a draft to this effect.
>>>>>>>> Seems reasonable.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused =
set of
>>>>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space for =
future
>>>>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>>>>> That goes to the argument of (d), that it isn't harmful to =
assign
>>>>>>>> some space to 4rd.
>>>>>>> I still think we need to answer the question Brian raised.
>>>>>>> should the interface-id have any encoded meaning?
>>>>>> That will not be done overnight. I've been thinking about it and
>>>>>> have some ideas about how to write a discussion draft, but it is
>>>>>> unfortuante to make the 4rd work queue behind us. Is there any =
risk
>>>>>> in doing as R=E9mi suggested?
>>>>> it depends on what the expected meaning of a reservation is.
>>>>> should all implementations treat the reserved part of the =
interface-id as
>>>>> martian,
>>>>> and prohibit a user from configuring it for another purpose than =
4rd?
>>>>>=20
>>>>> or is it just a 'suggestion' for interface-id's that the 4rd =
mechanism can
>>>>> use, and the operator
>>>>> deploying it will make sure there are no conflicts?
>>>> my 2 cents.
>>>>=20
>>>> If 4rd is truly experimental then indeed I think it's up to the
>>>> operators deploying it to ensure they choose a unique IID range =
within
>>>> the scope of where they are operating 4rd (between tunnel endpoints =
and
>>>> the tunnel gateway). My initial concerns were that this could cause =
harm
>>>> even in experimental form, but I've convinced myself that it =
shouldn't.
>>>> In this case I see no need for a hard global IID reservation, =
because at
>>>> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with =
SLAAC.
>>>=20
>>> Just some comments from operational views. I guess it's true =
operators
>>> could avoid confliction with u=3D1 g=3D1 in near future. However, I
>>> believe that is relative short-term guarantee with the condition of =
a
>>> particular operational domain. The term of "experimental" is not
>>> really mean "experimental" to a commercial network. It would be safe
>>> for operations if there is legitimate registry to ensure there is no
>>> need to renumbering. Therefore I prefer Remi's proposal (e) to grant
>>> 4rd 0x0300.
>>>=20
>>> Best Regards
>>>=20
>>> Gang
>>>=20
>>=20
>> I disagree.
>>=20
>> See http://www.ietf.org/iesg/informational-vs-experimental.html
>>=20
>> IMVHO "Experimental" means everything could change: including a need =
for
>> mass renumbering or equipment replacement.
>>=20
>> Publication is "Subject only to editorial considerations and to
>> verification that there has been adequate coordination with the
>> standards process." No guarantees. The test I am currently applying =
when
>> reviewing this ID is whether the experiment is likely to cause harm.
>>=20
>> I see no compelling reason at this time to define a global =
reservation
>> or an explicit IID structure in order for the experiment to be able =
to
>> proceed and succeed. On the other hand, adding a reservation and
>> structure to the IID at this time would likely impact other
>> implementations (e.g. packet classifiers) and existing documents and =
IDs
>> (e.g. address selection).
>>=20
>> If you want 4rd to be "informational" or "standards track" I also =
think
>> that's worth discussing, but then I also think there's a lot more to
>> specify and discuss beyond the current ID.
>>=20
>>>> On the other hand, If 4rd is not truly experimental, or it's =
expected to
>>>> work universally across AS boundaries, I suspect the WG will have =
to
>>>> wait for an answer to Brian's question on whether structure within =
the
>>>> IID is desirable. I don't think there's any clear consensus so far =
on
>>>> that point (indeed there are some counter posts saying structure =
within
>>>> the IID is undesirable).
>>>>=20
>>>> My own particular concern here is that there is a danger of =
creating a
>>>> precedent of a completely new class of IPv6 addressing by the back =
door
>>>> without this being fully and properly debated i.e. address ranges =
that
>>>> don't perform DAD, and that are associated directly with a certain
>>>> tunnel or transport protocol, and yet which are assigned within the
>>>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>>>> spaces too.
>>>>=20
>>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space =
used by
>>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>>>=20
>>>> e.g. 2 How would this new class of IID encoded =
ranges/tunnel/transport
>>>> protocols interact with RFC6724 and =
draft-ietf-6man-addr-select-opt-08
>>>> (both of which assume that bit-contiguous left-anchored IPv6 =
prefixes
>>>> map to transport protocols, not individual IID bits)?
>>>>=20
>>>> These questions probably have little relevance to 4rd being =
deployed in
>>>> an experimental situation, and I think we should perhaps try to =
keep
>>>> them decoupled as far as possible.
>>>>=20
>>>>> one of my concerns is that continuing to add the interface-id =
bits, is the
>>>>> opposite direction of where
>>>>> I want us to go.
>>>>>=20
>>>>> I wouldn't object to non-normative language in 4rd suggesting a
>>>>> interface-id to use, without
>>>>> creating any expectation that new or existing IPv6 implementations =
have to
>>>>> change.
>>>>>=20
>>>>> that said, 4rd will work perfectly well _without_ this =
reservation, so I
>>>>> don't buy the argument that
>>>>> we're holding up the 4rd work.
>>>>>=20
>>>>> cheers,
>>>>> Ole
>>>>>=20
>>>>>=20
>>>> =
--------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> =
--------------------------------------------------------------------
>>>>=20
>>> Ray Hunter 
>>> 30 January 2013 16:59
>>> inline.
>>>=20
>>> Ole Troan wrote:
>>>> Brian,
>>>>=20
>>>>>>>> - If agreed on the principle, and if no one else volunteers, I =
can be
>>>>>>>> available to propose a draft to this effect.
>>>>>>> Seems reasonable.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused =
set of
>>>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space for =
future
>>>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>>>> That goes to the argument of (d), that it isn't harmful to =
assign
>>>>>>> some space to 4rd.
>>>>>> I still think we need to answer the question Brian raised.
>>>>>> should the interface-id have any encoded meaning?
>>>>> That will not be done overnight. I've been thinking about it and
>>>>> have some ideas about how to write a discussion draft, but it is
>>>>> unfortuante to make the 4rd work queue behind us. Is there any =
risk
>>>>> in doing as R=E9mi suggested?
>>>> it depends on what the expected meaning of a reservation is.
>>>> should all implementations treat the reserved part of the =
interface-id as martian,
>>>> and prohibit a user from configuring it for another purpose than =
4rd?
>>>>=20
>>>> or is it just a 'suggestion' for interface-id's that the 4rd =
mechanism can use, and the operator
>>>> deploying it will make sure there are no conflicts?
>>> my 2 cents.
>>>=20
>>> If 4rd is truly experimental then indeed I think it's up to the
>>> operators deploying it to ensure they choose a unique IID range =
within
>>> the scope of where they are operating 4rd (between tunnel endpoints =
and
>>> the tunnel gateway). My initial concerns were that this could cause =
harm
>>> even in experimental form, but I've convinced myself that it =
shouldn't.
>>> In this case I see no need for a hard global IID reservation, =
because at
>>> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with =
SLAAC.
>>>=20
>>> On the other hand, If 4rd is not truly experimental, or it's =
expected to
>>> work universally across AS boundaries, I suspect the WG will have to
>>> wait for an answer to Brian's question on whether structure within =
the
>>> IID is desirable. I don't think there's any clear consensus so far =
on
>>> that point (indeed there are some counter posts saying structure =
within
>>> the IID is undesirable).
>>>=20
>>> My own particular concern here is that there is a danger of creating =
a
>>> precedent of a completely new class of IPv6 addressing by the back =
door
>>> without this being fully and properly debated i.e. address ranges =
that
>>> don't perform DAD, and that are associated directly with a certain
>>> tunnel or transport protocol, and yet which are assigned within the
>>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>>> spaces too.
>>>=20
>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used =
by
>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>>=20
>>> e.g. 2 How would this new class of IID encoded =
ranges/tunnel/transport
>>> protocols interact with RFC6724 and =
draft-ietf-6man-addr-select-opt-08
>>> (both of which assume that bit-contiguous left-anchored IPv6 =
prefixes
>>> map to transport protocols, not individual IID bits)?
>>>=20
>>> These questions probably have little relevance to 4rd being deployed =
in
>>> an experimental situation, and I think we should perhaps try to keep
>>> them decoupled as far as possible.
>>>=20
>>>> one of my concerns is that continuing to add the interface-id bits, =
is the opposite direction of where
>>>> I want us to go.
>>>>=20
>>>> I wouldn't object to non-normative language in 4rd suggesting a =
interface-id to use, without
>>>> creating any expectation that new or existing IPv6 implementations =
have to change.
>>>>=20
>>>> that said, 4rd will work perfectly well _without_ this reservation, =
so I don't buy the argument that
>>>> we're holding up the 4rd work.
>>>>=20
>>>> cheers,
>>>> Ole
>>>>=20
>>>>=20
>>>=20
>>> =
------------------------------------------------------------------------
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

From v6ops@globis.net  Thu Jan 31 07:43:49 2013
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 4BB6621F85A1 for ; Thu, 31 Jan 2013 07:43:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level: 
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 JMj5XBM79XMl for ; Thu, 31 Jan 2013 07:43:47 -0800 (PST)
Received: from globis01.globis.net (mail.globis.net [87.195.182.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1A73521F857C for ; Thu, 31 Jan 2013 07:43:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 15F248700FE; Thu, 31 Jan 2013 16:35:59 +0100 (CET)
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 1w6kRRFOqSux; Thu, 31 Jan 2013 16:35:29 +0100 (CET)
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 4AFD887005B; Thu, 31 Jan 2013 16:35:29 +0100 (CET)
Message-ID: <510A8F3B.5020107@globis.net>
Date: Thu, 31 Jan 2013 16:35:23 +0100
From: Ray Hunter 
User-Agent: Postbox 3.0.7 (Macintosh/20130119)
MIME-Version: 1.0
To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= 
Subject: Re: 4rd IID range & IPv6 addressing architecture
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <51094345.4030503@globis.net>  <510A46F3.5090407@globis.net>  <4A46CF39-7363-4923-9621-763781E7D875@laposte.net>
In-Reply-To: <4A46CF39-7363-4923-9621-763781E7D875@laposte.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: 6man 6man-wg , 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, 31 Jan 2013 15:43:49 -0000

> Rémi Després 
> 31 January 2013 15:44
> 2013-01-31  11:42, Ole Troan  :
>
>> agree with what Ray says. that gives a path forward for 4rd without requiring us to settle the interface-id structure question.
>
> Do you mean by this that "4rd will work perfectly well _without_ this reservation"?
>
> - If not, please clarify what you mean.
>
> - If yes, you forgot (once more!) that this reservation is what eliminates the risk of collisions with host addresses that, in 4rd sites, comply with RFC 4291.  
> In my understanding, Ray has now acknowledged this point.
>
> RD
No.

I acknowledge that I understood that no new behaviour is required of
existing implementations, and no existing standards need updating for
successful experimental deployment of 4rd.


I do not acknowledge that a (new) global IID reservation is necessary at
this time for 4rd to function perfectly correctly in an experimental
deployment.

In practical terms, a (new) reservation for experimental deployment of
4rd makes no difference whatsoever.

If there are few or no collisions at the IID level (as we expect), then
there's no need for a reservation for experimental 4rd at this time.

If there are collisions (e.g. due to static numbering) they'll have to
be renumbered or reconfigured before 4rd is deployed in that environment
whether a new reservation has been made in an RFC or not. Publishing an
RFC and registering something in IANA won't change the facts on the ground.

So unless you plan to update existing standards and/or require a
universal update of all non-4rd-aware implementations and deployments
(which I feel would be well beyond the spirit of the experimental status
of 4rd) I see no significant value in the assignment at this time.

And I don't see 6man assigning these u=1 g=1 EUI64 derived IID bits for
any other use at the moment either. But if the WG did decide to do that,
that would IMHO be the time to make the reservation, and to include a
range for exclusive use by 4rd if it was ever likely to move to
standards track.

regards,

>
>
>
>> cheers,
>> Ole
>>
>>
>> On Jan 31, 2013, at 11:26 , Ray Hunter  wrote:
>>
>>>> GangChen 
>>>> 31 January 2013 08:53
>>>> 2013/1/30, Ray Hunter :
>>>>> inline.
>>>>>
>>>>> Ole Troan wrote:
>>>>>> Brian,
>>>>>>
>>>>>>>>>> - If agreed on the principle, and if no one else volunteers, I can be
>>>>>>>>>> available to propose a draft to this effect.
>>>>>>>>> Seems reasonable.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>>>>>>>>> IIDs having u=1 is reserved. This leaves plenty of space for future
>>>>>>>>>> uses of IIDs having u= as explicitly expected in RFC 4291.
>>>>>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>>>>>> some space to 4rd.
>>>>>>>> I still think we need to answer the question Brian raised.
>>>>>>>> should the interface-id have any encoded meaning?
>>>>>>> That will not be done overnight. I've been thinking about it and
>>>>>>> have some ideas about how to write a discussion draft, but it is
>>>>>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>>>>>> in doing as Rémi suggested?
>>>>>> it depends on what the expected meaning of a reservation is.
>>>>>> should all implementations treat the reserved part of the interface-id as
>>>>>> martian,
>>>>>> and prohibit a user from configuring it for another purpose than 4rd?
>>>>>>
>>>>>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism can
>>>>>> use, and the operator
>>>>>> deploying it will make sure there are no conflicts?
>>>>> my 2 cents.
>>>>>
>>>>> If 4rd is truly experimental then indeed I think it's up to the
>>>>> operators deploying it to ensure they choose a unique IID range within
>>>>> the scope of where they are operating 4rd (between tunnel endpoints and
>>>>> the tunnel gateway). My initial concerns were that this could cause harm
>>>>> even in experimental form, but I've convinced myself that it shouldn't.
>>>>> In this case I see no need for a hard global IID reservation, because at
>>>>> the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC.
>>>> Just some comments from operational views. I guess it's true operators
>>>> could avoid confliction with u=1 g=1 in near future. However, I
>>>> believe that is relative short-term guarantee with the condition of a
>>>> particular operational domain. The term of "experimental" is not
>>>> really mean "experimental" to a commercial network. It would be safe
>>>> for operations if there is legitimate registry to ensure there is no
>>>> need to renumbering. Therefore I prefer Remi's proposal (e) to grant
>>>> 4rd 0x0300.
>>>>
>>>> Best Regards
>>>>
>>>> Gang
>>>>
>>> I disagree.
>>>
>>> See http://www.ietf.org/iesg/informational-vs-experimental.html
>>>
>>> IMVHO "Experimental" means everything could change: including a need for
>>> mass renumbering or equipment replacement.
>>>
>>> Publication is "Subject only to editorial considerations and to
>>> verification that there has been adequate coordination with the
>>> standards process." No guarantees. The test I am currently applying when
>>> reviewing this ID is whether the experiment is likely to cause harm.
>>>
>>> I see no compelling reason at this time to define a global reservation
>>> or an explicit IID structure in order for the experiment to be able to
>>> proceed and succeed. On the other hand, adding a reservation and
>>> structure to the IID at this time would likely impact other
>>> implementations (e.g. packet classifiers) and existing documents and IDs
>>> (e.g. address selection).
>>>
>>> If you want 4rd to be "informational" or "standards track" I also think
>>> that's worth discussing, but then I also think there's a lot more to
>>> specify and discuss beyond the current ID.
>>>
>>>>> On the other hand, If 4rd is not truly experimental, or it's expected to
>>>>> work universally across AS boundaries, I suspect the WG will have to
>>>>> wait for an answer to Brian's question on whether structure within the
>>>>> IID is desirable. I don't think there's any clear consensus so far on
>>>>> that point (indeed there are some counter posts saying structure within
>>>>> the IID is undesirable).
>>>>>
>>>>> My own particular concern here is that there is a danger of creating a
>>>>> precedent of a completely new class of IPv6 addressing by the back door
>>>>> without this being fully and properly debated i.e. address ranges that
>>>>> don't perform DAD, and that are associated directly with a certain
>>>>> tunnel or transport protocol, and yet which are assigned within the
>>>>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>>>>> spaces too.
>>>>>
>>>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
>>>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>>>>
>>>>> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
>>>>> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
>>>>> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
>>>>> map to transport protocols, not individual IID bits)?
>>>>>
>>>>> These questions probably have little relevance to 4rd being deployed in
>>>>> an experimental situation, and I think we should perhaps try to keep
>>>>> them decoupled as far as possible.
>>>>>
>>>>>> one of my concerns is that continuing to add the interface-id bits, is the
>>>>>> opposite direction of where
>>>>>> I want us to go.
>>>>>>
>>>>>> I wouldn't object to non-normative language in 4rd suggesting a
>>>>>> interface-id to use, without
>>>>>> creating any expectation that new or existing IPv6 implementations have to
>>>>>> change.
>>>>>>
>>>>>> that said, 4rd will work perfectly well _without_ this reservation, so I
>>>>>> don't buy the argument that
>>>>>> we're holding up the 4rd work.
>>>>>>
>>>>>> cheers,
>>>>>> Ole
>>>>>>
>>>>>>
>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> ipv6@ietf.org
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>>>>
>>>> Ray Hunter 
>>>> 30 January 2013 16:59
>>>> inline.
>>>>
>>>> Ole Troan wrote:
>>>>> Brian,
>>>>>
>>>>>>>>> - If agreed on the principle, and if no one else volunteers, I can be
>>>>>>>>> available to propose a draft to this effect.
>>>>>>>> Seems reasonable.
>>>>>>>>
>>>>>>>>
>>>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>>>>>>>> IIDs having u=1 is reserved. This leaves plenty of space for future
>>>>>>>>> uses of IIDs having u= as explicitly expected in RFC 4291.
>>>>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>>>>> some space to 4rd.
>>>>>>> I still think we need to answer the question Brian raised.
>>>>>>> should the interface-id have any encoded meaning?
>>>>>> That will not be done overnight. I've been thinking about it and
>>>>>> have some ideas about how to write a discussion draft, but it is
>>>>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>>>>> in doing as Rémi suggested?
>>>>> it depends on what the expected meaning of a reservation is.
>>>>> should all implementations treat the reserved part of the interface-id as martian,
>>>>> and prohibit a user from configuring it for another purpose than 4rd?
>>>>>
>>>>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism can use, and the operator
>>>>> deploying it will make sure there are no conflicts?
>>>> my 2 cents.
>>>>
>>>> If 4rd is truly experimental then indeed I think it's up to the
>>>> operators deploying it to ensure they choose a unique IID range within
>>>> the scope of where they are operating 4rd (between tunnel endpoints and
>>>> the tunnel gateway). My initial concerns were that this could cause harm
>>>> even in experimental form, but I've convinced myself that it shouldn't.
>>>> In this case I see no need for a hard global IID reservation, because at
>>>> the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC.
>>>>
>>>> On the other hand, If 4rd is not truly experimental, or it's expected to
>>>> work universally across AS boundaries, I suspect the WG will have to
>>>> wait for an answer to Brian's question on whether structure within the
>>>> IID is desirable. I don't think there's any clear consensus so far on
>>>> that point (indeed there are some counter posts saying structure within
>>>> the IID is undesirable).
>>>>
>>>> My own particular concern here is that there is a danger of creating a
>>>> precedent of a completely new class of IPv6 addressing by the back door
>>>> without this being fully and properly debated i.e. address ranges that
>>>> don't perform DAD, and that are associated directly with a certain
>>>> tunnel or transport protocol, and yet which are assigned within the
>>>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>>>> spaces too.
>>>>
>>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
>>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>>>
>>>> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
>>>> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
>>>> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
>>>> map to transport protocols, not individual IID bits)?
>>>>
>>>> These questions probably have little relevance to 4rd being deployed in
>>>> an experimental situation, and I think we should perhaps try to keep
>>>> them decoupled as far as possible.
>>>>
>>>>> one of my concerns is that continuing to add the interface-id bits, is the opposite direction of where
>>>>> I want us to go.
>>>>>
>>>>> I wouldn't object to non-normative language in 4rd suggesting a interface-id to use, without
>>>>> creating any expectation that new or existing IPv6 implementations have to change.
>>>>>
>>>>> that said, 4rd will work perfectly well _without_ this reservation, so I don't buy the argument that
>>>>> we're holding up the 4rd work.
>>>>>
>>>>> cheers,
>>>>> Ole
>>>>>
>>>>>
>>>> ------------------------------------------------------------------------
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> Ole Troan 
> 31 January 2013 11:42
> agree with what Ray says. that gives a path forward for 4rd without
> requiring us to settle the interface-id structure question.
>
> cheers,
> Ole
>
>
>
> Ray Hunter 
> 31 January 2013 11:26
>> GangChen 
>> 31 January 2013 08:53
>> 2013/1/30, Ray Hunter :
>>> inline.
>>>
>>> Ole Troan wrote:
>>>> Brian,
>>>>
>>>>>>>> - If agreed on the principle, and if no one else volunteers, I can be
>>>>>>>> available to propose a draft to this effect.
>>>>>>> Seems reasonable.
>>>>>>>
>>>>>>>
>>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>>>>>>> IIDs having u=1 is reserved. This leaves plenty of space for future
>>>>>>>> uses of IIDs having u= as explicitly expected in RFC 4291.
>>>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>>>> some space to 4rd.
>>>>>> I still think we need to answer the question Brian raised.
>>>>>> should the interface-id have any encoded meaning?
>>>>> That will not be done overnight. I've been thinking about it and
>>>>> have some ideas about how to write a discussion draft, but it is
>>>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>>>> in doing as Rémi suggested?
>>>> it depends on what the expected meaning of a reservation is.
>>>> should all implementations treat the reserved part of the interface-id as
>>>> martian,
>>>> and prohibit a user from configuring it for another purpose than 4rd?
>>>>
>>>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism can
>>>> use, and the operator
>>>> deploying it will make sure there are no conflicts?
>>> my 2 cents.
>>>
>>> If 4rd is truly experimental then indeed I think it's up to the
>>> operators deploying it to ensure they choose a unique IID range within
>>> the scope of where they are operating 4rd (between tunnel endpoints and
>>> the tunnel gateway). My initial concerns were that this could cause harm
>>> even in experimental form, but I've convinced myself that it shouldn't.
>>> In this case I see no need for a hard global IID reservation, because at
>>> the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC.
>> Just some comments from operational views. I guess it's true operators
>> could avoid confliction with u=1 g=1 in near future. However, I
>> believe that is relative short-term guarantee with the condition of a
>> particular operational domain. The term of "experimental" is not
>> really mean "experimental" to a commercial network. It would be safe
>> for operations if there is legitimate registry to ensure there is no
>> need to renumbering. Therefore I prefer Remi's proposal (e) to grant
>> 4rd 0x0300.
>>
>> Best Regards
>>
>> Gang
>>
>
> I disagree.
>
> See http://www.ietf.org/iesg/informational-vs-experimental.html
>
> IMVHO "Experimental" means everything could change: including a need for
> mass renumbering or equipment replacement.
>
> Publication is "Subject only to editorial considerations and to
> verification that there has been adequate coordination with the
> standards process." No guarantees. The test I am currently applying when
> reviewing this ID is whether the experiment is likely to cause harm.
>
> I see no compelling reason at this time to define a global reservation
> or an explicit IID structure in order for the experiment to be able to
> proceed and succeed. On the other hand, adding a reservation and
> structure to the IID at this time would likely impact other
> implementations (e.g. packet classifiers) and existing documents and IDs
> (e.g. address selection).
>
> If you want 4rd to be "informational" or "standards track" I also think
> that's worth discussing, but then I also think there's a lot more to
> specify and discuss beyond the current ID.
>
>>> On the other hand, If 4rd is not truly experimental, or it's expected to
>>> work universally across AS boundaries, I suspect the WG will have to
>>> wait for an answer to Brian's question on whether structure within the
>>> IID is desirable. I don't think there's any clear consensus so far on
>>> that point (indeed there are some counter posts saying structure within
>>> the IID is undesirable).
>>>
>>> My own particular concern here is that there is a danger of creating a
>>> precedent of a completely new class of IPv6 addressing by the back door
>>> without this being fully and properly debated i.e. address ranges that
>>> don't perform DAD, and that are associated directly with a certain
>>> tunnel or transport protocol, and yet which are assigned within the
>>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>>> spaces too.
>>>
>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>>
>>> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
>>> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
>>> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
>>> map to transport protocols, not individual IID bits)?
>>>
>>> These questions probably have little relevance to 4rd being deployed in
>>> an experimental situation, and I think we should perhaps try to keep
>>> them decoupled as far as possible.
>>>
>>>> one of my concerns is that continuing to add the interface-id bits, is the
>>>> opposite direction of where
>>>> I want us to go.
>>>>
>>>> I wouldn't object to non-normative language in 4rd suggesting a
>>>> interface-id to use, without
>>>> creating any expectation that new or existing IPv6 implementations have to
>>>> change.
>>>>
>>>> that said, 4rd will work perfectly well _without_ this reservation, so I
>>>> don't buy the argument that
>>>> we're holding up the 4rd work.
>>>>
>>>> cheers,
>>>> Ole
>>>>
>>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>> Ray Hunter 
>> 30 January 2013 16:59
>> inline.
>>
>> Ole Troan wrote:
>>> Brian,
>>>
>>>>>>> - If agreed on the principle, and if no one else volunteers, I can be
>>>>>>> available to propose a draft to this effect.
>>>>>> Seems reasonable.
>>>>>>
>>>>>>
>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>>>>>> IIDs having u=1 is reserved. This leaves plenty of space for future
>>>>>>> uses of IIDs having u= as explicitly expected in RFC 4291.
>>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>>> some space to 4rd.
>>>>> I still think we need to answer the question Brian raised.
>>>>> should the interface-id have any encoded meaning?
>>>> That will not be done overnight. I've been thinking about it and
>>>> have some ideas about how to write a discussion draft, but it is
>>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>>> in doing as Rémi suggested?
>>> it depends on what the expected meaning of a reservation is.
>>> should all implementations treat the reserved part of the interface-id as martian,
>>> and prohibit a user from configuring it for another purpose than 4rd?
>>>
>>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism can use, and the operator
>>> deploying it will make sure there are no conflicts?
>> my 2 cents.
>>
>> If 4rd is truly experimental then indeed I think it's up to the
>> operators deploying it to ensure they choose a unique IID range within
>> the scope of where they are operating 4rd (between tunnel endpoints and
>> the tunnel gateway). My initial concerns were that this could cause harm
>> even in experimental form, but I've convinced myself that it shouldn't.
>> In this case I see no need for a hard global IID reservation, because at
>> the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC.
>>
>> On the other hand, If 4rd is not truly experimental, or it's expected to
>> work universally across AS boundaries, I suspect the WG will have to
>> wait for an answer to Brian's question on whether structure within the
>> IID is desirable. I don't think there's any clear consensus so far on
>> that point (indeed there are some counter posts saying structure within
>> the IID is undesirable).
>>
>> My own particular concern here is that there is a danger of creating a
>> precedent of a completely new class of IPv6 addressing by the back door
>> without this being fully and properly debated i.e. address ranges that
>> don't perform DAD, and that are associated directly with a certain
>> tunnel or transport protocol, and yet which are assigned within the
>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>> spaces too.
>>
>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>
>> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
>> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
>> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
>> map to transport protocols, not individual IID bits)?
>>
>> These questions probably have little relevance to 4rd being deployed in
>> an experimental situation, and I think we should perhaps try to keep
>> them decoupled as far as possible.
>>
>>> one of my concerns is that continuing to add the interface-id bits, is the opposite direction of where
>>> I want us to go.
>>>
>>> I wouldn't object to non-normative language in 4rd suggesting a interface-id to use, without
>>> creating any expectation that new or existing IPv6 implementations have to change.
>>>
>>> that said, 4rd will work perfectly well _without_ this reservation, so I don't buy the argument that
>>> we're holding up the 4rd work.
>>>
>>> cheers,
>>> Ole
>>>
>>>
>> ------------------------------------------------------------------------
>
> GangChen 
> 31 January 2013 08:53
> 2013/1/30, Ray Hunter :
>> inline.
>>
>> Ole Troan wrote:
>>> Brian,
>>>
>>>>>>> - If agreed on the principle, and if no one else volunteers, I can be
>>>>>>> available to propose a draft to this effect.
>>>>>> Seems reasonable.
>>>>>>
>>>>>>
>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>>>>>> IIDs having u=1 is reserved. This leaves plenty of space for future
>>>>>>> uses of IIDs having u= as explicitly expected in RFC 4291.
>>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>>> some space to 4rd.
>>>>> I still think we need to answer the question Brian raised.
>>>>> should the interface-id have any encoded meaning?
>>>> That will not be done overnight. I've been thinking about it and
>>>> have some ideas about how to write a discussion draft, but it is
>>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>>> in doing as Rémi suggested?
>>> it depends on what the expected meaning of a reservation is.
>>> should all implementations treat the reserved part of the interface-id as
>>> martian,
>>> and prohibit a user from configuring it for another purpose than 4rd?
>>>
>>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism can
>>> use, and the operator
>>> deploying it will make sure there are no conflicts?
>> my 2 cents.
>>
>> If 4rd is truly experimental then indeed I think it's up to the
>> operators deploying it to ensure they choose a unique IID range within
>> the scope of where they are operating 4rd (between tunnel endpoints and
>> the tunnel gateway). My initial concerns were that this could cause harm
>> even in experimental form, but I've convinced myself that it shouldn't.
>> In this case I see no need for a hard global IID reservation, because at
>> the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC.
>
> Just some comments from operational views. I guess it's true operators
> could avoid confliction with u=1 g=1 in near future. However, I
> believe that is relative short-term guarantee with the condition of a
> particular operational domain. The term of "experimental" is not
> really mean "experimental" to a commercial network. It would be safe
> for operations if there is legitimate registry to ensure there is no
> need to renumbering. Therefore I prefer Remi's proposal (e) to grant
> 4rd 0x0300.
>
> Best Regards
>
> Gang
>
>
>> On the other hand, If 4rd is not truly experimental, or it's expected to
>> work universally across AS boundaries, I suspect the WG will have to
>> wait for an answer to Brian's question on whether structure within the
>> IID is desirable. I don't think there's any clear consensus so far on
>> that point (indeed there are some counter posts saying structure within
>> the IID is undesirable).
>>
>> My own particular concern here is that there is a danger of creating a
>> precedent of a completely new class of IPv6 addressing by the back door
>> without this being fully and properly debated i.e. address ranges that
>> don't perform DAD, and that are associated directly with a certain
>> tunnel or transport protocol, and yet which are assigned within the
>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>> spaces too.
>>
>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>
>> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
>> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
>> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
>> map to transport protocols, not individual IID bits)?
>>
>> These questions probably have little relevance to 4rd being deployed in
>> an experimental situation, and I think we should perhaps try to keep
>> them decoupled as far as possible.
>>
>>> one of my concerns is that continuing to add the interface-id bits, is the
>>> opposite direction of where
>>> I want us to go.
>>>
>>> I wouldn't object to non-normative language in 4rd suggesting a
>>> interface-id to use, without
>>> creating any expectation that new or existing IPv6 implementations have to
>>> change.
>>>
>>> that said, 4rd will work perfectly well _without_ this reservation, so I
>>> don't buy the argument that
>>> we're holding up the 4rd work.
>>>
>>> cheers,
>>> Ole
>>>
>>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> Ray Hunter 
> 30 January 2013 16:59
> inline.
>
> Ole Troan wrote:
>> Brian,
>>
>>>>>> - If agreed on the principle, and if no one else volunteers, I can be
>>>>>> available to propose a draft to this effect.
>>>>> Seems reasonable.
>>>>>
>>>>>
>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
>>>>>> IIDs having u=1 is reserved. This leaves plenty of space for future
>>>>>> uses of IIDs having u= as explicitly expected in RFC 4291.
>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>> some space to 4rd.
>>>> I still think we need to answer the question Brian raised.
>>>> should the interface-id have any encoded meaning?
>>> That will not be done overnight. I've been thinking about it and
>>> have some ideas about how to write a discussion draft, but it is
>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>> in doing as Rémi suggested?
>> it depends on what the expected meaning of a reservation is.
>> should all implementations treat the reserved part of the interface-id as martian,
>> and prohibit a user from configuring it for another purpose than 4rd?
>>
>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism can use, and the operator
>> deploying it will make sure there are no conflicts?
> my 2 cents.
>
> If 4rd is truly experimental then indeed I think it's up to the
> operators deploying it to ensure they choose a unique IID range within
> the scope of where they are operating 4rd (between tunnel endpoints and
> the tunnel gateway). My initial concerns were that this could cause harm
> even in experimental form, but I've convinced myself that it shouldn't.
> In this case I see no need for a hard global IID reservation, because at
> the moment, u=1 g=1 isn't used for creating IID's for use with SLAAC.
>
> On the other hand, If 4rd is not truly experimental, or it's expected to
> work universally across AS boundaries, I suspect the WG will have to
> wait for an answer to Brian's question on whether structure within the
> IID is desirable. I don't think there's any clear consensus so far on
> that point (indeed there are some counter posts saying structure within
> the IID is undesirable).
>
> My own particular concern here is that there is a danger of creating a
> precedent of a completely new class of IPv6 addressing by the back door
> without this being fully and properly debated i.e. address ranges that
> don't perform DAD, and that are associated directly with a certain
> tunnel or transport protocol, and yet which are assigned within the
> generic GUA space, but perhaps which overlap with other IPv6 prefix
> spaces too.
>
> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
> 6to4 (2002::/16) being associated with 4rd IIDs?
>
> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
> map to transport protocols, not individual IID bits)?
>
> These questions probably have little relevance to 4rd being deployed in
> an experimental situation, and I think we should perhaps try to keep
> them decoupled as far as possible.
>
>> one of my concerns is that continuing to add the interface-id bits, is the opposite direction of where
>> I want us to go.
>>
>> I wouldn't object to non-normative language in 4rd suggesting a interface-id to use, without
>> creating any expectation that new or existing IPv6 implementations have to change.
>>
>> that said, 4rd will work perfectly well _without_ this reservation, so I don't buy the argument that
>> we're holding up the 4rd work.
>>
>> cheers,
>> Ole
>>
>>
>
> ------------------------------------------------------------------------


From rja.lists@gmail.com  Thu Jan 31 07:54:34 2013
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 4B42921F856C for ; Thu, 31 Jan 2013 07:54:34 -0800 (PST)
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 iw-vYE84RBpr for ; Thu, 31 Jan 2013 07:54:29 -0800 (PST)
Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0618121F8526 for ; Thu, 31 Jan 2013 07:54:26 -0800 (PST)
Received: by mail-qe0-f45.google.com with SMTP id b4so1341712qen.32 for ; Thu, 31 Jan 2013 07:54:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=M24sLaHEl0pWDwDBZugTs3blNjJ57RqC6e/8fkui3Fk=; b=vPDPPfjTDttoMO93TAI+aFy8HwT4XRkaXgt6J6xf7eQ3b38QkFfy/9gvJXhJFd2s0V 6GEenRESlPBmvrnPf3d78195VUXN1VYH63JwEU84e0yIKdCiN3/XicDeii6u+GlsPZ5f 0OfHU5BbppI4+f/gaoFu7gQ+Vn0rvVBEMsPJ0OHR6rI6RYHxVmNnFAXMoYN5J/CkTnWS 3JdqD9lxMEm6wf+5QkLLPSl5XxZZK9Q9zX+q6v9Wqdn/fYOJ8mEOIrRCrZuZp6agyDK6 i4m5slGWzjNAz4b3pPFDPlPWnkIJ2GaCxv0DnD/yHhgdZJ9R8eS9+81keUgDKiwmQvRP 5eOQ==
X-Received: by 10.224.209.193 with SMTP id gh1mr9395032qab.86.1359647666433; Thu, 31 Jan 2013 07:54:26 -0800 (PST)
Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id ei2sm4614254qab.3.2013.01.31.07.54.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 07:54:25 -0800 (PST)
From: RJ Atkinson 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: 4rd IID range & IPv6 addressing architecture
Date: Thu, 31 Jan 2013 10:54:24 -0500
Message-Id: <034A969A-98AB-40D0-B7D6-01FDC482C552@gmail.com>
To: ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
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, 31 Jan 2013 15:54:34 -0000

Remi,

PLEASE STOP making incorrect statements about ILNP.
Perhaps you haven't had time to read the full ILNP 
literature, but your (repeated) claims about ILNP 
are wrong -- contradicted by published papers, etc.


For those who'd like to read more about ILNP, a reasonably 
complete archive of ILNP papers is maintained online at:
	http://ilnp.cs.st-andrews.ac.uk
Most papers there are freely available, but a few have 
copyright restrictions and link to appropriate access URLs.


I understand your desire to strongly advocate for
your proposal, but please STOP mis-characterising
ILNP as part of your advocacy.




All,

On 21st January, Remi Depres wrote, in part:
> (In particular, they don't conflict with those
> of ILNP.)


This is NOT true. 

ILNP has published papers describing the use of
(U=G=1) as a multicast group identifier with ILNP.
As with ALL of ILNP, that use is experimental at
present.

However, the proposed "4rd" is ALSO EXPERIMENTAL.
The Software WG decided to standardise a different
proposal -- not standardise "4rd".  Separately,
we have several different IPv6 transition technologies
defined, most of which are NOT used (or not used
in any measurably frequent way).  

On 30th January, Remi Depres wrote, in part:
> ILNP, which has u=0.
> Out of scope!


1) The quote above is wrong.  ILNP uses the U bit
   as defined by RFC-4291 && by IEEE EUI-64 standards.
   So ILNP has BOTH U=1 and U=0 support.  ILNP also
   uses the G bit as defined by IEEE EUI-64 standards
   when U=1.  This use is consistent with the IESG 

2) ILNP does have published papers describing the use 
   of (U=G=1) as a multicast group identifier with ILNP.
   As with ALL of ILNP, that use is experimental at
   present.  Again, "4rd" is being proposed as experimental
   also, because Softwire chose to standardise a different
   (competing) proposal.



On 30th January, Ole Troan wrote, in part:
> On 30th January, Remi Depres wrote, in part:
>> ("The use of the universal/local bit in the Modified EUI-64 
>> format identifier is to allow development of future technology 
>> that can take advantage of interface identifiers with universal 
>> scope").
> 
> yes, that technology is called ILNP. It does not require
> globally unique interface identifiers, which in any case
> would have required some sort of registry.

(clarification)

I believe that at the time RFC-4291 was written, that phrase
referred to the GSE/8+8 concept from Mike O'Dell.  ILNP is
an intellectual descendant/relative of Mike O'Dell's proposals,
as is HIP, but ILNP is more fully specified than GSE/8+8 and 
has some technical differences from GSE/8+8.  ILNP does 
"take advantage of interface identifiers with universal scope".
However, I believe some other protocols by other folks 
also seek to do so.

There is the larger topic here.  This proposal is not mere 
bit twiddling, but in fact makes a significant architectural 
change.  Reading the discussions here, it is not obvious
to me whether the 6MAN WG wants to make those fundamental 
architectural changes to the IPv6 Identifier namespace.
For my own part, I'm not persuaded that such changes are
wise to undertake at this time.



(new topic)

Ray Hunter and others make compelling arguments that
4rd does not need this allocation in order to go forward 
*as an experiment* (which is precisely what Experimental 
status means in a document) at this time.  So it seems 
rash and premature to make a large permanent allocation 
of a limited resource to the 4rd experiment at this time,
especially since Software WG is standardising an approach
directly competing with "4rd".

I would not object to having some small set aside of
Identifier space for SHARED experimental use under the
RFC-3692/RFC-4727 rules, provided that it were clear that 
such experiments could NOT interfere with proper operation 
of SLAAC or other basic IPv6 operational functions
(i.e the caveat that Ray Hunter explained on-list in 
recent days).

Yours,

Ran Atkinson



From rogerj@gmail.com  Thu Jan 31 09:25:47 2013
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 1242B21F84FC for ; Thu, 31 Jan 2013 09:25:47 -0800 (PST)
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 n8WKrvSkcRPa for ; Thu, 31 Jan 2013 09:25:46 -0800 (PST)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0219E21F84F8 for ; Thu, 31 Jan 2013 09:25:45 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id hm14so3065131wib.10 for ; Thu, 31 Jan 2013 09:25:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=4HJQeH4zcgn7dws4icGy2lI23jQUBW5gad2igyw417s=; b=pUPghEbV9EPttSpstD2Zg23oxJnnVEiuSmQDqmSmfVIvrmXtQAsskwaLrASyXlYjSe xUYSiZrGzJRSy+SuSnI1mgsQBh9oiPU7J/451Px8lXpdtBxmfBYLwPqaBAIpsfsZzLEF 7YrWjJ1VQdOo40dwr5vkWq+EILZntde16d32vHN+2bXhrtiunhKyfOsyYfhjvuA23Aec BxFjvuIyJw0pMH7KYK5O96ESKuc5FAKPmF1yxyW+8JPTAEUE6WR69DEdeFM8IogTXQHP XII1iKdAhS3P1jLtsl4suVcNBfOJs+zQgFNaSWsdl3b/BnWva4OYKcT6mXsQFnkBjXFC 3TQQ==
MIME-Version: 1.0
X-Received: by 10.180.73.80 with SMTP id j16mr16515431wiv.5.1359653145160; Thu, 31 Jan 2013 09:25:45 -0800 (PST)
Received: by 10.217.44.74 with HTTP; Thu, 31 Jan 2013 09:25:44 -0800 (PST)
In-Reply-To: 
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <51094345.4030503@globis.net>  <510A46F3.5090407@globis.net> 
Date: Thu, 31 Jan 2013 17:25:44 +0000
Message-ID: 
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= 
To: Ole Troan , Ray Hunter ,  Bob Hinden , 6man 6man-wg 
Content-Type: text/plain; charset=ISO-8859-1
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, 31 Jan 2013 17:25:47 -0000

On Thu, Jan 31, 2013 at 10:42 AM, Ole Troan  wrote:
> agree with what Ray says. that gives a path forward for 4rd without requiring us to settle the interface-id structure question.

For what it's worth, I also agree with Ray.


Nothing brought forward by or from 4rd have convince me about anything else.



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj@gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger@jorgensen.no

From rajiva@cisco.com  Thu Jan 31 09:26:44 2013
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 B647621F8621 for ; Thu, 31 Jan 2013 09:26:44 -0800 (PST)
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 FSzPPRpF6ZI2 for ; Thu, 31 Jan 2013 09:26:44 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9A421F84F8 for ; Thu, 31 Jan 2013 09:26:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1576; q=dns/txt; s=iport; t=1359653203; x=1360862803; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=c6ihanQRz4wIdDaY2JmU62HPgARFvlHoEWX6YzOieMU=; b=hYlOSzUf7aZNXQ3zGL2MO1PhGj2gHXIZLDES0jqBVNM2RyeilCa0AcSm /UVOujxGIUcit+QJ1J660Vo97vphM3332yICWGV7LbBklx7KIg+QcRJOE 6ooXkrOgn0h8OZgB+QruHKHNYuF2I2X8kq8PKsSd/04wYouVGneXai6wF 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAAioClGtJXHA/2dsb2JhbABFvx8Wc4IeAQEBBDo/DAYBCA4DAwECAQoUQh0IAgQBDQUIiAkMwiqNBoMlYQOXLo8wgneCJA
X-IronPort-AV: E=Sophos;i="4.84,577,1355097600"; d="scan'208";a="171234574"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 31 Jan 2013 17:26:43 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0VHQhdo026881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jan 2013 17:26:43 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 11:26:42 -0600
From: "Rajiv Asati (rajiva)" 
To: Philipp Kern , Brian Hamacher 
Subject: Re: MAC Address Tracking via DHCP6
Thread-Topic: MAC Address Tracking via DHCP6
Thread-Index: AQHN/9giM3WALPSOxEqXmVcvCQGGwQ==
Date: Thu, 31 Jan 2013 17:26:42 +0000
Message-ID: 
In-Reply-To: <20121212153725.GA11716@spike.0x539.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.5.121010
x-originating-ip: [10.86.115.198]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <094D1AB986BAC24FB80035C559CA6535@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipv6@ietf.org" 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 17:26:44 -0000

There is a better way out to track the IPv6 addresses used by the hosts
(via SLAAC or static) -

http://tools.ietf.org/html/draft-asati-dhc-ipv6-autoconfig-address-tracking

Cheers,
Rajiv

-----Original Message-----
From: Philipp Kern 
Organization: The Debian Project (http://www.debian.org)
Date: Wednesday, December 12, 2012 10:37 AM
To: Brian Hamacher 
Cc: "ipv6@ietf.org" 
Subject: Re: MAC Address Tracking

>On Tue, Dec 11, 2012 at 04:04:14PM -0600, Brian Hamacher wrote:
>> I am looking for a good way to track my users MAC Addresses.  I have a
>> test DHCPv6 server up and running ISC 4.1.1-P1.  When I look through my
>> DHCP logs as well as my leases file I do not see the client MAC Address
>> anywhere.  Do I need to enable an option to allow this to be logged?  I
>> am looking to figure out how I can track what user had what IP Address
>> at any given time.  The MAC Address is traditionally how I have done
>> this.
>
>One way would be to poll your routers' ND tables (like fetching ARP tables
>in IPv4). As soon as you use relaying you most certainly won't get a
>useable MAC address from your client, even though it might be possible in
>the same network segment. (The MAC address is not copied from the wire
>into the new relayed packet sent by the router to your server.)
>
>DHCPv6 uses the so-called client identifier extensively and not the MAC
>address anymore. So you cannot do any static assignment based on MAC
>addresses.
>
>Kind regards
>Philipp Kern


From despres.remi@laposte.net  Thu Jan 31 09:28:46 2013
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 1858E21F8574 for ; Thu, 31 Jan 2013 09:28:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.297
X-Spam-Level: 
X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24]
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 E3dUR4LyrSOM for ; Thu, 31 Jan 2013 09:28:44 -0800 (PST)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC2C21F8550 for ; Thu, 31 Jan 2013 09:28:43 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id 38E3870000E5; Thu, 31 Jan 2013 18:28:42 +0100 (CET)
Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id 969CF70000AD; Thu, 31 Jan 2013 18:28:41 +0100 (CET)
X-SFR-UUID: 20130131172841616.969CF70000AD@msfrf2214.sfr.fr
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= 
In-Reply-To: <510A8F3B.5020107@globis.net>
Date: Thu, 31 Jan 2013 18:28:40 +0100
Message-Id: <2060D997-AEA9-45CB-849A-067927633CCB@laposte.net>
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <51094345.4030503@globis.net>  <510A46F3.5090407@globis.net>  <4A46CF39-7363-4923-9621-763781E7D875@laposte.net> <510A8F3B.5020107@globis.net>
To: Ray Hunter 
X-Mailer: Apple Mail (2.1499)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: 6man 6man-wg , 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, 31 Jan 2013 17:28:46 -0000

2013-01-31 16:35, Ray Hunter :

>> R=E9mi Despr=E9s 
>> 31 January 2013 15:44
>> 2013-01-31  11:42, Ole Troan  :
>>=20
>>> agree with what Ray says. that gives a path forward for 4rd without =
requiring us to settle the interface-id structure question.
>>=20
>> Do you mean by this that "4rd will work perfectly well _without_ this =
reservation"?
>>=20
>> - If not, please clarify what you mean.
>>=20
>> - If yes, you forgot (once more!) that this reservation is what =
eliminates the risk of
>> collisions with host addresses that, in 4rd sites, comply with RFC =
4291.
>> In my understanding, Ray has now acknowledged this point.
>>=20
>> RD


> No.

I see. Thanks for the clarification.=20
Sorry for having misunderstood what you meant in the following answer to =
my point:
>> This misses the point that 4rd IIDs are chosen to be collision-free =
with all possible IPv6 hosts that, in sites that use 4rd for IPv4, are =
configured with SLAAC (and therefore have to comply with RFC4291).=20
>> IIDs of these hosts are assigned independently of any knowledge that =
4rd is used or not.
> Understood. No new reservation is required. No new behaviour is =
required
> of existing hosts.
(At least you didn't negate that the proposed 4rd range reservation =
eliminates the risk of collisions with hosts that, in 4rd sites, use =
SLAAC.)=20


Now, more comments now on what you added:

> I acknowledge that I understood that no new behaviour is required of
> existing implementations, and no existing standards need updating for
> successful experimental deployment of 4rd.

OK. This remains important.

> I do not acknowledge that a (new) global IID reservation is necessary =
at
> this time for 4rd to function perfectly correctly in an experimental
> deployment.

The difference you make between working "perfectly" "in an experimental =
environment" and working "perfectly" in some other environment, say in =
production environment, is unclear to me.=20

The 4rd specification has been frozen for a long time now. It is only =
waiting for the 6man response on compatibility of its reserved IID range =
with the IPv6 addressing architecture.=20

The decision to keep 4rd experimental has been made to avoid several =
similar standards, but not because of remaining issues on its ability to =
work in production environments.=20


> In practical terms, a (new) reservation for experimental deployment of
> 4rd makes no difference whatsoever.

Well, this reservation does ensure that no other reservation can be =
made, at any time, which would conflict with that used for 4rd.
The registry of reserved IID ranges is precisely the place to ensure it.


> If there are few or no collisions at the IID level (as we expect), =
then
> there's no need for a reservation for experimental 4rd at this time.

Completed designs, if available and simple, are better than designs that =
are already known to be incomplete *including for experiments*.=20

In this instance, no possible collisions is better than possibly a few =
(with additional precautions to deal with them, and risks of having to =
renumber).=20

Is it right to suppose we can agree on this?


> If there are collisions (e.g. due to static numbering) they'll have to
> be renumbered or reconfigured before 4rd is deployed in that =
environment
> whether a new reservation has been made in an RFC or not. Publishing =
an
> RFC and registering something in IANA won't change the facts on the =
ground.
>=20
> So unless you plan to update existing standards and/or require a
> universal update of all non-4rd-aware implementations and deployments
> (which I feel would be well beyond the spirit of the experimental =
status
> of 4rd) I see no significant value in the assignment at this time.

Requiring a "universal update of all non-4rd-aware implementations and =
deployments" wouldn't make sense at all!
If you think 4rd might introduce such a requirement, could you please =
explain?

The only standard-track update that is needed concerns RFC 5453, to =
permit an IID-range reservation for an experimental track solution that =
doesn't imply any "disruption to existing implementations". =20


> And I don't see 6man assigning these u=3D1 g=3D1 EUI64 derived IID =
bits for
> any other use at the moment either.

I don't see any either... but sometimes progress needs a pioneer case =
;-).

> But if the WG did decide to do that,
> that would IMHO be the time to make the reservation, and to include a
> range for exclusive use by 4rd if it was ever likely to move to
> standards track.

If 4rd may ever be moved to standard track despite its level of =
commonality with MAP-E, it would only be because its functional =
differences are then found significant enough. In view of the recent =
debate in Softwire, its happening in any short term is very doubtful.=20

Yet, what will happen in the longer term belongs to the future.
Today, let's just do things right.=20
In this instance, this means reserving the IID range that is needed for =
4rd to be up to its objectives.

Regards,
RD




>=20
> regards,
>=20
>>=20
>>=20
>>=20
>>> cheers,
>>> Ole
>>>=20
>>>=20
>>> On Jan 31, 2013, at 11:26 , Ray Hunter  wrote:
>>>=20
>>>>> GangChen 
>>>>> 31 January 2013 08:53
>>>>> 2013/1/30, Ray Hunter :
>>>>>> inline.
>>>>>>=20
>>>>>> Ole Troan wrote:
>>>>>>> Brian,
>>>>>>>=20
>>>>>>>>>>> - If agreed on the principle, and if no one else volunteers, =
I can be
>>>>>>>>>>> available to propose a draft to this effect.
>>>>>>>>>> Seems reasonable.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the =
unused set of
>>>>>>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space =
for future
>>>>>>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>>>>>>> That goes to the argument of (d), that it isn't harmful to =
assign
>>>>>>>>>> some space to 4rd.
>>>>>>>>> I still think we need to answer the question Brian raised.
>>>>>>>>> should the interface-id have any encoded meaning?
>>>>>>>> That will not be done overnight. I've been thinking about it =
and
>>>>>>>> have some ideas about how to write a discussion draft, but it =
is
>>>>>>>> unfortuante to make the 4rd work queue behind us. Is there any =
risk
>>>>>>>> in doing as R=E9mi suggested?
>>>>>>> it depends on what the expected meaning of a reservation is.
>>>>>>> should all implementations treat the reserved part of the =
interface-id as
>>>>>>> martian,
>>>>>>> and prohibit a user from configuring it for another purpose than =
4rd?
>>>>>>>=20
>>>>>>> or is it just a 'suggestion' for interface-id's that the 4rd =
mechanism can
>>>>>>> use, and the operator
>>>>>>> deploying it will make sure there are no conflicts?
>>>>>> my 2 cents.
>>>>>>=20
>>>>>> If 4rd is truly experimental then indeed I think it's up to the
>>>>>> operators deploying it to ensure they choose a unique IID range =
within
>>>>>> the scope of where they are operating 4rd (between tunnel =
endpoints and
>>>>>> the tunnel gateway). My initial concerns were that this could =
cause harm
>>>>>> even in experimental form, but I've convinced myself that it =
shouldn't.
>>>>>> In this case I see no need for a hard global IID reservation, =
because at
>>>>>> the moment, u=3D1 g=3D1 isn't used for creating IID's for use =
with SLAAC.
>>>>> Just some comments from operational views. I guess it's true =
operators
>>>>> could avoid confliction with u=3D1 g=3D1 in near future. However, =
I
>>>>> believe that is relative short-term guarantee with the condition =
of a
>>>>> particular operational domain. The term of "experimental" is not
>>>>> really mean "experimental" to a commercial network. It would be =
safe
>>>>> for operations if there is legitimate registry to ensure there is =
no
>>>>> need to renumbering. Therefore I prefer Remi's proposal (e) to =
grant
>>>>> 4rd 0x0300.
>>>>>=20
>>>>> Best Regards
>>>>>=20
>>>>> Gang
>>>>>=20
>>>> I disagree.
>>>>=20
>>>> See http://www.ietf.org/iesg/informational-vs-experimental.html
>>>>=20
>>>> IMVHO "Experimental" means everything could change: including a =
need for
>>>> mass renumbering or equipment replacement.
>>>>=20
>>>> Publication is "Subject only to editorial considerations and to
>>>> verification that there has been adequate coordination with the
>>>> standards process." No guarantees. The test I am currently applying =
when
>>>> reviewing this ID is whether the experiment is likely to cause =
harm.
>>>>=20
>>>> I see no compelling reason at this time to define a global =
reservation
>>>> or an explicit IID structure in order for the experiment to be able =
to
>>>> proceed and succeed. On the other hand, adding a reservation and
>>>> structure to the IID at this time would likely impact other
>>>> implementations (e.g. packet classifiers) and existing documents =
and IDs
>>>> (e.g. address selection).
>>>>=20
>>>> If you want 4rd to be "informational" or "standards track" I also =
think
>>>> that's worth discussing, but then I also think there's a lot more =
to
>>>> specify and discuss beyond the current ID.
>>>>=20
>>>>>> On the other hand, If 4rd is not truly experimental, or it's =
expected to
>>>>>> work universally across AS boundaries, I suspect the WG will have =
to
>>>>>> wait for an answer to Brian's question on whether structure =
within the
>>>>>> IID is desirable. I don't think there's any clear consensus so =
far on
>>>>>> that point (indeed there are some counter posts saying structure =
within
>>>>>> the IID is undesirable).
>>>>>>=20
>>>>>> My own particular concern here is that there is a danger of =
creating a
>>>>>> precedent of a completely new class of IPv6 addressing by the =
back door
>>>>>> without this being fully and properly debated i.e. address ranges =
that
>>>>>> don't perform DAD, and that are associated directly with a =
certain
>>>>>> tunnel or transport protocol, and yet which are assigned within =
the
>>>>>> generic GUA space, but perhaps which overlap with other IPv6 =
prefix
>>>>>> spaces too.
>>>>>>=20
>>>>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space =
used by
>>>>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>>>>>=20
>>>>>> e.g. 2 How would this new class of IID encoded =
ranges/tunnel/transport
>>>>>> protocols interact with RFC6724 and =
draft-ietf-6man-addr-select-opt-08
>>>>>> (both of which assume that bit-contiguous left-anchored IPv6 =
prefixes
>>>>>> map to transport protocols, not individual IID bits)?
>>>>>>=20
>>>>>> These questions probably have little relevance to 4rd being =
deployed in
>>>>>> an experimental situation, and I think we should perhaps try to =
keep
>>>>>> them decoupled as far as possible.
>>>>>>=20
>>>>>>> one of my concerns is that continuing to add the interface-id =
bits, is the
>>>>>>> opposite direction of where
>>>>>>> I want us to go.
>>>>>>>=20
>>>>>>> I wouldn't object to non-normative language in 4rd suggesting a
>>>>>>> interface-id to use, without
>>>>>>> creating any expectation that new or existing IPv6 =
implementations have to
>>>>>>> change.
>>>>>>>=20
>>>>>>> that said, 4rd will work perfectly well _without_ this =
reservation, so I
>>>>>>> don't buy the argument that
>>>>>>> we're holding up the 4rd work.
>>>>>>>=20
>>>>>>> cheers,
>>>>>>> Ole
>>>>>>>=20
>>>>>>>=20
>>>>>> =
--------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> ipv6@ietf.org
>>>>>> Administrative Requests: =
https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> =
--------------------------------------------------------------------
>>>>>>=20
>>>>> Ray Hunter 
>>>>> 30 January 2013 16:59
>>>>> inline.
>>>>>=20
>>>>> Ole Troan wrote:
>>>>>> Brian,
>>>>>>=20
>>>>>>>>>> - If agreed on the principle, and if no one else volunteers, =
I can be
>>>>>>>>>> available to propose a draft to this effect.
>>>>>>>>> Seems reasonable.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused =
set of
>>>>>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space =
for future
>>>>>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>>>>>> That goes to the argument of (d), that it isn't harmful to =
assign
>>>>>>>>> some space to 4rd.
>>>>>>>> I still think we need to answer the question Brian raised.
>>>>>>>> should the interface-id have any encoded meaning?
>>>>>>> That will not be done overnight. I've been thinking about it and
>>>>>>> have some ideas about how to write a discussion draft, but it is
>>>>>>> unfortuante to make the 4rd work queue behind us. Is there any =
risk
>>>>>>> in doing as R=E9mi suggested?
>>>>>> it depends on what the expected meaning of a reservation is.
>>>>>> should all implementations treat the reserved part of the =
interface-id as martian,
>>>>>> and prohibit a user from configuring it for another purpose than =
4rd?
>>>>>>=20
>>>>>> or is it just a 'suggestion' for interface-id's that the 4rd =
mechanism can use, and the operator
>>>>>> deploying it will make sure there are no conflicts?
>>>>> my 2 cents.
>>>>>=20
>>>>> If 4rd is truly experimental then indeed I think it's up to the
>>>>> operators deploying it to ensure they choose a unique IID range =
within
>>>>> the scope of where they are operating 4rd (between tunnel =
endpoints and
>>>>> the tunnel gateway). My initial concerns were that this could =
cause harm
>>>>> even in experimental form, but I've convinced myself that it =
shouldn't.
>>>>> In this case I see no need for a hard global IID reservation, =
because at
>>>>> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with =
SLAAC.
>>>>>=20
>>>>> On the other hand, If 4rd is not truly experimental, or it's =
expected to
>>>>> work universally across AS boundaries, I suspect the WG will have =
to
>>>>> wait for an answer to Brian's question on whether structure within =
the
>>>>> IID is desirable. I don't think there's any clear consensus so far =
on
>>>>> that point (indeed there are some counter posts saying structure =
within
>>>>> the IID is undesirable).
>>>>>=20
>>>>> My own particular concern here is that there is a danger of =
creating a
>>>>> precedent of a completely new class of IPv6 addressing by the back =
door
>>>>> without this being fully and properly debated i.e. address ranges =
that
>>>>> don't perform DAD, and that are associated directly with a certain
>>>>> tunnel or transport protocol, and yet which are assigned within =
the
>>>>> generic GUA space, but perhaps which overlap with other IPv6 =
prefix
>>>>> spaces too.
>>>>>=20
>>>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space =
used by
>>>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>>>>=20
>>>>> e.g. 2 How would this new class of IID encoded =
ranges/tunnel/transport
>>>>> protocols interact with RFC6724 and =
draft-ietf-6man-addr-select-opt-08
>>>>> (both of which assume that bit-contiguous left-anchored IPv6 =
prefixes
>>>>> map to transport protocols, not individual IID bits)?
>>>>>=20
>>>>> These questions probably have little relevance to 4rd being =
deployed in
>>>>> an experimental situation, and I think we should perhaps try to =
keep
>>>>> them decoupled as far as possible.
>>>>>=20
>>>>>> one of my concerns is that continuing to add the interface-id =
bits, is the opposite direction of where
>>>>>> I want us to go.
>>>>>>=20
>>>>>> I wouldn't object to non-normative language in 4rd suggesting a =
interface-id to use, without
>>>>>> creating any expectation that new or existing IPv6 =
implementations have to change.
>>>>>>=20
>>>>>> that said, 4rd will work perfectly well _without_ this =
reservation, so I don't buy the argument that
>>>>>> we're holding up the 4rd work.
>>>>>>=20
>>>>>> cheers,
>>>>>> Ole
>>>>>>=20
>>>>>>=20
>>>>> =
------------------------------------------------------------------------
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> Ole Troan 
>> 31 January 2013 11:42
>> agree with what Ray says. that gives a path forward for 4rd without
>> requiring us to settle the interface-id structure question.
>>=20
>> cheers,
>> Ole
>>=20
>>=20
>>=20
>> Ray Hunter 
>> 31 January 2013 11:26
>>> GangChen 
>>> 31 January 2013 08:53
>>> 2013/1/30, Ray Hunter :
>>>> inline.
>>>>=20
>>>> Ole Troan wrote:
>>>>> Brian,
>>>>>=20
>>>>>>>>> - If agreed on the principle, and if no one else volunteers, I =
can be
>>>>>>>>> available to propose a draft to this effect.
>>>>>>>> Seems reasonable.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused =
set of
>>>>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space for =
future
>>>>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>>>>> That goes to the argument of (d), that it isn't harmful to =
assign
>>>>>>>> some space to 4rd.
>>>>>>> I still think we need to answer the question Brian raised.
>>>>>>> should the interface-id have any encoded meaning?
>>>>>> That will not be done overnight. I've been thinking about it and
>>>>>> have some ideas about how to write a discussion draft, but it is
>>>>>> unfortuante to make the 4rd work queue behind us. Is there any =
risk
>>>>>> in doing as R=E9mi suggested?
>>>>> it depends on what the expected meaning of a reservation is.
>>>>> should all implementations treat the reserved part of the =
interface-id as
>>>>> martian,
>>>>> and prohibit a user from configuring it for another purpose than =
4rd?
>>>>>=20
>>>>> or is it just a 'suggestion' for interface-id's that the 4rd =
mechanism can
>>>>> use, and the operator
>>>>> deploying it will make sure there are no conflicts?
>>>> my 2 cents.
>>>>=20
>>>> If 4rd is truly experimental then indeed I think it's up to the
>>>> operators deploying it to ensure they choose a unique IID range =
within
>>>> the scope of where they are operating 4rd (between tunnel endpoints =
and
>>>> the tunnel gateway). My initial concerns were that this could cause =
harm
>>>> even in experimental form, but I've convinced myself that it =
shouldn't.
>>>> In this case I see no need for a hard global IID reservation, =
because at
>>>> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with =
SLAAC.
>>> Just some comments from operational views. I guess it's true =
operators
>>> could avoid confliction with u=3D1 g=3D1 in near future. However, I
>>> believe that is relative short-term guarantee with the condition of =
a
>>> particular operational domain. The term of "experimental" is not
>>> really mean "experimental" to a commercial network. It would be safe
>>> for operations if there is legitimate registry to ensure there is no
>>> need to renumbering. Therefore I prefer Remi's proposal (e) to grant
>>> 4rd 0x0300.
>>>=20
>>> Best Regards
>>>=20
>>> Gang
>>>=20
>>=20
>> I disagree.
>>=20
>> See http://www.ietf.org/iesg/informational-vs-experimental.html
>>=20
>> IMVHO "Experimental" means everything could change: including a need =
for
>> mass renumbering or equipment replacement.
>>=20
>> Publication is "Subject only to editorial considerations and to
>> verification that there has been adequate coordination with the
>> standards process." No guarantees. The test I am currently applying =
when
>> reviewing this ID is whether the experiment is likely to cause harm.
>>=20
>> I see no compelling reason at this time to define a global =
reservation
>> or an explicit IID structure in order for the experiment to be able =
to
>> proceed and succeed. On the other hand, adding a reservation and
>> structure to the IID at this time would likely impact other
>> implementations (e.g. packet classifiers) and existing documents and =
IDs
>> (e.g. address selection).
>>=20
>> If you want 4rd to be "informational" or "standards track" I also =
think
>> that's worth discussing, but then I also think there's a lot more to
>> specify and discuss beyond the current ID.
>>=20
>>>> On the other hand, If 4rd is not truly experimental, or it's =
expected to
>>>> work universally across AS boundaries, I suspect the WG will have =
to
>>>> wait for an answer to Brian's question on whether structure within =
the
>>>> IID is desirable. I don't think there's any clear consensus so far =
on
>>>> that point (indeed there are some counter posts saying structure =
within
>>>> the IID is undesirable).
>>>>=20
>>>> My own particular concern here is that there is a danger of =
creating a
>>>> precedent of a completely new class of IPv6 addressing by the back =
door
>>>> without this being fully and properly debated i.e. address ranges =
that
>>>> don't perform DAD, and that are associated directly with a certain
>>>> tunnel or transport protocol, and yet which are assigned within the
>>>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>>>> spaces too.
>>>>=20
>>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space =
used by
>>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>>>=20
>>>> e.g. 2 How would this new class of IID encoded =
ranges/tunnel/transport
>>>> protocols interact with RFC6724 and =
draft-ietf-6man-addr-select-opt-08
>>>> (both of which assume that bit-contiguous left-anchored IPv6 =
prefixes
>>>> map to transport protocols, not individual IID bits)?
>>>>=20
>>>> These questions probably have little relevance to 4rd being =
deployed in
>>>> an experimental situation, and I think we should perhaps try to =
keep
>>>> them decoupled as far as possible.
>>>>=20
>>>>> one of my concerns is that continuing to add the interface-id =
bits, is the
>>>>> opposite direction of where
>>>>> I want us to go.
>>>>>=20
>>>>> I wouldn't object to non-normative language in 4rd suggesting a
>>>>> interface-id to use, without
>>>>> creating any expectation that new or existing IPv6 implementations =
have to
>>>>> change.
>>>>>=20
>>>>> that said, 4rd will work perfectly well _without_ this =
reservation, so I
>>>>> don't buy the argument that
>>>>> we're holding up the 4rd work.
>>>>>=20
>>>>> cheers,
>>>>> Ole
>>>>>=20
>>>>>=20
>>>> =
--------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> =
--------------------------------------------------------------------
>>>>=20
>>> Ray Hunter 
>>> 30 January 2013 16:59
>>> inline.
>>>=20
>>> Ole Troan wrote:
>>>> Brian,
>>>>=20
>>>>>>>> - If agreed on the principle, and if no one else volunteers, I =
can be
>>>>>>>> available to propose a draft to this effect.
>>>>>>> Seems reasonable.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused =
set of
>>>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space for =
future
>>>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>>>> That goes to the argument of (d), that it isn't harmful to =
assign
>>>>>>> some space to 4rd.
>>>>>> I still think we need to answer the question Brian raised.
>>>>>> should the interface-id have any encoded meaning?
>>>>> That will not be done overnight. I've been thinking about it and
>>>>> have some ideas about how to write a discussion draft, but it is
>>>>> unfortuante to make the 4rd work queue behind us. Is there any =
risk
>>>>> in doing as R=E9mi suggested?
>>>> it depends on what the expected meaning of a reservation is.
>>>> should all implementations treat the reserved part of the =
interface-id as martian,
>>>> and prohibit a user from configuring it for another purpose than =
4rd?
>>>>=20
>>>> or is it just a 'suggestion' for interface-id's that the 4rd =
mechanism can use, and the operator
>>>> deploying it will make sure there are no conflicts?
>>> my 2 cents.
>>>=20
>>> If 4rd is truly experimental then indeed I think it's up to the
>>> operators deploying it to ensure they choose a unique IID range =
within
>>> the scope of where they are operating 4rd (between tunnel endpoints =
and
>>> the tunnel gateway). My initial concerns were that this could cause =
harm
>>> even in experimental form, but I've convinced myself that it =
shouldn't.
>>> In this case I see no need for a hard global IID reservation, =
because at
>>> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with =
SLAAC.
>>>=20
>>> On the other hand, If 4rd is not truly experimental, or it's =
expected to
>>> work universally across AS boundaries, I suspect the WG will have to
>>> wait for an answer to Brian's question on whether structure within =
the
>>> IID is desirable. I don't think there's any clear consensus so far =
on
>>> that point (indeed there are some counter posts saying structure =
within
>>> the IID is undesirable).
>>>=20
>>> My own particular concern here is that there is a danger of creating =
a
>>> precedent of a completely new class of IPv6 addressing by the back =
door
>>> without this being fully and properly debated i.e. address ranges =
that
>>> don't perform DAD, and that are associated directly with a certain
>>> tunnel or transport protocol, and yet which are assigned within the
>>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>>> spaces too.
>>>=20
>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used =
by
>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>>=20
>>> e.g. 2 How would this new class of IID encoded =
ranges/tunnel/transport
>>> protocols interact with RFC6724 and =
draft-ietf-6man-addr-select-opt-08
>>> (both of which assume that bit-contiguous left-anchored IPv6 =
prefixes
>>> map to transport protocols, not individual IID bits)?
>>>=20
>>> These questions probably have little relevance to 4rd being deployed =
in
>>> an experimental situation, and I think we should perhaps try to keep
>>> them decoupled as far as possible.
>>>=20
>>>> one of my concerns is that continuing to add the interface-id bits, =
is the opposite direction of where
>>>> I want us to go.
>>>>=20
>>>> I wouldn't object to non-normative language in 4rd suggesting a =
interface-id to use, without
>>>> creating any expectation that new or existing IPv6 implementations =
have to change.
>>>>=20
>>>> that said, 4rd will work perfectly well _without_ this reservation, =
so I don't buy the argument that
>>>> we're holding up the 4rd work.
>>>>=20
>>>> cheers,
>>>> Ole
>>>>=20
>>>>=20
>>> =
------------------------------------------------------------------------
>>=20
>> GangChen 
>> 31 January 2013 08:53
>> 2013/1/30, Ray Hunter :
>>> inline.
>>>=20
>>> Ole Troan wrote:
>>>> Brian,
>>>>=20
>>>>>>>> - If agreed on the principle, and if no one else volunteers, I =
can be
>>>>>>>> available to propose a draft to this effect.
>>>>>>> Seems reasonable.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused =
set of
>>>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space for =
future
>>>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>>>> That goes to the argument of (d), that it isn't harmful to =
assign
>>>>>>> some space to 4rd.
>>>>>> I still think we need to answer the question Brian raised.
>>>>>> should the interface-id have any encoded meaning?
>>>>> That will not be done overnight. I've been thinking about it and
>>>>> have some ideas about how to write a discussion draft, but it is
>>>>> unfortuante to make the 4rd work queue behind us. Is there any =
risk
>>>>> in doing as R=E9mi suggested?
>>>> it depends on what the expected meaning of a reservation is.
>>>> should all implementations treat the reserved part of the =
interface-id as
>>>> martian,
>>>> and prohibit a user from configuring it for another purpose than =
4rd?
>>>>=20
>>>> or is it just a 'suggestion' for interface-id's that the 4rd =
mechanism can
>>>> use, and the operator
>>>> deploying it will make sure there are no conflicts?
>>> my 2 cents.
>>>=20
>>> If 4rd is truly experimental then indeed I think it's up to the
>>> operators deploying it to ensure they choose a unique IID range =
within
>>> the scope of where they are operating 4rd (between tunnel endpoints =
and
>>> the tunnel gateway). My initial concerns were that this could cause =
harm
>>> even in experimental form, but I've convinced myself that it =
shouldn't.
>>> In this case I see no need for a hard global IID reservation, =
because at
>>> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with =
SLAAC.
>>=20
>> Just some comments from operational views. I guess it's true =
operators
>> could avoid confliction with u=3D1 g=3D1 in near future. However, I
>> believe that is relative short-term guarantee with the condition of a
>> particular operational domain. The term of "experimental" is not
>> really mean "experimental" to a commercial network. It would be safe
>> for operations if there is legitimate registry to ensure there is no
>> need to renumbering. Therefore I prefer Remi's proposal (e) to grant
>> 4rd 0x0300.
>>=20
>> Best Regards
>>=20
>> Gang
>>=20
>>=20
>>> On the other hand, If 4rd is not truly experimental, or it's =
expected to
>>> work universally across AS boundaries, I suspect the WG will have to
>>> wait for an answer to Brian's question on whether structure within =
the
>>> IID is desirable. I don't think there's any clear consensus so far =
on
>>> that point (indeed there are some counter posts saying structure =
within
>>> the IID is undesirable).
>>>=20
>>> My own particular concern here is that there is a danger of creating =
a
>>> precedent of a completely new class of IPv6 addressing by the back =
door
>>> without this being fully and properly debated i.e. address ranges =
that
>>> don't perform DAD, and that are associated directly with a certain
>>> tunnel or transport protocol, and yet which are assigned within the
>>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>>> spaces too.
>>>=20
>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used =
by
>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>>=20
>>> e.g. 2 How would this new class of IID encoded =
ranges/tunnel/transport
>>> protocols interact with RFC6724 and =
draft-ietf-6man-addr-select-opt-08
>>> (both of which assume that bit-contiguous left-anchored IPv6 =
prefixes
>>> map to transport protocols, not individual IID bits)?
>>>=20
>>> These questions probably have little relevance to 4rd being deployed =
in
>>> an experimental situation, and I think we should perhaps try to keep
>>> them decoupled as far as possible.
>>>=20
>>>> one of my concerns is that continuing to add the interface-id bits, =
is the
>>>> opposite direction of where
>>>> I want us to go.
>>>>=20
>>>> I wouldn't object to non-normative language in 4rd suggesting a
>>>> interface-id to use, without
>>>> creating any expectation that new or existing IPv6 implementations =
have to
>>>> change.
>>>>=20
>>>> that said, 4rd will work perfectly well _without_ this reservation, =
so I
>>>> don't buy the argument that
>>>> we're holding up the 4rd work.
>>>>=20
>>>> cheers,
>>>> Ole
>>>>=20
>>>>=20
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>=20
>> Ray Hunter 
>> 30 January 2013 16:59
>> inline.
>>=20
>> Ole Troan wrote:
>>> Brian,
>>>=20
>>>>>>> - If agreed on the principle, and if no one else volunteers, I =
can be
>>>>>>> available to propose a draft to this effect.
>>>>>> Seems reasonable.
>>>>>>=20
>>>>>>=20
>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused =
set of
>>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space for =
future
>>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>>> some space to 4rd.
>>>>> I still think we need to answer the question Brian raised.
>>>>> should the interface-id have any encoded meaning?
>>>> That will not be done overnight. I've been thinking about it and
>>>> have some ideas about how to write a discussion draft, but it is
>>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>>> in doing as R=E9mi suggested?
>>> it depends on what the expected meaning of a reservation is.
>>> should all implementations treat the reserved part of the =
interface-id as martian,
>>> and prohibit a user from configuring it for another purpose than =
4rd?
>>>=20
>>> or is it just a 'suggestion' for interface-id's that the 4rd =
mechanism can use, and the operator
>>> deploying it will make sure there are no conflicts?
>> my 2 cents.
>>=20
>> If 4rd is truly experimental then indeed I think it's up to the
>> operators deploying it to ensure they choose a unique IID range =
within
>> the scope of where they are operating 4rd (between tunnel endpoints =
and
>> the tunnel gateway). My initial concerns were that this could cause =
harm
>> even in experimental form, but I've convinced myself that it =
shouldn't.
>> In this case I see no need for a hard global IID reservation, because =
at
>> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with =
SLAAC.
>>=20
>> On the other hand, If 4rd is not truly experimental, or it's expected =
to
>> work universally across AS boundaries, I suspect the WG will have to
>> wait for an answer to Brian's question on whether structure within =
the
>> IID is desirable. I don't think there's any clear consensus so far on
>> that point (indeed there are some counter posts saying structure =
within
>> the IID is undesirable).
>>=20
>> My own particular concern here is that there is a danger of creating =
a
>> precedent of a completely new class of IPv6 addressing by the back =
door
>> without this being fully and properly debated i.e. address ranges =
that
>> don't perform DAD, and that are associated directly with a certain
>> tunnel or transport protocol, and yet which are assigned within the
>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>> spaces too.
>>=20
>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used =
by
>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>=20
>> e.g. 2 How would this new class of IID encoded =
ranges/tunnel/transport
>> protocols interact with RFC6724 and =
draft-ietf-6man-addr-select-opt-08
>> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
>> map to transport protocols, not individual IID bits)?
>>=20
>> These questions probably have little relevance to 4rd being deployed =
in
>> an experimental situation, and I think we should perhaps try to keep
>> them decoupled as far as possible.
>>=20
>>> one of my concerns is that continuing to add the interface-id bits, =
is the opposite direction of where
>>> I want us to go.
>>>=20
>>> I wouldn't object to non-normative language in 4rd suggesting a =
interface-id to use, without
>>> creating any expectation that new or existing IPv6 implementations =
have to change.
>>>=20
>>> that said, 4rd will work perfectly well _without_ this reservation, =
so I don't buy the argument that
>>> we're holding up the 4rd work.
>>>=20
>>> cheers,
>>> Ole
>>>=20
>>>=20
>>=20
>> =
------------------------------------------------------------------------
>=20

From despres.remi@laposte.net  Thu Jan 31 10:11:37 2013
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 2C86121F86A5 for ; Thu, 31 Jan 2013 10:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level: 
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 5WMzQaGtvUx3 for ; Thu, 31 Jan 2013 10:11:36 -0800 (PST)
Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4652821F855D for ; Thu, 31 Jan 2013 10:11:28 -0800 (PST)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id 00BC37000178; Thu, 31 Jan 2013 19:11:27 +0100 (CET)
Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2214.sfr.fr (SMTP Server) with ESMTP id C2AED70000E2; Thu, 31 Jan 2013 19:11:26 +0100 (CET)
X-SFR-UUID: 20130131181126797.C2AED70000E2@msfrf2214.sfr.fr
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= 
In-Reply-To: <034A969A-98AB-40D0-B7D6-01FDC482C552@gmail.com>
Date: Thu, 31 Jan 2013 19:11:25 +0100
Message-Id: <3EFD1D88-0FE2-451E-BD71-CFCD4F9D292B@laposte.net>
References: <034A969A-98AB-40D0-B7D6-01FDC482C552@gmail.com>
To: RJ Atkinson 
X-Mailer: Apple Mail (2.1499)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jan 2013 18:11:37 -0000

Ran,=20

Oops!

I must really apologize for having given a wrong reason why 4rd doesn't =
conflict with ILNP as specified by RFCs.=20
(I didn't check yesterday what I had understood, some time ago, after =
reading some of the ILNP RFCs, and definitely mischaracterized the =
reason).

What ensures 4rd doesn't conflict with ILNP isn't at all that ILNP only =
uses u=3D0.=20
It is that, in ILNP, no u=3Dg=3D1 is used in *unicast* addresses (those =
whose IIDs are specified by RFC 4291).=20

Thank you for having pointed out the mistake.
RD


Le 2013-01-31 =E0 16:54, RJ Atkinson  a =E9crit :

> Remi,
>=20
> PLEASE STOP making incorrect statements about ILNP.
> Perhaps you haven't had time to read the full ILNP=20
> literature, but your (repeated) claims about ILNP=20
> are wrong -- contradicted by published papers, etc.
>=20
>=20
> For those who'd like to read more about ILNP, a reasonably=20
> complete archive of ILNP papers is maintained online at:
> 	http://ilnp.cs.st-andrews.ac.uk
> Most papers there are freely available, but a few have=20
> copyright restrictions and link to appropriate access URLs.
>=20
>=20
> I understand your desire to strongly advocate for
> your proposal, but please STOP mis-characterising
> ILNP as part of your advocacy.
>=20
>=20
>=20
>=20
> All,
>=20
> On 21st January, Remi Depres wrote, in part:
>> (In particular, they don't conflict with those
>> of ILNP.)
>=20
>=20
> This is NOT true.=20
>=20
> ILNP has published papers describing the use of
> (U=3DG=3D1) as a multicast group identifier with ILNP.
> As with ALL of ILNP, that use is experimental at
> present.
>=20
> However, the proposed "4rd" is ALSO EXPERIMENTAL.
> The Software WG decided to standardise a different
> proposal -- not standardise "4rd".  Separately,
> we have several different IPv6 transition technologies
> defined, most of which are NOT used (or not used
> in any measurably frequent way). =20
>=20
> On 30th January, Remi Depres wrote, in part:
>> ILNP, which has u=3D0.
>> Out of scope!
>=20
>=20
> 1) The quote above is wrong.  ILNP uses the U bit
>   as defined by RFC-4291 && by IEEE EUI-64 standards.
>   So ILNP has BOTH U=3D1 and U=3D0 support.  ILNP also
>   uses the G bit as defined by IEEE EUI-64 standards
>   when U=3D1.  This use is consistent with the IESG=20
>=20
> 2) ILNP does have published papers describing the use=20
>   of (U=3DG=3D1) as a multicast group identifier with ILNP.
>   As with ALL of ILNP, that use is experimental at
>   present.  Again, "4rd" is being proposed as experimental
>   also, because Softwire chose to standardise a different
>   (competing) proposal.
>=20
>=20
>=20
> On 30th January, Ole Troan wrote, in part:
>> On 30th January, Remi Depres wrote, in part:
>>> ("The use of the universal/local bit in the Modified EUI-64=20
>>> format identifier is to allow development of future technology=20
>>> that can take advantage of interface identifiers with universal=20
>>> scope").
>>=20
>> yes, that technology is called ILNP. It does not require
>> globally unique interface identifiers, which in any case
>> would have required some sort of registry.
>=20
> (clarification)
>=20
> I believe that at the time RFC-4291 was written, that phrase
> referred to the GSE/8+8 concept from Mike O'Dell.  ILNP is
> an intellectual descendant/relative of Mike O'Dell's proposals,
> as is HIP, but ILNP is more fully specified than GSE/8+8 and=20
> has some technical differences from GSE/8+8.  ILNP does=20
> "take advantage of interface identifiers with universal scope".
> However, I believe some other protocols by other folks=20
> also seek to do so.
>=20
> There is the larger topic here.  This proposal is not mere=20
> bit twiddling, but in fact makes a significant architectural=20
> change.  Reading the discussions here, it is not obvious
> to me whether the 6MAN WG wants to make those fundamental=20
> architectural changes to the IPv6 Identifier namespace.
> For my own part, I'm not persuaded that such changes are
> wise to undertake at this time.
>=20
>=20
>=20
> (new topic)
>=20
> Ray Hunter and others make compelling arguments that
> 4rd does not need this allocation in order to go forward=20
> *as an experiment* (which is precisely what Experimental=20
> status means in a document) at this time.  So it seems=20
> rash and premature to make a large permanent allocation=20
> of a limited resource to the 4rd experiment at this time,
> especially since Software WG is standardising an approach
> directly competing with "4rd".
>=20
> I would not object to having some small set aside of
> Identifier space for SHARED experimental use under the
> RFC-3692/RFC-4727 rules, provided that it were clear that=20
> such experiments could NOT interfere with proper operation=20
> of SLAAC or other basic IPv6 operational functions
> (i.e the caveat that Ray Hunter explained on-list in=20
> recent days).
>=20
> Yours,
>=20
> Ran Atkinson
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

From phdgang@gmail.com  Thu Jan 31 19:57:44 2013
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 052F721F8893 for ; Thu, 31 Jan 2013 19:57:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.549
X-Spam-Level: 
X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050,  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 oABEVNP5v2dD for ; Thu, 31 Jan 2013 19:57:43 -0800 (PST)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C258821F888E for ; Thu, 31 Jan 2013 19:57:42 -0800 (PST)
Received: by mail-qa0-f44.google.com with SMTP id bv4so90227qab.3 for ; Thu, 31 Jan 2013 19:57:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=QN5joiTTzK1j597i+STJn+gKdoHhOUDC0BYclVTatCw=; b=WRgsjw4JBZnIFDmIy2F6u2KU8MNIbVpV3mixEMTIHf6wA62SmcLkLsjz34aZA2tLL1 c5ZXHc4wYNay8Bj2l5Iwgbb+Y/aXn1mYX2eF7mszYO3haTbFplekzE9+vWiifjYwKmHd LeWwwDDvHarBFXvCBi15C91HduXp8ksEczzfISVPHwh5NvRAIswJ17hNu1TuCBo08u4h /jsbieQQKCmX8qrar3E2KsjcKlQV6tqqwn2pC4BSGCTVbbFNZJ0KU9PfCIZDsxcSzRGd Dk6Xpo3wCkEhZ1UfiknvNqLTzkfhty/uVzzzoIn2A7vRNZgkR6Qw3nujY12nOR9+R+Ac rUcA==
MIME-Version: 1.0
X-Received: by 10.229.179.23 with SMTP id bo23mr2703283qcb.104.1359691062108;  Thu, 31 Jan 2013 19:57:42 -0800 (PST)
Received: by 10.49.48.12 with HTTP; Thu, 31 Jan 2013 19:57:41 -0800 (PST)
In-Reply-To: <510A46F3.5090407@globis.net>
References:  <02ac01cdfdac$0b5a1e30$220e5a90$@cisco.com>  <5107DD67.1000502@gmail.com>  <51094345.4030503@globis.net>  <510A46F3.5090407@globis.net>
Date: Fri, 1 Feb 2013 11:57:41 +0800
Message-ID: 
Subject: Re: 4rd IID range & IPv6 addressing architecture
From: GangChen 
To: Ray Hunter 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Bob Hinden , 6man 6man-wg 
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, 01 Feb 2013 03:57:44 -0000

Hello Ray,

2013/1/31, Ray Hunter :
>> GangChen 
>> 31 January 2013 08:53
>> 2013/1/30, Ray Hunter :
>>> inline.
>>>
>>> Ole Troan wrote:
>>>> Brian,
>>>>
>>>>>>>> - If agreed on the principle, and if no one else volunteers, I can
>>>>>>>> be
>>>>>>>> available to propose a draft to this effect.
>>>>>>> Seems reasonable.
>>>>>>>
>>>>>>>
>>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set
>>>>>>>> of
>>>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space for fut=
ure
>>>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>>>> some space to 4rd.
>>>>>> I still think we need to answer the question Brian raised.
>>>>>> should the interface-id have any encoded meaning?
>>>>> That will not be done overnight. I've been thinking about it and
>>>>> have some ideas about how to write a discussion draft, but it is
>>>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>>>> in doing as R=E9mi suggested?
>>>> it depends on what the expected meaning of a reservation is.
>>>> should all implementations treat the reserved part of the interface-id
>>>> as
>>>> martian,
>>>> and prohibit a user from configuring it for another purpose than 4rd?
>>>>
>>>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism
>>>> can
>>>> use, and the operator
>>>> deploying it will make sure there are no conflicts?
>>> my 2 cents.
>>>
>>> If 4rd is truly experimental then indeed I think it's up to the
>>> operators deploying it to ensure they choose a unique IID range within
>>> the scope of where they are operating 4rd (between tunnel endpoints and
>>> the tunnel gateway). My initial concerns were that this could cause har=
m
>>> even in experimental form, but I've convinced myself that it shouldn't.
>>> In this case I see no need for a hard global IID reservation, because a=
t
>>> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with SLAA=
C.
>>
>> Just some comments from operational views. I guess it's true operators
>> could avoid confliction with u=3D1 g=3D1 in near future. However, I
>> believe that is relative short-term guarantee with the condition of a
>> particular operational domain. The term of "experimental" is not
>> really mean "experimental" to a commercial network. It would be safe
>> for operations if there is legitimate registry to ensure there is no
>> need to renumbering. Therefore I prefer Remi's proposal (e) to grant
>> 4rd 0x0300.
>>
>> Best Regards
>>
>> Gang
>>
>
> I disagree.
>
> See http://www.ietf.org/iesg/informational-vs-experimental.html
>
> IMVHO "Experimental" means everything could change: including a need for
> mass renumbering or equipment replacement.
>
> Publication is "Subject only to editorial considerations and to
> verification that there has been adequate coordination with the
> standards process." No guarantees. The test I am currently applying when
> reviewing this ID is whether the experiment is likely to cause harm.

Understood your objection.

If "Experimental" was claimed to not be "No guarantees" due to
"Subject only to editorial considerations and to verification that
there has been adequate coordination with the standards process."

I would say 4rd seems a different story.

It was proposed as "standard track".  The label of "experimental" was
made because Softwire group needs to determine the way moving on among
competing solutions, not technical limitation to a commerical network.

It's regretful to not allow 4rd with the ability since the
"experimental" is underqualified to reservation.

> I see no compelling reason at this time to define a global reservation
> or an explicit IID structure in order for the experiment to be able to
> proceed and succeed.

May I understand the "no compelling reason" means V bits
recommendation fits into "Experimental" status?

> On the other hand, adding a reservation and
> structure to the IID at this time would likely impact other
> implementations (e.g. packet classifiers) and existing documents and IDs
> (e.g. address selection).

I have a different view. If there is no prompt reservation, it may
likely have such impact.

Best Regards

Gang

> If you want 4rd to be "informational" or "standards track" I also think
> that's worth discussing, but then I also think there's a lot more to
> specify and discuss beyond the current ID.
>
>>> On the other hand, If 4rd is not truly experimental, or it's expected t=
o
>>> work universally across AS boundaries, I suspect the WG will have to
>>> wait for an answer to Brian's question on whether structure within the
>>> IID is desirable. I don't think there's any clear consensus so far on
>>> that point (indeed there are some counter posts saying structure within
>>> the IID is undesirable).
>>>
>>> My own particular concern here is that there is a danger of creating a
>>> precedent of a completely new class of IPv6 addressing by the back door
>>> without this being fully and properly debated i.e. address ranges that
>>> don't perform DAD, and that are associated directly with a certain
>>> tunnel or transport protocol, and yet which are assigned within the
>>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>>> spaces too.
>>>
>>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
>>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>>
>>> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
>>> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
>>> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
>>> map to transport protocols, not individual IID bits)?
>>>
>>> These questions probably have little relevance to 4rd being deployed in
>>> an experimental situation, and I think we should perhaps try to keep
>>> them decoupled as far as possible.
>>>
>>>> one of my concerns is that continuing to add the interface-id bits, is
>>>> the
>>>> opposite direction of where
>>>> I want us to go.
>>>>
>>>> I wouldn't object to non-normative language in 4rd suggesting a
>>>> interface-id to use, without
>>>> creating any expectation that new or existing IPv6 implementations hav=
e
>>>> to
>>>> change.
>>>>
>>>> that said, 4rd will work perfectly well _without_ this reservation, so
>>>> I
>>>> don't buy the argument that
>>>> we're holding up the 4rd work.
>>>>
>>>> cheers,
>>>> Ole
>>>>
>>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>> Ray Hunter 
>> 30 January 2013 16:59
>> inline.
>>
>> Ole Troan wrote:
>>> Brian,
>>>
>>>>>>> - If agreed on the principle, and if no one else volunteers, I can
>>>>>>> be
>>>>>>> available to propose a draft to this effect.
>>>>>> Seems reasonable.
>>>>>>
>>>>>>
>>>>>>> (e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set o=
f
>>>>>>> IIDs having u=3D1 is reserved. This leaves plenty of space for futu=
re
>>>>>>> uses of IIDs having u=3D as explicitly expected in RFC 4291.
>>>>>> That goes to the argument of (d), that it isn't harmful to assign
>>>>>> some space to 4rd.
>>>>> I still think we need to answer the question Brian raised.
>>>>> should the interface-id have any encoded meaning?
>>>> That will not be done overnight. I've been thinking about it and
>>>> have some ideas about how to write a discussion draft, but it is
>>>> unfortuante to make the 4rd work queue behind us. Is there any risk
>>>> in doing as R=E9mi suggested?
>>> it depends on what the expected meaning of a reservation is.
>>> should all implementations treat the reserved part of the interface-id =
as
>>> martian,
>>> and prohibit a user from configuring it for another purpose than 4rd?
>>>
>>> or is it just a 'suggestion' for interface-id's that the 4rd mechanism
>>> can use, and the operator
>>> deploying it will make sure there are no conflicts?
>> my 2 cents.
>>
>> If 4rd is truly experimental then indeed I think it's up to the
>> operators deploying it to ensure they choose a unique IID range within
>> the scope of where they are operating 4rd (between tunnel endpoints and
>> the tunnel gateway). My initial concerns were that this could cause harm
>> even in experimental form, but I've convinced myself that it shouldn't.
>> In this case I see no need for a hard global IID reservation, because at
>> the moment, u=3D1 g=3D1 isn't used for creating IID's for use with SLAAC=
.
>>
>> On the other hand, If 4rd is not truly experimental, or it's expected to
>> work universally across AS boundaries, I suspect the WG will have to
>> wait for an answer to Brian's question on whether structure within the
>> IID is desirable. I don't think there's any clear consensus so far on
>> that point (indeed there are some counter posts saying structure within
>> the IID is undesirable).
>>
>> My own particular concern here is that there is a danger of creating a
>> precedent of a completely new class of IPv6 addressing by the back door
>> without this being fully and properly debated i.e. address ranges that
>> don't perform DAD, and that are associated directly with a certain
>> tunnel or transport protocol, and yet which are assigned within the
>> generic GUA space, but perhaps which overlap with other IPv6 prefix
>> spaces too.
>>
>> e.g. 1 What in draft-ietf-softwire-4rd-04 prevents tunnel space used by
>> 6to4 (2002::/16) being associated with 4rd IIDs?
>>
>> e.g. 2 How would this new class of IID encoded ranges/tunnel/transport
>> protocols interact with RFC6724 and draft-ietf-6man-addr-select-opt-08
>> (both of which assume that bit-contiguous left-anchored IPv6 prefixes
>> map to transport protocols, not individual IID bits)?
>>
>> These questions probably have little relevance to 4rd being deployed in
>> an experimental situation, and I think we should perhaps try to keep
>> them decoupled as far as possible.
>>
>>> one of my concerns is that continuing to add the interface-id bits, is
>>> the opposite direction of where
>>> I want us to go.
>>>
>>> I wouldn't object to non-normative language in 4rd suggesting a
>>> interface-id to use, without
>>> creating any expectation that new or existing IPv6 implementations have
>>> to change.
>>>
>>> that said, 4rd will work perfectly well _without_ this reservation, so =
I
>>> don't buy the argument that
>>> we're holding up the 4rd work.
>>>
>>> cheers,
>>> Ole
>>>
>>>
>>
>> ------------------------------------------------------------------------
>
>