From iesg-secretary@ietf.org Wed Feb 1 07:09:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C4711E80EE; Wed, 1 Feb 2012 07:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6BB1iEZeZVV; Wed, 1 Feb 2012 07:09:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF5D11E80BE; Wed, 1 Feb 2012 07:09:11 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2012 07:09:11 -0800 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 15:09:12 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Considerations for Transitioning Content to IPv6' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-15. 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 describes considerations for the transition of end user content on the Internet to IPv6. While this is tailored to address end user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/ No IPR declarations have been submitted directly on this I-D. From brian.e.carpenter@gmail.com Wed Feb 1 12:32:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EB821F8666 for ; Wed, 1 Feb 2012 12:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.123 X-Spam-Level: X-Spam-Status: No, score=-103.123 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiieBUk1SRVr for ; Wed, 1 Feb 2012 12:32:37 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA7521F864D for ; Wed, 1 Feb 2012 12:32:37 -0800 (PST) Received: by iagf6 with SMTP id f6so2448530iag.31 for ; Wed, 01 Feb 2012 12:32:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tGxVjWAR3Ytlca210TrPXiz3FGdQJ66+5JUQtcaWVFs=; b=pQNSnYPr+20ZWuj5AOt1euhlTm7MZMRvxO/afqf1De9jaoB7iFm5/RKdgwM7fJmpc4 9OIlSCZVov1weTogzRungwJ4Ay7fxUN+6JRUye4tSghEhObG5eLhCl6XIX77LL7Oifbd QSzI4uhXGwiZ5CDXTKbIX5tTKCD35buk2zzsI= Received: by 10.42.131.136 with SMTP id z8mr171475ics.5.1328128356919; Wed, 01 Feb 2012 12:32:36 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id ut1sm145704igc.2.2012.02.01.12.32.33 (version=SSLv3 cipher=OTHER); Wed, 01 Feb 2012 12:32:35 -0800 (PST) Message-ID: <4F29A15F.7090202@gmail.com> Date: Thu, 02 Feb 2012 09:32:31 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <4F0B975E.60604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 20:32:38 -0000 > I'm still on the fence about the draft status - I'm no longer opposed to adopting it as a WG item if that's the general consensus, but I think it would be ok as an individual draft as well. May I ask the WG chairs to put that question to the WG? We can of course make an update with the various comments received recently, either as a WG draft or for individual submission, as long as we get guidance by the end of this month. Also do people want to use meeting time for this topic, or can we handle it on the list? Regards Brian Carpenter On 2012-01-12 03:53, George, Wes wrote: > Brian - Thanks for addressing my comments in this version. > > I'm still on the fence about the draft status - I'm no longer opposed to adopting it as a WG item if that's the general consensus, but I think it would be ok as an individual draft as well. > > A couple of additional comments from this read. > > In your introduction, You mention the "first do no harm" concept - don't make IPv4 worse by deploying IPv6 (with the implication that some IPv6 transition technologies might have that effect). > I think you might be able to take that a step further and note that IPv4 *extension* technologies (CGN, etc) on the client side may also have that effect, meaning that this is one of the reasons why ubiquitous IPv6 support (perhaps "on by default" even) is critical for ASP/ICP - it increases the chances that their service transits to an end customer largely unmolested by IPv4 extension technologies. > > Additionally, it might be worth mentioning the connection between the ICP/ASP and their partners and their partner's uplinks - that is, if an ASP/ICP has a direct business relationship with the consumers/clients of their content or the networks that connect them to their clients, they should be working with those partners to ensure that they have a plan to enable IPv6 on their side (especially in implementations that require IPv6 support in specialized programs or systems for the IPv6 support on the ICP/ASP to be useful), and that they have first-class IPv6 connectivity between the networks. This coordination and testing detail is something that's sometimes overlooked, and while it's getting to a point where it might be a safe assumption that IPv6 is already available on the remote side, at this point it's worth mentioning explicitly. > > Thanks, > > Wes George > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of Brian E Carpenter >> Sent: Monday, January 09, 2012 8:42 PM >> To: IPv6 Operations >> Subject: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance- >> 02.txt] >> >> Hi, >> >> We've updated this according to the comments received since Taipei. >> >> At this point we'd like opinions about the future of the document. >> Should it become a WG draft, or should we progress it as an >> individual submission? >> >> Brian >> >> -------- Original Message -------- >> Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-02.txt >> Date: Fri, 06 Jan 2012 11:37:09 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : IPv6 Guidance for Internet Content and >> Application Service Providers >> Author(s) : Brian Carpenter >> Sheng Jiang >> Filename : draft-carpenter-v6ops-icp-guidance-02.txt >> Pages : 16 >> Date : 2012-01-06 >> >> This document provides guidance and suggestions for Internet Content >> Providers and Application Service Providers who wish to offer their >> service to both IPv6 and IPv4 customers. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance- >> 02.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance- >> 02.txt >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > From fgont@si6networks.com Wed Feb 1 16:45:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF62B21F8718 for ; Wed, 1 Feb 2012 16:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdt+6EZoh1R6 for ; Wed, 1 Feb 2012 16:45:01 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id DF88121F8715 for ; Wed, 1 Feb 2012 16:45:00 -0800 (PST) Received: from [190.48.223.230] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RsknK-0007J4-Sb; Thu, 02 Feb 2012 01:44:59 +0100 Message-ID: <4F29DC6D.5010601@si6networks.com> Date: Wed, 01 Feb 2012 21:44:29 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: IPv6 Operations X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] RA-Guard: Advice on the implementation (feedback requested) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 00:45:02 -0000 Folks, We have just published a revision of our I-D "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)" . In essence, this is the problem statement, and what this I-D is about: * RA-Guard is essential to have feature parity with IPv4. * Most (all?) existing RA-Guard implementations can be trivially evaded: if the attacker includes extension headers in his packets, the RA-Guard devices fail to identify the Router Advertisement messages. -- For instance, THC's "IPv6 attack suite" () contains tools that can evade RA-Guard as indicated. * The I-D discusses this problem, and provides advice on how to implement RA-Guard, such that the aforementioned vulnerabilities are eliminated, we have an effective RA-Guard device, and hence feature-parity with IPv4. We'd like feedback on this I-D, including high-level comments on whether you support the proposal in this I-D. 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 Wed Feb 1 17:40:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F9911E814E; Wed, 1 Feb 2012 17:40:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuwAHxuWOchJ; Wed, 1 Feb 2012 17:40:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7DB11E80B0; Wed, 1 Feb 2012 17:40:13 -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 X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120202014013.7595.76024.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2012 17:40:13 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-wireline-incremental-ipv6-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 01:40:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Wireline Incremental IPv6 Author(s) : Victor Kuarsingh Lee Howard Filename : draft-ietf-v6ops-wireline-incremental-ipv6-01.txt Pages : 25 Date : 2012-02-01 Operators worldwide are in various stages of preparing for, or deploying IPv6 into their networks. The operators often face difficult challenges related to both IPv6 introduction along with those related to IPv4 run out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a depleting supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6 focused environment with long period of dual stack operation varying by operator. This document helps provide a framework for Wireline providers who are faced with the challenges of introducing IPv6 along meeting the legacy needs of IPv4 connectivity utilizing well defined and commercially available IPv6 transition technologies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-wireline-incremental-i= pv6-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-wireline-incremental-ip= v6-01.txt From victor.kuarsingh@gmail.com Wed Feb 1 17:52:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F4111E8087 for ; Wed, 1 Feb 2012 17:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phf0RZfp41pq for ; Wed, 1 Feb 2012 17:52:45 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8A111E80A2 for ; Wed, 1 Feb 2012 17:52:44 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2551368obb.31 for ; Wed, 01 Feb 2012 17:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=G8+bP0V/XXGPSy+y/LLZ01GhFc+xi4XHquiRRlDNLmY=; b=iwLtMNbcohLZtNliWh8lAtfC0iSkMewc+IPAtzlv4rQ//wnxAPz4S8bZQWFoO5WQeH V5wUnPJNqRXX8+fMW1frxmOwXNrxKLsSg0KXZvAO+UW2GXHMGABRkRcmIxbhqrvd9EGa 4b2n0OgCbBWw2PtbI0jkCwZdzRRykaXRbJVKw= Received: by 10.50.217.129 with SMTP id oy1mr1451000igc.4.1328147563889; Wed, 01 Feb 2012 17:52:43 -0800 (PST) Received: from [192.168.100.89] ([67.224.83.162]) by mx.google.com with ESMTPS id z22sm1687461ibg.5.2012.02.01.17.52.41 (version=SSLv3 cipher=OTHER); Wed, 01 Feb 2012 17:52:43 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 01 Feb 2012 20:52:38 -0500 From: Victor Kuarsingh To: Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-wireline-incremental-ipv6-01.txt In-Reply-To: <20120202014013.7595.76024.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "Howard, Lee" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-wireline-incremental-ipv6-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 01:52:46 -0000 V6OPS WG, An update has been posted which rolled up comments made to date. This version reflects the following: - Focus on IPv6 enablement and deployment progression - Tone around IPv4 has been muted somewhat in that it's noted, but again - focus on IPv6 - Less focus on text around "IPv6 code immaturity" as it did not sit well with many - focus here is on operational experience in IPv6 and lack of maturity in operation networks Points still in debate and/or require more discussion - Test describing and including technologies outside of Dual Stack, DS-Lite and 6RD. Some have noted that inclusion of NAT46 (with relation to NAT64) should be included. Example would be draft-mawatari-v6ops-464xlat-00. - Regarding the above, we had originally intended to only include a set of technologies which have commercial availability. Would discussion of the above be worth describing in document? (as actual text and/or just minor reference?) I will be looking for comments which support (or challenge) updates on the recent -01 post, and the matter of including NAT46/NAT464 (as referenced above). Future update will include more information in the considerations portion of the document as I have much input from folks who have deployment experience information for some areas. Regards, Victor K On 12-02-01 8:40 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 Operations Working >Group of the IETF. > > Title : Wireline Incremental IPv6 > Author(s) : Victor Kuarsingh > Lee Howard > Filename : draft-ietf-v6ops-wireline-incremental-ipv6-01.txt > Pages : 25 > Date : 2012-02-01 > > Operators worldwide are in various stages of preparing for, or > deploying IPv6 into their networks. The operators often face > difficult challenges related to both IPv6 introduction along with > those related to IPv4 run out. Operators will need to meet the > simultaneous needs of IPv6 connectivity and continue support for IPv4 > connectivity for legacy devices with a depleting supply of IPv4 > addresses. The IPv6 transition will take most networks from an IPv4- > only environment to an IPv6 focused environment with long period of > dual stack operation varying by operator. This document helps > provide a framework for Wireline providers who are faced with the > challenges of introducing IPv6 along meeting the legacy needs of IPv4 > connectivity utilizing well defined and commercially available IPv6 > transition technologies. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-wireline-incremental- >ipv6-01.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-wireline-incremental-i >pv6-01.txt > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From Tina.Tsou.Zouting@huawei.com Wed Feb 1 19:01:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128D521F88EE for ; Wed, 1 Feb 2012 19:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VK8pnIqB8b6 for ; Wed, 1 Feb 2012 19:01:38 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4350B21F88ED for ; Wed, 1 Feb 2012 19:01:38 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYQ008XHWEO8T@szxga04-in.huawei.com> for v6ops@ietf.org; Thu, 02 Feb 2012 11:01:36 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYQ00CTDWDWFD@szxga04-in.huawei.com> for v6ops@ietf.org; Thu, 02 Feb 2012 11:01:36 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGT14817; Thu, 02 Feb 2012 11:01:36 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 02 Feb 2012 11:01:04 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 02 Feb 2012 11:01:15 +0800 Date: Thu, 02 Feb 2012 03:01:14 +0000 From: Tina TSOU In-reply-to: <4F29DC6D.5010601@si6networks.com> To: Fernando Gont Message-id: <2D5B11C6-4AB1-4908-B635-3E5DEF927CA3@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [v6ops] RA-Guard: Advice on the implementation (feedback requested) Thread-index: AQHM4UPu0cBfLMNEOUiY6BKRlcoQNpYo61Kt X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F29DC6D.5010601@si6networks.com> Cc: IPv6 Operations Subject: Re: [v6ops] RA-Guard: Advice on the implementation (feedback requested) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 03:01:39 -0000 It is useful for my current deployment. I like this document in general, will discuss more details with Fernando. Sent from my iPhone On Feb 1, 2012, at 4:45 PM, "Fernando Gont" wrote: > Folks, > > We have just published a revision of our I-D "Implementation Advice for > IPv6 Router Advertisement Guard (RA-Guard)" > . > > In essence, this is the problem statement, and what this I-D is about: > > * RA-Guard is essential to have feature parity with IPv4. > > * Most (all?) existing RA-Guard implementations can be trivially evaded: > if the attacker includes extension headers in his packets, the RA-Guard > devices fail to identify the Router Advertisement messages. -- For > instance, THC's "IPv6 attack suite" () > contains tools that can evade RA-Guard as indicated. > > * The I-D discusses this problem, and provides advice on how to > implement RA-Guard, such that the aforementioned vulnerabilities are > eliminated, we have an effective RA-Guard device, and hence > feature-parity with IPv4. > > We'd like feedback on this I-D, including high-level comments on whether > you support the proposal in this I-D. > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ek@google.com Thu Feb 2 19:04:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2725C11E8072 for ; Thu, 2 Feb 2012 19:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beMfybg9jG2E for ; Thu, 2 Feb 2012 19:04:09 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE95311E8071 for ; Thu, 2 Feb 2012 19:04:08 -0800 (PST) Received: by obbwd15 with SMTP id wd15so4435585obb.31 for ; Thu, 02 Feb 2012 19:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type:content-transfer-encoding; bh=0asXAR0YJ9bNbQ7IYFFtRqiP3MiXdCmmQNZAbeXhRp0=; b=f2zluPHpfYblmRcgNJPkXJCJeBgwERaKHAzW+72SLtg5lWXi2OGf6bs0Kudl79uz77 hsaPlmHPXBUcl1HKx8Z5OpPopDNAzX0lTRyGK9VQxZywQ5I1RTUZtOfiCAYr8M7mp1K0 DcohRfcvD80NpbmQjwFk2io1+rDQRRqK3jFUg= Received: by 10.182.75.65 with SMTP id a1mr4949922obw.32.1328237845535; Thu, 02 Feb 2012 18:57:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.75.65 with SMTP id a1mr4949861obw.32.1328237844017; Thu, 02 Feb 2012 18:57:24 -0800 (PST) Received: by 10.182.97.4 with HTTP; Thu, 2 Feb 2012 18:57:23 -0800 (PST) In-Reply-To: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> Date: Fri, 3 Feb 2012 11:57:23 +0900 Message-ID: From: Erik Kline To: ietf@ietf.org X-System-Of-Record: true Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, IETF-Announce Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 03:04:09 -0000 World IPv6 Launch changes the relevance of this document greatly, I think. Since this would be published after the announcement of World IPv6 Launch, I think the document should be updated to discuss its own applicability in a post- World IPv6 Launch Internet. On 2 February 2012 00:09, The IESG wrote: > > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'Considerations for Transitioning Content to IPv6' > =C2=A0 as an > Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-15. 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 > > > =C2=A0 This document describes considerations for the transition of end u= ser > =C2=A0 content on the Internet to IPv6. =C2=A0While this is tailored to a= ddress > =C2=A0 end user content, which is typically web-based, many aspects of th= is > =C2=A0 document may be more broadly applicable to the transition to IPv6 = of > =C2=A0 other applications and services. =C2=A0This document explores the > =C2=A0 challenges involved in the transition to IPv6, potential migration > =C2=A0 tactics, possible migration phases, and other considerations. =C2= =A0The > =C2=A0 audience for this document is the Internet community generally, > =C2=A0 particularly IPv6 implementers. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-imp= lications/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-imp= lications/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Tina.Tsou.Zouting@huawei.com Thu Feb 2 20:56:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9302D21F85E7; Thu, 2 Feb 2012 20:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.432 X-Spam-Level: X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=-1.974, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MANGLED_PERFRM=2.3, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH8-K8LhqR8g; Thu, 2 Feb 2012 20:56:35 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1033021F85DD; Thu, 2 Feb 2012 20:56:35 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYS00ATOWE83A@szxga03-in.huawei.com>; Fri, 03 Feb 2012 12:56:32 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYS00GGTWDY3U@szxga03-in.huawei.com>; Fri, 03 Feb 2012 12:56:32 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGU28948; Fri, 03 Feb 2012 12:56:31 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 03 Feb 2012 12:55:59 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 03 Feb 2012 12:56:09 +0800 Date: Fri, 03 Feb 2012 04:56:08 +0000 From: Tina TSOU In-reply-to: To: Erik Kline Message-id: <7AA10427-E0B6-4441-A59D-54D51084948C@huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FjKF2JMaMHLx6rDWEfWHxg)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-index: AQHM4iCuCXHujMgG4UGZ2dpnBHAge5YqnAg2 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> Cc: "v6ops@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 04:56:36 -0000 --Boundary_(ID_FjKF2JMaMHLx6rDWEfWHxg) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable I think that although the draft mainly discusses aaaa-whitelisting, it can = be more specific in section 2 on issues impacting content delivery over ipv= 6. Perhaps the biggest challenge in the IPv4-to-IPv6 transition is that the tw= o protocols are not compatible; that is, IPv4-only systems cannot talk dire= ctly to IPv6-only systems. This means no one can turn off IPv4 support unti= l every last device they want to reach has acquired IPv6 connectivity. Unfo= rtunately, many existing devices =97 including PCs running older OSes, as w= ell as older cable and DSL modems, wireless routers, and other business and= consumer electronic devices=97have either limited or no IPv6 support. In o= ther words, companies will have to support both protocols for years to come= , in a long and bumpy transition period. During that time, there will effec= tively be two Internets, an IPv4 one and an IPv6 one, loosely bound togethe= r into a hybrid Internet by various transition technologies. Challenges of reaching IPv6 users from IPv4 sites Many types of Web applications rely on an end-to-end connection, where each= device, household, or entity is associated with a single IP address. CGN b= reaks this assumption =97 as it creates a situa=ADtion where hundreds or th= ousands of end users =97 related only by their network provider =97 share t= he same IP address, and each user=92s IP address may change with every new = connection. Thus, CGN cripples functions like geo-location =97 using the us= er=92s IP address to determine their location, in order to personalize cont= ent or to enforce licensing restrictions, for example, and abuse mitiga=ADt= ion =97 IP blacklisting or whitelisting, in order to block spammers, trolls= , or other abusive users. CGN breaks assumptions that many of today=92s Web applications rely on. I= n particular it affects applications, such as peer-to-peer and VoIP, which = rely in some way on a unique end user IP address. Troubleshooting the issue= s is extremely complex and costly, as it can=92t be done without the NAT op= erator=92s help. In order to reach IPv4 sites, IPv6 end users need to go through a NAT64 gat= eway. Because there may be only one or two such gateways within a network, = communications may be forced through long, indirect paths. In addition, the= se gateways quickly become congestion points within the network, as well as= easily targeted points of failure, further affecting the perfor=ADmance an= d reliability. Challenges of reaching IPv6 users from IPv6 sites Because the IPv6 Internet is still sparsely connected, native IPv6 communic= ations may require longer, less direct routes than their IPv4 counterparts,= resulting in slower performance and higher packet loss. This is particular= ly troublesome for high throughput or low latency applications such as onli= ne gaming or streaming media. In addition, a significant portion of the IPv= 6 Internet currently relies on tunneling traffic over IPv4, creating additi= onal performance degradation. So I think that content providers and application providers are no longer p= ondering when to enable delivery over IPv6 but are focused on how to manag= e this transition in a manner that is cost-effective and efficient in the s= hort term but takes into account long-term needs and opportunities. Sent from my iPad On Feb 2, 2012, at 7:05 PM, "Erik Kline" > wrote: World IPv6 Launch changes the relevance of this document greatly, I think. Since this would be published after the announcement of World IPv6 Launch, I think the document should be updated to discuss its own applicability in a post- World IPv6 Launch Internet. On 2 February 2012 00:09, The IESG > wrote: The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Considerations for Transitioning Content to IPv6' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-15. Exceptiona= lly, 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 describes considerations for the transition of end user content on the Internet to IPv6. While this is tailored to address end user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impli= cations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impli= cations/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --Boundary_(ID_FjKF2JMaMHLx6rDWEfWHxg) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable

I think that although the draft mainly discusses aaaa-whitelisting, it can = be more specific in section 2 on issues impacting content delivery over ipv= 6.

 

Perhaps the biggest challenge in the IPv4-to-IPv6 transi= tion is that the two protocols are not compatible; that is, IPv4-only syste= ms cannot talk directly to IPv6-only systems. This means no one can turn of= f IPv4 support until every last device they want to reach has acquired IPv6 connectivity. Unfortunately, many exi= sting devices =97 including PCs running older OSes, as well as older cable = and DSL modems, wireless routers, and other business and consumer electroni= c devices=97have either limited or no IPv6 support. In other words, companies will have to support both protocol= s for years to come, in a long and bumpy transition period. During that tim= e, there will effectively be two Internets, an IPv4 one and an IPv6 one, lo= osely bound together into a hybrid Internet by various transition technologies.

 

Challenges of reaching IPv6 users from IPv4 sites

Many types of Web applications rely on an end-to-end con= nection, where each device, household, or entity is associated with a singl= e IP address. CGN breaks this assumption =97 as it creates a situa=ADtion w= here hundreds or thousands of end users =97 related only by their network provider =97 share the same IP address, = and each user=92s IP address may change with every new connection. Thus, CG= N cripples functions like geo-location =97 using the user=92s IP address to= determine their location, in order to personalize content or to enforce licensing restrictions, for example, and abuse mitig= a=ADtion =97 IP blacklisting or whitelisting, in order to block spammers, t= rolls, or other abusive users.

CGN   breaks assumptions that many of today=92= s Web applications rely on. In particular it affects applications, such as = peer-to-peer and VoIP, which rely in some way on a unique end user IP addre= ss. Troubleshooting the issues is extremely complex and costly, as it can=92t be done without the NAT operator=92s help.<= /o:p>

In order to reach IPv4 sites, IPv6 end users need to go = through a NAT64 gateway. Because there may be only one or two such gateways= within a network, communications may be forced through long, indirect path= s. In addition, these gateways quickly become congestion points within the network, as well as easily targeted po= ints of failure, further affecting the perfor=ADmance and reliability.=

 

Challenges of reaching IPv6 users from IPv6 sites

Because the IPv6 Internet is still sparsely connected, n= ative IPv6 communications may require longer, less direct routes than their= IPv4 counterparts, resulting in slower performance and higher packet loss.= This is particularly troublesome for high throughput or low latency applications such as online gaming or s= treaming media. In addition, a significant portion of the IPv6 Internet cur= rently relies on tunneling traffic over IPv4, creating additional performan= ce degradation.

 

So I think that content providers and applic= ation providers are no longer pondering when to enable delivery over  = IPv6 but are focused on how to manage this transition in a manner that is c= ost-effective and efficient in the short term but takes into account long-term needs and opportunities.


Sent from my iPad

On Feb 2, 2012, at 7:05 PM, "Erik Kline" <ek@google.com> wrote:

World IPv6 Launch changes the relevance of this document greatly= , I
think.  Since this would be published after the announcement of = World
IPv6 Launch, I think the document should be updated to discuss its ow= n
applicability in a post- World IPv6 Launch Internet.

On 2 February 2012 00:09, The IESG <iesg-secretary@ietf.org> wrote:

The IESG has received a request from the IP= v6 Operations WG (v6ops) to
consider the following document:
- 'Considerations for Transitioning Content= to IPv6'
 <draft-ietf-v6ops-v6-aaaa-whitelis= ting-implications-08.txt> as an
Informational RFC

The IESG plans to make a decision in the ne= xt few weeks, and solicits
final comments on this action. Please send = substantive comments to the
ietf@ietf.= org mailing lists by 2012-02-15. Exceptionally, comments may be<= br>
sent to ie= sg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow auto= mated sorting.

Abstract


  This document describes consideratio= ns for the transition of end user
  content on the Internet to IPv6. &nb= sp;While this is tailored to address
  end user content, which is typically= web-based, many aspects of this
  document may be more broadly applica= ble to the transition to IPv6 of
  other applications and services. &nb= sp;This document explores the
  challenges involved in the transitio= n to IPv6, potential migration
  tactics, possible migration phases, = and other considerations.  The
  audience for this document is the In= ternet community generally,
  particularly IPv6 implementers.




The file can be obtained via
http://datatracker.iet= f.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/

IESG discussion can be tracked via
http://datatracker.iet= f.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/


No IPR declarations have been submitted dir= ectly on this I-D.


___________________________________________= ____
v6ops mailing list
v6ops@iet= f.org
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops
--Boundary_(ID_FjKF2JMaMHLx6rDWEfWHxg)-- From fred@cisco.com Fri Feb 3 08:35:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C1E21F84FB; Fri, 3 Feb 2012 08:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.17 X-Spam-Level: X-Spam-Status: No, score=-106.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rh3awGi3VWgg; Fri, 3 Feb 2012 08:35:38 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4991221F84D0; Fri, 3 Feb 2012 08:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3592; q=dns/txt; s=iport; t=1328286938; x=1329496538; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=bDbztDUlH0glbqhDJXDUInHLDg+k4cnC6nQNfbYXdyA=; b=ZtrQg40h2qdpcAADaW75Q53aK6hxbw21KpUTa5fXBaYx9+GAhG+2UvNy vxs8Hjx1Mi50g9sY0Q1P4gEQtabYis1zCbiEVYTGkeQ3Qp90xV19Slo4r wzVCkhQ7xjzQW8o58kYxA0TAqJPOusH9M+sdP7k1fIqDJDFfBiM2zXGd1 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAG8MLE+rRDoI/2dsb2JhbABDrx6BBYFyAQEBAwEBAQEPASc0CwULCw4KIwsnMAYTFA6HWgmZXwGeeYtWBwICCQUMBhMBCAUDAwkNgw8FGAILAgVjBRAbBIJWYwSIRIxjhViNIg X-IronPort-AV: E=Sophos;i="4.73,352,1325462400"; d="scan'208";a="28623756" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 03 Feb 2012 16:35:37 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q13GWoga003616; Fri, 3 Feb 2012 16:35:36 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Fri, 03 Feb 2012 08:35:36 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Fri, 03 Feb 2012 08:35:36 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Fri, 3 Feb 2012 08:35:36 -0800 Message-Id: <8EA035DE-DAB9-4920-9BD6-75944848CA5D@cisco.com> References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> To: Erik Kline X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG , IETF Discussion Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 16:35:39 -0000 On Feb 2, 2012, at 6:57 PM, Erik Kline wrote: > World IPv6 Launch changes the relevance of this document greatly, I > think. Since this would be published after the announcement of World > IPv6 Launch, I think the document should be updated to discuss its own > applicability in a post- World IPv6 Launch Internet. With respect... The document was originally discussed in v6ops, and you chose to not = comment. It went through last call there in January 2011 and was sent to = the IESG. IESG review took until April, and an updated draft was posted = at the end of May 2011. At IETF 81 (Quebec City) we were able to have = you, the author, and some others discuss it. The IESG again decided it = needed a revised draft, and that draft - in large part, a rewrite - = arrived in October. v6ops had a second WGLC, in which you again declined = to comment, although you may have seen Lorenzo's comments, which were = picked up in a November version of the draft. Ralph and Jari finally = cleared their "discuss" ballots a couple of weeks ago, and we are having = a second IETF last call. I'd like to understand your objective here. I know that you don't care = for the draft, and at least at one point took it as a somewhat-personal = attack. Is your objective to prevent the draft's publication entirely, = or do you think that there is value in publishing it given a productive = response to this comment? At what point are you willing to either = participate in the public dialog or choose to not comment at all? > On 2 February 2012 00:09, The IESG wrote: >>=20 >> The IESG has received a request from the IPv6 Operations WG (v6ops) = to >> consider the following document: >> - 'Considerations for Transitioning Content to IPv6' >> as an >> Informational RFC >>=20 >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to = the >> ietf@ietf.org mailing lists by 2012-02-15. 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. >>=20 >> Abstract >>=20 >>=20 >> This document describes considerations for the transition of end = user >> content on the Internet to IPv6. While this is tailored to address >> end user content, which is typically web-based, many aspects of = this >> document may be more broadly applicable to the transition to IPv6 = of >> other applications and services. This document explores the >> challenges involved in the transition to IPv6, potential migration >> tactics, possible migration phases, and other considerations. The >> audience for this document is the Internet community generally, >> particularly IPv6 implementers. >>=20 >>=20 >>=20 >>=20 >> The file can be obtained via >> = http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impl= ications/ >>=20 >> IESG discussion can be tracked via >> = http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impl= ications/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From cb.list6@gmail.com Fri Feb 3 12:17:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0573A11E8074 for ; Fri, 3 Feb 2012 12:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.715 X-Spam-Level: X-Spam-Status: No, score=-2.715 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGAeya5k2isl for ; Fri, 3 Feb 2012 12:17:08 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52B8F11E8071 for ; Fri, 3 Feb 2012 12:17:08 -0800 (PST) Received: by dakl33 with SMTP id l33so3616752dak.31 for ; Fri, 03 Feb 2012 12:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=85CYPn+qJcKPvc7uH+TLYqtS9mzVnKjxzNayAVLoUAY=; b=fA4tapDgZc4JOJj/vTb2URIZUx52j542t/cND6VZ/B+KQHLEX2znJ8X345JnHd06ZZ 7dHkksc6TZ7KhW8tzBzbDfVKmSWwlw8V3HNzcTdDwWh0MXpbG1GEGRTb03StplN0gwDb mbMXS9mU7GoTbC7c44Sr8rF9iaumAD8e+sDX4= MIME-Version: 1.0 Received: by 10.68.216.4 with SMTP id om4mr20281313pbc.19.1328300228114; Fri, 03 Feb 2012 12:17:08 -0800 (PST) Received: by 10.143.78.7 with HTTP; Fri, 3 Feb 2012 12:17:08 -0800 (PST) Date: Fri, 3 Feb 2012 12:17:08 -0800 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 20:17:09 -0000 Hi, I have recently concluded a simple initial experimental deployment 464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android Nexus S phone. The high level summary is that a sample of the top ~200 free Android apps that use network services (ie not a calculator with no ads), ~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a stock Android 4.0 (ICS) on a stock Nexus S phone. When using custom 464XLAT code [3] on Android, 100% of the ~15% of apps that failed in the initial test now work. The 464XLAT CLAT code on the Android allowed for IPv4 socket bindings and IPv4 referrals to proceed on the IPv6-only network by doing RFC 6145 protocol translation locally on the phone. The tested application sample set is at [4]. I believe this simple experiment running real code on a real network shows the value of draft-mawatari-v6ops-464xlat for enabling network operators to embrace IPv6-only networks as the going forward future of access networks. 464XLAT, like NAT64/DNS64, is a bridge technology that makes IPv6 deployment feasible without harming the customer experience. 464XLAT, like DNS64/NAT64, is not used when apps and service are IPv6 native. Thus, as IPv6 deployment progresses across the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of service. I hope the problem statement that draft-mawatari-v6ops-464xlat addresses is clear as it applies to this trial: 15% of applications for this sample in the Android market require IPv4 addresses. And, i hope the proposed applicability and usefulness of 464XLAT is clear as it applies to this trial: 464XLAT allows for 100% functionality of all applications in the sample and is only used when IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...). I do have 2 requests of the group. First, please read and comment on draft-mawatari-v6ops-464xlat [1]. We are looking for working group adoption of this draft since we believe it will broadly support the ability of network operators to move forward with IPv6 in the near term (code is running, network is deployed). Right now, some networks feel they are held back by "IPv6 spoilers" like Skype that require IPv4. But now, even Skype works on IPv6 with the help of 464XLAT :) . I would like to emphasize that Skype and others MUST still deploy and support IPv6. That said, we cannot let their failure hold the rest of us back. Second, the IPv4 exhaustion problem is real and now, the urgency must be high. Please also comment to the folks at Android that this code should be brought into the Android main line distribution because network operators (v6ops) need it to continue growing the Internet and restoring the end-to-end principle [5]. Thanks, Cameron ps. Big thanks to Dan Drown for open-sourcing his CLAT code! [1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat [2] http://goo.gl/HGmsy or https://sites.google.com/site/tmoipv6/lg-mytouch [3] http://code.google.com/p/android-clat/ and http://dan.drown.org/android/clat/ and [4] http://goo.gl/z3j3q or https://docs.google.com/spreadsheet/ccc?key=0AnVbRg3DotzFdGVwZWlWeG5wXzVMcG5qczZEZloxWGc [5] http://goo.gl/W55YQ or http ://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select-devices-here-is-what-it-all-means-and-yes-no-more-nat/ From fred@cisco.com Fri Feb 3 12:40:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7227A11E8071 for ; Fri, 3 Feb 2012 12:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmxRaXvX1+GP for ; Fri, 3 Feb 2012 12:40:51 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E815221F860D for ; Fri, 3 Feb 2012 12:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5411; q=dns/txt; s=iport; t=1328301629; x=1329511229; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=fpLBdySsJizoLwX7799a1d8yJNsvbjdm9Z8RBmVsteI=; b=NXTmLav1p4NmQ1RjCEzCCWiuEutz5UHEHYWkNjEYYOb0JqBOutThpb71 OKuhG/uulf1bY3fg+EPkdIe2YHe8ogM+4WvkRiQKkG+CrvMbrKcTWpmG5 2814S7/2qIzLoJQOclE5lnUiJdrcGcUL1RrYrWS702HH2GQviMZZxTMc+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMNFLE+rRDoG/2dsb2JhbABDryiBBYFyAQEBAwEBAQEPASc0EAscAwECLyEGJgIIBhMih1oJmXwBmmiEAogPg0ADBAcCAgkFDAYTAQgFAwMJDYMPBRgCCwIFYwUQgnVjBIhEjGOFWIUxAwGHbQ X-IronPort-AV: E=Sophos;i="4.73,353,1325462400"; d="scan'208";a="28666239" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 03 Feb 2012 20:40:29 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q13KeS5V009139 for ; Fri, 3 Feb 2012 20:40:29 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Fri, 03 Feb 2012 12:40:29 -0800 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Fri, 03 Feb 2012 12:40:29 -0800 From: Fred Baker Date: Fri, 3 Feb 2012 12:40:16 -0800 References: To: v6ops v6ops WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fwd: 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 20:40:52 -0000 So - I have a question for the working group. We have a draft and a = deployment report on http://datatracker.ietf.org/doc/draft-mawatari-v6ops-464xlat http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat "464XLAT: Combination of Stateful and Stateless Translation", Masataka Mawatari, Masanobu Kawashima, Cameron Byrne, 15-Jan-12 indicating that it is useful in a live network. It is, an rfcdiff will = tell you, a rework of draft-mawatari-softwire-464xlat. The technique has = similarities and differences from the concepts in the various dIVI = drafts and http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-cpe http://tools.ietf.org/html/draft-chen-v6ops-nat64-cpe "NAT64 Operational Considerations", Gang Chen, 31-Oct-11 http://datatracker.ietf.org/doc/draft-sunq-v6ops-contents-transition http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition "Rapid Transition of IPv4 contents to be IPv6-accessible", Qiong Sun, Chongfeng Xie, Qian Liu, Xing Li, Jacni Qin, Dong Liu, Qin Zhao, 29-Oct-11 The authors argue that this is about operational experience with a = protocol translation technology defined in behave, and that it has = current deployment. I need to know what the working group, and especially the operators in = it, wants to do with this. Do you want to adopt it as a working group = draft? Do you want to discuss it but leave it individual? Do you think = it belongs in another working group, and if so which? Do you have = another opinion? > From: Cameron Byrne > Date: February 3, 2012 12:17:08 PM PST > To: IPv6 Ops WG > Subject: [v6ops] 464XLAT Trial Deployment Report >=20 > Hi, >=20 > I have recently concluded a simple initial experimental deployment > 464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android > Nexus S phone. >=20 > The high level summary is that a sample of the top ~200 free Android > apps that use network services (ie not a calculator with no ads), > ~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a > stock Android 4.0 (ICS) on a stock Nexus S phone. >=20 > When using custom 464XLAT code [3] on Android, 100% of the ~15% of > apps that failed in the initial test now work. The 464XLAT CLAT code > on the Android allowed for IPv4 socket bindings and IPv4 referrals to > proceed on the IPv6-only network by doing RFC 6145 protocol > translation locally on the phone. The tested application sample set > is at [4]. >=20 > I believe this simple experiment running real code on a real network > shows the value of draft-mawatari-v6ops-464xlat for enabling network > operators to embrace IPv6-only networks as the going forward future of > access networks. 464XLAT, like NAT64/DNS64, is a bridge technology > that makes IPv6 deployment feasible without harming the customer > experience. 464XLAT, like DNS64/NAT64, is not used when apps and > service are IPv6 native. Thus, as IPv6 deployment progresses across > the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of > service. >=20 > I hope the problem statement that draft-mawatari-v6ops-464xlat > addresses is clear as it applies to this trial: 15% of applications > for this sample in the Android market require IPv4 addresses. >=20 > And, i hope the proposed applicability and usefulness of 464XLAT is > clear as it applies to this trial: 464XLAT allows for 100% > functionality of all applications in the sample and is only used when > IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...). >=20 > I do have 2 requests of the group. First, please read and comment on > draft-mawatari-v6ops-464xlat [1]. We are looking for working group > adoption of this draft since we believe it will broadly support the > ability of network operators to move forward with IPv6 in the near > term (code is running, network is deployed). Right now, some networks > feel they are held back by "IPv6 spoilers" like Skype that require > IPv4. But now, even Skype works on IPv6 with the help of 464XLAT :) . > I would like to emphasize that Skype and others MUST still deploy and > support IPv6. That said, we cannot let their failure hold the rest of > us back. Second, the IPv4 exhaustion problem is real and now, the > urgency must be high. Please also comment to the folks at Android > that this code should be brought into the Android main line > distribution because network operators (v6ops) need it to continue > growing the Internet and restoring the end-to-end principle [5]. >=20 > Thanks, >=20 > Cameron >=20 > ps. Big thanks to Dan Drown for open-sourcing his CLAT code! >=20 >=20 > [1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat >=20 > [2] http://goo.gl/HGmsy or = https://sites.google.com/site/tmoipv6/lg-mytouch >=20 > [3] http://code.google.com/p/android-clat/ and > http://dan.drown.org/android/clat/ and >=20 > [4] http://goo.gl/z3j3q or > = https://docs.google.com/spreadsheet/ccc?key=3D0AnVbRg3DotzFdGVwZWlWeG5wXzV= McG5qczZEZloxWGc >=20 > [5] http://goo.gl/W55YQ or http > = ://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select-de= vices-here-is-what-it-all-means-and-yes-no-more-nat/ > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jeroen@unfix.org Fri Feb 3 12:49:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2131F21F85F4 for ; Fri, 3 Feb 2012 12:49:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYsK0SXyL5iw for ; Fri, 3 Feb 2012 12:49:36 -0800 (PST) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 7648921F860D for ; Fri, 3 Feb 2012 12:49:36 -0800 (PST) Received: from yomi.ch.unfix.org (117-1.5-85.cust.bluewin.ch [85.5.1.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 8831C801BCC3; Fri, 3 Feb 2012 21:49:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1328302173; bh=E9gGnu7PaLWREGh8FgQl9uAzpX+97h8yDR4IqxqQVuQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HUOjvOgXyVDdnFIdbcm8ZV7kBgGL9A7JQv5mD5hPLz8PzaPuFclHWwgbNm6eAIFcv w2dLu2P3b1Yo4lZzRfF9TZ0Alc/v4YWjm/OiSSrSolKe6hU3OeIPyeLQDkqN5wnzWk CqVJOKPyv8nXU3Hr3trlogkh1MFX1kkORgT+buIhFmJ6q+zFh1dhByOF89eEL9kh+W YZM4qYFl3ofE2Vy+2NNY6qQwohsebiz0prPKWbjbEyUBvFb1no10bqqOyVX61n4uwO HnrbdsrQoOPhuGgZMlGI/dGYFGrQ9aTZ59VJJuTOxk5lkg6qtsphKkucsDsYdUnlwi g7GXEm7o2SmoQ== Message-ID: <4F2C4854.40701@unfix.org> Date: Fri, 03 Feb 2012 21:49:24 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Fred Baker References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops v6ops WG Subject: Re: [v6ops] Fwd: 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 20:49:37 -0000 On 2012-02-03 21:40 , Fred Baker wrote: [..] > I need to know what the working group, and especially the operators > in it, wants to do with this. Do you want to adopt it as a working > group draft? Do you want to discuss it but leave it individual? Do > you think it belongs in another working group, and if so which? Do > you have another opinion? I very much appreciate the folks writing these operational reports. I do not think they fit in the RFC process, though they are great for discussing pro's and con's about a certain solution. IMHO They are much better fit for the various conferences out there. Greets, Jeroen From sarikaya2012@gmail.com Fri Feb 3 12:58:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E8021F84F8 for ; Fri, 3 Feb 2012 12:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IIC5zvQRsc1 for ; Fri, 3 Feb 2012 12:58:56 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5366421F84CE for ; Fri, 3 Feb 2012 12:58:56 -0800 (PST) Received: by yenm3 with SMTP id m3so2074242yen.31 for ; Fri, 03 Feb 2012 12:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=U5b0AdlNkGYTPCXCgaI9FWpm2CZ2LBJvsMoAZ/CI43g=; b=HSpWoKfuyU2YbJOLZXBRX1jnH0C58pzxHdP/20rtDWggo1srwKPzevmrmqn0RyXdY2 7YeFBC5RXUHHEiSwyio2eMWMAqFGnvuJzepNNFndZz5uo2OUWcY3n1olZbB9CqW4p9yJ ORYCYGZ/JasBVDGFzEnJIattFMgq2IXQOuTt8= MIME-Version: 1.0 Received: by 10.236.131.38 with SMTP id l26mr14060992yhi.70.1328302735021; Fri, 03 Feb 2012 12:58:55 -0800 (PST) Received: by 10.236.108.165 with HTTP; Fri, 3 Feb 2012 12:58:54 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Feb 2012 14:58:54 -0600 Message-ID: From: Behcet Sarikaya To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 20:58:57 -0000 Hi Cameron, As you know, many UEs can not connect to an UMTS network on IPv6 due to the firmware problem. How did this affect your experiments? Cheers, Behcet On Fri, Feb 3, 2012 at 2:17 PM, Cameron Byrne wrote: > Hi, > > I have recently concluded a simple initial experimental deployment > 464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android > Nexus S phone. > > The high level summary is that a sample of the top ~200 free Android > apps that use network services (ie not a calculator with no ads), > ~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a > stock Android 4.0 (ICS) on a stock Nexus S phone. > > When using custom 464XLAT code [3] on Android, 100% of =A0the ~15% of > apps that failed in the initial test now work. The 464XLAT CLAT code > on the Android allowed for IPv4 socket bindings and IPv4 referrals to > proceed on the IPv6-only network by doing RFC 6145 protocol > translation locally on the phone. =A0The tested application sample set > is at [4]. > > I believe this simple experiment running real code on a real network > shows the value of draft-mawatari-v6ops-464xlat for enabling network > operators to embrace IPv6-only networks as the going forward future of > access networks. 464XLAT, like NAT64/DNS64, is a bridge technology > that makes IPv6 deployment feasible without harming the customer > experience. =A0464XLAT, like DNS64/NAT64, is not used when apps and > service are IPv6 native. =A0Thus, as IPv6 deployment progresses across > the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of > service. > > I hope the problem statement that draft-mawatari-v6ops-464xlat > addresses is clear as it applies to this trial: 15% of applications > for this sample in the Android market require IPv4 addresses. > > And, i hope the proposed applicability and usefulness of 464XLAT is > clear as it applies to this trial: =A0464XLAT allows for 100% > functionality of all applications in the sample and is only used when > IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...). > > I do have 2 requests of =A0the group. =A0First, please read and comment o= n > draft-mawatari-v6ops-464xlat [1]. =A0We are looking for working group > adoption of this draft since we believe it will broadly support the > ability of network operators to move forward with IPv6 in the near > term (code is running, network is deployed). =A0Right now, some networks > feel they are held back by "IPv6 spoilers" like Skype that require > IPv4. =A0But now, even Skype works on IPv6 with the help of 464XLAT :) . > =A0I would like to emphasize that Skype and others MUST still deploy and > support IPv6. =A0That said, we cannot let their failure hold the rest of > us back. =A0Second, the IPv4 exhaustion problem is real and now, the > urgency must be high. =A0Please also comment to the folks at Android > that this code should be brought into the Android main line > distribution because network operators (v6ops) need it to continue > growing the Internet and restoring the end-to-end principle [5]. > > Thanks, > > Cameron > > ps. =A0Big thanks to Dan Drown for open-sourcing his CLAT code! > > > [1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat > > [2] http://goo.gl/HGmsy or https://sites.google.com/site/tmoipv6/lg-mytou= ch > > [3] =A0http://code.google.com/p/android-clat/ and > http://dan.drown.org/android/clat/ =A0and > > [4] http://goo.gl/z3j3q =A0or > https://docs.google.com/spreadsheet/ccc?key=3D0AnVbRg3DotzFdGVwZWlWeG5wXz= VMcG5qczZEZloxWGc > > [5] =A0http://goo.gl/W55YQ or http > ://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select-d= evices-here-is-what-it-all-means-and-yes-no-more-nat/ > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Fri Feb 3 13:04:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF2621F8528 for ; Fri, 3 Feb 2012 13:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl3he7zj66tE for ; Fri, 3 Feb 2012 13:04:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D2B4521F8517 for ; Fri, 3 Feb 2012 13:04:12 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RtQIj-000GLh-1T; Fri, 03 Feb 2012 21:04:09 +0000 Date: Sat, 04 Feb 2012 06:04:07 +0900 Message-ID: From: Randy Bush To: Jeroen Massar In-Reply-To: <4F2C4854.40701@unfix.org> References: <4F2C4854.40701@unfix.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: v6ops v6ops WG Subject: Re: [v6ops] Fwd: 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 21:04:28 -0000 > I very much appreciate the folks writing these operational reports. > > I do not think they fit in the RFC process, though they are great for > discussing pro's and con's about a certain solution. IMHO They are > much better fit for the various conferences out there. excuse! for many kinds of protocols, i-ds/rfcs of operability and interoperability are a required part of the ietf process. randy From jeroen@unfix.org Fri Feb 3 13:21:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CD921F85E6 for ; Fri, 3 Feb 2012 13:21:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd5mlFHz7nPa for ; Fri, 3 Feb 2012 13:21:46 -0800 (PST) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF4E21F858B for ; Fri, 3 Feb 2012 13:21:39 -0800 (PST) Received: from yomi.ch.unfix.org (117-1.5-85.cust.bluewin.ch [85.5.1.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 1CA33801BCC3; Fri, 3 Feb 2012 22:21:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1328304096; bh=xh4wthrSkrYJSWWsn9bvpMGg5S5QDQ353+bP9/djahU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qPw20ZwxFKLW92KE0rUDrxyMgrA9k/EdHS+ADCnHYKFkg/V3BNpAkFpqz3xd6V0y9 ADA7givoKqu9HJxPVk/LGj3mKnnt2sd0JrZBpfuokdYiku2zbMh8NtcQHGhQEKZZFw V+Bbr9ri/5Fc4cgFqNIe2NoTxGp4FyRrfIJ+TlJ9c9FZag7NVvMDifetVwUsLV+AUp jkagZ2uD+evii0E1VY7uoCGmbwBbVCaDRO/fZ4nLBWOM6hwrhT+NgPhf3k9zZR8fom s41zvfCXBEFDV4Ca13f9jD8cG5lEOr7GFJJ7zJ9EVyFruulqiyh8RoINDjuXrevZTd mlPMHI52ohrzQ== Message-ID: <4F2C4FD1.1030901@unfix.org> Date: Fri, 03 Feb 2012 22:21:21 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Randy Bush References: <4F2C4854.40701@unfix.org> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops v6ops WG Subject: Re: [v6ops] Fwd: 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 21:21:46 -0000 On 2012-02-03 22:04 , Randy Bush wrote: >> I very much appreciate the folks writing these operational reports. >> >> I do not think they fit in the RFC process, though they are great for >> discussing pro's and con's about a certain solution. IMHO They are >> much better fit for the various conferences out there. > > excuse! for many kinds of protocols, i-ds/rfcs of operability and > interoperability are a required part of the ietf process. If reports are indeed solely published in IETF-form then that is a good way, if they though are published through other means then those can serve already as stable references. Thus either/or IMHO. Greets, Jeroen From jhw@apple.com Fri Feb 3 13:30:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C43C21F8618 for ; Fri, 3 Feb 2012 13:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.454 X-Spam-Level: X-Spam-Status: No, score=-109.454 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6da7p-ngxcI5 for ; Fri, 3 Feb 2012 13:30:57 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id BC69921F8617 for ; Fri, 3 Feb 2012 13:30:57 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_bhyrh5p+ngWa8DHJZNmARQ)" Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0LYU00IRL6EWF8M1@mail-out.apple.com> for v6ops@ietf.org; Fri, 03 Feb 2012 13:30:57 -0800 (PST) X-AuditID: 11807137-b7b87ae000004a2b-53-4f2c5210aea7 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 00.09.18987.0125C2F4; Fri, 03 Feb 2012 13:30:56 -0800 (PST) From: james woodyatt Date: Fri, 03 Feb 2012 13:30:56 -0800 In-reply-to: To: IPv6 Ops WG References: Message-id: <33E9F5E8-FE9C-4863-B4B7-AD7CB50F598E@apple.com> X-Mailer: Apple Mail (2.1257) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUieJDXQVcgSMff4NMDS4vTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEro+vhJ8aCD3oVZx5/Ym9gvKjRxcjJISFgIrHsxUsmCFtM4sK9 9WxdjFwcQgKzmSQm9b5nA0mwCahIfLt8F6yIV8BQYuardlYQm1kgQWLXze3MILYw0KBHu7aA 1bMA1a87uhCohoODUyBQYnc/2C4RAQWJHf93go0REgiQmHfxLDNICa+AjcSkB8IQJ8hK3D64 n2kCI+8sJMtmIVkGYWtLLFv4GsjmALJ1JCYvZEQVhrA/nj/CtICRbRWjYFFqTmKloZleYkFB Tqpecn7uJkZQ0DUUmu9g3P5X7hCjAAejEg8vo5aOvxBrYllxZe4hRgkOZiURXit1oBBvSmJl VWpRfnxRaU5q8SFGaQ4WJXHebdbK/kIC6YklqdmpqQWpRTBZJg5OqQbGLYKta+4cFzm1Y2eD 7rIb25apq5RU6VWa1ac+U56yYuru+lPG5bF3N5WauZ5SaPf4OTXv8r5s1u6k9pUPGD4eut6R uTsjN7bEwO6JgDU/X6fdI90nLxZX8jxs3PHzyKzTWcoTmx1WBfgWZp6TO7p7e0lr/z+uvZ0X Umo0DRk0y8w4wphytsgosRRnJBpqMRcVJwIAmYCIBjYCAAA= Subject: Re: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 21:30:58 -0000 --Boundary_(ID_bhyrh5p+ngWa8DHJZNmARQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Feb 3, 2012, at 12:17 , Cameron Byrne wrote: > Right now, some networks feel they are held back by "IPv6 spoilers" like Skype that require IPv4. [...] Who knew networks could be so touchy-feely and civilized? Me, I'm more of a barbarian. "Conan, what is best in life?" "To break obsolete IPv4-only applications, to see the revenues of their developers crushed, and to hear the lamentations of their abandoned users." "Ah, yes... that is best." But no, I don't think this should be a working group draft. It might be worthy of publication by the individual track, but it would be a waste of valuable WG agenda slots. > Please also comment to the folks at Android that this code should be brought into the Android main line distribution Yes. Please please please add 464XLAT to the Android main line distribution. I will shout with joy if they do that. -- james woodyatt member of technical staff, core os networking --Boundary_(ID_bhyrh5p+ngWa8DHJZNmARQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable  Right now, some = networks feel they are held back by "IPv6 spoilers" like Skype that = require IPv4. [...]

Who knew networks could be so touchy-feely and = civilized?  Me, I'm more of a barbarian.

"Conan, what is best in = life?"
"To break = obsolete IPv4-only applications, to see the revenues of their developers = crushed, and to hear the lamentations of their abandoned = users."
"Ah, = yes... that is best."

But no, I don't = think this should be a working group draft.  It might be worthy of = publication by the individual track, but it would be a waste of valuable = WG agenda = slots.

Please also comment to the folks at Android that = this code should be brought into the Android main = line distribution

Yes. =  Please please please add 464XLAT to the Android main line = distribution.  I will shout with joy if they do = that.

--
james woodyatt <jhw@apple.com>
member of technical staff, core os = networking



= --Boundary_(ID_bhyrh5p+ngWa8DHJZNmARQ)-- From cb.list6@gmail.com Fri Feb 3 13:53:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF8D1F0C36 for ; Fri, 3 Feb 2012 13:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycqDKJK9VFII for ; Fri, 3 Feb 2012 13:53:03 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABCEB1F0C3C for ; Fri, 3 Feb 2012 13:53:03 -0800 (PST) Received: by dakl33 with SMTP id l33so3680103dak.31 for ; Fri, 03 Feb 2012 13:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z6EaL3/A00fSxoMqbU0fLrOHygWCgvMvGBug531vmUE=; b=Y6xvhlQqC42CUqRixPNcRm79gN8j/HE1aUpJUjmQnLQQg8l87p5nZNq/EqqtLhgLHQ wIRc93Ky1CBLS286YlYvePNSZ5O5+zDvNdvVMbGSEzQGscb1CNlh2iDmjFbqYVQyIcid tCzwPUKzwgHPCPuMPNS+kQAbia7JJEr7FMxwo= MIME-Version: 1.0 Received: by 10.68.222.103 with SMTP id ql7mr21274262pbc.53.1328305983449; Fri, 03 Feb 2012 13:53:03 -0800 (PST) Received: by 10.143.78.7 with HTTP; Fri, 3 Feb 2012 13:53:03 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Feb 2012 13:53:03 -0800 Message-ID: From: Cameron Byrne To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=047d7b2ed4314be89c04b8165637 Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 21:53:04 -0000 --047d7b2ed4314be89c04b8165637 Content-Type: text/plain; charset=ISO-8859-1 On Feb 3, 2012 12:58 PM, "Behcet Sarikaya" gmail.com > wrote: > > Hi Cameron, > > As you know, many UEs can not connect to an UMTS network on IPv6 due > to the firmware problem. > Absolutely > How did this affect your experiments? > The goal was to test the ability of 464XLAT architecture to enable 100% functionality of Android applications on an IPv6-only network That goal was achieved on the Nexus S hardware, which is 1 of the 4 phones that are capable of doing IPv6 on the T-Mobile USA UMTS network. We believe the pipeline of IPv6 phones is improving, we continue to push the OEMs to support IPv6. We are happy that the Nexus S has been enabled with IPv6 since the Nexus line of phones are the official baseline developer phones for Android, and so we are hopeful that the code can be pushed upstream without much modification. CB --047d7b2ed4314be89c04b8165637 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 3, 2012 12:58 PM, "Behcet Sarikaya" <sarikaya2012@gmail.com> wrote:
>
> Hi Cameron,
>
> As you know, many UEs can not connect to an UMTS network on IPv6 due > to the firmware problem.
>

Absolutely

> How did this affect your experiments?
>

The goal was to test the ability of 464XLAT architecture to enable 100% = functionality of Android applications on an IPv6-only network

That goal was achieved on the Nexus S hardware, which is 1 of the 4 phon= es that are capable of doing IPv6 on the T-Mobile USA UMTS network. =A0We b= elieve the pipeline of IPv6 phones is improving, we continue to push the OE= Ms to support IPv6.

We are happy that the Nexus S has been enabled with IPv6 since the Nexus= line of phones are the official baseline developer phones for Android, and= so we are hopeful that the code can be pushed upstream without much modifi= cation.


CB

--047d7b2ed4314be89c04b8165637-- From sarikaya2012@gmail.com Fri Feb 3 14:37:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05A721F85AF for ; Fri, 3 Feb 2012 14:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqBzU51iXvrB for ; Fri, 3 Feb 2012 14:37:31 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFC5B21F859E for ; Fri, 3 Feb 2012 14:37:30 -0800 (PST) Received: by ghbg16 with SMTP id g16so2242086ghb.31 for ; Fri, 03 Feb 2012 14:37:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=e4RquKjLgO7XQr2h7DwF567dou5B+bMoUkMeAPWdSZk=; b=fV4WlZxgU8MCx/plJZv4D5Nc/8+dRrc/p/MTZxZ2cRx+Zgzrli/fD7ZErHcvOz7DEB nNAk/2GgXXQZs0F+AVwH4lQKRcbB6+LnmAzdgT6atIc319mVyZ5UHXGioOmwjZIcm1Wn a2uJvrN3i4vxX03bs+IWPTGO+WcD+5r7IfThs= MIME-Version: 1.0 Received: by 10.236.184.226 with SMTP id s62mr14018972yhm.104.1328308650424; Fri, 03 Feb 2012 14:37:30 -0800 (PST) Received: by 10.236.108.165 with HTTP; Fri, 3 Feb 2012 14:37:30 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Feb 2012 16:37:30 -0600 Message-ID: From: Behcet Sarikaya To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] Fwd: 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 22:37:32 -0000 Hi Fred, I have technical concerns: - RFC 6146 does use DNS64 as an integral component. In this draft DNS64 is not used however RFC 6146 is referenced. I think that this point should be clarified instead of just giving a reference to 6146. - As you will remember, in 3GPP-IETF workshop in 2010, pnat proposal was discussed in depth. I think 464XLAT is very much like pnat. The workshop did not endorse such approaches because of UE modification requirement. Instead, dual stack network was endorsed. - Since Release 8, 3GPP has adopted v4v6 or dual stack PDP Context which is not mentioned in the draft. I do like the principle of IPv6-only network instead of the old fashioned dual stack network, if only we could resolve the technical issues :-). I also like the observation that Skype should be IPv6 friendly. Regards, Behcet On Fri, Feb 3, 2012 at 2:40 PM, Fred Baker wrote: > So - I have a question for the working group. We have a draft and a deplo= yment report on > > http://datatracker.ietf.org/doc/draft-mawatari-v6ops-464xlat > http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat > =A0"464XLAT: Combination of Stateful and Stateless Translation", Masataka > =A0Mawatari, Masanobu Kawashima, Cameron Byrne, 15-Jan-12 > > indicating that it is useful in a live network. It is, an rfcdiff will te= ll you, a rework of draft-mawatari-softwire-464xlat. The technique has simi= larities and differences from the concepts in the various dIVI drafts and > > http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-cpe > http://tools.ietf.org/html/draft-chen-v6ops-nat64-cpe > =A0"NAT64 Operational Considerations", Gang Chen, 31-Oct-11 > > http://datatracker.ietf.org/doc/draft-sunq-v6ops-contents-transition > http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition > =A0"Rapid Transition of IPv4 contents to be IPv6-accessible", Qiong Sun, > =A0Chongfeng Xie, Qian Liu, Xing Li, Jacni Qin, Dong Liu, Qin Zhao, > =A029-Oct-11 > > The authors argue that this is about operational experience with a protoc= ol translation technology defined in behave, and that it has current deploy= ment. > > I need to know what the working group, and especially the operators in it= , wants to do with this. Do you want to adopt it as a working group draft? = Do you want to discuss it but leave it individual? Do you think it belongs = in another working group, and if so which? Do you have another opinion? > > >> From: Cameron Byrne >> Date: February 3, 2012 12:17:08 PM PST >> To: IPv6 Ops WG >> Subject: [v6ops] 464XLAT Trial Deployment Report >> >> Hi, >> >> I have recently concluded a simple initial experimental deployment >> 464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android >> Nexus S phone. >> >> The high level summary is that a sample of the top ~200 free Android >> apps that use network services (ie not a calculator with no ads), >> ~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a >> stock Android 4.0 (ICS) on a stock Nexus S phone. >> >> When using custom 464XLAT code [3] on Android, 100% of =A0the ~15% of >> apps that failed in the initial test now work. The 464XLAT CLAT code >> on the Android allowed for IPv4 socket bindings and IPv4 referrals to >> proceed on the IPv6-only network by doing RFC 6145 protocol >> translation locally on the phone. =A0The tested application sample set >> is at [4]. >> >> I believe this simple experiment running real code on a real network >> shows the value of draft-mawatari-v6ops-464xlat for enabling network >> operators to embrace IPv6-only networks as the going forward future of >> access networks. 464XLAT, like NAT64/DNS64, is a bridge technology >> that makes IPv6 deployment feasible without harming the customer >> experience. =A0464XLAT, like DNS64/NAT64, is not used when apps and >> service are IPv6 native. =A0Thus, as IPv6 deployment progresses across >> the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of >> service. >> >> I hope the problem statement that draft-mawatari-v6ops-464xlat >> addresses is clear as it applies to this trial: 15% of applications >> for this sample in the Android market require IPv4 addresses. >> >> And, i hope the proposed applicability and usefulness of 464XLAT is >> clear as it applies to this trial: =A0464XLAT allows for 100% >> functionality of all applications in the sample and is only used when >> IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...). >> >> I do have 2 requests of =A0the group. =A0First, please read and comment = on >> draft-mawatari-v6ops-464xlat [1]. =A0We are looking for working group >> adoption of this draft since we believe it will broadly support the >> ability of network operators to move forward with IPv6 in the near >> term (code is running, network is deployed). =A0Right now, some networks >> feel they are held back by "IPv6 spoilers" like Skype that require >> IPv4. =A0But now, even Skype works on IPv6 with the help of 464XLAT :) . >> I would like to emphasize that Skype and others MUST still deploy and >> support IPv6. =A0That said, we cannot let their failure hold the rest of >> us back. =A0Second, the IPv4 exhaustion problem is real and now, the >> urgency must be high. =A0Please also comment to the folks at Android >> that this code should be brought into the Android main line >> distribution because network operators (v6ops) need it to continue >> growing the Internet and restoring the end-to-end principle [5]. >> >> Thanks, >> >> Cameron >> >> ps. =A0Big thanks to Dan Drown for open-sourcing his CLAT code! >> >> >> [1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat >> >> [2] http://goo.gl/HGmsy or https://sites.google.com/site/tmoipv6/lg-myto= uch >> >> [3] =A0http://code.google.com/p/android-clat/ and >> http://dan.drown.org/android/clat/ =A0and >> >> [4] http://goo.gl/z3j3q =A0or >> https://docs.google.com/spreadsheet/ccc?key=3D0AnVbRg3DotzFdGVwZWlWeG5wX= zVMcG5qczZEZloxWGc >> >> [5] =A0http://goo.gl/W55YQ or http >> ://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select-= devices-here-is-what-it-all-means-and-yes-no-more-nat/ >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Fri Feb 3 14:55:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664F811E8088 for ; Fri, 3 Feb 2012 14:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvJ8w2I5CUeB for ; Fri, 3 Feb 2012 14:55:00 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5347021F8620 for ; Fri, 3 Feb 2012 14:55:00 -0800 (PST) Received: by dakl33 with SMTP id l33so3717059dak.31 for ; Fri, 03 Feb 2012 14:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3ow9JGLol/zX6zrOc3QbrbuXFGf9cmgO02HmDLICALA=; b=nNkF4xEAovuVQb5a+QugsI0VHnRzUHgTvjXKtEo/adZMlDitYslaWCbl0vF7FOjruy CFu0WGqMENcwV3ujqhJQ2A/dIXrkF5r03gQMSmkoe+5jtNj26bH2F5ouQiaWfq1VGdM4 UhgrqrpvWi9iJRFLSvknFuyVhKKprApBdVqPw= MIME-Version: 1.0 Received: by 10.68.225.73 with SMTP id ri9mr21180708pbc.70.1328309699576; Fri, 03 Feb 2012 14:54:59 -0800 (PST) Received: by 10.143.78.7 with HTTP; Fri, 3 Feb 2012 14:54:59 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Feb 2012 14:54:59 -0800 Message-ID: From: Cameron Byrne To: sarikaya@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] Fwd: 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 22:55:01 -0000 On Fri, Feb 3, 2012 at 2:37 PM, Behcet Sarikaya wr= ote: > Hi Fred, > > I have technical concerns: > > - RFC 6146 does use DNS64 as an integral component. In this draft > DNS64 is not used however RFC 6146 is referenced. I think that this > point should be clarified instead of just giving a reference to 6146. > RFC6146 is stateful NAT64. It does not require DNS64. They are completely decoupled. RFC6146 can function fine without DNS64. draft-mawatari-v6ops-464xlat can also function fine without DNS64, in my particular implementation i choose to use DNS64 since it reduces a layer of translation in most of *my* cases. > - As you will remember, in 3GPP-IETF workshop in 2010, pnat proposal > was discussed in depth. I think 464XLAT is very much like pnat. The > workshop did not endorse such approaches because of UE modification > requirement. Instead, dual stack network was endorsed. > PNAT, AFAIK, had an on-host DNS64 ENR function and specified ALGs. It was overall a bit more complicated, and eventually that work evolved into the BIH work that has been approved as an RFC. PNAT was also standards track work, as where this draft is informational. From my perspective, the BIH work does not solve my stated problem scope since it is only scoped for IPv4 applications communicating with IPv6-only servers. > - Since Release 8, 3GPP has adopted v4v6 or dual stack PDP Context > which is not mentioned in the draft. > Why would there be a mention of that? The scope here is IPv6-only access networks, not dual-stack networks. That said, there are very few Release 8+ networks deployed globally. And, dual-stack faces the challenge of provide IPv4 addresses that are no available. > I do like the principle of IPv6-only network instead of the old > fashioned dual stack network, if only we could resolve the technical > issues :-). > Good on this point ! > I also like the observation that Skype should be IPv6 friendly. > That application would go a long way helping network operators deploy IPv6 networks. CB > Regards, > > Behcet > > On Fri, Feb 3, 2012 at 2:40 PM, Fred Baker wrote: >> So - I have a question for the working group. We have a draft and a depl= oyment report on >> >> http://datatracker.ietf.org/doc/draft-mawatari-v6ops-464xlat >> http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat >> =A0"464XLAT: Combination of Stateful and Stateless Translation", Masatak= a >> =A0Mawatari, Masanobu Kawashima, Cameron Byrne, 15-Jan-12 >> >> indicating that it is useful in a live network. It is, an rfcdiff will t= ell you, a rework of draft-mawatari-softwire-464xlat. The technique has sim= ilarities and differences from the concepts in the various dIVI drafts and >> >> http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-cpe >> http://tools.ietf.org/html/draft-chen-v6ops-nat64-cpe >> =A0"NAT64 Operational Considerations", Gang Chen, 31-Oct-11 >> >> http://datatracker.ietf.org/doc/draft-sunq-v6ops-contents-transition >> http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition >> =A0"Rapid Transition of IPv4 contents to be IPv6-accessible", Qiong Sun, >> =A0Chongfeng Xie, Qian Liu, Xing Li, Jacni Qin, Dong Liu, Qin Zhao, >> =A029-Oct-11 >> >> The authors argue that this is about operational experience with a proto= col translation technology defined in behave, and that it has current deplo= yment. >> >> I need to know what the working group, and especially the operators in i= t, wants to do with this. Do you want to adopt it as a working group draft?= Do you want to discuss it but leave it individual? Do you think it belongs= in another working group, and if so which? Do you have another opinion? >> >> >>> From: Cameron Byrne >>> Date: February 3, 2012 12:17:08 PM PST >>> To: IPv6 Ops WG >>> Subject: [v6ops] 464XLAT Trial Deployment Report >>> >>> Hi, >>> >>> I have recently concluded a simple initial experimental deployment >>> 464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android >>> Nexus S phone. >>> >>> The high level summary is that a sample of the top ~200 free Android >>> apps that use network services (ie not a calculator with no ads), >>> ~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a >>> stock Android 4.0 (ICS) on a stock Nexus S phone. >>> >>> When using custom 464XLAT code [3] on Android, 100% of =A0the ~15% of >>> apps that failed in the initial test now work. The 464XLAT CLAT code >>> on the Android allowed for IPv4 socket bindings and IPv4 referrals to >>> proceed on the IPv6-only network by doing RFC 6145 protocol >>> translation locally on the phone. =A0The tested application sample set >>> is at [4]. >>> >>> I believe this simple experiment running real code on a real network >>> shows the value of draft-mawatari-v6ops-464xlat for enabling network >>> operators to embrace IPv6-only networks as the going forward future of >>> access networks. 464XLAT, like NAT64/DNS64, is a bridge technology >>> that makes IPv6 deployment feasible without harming the customer >>> experience. =A0464XLAT, like DNS64/NAT64, is not used when apps and >>> service are IPv6 native. =A0Thus, as IPv6 deployment progresses across >>> the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of >>> service. >>> >>> I hope the problem statement that draft-mawatari-v6ops-464xlat >>> addresses is clear as it applies to this trial: 15% of applications >>> for this sample in the Android market require IPv4 addresses. >>> >>> And, i hope the proposed applicability and usefulness of 464XLAT is >>> clear as it applies to this trial: =A0464XLAT allows for 100% >>> functionality of all applications in the sample and is only used when >>> IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...). >>> >>> I do have 2 requests of =A0the group. =A0First, please read and comment= on >>> draft-mawatari-v6ops-464xlat [1]. =A0We are looking for working group >>> adoption of this draft since we believe it will broadly support the >>> ability of network operators to move forward with IPv6 in the near >>> term (code is running, network is deployed). =A0Right now, some network= s >>> feel they are held back by "IPv6 spoilers" like Skype that require >>> IPv4. =A0But now, even Skype works on IPv6 with the help of 464XLAT :) = . >>> I would like to emphasize that Skype and others MUST still deploy and >>> support IPv6. =A0That said, we cannot let their failure hold the rest o= f >>> us back. =A0Second, the IPv4 exhaustion problem is real and now, the >>> urgency must be high. =A0Please also comment to the folks at Android >>> that this code should be brought into the Android main line >>> distribution because network operators (v6ops) need it to continue >>> growing the Internet and restoring the end-to-end principle [5]. >>> >>> Thanks, >>> >>> Cameron >>> >>> ps. =A0Big thanks to Dan Drown for open-sourcing his CLAT code! >>> >>> >>> [1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat >>> >>> [2] http://goo.gl/HGmsy or https://sites.google.com/site/tmoipv6/lg-myt= ouch >>> >>> [3] =A0http://code.google.com/p/android-clat/ and >>> http://dan.drown.org/android/clat/ =A0and >>> >>> [4] http://goo.gl/z3j3q =A0or >>> https://docs.google.com/spreadsheet/ccc?key=3D0AnVbRg3DotzFdGVwZWlWeG5w= XzVMcG5qczZEZloxWGc >>> >>> [5] =A0http://goo.gl/W55YQ or http >>> ://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select= -devices-here-is-what-it-all-means-and-yes-no-more-nat/ >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sarikaya2012@gmail.com Fri Feb 3 15:18:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E359B21F84B5 for ; Fri, 3 Feb 2012 15:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdpPlqQCQkKB for ; Fri, 3 Feb 2012 15:18:01 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5383721F85D8 for ; Fri, 3 Feb 2012 15:18:01 -0800 (PST) Received: by yhkk25 with SMTP id k25so2156023yhk.31 for ; Fri, 03 Feb 2012 15:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=i2D0xaJ3Ou3dNJDMnBGQ6d45acFKTLdWWGH2mUfJh7M=; b=G/Ekyf7A67K6b810H4usvqTOA9YQeSw4l25L8gZZ8IZCSiWutZPFlj6aAbgN2qb+dX Vy1OkLcSMBfQwaT3jqHUqEkv8R1BkVPSIdb7PdFaN2QwXLHXyg/G8Po1rsXdf7jW1oPn zW+26dOOJFBFUv6EaPq+AXlWdxWH4uVF49tTg= MIME-Version: 1.0 Received: by 10.236.184.226 with SMTP id s62mr14123437yhm.104.1328311080878; Fri, 03 Feb 2012 15:18:00 -0800 (PST) Received: by 10.236.108.165 with HTTP; Fri, 3 Feb 2012 15:18:00 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Feb 2012 17:18:00 -0600 Message-ID: From: Behcet Sarikaya To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] Fwd: 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 23:18:02 -0000 On Fri, Feb 3, 2012 at 4:54 PM, Cameron Byrne wrote: > On Fri, Feb 3, 2012 at 2:37 PM, Behcet Sarikaya = wrote: >> Hi Fred, >> >> I have technical concerns: >> >> - RFC 6146 does use DNS64 as an integral component. In this draft >> DNS64 is not used however RFC 6146 is referenced. I think that this >> point should be clarified instead of just giving a reference to 6146. >> > > RFC6146 is stateful NAT64. =A0It does not require DNS64. =A0They are > completely decoupled. =A0RFC6146 can function fine without DNS64. > draft-mawatari-v6ops-464xlat can also function fine without DNS64, in > my particular implementation i choose to use DNS64 since it reduces a > layer of translation in most of *my* cases. My point was to ask you to add at least one paragraph explaining how DNS64 is avoided. > >> - As you will remember, in 3GPP-IETF workshop in 2010, pnat proposal >> was discussed in depth. I think 464XLAT is very much like pnat. The >> workshop did not endorse such approaches because of UE modification >> requirement. Instead, dual stack network was endorsed. >> > > PNAT, AFAIK, had an on-host DNS64 ENR function and specified ALGs. =A0It > was overall a bit more complicated, and eventually that work evolved > into the BIH work that has been approved as an RFC. =A0 PNAT was also > standards track work, as where this draft is informational. =A0From my > perspective, the BIH work does not solve my stated problem scope since > it is only scoped for IPv4 applications communicating with IPv6-only > servers. > I know the pnat story. >> - Since Release 8, 3GPP has adopted v4v6 or dual stack PDP Context >> which is not mentioned in the draft. >> > > Why would there be a mention of that? =A0The scope here is IPv6-only > access networks, not dual-stack networks. =A0That said, there are very > few Release 8+ networks deployed globally. And, dual-stack faces the > challenge of provide IPv4 addresses that are no available. > Because in Section 3 you have this: This is especially cost-effective in wireless 3GPP network that would otherwise require two separate PDP connections to support IPv4 and IPv6. Regards, Behcet From ek@google.com Fri Feb 3 17:43:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5001A11E80E1 for ; Fri, 3 Feb 2012 17:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygK7b6xeqfVE for ; Fri, 3 Feb 2012 17:43:19 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B849411E8098 for ; Fri, 3 Feb 2012 17:43:19 -0800 (PST) Received: by qcsg13 with SMTP id g13so2783845qcs.31 for ; Fri, 03 Feb 2012 17:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type:content-transfer-encoding; bh=hok4rc7Ei+ic50sRwyzc2soLt/VSXwlK3ZNnxrXuINQ=; b=kUYMR74BiMJqqaVjRY91r4+W+bSxQACMr0x+9hnyK+s4IY2hZHXqG4PFp7vfCW1N1T ZdQO8nzzll/XDRPxBJrXWO7MvuYG6aD8nvyHayhTFLTRp8VMOK1uWJEJoPm4oSAX29w9 WFudfHMr2tl467SekWXR0pChfoftg8X5QAsCw= Received: by 10.224.177.68 with SMTP id bh4mr11680496qab.2.1328319799178; Fri, 03 Feb 2012 17:43:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.177.68 with SMTP id bh4mr11680489qab.2.1328319799080; Fri, 03 Feb 2012 17:43:19 -0800 (PST) Received: by 10.229.101.158 with HTTP; Fri, 3 Feb 2012 17:43:19 -0800 (PST) In-Reply-To: <8EA035DE-DAB9-4920-9BD6-75944848CA5D@cisco.com> References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <8EA035DE-DAB9-4920-9BD6-75944848CA5D@cisco.com> Date: Sat, 4 Feb 2012 10:43:19 +0900 Message-ID: From: Erik Kline To: Fred Baker X-System-Of-Record: true Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG , IETF Discussion Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 01:43:20 -0000 On 4 February 2012 01:35, Fred Baker wrote: > > On Feb 2, 2012, at 6:57 PM, Erik Kline wrote: > >> World IPv6 Launch changes the relevance of this document greatly, I >> think. =C2=A0Since this would be published after the announcement of Wor= ld >> IPv6 Launch, I think the document should be updated to discuss its own >> applicability in a post- World IPv6 Launch Internet. > > With respect... > > The document was originally discussed in v6ops, and you chose to not comm= ent. It went through last call there in January 2011 and was sent to the IE= SG. IESG review took until April, and an updated draft was posted at the en= d of May 2011. At IETF 81 (Quebec City) we were able to have you, the autho= r, and some others discuss it. The IESG again decided it needed a revised d= raft, and that draft - in large part, a rewrite - arrived in October. v6ops= had a second WGLC, in which you again declined to comment, although you ma= y have seen Lorenzo's comments, which were picked up in a November version = of the draft. Ralph and Jari finally cleared their "discuss" ballots a coup= le of weeks ago, and we are having a second IETF last call. > > I'd like to understand your objective here. I know that you don't care fo= r the draft, and at least at one point took it as a somewhat-personal attac= k. Is your objective to prevent the draft's publication entirely, or do you= think that there is value in publishing it given a productive response to = this comment? At what point are you willing to either participate in the pu= blic dialog or choose to not comment at all? With humblest apologies... Having spent time rereading, I think W6L is clearly an implementation of sections 4.5 and 5.7, or 4.4 and 5.6, depending on the implementer. Additionally, in retrospect, there's probably no great reason to add a reference to a future event. It seems to me that the most meaningful technical observation that can actually be offered would be its scheduled calendar date. There's no excuse for my failing to reread afresh before commenting. Again, my apologies, -Erik From internet-drafts@ietf.org Fri Feb 3 20:00:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF911F0C42; Fri, 3 Feb 2012 20:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hINMAH73MSp0; Fri, 3 Feb 2012 20:00:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0F721F8510; Fri, 3 Feb 2012 19:59:55 -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 X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120204035955.6814.7380.idtracker@ietfa.amsl.com> Date: Fri, 03 Feb 2012 19:59:55 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 04:00:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Operational Neighbor Discovery Problems Author(s) : Igor Gashinsky Joel Jaeggli Warren Kumari Filename : draft-ietf-v6ops-v6nd-problems-04.txt Pages : 13 Date : 2012-02-03 In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service, whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes the potential for DOS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can in some cases be used to protect against or at least alleviate the impact of such attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-04.txt From mawatari@jpix.ad.jp Sun Feb 5 19:01:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF9721F852E for ; Sun, 5 Feb 2012 19:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.51 X-Spam-Level: * X-Spam-Status: No, score=1.51 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkEaL3tvjDMu for ; Sun, 5 Feb 2012 19:01:25 -0800 (PST) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id AB69521F8512 for ; Sun, 5 Feb 2012 19:01:25 -0800 (PST) Received: from [10.10.31.235] (eth3-1-bb-fw-34.jpix.ad.jp [210.171.226.102]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 284EEFC021; Mon, 6 Feb 2012 12:01:17 +0900 (JST) Date: Mon, 06 Feb 2012 12:01:17 +0900 From: MAWATARI Masataka To: jhw@apple.com In-Reply-To: <33E9F5E8-FE9C-4863-B4B7-AD7CB50F598E@apple.com> References: <33E9F5E8-FE9C-4863-B4B7-AD7CB50F598E@apple.com> Message-Id: <20120206120117.0E17.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.03 [ja] Cc: v6ops@ietf.org Subject: Re: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 03:01:26 -0000 Dear James-san, I appreciate your comments. * On Fri, 03 Feb 2012 13:30:56 -0800 * james woodyatt wrote: > On Feb 3, 2012, at 12:17 , Cameron Byrne wrote: > > Right now, some networks feel they are held back by "IPv6 spoilers" like Skype that require IPv4. [...] > > Who knew networks could be so touchy-feely and civilized? Me, I'm more of a barbarian. > > "Conan, what is best in life?" > "To break obsolete IPv4-only applications, to see the revenues of their developers crushed, and to hear the lamentations of their abandoned users." > "Ah, yes... that is best." > > But no, I don't think this should be a working group draft. It might be worthy of publication by the individual track, but it would be a waste of valuable WG agenda slots. We would like to enough provide information about how to use widely implemented NAT64 feature (RFC 6146) as a PLAT other than using for NAT64/DNS64 to operators (of course, you can adopt both ways at the same time), so we hope that this 464XLAT is adopted as a working group draft. And it based on effective and reasonable IPv6 deployment and IPv4 address exhaustion issue, especially for ISPs and mobile operators that does not have much IPv4 address pool. > > Please also comment to the folks at Android that this code should be brought into the Android main line distribution > > Yes. Please please please add 464XLAT to the Android main line distribution. I will shout with joy if they do that. I also hope that 464XLAT is official implemented to android. :) Kind Regards, Masataka MAWATARI From lorenzo@google.com Sun Feb 5 23:54:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F2821F85C4 for ; Sun, 5 Feb 2012 23:54:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjGhBbgq3tGF for ; Sun, 5 Feb 2012 23:54:05 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB54C21F85C7 for ; Sun, 5 Feb 2012 23:54:05 -0800 (PST) Received: by obbwd15 with SMTP id wd15so7816579obb.31 for ; Sun, 05 Feb 2012 23:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=V0STqhowbIneyphBsDEfdWERaJ04B/DMfHYkWADjINg=; b=lmYghhfcwX4kj4k4TuAsvNkJ4jA6mi4A/c0eNK7O8kFiBFQANs/AwOXangzj2g/Tlj M51ih6J0AD0HnN/m235TQrW46YywPX+3vAkKzJ1RBopW5d9AQ/IwrI2DvTs/HHXFaXqK lfs1mEXbQWq0JxULwmqTM2LFfgucc2EMP6Jv0= Received: by 10.182.85.103 with SMTP id g7mr15807889obz.38.1328514845320; Sun, 05 Feb 2012 23:54:05 -0800 (PST) Received: by 10.182.85.103 with SMTP id g7mr15807884obz.38.1328514845227; Sun, 05 Feb 2012 23:54:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.0.11 with HTTP; Sun, 5 Feb 2012 23:53:45 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Mon, 6 Feb 2012 16:53:45 +0900 Message-ID: To: Fred Baker X-System-Of-Record: true Content-Type: multipart/alternative; boundary=f46d044789876dbbd104b846f7f3 Cc: v6ops v6ops WG Subject: Re: [v6ops] Fwd: 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 07:54:06 -0000 --f46d044789876dbbd104b846f7f3 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Feb 4, 2012 at 05:40, Fred Baker wrote: > I need to know what the working group, and especially the operators in it, > wants to do with this. Do you want to adopt it as a working group draft? Do > you want to discuss it but leave it individual? Do you think it belongs in > another working group, and if so which? Do you have another opinion? > Speaking as an Android developer, I think this is useful. Many GSM / UMTS networks do not and will not support the IPV4V6 PDP type required for dual-stack access, and running IPv4 and IPv6 on separate PDP contexts is brittle and has scaling issues. It would be nice if there was a WG draft aiming to take this to standards track in addition to an implementation. As to which WG it belongs in, I don't know. --f46d044789876dbbd104b846f7f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Feb 4, 2012 at 05:40, Fred Baker <fred@cisco.com> wrote:
I need to know what the working group, and especially the operators in it, = wants to do with this. Do you want to adopt it as a working group draft? Do= you want to discuss it but leave it individual? Do you think it belongs in= another working group, and if so which? Do you have another opinion?

Speaking as an Android developer, I think = this is useful. Many GSM / UMTS networks do not and will not support the IP= V4V6 PDP type required for dual-stack access, and running IPv4 and IPv6 on = separate PDP contexts is brittle and has scaling issues.

It would be nice if there was a WG draft aiming to take= this to standards track in addition to an implementation.=A0As to which WG= it belongs in, I don't know.
--f46d044789876dbbd104b846f7f3-- From iesg-secretary@ietf.org Mon Feb 6 07:02:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928A721F8699; Mon, 6 Feb 2012 07:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSVFGnvPSaPn; Mon, 6 Feb 2012 07:02:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FB921F85EA; Mon, 6 Feb 2012 07:02:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120206150214.5445.40209.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2012 07:02:14 -0800 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Operational Neighbor Discovery Problems) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 15:02:14 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Operational Neighbor Discovery Problems' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service, whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes the potential for DOS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can in some cases be used to protect against or at least alleviate the impact of such attacks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6nd-problems/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6nd-problems/ No IPR declarations have been submitted directly on this I-D. From cx.cernet@gmail.com Mon Feb 6 07:46:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B42321F8591 for ; Mon, 6 Feb 2012 07:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFJeuIOPazJU for ; Mon, 6 Feb 2012 07:46:30 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F91321F858B for ; Mon, 6 Feb 2012 07:46:30 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2181312pbc.31 for ; Mon, 06 Feb 2012 07:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FKsIe5VVhxQ6IZtH2r75ow+3MWdUuBMM/lV9OH/yScw=; b=Nzff7cM+z7rpDSpT0K+yfs04anw+6uqqFqsJLHKoNifdK0s9vI4SrBltrgYhZSaz7R qihIepTuF/CiAPhw8HxqtsDaWMWJn0sgqNA+H8ACdhh23KrBQomzfs383JpX412eI/8W oRujIO8K5KEqkgTovmPZZDPIFLkuRtDbaSNDU= MIME-Version: 1.0 Received: by 10.68.228.101 with SMTP id sh5mr48988573pbc.127.1328543190001; Mon, 06 Feb 2012 07:46:30 -0800 (PST) Received: by 10.143.32.7 with HTTP; Mon, 6 Feb 2012 07:46:29 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Feb 2012 23:46:29 +0800 Message-ID: From: Congxiao Bao To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=e89a8ff251a2e8a80604b84d9038 Cc: v6ops v6ops WG Subject: Re: [v6ops] Fwd: 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 15:46:34 -0000 --e89a8ff251a2e8a80604b84d9038 Content-Type: text/plain; charset=ISO-8859-1 Hi I think 464 XLAT can work for the cases where scalability and user tracking ability are not so critical, since it uses stateful XLAT in Core and stateless XLAT in CPE, not stateless double translation for both Core and CPE. I support it adopted by WG as an experimental document. Congxiao 2012/2/6 Lorenzo Colitti > On Sat, Feb 4, 2012 at 05:40, Fred Baker wrote: > >> I need to know what the working group, and especially the operators in >> it, wants to do with this. Do you want to adopt it as a working group >> draft? Do you want to discuss it but leave it individual? Do you think it >> belongs in another working group, and if so which? Do you have another >> opinion? >> > > Speaking as an Android developer, I think this is useful. Many GSM / UMTS > networks do not and will not support the IPV4V6 PDP type required for > dual-stack access, and running IPv4 and IPv6 on separate PDP contexts is > brittle and has scaling issues. > > It would be nice if there was a WG draft aiming to take this to standards > track in addition to an implementation. As to which WG it belongs in, I > don't know. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --e89a8ff251a2e8a80604b84d9038 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi
I think 464 XLAT can work for the cases where scalability and user tra= cking ability=A0are not so critical, since it uses stateful XLAT in Core an= d stateless XLAT in CPE, not stateless double translation for both Core and= CPE.
=A0
I support it adopted by WG as an experimental document.
Congxiao
2012/2/6 Lorenzo Colitti <<= a href=3D"mailto:lorenzo@google.com">lorenzo@google.com>
On Sat, Feb 4, 2012 at 05:40, Fred Baker <fred@cisco.com> wrote:
I need to know what the working group= , and especially the operators in it, wants to do with this. Do you want to= adopt it as a working group draft? Do you want to discuss it but leave it = individual? Do you think it belongs in another working group, and if so whi= ch? Do you have another opinion?

Speaking as an Android developer, I think this is useful. Many GSM / U= MTS networks do not and will not support the IPV4V6 PDP type required for d= ual-stack access, and running IPv4 and IPv6 on separate PDP contexts is bri= ttle and has scaling issues.

It would be nice if there was a WG draft aiming to take this to standa= rds track in addition to an implementation.=A0As to which WG it belongs in,= I don't know.

_________________________________________= ______
v6ops mailing list
v6ops@ietf.org<= br>https://www.ietf.org/mailman/listinfo/v6ops


--e89a8ff251a2e8a80604b84d9038-- From victor.kuarsingh@gmail.com Mon Feb 6 08:02:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A780821F84C5 for ; Mon, 6 Feb 2012 08:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUwLFJPf40LP for ; Mon, 6 Feb 2012 08:02:54 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 740A121F844C for ; Mon, 6 Feb 2012 08:02:54 -0800 (PST) Received: by werm10 with SMTP id m10so5398809wer.31 for ; Mon, 06 Feb 2012 08:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type; bh=jDJeiUy9gkzz/aom1HquonnLXDJBNIV2OsS6wGCBSSs=; b=DDT7aphhfgoXuN68cbecsFDRKm5iznHXK7LRH/2907wUEF6ZCN1ola5b/VLom2rZWx TxrKVcJxQ7ck9a4yDXT1WYnikNagVCIomIkx2Sp7xNaJXhd2xorKpJoierX6rQP6fhmp VHvBRZWAAYZhDnQorYzD1HS2Knapx1dsVfuGw= Received: by 10.216.134.37 with SMTP id r37mr7359292wei.38.1328544173710; Mon, 06 Feb 2012 08:02:53 -0800 (PST) Received: from [192.168.0.110] (a50.fluent.fr. [195.68.67.50]) by mx.google.com with ESMTPS id y6sm13909006wix.10.2012.02.06.08.02.50 (version=SSLv3 cipher=OTHER); Mon, 06 Feb 2012 08:02:52 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 06 Feb 2012 17:02:46 +0100 From: Victor Kuarsingh To: Congxiao Bao , Lorenzo Colitti Message-ID: Thread-Topic: [v6ops] Fwd: 464XLAT Trial Deployment Report In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3411392569_6247434" Cc: v6ops v6ops WG Subject: Re: [v6ops] Fwd: 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 16:02:57 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3411392569_6247434 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit From: Congxiao Bao > Hi > I think 464 XLAT can work for the cases where scalability and user tracking ability are not so critical, since it uses stateful XLAT in Core and stateless XLAT in > > CPE, not stateless double translation for both Core and CPE. > support it adopted by WG as an experimental document. >Congxiao +1. I agree this work has value. Regards, Victor K --B_3411392569_6247434 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable


From: Congxiao Bao <cx.cernet@gmail.com>

> H= i
> I think 464 XLAT can work for the cases where scalability a= nd user tracking ability are not so critical, since it uses stateful XL= AT in Core and stateless XLAT in > > CPE, not stateless double transla= tion for both Core and CPE.
 
> support it adopted by WG as an experimental document.=
>Congxiao

+1.  I =  agree this work has value.

Regards,

Victor K

 --B_3411392569_6247434-- From jhw@apple.com Mon Feb 6 10:33:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD1C21F852B for ; Mon, 6 Feb 2012 10:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.849 X-Spam-Level: X-Spam-Status: No, score=-109.849 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpr1tFT+junO for ; Mon, 6 Feb 2012 10:33:19 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 530B621F870B for ; Mon, 6 Feb 2012 10:33:19 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_VnKvTPWOIXrKfsk8cL78tQ)" Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0LYZ006NEI5TVL02@mail-out.apple.com> for v6ops@ietf.org; Mon, 06 Feb 2012 10:33:18 -0800 (PST) X-AuditID: 11807136-b7cd6ae000007787-2f-4f301cedfac4 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 65.BB.30599.EEC103F4; Mon, 06 Feb 2012 10:33:18 -0800 (PST) From: james woodyatt In-reply-to: Date: Mon, 06 Feb 2012 10:33:17 -0800 Message-id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1257) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUieJDXQfedjIG/weT1hhbrT79jtDh9bC+z A5PHgk2lHkuW/GQKYIrisklJzcksSy3St0vgyrj4rJWx4IF8xaMHz9kbGO9IdzFyckgImEh8 etDICGGLSVy4t56ti5GLQ0hgNpPE4oWdYAlhoKJHu7awgdi8AoYSM1+1s4LYzAIJEo+u9bKA 2GwCKhLfLt9l6mLk4OAUCJS48kEVJMwCFL75ZjIzRLmyxJ4H+9ghxthITF30hwli1zFGid/T loLtEhHQkHiw7jgTxEGyErcP7meawMg3C8nqWUhWQ9jaEssWvmaGsPUkXja9Y8cU15W4uG4S 4wJGtlWMgkWpOYmVhqZ6iQUFOal6yfm5mxhBQdpQaLaDccdfuUOMAhyMSjy8B7kN/IVYE8uK K3MPMUpwMCuJ8Ma90vcX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzrtxFlBKID2xJDU7NbUgtQgm y8TBKdXAaPbkveKTvieVBtvzXn4/tnlJ4eOim/zbC8v/TAmcayFQHqPs8qH/2V0nhtdeIetS mpjWcXSnlizT3b145nuGj5yuyzQDbr/LebBYSq2j5b5HQMubtgU+HkYXRX8GzcxN12pn99U6 7zOHw47//e0zs3+HZourR95dsPh+9TLfrU831qSE9snMUWIpzkg01GIuKk4EAG8Td0BOAgAA Cc: v6ops v6ops WG Subject: Re: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 18:33:20 -0000 --Boundary_(ID_VnKvTPWOIXrKfsk8cL78tQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Feb 5, 2012, at 23:53 , Lorenzo Colitti wrote: > > As to which WG it belongs in, I don't know. I would say that if there is a WG where this belongs, then it would be BEHAVE and not V6OPS. I fail to see why this needs a working group to develop any further. Wouldn't the individual submission track be more appropriate? -- j h woodyatt --Boundary_(ID_VnKvTPWOIXrKfsk8cL78tQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
As to which = WG it belongs in, I don't know.

I would say that if = there is a WG where this belongs, then it would be BEHAVE and not V6OPS. =  I fail to see why this needs a working group to develop any = further.  Wouldn't the individual submission track be more = appropriate?


--
j h woodyatt <jhw@apple.com>

= --Boundary_(ID_VnKvTPWOIXrKfsk8cL78tQ)-- From washam.fan@gmail.com Mon Feb 6 22:01:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7428721F871D for ; Mon, 6 Feb 2012 22:01:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYLKAfgLJSZj for ; Mon, 6 Feb 2012 22:01:20 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 577D621F858E for ; Mon, 6 Feb 2012 22:01:20 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so5075913wgb.13 for ; Mon, 06 Feb 2012 22:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=5in0Ge741uuyn99SA/sqH5edNVyR/P2QZeVAFFwy5i0=; b=fy0++mw4CLYwpV82KQQPeLw7FFZ8FPJJCY5+tGUZQ/ybnqqWlz4LnLTH9dXyWsqHgB umbadH+gNYMiHdBVck0u2LivwlzBsmpL6CYTbY0JHhXq6JzL0k63ABLA/8X/Eujl5lWh 9TiIWvT669f/+kXq4nyp6cZtrKXYMg1toVbUc= MIME-Version: 1.0 Received: by 10.180.82.227 with SMTP id l3mr30074098wiy.1.1328594479545; Mon, 06 Feb 2012 22:01:19 -0800 (PST) Received: by 10.216.1.6 with HTTP; Mon, 6 Feb 2012 22:01:19 -0800 (PST) Date: Tue, 7 Feb 2012 14:01:19 +0800 Message-ID: From: Washam Fan To: IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] Comments on 464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 06:01:21 -0000 Hi, I generally support this work. But have several comments below. 1. section 7.4 mentioned DNS proxy for both IPv4 and IPv6 hosts, i don't know why DNS proxy for IPv6 hosts is needed. 2. I think the author should elaborate on what the configuration function is like in section 7.6 3. i don't know what is the meaning for the text under section 7.5. I think NDP should always perform while SLAAC perform only if the prefix equals to 64. 4. I don't know if the draft should cover the host1-CLAT1-CLAT2-host2 communication case. Thanks, washam From ietfc@btconnect.com Tue Feb 7 02:23:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B12A21F8755 for ; Tue, 7 Feb 2012 02:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.343 X-Spam-Level: X-Spam-Status: No, score=-0.343 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_50=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4STT0yFQuFFU for ; Tue, 7 Feb 2012 02:23:05 -0800 (PST) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id D923C21F8754 for ; Tue, 7 Feb 2012 02:23:02 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2bthomr13.btconnect.com with SMTP id GED91458; Tue, 07 Feb 2012 10:22:59 +0000 (GMT) Message-ID: <01bf01cce57a$1a0e0900$4001a8c0@gateway.2wire.net> From: "t.petch" To: "james woodyatt" References: Date: Tue, 7 Feb 2012 10:23:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4F30FB83.000E, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.30.73017:17:7.586, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, ECARD_KNOWN_DOMAINS, BODY_SIZE_1100_1199, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020C.4F30FB83.013F,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: v6ops v6ops WG Subject: Re: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 10:23:06 -0000 ----- Original Message ----- From: "james woodyatt" To: "Lorenzo Colitti" Cc: "v6ops v6ops WG" Sent: Monday, February 06, 2012 7:33 PM > On Feb 5, 2012, at 23:53 , Lorenzo Colitti wrote: > > > > As to which WG it belongs in, I don't know. > > I would say that if there is a WG where this belongs, then it would be BEHAVE and not V6OPS. I fail to see why this needs a working group to develop any further. Wouldn't the individual submission track be more appropriate? When I have suggested an individual submission, I get told that it costs the IETF more, that is that the necessary evils of publishing are amortised across a wider spectrum of people when a WG is involved, so unless an AD is really burning with desire to support an individual submission, then a WG is the way to go. V6OPS or BEHAVE? I see the latter as more limited, more focussed in scope, so would go for V6OPS. Is it worth publishing as an RFC? Yes, the IETF traditionally neglects operators, favouring 'manufacturers' so this would help redress the balance. Tom Petch > -- > j h woodyatt > From fred@cisco.com Tue Feb 7 05:48:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D7721F87B5 for ; Tue, 7 Feb 2012 05:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.862 X-Spam-Level: X-Spam-Status: No, score=-105.862 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yqY7owBEQEO for ; Tue, 7 Feb 2012 05:48:51 -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 DA83021F863D for ; Tue, 7 Feb 2012 05:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3099; q=dns/txt; s=iport; t=1328622531; x=1329832131; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=x5aVsiSAcIZiaLRN+HM6avPN6v/thcatiTfs4vb9PiI=; b=h4Srod4kfYqZGQ7kGZKz4Tioqn6kqIqZBVItVIyKc8Fsh57vI50PAXgD KSE0R2fdEcAt3m86CpUzZ2mDON0TUeBQ28ZHpJhbYXeLdAMZQpq7gDe56 9sOhkD2xosjoay7ru5ZTL9zu9LvGoWsPpud/xFxBpLdyItoi3iboHUB7J Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALcqMU+rRDoG/2dsb2JhbAA5Cq9QgQWBcgEBAQMBAQEBCwQBJysJCwUHBAUGFQECLicwBhMRCgeHWgmbPAGfDohogk0HAgIJBQwGEwEIBQMDCQ2DDwUYAgsCBWMVgnZjBIhGjGaFWI0m X-IronPort-AV: E=Sophos;i="4.73,377,1325462400"; d="scan'208";a="28964319" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 07 Feb 2012 13:48:50 +0000 Received: from Freds-Computer.local (sjc-vpn5-246.cisco.com [10.21.88.246]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q17DmoVY002642; Tue, 7 Feb 2012 13:48:50 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 07 Feb 2012 05:48:50 -0800 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 07 Feb 2012 05:48:50 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker X-Priority: 3 In-Reply-To: <01bf01cce57a$1a0e0900$4001a8c0@gateway.2wire.net> Date: Tue, 7 Feb 2012 05:48:21 -0800 Message-Id: References: <01bf01cce57a$1a0e0900$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 13:48:52 -0000 On Feb 7, 2012, at 1:23 AM, t.petch wrote: > ----- Original Message ----- > From: "james woodyatt" > To: "Lorenzo Colitti" > Cc: "v6ops v6ops WG" > Sent: Monday, February 06, 2012 7:33 PM >> On Feb 5, 2012, at 23:53 , Lorenzo Colitti wrote: >>>=20 >>> As to which WG it belongs in, I don't know. >>=20 >> I would say that if there is a WG where this belongs, then it would = be BEHAVE >> and not V6OPS. I fail to see why this needs a working group to = develop any >> further. Wouldn't the individual submission track be more = appropriate? >=20 > When I have suggested an individual submission, I get told that it = costs the > IETF more, that is that the necessary evils of publishing are = amortised across a > wider spectrum of people when a WG is involved, so unless an AD is = really > burning with desire to support an individual submission, then a WG is = the way to > go. You haven't heard that from me. I think that a WG is the preferred = approach because you are likely to get better review and discussion, but = the cost issues are largely a wash. > V6OPS or BEHAVE? I see the latter as more limited, more focussed in = scope, so > would go for V6OPS. The real question there is one of charter. Behave's charter = (http://datatracker.ietf.org/wg/behave/charter/), which is written in = incomplete sentences and has some important bits presumed rather than = stated, is about the development of translation technologies - IPv4/IPv4 = and IPv4/IPv6, in four scenarios. It is supposed to interact with v6ops = on requirements and operational matters. V6ops' charter = (http://datatracker.ietf.org/wg/v6ops/charter/), among other things, = calls for us to "Publish Informational or BCP RFCs that identify and = analyze solutions for deploying IPv6 within common network environments, = such as ISP Networks, Enterprise Networks, Unmanaged Networks = (Home/Small Office), and Cellular Networks.". By that rubric, v6ops is = an obvious place it might go. One could also imagine opsawg or opsec = under one rubric or another. If it's going to be discussed, I'm personally happy to have it discussed = here. I have, however, gotten a lot of commentary from the operators = about documents coming into v6ops that they don't want to discuss. = Hence, my question is whether the operators what to discuss it, and = whether they specifically want to discuss it here. > Is it worth publishing as an RFC? Yes, the IETF traditionally = neglects > operators, favouring 'manufacturers' so this would help redress the = balance. Urban legend. This falls right in there with "operators don't get = involved in the IETF". Hi. Welcome to the IETF. You're an operator, and = you are participating in a discussion that is largely among operators = within the IETF. > Tom Petch >=20 >> -- >> j h woodyatt >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From shtsuchi@cisco.com Tue Feb 7 21:17:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16ED611E8088; Tue, 7 Feb 2012 21:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+f2K4F1kBXv; Tue, 7 Feb 2012 21:17:00 -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 8FB7D11E8094; Tue, 7 Feb 2012 21:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=1797; q=dns/txt; s=iport; t=1328678219; x=1329887819; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=abd6fC2wBSptmpobZToYYQA1bZx5fKVb+ZOmTdWu/S0=; b=JPRKz51u4ABVO/US323MfbHX6Hvme/vAIQkb5nV+ddF0BDR6pVgv3Luc 4YKOEQ/Ra32d53KluzihFh2bsFBnFESZKzJzh8VJNYJAZf8RTHueVkOA7 L1v6NpVtM8fYwwxsgO3I5cQkP62SFYyAVUQYbZx1RtRje3LlNa0o22UA3 I=; X-IronPort-AV: E=Sophos;i="4.73,382,1325462400"; d="scan'208";a="29241710" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 08 Feb 2012 05:16:59 +0000 Received: from [64.104.9.218] (dhcp-shinjuku-64-104-9-218.cisco.com [64.104.9.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q185Gwn1010353; Wed, 8 Feb 2012 05:16:58 GMT Message-ID: <4F320549.20100@cisco.com> Date: Wed, 08 Feb 2012 14:16:57 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: armd@ietf.org, v6ops@ietf.org References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com> In-Reply-To: <20111114092126.3494.19513.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111114092126.3494.19513.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org Subject: [v6ops] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 05:17:01 -0000 v6ops and ARMD Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd. We thought this is interesting idea,so published the draft. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 I think both of mailing list participants are also interesting in this technique. If you have any comment and question of the draft,please let me know. Regards, -Shishio -------- Original Message -------- Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt Date: Mon, 14 Nov 2011 17:21:26 +0800 From: Reply-To: To: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Rapid Deployment (6rd) in a Large Data Center Author(s) : Shishio Tsuchiya Mark Townsley Shuichi Ohkubo Filename : draft-sakura-6rd-datacenter-03.txt Pages : 15 Date : 2011-11-14 IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid deployment of IPv6 by an access service provider which has difficulty deploying native IPv6. This document describes how 6rd can be used to deliver IPv6 within a Large Data Center. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt _______________________________________________ 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 yiu_lee@cable.comcast.com Tue Feb 7 21:23:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2838611E80A5; Tue, 7 Feb 2012 21:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.648 X-Spam-Level: X-Spam-Status: No, score=-100.648 tagged_above=-999 required=5 tests=[AWL=-1.532, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R-DV5h4qQ7Q; Tue, 7 Feb 2012 21:23:44 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 1816111E8088; Tue, 7 Feb 2012 21:23:44 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.5455620; Tue, 07 Feb 2012 22:14:04 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Wed, 8 Feb 2012 00:23:41 -0500 From: "Lee, Yiu" To: Shishio Tsuchiya Thread-Topic: [Softwires] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt Thread-Index: AQHM5iDpvq1pF/9+ckGtbaXvkonN/5Yyd2BV Date: Wed, 8 Feb 2012 05:23:40 +0000 Message-ID: <40137D15-A014-4C28-B531-9D949173C222@Cable.Comcast.com> References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com>, <4F320549.20100@cisco.com> In-Reply-To: <4F320549.20100@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" , "v6ops@ietf.org" , "draft-sakura-6rd-datacenter@tools.ietf.org" , "armd@ietf.org" Subject: Re: [v6ops] [Softwires] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 05:23:45 -0000 Hi Shishio, Thanks for sharing this. I am glad but not surprised to see the result beca= use free.fr has shown to scale 6rd to millions of their users since few yea= rs ago. Yiu On Feb 8, 2012, at 0:17, "Shishio Tsuchiya" wrote: > v6ops and ARMD > Sakura internet are providing IPv6 service without scalability impact to = core network equipment to customer using 6rd. > We thought this is interesting idea,so published the draft. >=20 > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 >=20 > I think both of mailing list participants are also interesting in this te= chnique. > If you have any comment and question of the draft,please let me know. >=20 > Regards, > -Shishio > -------- Original Message -------- > Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt > Date: Mon, 14 Nov 2011 17:21:26 +0800 > From: > Reply-To: > To: >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : IPv6 Rapid Deployment (6rd) in a Large Data Center > Author(s) : Shishio Tsuchiya > Mark Townsley > Shuichi Ohkubo > Filename : draft-sakura-6rd-datacenter-03.txt > Pages : 15 > Date : 2011-11-14 >=20 > IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid > deployment of IPv6 by an access service provider which has difficulty > deploying native IPv6. This document describes how 6rd can be used > to deliver IPv6 within a Large Data Center. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt > _______________________________________________ > 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 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From shtsuchi@cisco.com Tue Feb 7 21:39:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F1311E8089; Tue, 7 Feb 2012 21:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.408 X-Spam-Level: X-Spam-Status: No, score=-5.408 tagged_above=-999 required=5 tests=[AWL=-2.124, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyVeyHlPo6av; Tue, 7 Feb 2012 21:39:50 -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 545B621F8507; Tue, 7 Feb 2012 21:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=2893; q=dns/txt; s=iport; t=1328679590; x=1329889190; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=+pxfYkUbPwPJDB3arVToosXMP7EeF5y37/lSTDMZAdQ=; b=Sd9zfxHDABI2lBslDD7a6Q4TtIk1V+2I+01+9DtHcJ1es8Mpo/oyogep lepDS1iQOOwPF3ckW6KRElBrWvrrjBhU8Y6/zPUwLnltIl7W1qTCfEXb2 0m2QV4jexRFsaGJx43b5r9SeJu/FV6oi2rL1+iZkR1Fl7sCqoATK+03Tq w=; X-IronPort-AV: E=Sophos;i="4.73,382,1325462400"; d="scan'208";a="29107881" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 08 Feb 2012 05:39:49 +0000 Received: from [64.104.9.218] (dhcp-shinjuku-64-104-9-218.cisco.com [64.104.9.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q185dlZw003253; Wed, 8 Feb 2012 05:39:48 GMT Message-ID: <4F320AA3.1020803@cisco.com> Date: Wed, 08 Feb 2012 14:39:47 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Yiu_Lee@Cable.Comcast.com References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com>, <4F320549.20100@cisco.com> <40137D15-A014-4C28-B531-9D949173C222@Cable.Comcast.com> In-Reply-To: <40137D15-A014-4C28-B531-9D949173C222@Cable.Comcast.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, v6ops@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org, armd@ietf.org Subject: Re: [v6ops] [Softwires] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 05:39:51 -0000 Yiu Thanks for comments. Yes,Free,Swisscom,Softbank and so on already deployed 6rd to the access network. But Sakura deployed IPv6 to the datacenter network by server based 6rd with variable OSs and 6rd BR. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03#section-3 This is my interesting point,and this would be useful information. Regards, -Shishio (2012/02/08 14:23), Lee, Yiu wrote: > Hi Shishio, > > Thanks for sharing this. I am glad but not surprised to see the result because free.fr has shown to scale 6rd to millions of their users since few years ago. > > Yiu > > On Feb 8, 2012, at 0:17, "Shishio Tsuchiya" wrote: > > > v6ops and ARMD > > Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd. > > We thought this is interesting idea,so published the draft. > > > > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 > > > > I think both of mailing list participants are also interesting in this technique. > > If you have any comment and question of the draft,please let me know. > > > > Regards, > > -Shishio > > -------- Original Message -------- > > Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt > > Date: Mon, 14 Nov 2011 17:21:26 +0800 > > From: > > Reply-To: > > To: > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : IPv6 Rapid Deployment (6rd) in a Large Data Center > > Author(s) : Shishio Tsuchiya > > Mark Townsley > > Shuichi Ohkubo > > Filename : draft-sakura-6rd-datacenter-03.txt > > Pages : 15 > > Date : 2011-11-14 > > > > IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid > > deployment of IPv6 by an access service provider which has difficulty > > deploying native IPv6. This document describes how 6rd can be used > > to deliver IPv6 within a Large Data Center. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt > > _______________________________________________ > > 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 > > > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > From lorenzo@google.com Wed Feb 8 05:54:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F4321F865B for ; Wed, 8 Feb 2012 05:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49HdVvrCXb1S for ; Wed, 8 Feb 2012 05:54:51 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A02E421F85D9 for ; Wed, 8 Feb 2012 05:54:51 -0800 (PST) Received: by obbwd15 with SMTP id wd15so1023543obb.31 for ; Wed, 08 Feb 2012 05:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=ENct9zuBM/KtSoi788U61wDlvFKkk+3auCus6P3AbdA=; b=bm2E4v5g3eYiOW9JD9yTZW7XYWzx9DJSH8no7P65BLiu3+8FAJOky5Hii/LQXZJoTh +3pKmX88U/MGCtwsTwZSAlTbqMKqhHvXzVT3XvLpNc8NW34eceQtgBU5jTjwy+xrB7KY ugCW6TKc9KtWWdfGQvObmQI1cecKPsiUBKtE0= Received: by 10.182.8.69 with SMTP id p5mr25761754oba.28.1328709291319; Wed, 08 Feb 2012 05:54:51 -0800 (PST) Received: by 10.182.8.69 with SMTP id p5mr25761741oba.28.1328709291188; Wed, 08 Feb 2012 05:54:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.81.71 with HTTP; Wed, 8 Feb 2012 05:54:31 -0800 (PST) In-Reply-To: <8EA035DE-DAB9-4920-9BD6-75944848CA5D@cisco.com> References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <8EA035DE-DAB9-4920-9BD6-75944848CA5D@cisco.com> From: Lorenzo Colitti Date: Wed, 8 Feb 2012 22:54:31 +0900 Message-ID: To: Fred Baker X-System-Of-Record: true Content-Type: multipart/alternative; boundary=f46d0444ec4b4fa32b04b8743d3a Cc: v6ops v6ops WG , IETF Discussion Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 13:54:52 -0000 --f46d0444ec4b4fa32b04b8743d3a Content-Type: text/plain; charset=ISO-8859-1 On Sat, Feb 4, 2012 at 01:35, Fred Baker wrote: > The IESG again decided it needed a revised draft, and that draft - in > large part, a rewrite - arrived in October. v6ops had a second WGLC, in > which you again declined to comment, although you may have seen Lorenzo's > comments, which were picked up in a November version of the draft. Ralph > and Jari finally cleared their "discuss" ballots a couple of weeks ago, and > we are having a second IETF last call. > > I'd like to understand your objective here. I know that you don't care for > the draft, and at least at one point took it as a somewhat-personal attack. > Is your objective to prevent the draft's publication entirely, or do you > think that there is value in publishing it given a productive response to > this comment? At what point are you willing to either participate in the > public dialog or choose to not comment at all? Ok, let me see if I can rephrase Erik's objection. The draft needs to take World IPv6 Launch into account, because it's a key piece of the puzzle. We can't publish an RFC on how to transition content to IPv6 if the RFC ignores the event when 5 of the top 10 websites in the world (and probably many more) will permanently enable IPv6 for everyone. Cheers, Lorenzo --f46d0444ec4b4fa32b04b8743d3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Feb 4, 2012 at 01:35, Fred Baker <fred@cisco.com> wrote:
The IESG again decided it needed a revised draft, and tha= t draft - in large part, a rewrite - arrived in October. v6ops had a second= WGLC, in which you again declined to comment, although you may have seen L= orenzo's comments, which were picked up in a November version of the dr= aft. Ralph and Jari finally cleared their "discuss" ballots a cou= ple of weeks ago, and we are having a second IETF last call.

I'd like to understand your objective here. I know that you don't c= are for the draft, and at least at one point took it as a somewhat-personal= attack. Is your objective to prevent the draft's publication entirely,= or do you think that there is value in publishing it given a productive re= sponse to this comment? At what point are you willing to either participate= in the public dialog or choose to not comment at all?

Ok, let me see if I can rephrase Erik's objection.<= /div>

The draft needs to take World IPv6 Launch into acc= ount, because it's a key piece of the puzzle.

We can't publish an RFC on how to transition content to IPv6 if the RFC= ignores the event when 5 of the top 10 websites in the world (and probably= many more) will permanently enable IPv6 for everyone.

Cheers,
Lorenzo
--f46d0444ec4b4fa32b04b8743d3a-- From fgont@si6networks.com Wed Feb 8 06:24:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A220121F85DD; Wed, 8 Feb 2012 06:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX-EhpNqnj6j; Wed, 8 Feb 2012 06:24:37 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id D6AB721F85F7; Wed, 8 Feb 2012 06:24:36 -0800 (PST) Received: from [190.48.215.115] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rv8Rk-0000d3-5X; Wed, 08 Feb 2012 15:24:32 +0100 Message-ID: <4F31EFFC.5020402@si6networks.com> Date: Wed, 08 Feb 2012 00:46:04 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: ietf@ietf.org, igor@yahoo-inc.com, jjaeggli@zynga.com, Warren Kumari References: <20120206150214.5445.40209.idtracker@ietfa.amsl.com> In-Reply-To: <20120206150214.5445.40209.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Operational Neighbor Discovery Problems) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 14:24:37 -0000 Folks, I've reviewed the aforementioned document. These are my comments: ** Technical: ** * Section 6.1: It should be noted that the proposed mitigations makes address scans easier. Also, the text currently says "and may not interact well with networks using [RFC4862]". -- I'd argue that "it does not work with networks using [RFC4862]". * Section 7: I believe that probably the most important implementation advice with respect to the issue being discussed is missing (at least explicitly). It could be stated as follows: "NDP implementations should limit the number of Neighbor Cache entries that are in the INCOMPLETE state. The aforementioned limit should be much lower than the global limit on the total number of Neighbor Cache entries. Since the attack discussed in this document is based on triggering address resolution for non-existing nodes, limiting the number of entries in the Neighbor Cache that are in the INCOMPLETE state will mitigate the aforementioned attack, while still allowing ongoing communications with "known" nodes to continue unnafected". (feel free to use the text verbatim or modify as necessary) * Section 7.1, bullet "4": This paragraph is at least a bit vague. I'm not sure if you're referring to something similar to what I've mentioned above -- but it doesn't read like that. You may want to replace this paragraph with the one I provided above, or at least clarify it. * Section 7.2: On implementations in which requests to NDP are submitted via a single queue, router vendors SHOULD provide operators with means to control both the rate of link-layer address resolution requests placed into the queue and the size of the queue. My understanding is that being an "Informational" document, you should s/SHOULD/should/ -- i.e., remove the RFC2119 language in the recommendation. ** Editorial: ** * Section 3: packets. In higher-end routers, the forwarding plane is typically implemented in specialized hardware optimized for performance. Steps in the forwarding process include determining the correct outgoing interface for a packet, decrementing its Time To Live (TTL), verifying and updating the checksum, placing the correct link-layer header on the packet, and forwarding it. Maybe this text should reflect IPv6, rather than IPv4 (i..e, s/TTL/Hop Limit/, and remove the checksum bit) ** Nits: ** * Abstract: s/DOS/DoS/, (there are a few instances of this elsewhere) and expand the acronym the first time you use it. * Section 1.1: s/IPV6/IPv6/ * Section 2: Missing space in "memoryand replaces existing " * Section 4: addresses (and in many cases becomes unable to perform maintenance of existing entries in the neighbor cache, and unable to answer Neighbor Solicitation). s/Solicitation/Solicitations/ * Section 7.2: s/Neighbour/Neighbor/ Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From joelja@bogus.com Wed Feb 8 07:37:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F80B21F8701; Wed, 8 Feb 2012 07:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.849 X-Spam-Level: X-Spam-Status: No, score=-101.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFwByYVouxow; Wed, 8 Feb 2012 07:37:09 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 95AF021F8700; Wed, 8 Feb 2012 07:37:09 -0800 (PST) Received: from Joels-MacBook-Pro.local (115.sub-166-250-77.myvzw.com [166.250.77.115]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q18Fb5Ot039504 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 8 Feb 2012 15:37:06 GMT (envelope-from joelja@bogus.com) Message-ID: <4F329696.6000505@bogus.com> Date: Wed, 08 Feb 2012 07:36:54 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <8EA035DE-DAB9-4920-9BD6-75944848CA5D@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 08 Feb 2012 15:37:07 +0000 (UTC) Cc: v6ops v6ops WG , IETF Discussion Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 15:37:10 -0000 On 2/8/12 05:54 , Lorenzo Colitti wrote: > On Sat, Feb 4, 2012 at 01:35, Fred Baker > wrote: > > The IESG again decided it needed a revised draft, and that draft - > in large part, a rewrite - arrived in October. v6ops had a second > WGLC, in which you again declined to comment, although you may have > seen Lorenzo's comments, which were picked up in a November version > of the draft. Ralph and Jari finally cleared their "discuss" ballots > a couple of weeks ago, and we are having a second IETF last call. > > I'd like to understand your objective here. I know that you don't > care for the draft, and at least at one point took it as a > somewhat-personal attack. Is your objective to prevent the draft's > publication entirely, or do you think that there is value in > publishing it given a productive response to this comment? At what > point are you willing to either participate in the public dialog or > choose to not comment at all? > > > Ok, let me see if I can rephrase Erik's objection. > > The draft needs to take World IPv6 Launch into account, because it's a > key piece of the puzzle. > > We can't publish an RFC on how to transition content to IPv6 if the RFC > ignores the event when 5 of the top 10 websites in the world (and > probably many more) will permanently enable IPv6 for everyone. Ops is not marketing. If you're saying some flag day makes the contents of the document no longer operationally relevant after a given date, I'll take the point but disagree. The document in it's present form has a wider audience than the operators at 5 of the ton 10 websites. > Cheers, > Lorenzo > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Wed Feb 8 08:02:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF2F21F85DF; Wed, 8 Feb 2012 08:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.151 X-Spam-Level: X-Spam-Status: No, score=-106.151 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFoL6LLlIstJ; Wed, 8 Feb 2012 08:02:55 -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 695BB21F85D6; Wed, 8 Feb 2012 08:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3757; q=dns/txt; s=iport; t=1328716975; x=1329926575; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=ZaC+ql16a2rAMnYFUS1q0vo8Jzj6hwbyq9/wG5jh1QA=; b=FqA1BYSknvWiVlzglmrQp5h7IWkXg1AyKCtWQya+7UEHrYiKt0/K0ejW OtcwihL460nLWVqVNR9pZlEqx/kEJYqrO2nbt4BU9yum08nVEHl7H3yLs /zyrz4OUdousE0txTcJ0bpvAX4vrmSy5vT4Ke6WL4oUBvkETBa5NeUIfZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOebMk+rRDoH/2dsb2JhbABDr3CBB4FyAQEBAwESAWYFCwsEFBUOC1cGEyKHWpt6AZcAi1MCDxETAQgFAwMJDYMPBRgCCwIFQSIVGwQRgkZjBIhGjGeFWI0m X-IronPort-AV: E=Sophos;i="4.73,384,1325462400"; d="scan'208,217";a="29317827" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 08 Feb 2012 16:02:55 +0000 Received: from Freds-Computer.local (sjc-vpn2-244.cisco.com [10.21.112.244]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q18G2Qas004363; Wed, 8 Feb 2012 16:02:54 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Wed, 08 Feb 2012 08:02:55 -0800 X-PGP-Universal: processed; by Freds-Computer.local on Wed, 08 Feb 2012 08:02:55 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Wed, 8 Feb 2012 08:02:54 -0800 Message-Id: <2381D869-D36C-4817-BE5C-32A65813EB38@cisco.com> References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <8EA035DE-DAB9-4920-9BD6-75944848CA5D@cisco.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-16-369940344 Cc: v6ops v6ops WG , IETF Discussion Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 16:02:56 -0000 --Apple-Mail-16-369940344 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii What specifically would you like changed in the draft? Can you suggest = text?=20 On Feb 8, 2012, at 5:54 AM, Lorenzo Colitti wrote: > On Sat, Feb 4, 2012 at 01:35, Fred Baker wrote: > The IESG again decided it needed a revised draft, and that draft - in = large part, a rewrite - arrived in October. v6ops had a second WGLC, in = which you again declined to comment, although you may have seen = Lorenzo's comments, which were picked up in a November version of the = draft. Ralph and Jari finally cleared their "discuss" ballots a couple = of weeks ago, and we are having a second IETF last call. >=20 > I'd like to understand your objective here. I know that you don't care = for the draft, and at least at one point took it as a somewhat-personal = attack. Is your objective to prevent the draft's publication entirely, = or do you think that there is value in publishing it given a productive = response to this comment? At what point are you willing to either = participate in the public dialog or choose to not comment at all? >=20 > Ok, let me see if I can rephrase Erik's objection. >=20 > The draft needs to take World IPv6 Launch into account, because it's a = key piece of the puzzle. >=20 > We can't publish an RFC on how to transition content to IPv6 if the = RFC ignores the event when 5 of the top 10 websites in the world (and = probably many more) will permanently enable IPv6 for everyone. >=20 > Cheers, > Lorenzo --Apple-Mail-16-369940344 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii What specifically would you like changed in the draft? Can you suggest text? 

On Feb 8, 2012, at 5:54 AM, Lorenzo Colitti wrote:

On Sat, Feb 4, 2012 at 01:35, Fred Baker <fred@cisco.com> wrote:
The IESG again decided it needed a revised draft, and that draft - in large part, a rewrite - arrived in October. v6ops had a second WGLC, in which you again declined to comment, although you may have seen Lorenzo's comments, which were picked up in a November version of the draft. Ralph and Jari finally cleared their "discuss" ballots a couple of weeks ago, and we are having a second IETF last call.

I'd like to understand your objective here. I know that you don't care for the draft, and at least at one point took it as a somewhat-personal attack. Is your objective to prevent the draft's publication entirely, or do you think that there is value in publishing it given a productive response to this comment? At what point are you willing to either participate in the public dialog or choose to not comment at all?

Ok, let me see if I can rephrase Erik's objection.

The draft needs to take World IPv6 Launch into account, because it's a key piece of the puzzle.

We can't publish an RFC on how to transition content to IPv6 if the RFC ignores the event when 5 of the top 10 websites in the world (and probably many more) will permanently enable IPv6 for everyone.

Cheers,
Lorenzo

--Apple-Mail-16-369940344-- From brian.e.carpenter@gmail.com Wed Feb 8 12:06:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B5B11E80AE for ; Wed, 8 Feb 2012 12:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QiGc+ZHGm9w for ; Wed, 8 Feb 2012 12:06:13 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B949E11E8099 for ; Wed, 8 Feb 2012 12:06:01 -0800 (PST) Received: by werm10 with SMTP id m10so941095wer.31 for ; Wed, 08 Feb 2012 12:06:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pjpc5/JpyPKqgrRJT14B7jNe7wvo1IIxMX99XY0jkWc=; b=KjSOHyylS046QTuNT87XawktXNLVDs3W436kEn6H0MpOeaDCrSsP8Q1XI4U/emxDTe 66jd0YUQ7nQtAhDgetSfPGoDLv5Vb/uZ80P3LuwbnwRwmjbgelrHczHCUpgdzw1dHh6X 5pM/9j/AldAhXjK6QQAPU9Ue8SD+TubdCarcM= Received: by 10.216.136.96 with SMTP id v74mr7170522wei.27.1328731560764; Wed, 08 Feb 2012 12:06:00 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id cb8sm2227754wib.0.2012.02.08.12.05.58 (version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 12:06:00 -0800 (PST) Message-ID: <4F32D59E.7080306@gmail.com> Date: Thu, 09 Feb 2012 09:05:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> In-Reply-To: <4F25C955.8070704@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] Why v6ops should think about load balancers [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:06:14 -0000 Every serious content provider runs load balancers. Missing IPv6 support in load balancers has been a delaying factor for IPv6 deployment. This draft discusses the only aspect of IPv6 that seems to be significantly different from IPv4: the flow label may enhance load balancer efficiency. The authors suggest that the topic belongs in v6ops because it potentially affects all large server operators, but calls for no protocol changes. We'd like to know who agrees or disagrees. Regards Brian Carpenter On 2012-01-30 11:33, Brian E Carpenter wrote: > Hi, > > I'm not seeing more comments on this. The authors would like advice: > > Should we ask for v6ops to adopt this? > Should we ask another WG to adopt it? > Should we propose it as an individual submission? > Should we forget about it? > > Regards > Brian Carpenter > > On 2012-01-18 10:14, Brian E Carpenter wrote: >> This is a significant update since the version discussed in Taipei, >> with an additional author who is a practitioner in the field, >> and incorporating comments from implementors. >> >> Of course we would like more feedback. For the moment I suggest >> discussion on the v6ops list, although that may not be the >> final home for this draft. >> >> Please keep Willy on CC since I'm not sure he's on this list. >> >> Brian Carpenter >> >> -------- Original Message -------- >> Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt >> Date: Tue, 17 Jan 2012 12:40:05 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Using the IPv6 Flow Label for Server Load Balancing >> Author(s) : Brian Carpenter >> Sheng Jiang >> Willy Tarreau >> Filename : draft-carpenter-v6ops-label-balance-01.txt >> Pages : 12 >> Date : 2012-01-17 >> >> This document describes how the IPv6 flow label can be used in >> support of layer 3/4 load distribution and balancing for large server >> farms. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >> >> _______________________________________________ >> 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 marka@isc.org Wed Feb 8 13:06:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5996D21F851B; Wed, 8 Feb 2012 13:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfuKXn+CkxGX; Wed, 8 Feb 2012 13:06:04 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B83C121F8508; Wed, 8 Feb 2012 13:06:04 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 566A6C944A; Wed, 8 Feb 2012 21:05:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:3981:7370:f4ed:515c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id EDD4F216C6A; Wed, 8 Feb 2012 21:05:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 18A0D1D0458C; Thu, 9 Feb 2012 08:05:48 +1100 (EST) To: Lorenzo Colitti From: Mark Andrews References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <8EA035DE-DAB9-4920-9BD6-75944848CA5D@cisco.com> In-reply-to: Your message of "Wed, 08 Feb 2012 22:54:31 +0900." Date: Thu, 09 Feb 2012 08:05:48 +1100 Message-Id: <20120208210548.18A0D1D0458C@drugs.dv.isc.org> Cc: v6ops v6ops WG , IETF Discussion Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 21:06:05 -0000 In message , Lorenzo Colitti writes: > On Sat, Feb 4, 2012 at 01:35, Fred Baker wrote: > > > The IESG again decided it needed a revised draft, and that draft - in > > large part, a rewrite - arrived in October. v6ops had a second WGLC, in > > which you again declined to comment, although you may have seen Lorenzo's > > comments, which were picked up in a November version of the draft. Ralph > > and Jari finally cleared their "discuss" ballots a couple of weeks ago, and > > we are having a second IETF last call. > > > > I'd like to understand your objective here. I know that you don't care for > > the draft, and at least at one point took it as a somewhat-personal attack. > > Is your objective to prevent the draft's publication entirely, or do you > > think that there is value in publishing it given a productive response to > > this comment? At what point are you willing to either participate in the > > public dialog or choose to not comment at all? > > > Ok, let me see if I can rephrase Erik's objection. > > The draft needs to take World IPv6 Launch into account, because it's a key > piece of the puzzle. > > We can't publish an RFC on how to transition content to IPv6 if the RFC > ignores the event when 5 of the top 10 websites in the world (and probably > many more) will permanently enable IPv6 for everyone. > > Cheers, > Lorenzo World IPv6 day just means Google is at 5.5 now and will go to 5.6/5.7. It really does not change anything. The decision to whitelist is a subjective one, not a objective one. Similarly the decision to stop whitelisting is also a subjective one. While I, and I suspect most of the list, think that whitelisting should no longer be needed that isn't our call to make. All we can do is encourage people to not whitelist by running dual stack services without using whitelisting. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From despres.remi@laposte.net Thu Feb 9 00:27:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7455A21F85C3 for ; Thu, 9 Feb 2012 00:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnsQf2QujsmU for ; Thu, 9 Feb 2012 00:27:45 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id CC68D21F85C2 for ; Thu, 9 Feb 2012 00:27:41 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 7D3D270000EA; Thu, 9 Feb 2012 09:27:40 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 494847000072; Thu, 9 Feb 2012 09:27:40 +0100 (CET) X-SFR-UUID: 20120209082740300.494847000072@msfrf2116.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Priority: 3 In-Reply-To: <01bf01cce57a$1a0e0900$4001a8c0@gateway.2wire.net> Date: Thu, 9 Feb 2012 09:27:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <139469BF-BE6E-4939-9550-EFA4FB1F4DA6@laposte.net> References: <01bf01cce57a$1a0e0900$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: v6ops v6ops WG Subject: Re: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 08:27:45 -0000 Le 2012-02-07 =E0 10:23, t.petch a =E9crit : > ----- Original Message ----- > From: "james woodyatt" > To: "Lorenzo Colitti" > Cc: "v6ops v6ops WG" > Sent: Monday, February 06, 2012 7:33 PM >> On Feb 5, 2012, at 23:53 , Lorenzo Colitti wrote: >>>=20 >>> As to which WG it belongs in, I don't know. >>=20 >> I would say that if there is a WG where this belongs, then it would = be BEHAVE > and not V6OPS. I fail to see why this needs a working group to = develop any > further. Wouldn't the individual submission track be more = appropriate? +1=20 > When I have suggested an individual submission, I get told that it = costs the > IETF more, that is that the necessary evils of publishing are = amortised across a > wider spectrum of people when a WG is involved, so unless an AD is = really > burning with desire to support an individual submission, then a WG is = the way to > go. >=20 > V6OPS or BEHAVE? I see the latter as more limited, more focussed in = scope, so > would go for V6OPS. >=20 > Is it worth publishing as an RFC? Yes, the IETF traditionally = neglects > operators, favouring 'manufacturers' so this would help redress the = balance. As individual submission and experimental, yes. For anything else, Softwire would be the place (the overlap with = stateless solutions studied there is obvious). RD >=20 > Tom Petch >=20 >> -- >> j h woodyatt >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Thu Feb 9 00:28:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8D321F85C3 for ; Thu, 9 Feb 2012 00:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_20=-0.74, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSzbZIYytDnc for ; Thu, 9 Feb 2012 00:28:32 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 5276E21F85C2 for ; Thu, 9 Feb 2012 00:28:32 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id ACE9C70000FF; Thu, 9 Feb 2012 09:28:31 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 5F72770000EA; Thu, 9 Feb 2012 09:28:31 +0100 (CET) X-SFR-UUID: 20120209082831391.5F72770000EA@msfrf2116.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-429076760 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 9 Feb 2012 09:28:31 +0100 Message-Id: References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT Trial Deployment Report - 6rd in mobiles? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 08:28:32 -0000 --Apple-Mail-2-429076760 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-02-03 =E0 22:53, Cameron Byrne a =E9crit : > On Feb 3, 2012 12:58 PM, "Behcet Sarikaya" = wrote: >=20 ... > > As you know, many UEs can not connect to an UMTS network on IPv6 due > > to the firmware problem. > > >=20 > Absolutely >=20 Consequence: 6rd would be very useful to permit rapid IPv6-service = availability in mobile networks. (AFAIK it is technically trivial, but does need the will to do it.) Something missing? Regards, RD= --Apple-Mail-2-429076760 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On Feb 3, 2012 12:58 PM, "Behcet Sarikaya" <sarikaya2012@gmail.com>= wrote:

...

> As you know, many UEs can not connect to an UMTS network on IPv6 = due
> to the firmware problem.
>

Absolutely

Consequence: 6rd would be very = useful to permit rapid IPv6-service availability in mobile = networks.
(AFAIK it is technically trivial, but does need the = will to do it.)

Something = missing?

Regards,
RD
= --Apple-Mail-2-429076760-- From lorenzo@google.com Thu Feb 9 01:25:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0CB21F86B7 for ; Thu, 9 Feb 2012 01:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.68 X-Spam-Level: X-Spam-Status: No, score=-101.68 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXZoATmsQfev for ; Thu, 9 Feb 2012 01:25:22 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8EF121F86B1 for ; Thu, 9 Feb 2012 01:25:22 -0800 (PST) Received: by iagf6 with SMTP id f6so2682263iag.31 for ; Thu, 09 Feb 2012 01:25:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=foXKHPrx3LuDKdmXGmafHXaI8VY0+nJ/vLf6S5WS5Iw=; b=f/XwLXF71+j2Ed8hg1yybsJwHzNHrGw8eNMV43eVceHDWEpKjDK1SnnKKJ42373H8T Ms1ABfO4tUZ1n0p7i770ln0ro0lMFZ1/CRAHVL3kCQn1WqeyrobpLRAgnOcTMiKuChXU UrmJrn8G10GGCQbgruPkUTukx/LmGN2CirYdc= Received: by 10.42.177.133 with SMTP id bi5mr1207199icb.40.1328779522310; Thu, 09 Feb 2012 01:25:22 -0800 (PST) Received: by 10.42.177.133 with SMTP id bi5mr1207186icb.40.1328779522214; Thu, 09 Feb 2012 01:25:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.122.218 with HTTP; Thu, 9 Feb 2012 01:25:02 -0800 (PST) In-Reply-To: <4F329696.6000505@bogus.com> References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <8EA035DE-DAB9-4920-9BD6-75944848CA5D@cisco.com> <4F329696.6000505@bogus.com> From: Lorenzo Colitti Date: Thu, 9 Feb 2012 18:25:02 +0900 Message-ID: To: Joel jaeggli Content-Type: multipart/alternative; boundary=90e6ba6e86dc680cfe04b88497ee X-System-Of-Record: true X-Gm-Message-State: ALoCoQlPJ9FOlRXhDqExyIyxqLtVkUasEZ+csY3VBNfnQvobOREo3IUdmATpLs9W1nDKCCRTbLCLtzdvSFXxRq3bTtuqSHDRZkDYE1u4lbQCAnEI35d+uUP78HBXBgzUKSLwQ3RZW6f/ Cc: v6ops v6ops WG , IETF Discussion Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 09:25:23 -0000 --90e6ba6e86dc680cfe04b88497ee Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 9, 2012 at 00:36, Joel jaeggli wrote: > Ops is not marketing. > And if I were looking for a marketing venue, a standards body that produces ASCII text documents read by a handful of engineers would not be high on my list. This is not about marketing. > If you're saying some flag day makes the contents of the document no > longer operationally relevant after a given date, I'll take the point > but disagree. > I think you're missing my point. It seems to me that approximately 30% of the non-biolerplate text in this draft discusses DNS whitelisting. (And in fact, in its original form the draft entirely on DNS whitelisting - hence the filename. The rest was added later.) Whitelisting is a practice relevant to a few large websites (since nobody else is using it). It so happens that the websites that employ this practice are going to stop using it, all together. Given the cost and implications, I'd say practice is unlikely to be resurrected. So, you decide to tell the whole story, and talk about whitelisting *and* World IPv6 Launch. Or you can decide that whitelisting will soon be irrelevant, and not talk about either whitelisting or World IPv6 Launch. But you can't talk about whitelisting without talking about World IPv6 Launch, because if you do, your document is missing the key piece "how do you remove the whitelist", and that's a disservice to its readers. To be more specific, at least section 5.5 ("it is unclear how implementers will judge when the network conditions will have changed sufficiently to justify turning off DNS Resolver Whitelisting and/or what the process and timing will be for discontinuing this practice") is now incorrect. It *is* clear, and it's what those implementers are doing as part of World IPv6 Launch. Does that make more sense? Cheers, Lorenzo --90e6ba6e86dc680cfe04b88497ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 9, 2012 at 00:36, Joel jaeggli <joelja@bogus.com&g= t; wrote:
Ops is not marketing.

And if I were looking for a marketing venue, a standards body that produ= ces ASCII text documents read by a handful of=A0engineers would not be high= on my list. This is not about marketing.
=A0
If you're saying some flag= day makes the contents of the document no
longer operationally relevant after a given date, I'll take the point but disagree.

I think you're missin= g my point.

It seems to me that approximately 30% = of the non-biolerplate text in this draft discusses DNS whitelisting. (And = in fact, in its original form the draft entirely on DNS whitelisting - henc= e the filename. The rest was added later.)

Whitelisting is a practice relevant to a few large webs= ites (since nobody else is using it). It so happens that the websites that = employ this practice are going to stop using it, all together. Given the co= st and implications, I'd say practice is unlikely to be resurrected.

So, you decide to tell the whole story, and talk about = whitelisting *and* World IPv6 Launch. Or=A0you can decide that whitelisting= will soon be irrelevant, and not talk about either whitelisting or World I= Pv6 Launch.=A0But you can't talk about whitelisting without talking abo= ut World IPv6 Launch, because if you do, your document is missing the key p= iece "how do you remove the whitelist", and that's a disservi= ce to its readers.

To be more specific, at least section 5.5 ("it is = unclear how=A0implementers will judge when the network conditions will have= changed=A0sufficiently to justify turning off DNS Resolver Whitelisting an= d/or=A0what the process and timing will be for discontinuing this practice&= quot;) is now incorrect. It *is* clear, and it's what those implementer= s are doing as part of World IPv6 Launch.

Does that make more sense?

Che= ers,
Lorenzo
--90e6ba6e86dc680cfe04b88497ee-- From sarikaya2012@gmail.com Thu Feb 9 01:59:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6010821F86C5 for ; Thu, 9 Feb 2012 01:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.353 X-Spam-Level: X-Spam-Status: No, score=-3.353 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCV8JKQJuoOi for ; Thu, 9 Feb 2012 01:59:45 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D8D4C21F86C4 for ; Thu, 9 Feb 2012 01:59:44 -0800 (PST) Received: by yhkk25 with SMTP id k25so833551yhk.31 for ; Thu, 09 Feb 2012 01:59:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=g4ali3JHOGxXYZZkLKzE8iYWaHSbW0VkspSPdsWZ2Yc=; b=ZArrrOicEI0DnRIizjD9m16fbRAMYIPo0B61CwlvdE/FkJ3Zy6qj3aN17dEu7be8aG RrFjotsnCjXKNKKwEJ/ceBegytJdFWa82jhTX55jYcbqX3htK7WQ1UnQuK68QayDkmCj yjKcgw0aD/3ygySRXF86l+dwu4k624LfxCexE= MIME-Version: 1.0 Received: by 10.236.170.168 with SMTP id p28mr1098682yhl.72.1328781584487; Thu, 09 Feb 2012 01:59:44 -0800 (PST) Received: by 10.236.9.73 with HTTP; Thu, 9 Feb 2012 01:59:44 -0800 (PST) In-Reply-To: References: Date: Thu, 9 Feb 2012 03:59:44 -0600 Message-ID: From: Behcet Sarikaya To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT Trial Deployment Report - 6rd in mobiles? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 09:59:45 -0000 On Thu, Feb 9, 2012 at 2:28 AM, R=E9mi Despr=E9s = wrote: > > Le 2012-02-03 =E0 22:53, Cameron Byrne a =E9crit : > > On Feb 3, 2012 12:58 PM, "Behcet Sarikaya" wrote= : > > ... > >> As you know, many UEs can not connect to an UMTS network on IPv6 due >> to the firmware problem. >> > > Absolutely > > Consequence: 6rd would be very useful to permit rapid IPv6-service > availability in mobile networks. > (AFAIK it is technically trivial, but does need the will to do it.) > Maybe so (although many people doubt it). The point in draft-mawatari is IPv6-only network, in 6rd that is not the case. This effort needs some encouragement from the community, let's do so :-). Cheers, Behcet From despres.remi@laposte.net Thu Feb 9 02:06:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EAC21F8666 for ; Thu, 9 Feb 2012 02:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQIRfSPXnwsE for ; Thu, 9 Feb 2012 02:06:22 -0800 (PST) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.119]) by ietfa.amsl.com (Postfix) with ESMTP id 99E9221F8663 for ; Thu, 9 Feb 2012 02:06:22 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2507.sfr.fr (SMTP Server) with ESMTP id 3C8987000117; Thu, 9 Feb 2012 11:06:21 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2507.sfr.fr (SMTP Server) with ESMTP id D016D7000104; Thu, 9 Feb 2012 11:06:20 +0100 (CET) X-SFR-UUID: 20120209100620852.D016D7000104@msfrf2507.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 9 Feb 2012 11:06:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8C8156E6-DDC8-4B11-BCA9-01753877DAD3@laposte.net> References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT Trial Deployment Report - 6rd in mobiles? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 10:06:23 -0000 Le 2012-02-09 =E0 10:59, Behcet Sarikaya a =E9crit : > On Thu, Feb 9, 2012 at 2:28 AM, R=E9mi Despr=E9s = wrote: >>=20 >> Le 2012-02-03 =E0 22:53, Cameron Byrne a =E9crit : >>=20 >> On Feb 3, 2012 12:58 PM, "Behcet Sarikaya" = wrote: >>=20 >> ... >>=20 >>> As you know, many UEs can not connect to an UMTS network on IPv6 due >>> to the firmware problem. >>>=20 >>=20 >> Absolutely >>=20 >> Consequence: 6rd would be very useful to permit rapid IPv6-service >> availability in mobile networks. >> (AFAIK it is technically trivial, but does need the will to do it.) >>=20 >=20 >=20 > Maybe so (although many people doubt it). The point in draft-mawatari > is IPv6-only network, in 6rd that is not the case. Indeed different problems have different solutions. But my point is only about IPv6 Rapid Deployment, without being blocked = by lack of knowledge or lack of will. Where the firmware is hard to change (an only there) IPv6 can very = easily be offered.=20 The advice is then "just do it, it's so easy". Nothing more. Cheers, RD , >=20 > This effort needs some encouragement from the community, let's do so = :-). >=20 > Cheers, >=20 > Behcet From Carl.Wuyts@technicolor.com Thu Feb 9 05:25:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A583821F8729 for ; Thu, 9 Feb 2012 05:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.148 X-Spam-Level: X-Spam-Status: No, score=-5.148 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l95LLE+Gipdn for ; Thu, 9 Feb 2012 05:25:02 -0800 (PST) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id 61FC821F8700 for ; Thu, 9 Feb 2012 05:25:01 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTzPJLJ/11pqfEZfBaUebQNvncBroLuMK@postini.com; Thu, 09 Feb 2012 05:25:01 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 9 Feb 2012 14:18:53 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.201]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Thu, 9 Feb 2012 14:18:59 +0100 From: Wuyts Carl To: "v6ops@ietf.org" Date: Thu, 9 Feb 2012 14:18:57 +0100 Thread-Topic: RFC6204-05: minor adjustment needed Thread-Index: AcznLWDTShHdv7DzQ1KmGaz4dca5NQ== Message-ID: <867F4B6A1672E541A94676D556793ACD0E9AD9CB12@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0E9AD9CB12MOPESMBX01eut_" MIME-Version: 1.0 Subject: [v6ops] RFC6204-05: minor adjustment needed X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 13:25:02 -0000 --_000_867F4B6A1672E541A94676D556793ACD0E9AD9CB12MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I think a small update is needed for: G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node Requirements [RFC4294] specification. As rfc4294 is being obsolete by RFC6434 Regs Carl --_000_867F4B6A1672E541A94676D556793ACD0E9AD9CB12MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I thin= k a small update is needed for:

G-1:  An IPv6 CE ro= uter is an IPv6 node according to the IPv6 Node

&= nbsp;        Requirements [RFC4294] spec= ification.

As rfc4294 is being ob= solete by RFC6434

 

<= p class=3DMsoNormal>Regs

Carl=

= --_000_867F4B6A1672E541A94676D556793ACD0E9AD9CB12MOPESMBX01eut_-- From cb.list6@gmail.com Thu Feb 9 05:33:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C6521F8712 for ; Thu, 9 Feb 2012 05:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PunSlo16Wcx4 for ; Thu, 9 Feb 2012 05:33:36 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8D94F21F8722 for ; Thu, 9 Feb 2012 05:33:15 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so1610350pbc.31 for ; Thu, 09 Feb 2012 05:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z0nsx4vnXSKUnsh+kPCsjWhMyv2K7RsMbHVGfGy7zXE=; b=vD0t2XBuaEwSEBSgf84RLgEffxadElTMfehC6pvmA/7lSqxn0oaCMvJ4ySkq11KiRQ hcxWQISzX+w60P60MMfoAMpc3CXYiqrR7RaLe5YzjDOBEKukkmj0WDeDbkHeh/3qVwgb cDl6en0BVtfBzuvW45WB0DGuOq41nFKo1z2r0= MIME-Version: 1.0 Received: by 10.68.73.105 with SMTP id k9mr5835288pbv.121.1328794395405; Thu, 09 Feb 2012 05:33:15 -0800 (PST) Received: by 10.143.164.16 with HTTP; Thu, 9 Feb 2012 05:33:15 -0800 (PST) Received: by 10.143.164.16 with HTTP; Thu, 9 Feb 2012 05:33:15 -0800 (PST) In-Reply-To: References: Date: Thu, 9 Feb 2012 05:33:15 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d04190db4eaede204b8880db7 Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT Trial Deployment Report - 6rd in mobiles? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 13:33:37 -0000 --f46d04190db4eaede204b8880db7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Feb 9, 2012 12:17 AM, "R=E9mi Despr=E9s" wrote: > > > Le 2012-02-03 =E0 22:53, Cameron Byrne a =E9crit : >> >> On Feb 3, 2012 12:58 PM, "Behcet Sarikaya" wrote: > > ... >> >> > As you know, many UEs can not connect to an UMTS network on IPv6 due >> > to the firmware problem. >> > >> >> Absolutely > > Consequence: 6rd would be very useful to permit rapid IPv6-service availability in mobile networks. > (AFAIK it is technically trivial, but does need the will to do it.) > > Something missing? > Yes, mobile operator network operator support is missing Cb > Regards, > RD --f46d04190db4eaede204b8880db7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 9, 2012 12:17 AM, "R=E9mi Despr=E9s" <remi.despres@free.fr> wrote:
>
>
> Le 2012-02-03 =E0 22:53, Cameron Byrne a =E9crit :
>>
>> On Feb 3, 2012 12:58 PM, "Behcet Sarikaya" <sarikaya2012@gmail.com> wrote: >
> ...
>>
>> > As you know, many UEs can not connect to an UMTS network on I= Pv6 due
>> > to the firmware problem.
>> >
>>
>> Absolutely
>
> Consequence: 6rd would be very useful to permit rapid IPv6-service ava= ilability in mobile networks.
> (AFAIK it is technically trivial, but does need the will to do it.) >
> Something missing?
>

Yes, mobile operator network operator=A0 support is missing

Cb

> Regards,
> RD

--f46d04190db4eaede204b8880db7-- From dunbar.ll@gmail.com Thu Feb 9 15:26:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361E221E8062; Thu, 9 Feb 2012 15:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-JVhXOiHDpN; Thu, 9 Feb 2012 15:26:15 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09F9E21E805E; Thu, 9 Feb 2012 15:26:14 -0800 (PST) Received: by bkuw12 with SMTP id w12so2299657bku.31 for ; Thu, 09 Feb 2012 15:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v3RChyv2tECrWeNW6pB/62ecQRxA/q/kGGByju1608I=; b=BnUY4gqnFvtcglnuk5GUZ2L+LnmbeJkpV7dzcd0rNKThlkSntC5M0oQrc1WSo1lVda Az83wFnyOlytOkvj+2+iNpCHbvOIZxVoOky6GF3gWwhDo27iu6bexhblI7maGtaHTm41 jgpdR/CTa34pJ+mVI76cpfmyBBRln9DsadgYk= MIME-Version: 1.0 Received: by 10.204.150.69 with SMTP id x5mr1536581bkv.53.1328829974062; Thu, 09 Feb 2012 15:26:14 -0800 (PST) Received: by 10.204.62.199 with HTTP; Thu, 9 Feb 2012 15:26:14 -0800 (PST) In-Reply-To: <4F320549.20100@cisco.com> References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com> <4F320549.20100@cisco.com> Date: Thu, 9 Feb 2012 17:26:14 -0600 Message-ID: From: Linda Dunbar To: Shishio Tsuchiya Content-Type: multipart/alternative; boundary=0015175cdafa9227df04b8905671 X-Mailman-Approved-At: Thu, 09 Feb 2012 17:30:47 -0800 Cc: softwires@ietf.org, v6ops@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org, armd@ietf.org Subject: Re: [v6ops] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 23:26:18 -0000 --0015175cdafa9227df04b8905671 Content-Type: text/plain; charset=ISO-8859-1 Shishio, Thank you very much for sharing the v6 deployment in data center. I am not an IPv6 expert. So I have a simple question: when you say "server-based 6rd", do you mean that server does the IPv4 encapsulation? Does your data center allow hosts/servers under one IPv6 subnet (e.g. /64) to be placed under different server racks? Thanks, Linda Dunbar On Tue, Feb 7, 2012 at 11:16 PM, Shishio Tsuchiya wrote: > v6ops and ARMD > Sakura internet are providing IPv6 service without scalability impact to > core network equipment to customer using 6rd. > We thought this is interesting idea,so published the draft. > > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 > > I think both of mailing list participants are also interesting in this > technique. > If you have any comment and question of the draft,please let me know. > > Regards, > -Shishio > -------- Original Message -------- > Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt > Date: Mon, 14 Nov 2011 17:21:26 +0800 > From: > Reply-To: > To: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : IPv6 Rapid Deployment (6rd) in a Large Data Center > Author(s) : Shishio Tsuchiya > Mark Townsley > Shuichi Ohkubo > Filename : draft-sakura-6rd-datacenter-03.txt > Pages : 15 > Date : 2011-11-14 > > IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid > deployment of IPv6 by an access service provider which has difficulty > deploying native IPv6. This document describes how 6rd can be used > to deliver IPv6 within a Large Data Center. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt > _______________________________________________ > 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 > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > --0015175cdafa9227df04b8905671 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Shishio,

Thank you very much for sharing the v6 deployment in data = center.

I am not an IPv6 expert. So I have a simple question: when = you say "server-based 6rd", do you mean that server does the IPv4= encapsulation?


Does your data center allow hosts/servers under one IPv6 subnet (e.= g. /64) to be placed under different server racks?

Thanks, Linda Dun= bar





On Tue, Feb 7, 2012 a= t 11:16 PM, Shishio Tsuchiya <shtsuchi@cisco.com> wrote:
v6ops and ARMD
Sakura internet are providing IPv6 service without scalability impact to co= re network equipment to customer using 6rd.
We thought this is interesting idea,so published the draft.

http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03<= br>
I think both of mailing list participants are also interesting in this tech= nique.
If you have any comment and question of the draft,please let me know.

Regards,
-Shishio
-------- Original Message --------
Subject: =A0 =A0 =A0 =A0I-D Action: draft-sakura-6rd-datacenter-03.txt
Date: =A0 Mon, 14 Nov 2011 17:21:26 +0800
From: =A0 <internet-drafts@ietf.org>
Reply-To: =A0 =A0 =A0 <internet-drafts@ietf.org>
To: =A0 =A0 <= i-d-announce@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

Title : IPv6 Rapid Deployment (6rd) in a Large Data Center
Author(s) : Shishio Tsuchiya
Mark Townsley
Shuichi Ohkubo
Filename : draft-sakura-6rd-datacenter-03.txt
Pages : 15
Date : 2011-11-14

IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid
deployment of IPv6 by an access service provider which has difficulty
deploying native IPv6. This document describes how 6rd can be used
to deliver IPv6 within a Large Data Center.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sakura-= 6rd-datacenter-03.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-sakura-6r= d-datacenter-03.txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.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


_______________________________________________
armd mailing list
armd@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/armd

--0015175cdafa9227df04b8905671-- From Tina.Tsou.Zouting@huawei.com Thu Feb 9 18:13:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BF711E8075; Thu, 9 Feb 2012 18:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.564 X-Spam-Level: X-Spam-Status: No, score=-5.564 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj-Kl-OykHk2; Thu, 9 Feb 2012 18:13:35 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E335311E8076; Thu, 9 Feb 2012 18:13:33 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ5004XFNEIU7@szxga03-in.huawei.com>; Fri, 10 Feb 2012 10:11:06 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ500L5CNEFPJ@szxga03-in.huawei.com>; Fri, 10 Feb 2012 10:11:06 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGZ93690; Fri, 10 Feb 2012 10:11:05 +0800 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 10 Feb 2012 10:10:22 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Fri, 10 Feb 2012 10:11:15 +0800 Date: Fri, 10 Feb 2012 02:10:47 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.212.244.142] To: Linda Dunbar , Shishio Tsuchiya Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_jV0Jsk21GpYdhx328yWtcQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [v6ops] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt Thread-index: AQHM55OqKuMa1bvJ8kCzdvdIpYIP2ZY1Yw1A X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com> <4F320549.20100@cisco.com> Cc: "softwires@ietf.org" , "v6ops@ietf.org" , "armd@ietf.org" , "draft-sakura-6rd-datacenter@tools.ietf.org" Subject: Re: [v6ops] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 02:13:36 -0000 --Boundary_(ID_jV0Jsk21GpYdhx328yWtcQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Tina From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, February 09, 2012 3:26 PM To: Shishio Tsuchiya Cc: softwires@ietf.org; v6ops@ietf.org; draft-sakura-6rd-datacenter@tools.ietf.org; armd@ietf.org Subject: Re: [v6ops] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt Shishio, Thank you very much for sharing the v6 deployment in data center. I am not an IPv6 expert. So I have a simple question: when you say "server-based 6rd", do you mean that server does the IPv4 encapsulation? Does your data center allow hosts/servers under one IPv6 subnet (e.g. /64) to be placed under different server racks? [Tina] In my case, yes. Thanks, Linda Dunbar On Tue, Feb 7, 2012 at 11:16 PM, Shishio Tsuchiya > wrote: v6ops and ARMD Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd. We thought this is interesting idea,so published the draft. http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 I think both of mailing list participants are also interesting in this technique. If you have any comment and question of the draft,please let me know. Regards, -Shishio -------- Original Message -------- Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt Date: Mon, 14 Nov 2011 17:21:26 +0800 From: > Reply-To: > To: > A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Rapid Deployment (6rd) in a Large Data Center Author(s) : Shishio Tsuchiya Mark Townsley Shuichi Ohkubo Filename : draft-sakura-6rd-datacenter-03.txt Pages : 15 Date : 2011-11-14 IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid deployment of IPv6 by an access service provider which has difficulty deploying native IPv6. This document describes how 6rd can be used to deliver IPv6 within a Large Data Center. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt _______________________________________________ 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 _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd --Boundary_(ID_jV0Jsk21GpYdhx328yWtcQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

 

Tina

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: Thursday, February 09, 2012 3:26 PM
To: Shishio Tsuchiya
Cc: softwires@ietf.org; v6ops@ietf.org; draft-sakura-6rd-datacenter@tools.ietf.org; armd@ietf.org
Subject: Re: [v6ops] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt

 

Shishio,

Thank you very much for sharing the v6 deployment in data center.

I am not an IPv6 expert. So I have a simple question: when you say "server-based 6rd", do you mean that server does the IPv4 encapsulation?


Does your data center allow hosts/servers under one IPv6 subnet (e.g. /64) to be placed under different server racks?

[Tina] In my case, yes.



Thanks, Linda Dunbar




On Tue, Feb 7, 2012 at 11:16 PM, Shishio Tsuchiya <shtsuchi@cisco.com> wrote:

v6ops and ARMD
Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd.
We thought this is interesting idea,so published the draft.

http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03

I think both of mailing list participants are also interesting in this technique.
If you have any comment and question of the draft,please let me know.

Regards,
-Shishio
-------- Original Message --------
Subject:        I-D Action: draft-sakura-6rd-datacenter-03.txt
Date:   Mon, 14 Nov 2011 17:21:26 +0800
From:   <internet-drafts@ietf.org>
Reply-To:       <internet-drafts@ietf.org>
To:     <i-d-announce@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : IPv6 Rapid Deployment (6rd) in a Large Data Center
Author(s) : Shishio Tsuchiya
Mark Townsley
Shuichi Ohkubo
Filename : draft-sakura-6rd-datacenter-03.txt
Pages : 15
Date : 2011-11-14

IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid
deployment of IPv6 by an access service provider which has difficulty
deploying native IPv6. This document describes how 6rd can be used
to deliver IPv6 within a Large Data Center.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt
_______________________________________________
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


_______________________________________________
armd mailing list
armd@ietf.org
https://www.ietf.org/mailman/listinfo/armd

 

--Boundary_(ID_jV0Jsk21GpYdhx328yWtcQ)-- From mawatari@jpix.ad.jp Thu Feb 9 20:29:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09A111E80A1 for ; Thu, 9 Feb 2012 20:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gvglq5Ojay1h for ; Thu, 9 Feb 2012 20:29:47 -0800 (PST) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 309FB11E8087 for ; Thu, 9 Feb 2012 20:29:46 -0800 (PST) Received: from [192.168.0.230] (v4pool2.ip64es.jpix.ad.jp [202.90.12.2]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 99F93FC021; Fri, 10 Feb 2012 13:29:45 +0900 (JST) Date: Fri, 10 Feb 2012 13:29:44 +0900 From: MAWATARI Masataka To: washam.fan@gmail.com In-Reply-To: References: Message-Id: <20120210132943.276A.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.03 [ja] Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on 464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 04:29:47 -0000 Dear Washam-san, Thank you for your comments and sorry for delay. > 1. section 7.4 mentioned DNS proxy for both IPv4 and IPv6 hosts, i > don't know why DNS proxy for IPv6 hosts is needed. The 464XLAT does not require DNS Proxy for both IPv4 and IPv6 hosts. IPv6 host may directly query an IPv6 DNS server. IPv4 host may also directly query an IPv4 DNS server through 464XLAT translation. DNS Proxy is useful function for IPv4 host so the host can not easily discover an IPv4 DNS server address. > 2. I think the author should elaborate on what the configuration > function is like in section 7.6 I do not know where your consideraton about this configuration function is. Could you please specifically indicate about your consideraton? I think we can make a appropriate document by yours. > 3. i don't know what is the meaning for the text under section 7.5. I > think NDP should always perform while SLAAC perform only if the prefix > equals to 64. If CLAT gets a single /64 prefix from WAN interface, it has to perform ND for 464XLAT IPv6 addresses(It means that IPv4 host under CLAT), and it has to perform ND-Proxy for IPv6 host under CLAT. > 4. I don't know if the draft should cover the host1-CLAT1-CLAT2-host2 > communication case. This 464XLAT architecture is hub and spoke model. Kind Regards, Masataka MAWATARI * On Tue, 7 Feb 2012 14:01:19 +0800 * Washam Fan wrote: > Hi, > > I generally support this work. But have several comments below. > > 1. section 7.4 mentioned DNS proxy for both IPv4 and IPv6 hosts, i > don't know why DNS proxy for IPv6 hosts is needed. > > 2. I think the author should elaborate on what the configuration > function is like in section 7.6 > > 3. i don't know what is the meaning for the text under section 7.5. I > think NDP should always perform while SLAAC perform only if the prefix > equals to 64. > > 4. I don't know if the draft should cover the host1-CLAT1-CLAT2-host2 > communication case. > > Thanks, > washam From shtsuchi@cisco.com Thu Feb 9 20:44:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFEF21F85DB; Thu, 9 Feb 2012 20:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=-4.336, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TECnOlY6X4y; Thu, 9 Feb 2012 20:44:36 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 51BDD21F85D8; Thu, 9 Feb 2012 20:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=4214; q=dns/txt; s=iport; t=1328849073; x=1330058673; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=9Q7NnMHNjXBGTghYArNDL/ysh93IonMuhYwPRjMb2CI=; b=gyLg8esOZNjj4eszpun97L2pwrJUFO8iz4eBNMFa7dJOg/b1fItWyY9L JolTPmX3cKxLbBnGa09/fzawzjy4HYYIw65/rJ7HJ79XpEQ2LKRQWUh85 +QHeBsCDjmPdFynvCxf4PbJcQcanyjwSSwYxyfSQ/jBmnRcdAPnRTx/CH g=; X-IronPort-AV: E=Sophos;i="4.73,394,1325462400"; d="scan'208";a="5237742" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 10 Feb 2012 04:44:30 +0000 Received: from [64.104.53.150] (dhcp-tmt-wirelessdata-64-104-53-150.cisco.com [64.104.53.150]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1A4iT3b019125; Fri, 10 Feb 2012 04:44:29 GMT Message-ID: <4F34A0AD.4040300@cisco.com> Date: Fri, 10 Feb 2012 13:44:29 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: dunbar.ll@gmail.com References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com><4F320549.20100@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, v6ops@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org, armd@ietf.org Subject: Re: [v6ops] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 04:44:37 -0000 Linda Thanks for comments. (2012/02/10 8:26), Linda Dunbar wrote: > Shishio, > > Thank you very much for sharing the v6 deployment in data center. > > I am not an IPv6 expert. So I have a simple question: when you say "server-based 6rd", do you mean that server does the IPv4 encapsulation? Yes. 6rd is IPv6 over IPv4 tunnel technology. So backbone operator does not need to care to IPv6 on the core. Additionally 6rd has stateless feature. Once the operator has placed/configured 6rd BR on the exit point to the IPv6 internet,does not need additional operation to add 6rd CE(server based 6rd). And if the server would like to go to the IPv6 internet,then IPv4 packets will through 6rd BR and de-capsulate. If the server would like to communicate other 6rd server within the data center,then IPv4 packets will reach 6rd server directly and de-capsulate. > > > Does your data center allow hosts/servers under one IPv6 subnet (e.g. /64) to be placed under different server racks? In Sakura internet 6rd cases,each of 6rd server has one 6rd delegate prefix(/64). http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03#section-4.1 The 6rd delegate prefix calculates from Sakura's IPv6 prefix(/32) and IPv4 address. Sakura has the scalability problem which is same as ARMD draft. http://tools.ietf.org/html/draft-ietf-armd-problem-statement-00 They also had to update switches to resolve security issue(Rogue RA). http://tools.ietf.org/html/rfc6104 They selected "server-based 6rd" as the solution to avoid scalability and security problem. Regards, -Shishio > > Thanks, Linda Dunbar > > > > > > On Tue, Feb 7, 2012 at 11:16 PM, Shishio Tsuchiya > wrote: > > v6ops and ARMD > Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd. > We thought this is interesting idea,so published the draft. > > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 > > I think both of mailing list participants are also interesting in this technique. > If you have any comment and question of the draft,please let me know. > > Regards, > -Shishio > -------- Original Message -------- > Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt > Date: Mon, 14 Nov 2011 17:21:26 +0800 > From: > > Reply-To: > > To: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : IPv6 Rapid Deployment (6rd) in a Large Data Center > Author(s) : Shishio Tsuchiya > Mark Townsley > Shuichi Ohkubo > Filename : draft-sakura-6rd-datacenter-03.txt > Pages : 15 > Date : 2011-11-14 > > IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid > deployment of IPv6 by an access service provider which has difficulty > deploying native IPv6. This document describes how 6rd can be used > to deliver IPv6 within a Large Data Center. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt > _______________________________________________ > 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 > > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > From washam.fan@gmail.com Thu Feb 9 21:18:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D089921F84DC for ; Thu, 9 Feb 2012 21:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ltx8jEc7ldNr for ; Thu, 9 Feb 2012 21:18:11 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9B511E8081 for ; Thu, 9 Feb 2012 21:18:01 -0800 (PST) Received: by wibhm9 with SMTP id hm9so2237631wib.31 for ; Thu, 09 Feb 2012 21:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m0+5XwOkxLfKoUTffLu+STmHDobYCMV6FrYvXUGLoYY=; b=okrJ+mvYXYb63uBRZny92QmGuZbHG74NTVFHsj/2GxK/gIutxKWfXtYWMCc+DPrNmf INZwVVv4i9U4qOSCLB9PYUXEMfooDzmtAE+YxhWRauxj6RX4fBa8EUgOT+3xYpe3LLSm wry5Nhu0N0ryvgRiNy5/5msQ9whNv9VJNU4+U= MIME-Version: 1.0 Received: by 10.180.100.228 with SMTP id fb4mr7033525wib.1.1328851081119; Thu, 09 Feb 2012 21:18:01 -0800 (PST) Received: by 10.216.1.6 with HTTP; Thu, 9 Feb 2012 21:18:00 -0800 (PST) In-Reply-To: <20120210132943.276A.8FE1F57E@jpix.ad.jp> References: <20120210132943.276A.8FE1F57E@jpix.ad.jp> Date: Fri, 10 Feb 2012 13:18:00 +0800 Message-ID: From: Washam Fan To: MAWATARI Masataka Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on 464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 05:18:11 -0000 Hi, >> 1. section 7.4 mentioned DNS proxy for both IPv4 and IPv6 hosts, i >> don't know why DNS proxy for IPv6 hosts is needed. > > > The 464XLAT does not require DNS Proxy for both IPv4 and IPv6 hosts. > IPv6 host may directly query an IPv6 DNS server. IPv4 host may also > directly query an IPv4 DNS server through 464XLAT translation. > DNS Proxy is useful function for IPv4 host so the host can not easily > discover an IPv4 DNS server address. Got it. But it seemed to me that such DNS Proxy is required when I read section 7.4. >> 2. I think the author should elaborate on what the configuration >> function is like in section 7.6 > > > I do not know where your consideraton about this configuration > function is. > Could you please specifically indicate about your consideraton? > I think we can make a appropriate document by yours. > i was referring to the configuration function which allows the PLAT and CLAT not to include the Fragment Header. >> 3. i don't know what is the meaning for the text under section 7.5. I >> think NDP should always perform while SLAAC perform only if the prefix >> equals to 64. > > > If CLAT gets a single /64 prefix from WAN interface, it has to perform > ND for 464XLAT IPv6 addresses(It means that IPv4 host under CLAT), > and it has to perform ND-Proxy for IPv6 host under CLAT. > Do you mean ND for the translated ipv6 addresses where ipv4 addresses assigned to the hosts under CLAT are embeded? If yes, then i think you need to clarify in this section because this section is too vague. My point was ND can perform even the prefix != 64, cant it? And when you say ND, are you referring to DAD or full functionality of ND? >> 4. I don't know if the draft should cover the host1-CLAT1-CLAT2-host2 >> communication case. > > > This 464XLAT architecture is hub and spoke model. > Would you mind clarify this scope in somewhere in the draft? Thanks, washam From washam.fan@gmail.com Thu Feb 9 21:21:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5300D21F84FE for ; Thu, 9 Feb 2012 21:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uNXU6OSjfWS for ; Thu, 9 Feb 2012 21:21:37 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFD9821F84FD for ; Thu, 9 Feb 2012 21:21:34 -0800 (PST) Received: by wibhm9 with SMTP id hm9so2239035wib.31 for ; Thu, 09 Feb 2012 21:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m0+5XwOkxLfKoUTffLu+STmHDobYCMV6FrYvXUGLoYY=; b=KubVhbdiA7DEjboUn5E/MfCoJUaipIQcLQjMGcjAggrVaH3C3NZK0P0lgrOQYstScn HegM4wx7Xk0Nw6BpgVHZ3N2dzF2mVbh8m/R9s5LBRcvAz7ymU26n09jQhaX3f0sW7h1y 6WWcrwJCVYcBHR50FTTjxDQmTsSvMMujVNmIY= MIME-Version: 1.0 Received: by 10.216.133.204 with SMTP id q54mr231643wei.2.1328851293959; Thu, 09 Feb 2012 21:21:33 -0800 (PST) Received: by 10.216.1.6 with HTTP; Thu, 9 Feb 2012 21:21:33 -0800 (PST) In-Reply-To: <20120210132943.276A.8FE1F57E@jpix.ad.jp> References: <20120210132943.276A.8FE1F57E@jpix.ad.jp> Date: Fri, 10 Feb 2012 13:21:33 +0800 Message-ID: From: Washam Fan To: MAWATARI Masataka Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on 464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 05:21:37 -0000 Hi, >> 1. section 7.4 mentioned DNS proxy for both IPv4 and IPv6 hosts, i >> don't know why DNS proxy for IPv6 hosts is needed. > > > The 464XLAT does not require DNS Proxy for both IPv4 and IPv6 hosts. > IPv6 host may directly query an IPv6 DNS server. IPv4 host may also > directly query an IPv4 DNS server through 464XLAT translation. > DNS Proxy is useful function for IPv4 host so the host can not easily > discover an IPv4 DNS server address. Got it. But it seemed to me that such DNS Proxy is required when I read section 7.4. >> 2. I think the author should elaborate on what the configuration >> function is like in section 7.6 > > > I do not know where your consideraton about this configuration > function is. > Could you please specifically indicate about your consideraton? > I think we can make a appropriate document by yours. > i was referring to the configuration function which allows the PLAT and CLAT not to include the Fragment Header. >> 3. i don't know what is the meaning for the text under section 7.5. I >> think NDP should always perform while SLAAC perform only if the prefix >> equals to 64. > > > If CLAT gets a single /64 prefix from WAN interface, it has to perform > ND for 464XLAT IPv6 addresses(It means that IPv4 host under CLAT), > and it has to perform ND-Proxy for IPv6 host under CLAT. > Do you mean ND for the translated ipv6 addresses where ipv4 addresses assigned to the hosts under CLAT are embeded? If yes, then i think you need to clarify in this section because this section is too vague. My point was ND can perform even the prefix != 64, cant it? And when you say ND, are you referring to DAD or full functionality of ND? >> 4. I don't know if the draft should cover the host1-CLAT1-CLAT2-host2 >> communication case. > > > This 464XLAT architecture is hub and spoke model. > Would you mind clarify this scope in somewhere in the draft? Thanks, washam From kawashimam@vx.jp.nec.com Fri Feb 10 02:04:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13F221F876D for ; Fri, 10 Feb 2012 02:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.41 X-Spam-Level: X-Spam-Status: No, score=0.41 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4RimnmxQaPk for ; Fri, 10 Feb 2012 02:03:59 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id 81DAE21F876E for ; Fri, 10 Feb 2012 02:03:59 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q1AA3uaq016577; Fri, 10 Feb 2012 19:03:56 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q1AA3uK14652; Fri, 10 Feb 2012 19:03:56 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id q1AA3uaY009054; Fri, 10 Feb 2012 19:03:56 +0900 (JST) Received: from shoin.jp.nec.com ([10.26.220.3] [10.26.220.3]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-847871; Fri, 10 Feb 2012 19:02:36 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Fri, 10 Feb 2012 19:02:35 +0900 To: Washam Fan In-reply-to: References: Message-Id: <20120210190234kawashimam@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Fri, 10 Feb 2012 19:02:32 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on 464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 10:04:00 -0000 Hi Washam, Thank you for your useful comments. Please see inline. >> The 464XLAT does not require DNS Proxy for both IPv4 and IPv6 hosts. >> IPv6 host may directly query an IPv6 DNS server. IPv4 host may also >> directly query an IPv4 DNS server through 464XLAT translation. >> DNS Proxy is useful function for IPv4 host so the host can not easily >> discover an IPv4 DNS server address. > >Got it. But it seemed to me that such DNS Proxy is required when I >read section 7.4. I'm sorry for confusing you. I took similar question from Brian a few weeks ago. We will add some clarifying language in the next version. http://www.ietf.org/mail-archive/web/v6ops/current/msg11853.html >i was referring to the configuration function which allows the PLAT >and CLAT not to include the Fragment Header. The function provide a configuration function to adjust minimum IPv6 MTU, or can configure whether it include the Fragment Header. >> If CLAT gets a single /64 prefix from WAN interface, it has to perform >> ND for 464XLAT IPv6 addresses(It means that IPv4 host under CLAT), >> and it has to perform ND-Proxy for IPv6 host under CLAT. > >Do you mean ND for the translated ipv6 addresses where ipv4 addresses >assigned to the hosts under CLAT are embeded? Yes, exactly. >If yes, then i think you need to clarify in this section because this >section is too vague. I agree with you. We will add some clarifying language about this in the next version. >My point was ND can perform even the prefix != 64, cant it? And when >you say ND, are you referring to DAD or full functionality of ND? Would you mind clarifying what you meant by that? If CLAT gets a single /64 prefix from WAN interface, it has to perform full functionality of ND for 464XLAT IPv6 addresses. >> This 464XLAT architecture is hub and spoke model. >> >Would you mind clarify this scope in somewhere in the draft? We will add some language in somewhere in next version. :-) Regards, Masanobu >Hi, > >>> 1. section 7.4 mentioned DNS proxy for both IPv4 and IPv6 hosts, i >>> don't know why DNS proxy for IPv6 hosts is needed. >> >> >> The 464XLAT does not require DNS Proxy for both IPv4 and IPv6 hosts. >> IPv6 host may directly query an IPv6 DNS server. IPv4 host may also >> directly query an IPv4 DNS server through 464XLAT translation. >> DNS Proxy is useful function for IPv4 host so the host can not easily >> discover an IPv4 DNS server address. > >Got it. But it seemed to me that such DNS Proxy is required when I >read section 7.4. > >>> 2. I think the author should elaborate on what the configuration >>> function is like in section 7.6 >> >> >> I do not know where your consideraton about this configuration >> function is. >> Could you please specifically indicate about your consideraton? >> I think we can make a appropriate document by yours. >> >i was referring to the configuration function which allows the PLAT >and CLAT not to include the Fragment Header. > >>> 3. i don't know what is the meaning for the text under section 7.5. I >>> think NDP should always perform while SLAAC perform only if the prefix >>> equals to 64. >> >> >> If CLAT gets a single /64 prefix from WAN interface, it has to perform >> ND for 464XLAT IPv6 addresses(It means that IPv4 host under CLAT), >> and it has to perform ND-Proxy for IPv6 host under CLAT. >> > >Do you mean ND for the translated ipv6 addresses where ipv4 addresses >assigned to the hosts under CLAT are embeded? If yes, then i think you >need to clarify in this section because this section is too vague. > >My point was ND can perform even the prefix != 64, cant it? And when >you say ND, are you referring to DAD or full functionality of ND? > >>> 4. I don't know if the draft should cover the host1-CLAT1-CLAT2-host2 >>> communication case. >> >> >> This 464XLAT architecture is hub and spoke model. >> >Would you mind clarify this scope in somewhere in the draft? > >Thanks, >washam >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From washam.fan@gmail.com Fri Feb 10 07:22:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D6721F841D for ; Fri, 10 Feb 2012 07:22:44 -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=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKB384CAdwG5 for ; Fri, 10 Feb 2012 07:22:43 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF10821F86C2 for ; Fri, 10 Feb 2012 07:22:40 -0800 (PST) Received: by wibhm9 with SMTP id hm9so2676512wib.31 for ; Fri, 10 Feb 2012 07:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r3zm2AxQ19gcCvYcb3UrjhivkNz2BE1T/yLMq4RbVWg=; b=dJ4jJSpBIQQwDR84VC8Xodydj+JRwiUGAf+Gs0RTFZsuJARrrxN0C+KupaOCZcxipC rEDcReQD1jFrFIEPDrA8uTPYr1iqCbiMFtyUi9p0AZ4Cbc8/TRBS8lg3IAFZuvek2Mlo UnPUSlwpk9fk5Ddmssg3vJa3xvxcWJv1PU010= MIME-Version: 1.0 Received: by 10.180.82.227 with SMTP id l3mr9994388wiy.1.1328887347604; Fri, 10 Feb 2012 07:22:27 -0800 (PST) Received: by 10.216.1.6 with HTTP; Fri, 10 Feb 2012 07:22:27 -0800 (PST) In-Reply-To: <20120210190234kawashimam@mail.jp.nec.com> References: <20120210190234kawashimam@mail.jp.nec.com> Date: Fri, 10 Feb 2012 23:22:27 +0800 Message-ID: From: Washam Fan To: Masanobu Kawashima Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on 464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 15:22:44 -0000 Hi, >>My point was ND can perform even the prefix != 64, cant it? And when >>you say ND, are you referring to DAD or full functionality of ND? > > Would you mind clarifying what you meant by that? > If CLAT gets a single /64 prefix from WAN interface, it has to perform > full functionality of ND for 464XLAT IPv6 addresses. Sorry haven't made clearer. If CLAT gets a prefix length longer or shorter than /64, should it perform ND for the IPv6 addresses? And another question, did you mean perform ND at the interface facing the network under CLAT or at the WAN interface? Thanks, washam From kawashimam@vx.jp.nec.com Fri Feb 10 08:18:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B223121F86C8 for ; Fri, 10 Feb 2012 08:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.135 X-Spam-Level: X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am6q3bZoxAKQ for ; Fri, 10 Feb 2012 08:18:41 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id 47AE321F8589 for ; Fri, 10 Feb 2012 08:18:40 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q1AGIcmM008896; Sat, 11 Feb 2012 01:18:38 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q1AGIcC16917; Sat, 11 Feb 2012 01:18:38 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id q1AGIbo0004450; Sat, 11 Feb 2012 01:18:37 +0900 (JST) Received: from kogoro.jp.nec.com ([10.26.220.12] [10.26.220.12]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-874797; Sat, 11 Feb 2012 01:17:14 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-72212; Sat, 11 Feb 2012 01:17:14 +0900 To: Washam Fan In-reply-to: Message-Id: <20120211011714kawashimam@mail.jp.nec.com> References: Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Sat, 11 Feb 2012 01:17:13 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on 464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 16:18:43 -0000 Hi Washam, If CLAT gets a prefix longer than /64, it does not need to perform ND for 464XLAT addresses on WAN interface because 464XLAT addresses are assigned to LAN interface or Virtual interface in CLAT. (i.e. 464XLAT addresses are not included in WAN Prefix.) If CLAT gets a prefix shorter than /64, it must perform ND for 464XLAT addresses on WAN interface because 464XLAT addresses are assigned to WAN interface. (i.e. 464XLAT addresses are included in WAN Prefix.) Moreover, if CLAT gets a prefix shorter than /96, it can not perform CLAT function. Regards, Masanobu >Hi, > >>>My point was ND can perform even the prefix != 64, cant it? And when >>>you say ND, are you referring to DAD or full functionality of ND? >> >> Would you mind clarifying what you meant by that? >> If CLAT gets a single /64 prefix from WAN interface, it has to perform >> full functionality of ND for 464XLAT IPv6 addresses. > >Sorry haven't made clearer. If CLAT gets a prefix length longer or >shorter than /64, should it perform ND for the IPv6 addresses? And >another question, did you mean perform ND at the interface facing the >network under CLAT or at the WAN interface? > >Thanks, >washam ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From rajiva@cisco.com Fri Feb 10 08:31:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6923D21F86AF for ; Fri, 10 Feb 2012 08:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.531 X-Spam-Level: X-Spam-Status: No, score=-8.531 tagged_above=-999 required=5 tests=[AWL=1.468, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9E2cQO5JbEA for ; Fri, 10 Feb 2012 08:31:24 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DB8E521F8645 for ; Fri, 10 Feb 2012 08:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=6047; q=dns/txt; s=iport; t=1328891484; x=1330101084; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=7nQeq8gFKUOE67Di6kx5IpYwCzWQ4xWClSmOIHQoF2E=; b=Zg85RJ+uYX1FELzYwOzPAdr0X8UmVmhRyAZS4Pz4E7R7qxbOCFFrUp04 CETrU/bEbF9VjksXRy+TCsiFzw/JHrGKopmKbl0W+yu6R083cbV+6qgIS gl4cS+sHtRYn4MMvLhn0fa2egxkds4Y0sMG5eu24zhB62/dpYrx1jFnqZ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOFFNU+tJXG8/2dsb2JhbABEr1yBB4FyAQEBBAEBAQ8BHQo0FwQCAQgRAwEBAQsGFwEGASAGHwkIAQEEARIIGodjmnQBmmGEAog6gy8FBgQGN4RmgmBjBIhJl3cDAYdv X-IronPort-AV: E=Sophos;i="4.73,396,1325462400"; d="scan'208";a="57972142" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 10 Feb 2012 16:31:23 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1AGVNbI017972 for ; Fri, 10 Feb 2012 16:31:23 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 10:31:23 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Feb 2012 10:31:22 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0759DD4F@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Fwd: 464XLAT Trial Deployment Report Thread-Index: AczitCSgb321r0xrT7yaerQmOd+tPADCi3Ng References: From: "Rajiv Asati (rajiva)" To: "Fred Baker (fred)" , "v6ops v6ops WG" X-OriginalArrivalTime: 10 Feb 2012 16:31:23.0225 (UTC) FILETIME=[6D455490:01CCE811] Subject: Re: [v6ops] Fwd: 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 16:31:25 -0000 I support this as a WG document. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Fred Baker (fred) > Sent: Friday, February 03, 2012 3:40 PM > To: v6ops v6ops WG > Subject: [v6ops] Fwd: 464XLAT Trial Deployment Report >=20 > So - I have a question for the working group. We have a draft and a deployment > report on >=20 > http://datatracker.ietf.org/doc/draft-mawatari-v6ops-464xlat > http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat > "464XLAT: Combination of Stateful and Stateless Translation", Masataka > Mawatari, Masanobu Kawashima, Cameron Byrne, 15-Jan-12 >=20 > indicating that it is useful in a live network. It is, an rfcdiff will tell you, a > rework of draft-mawatari-softwire-464xlat. The technique has similarities and > differences from the concepts in the various dIVI drafts and >=20 > http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-cpe > http://tools.ietf.org/html/draft-chen-v6ops-nat64-cpe > "NAT64 Operational Considerations", Gang Chen, 31-Oct-11 >=20 > http://datatracker.ietf.org/doc/draft-sunq-v6ops-contents-transition > http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition > "Rapid Transition of IPv4 contents to be IPv6-accessible", Qiong Sun, > Chongfeng Xie, Qian Liu, Xing Li, Jacni Qin, Dong Liu, Qin Zhao, > 29-Oct-11 >=20 > The authors argue that this is about operational experience with a protocol > translation technology defined in behave, and that it has current deployment. >=20 > I need to know what the working group, and especially the operators in it, > wants to do with this. Do you want to adopt it as a working group draft? Do you > want to discuss it but leave it individual? Do you think it belongs in another > working group, and if so which? Do you have another opinion? >=20 >=20 > > From: Cameron Byrne > > Date: February 3, 2012 12:17:08 PM PST > > To: IPv6 Ops WG > > Subject: [v6ops] 464XLAT Trial Deployment Report > > > > Hi, > > > > I have recently concluded a simple initial experimental deployment > > 464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android > > Nexus S phone. > > > > The high level summary is that a sample of the top ~200 free Android > > apps that use network services (ie not a calculator with no ads), > > ~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a > > stock Android 4.0 (ICS) on a stock Nexus S phone. > > > > When using custom 464XLAT code [3] on Android, 100% of the ~15% of > > apps that failed in the initial test now work. The 464XLAT CLAT code > > on the Android allowed for IPv4 socket bindings and IPv4 referrals to > > proceed on the IPv6-only network by doing RFC 6145 protocol > > translation locally on the phone. The tested application sample set > > is at [4]. > > > > I believe this simple experiment running real code on a real network > > shows the value of draft-mawatari-v6ops-464xlat for enabling network > > operators to embrace IPv6-only networks as the going forward future of > > access networks. 464XLAT, like NAT64/DNS64, is a bridge technology > > that makes IPv6 deployment feasible without harming the customer > > experience. 464XLAT, like DNS64/NAT64, is not used when apps and > > service are IPv6 native. Thus, as IPv6 deployment progresses across > > the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of > > service. > > > > I hope the problem statement that draft-mawatari-v6ops-464xlat > > addresses is clear as it applies to this trial: 15% of applications > > for this sample in the Android market require IPv4 addresses. > > > > And, i hope the proposed applicability and usefulness of 464XLAT is > > clear as it applies to this trial: 464XLAT allows for 100% > > functionality of all applications in the sample and is only used when > > IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...). > > > > I do have 2 requests of the group. First, please read and comment on > > draft-mawatari-v6ops-464xlat [1]. We are looking for working group > > adoption of this draft since we believe it will broadly support the > > ability of network operators to move forward with IPv6 in the near > > term (code is running, network is deployed). Right now, some networks > > feel they are held back by "IPv6 spoilers" like Skype that require > > IPv4. But now, even Skype works on IPv6 with the help of 464XLAT :) . > > I would like to emphasize that Skype and others MUST still deploy and > > support IPv6. That said, we cannot let their failure hold the rest of > > us back. Second, the IPv4 exhaustion problem is real and now, the > > urgency must be high. Please also comment to the folks at Android > > that this code should be brought into the Android main line > > distribution because network operators (v6ops) need it to continue > > growing the Internet and restoring the end-to-end principle [5]. > > > > Thanks, > > > > Cameron > > > > ps. Big thanks to Dan Drown for open-sourcing his CLAT code! > > > > > > [1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat > > > > [2] http://goo.gl/HGmsy or https://sites.google.com/site/tmoipv6/lg-mytouch > > > > [3] http://code.google.com/p/android-clat/ and > > http://dan.drown.org/android/clat/ and > > > > [4] http://goo.gl/z3j3q or > > > https://docs.google.com/spreadsheet/ccc?key=3D0AnVbRg3DotzFdGVwZWlWeG5 > wXzVMcG5qczZEZloxWGc > > > > [5] http://goo.gl/W55YQ or http > > ://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select- > devices-here-is-what-it-all-means-and-yes-no-more-nat/ > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Fri Feb 10 09:16:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E51121F86A6 for ; Fri, 10 Feb 2012 09:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJV63oIk7uWj for ; Fri, 10 Feb 2012 09:16:25 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 78AB221F8668 for ; Fri, 10 Feb 2012 09:16:25 -0800 (PST) Received: by dakl33 with SMTP id l33so2644523dak.31 for ; Fri, 10 Feb 2012 09:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n3JIWpHKdxKmS2WbQo5dpblg+hwOFxCxaTr0o6ZV1g0=; b=b9kVU9QcSsG41bcsE3f42QX7IBp0XAViydaZGIDGrbPnigPITUlnIK7nGyWR5Mu6+b GZyg2fqlB89oo/ua2XBTvHMyXq8KHhJJVm1OgI2rh/P7YS/2UZo5CzuDkiNM976FM9RN /7AmZMAeTKXMIebX2SyDliK2fV3twTmGcbvvQ= MIME-Version: 1.0 Received: by 10.68.225.39 with SMTP id rh7mr17826339pbc.104.1328894177493; Fri, 10 Feb 2012 09:16:17 -0800 (PST) Received: by 10.143.164.16 with HTTP; Fri, 10 Feb 2012 09:16:17 -0800 (PST) In-Reply-To: <20120211011714kawashimam@mail.jp.nec.com> References: <20120211011714kawashimam@mail.jp.nec.com> Date: Fri, 10 Feb 2012 09:16:17 -0800 Message-ID: From: Cameron Byrne To: Masanobu Kawashima Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on 464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 17:16:26 -0000 On Fri, Feb 10, 2012 at 8:17 AM, Masanobu Kawashima wrote: > > Hi Washam, > > If CLAT gets a prefix longer than /64, it does not need to perform ND > for 464XLAT addresses on WAN interface because 464XLAT addresses are > assigned to LAN interface or Virtual interface in CLAT. (i.e. 464XLAT > addresses are not included in WAN Prefix.) > > If CLAT gets a prefix shorter than /64, it must perform ND for 464XLAT > addresses on WAN interface because 464XLAT addresses are assigned to > WAN interface. (i.e. 464XLAT addresses are included in WAN Prefix.) > > Moreover, if CLAT gets a prefix shorter than /96, it can not perform > CLAT function. > > Regards, > Masanobu > Allow me to add a use case that may make this clearer. In the draft, we will work on making that language clear. This is one of the key benefits of working group feedback. In the ideal case, DHCP-PD will provide a dedicated /64 that can be used for sourcing and receiving the RFC 6145 stateless translation traffic. In the case of a 3G phone from a 3GPP pre-release 10 network that does not support DHCP-PD, the CLAT/Phone will receive a /64 from the network to be used on the WAN 3G interface. The CLAT function on the phone will own the lower /96 of /64 and claim those addresses as its own so that i may source and receive RFC6145 stateless translations. It is relevant to reserve this address space for data sessions that originate from the phone as well as the use case of the phone being used as a wireless router with NDproxy to the 3G network. This also applies to any landline deployment where there is either only 1 WAN or LAN /64. The CLAT must ensure that /96 is owned by the CLAT for that subnet for RFC 6145 to function properly and not conflict with the IPv6 addresses of other devices on the subnet. CB From naveen.ipv6@gmail.com Fri Feb 10 19:27:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3238621F84EC for ; Fri, 10 Feb 2012 19:27:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V745m25WrLTy for ; Fri, 10 Feb 2012 19:27:43 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D03E21F84E0 for ; Fri, 10 Feb 2012 19:27:43 -0800 (PST) Received: by ghbg16 with SMTP id g16so2089565ghb.31 for ; Fri, 10 Feb 2012 19:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=WroCKOVAgeXr9rNn5iKhMLZRQThdOK3UzZWLy/HFuzo=; b=Ie1TsMvk8y5gp0LwfRBOwXSr2wz/O9ztc4cUna51QrYQsaSlWBN9nvXLRFia7JuiQd A+WclDjAE/IH5PxG73Zl5eEjAAfQxVer+A5ivRi4Nw8LchTZQs/9Je+pXEjbNzgyppCj annohsIMmDOB6gKsq1URo2Zf4JsCCbXg70tjk= MIME-Version: 1.0 Received: by 10.236.184.8 with SMTP id r8mr12156884yhm.110.1328930863159; Fri, 10 Feb 2012 19:27:43 -0800 (PST) Received: by 10.146.167.13 with HTTP; Fri, 10 Feb 2012 19:27:43 -0800 (PST) Date: Sat, 11 Feb 2012 08:57:43 +0530 Message-ID: From: Naveen Lakshman To: "Fred Baker (fred)" , v6ops v6ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 03:27:44 -0000 I support 464 XLAT as WG Doc. Regards, Naveen From fred@cisco.com Fri Feb 10 22:00:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076FA21F85C9 for ; Fri, 10 Feb 2012 22:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.454 X-Spam-Level: X-Spam-Status: No, score=-108.454 tagged_above=-999 required=5 tests=[AWL=2.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BisnP9KdjNOP for ; Fri, 10 Feb 2012 22:00:44 -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 3F71621F85B4 for ; Fri, 10 Feb 2012 22:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=92; q=dns/txt; s=iport; t=1328940043; x=1330149643; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=fXMvBHmBlnDqNuv3YAhpP3Ib9BfBeUIekOB770uXIhQ=; b=EuJ49N4bIhK72ShK4TNrPTYhFjGsmfYXeVS/hhxor2fU3FngDvBIDxpa vwPmDFPhf2I3A+3ZCXymDywc4+PGmAKHSbdSHDzy2C+aPpqnoUQZoQCbt 58K33dbxzsONI25Q8j1ehZvSYL+lzgr2ck1dKi0CT2vczAjtCBwMo7mko A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAMcDNk+rRDoI/2dsb2JhbABEr2+BB4ILASeBfTWgKYEnAZ43i24KBgUCBAcCBwcLBAEFFAEDEAEBAQIBgxcFBj0EgzVjBIhKjGeFWo0r X-IronPort-AV: E=Sophos;i="4.73,400,1325462400"; d="scan'208";a="29835117" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 11 Feb 2012 06:00:29 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1B60TXa014575 for ; Sat, 11 Feb 2012 06:00:29 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Fri, 10 Feb 2012 22:00:29 -0800 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Fri, 10 Feb 2012 22:00:29 -0800 From: Fred Baker Date: Fri, 10 Feb 2012 22:00:17 -0800 Message-Id: To: v6ops v6ops WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] draft-gont-v6ops-ra-guard-evasion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 06:00:47 -0000 The author has asked whether the working group supports this as a = working group draft.= From cra@WPI.EDU Fri Feb 10 22:37:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5197F21F8480 for ; Fri, 10 Feb 2012 22:37:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P0CuTjb29Zf for ; Fri, 10 Feb 2012 22:37:24 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBAF21F8462 for ; Fri, 10 Feb 2012 22:37:24 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q1B6bMqa021703; Sat, 11 Feb 2012 01:37:22 -0500 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q1B6bMqa021703 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1328942242; bh=wSPiJVwuIX5SAquHX5oA+tC5i8eOAXx8oCygJOrPkSc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=i8jtPrTYY3sbUikcCIeO4QR3M0rCiToEBuB/j3KTuBhAdzFZGaQKCJgx7eSAcVyVa VpWJPUZF8INllM3ZJUVPIdax8RsI0MSE+NqwJwUNCuaKOnkgpVK7JLSwSfpyrZ63jT R6wySGsvhg13TxgHyORxJ3ltF7EhdX/ZxTGlqpTc= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q1B6bM4f021700; Sat, 11 Feb 2012 01:37:22 -0500 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q1B6bGii019034; Sat, 11 Feb 2012 01:37:22 -0500 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (angus.ind.WPI.EDU [127.0.0.1]) by angus.ind.WPI.EDU (8.14.2/8.14.2) with ESMTP id q1B6aakj001160; Sat, 11 Feb 2012 01:36:51 -0500 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.2/8.14.2/Submit) id q1B6aFUD001143; Sat, 11 Feb 2012 01:36:15 -0500 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Sat, 11 Feb 2012 01:36:15 -0500 From: Chuck Anderson To: Fred Baker Message-ID: <20120211063615.GL17691@angus.ind.WPI.EDU> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-gont-v6ops-ra-guard-evasion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 06:37:25 -0000 On Fri, Feb 10, 2012 at 10:00:17PM -0800, Fred Baker wrote: > The author has asked whether the working group supports this as a working group draft. Support. From fgont@si6networks.com Sat Feb 11 10:20:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FB421F8525 for ; Sat, 11 Feb 2012 10:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1BVhdXSWKLW for ; Sat, 11 Feb 2012 10:20:46 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1906021F845F for ; Sat, 11 Feb 2012 10:20:45 -0800 (PST) Received: from [186.204.84.13] (helo=[192.168.2.10]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RwHYv-0006KG-6H; Sat, 11 Feb 2012 19:20:41 +0100 Message-ID: <4F36B175.4060108@si6networks.com> Date: Sat, 11 Feb 2012 16:20:37 -0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Fred Baker References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-gont-v6ops-ra-guard-evasion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 18:20:56 -0000 FYI, strictly speaking, the latest revision of this is draft-gont-v6ops-ra-guard-implementation (http://tools.ietf.org/html/draft-gont-v6ops-ra-guard-implementation-01) -- this is the I-D that I'd expect the WG to decide whether to adopt (since it is the one that incoporporates all the comments received so far. Thanks, Fernando On 02/11/2012 04:00 AM, Fred Baker wrote: > The author has asked whether the working group supports this as a working group draft. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fred@cisco.com Sat Feb 11 10:46:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5410521F850C for ; Sat, 11 Feb 2012 10:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.196 X-Spam-Level: X-Spam-Status: No, score=-108.196 tagged_above=-999 required=5 tests=[AWL=1.803, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rehOiehH1cam for ; Sat, 11 Feb 2012 10:46:41 -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 B731D21F849D for ; Sat, 11 Feb 2012 10:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=924; q=dns/txt; s=iport; t=1328986001; x=1330195601; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=UlYfLcYUCTO/aaHtExUCMXJdIcuRTQh2yLAg2Jfa1WY=; b=lm7tO7V6+DSTfQwErvEXp/ozTizxyOHlYbyvDXGhHbsEAQETKLPqXCIO x+dT4JFm/cEARpIoB8KvqOXPvdgJFkj7QBmFfaSIUrjp+nprgJVBfzTqt A8GGSf/c3zI7PA9Kh/2v4CzirQT7A47/enfh35mtXeSb9bf2XG9pmm/p0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEG3Nk+rRDoG/2dsb2JhbABEr3CBB4FyAQEBAwEBAQEPASc0CwULCw4KLicwBhMih1oJmh4BnXWLdAUKBgUCBAcCBwcLBAEFFAEDEgODGAUGPQRVgmBjBIhKjGiFWo0r X-IronPort-AV: E=Sophos;i="4.73,403,1325462400"; d="scan'208";a="29748112" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 11 Feb 2012 18:46:40 +0000 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1BIkbaH020555; Sat, 11 Feb 2012 18:46:40 GMT Received: from [127.0.0.1] by stealth-10-32-244-219.cisco.com (PGP Universal service); Sat, 11 Feb 2012 10:46:40 -0800 X-PGP-Universal: processed; by stealth-10-32-244-219.cisco.com on Sat, 11 Feb 2012 10:46:40 -0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4F36B175.4060108@si6networks.com> Date: Sat, 11 Feb 2012 10:45:42 -0800 Message-Id: References: <4F36B175.4060108@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-gont-v6ops-ra-guard-evasion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 18:46:44 -0000 Sorry, my error. On Feb 11, 2012, at 10:20 AM, Fernando Gont wrote: > FYI, strictly speaking, the latest revision of this is > draft-gont-v6ops-ra-guard-implementation > = (http://tools.ietf.org/html/draft-gont-v6ops-ra-guard-implementation-01) > -- this is the I-D that I'd expect the WG to decide whether to adopt > (since it is the one that incoporporates all the comments received so = far. >=20 > Thanks, > Fernando >=20 >=20 >=20 >=20 > On 02/11/2012 04:00 AM, Fred Baker wrote: >> The author has asked whether the working group supports this as a = working group draft. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 > --=20 > 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 Tina.Tsou.Zouting@huawei.com Sat Feb 11 11:10:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C55621F856D for ; Sat, 11 Feb 2012 11:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHxtT73SEH+e for ; Sat, 11 Feb 2012 11:10:05 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8358921F856C for ; Sat, 11 Feb 2012 11:10:05 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ80050NT8Q0C@szxga05-in.huawei.com> for v6ops@ietf.org; Sun, 12 Feb 2012 03:10:02 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ8009GIT8QIF@szxga05-in.huawei.com> for v6ops@ietf.org; Sun, 12 Feb 2012 03:10:02 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHA95679; Sun, 12 Feb 2012 03:07:35 +0800 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 12 Feb 2012 03:07:34 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.64]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Sun, 12 Feb 2012 03:07:46 +0800 Date: Sat, 11 Feb 2012 19:07:18 +0000 From: Tina TSOU In-reply-to: To: Fred Baker Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [v6ops] draft-gont-v6ops-ra-guard-evasion Thread-index: AQHM6IKWh5llIcv8RUmWHXU1HAOvKZY4D7r2 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-gont-v6ops-ra-guard-evasion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 19:10:06 -0000 Sent from my iPad On Feb 10, 2012, at 10:01 PM, "Fred Baker" wrote: > The author has asked whether the working group supports this as a working group draft. Support. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From washam.fan@gmail.com Sat Feb 11 21:33:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998C121F85A4 for ; Sat, 11 Feb 2012 21:33:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhTgbhhgaroV for ; Sat, 11 Feb 2012 21:33:10 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C46A121F8571 for ; Sat, 11 Feb 2012 21:33:09 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so2925078wgb.13 for ; Sat, 11 Feb 2012 21:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eeWhf3MoTvrEobmQy+SuzohPJFYi9QNlc9rtgJkWdaU=; b=QVIteV0uKa2KxcCQEHZ74tnw3nkdP9N3VTJTzA2rkP+VCLIr5yLXd4gNUTCCoZKCQl 3OihXmPrQBcWCYz8eSPPlJsVaujVf+TBnordWqdFWbT4XYnELwCgx9Oq6ei+DeMBJ8Wh Dx4bIcKA7nxUkHXa95rOtB4P0x/uPyoaVFyqU= MIME-Version: 1.0 Received: by 10.180.82.227 with SMTP id l3mr17724604wiy.1.1329024785663; Sat, 11 Feb 2012 21:33:05 -0800 (PST) Received: by 10.216.1.6 with HTTP; Sat, 11 Feb 2012 21:33:05 -0800 (PST) In-Reply-To: <20120211011714kawashimam@mail.jp.nec.com> References: <20120211011714kawashimam@mail.jp.nec.com> Date: Sun, 12 Feb 2012 13:33:05 +0800 Message-ID: From: Washam Fan To: Masanobu Kawashima Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on 464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 05:33:10 -0000 Hi Masanobu, > If CLAT gets a prefix longer than /64, it does not need to perform ND > for 464XLAT addresses on WAN interface because 464XLAT addresses are > assigned to LAN interface or Virtual interface in CLAT. (i.e. 464XLAT > addresses are not included in WAN Prefix.) > > If CLAT gets a prefix shorter than /64, it must perform ND for 464XLAT > addresses on WAN interface because 464XLAT addresses are assigned to > WAN interface. (i.e. 464XLAT addresses are included in WAN Prefix.) But the draft says if CLAT get a prefix *equals to* /64, it MUST perform ND. Anyway, I think more text in section is necessary. Thanks, washam > Moreover, if CLAT gets a prefix shorter than /96, it can not perform > CLAT function. > From mohacsi@niif.hu Sun Feb 12 04:30:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C9A21F8670 for ; Sun, 12 Feb 2012 04:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-AvJohJa7fC for ; Sun, 12 Feb 2012 04:30:24 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id CA88121F866E for ; Sun, 12 Feb 2012 04:30:23 -0800 (PST) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 80BF2879CE; Sun, 12 Feb 2012 13:30:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id LZ11DyLOeElo; Sun, 12 Feb 2012 13:30:18 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id C730E87992; Sun, 12 Feb 2012 13:30:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id C5A05878F4; Sun, 12 Feb 2012 13:30:18 +0100 (CET) Date: Sun, 12 Feb 2012 13:30:18 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Fred Baker In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-gont-v6ops-ra-guard-evasion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 12:30:24 -0000 Yes, I am suporting the draft - maybe with more appropriate title: e.g. ra-guard operational consideratios Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Fri, 10 Feb 2012, Fred Baker wrote: > The author has asked whether the working group supports this as a working group draft. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From kawashimam@vx.jp.nec.com Sun Feb 12 04:53:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB5521F8684 for ; Sun, 12 Feb 2012 04:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ0q39oiXg2u for ; Sun, 12 Feb 2012 04:53:13 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF1221F867E for ; Sun, 12 Feb 2012 04:53:12 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q1CCr6Hj019448; Sun, 12 Feb 2012 21:53:06 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q1CCr6r28081; Sun, 12 Feb 2012 21:53:06 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id q1CCr524027492; Sun, 12 Feb 2012 21:53:06 +0900 (JST) Received: from togyo.jp.nec.com ([10.26.220.4] [10.26.220.4]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-879494; Sun, 12 Feb 2012 21:52:19 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Sun, 12 Feb 2012 21:52:17 +0900 To: =?ISO-8859-1?B?V2FzaGFtIEZhbiA=?= In-reply-to: Message-Id: <20120212215215kawashimam@mail.jp.nec.com> References: Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Sun, 12 Feb 2012 21:52:14 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] =?iso-8859-1?q?Comments_on_464xlat-00?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 12:53:14 -0000 Hi Washam, Thank you for your helpful comments. We will add some clarifying language about this in the next version. Regards, Masanobu >Hi Masanobu, > >> If CLAT gets a prefix longer than /64, it does not need to perform ND >> for 464XLAT addresses on WAN interface because 464XLAT addresses are >> assigned to LAN interface or Virtual interface in CLAT. (i.e. 464XLAT >> addresses are not included in WAN Prefix.) >> >> If CLAT gets a prefix shorter than /64, it must perform ND for 464XLAT >> addresses on WAN interface because 464XLAT addresses are assigned to >> WAN interface. (i.e. 464XLAT addresses are included in WAN Prefix.) > >But the draft says if CLAT get a prefix *equals to* /64, it MUST >perform ND. Anyway, I think more text in section is necessary. > >Thanks, >washam > >> Moreover, if CLAT gets a prefix shorter than /96, it can not perform >> CLAT function. >> ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From arturo.servin@gmail.com Sun Feb 12 05:28:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817C321F872B for ; Sun, 12 Feb 2012 05:28: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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXMhnrwPs1Qp for ; Sun, 12 Feb 2012 05:28:47 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id EAF9D21F8725 for ; Sun, 12 Feb 2012 05:28:46 -0800 (PST) Received: by qan41 with SMTP id 41so2577719qan.10 for ; Sun, 12 Feb 2012 05:28:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=o139B65zQYSfOmILhVH4SkX7DFX3y5Bi6pzoQHoUvLc=; b=KHLq396TSjL8/ZDGw6rERBaI1RhoGrx2m8UUMxLmKLcoJwb+NiEWFIkobb3ZvHUvH1 qg8pz1czR9jfQb35QS6YNR1rOOUgx0QcUGGSEWSdxFxB1ha/t9WYgq3F5mkyXHwzM9aN JnVL0EwoqOzSky7jitoSbFZIV9GNudGj7EN+E= Received: by 10.224.116.197 with SMTP id n5mr6514916qaq.70.1329053325204; Sun, 12 Feb 2012 05:28:45 -0800 (PST) Received: from [192.168.1.102] (r186-48-231-51.dialup.adsl.anteldata.net.uy. [186.48.231.51]) by mx.google.com with ESMTPS id fh6sm26894145qab.22.2012.02.12.05.28.42 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Feb 2012 05:28:44 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Sun, 12 Feb 2012 11:28:39 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Fred Baker X-Mailer: Apple Mail (2.1257) Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-gont-v6ops-ra-guard-evasion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 13:28:47 -0000 support. /as On 11 Feb 2012, at 04:00, Fred Baker wrote: > The author has asked whether the working group supports this as a = working group draft. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Sun Feb 12 20:25:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B5921F865D; Sun, 12 Feb 2012 20:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.756 X-Spam-Level: X-Spam-Status: No, score=-102.756 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujn3mPPzfiCA; Sun, 12 Feb 2012 20:25:21 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 48E2321F862D; Sun, 12 Feb 2012 20:25:21 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q1D4PCGD059614 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 13 Feb 2012 04:25:16 GMT (envelope-from joelja@bogus.com) Message-ID: <4F3890A6.3090308@bogus.com> Date: Sun, 12 Feb 2012 20:25:10 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <8EA035DE-DAB9-4920-9BD6-75944848CA5D@cisco.com> <4F329696.6000505@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 13 Feb 2012 04:25:18 +0000 (UTC) Cc: v6ops v6ops WG , IETF Discussion Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 04:25:21 -0000 On 2/9/12 01:25 , Lorenzo Colitti wrote: > On Thu, Feb 9, 2012 at 00:36, Joel jaeggli > wrote: > > Ops is not marketing. > > > And if I were looking for a marketing venue, a standards body that > produces ASCII text documents read by a handful of engineers would not > be high on my list. This is not about marketing. > Sorry for being so droll, I found it hard to restrain myself. > > If you're saying some flag day makes the contents of the document no > longer operationally relevant after a given date, I'll take the point > but disagree. > > > I think you're missing my point. > > It seems to me that approximately 30% of the non-biolerplate text in > this draft discusses DNS whitelisting. (And in fact, in its original > form the draft entirely on DNS whitelisting - hence the filename. The > rest was added later.) > > Whitelisting is a practice relevant to a few large websites (since > nobody else is using it). It so happens that the websites that employ > this practice are going to stop using it, all together. Given the cost > and implications, I'd say practice is unlikely to be resurrected. I do not belive that the selective (inclusive) return of A or A + AAAA records on the basis of source address is likely to end on a particular day. It may well for you and some others, which is fine, or you may find it necessary again, or it may become a list of exclusions rather than inclusions. I belive you're on record indicating as much. In any event others may find it necessary. > So, you decide to tell the whole story, and talk about whitelisting > *and* World IPv6 Launch. Or you can decide that whitelisting will soon > be irrelevant, and not talk about either whitelisting or World IPv6 > Launch. But you can't talk about whitelisting without talking about > World IPv6 Launch, because if you do, your document is missing the key > piece "how do you remove the whitelist", and that's a disservice to its > readers. > > To be more specific, at least section 5.5 ("it is unclear > how implementers will judge when the network conditions will have > changed sufficiently to justify turning off DNS Resolver Whitelisting > and/or what the process and timing will be for discontinuing this > practice") is now incorrect. It *is* clear, and it's what those > implementers are doing as part of World IPv6 Launch. Invidual service operators like you and I are likely to make decisions on the basis of our instrumentation, we may well alter their behavior on a uni or multilateral basis, and some of us may do so for world ipv6 launch. ipv4/v6 Transition is not something with a flag day however, and I do not believe that the concerns embedded in the draft will be fundamentally altered on 6/6/12. > Does that make more sense? yes, that doesn't imply that we're in concert however. > Cheers, > Lorenzo From gvandeve@cisco.com Mon Feb 13 02:09:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987C321F86E0 for ; Mon, 13 Feb 2012 02:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.179 X-Spam-Level: X-Spam-Status: No, score=-10.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc0DjPsZBy2b for ; Mon, 13 Feb 2012 02:09:41 -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 8109921F8690 for ; Mon, 13 Feb 2012 02:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1205; q=dns/txt; s=iport; t=1329127781; x=1330337381; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=5RzynxkA6tq0Z8iHXi05hphqz+BwfuNQSsijOgnrioA=; b=fc+BYPYt9WXgdr8DDrgSapTQsECKFbfP7ng4OKgB1kZM+bEWXJlV14xQ 6AcHbWj6aZeguNVzku+9WQbCk0EHu6ue8QL2toNuwtSg8jgeSOKdCBHUE FBpRFDLLkINxug4t95J0jDR10l0pwwjz9deFC/lnVNeW/pAa5iRFbJuT7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADngOE+Q/khR/2dsb2JhbABDr3yBB4FyAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHWgmaWQGeBgSLeQoGPQEmhDmCYGMEqBc X-IronPort-AV: E=Sophos;i="4.73,411,1325462400"; d="scan'208";a="129233649" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2012 10:09:40 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1DA9eOZ011515; Mon, 13 Feb 2012 10:09:40 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Feb 2012 11:09:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Feb 2012 11:09:39 +0100 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC506D64C8D@XMB-AMS-102.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-gont-v6ops-ra-guard-evasion Thread-Index: AczpgjtSYHverWkIT6mTADnkmkthxAAtUIxg References: From: "Gunter Van de Velde (gvandeve)" To: "Mohacsi Janos" , "Fred Baker (fred)" X-OriginalArrivalTime: 13 Feb 2012 10:09:40.0123 (UTC) FILETIME=[99328EB0:01CCEA37] Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-gont-v6ops-ra-guard-evasion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 10:09:42 -0000 Fernando changed the title to something else: Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) draft-gont-v6ops-ra-guard-implementation-01 btw, I do not object for this to be adopted. G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Mohacsi Janos Sent: zondag 12 februari 2012 13:30 To: Fred Baker (fred) Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-gont-v6ops-ra-guard-evasion Yes, I am suporting the draft - maybe with more appropriate title: e.g. ra-guard operational consideratios Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Fri, 10 Feb 2012, Fred Baker wrote: > The author has asked whether the working group supports this as a working group draft. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From simon.perreault@viagenie.ca Mon Feb 13 05:45:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575FF21F857A for ; Mon, 13 Feb 2012 05:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxTn4yIA9R0k for ; Mon, 13 Feb 2012 05:45:21 -0800 (PST) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 9522721F8577 for ; Mon, 13 Feb 2012 05:45:21 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:a09b:8bd1:33c7:baaf]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D700221F04 for ; Mon, 13 Feb 2012 08:45:19 -0500 (EST) Message-ID: <4F3913EF.2060801@viagenie.ca> Date: Mon, 13 Feb 2012 08:45:19 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-gont-v6ops-ra-guard-evasion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 13:45:22 -0000 On 2012-02-11 01:00, Fred Baker wrote: > The author has asked whether the working group supports this as a working group draft. Support. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From jared@puck.nether.net Mon Feb 13 06:04:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF0E21F855F for ; Mon, 13 Feb 2012 06:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcWSGhPvb7av for ; Mon, 13 Feb 2012 06:04:47 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2F37921F84AE for ; Mon, 13 Feb 2012 06:04:47 -0800 (PST) Received: from [10.67.142.85] (mobile-166-147-099-210.mycingular.net [166.147.97.210] (may be forged)) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q1DE3YRq026391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Feb 2012 09:03:35 -0500 References: <4F36B175.4060108@si6networks.com> In-Reply-To: <4F36B175.4060108@si6networks.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Jared Mauch Date: Mon, 13 Feb 2012 08:47:23 -0500 To: Fernando Gont X-Mailer: iPhone Mail (9B5141a) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 13 Feb 2012 09:03:35 -0500 (EST) Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-gont-v6ops-ra-guard-evasion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 14:04:47 -0000 Support! Jared Mauch On Feb 11, 2012, at 1:20 PM, Fernando Gont wrote: > FYI, strictly speaking, the latest revision of this is > draft-gont-v6ops-ra-guard-implementation > (http://tools.ietf.org/html/draft-gont-v6ops-ra-guard-implementation-01) > -- this is the I-D that I'd expect the WG to decide whether to adopt > (since it is the one that incoporporates all the comments received so far.= >=20 > Thanks, > Fernando >=20 >=20 >=20 >=20 > On 02/11/2012 04:00 AM, Fred Baker wrote: >> The author has asked whether the working group supports this as a working= group draft. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Mon Feb 13 10:08:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B3721F86DB; Mon, 13 Feb 2012 10:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wapZrFyoyYni; Mon, 13 Feb 2012 10:08:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9BB21F86A0; Mon, 13 Feb 2012 10:08:07 -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 X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120213180807.21060.44105.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2012 10:08:07 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 18:08:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Implementation Advice for IPv6 Router Advertisement Guar= d (RA-Guard) Author(s) : Fernando Gont Filename : draft-ietf-v6ops-ra-guard-implementation-00.txt Pages : 16 Date : 2012-02-12 The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and provides advice on the implementation of RA-Guard, such that the RA-Guard evasion vectors are eliminated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementatio= n-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation= -00.txt From phdgang@gmail.com Mon Feb 13 20:11:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAE521F847D for ; Mon, 13 Feb 2012 20:11:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z1yrC8XquUq for ; Mon, 13 Feb 2012 20:11:06 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4A821F845C for ; Mon, 13 Feb 2012 20:11:05 -0800 (PST) Received: by werm10 with SMTP id m10so5126120wer.31 for ; Mon, 13 Feb 2012 20:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=o7iHDslq2QV5sL+172iSN9qcKHyqHYYNQuCs56vVSpo=; b=MxJySVqkAS2RCIzc+/qyNjKvvPpvQXJtkVSFpehmYmbtw9nkDa/LxkbV6pnfugV5QU N2xxcK+gzyvm8C3ZETIHU7AwDZMy/nWhTJtCrb56srfBMbrXa49BgMDwAsZnP6QZ2ymD T8nXcp1Kya4N0js7WlZl17sEpzduRTAj/39Jg= MIME-Version: 1.0 Received: by 10.180.109.228 with SMTP id hv4mr1062998wib.11.1329192660587; Mon, 13 Feb 2012 20:11:00 -0800 (PST) Received: by 10.180.78.200 with HTTP; Mon, 13 Feb 2012 20:11:00 -0800 (PST) Date: Tue, 14 Feb 2012 12:11:00 +0800 Message-ID: From: GangChen To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] I-D Action: draft-chen-v6ops-nat64-experience-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 04:11:06 -0000 Hello all, We have published draft-chen-v6ops-nat64-experience-00, which described NAT64 operational expriences and updated with all the information from the presentation of draft-chen-v6ops-nat64-cpe at last meeting. Considering the new changes, authors would like to retire the old draft (i.e. draft-chen-v6ops-nat64-cpe) and continue the discussion on nat64 experiences. All comments are welcome. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT64 Operational Experiences Author(s) : Gang Chen Zhen Cao Cameron Byrne QiBo Niu Filename : draft-chen-v6ops-nat64-experience-00.txt Pages : 11 Date : 2012-02-13 This document summarizes some stateful NAT64 deployment scenarios and operational experiences for NAT64-CGN and NAT64-CE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-00.txt From fred@cisco.com Tue Feb 14 06:55:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C8E21F87C4 for ; Tue, 14 Feb 2012 06:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J061DoynkRfK for ; Tue, 14 Feb 2012 06:55:02 -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 CBA6F21F8798 for ; Tue, 14 Feb 2012 06:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=142; q=dns/txt; s=iport; t=1329231301; x=1330440901; h=date:from:message-id:to:subject:cc; bh=X9CGbWe0ccz8uI8R+qDUrW6j/kEswHwFEffsXKv5QyU=; b=A4HolT7tDygrtOA/JI0zbbf+0h/EwxGODG0wKjCrCNbE5Pqbq5IDueKS qqR+i2Ty4lDg64cLR0M33WyHF5hlfqn1U3prZbhwUIH9VglhhmAx0URG1 jQWb4E27T4zEP0GX9s+ocYFV/sghDvQRpQ4BP7Hq6xtSrKIM/2EP5MGKK o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAKx0Ok+rRDoJ/2dsb2JhbABDn1wBkEOBB4ILAWY8LYEKh2OafQGefIt/awEBAQIBAgKDeAIxLII6YwSISp9t X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="30267554" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 14 Feb 2012 14:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1EEt1lS008048; Tue, 14 Feb 2012 14:55:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q1EEt1C04893; Tue, 14 Feb 2012 06:55:01 -0800 (PST) Date: Tue, 14 Feb 2012 06:55:01 -0800 (PST) From: Message-Id: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 14:55:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation. Please take a look at it and comment. From fred@cisco.com Tue Feb 14 06:55:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97E721F87C5 for ; Tue, 14 Feb 2012 06:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.266 X-Spam-Level: X-Spam-Status: No, score=-109.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOj6cjho7N6Y for ; Tue, 14 Feb 2012 06:55:02 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id CC50621F87A3 for ; Tue, 14 Feb 2012 06:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=135; q=dns/txt; s=iport; t=1329231301; x=1330440901; h=date:from:message-id:to:subject:cc; bh=6CEe+S5ZPXgTApKe4fUUYRBn71XPXOJ+KHZ7UzPj55Q=; b=YchJhV+O12E43d2C2Fy5XWsKCyp0iv5pSJzODjlq9nZOy3uBxNAhj+tb LGpm2x2/T/A4c9Dp9/d09croJ/xAZwYVz4W/fDkFpN+ws/bfI7W3DHXXz NboTxuL64IHhQoDQrvqgzAnZS/yKLlbfxqlfvkeVMNwH9ocDPjlZ/NDkR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8FAIF0Ok+rRDoG/2dsb2JhbABDn1wBkEOBB4ILAWY8LYEKh2OafQGee4t/awEBAQIBAgKDeAIxLIMdBIhKn20 X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="28623919" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 14 Feb 2012 14:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1EEt1cu001541; Tue, 14 Feb 2012 14:55:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q1EEt1I04887; Tue, 14 Feb 2012 06:55:01 -0800 (PST) Date: Tue, 14 Feb 2012 06:55:01 -0800 (PST) From: Message-Id: <201202141455.q1EEt1I04887@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-chen-v6ops-nat64-experience@tools.ietf.org Subject: [v6ops] new draft: draft-chen-v6ops-nat64-experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 14:55:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience. Please take a look at it and comment. From brian.e.carpenter@gmail.com Tue Feb 14 12:02:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60FC21E80D4 for ; Tue, 14 Feb 2012 12:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.419 X-Spam-Level: X-Spam-Status: No, score=-103.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi8JNjrTyoQ7 for ; Tue, 14 Feb 2012 12:02:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E578C21F864B for ; Tue, 14 Feb 2012 12:02:33 -0800 (PST) Received: by iagf6 with SMTP id f6so402003iag.31 for ; Tue, 14 Feb 2012 12:02:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=o2vXJdwpJUMXo23OpwihdThAKzqII/m406vU2FhZyUk=; b=XztiNd40Y2k4nytK7OgmDRA4K0zQ0rJXVnd5Mk8W53LGOvBOhDzIR2hBc4psNIR9H7 DiCTEj3vWeG/GiSCnmoRX4PlZds5JatIAaQ3gdnjeVVufAUM5MUUThnXlgdE8wcddj4h eYLttB1OL0+kJTD9UKdgn3VH+L0RdTyaru2g4= Received: by 10.42.156.7 with SMTP id x7mr30225305icw.56.1329249753580; Tue, 14 Feb 2012 12:02:33 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id ak10sm615699igc.6.2012.02.14.12.02.31 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 12:02:32 -0800 (PST) Message-ID: <4F3ABDCB.80004@gmail.com> Date: Wed, 15 Feb 2012 09:02:19 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] NAT64 performance comparisons X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 20:02:35 -0000 On the subject of NAT64, I'v just filed a tech report on some work done by Se-young Yu under my supervision. It will get an official library handle soon, but here is an ad hoc URL to be going on with: http://www.cs.auckland.ac.nz/~brian/IPv4-IPv6coexistenceTechnique-TR.pdf -- Regards Brian Carpenter From jhw@apple.com Tue Feb 14 16:37:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3470221F8546 for ; Tue, 14 Feb 2012 16:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.161 X-Spam-Level: X-Spam-Status: No, score=-110.161 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXBF43O4eSpq for ; Tue, 14 Feb 2012 16:37:27 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2245E21F8542 for ; Tue, 14 Feb 2012 16:37:27 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ESME6RlCBY52uN29wk/GVA)" Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0LZE00NEXSD22US2@mail-out.apple.com> for v6ops@ietf.org; Tue, 14 Feb 2012 16:37:05 -0800 (PST) X-AuditID: 11807136-b7b5aae000005be8-26-4f3afe3004e8 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id D3.19.23528.13EFA3F4; Tue, 14 Feb 2012 16:37:05 -0800 (PST) From: james woodyatt Date: Tue, 14 Feb 2012 16:37:04 -0800 In-reply-to: To: V6OPS Working Group References: Message-id: X-Mailer: Apple Mail (2.1257) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUieJDXQdfwn5W/wbpVghanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoqfd9kKbmhUbHl6nbWBcYJKFyMnh4SAicSMviZ2CFtM4sK9 9WxdjFwcQgKzmSSaD15kA0mwCahIfLt8lwnE5hUwlJj5qp0VxGYWSJD4O/0NWI2wgJnEznPn wOIsAqoS3R9XMoPYnAK2Ej+mLAWLiwhoSPxtm8MIYgsJ2Ej8vNPHBjHTRuLyoTWMEEfIStw+ uJ9pAiPvLCTrZiFZB2FrSyxb+Jp5FiMHkK0jMXkhI6owhP3x/BGmBYxsqxgFi1JzEisNTfUS CwpyUvWS83M3MYICr6HQbAfjjr9yhxgFOBiVeHgPPrLyF2JNLCuuzD3EKMHBrCTCu2k6UIg3 JbGyKrUoP76oNCe1+BCjNAeLkjivmIelv5BAemJJanZqakFqEUyWiYNTqoGRzznr1/eNm9IT Sx/sNj0hKMnRrR99Y/u01uquf/NFOD4InHWt/VW67AlP34tXTu5TxJUMlex5RCdfn5gQZ3iS bXfpc4mEDye3qDyt3Wu15e/a00dX3RVf7jgzWevazoD/bfPfhTEWKWoeX9H87n9v9O4vwYuO PWQSUbRcuM+iJujjMsPd3Qz/lViKMxINtZiLihMBu7TJrTgCAAA= Subject: Re: [v6ops] draft-gont-v6ops-ra-guard-evasion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 00:37:28 -0000 --Boundary_(ID_ESME6RlCBY52uN29wk/GVA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Feb 10, 2012, at 22:00 , Fred Baker wrote: > > The author has asked whether the working group supports this as a working group draft. Support. -- james woodyatt member of technical staff, core os networking --Boundary_(ID_ESME6RlCBY52uN29wk/GVA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
The author = has asked whether the working group supports this as a working group = draft.


--
james woodyatt <jhw@apple.com>
member of technical staff, core os = networking



= --Boundary_(ID_ESME6RlCBY52uN29wk/GVA)-- From internet-drafts@ietf.org Tue Feb 14 17:19:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F10521F87E5; Tue, 14 Feb 2012 17:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwytehrk9uef; Tue, 14 Feb 2012 17:19:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC0C21F87E2; Tue, 14 Feb 2012 17:19:28 -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 X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120215011928.4651.7195.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2012 17:19:28 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 01:19:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : 464XLAT: Combination of Stateful and Stateless Translati= on Author(s) : Masataka Mawatari Masanobu Kawashima Cameron Byrne Filename : draft-ietf-v6ops-464xlat-00.txt Pages : 15 Date : 2012-02-14 This document describes an architecture (464XLAT) for providing IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy IPv4 access service to mobile and wireline IPv6-only edge networks without encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-00.txt From kawashimam@vx.jp.nec.com Tue Feb 14 17:43:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCDC21F8803 for ; Tue, 14 Feb 2012 17:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.06 X-Spam-Level: X-Spam-Status: No, score=0.06 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgdMQ8ta5M30 for ; Tue, 14 Feb 2012 17:43:19 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA4D21F8804 for ; Tue, 14 Feb 2012 17:43:19 -0800 (PST) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q1F1hIAR005240 for ; Wed, 15 Feb 2012 10:43:18 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q1F1hI316655 for v6ops@ietf.org; Wed, 15 Feb 2012 10:43:18 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id q1F1hHKw015351 for ; Wed, 15 Feb 2012 10:43:18 +0900 (JST) Received: from kameyata.jp.nec.com ([10.26.220.29] [10.26.220.29]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-914929; Wed, 15 Feb 2012 10:42:32 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-18617; Wed, 15 Feb 2012 10:42:31 +0900 To: v6ops@ietf.org In-reply-to: <20120215011928.4651.7195.idtracker@ietfa.amsl.com> References: <20120215011928.4651.7195.idtracker@ietfa.amsl.com> Message-Id: <20120215104232kawashimam@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Wed, 15 Feb 2012 10:42:29 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 01:43:20 -0000 Dear all, We have published draft-ietf-v6ops-464xlat-00 as WG draft. We welcome all your comments. Regards, Masanobu > >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : 464XLAT: Combination of Stateful and Stateless Translation > Author(s) : Masataka Mawatari > Masanobu Kawashima > Cameron Byrne > Filename : draft-ietf-v6ops-464xlat-00.txt > Pages : 15 > Date : 2012-02-14 > > This document describes an architecture (464XLAT) for providing IPv4 > connectivity across an IPv6-only network by combining existing and > well-known stateful protocol translation RFC 6146 in the core and > stateless protocol translation RFC 6145 at the edge. 464XLAT is a > simple and scalable technique to quickly deploy IPv4 access service > to mobile and wireline IPv6-only edge networks without encapsulation. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-00.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-00.txt > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From fred@cisco.com Wed Feb 15 06:55:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED0921F8681 for ; Wed, 15 Feb 2012 06:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.599 X-Spam-Level: X-Spam-Status: No, score=-109.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbtx9jPmUZEa for ; Wed, 15 Feb 2012 06:55:01 -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 2A31321F8680 for ; Wed, 15 Feb 2012 06:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=126; q=dns/txt; s=iport; t=1329317701; x=1330527301; h=date:from:message-id:to:subject:cc; bh=of6CqRxzK8JY31q0c8vUw1W5kcy/KGEQoNGVlRc0qPA=; b=kWoxtWnRo9M8ZNMoDJcxFIYrWmPY1VHngGA5u2Ny76z2CIGjH1tEiATN HmBDjdB/NkVeh/yjq7nOu8vyhD2jzC/U+8IcTnGCJEvoDtgyvFJfikxLk 2saPyhEVByLPNpABO9rYCAT5wROcd+VoCHZ8ri5zXsgsKe78TrwrXpwM8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQGADDGO0+rRDoJ/2dsb2JhbABDn3sBkFCBB4ILAWY8LYEKh2abFAGeW4wGaQEBAQIBAoNJAiwCLYMdBIhNn3I X-IronPort-AV: E=Sophos;i="4.73,423,1325462400"; d="scan'208";a="30420603" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 15 Feb 2012 14:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1FEt0HP013497; Wed, 15 Feb 2012 14:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q1FEt0K02883; Wed, 15 Feb 2012 06:55:00 -0800 (PST) Date: Wed, 15 Feb 2012 06:55:00 -0800 (PST) From: Message-Id: <201202151455.q1FEt0K02883@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-464xlat@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 14:55:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-464xlat. Please take a look at it and comment. From jason_livingood@cable.comcast.com Wed Feb 15 07:52:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47FF21F8537; Wed, 15 Feb 2012 07:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=3.364, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jy0Gg8ubGhws; Wed, 15 Feb 2012 07:52:49 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 48E5D21F8533; Wed, 15 Feb 2012 07:52:49 -0800 (PST) Received: from ([24.40.56.114]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.151544428; Wed, 15 Feb 2012 10:52:17 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Wed, 15 Feb 2012 10:52:17 -0500 From: "Livingood, Jason" To: v6ops v6ops WG , IETF Discussion Thread-Topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-Index: AQHM6/nKbjYam0no7UGRxd2Rv+MjlA== Date: Wed, 15 Feb 2012 15:52:16 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.72] Content-Type: multipart/alternative; boundary="_000_CB61222C50472jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 15:52:51 -0000 --_000_CB61222C50472jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To be more specific, at least section 5.5 ("it is unclear how implementers = will judge when the network conditions will have changed sufficiently to ju= stify turning off DNS Resolver Whitelisting and/or what the process and tim= ing will be for discontinuing this practice") is now incorrect. It *is* cle= ar, and it's what those implementers are doing as part of World IPv6 Launch= . Does that make more sense? As the author, if it helps I plan to make the following change to Section 5= .5 following the conclusion of IETF Last Call. I ran this by a few folks al= ready and it seems broadly acceptable (have not heard from Lorenzo yet thou= gh). Jason CURRENT 5.5: 5.5. Turning Off DNS Resolver Whitelisting Domains that choose to implement DNS Resolver Whitelisting generally consid= er it to be a temporary measure. It is unclear how implementers will judge = when the network conditions will have changed sufficiently to justify turni= ng off DNS Resolver Whitelisting and/or what the process and timing will be= for discontinuing this practice, though the extent of IPv6 deployment to e= nd users in networks, the state of IPv6-related impairment, and the maturit= y of IPv6 operations are all clearly factors. However, implementers may wis= h to take into consideration that, as a practical matter, it will be imposs= ible to get to a point where there are no longer any IPv6-related impairmen= ts; some reasonably small number of hosts will inevitably be left behind as= end users elect not to upgrade them or as some hosts are incapable of bein= g upgraded. PROPOSED 5.5 (NEW TEXT IN ALL CAPS): 5.5. Turning Off DNS Resolver Whitelisting Domains that choose to implement DNS Resolver Whitelisting generally consid= er it to be a temporary measure. It is unclear how implementers will judge = when the network conditions will have changed sufficiently to justify turni= ng off DNS Resolver Whitelisting and/or what the process and timing will be= for discontinuing this practice, though the extent of IPv6 deployment to e= nd users in networks, the state of IPv6-related impairment, and the maturit= y of IPv6 operations are all clearly factors. However, SOME IMPLEMENTERS HA= VE ANNOUNCED THAT THEY PLAN TO PERMANENTLY TURN OFF WHITELISTING BEGINNING = ON WORLD IPV6 DAY IN JUNE 2012 [REFERENCE]. IN ANY CASE, implementers may w= ish to take into consideration that, as a practical matter, it will be impo= ssible to get to a point where there are no longer any IPv6-related impairm= ents; some reasonably small number of hosts will inevitably be left behind = as end users elect not to upgrade them or as some hosts are incapable of be= ing upgraded. --_000_CB61222C50472jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6226C31D1F287E4D9CFC5F915534CDA7@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
To be more specific, at least section 5.5 ("it is unclear how&nbs= p;implementers will judge when the network conditions will have changed&nbs= p;sufficiently to justify turning off DNS Resolver Whitelisting and/or = ;what the process and timing will be for discontinuing this practice") is now incorrect. It *is* clear, and it's what those = implementers are doing as part of World IPv6 Launch.

Does that make more sense?

As the author, if it helps I plan to make the following change to Sect= ion 5.5 following the conclusion of IETF Last Call. I ran this by a few fol= ks already and it seems broadly acceptable (have not heard from Lorenzo yet= though). 

Jason

CURRENT 5.5: 

5.5.  Turning Off DNS Reso= lver Whitelisting

Domains that choose to implement DNS Resolver Whitelisting generally consid= er it to be a temporary measure. It is unclear how implementers will judge = when the network conditions will have changed sufficiently to justify turni= ng off DNS Resolver Whitelisting and/or what the process and timing will be for discontinuing this practice= , though the extent of IPv6 deployment to end users in networks, the state = of IPv6-related impairment, and the maturity of IPv6 operations are all cle= arly factors. However, implementers may wish to take into consideration that, as a practical matter, it will b= e impossible to get to a point where there are no longer any IPv6-related i= mpairments; some reasonably small number of hosts will inevitably be left b= ehind as end users elect not to upgrade them or as some hosts are incapable of being upgraded.

PROPOSED 5.5 (NEW TEXT IN ALL CAPS):

5.5.  Turning Off DNS Reso= lver Whitelisting

wrote: > Hi, > > I have recently concluded a simple initial experimental deployment > 464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android > Nexus S phone. > > The high level summary is that a sample of the top ~200 free Android > apps that use network services (ie not a calculator with no ads), > ~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a > stock Android 4.0 (ICS) on a stock Nexus S phone. > > When using custom 464XLAT code [3] on Android, 100% of the ~15% of > apps that failed in the initial test now work. The 464XLAT CLAT code > on the Android allowed for IPv4 socket bindings and IPv4 referrals to > proceed on the IPv6-only network by doing RFC 6145 protocol > translation locally on the phone. The tested application sample set > is at [4]. > > I believe this simple experiment running real code on a real network > shows the value of draft-mawatari-v6ops-464xlat for enabling network > operators to embrace IPv6-only networks as the going forward future of > access networks. 464XLAT, like NAT64/DNS64, is a bridge technology > that makes IPv6 deployment feasible without harming the customer > experience. 464XLAT, like DNS64/NAT64, is not used when apps and > service are IPv6 native. Thus, as IPv6 deployment progresses across > the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of > service. > > I hope the problem statement that draft-mawatari-v6ops-464xlat > addresses is clear as it applies to this trial: 15% of applications > for this sample in the Android market require IPv4 addresses. > > And, i hope the proposed applicability and usefulness of 464XLAT is > clear as it applies to this trial: 464XLAT allows for 100% > functionality of all applications in the sample and is only used when > IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...). > > I do have 2 requests of the group. First, please read and comment on > draft-mawatari-v6ops-464xlat [1]. We are looking for working group > adoption of this draft since we believe it will broadly support the > ability of network operators to move forward with IPv6 in the near > term (code is running, network is deployed). Right now, some networks > feel they are held back by "IPv6 spoilers" like Skype that require > IPv4. But now, even Skype works on IPv6 with the help of 464XLAT :) . > I would like to emphasize that Skype and others MUST still deploy and > support IPv6. That said, we cannot let their failure hold the rest of > us back. Second, the IPv4 exhaustion problem is real and now, the > urgency must be high. Please also comment to the folks at Android > that this code should be brought into the Android main line > distribution because network operators (v6ops) need it to continue > growing the Internet and restoring the end-to-end principle [5]. > > Thanks, > > Cameron > > ps. Big thanks to Dan Drown for open-sourcing his CLAT code! > > > [1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat > > [2] http://goo.gl/HGmsy or > https://sites.google.com/site/tmoipv6/lg-mytouch > > [3] http://code.google.com/p/android-clat/ and > http://dan.drown.org/android/clat/ and > > [4] http://goo.gl/z3j3q or > > https://docs.google.com/spreadsheet/ccc?key=0AnVbRg3DotzFdGVwZWlWeG5wXzVMcG5qczZEZloxWGc > > [5] http://goo.gl/W55YQ or http > :// > www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select-devices-here-is-what-it-all-means-and-yes-no-more-nat/ > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --002354470e44fd21d404b90761f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cameron, All,

I think that this work is very useful and am suppor= ting that it be documented at least as an experiment, however in its curren= t form it does carry new normative text, and it also has a handful of techn= ical items that deserve to be seen in the context of related work.
In particular both xlat464 and MAP-T (softwires) architecture utilize state= less NAT64 on their CLAT/CE elements but differ in how it's allowed to = be configured. Both documents carry normative requirements for such functio= nality beyond the base RFCs. Avoiding incompatible architectures, while bot= h being based on NAT64, would appear to be a reasonable goal to have for st= andardization.

In some more detail the main contrasts between the current MAP-T and xl= at464 drafts appear to be the following:

1. CLAT/CE compatibility with "core" NAT64 element
Xlat464= appears to assume the use of implicit IPv4-in-IPv6 addressing for the CLAT= 's address, whereby the IPv4 address "part" would likely be t= he same across multiple CLATs, and correspond to some private IPv4 address.= This would be sufficent to communication brokenness should such a CLAT be = deployed with a stateless NAT64 "core". Regular IPv6 hosts do not= have such an issue, since they would not use such implicit addresses. Henc= e, while the xlat464 architecture is shown to be used in the context of a s= tateful NAT64 "core" element (PLAT), its current specification wo= uld actually not allowing the use of a stateless NAT64 core elment with a C= LAT device.
In contrast, MAP-T architecture, and MAP-T CE while depicted in terms of a = stateless=20 NAT64 core element, is compatible with a stateful core NAT64 element too.
2. NAT64 prefix configuration
Both a MAP-T CE and xlat464 CLAT nee= d=20 to find the prefix of the core NAT64 translator. The MAP-T envisaged achieving this by configuration (eg the MAP-T DHCPv6 op= tion being specified), while xlat464 indicates that a NAT64 prefix discover= y "via some method" (not specified, likely DNS) will be=20 used.

3. Embedded IPv4-in-IPv6 address assignment to CE/CLAT
xl= at464 does not appear to deal with a a determinate IPv4inIPv6 address to be= assigned and presented to a CLAT device, or not running into some severe I= Pv6 addressing mode restrictions (eg 128 bit addressing not being supported= by 3GPP) - a topic that MAP-T faced initially.
With MAP-T a determinate, public or private, IPv4 address is allowed to be = allocated and presented to a CE device as part of its IPv6 prefix (eg /64) = assignment and algorithm MAP address derivation.

4. The CLAT/CE NAT4= 4 functionality and subtended IPv4 hosts.
The xlat464 CLAT assumes no NAT44. Any subtended IPv4 host/address are mapp= ed statelessly to individual IPv6 address within the CLAT's /96 prefix.= With MAP-T a CE is taken to have a NAT44 component, and this multiplexes a= ny/all subtended private IPv4 hosts behind the MAP derived IPv4 address whi= ch is then statelessly mapped to an IPv6 prefix.
Disabling NAT44 on a MAP-T CE, would appear to be sufficient to allow a MAP= -T CE to be used in an xlat464 mode.

5. Mesh vs hub-spoke communication modes
xlat464 allows only hub-spo= ke communication between CLAT and the core PLAT. In MAP-T, both hub&spo= ke and mesh mode are allowed, with the latter being an optional extension/o= ptimization enabled by specific additional configuration of the CE.

Thus,in terms of specification, between xlat464 and MAP-T there appears= to be a decent case for a converged stateless NAT64 mode of operation/conf= iguration of CLAT/CE elements, allowing their use across both architectures= . This would effectively make the type of "core" NAT to become a = deployment choice, rather than a rule linked to the client devices.

Regards,
Wojciech


On 3 February 2012 21:17, Cameron Byrne <cb.li= st6@gmail.com> wrote:
Hi,

I have recently concluded a simple initial experimental deployment
464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android
Nexus S phone.

The high level summary is that a sample of the top ~200 free Android
apps that use network services (ie not a calculator with no ads),
~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a
stock Android 4.0 (ICS) on a stock Nexus S phone.

When using custom 464XLAT code [3] on Android, 100% of =A0the ~15% of
apps that failed in the initial test now work. The 464XLAT CLAT code
on the Android allowed for IPv4 socket bindings and IPv4 referrals to
proceed on the IPv6-only network by doing RFC 6145 protocol
translation locally on the phone. =A0The tested application sample set
is at [4].

I believe this simple experiment running real code on a real network
shows the value of draft-mawatari-v6ops-464xlat for enabling network
operators to embrace IPv6-only networks as the going forward future of
access networks. 464XLAT, like NAT64/DNS64, is a bridge technology
that makes IPv6 deployment feasible without harming the customer
experience. =A0464XLAT, like DNS64/NAT64, is not used when apps and
service are IPv6 native. =A0Thus, as IPv6 deployment progresses across
the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of
service.

I hope the problem statement that draft-mawatari-v6ops-464xlat
addresses is clear as it applies to this trial: 15% of applications
for this sample in the Android market require IPv4 addresses.

And, i hope the proposed applicability and usefulness of 464XLAT is
clear as it applies to this trial: =A0464XLAT allows for 100%
functionality of all applications in the sample and is only used when
IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...).

I do have 2 requests of =A0the group. =A0First, please read and comment on<= br> draft-mawatari-v6ops-464xlat [1]. =A0We are looking for working group
adoption of this draft since we believe it will broadly support the
ability of network operators to move forward with IPv6 in the near
term (code is running, network is deployed). =A0Right now, some networks feel they are held back by "IPv6 spoilers" like Skype that requir= e
IPv4. =A0But now, even Skype works on IPv6 with the help of 464XLAT :) . =A0I would like to emphasize that Skype and others MUST still deploy and support IPv6. =A0That said, we cannot let their failure hold the rest of us back. =A0Second, the IPv4 exhaustion problem is real and now, the
urgency must be high. =A0Please also comment to the folks at Android
that this code should be brought into the Android main line
distribution because network operators (v6ops) need it to continue
growing the Internet and restoring the end-to-end principle [5].

Thanks,

Cameron

ps. =A0Big thanks to Dan Drown for open-sourcing his CLAT code!


[1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat<= br>
[2] http://goo.gl/HGmsy or https://sites.google.com/site/tmoipv6/lg-mytouch

[3] =A0http://code.google.com/p/android-clat/ and
http://dan= .drown.org/android/clat/ =A0and

[4] http://goo.gl/z3j3q =A0or
https://docs.google.com/sprea= dsheet/ccc?key=3D0AnVbRg3DotzFdGVwZWlWeG5wXzVMcG5qczZEZloxWGc

[5] =A0http://goo.gl/W55Y= Q or http
://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on= -select-devices-here-is-what-it-all-means-and-yes-no-more-nat/
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--002354470e44fd21d404b90761f4-- From cb.list6@gmail.com Wed Feb 15 22:47:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AFD811E8074 for ; Wed, 15 Feb 2012 22:47:06 -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.767, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhNVw-QyHTF4 for ; Wed, 15 Feb 2012 22:47:01 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC7111E8073 for ; Wed, 15 Feb 2012 22:47:01 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2318893pbc.31 for ; Wed, 15 Feb 2012 22:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=7cpddcec6iueIQK80H7op+Z1JF9/JSJ4dQzpJx04xZk=; b=slLTTZudYLrlbp6isOR3VWrXeERxRHAcvkzetwCBCUtz7AFw/eMW2Sqey2FlPxSQ8z QEkvFQkfnAN3VSN4/i09zsA5v8XC+OvpslbN39BSAd94M+BOJhHkwuYryxq7Q+1y8qra REoWFhAYwy7a9BmYLOi3BoGaLi0pRHCWTxWLQ= MIME-Version: 1.0 Received: by 10.68.226.166 with SMTP id rt6mr10710699pbc.23.1329374821114; Wed, 15 Feb 2012 22:47:01 -0800 (PST) Received: by 10.143.164.16 with HTTP; Wed, 15 Feb 2012 22:47:00 -0800 (PST) In-Reply-To: References: Date: Wed, 15 Feb 2012 22:47:00 -0800 Message-ID: From: Cameron Byrne To: Wojciech Dec , IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 06:47:06 -0000 Trying to understand your feedback more On Wed, Feb 15, 2012 at 1:27 PM, Wojciech Dec wrote: > Hi Cameron, All, > > I think that this work is very useful and am supporting that it be Thanks. It is hard to argue with a solution that solves a real problem (15% app breakage in the Android market) > documented at least as an experiment, however in its current form it does > carry new normative text, and it also has a handful of technical items th= at Please explain in detail about the new normative text and what this means to the draft. > deserve to be seen in the context of related work. > In particular both xlat464 and MAP-T (softwires) architecture utilize > stateless NAT64 on their CLAT/CE elements but differ in how it's allowed = to Why is this relevant? MAP-T and 464XLAT both reference and use RFC6145. So= ... ? > be configured. Both documents carry normative requirements for such > functionality beyond the base RFCs. Avoiding incompatible architectures, > while both being based on NAT64, would appear to be a reasonable goal to > have for standardization. > Why is this desirable? The solution space is already very crowded, one more does not really change that. We have documented a network architecture that effectively does RFC 6145 at the CPE/UE and RFC6146 in the network. Relative to other solutions, we believe this is simple and deployable. In fact, it is already coded and deployed. Running code means a lot in the IETF. > In some more detail the main contrasts between the current MAP-T and xlat= 464 > drafts appear to be the following: > > 1. CLAT/CE compatibility with "core" NAT64 element > Xlat464 appears to assume the use of implicit IPv4-in-IPv6 addressing for > the CLAT's address, whereby the IPv4 address "part" would likely be the s= ame > across multiple CLATs, and correspond to some private IPv4 address. This > would be sufficent to communication brokenness should such a CLAT be I would not call this brokenness. We have made this out of scope, and it is in fact the same status quo that most home broadband users have today with IPv4. Most home broadband users have 192.168.0.x/24 overlapping space in their homes and they cannot communicate with each other directly. The same is true for 464XLAT IPv4 services. We are not looking to improve the IPv4 service, we are looking to replace it with IPv6-only and provide service level parity. We believe this has been achieved. Once again, running code in place, live network. > deployed with a stateless NAT64 "core". Regular IPv6 hosts do not have su= ch > an issue, since they would not use such implicit addresses. Hence, while = the > xlat464 architecture is shown to be used in the context of a stateful NAT= 64 > "core" element (PLAT), its current specification would actually not allow= ing > the use of a stateless NAT64 core elment with a CLAT device. > In contrast, MAP-T architecture, and MAP-T CE while depicted in terms of = a > stateless NAT64 core element, is compatible with a stateful core NAT64 > element too. > > 2. NAT64 prefix configuration > Both a MAP-T CE and xlat464 CLAT need to find the prefix of the core NAT6= 4 > translator. The MAP-T envisaged achieving this by configuration (eg the > MAP-T DHCPv6 option being specified), while xlat464 indicates that a NAT6= 4 > prefix discovery "via some method" (not specified, likely DNS) will be us= ed. > We reference a BEHAVE draft on how this can be achieved, but we leave it open for other methods as well since it is not core to the solution. Regarding DNS heuristics for Pref64 discovery, we have running code for this function. > 3. Embedded IPv4-in-IPv6 address assignment to CE/CLAT > xlat464 does not appear to deal with a a determinate IPv4inIPv6 address t= o > be assigned and presented to a CLAT device, or not running into some seve= re > IPv6 addressing mode restrictions (eg 128 bit addressing not being suppor= ted > by 3GPP) - a topic that MAP-T faced initially. > With MAP-T a determinate, public or private, IPv4 address is allowed to b= e > allocated and presented to a CE device as part of its IPv6 prefix (eg /64= ) > assignment and algorithm MAP address derivation. > I am not sure what you are talking about above. We do not have any requirements for determinate IPv4 addressing in 464XLAT. > 4. The CLAT/CE NAT44 functionality and subtended IPv4 hosts. > The xlat464 CLAT assumes no NAT44. Any subtended IPv4 host/address are > mapped statelessly to individual IPv6 address within the CLAT's /96 prefi= x. > With MAP-T a CE is taken to have a NAT44 component, and this multiplexes > any/all subtended private IPv4 hosts behind the MAP derived IPv4 address > which is then statelessly mapped to an IPv6 prefix. So MAP-T does NAT44 -> NAT46 -> NAT64 ? 3x NAT in all IPv4 server cases? ..... so 99% of websites will run through that ? :/ The 464XLAT architecture with DNS64 is 1 NAT in most cases (99% of the web...ie nearly everything without an IPv4 literal / referral ). It is 2 NATs at most NAT46 <-> NAT64 in the case of IPv4 only applications or hosts (Xbox?). And of course, IPv6 native end to end for all native flows. > Disabling NAT44 on a MAP-T CE, would appear to be sufficient to allow a > MAP-T CE to be used in an xlat464 mode. > > 5. Mesh vs hub-spoke communication modes > xlat464 allows only hub-spoke communication between CLAT and the core PLA= T. > In MAP-T, both hub&spoke and mesh mode are allowed, with the latter being= an > optional extension/optimization enabled by specific additional configurat= ion > of the CE. > I am not sure how that would work in a real network or why it is desirable. Probably off topic. That said, the DNS Pref64/n discovery is dynamic. This is a feature i use for geo-redundancy and may also be used for load sharing.... it is similar to mesh, but that is not a stated goal of the draft. One could say that MAP-T keeps the IPv4 resource tightly coupled with the edge network while 464XLAT allows them to be loosely coupled. > Thus,in terms of specification, between xlat464 and MAP-T there appears t= o > be a decent case for a converged stateless NAT64 mode of > operation/configuration of CLAT/CE elements, allowing their use across bo= th > architectures. This would effectively make the type of "core" NAT to beco= me > a deployment choice, rather than a rule linked to the client devices. > No, i disagree. The MAP work seems to be a "design by committee" and the 464XLAT is more of a ground-up "solve for x", where x is whatever it takes to make IPv6-only networks have service parity with IPv4-only status quo networks. And, it works today. I sent the deployment report showing 100% service parity with IPv4 on Android phones, no one has challenged those results. In all honesty, i turned my own nose up at NAT46 on the handset at first. I had the same perspective as James Woodyatt, those IPv4-only apps will get their just desserts.... But, then the folks on this board changed my mind http://talk.maemo.org/showthread.php?t=3D60320 They solved their own problems with NAT46 on the handset, and it worked. I can't argue with results and running code. CB > Regards, > Wojciech > > > On 3 February 2012 21:17, Cameron Byrne wrote: >> >> Hi, >> >> I have recently concluded a simple initial experimental deployment >> 464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android >> Nexus S phone. >> >> The high level summary is that a sample of the top ~200 free Android >> apps that use network services (ie not a calculator with no ads), >> ~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a >> stock Android 4.0 (ICS) on a stock Nexus S phone. >> >> When using custom 464XLAT code [3] on Android, 100% of =A0the ~15% of >> apps that failed in the initial test now work. The 464XLAT CLAT code >> on the Android allowed for IPv4 socket bindings and IPv4 referrals to >> proceed on the IPv6-only network by doing RFC 6145 protocol >> translation locally on the phone. =A0The tested application sample set >> is at [4]. >> >> I believe this simple experiment running real code on a real network >> shows the value of draft-mawatari-v6ops-464xlat for enabling network >> operators to embrace IPv6-only networks as the going forward future of >> access networks. 464XLAT, like NAT64/DNS64, is a bridge technology >> that makes IPv6 deployment feasible without harming the customer >> experience. =A0464XLAT, like DNS64/NAT64, is not used when apps and >> service are IPv6 native. =A0Thus, as IPv6 deployment progresses across >> the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of >> service. >> >> I hope the problem statement that draft-mawatari-v6ops-464xlat >> addresses is clear as it applies to this trial: 15% of applications >> for this sample in the Android market require IPv4 addresses. >> >> And, i hope the proposed applicability and usefulness of 464XLAT is >> clear as it applies to this trial: =A0464XLAT allows for 100% >> functionality of all applications in the sample and is only used when >> IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...). >> >> I do have 2 requests of =A0the group. =A0First, please read and comment = on >> draft-mawatari-v6ops-464xlat [1]. =A0We are looking for working group >> adoption of this draft since we believe it will broadly support the >> ability of network operators to move forward with IPv6 in the near >> term (code is running, network is deployed). =A0Right now, some networks >> feel they are held back by "IPv6 spoilers" like Skype that require >> IPv4. =A0But now, even Skype works on IPv6 with the help of 464XLAT :) . >> =A0I would like to emphasize that Skype and others MUST still deploy and >> support IPv6. =A0That said, we cannot let their failure hold the rest of >> us back. =A0Second, the IPv4 exhaustion problem is real and now, the >> urgency must be high. =A0Please also comment to the folks at Android >> that this code should be brought into the Android main line >> distribution because network operators (v6ops) need it to continue >> growing the Internet and restoring the end-to-end principle [5]. >> >> Thanks, >> >> Cameron >> >> ps. =A0Big thanks to Dan Drown for open-sourcing his CLAT code! >> >> >> [1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat >> >> [2] http://goo.gl/HGmsy or >> https://sites.google.com/site/tmoipv6/lg-mytouch >> >> [3] =A0http://code.google.com/p/android-clat/ and >> http://dan.drown.org/android/clat/ =A0and >> >> [4] http://goo.gl/z3j3q =A0or >> >> https://docs.google.com/spreadsheet/ccc?key=3D0AnVbRg3DotzFdGVwZWlWeG5wX= zVMcG5qczZEZloxWGc >> >> [5] =A0http://goo.gl/W55YQ or http >> >> ://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select-= devices-here-is-what-it-all-means-and-yes-no-more-nat/ >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From wdec.ietf@gmail.com Thu Feb 16 01:34:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730A821F86D8 for ; Thu, 16 Feb 2012 01:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZeQ-Zj3wM6Q for ; Thu, 16 Feb 2012 01:34:42 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B0D0521F86D3 for ; Thu, 16 Feb 2012 01:34:41 -0800 (PST) Received: by qan41 with SMTP id 41so2119472qan.10 for ; Thu, 16 Feb 2012 01:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MTpxS/WxH0emcAPsesZa97J9qQXKyTJDG2Q9T7udw1Y=; b=vRFW/Vsv4KFoGcakKw7BbiIv4XBHT5YkmGqE19fPdbmOvzdc6zWIOt+rnEPoSwyoI7 bpg44sk09o+v7jJgXcMTrBZK0fD0vdCmeHt3taK4dbDY8dXWixlAFgviV7tuJuaU1fbJ quWrMvkYRAwYGmzzPM4NtSxTtrPZNS5NrdZcM= MIME-Version: 1.0 Received: by 10.229.76.139 with SMTP id c11mr1473180qck.1.1329384877143; Thu, 16 Feb 2012 01:34:37 -0800 (PST) Received: by 10.229.82.201 with HTTP; Thu, 16 Feb 2012 01:34:37 -0800 (PST) In-Reply-To: References: Date: Thu, 16 Feb 2012 10:34:37 +0100 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=002354470ab05f355704b9118905 Cc: IPv6 Ops WG , Jan@go6.si Subject: Re: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 09:34:46 -0000 --002354470ab05f355704b9118905 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 16 February 2012 07:47, Cameron Byrne wrote: > Trying to understand your feedback more > > On Wed, Feb 15, 2012 at 1:27 PM, Wojciech Dec wrote: > > Hi Cameron, All, > > > > I think that this work is very useful and am supporting that it be > > Thanks. It is hard to argue with a solution that solves a real > problem (15% app breakage in the Android market) > > > documented at least as an experiment, however in its current form it does > > carry new normative text, and it also has a handful of technical items > that > > Please explain in detail about the new normative text and what this > means to the draft. > The draft contains rfc2119 text/type of requirements, that are specific to this architecture specification. What this means, is that the draft is more than a report on a trial/deployment/experiment. > > > deserve to be seen in the context of related work. > > In particular both xlat464 and MAP-T (softwires) architecture utilize > > stateless NAT64 on their CLAT/CE elements but differ in how it's allowed > to > > Why is this relevant? MAP-T and 464XLAT both reference and use RFC6145. > So... ? > xlat464 appears to selectively tailor nat64 use into a very specific case. That's fine that for you that it's your case, but it shouldn't automatically be the standards rule for all deployments, especially since it appears eminently possible to have a common approach and actually quite close. On this note, I would like to ask, why do you think that such a common approach is not desirable or relevant? > > be configured. Both documents carry normative requirements for such > > functionality beyond the base RFCs. Avoiding incompatible architectures, > > while both being based on NAT64, would appear to be a reasonable goal to > > have for standardization. > > > > Why is this desirable? The solution space is already very crowded, > one more does not really change that. We have documented a network > architecture that effectively does RFC 6145 at the CPE/UE and RFC6146 > in the network. Relative to other solutions, we believe this is > simple and deployable. In fact, it is already coded and deployed. > Running code means a lot in the IETF. > Ironically, that's what standardization is about. I'm not arguing that your deployment model & solution be ignored, but I am arguing that it doesn't need to create another splinter in the solution space. Past poor precedent shouldn't necessarily be an excuse for more of it. > > In some more detail the main contrasts between the current MAP-T and > xlat464 > > drafts appear to be the following: > > > > 1. CLAT/CE compatibility with "core" NAT64 element > > Xlat464 appears to assume the use of implicit IPv4-in-IPv6 addressing for > > the CLAT's address, whereby the IPv4 address "part" would likely be the > same > > across multiple CLATs, and correspond to some private IPv4 address. This > > would be sufficent to communication brokenness should such a CLAT be > > I would not call this brokenness. We have made this out of scope, and > it is in fact the same status quo that most home broadband users have > today with IPv4. Most home broadband users have 192.168.0.x/24 > overlapping space in their homes and they cannot communicate with each > other directly. The same is true for 464XLAT IPv4 services. We are > not looking to improve the IPv4 service, we are looking to replace it > with IPv6-only and provide service level parity. > It's not quite the status quo. Most users in home broadband get an explicit public IPv4 address from their SP. The problem can be illustrated by this example: - CLAT #1 has prefix 2001:db8:1::/64 and implicit address 192.168.0.1 for a host. The CLAT address would be 2001:db8:1::c0a8:0001 - CLAT #2 has prefix 2001:db8:2::/64 and implicit address 192.168.0.1 for a host. The CLAT address would be 2001:db8:2::c0a8:0001 There appears no way to have the above work in any practical sense with a stateless NAT64 core. The solution, in theory, would be to allow the CLAT to be configurable in terms of the prefix it uses and the IPv4-in-IPv6 explicit addresses, eg 1.1.1.1, and 1.1.1.2 for each host. It would be fine except that the CLAT spec does not allow this in practical terms since it casts a definition around a /96 (the xlat464 address format in section 6.1). And, we know that anything longer than a /64 doesn't work well for deployment in most SP networks, esp 3gpp ones. Again the solution would be to allow to allow both the prefix and addresses to be configurable, as required by an operator. > > We believe this has been achieved. Once again, running code in place, > live network. > As I said, I think your work is valuable, worthwhile to document at least in terms of experiment. In terms of running code, congrats and welcome, as there's a bunch of it for the other solutions too. > > > deployed with a stateless NAT64 "core". Regular IPv6 hosts do not have > such > > an issue, since they would not use such implicit addresses. Hence, while > the > > xlat464 architecture is shown to be used in the context of a stateful > NAT64 > > "core" element (PLAT), its current specification would actually not > allowing > > the use of a stateless NAT64 core elment with a CLAT device. > > In contrast, MAP-T architecture, and MAP-T CE while depicted in terms of > a > > stateless NAT64 core element, is compatible with a stateful core NAT64 > > element too. > > > > 2. NAT64 prefix configuration > > Both a MAP-T CE and xlat464 CLAT need to find the prefix of the core > NAT64 > > translator. The MAP-T envisaged achieving this by configuration (eg the > > MAP-T DHCPv6 option being specified), while xlat464 indicates that a > NAT64 > > prefix discovery "via some method" (not specified, likely DNS) will be > used. > > > > We reference a BEHAVE draft on how this can be achieved, but we leave > it open for other methods as well since it is not core to the > solution. Regarding DNS heuristics for Pref64 discovery, we have > running code for this function. > It is core to the solution since without a consistent configuration method, it won't work reliably (or at all). Again, this seems to be an area where a common standard would be desirable. > > 3. Embedded IPv4-in-IPv6 address assignment to CE/CLAT > > xlat464 does not appear to deal with a a determinate IPv4inIPv6 address > to > > be assigned and presented to a CLAT device, or not running into some > severe > > IPv6 addressing mode restrictions (eg 128 bit addressing not being > supported > > by 3GPP) - a topic that MAP-T faced initially. > > With MAP-T a determinate, public or private, IPv4 address is allowed to > be > > allocated and presented to a CE device as part of its IPv6 prefix (eg > /64) > > assignment and algorithm MAP address derivation. > > > > I am not sure what you are talking about above. We do not have any > requirements for determinate IPv4 addressing in 464XLAT. > > > 4. The CLAT/CE NAT44 functionality and subtended IPv4 hosts. > > The xlat464 CLAT assumes no NAT44. Any subtended IPv4 host/address are > > mapped statelessly to individual IPv6 address within the CLAT's /96 > prefix. > > With MAP-T a CE is taken to have a NAT44 component, and this multiplexes > > any/all subtended private IPv4 hosts behind the MAP derived IPv4 address > > which is then statelessly mapped to an IPv6 prefix. > > So MAP-T does NAT44 -> NAT46 -> NAT64 ? 3x NAT in all IPv4 server > cases? ..... so 99% of websites will run through that ? :/ > Well, it so happens that the NAT44 element would not be the likely culprit for anything short of the 99% (judging by how the internet runs today). The dual NAT64 aspect is something that both xlat464 and MAP-T utilize. > > The 464XLAT architecture with DNS64 is 1 NAT in most cases (99% of the > web...ie nearly everything without an IPv4 literal / referral ). It > is 2 NATs at most NAT46 <-> NAT64 in the case of IPv4 only > applications or hosts (Xbox?). And of course, IPv6 native end to end > for all native flows. > > > Disabling NAT44 on a MAP-T CE, would appear to be sufficient to allow a > > MAP-T CE to be used in an xlat464 mode. > > > > 5. Mesh vs hub-spoke communication modes > > xlat464 allows only hub-spoke communication between CLAT and the core > PLAT. > > In MAP-T, both hub&spoke and mesh mode are allowed, with the latter > being an > > optional extension/optimization enabled by specific additional > configuration > > of the CE. > > > > I am not sure how that would work in a real network or why it is > desirable. Probably off topic. > > That said, the DNS Pref64/n discovery is dynamic. This is a feature i > use for geo-redundancy and may also be used for load sharing.... it is > similar to mesh, but that is not a stated goal of the draft. > > One could say that MAP-T keeps the IPv4 resource tightly coupled with > the edge network while 464XLAT allows them to be loosely coupled. > One could rather say that IPv4 resource coupling is a factor that varies based on the type of deployment. One can see an XLAT464 PLAT function in edge network devices. > > > Thus,in terms of specification, between xlat464 and MAP-T there appears > to > > be a decent case for a converged stateless NAT64 mode of > > operation/configuration of CLAT/CE elements, allowing their use across > both > > architectures. This would effectively make the type of "core" NAT to > become > > a deployment choice, rather than a rule linked to the client devices. > > > > No, i disagree. The MAP work seems to be a "design by committee" and > the 464XLAT is more of a ground-up "solve for x", where x is whatever > it takes to make IPv6-only networks have service parity with IPv4-only > status quo networks. And, it works today. I sent the deployment > report showing 100% service parity with IPv4 on Android phones, no one > has challenged those results. > Well, the thing is that if MAP solves your problem x, and along the way it also solves other problems that are relevant, call it whatever you want, but the process of getting it standardized is worth it, as opposed to the point solution case. There have been similar, perhaps less publicised results (and not specific to Android) results for the other technologies too (presented at the softwire intrim). You called for the WG endorsement of a technical specification which IMO carries both normative specification material and the results of your experiments. I have no issue with documenting your results, or endorsing/supporting the approach for that matter, but I also do think that endorsing the specification part without wider consideration is premature. Regards, Woj. > In all honesty, i turned my own nose up at NAT46 on the handset at > first. I had the same perspective as James Woodyatt, those IPv4-only > apps will get their just desserts.... But, then the folks on this > board changed my mind http://talk.maemo.org/showthread.php?t=60320 > They solved their own problems with NAT46 on the handset, and it > worked. > > I can't argue with results and running code. > > CB > > > Regards, > > Wojciech > > > > > > On 3 February 2012 21:17, Cameron Byrne wrote: > >> > >> Hi, > >> > >> I have recently concluded a simple initial experimental deployment > >> 464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android > >> Nexus S phone. > >> > >> The high level summary is that a sample of the top ~200 free Android > >> apps that use network services (ie not a calculator with no ads), > >> ~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a > >> stock Android 4.0 (ICS) on a stock Nexus S phone. > >> > >> When using custom 464XLAT code [3] on Android, 100% of the ~15% of > >> apps that failed in the initial test now work. The 464XLAT CLAT code > >> on the Android allowed for IPv4 socket bindings and IPv4 referrals to > >> proceed on the IPv6-only network by doing RFC 6145 protocol > >> translation locally on the phone. The tested application sample set > >> is at [4]. > >> > >> I believe this simple experiment running real code on a real network > >> shows the value of draft-mawatari-v6ops-464xlat for enabling network > >> operators to embrace IPv6-only networks as the going forward future of > >> access networks. 464XLAT, like NAT64/DNS64, is a bridge technology > >> that makes IPv6 deployment feasible without harming the customer > >> experience. 464XLAT, like DNS64/NAT64, is not used when apps and > >> service are IPv6 native. Thus, as IPv6 deployment progresses across > >> the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of > >> service. > >> > >> I hope the problem statement that draft-mawatari-v6ops-464xlat > >> addresses is clear as it applies to this trial: 15% of applications > >> for this sample in the Android market require IPv4 addresses. > >> > >> And, i hope the proposed applicability and usefulness of 464XLAT is > >> clear as it applies to this trial: 464XLAT allows for 100% > >> functionality of all applications in the sample and is only used when > >> IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...). > >> > >> I do have 2 requests of the group. First, please read and comment on > >> draft-mawatari-v6ops-464xlat [1]. We are looking for working group > >> adoption of this draft since we believe it will broadly support the > >> ability of network operators to move forward with IPv6 in the near > >> term (code is running, network is deployed). Right now, some networks > >> feel they are held back by "IPv6 spoilers" like Skype that require > >> IPv4. But now, even Skype works on IPv6 with the help of 464XLAT :) . > >> I would like to emphasize that Skype and others MUST still deploy and > >> support IPv6. That said, we cannot let their failure hold the rest of > >> us back. Second, the IPv4 exhaustion problem is real and now, the > >> urgency must be high. Please also comment to the folks at Android > >> that this code should be brought into the Android main line > >> distribution because network operators (v6ops) need it to continue > >> growing the Internet and restoring the end-to-end principle [5]. > >> > >> Thanks, > >> > >> Cameron > >> > >> ps. Big thanks to Dan Drown for open-sourcing his CLAT code! > >> > >> > >> [1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat > >> > >> [2] http://goo.gl/HGmsy or > >> https://sites.google.com/site/tmoipv6/lg-mytouch > >> > >> [3] http://code.google.com/p/android-clat/ and > >> http://dan.drown.org/android/clat/ and > >> > >> [4] http://goo.gl/z3j3q or > >> > >> > https://docs.google.com/spreadsheet/ccc?key=0AnVbRg3DotzFdGVwZWlWeG5wXzVMcG5qczZEZloxWGc > >> > >> [5] http://goo.gl/W55YQ or http > >> > >> :// > www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select-devices-here-is-what-it-all-means-and-yes-no-more-nat/ > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > --002354470ab05f355704b9118905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 16 February 2012 07:47, Cameron By= rne <cb.list6@gm= ail.com> wrote:
Trying to understand your feedback more

On Wed, Feb 15, 2012 at 1:27 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> Hi Cameron, All,
>
> I think that this work is very useful and am supporting that it be

Thanks. =A0It is hard to argue with a solution that solves a real
problem (15% app breakage in the Android market)

> documented at least as an experiment, however in its current form it d= oes
> carry new normative text, and it also has a handful of technical items= that

Please explain in detail about the new normative text and what this means to the draft.

The draft contains rfc2119 tex= t/type of requirements, that are specific to this architecture specificatio= n. What this means, is that the draft is more than a report on a trial/depl= oyment/experiment.
=A0

> deserve to be seen in the context of related work.
> In particular both xlat464 and MAP-T (softwires) architecture utilize<= br> > stateless NAT64 on their CLAT/CE elements but differ in how it's a= llowed to

Why is this relevant? =A0MAP-T and 464XLAT both reference and use RFC= 6145. So... ?

xlat464 appears to selectively tailo= r nat64 use into a very specific case. That's fine that for you that it= 's your case, but it shouldn't automatically be the standards rule = for all deployments, especially since it appears eminently possible to have= a common approach and actually quite close.
On this note, I would like to ask, why do you think that such a common appr= oach is not desirable or relevant?



> be configured. Both documents carry normative requirements for such > functionality beyond the base RFCs. Avoiding incompatible architecture= s,
> while both being based on NAT64, would appear to be a reasonable goal = to
> have for standardization.
>

Why is this desirable? =A0The solution space is already very crowded,=
one more does not really change that. =A0We have documented a network
architecture that effectively does RFC 6145 at the CPE/UE and RFC6146
in the network. =A0Relative to other solutions, we believe this is
simple and deployable. In fact, it is already coded and deployed.
Running code means a lot in the IETF.

Ironically, = that's what standardization is about. I'm not arguing that your dep= loyment model & solution be ignored, but I am arguing that it doesn'= ;t need to create another splinter in the solution space. Past poor precede= nt shouldn't necessarily be an excuse for more of it.


> In some more detail the main contrasts between the current MAP-T and x= lat464
> drafts appear to be the following:
>
> 1. CLAT/CE compatibility with "core" NAT64 element
> Xlat464 appears to assume the use of implicit IPv4-in-IPv6 addressing = for
> the CLAT's address, whereby the IPv4 address "part" woul= d likely be the same
> across multiple CLATs, and correspond to some private IPv4 address. Th= is
> would be sufficent to communication brokenness should such a CLAT be
I would not call this brokenness. =A0We have made this out of scope, = and
it is in fact the same status quo that most home broadband users have
today with IPv4. =A0Most home broadband users have 192.168.0.x/24
overlapping space in their homes and they cannot communicate with each
other directly. =A0The same is true for 464XLAT IPv4 services. =A0We are not looking to improve the IPv4 service, we are looking to replace it
with IPv6-only and provide service level parity.

I= t's not quite the status quo. Most users in home broadband get an expli= cit public IPv4 address from their SP.
The problem can be illustrated by= this example:
- CLAT #1 has prefix 2001:db8:1::/64 and implicit address 192.168.0.1 for a= host. The CLAT address would be 2001:db8:1:<some random clat stuff>:= c0a8:0001
- CLAT #2 has prefix 2001:db8:2::/64 and implicit address 192.= 168.0.1 for a host. The CLAT address would be 2001:db8:2:<some random c= lat stuff>:c0a8:0001

There appears no way to have the above work in any practical sense with= a stateless NAT64 core.
The solution, in theory, would be to allow the = CLAT to be configurable in terms of the prefix it uses and the IPv4-in-IPv6= explicit addresses, eg 1.1.1.1, and 1.1.1.2 for each host. It would be fin= e except that the CLAT spec does not allow this in practical terms since it= casts a definition around a /96 (the xlat464 address format in section 6.1= ). And, we know that anything longer than a /64 doesn't work well for d= eployment in most SP networks, esp 3gpp ones. Again the solution would be t= o allow to allow both the prefix and addresses to be configurable, as requi= red by an operator.
=A0

We believe this has been achieved. =A0Once again, running code in place, live network.

As I said, I think your work is valu= able, worthwhile to document at least in terms of experiment. In terms of r= unning code, congrats and welcome, as there's a bunch of it for the oth= er solutions too.
=A0

> deployed with a stateless NAT64 "core". Regular IPv6 hosts d= o not have such
> an issue, since they would not use such implicit addresses. Hence, whi= le the
> xlat464 architecture is shown to be used in the context of a stateful = NAT64
> "core" element (PLAT), its current specification would actua= lly not allowing
> the use of a stateless NAT64 core elment with a CLAT device.
> In contrast, MAP-T architecture, and MAP-T CE while depicted in terms = of a
> stateless NAT64 core element, is compatible with a stateful core NAT64=
> element too.
>
> 2. NAT64 prefix configuration
> Both a MAP-T CE and xlat464 CLAT need to find the prefix of the core N= AT64
> translator. The MAP-T envisaged achieving this by configuration (eg th= e
> MAP-T DHCPv6 option being specified), while xlat464 indicates that a N= AT64
> prefix discovery "via some method" (not specified, likely DN= S) will be used.
>

We reference a BEHAVE draft on how this can be achieved, but we leave=
it open for other methods as well since it is not core to the
solution. Regarding DNS heuristics for Pref64 discovery, we have
running code for this function.

It is core to the = solution since without a consistent configuration method, it won't work= reliably (or at all). Again, this seems to be an area where a common stand= ard would be desirable.


> 3. Embedded IPv4-in-IPv6 address assignment to CE/CLAT
> xlat464 does not appear to deal with a a determinate IPv4inIPv6 addres= s to
> be assigned and presented to a CLAT device, or not running into some s= evere
> IPv6 addressing mode restrictions (eg 128 bit addressing not being sup= ported
> by 3GPP) - a topic that MAP-T faced initially.
> With MAP-T a determinate, public or private, IPv4 address is allowed t= o be
> allocated and presented to a CE device as part of its IPv6 prefix (eg = /64)
> assignment and algorithm MAP address derivation.
>

I am not sure what you are talking about above. =A0We do not have any=
requirements for determinate IPv4 addressing in 464XLAT.

> 4. The CLAT/CE NAT44 functionality and subtended IPv4 hosts.
> The xlat464 CLAT assumes no NAT44. Any subtended IPv4 host/address are=
> mapped statelessly to individual IPv6 address within the CLAT's /9= 6 prefix.
> With MAP-T a CE is taken to have a NAT44 component, and this multiplex= es
> any/all subtended private IPv4 hosts behind the MAP derived IPv4 addre= ss
> which is then statelessly mapped to an IPv6 prefix.

So =A0MAP-T does NAT44 -> NAT46 -> NAT64 ? =A03x NAT in all IPv= 4 server
cases? ..... so 99% of websites will run through that ? =A0:/

Well, it so happens that the NAT44 element would not be the lik= ely culprit for anything short of the 99% (judging by how the internet runs= today). The dual NAT64 aspect is something that both xlat464 and MAP-T uti= lize.

The 464XLAT architecture with DNS64 is 1 NAT in most cases (99% of the
web...ie nearly everything without an IPv4 literal / referral ). =A0It
is 2 NATs at most NAT46 <-> NAT64 in the case of IPv4 only
applications or hosts (Xbox?). =A0And of course, IPv6 native end to end
for all native flows.

> Disabling NAT44 on a MAP-T CE, would appear to be sufficient to allow = a
> MAP-T CE to be used in an xlat464 mode.
>
> 5. Mesh vs hub-spoke communication modes
> xlat464 allows only hub-spoke communication between CLAT and the core = PLAT.
> In MAP-T, both hub&spoke and mesh mode are allowed, with the latte= r being an
> optional extension/optimization enabled by specific additional configu= ration
> of the CE.
>

I am not sure how that would work in a real network or why it is
desirable. =A0Probably off topic.

That said, the DNS Pref64/n discovery is dynamic. This is a feature i
use for geo-redundancy and may also be used for load sharing.... it is
similar to mesh, but that is not a stated goal of the draft.

One could say that MAP-T keeps the IPv4 resource tightly coupled with
the edge network while 464XLAT allows them to be loosely coupled.

One could rather say that IPv4 resource coupling is a facto= r that varies based on the type of deployment. One can see an XLAT464 PLAT = function in edge network devices.
=A0

> Thus,in terms of specification, between xlat464 and MAP-T there appear= s to
> be a decent case for a converged stateless NAT64 mode of
> operation/configuration of CLAT/CE elements, allowing their use across= both
> architectures. This would effectively make the type of "core"= ; NAT to become
> a deployment choice, rather than a rule linked to the client devices.<= br> >

No, i disagree. =A0The MAP work seems to be a "design by committ= ee" and
the 464XLAT is more of a ground-up "solve for x", where x is what= ever
it takes to make IPv6-only networks have service parity with IPv4-only
status quo networks. =A0And, it works today. =A0I sent the deployment
report showing 100% service parity with IPv4 on Android phones, no one
has challenged those results.

Well, the thing is t= hat if MAP solves your problem x, and along the way it also solves other pr= oblems that are relevant, call it whatever you want, but the process of get= ting it standardized is worth it, as opposed to the point solution case. There have been similar, perhaps less publicised results (and not specific = to Android) results for the other technologies too (presented at the softwi= re intrim).

You called for the WG endorsement of a technical specifi= cation which IMO carries both normative specification material and the resu= lts of your experiments. I have no issue with documenting your results, or = endorsing/supporting the approach for that matter, but I also do think that= endorsing the specification part without wider consideration is premature.=

Regards,
Woj.


In all honesty, i turned my own nose up at NAT46 on the handset at
first. =A0I had the same perspective as James Woodyatt, those IPv4-only
apps will get their just desserts.... =A0 But, then the folks on this
board changed my mind =A0http://talk.maemo.org/showthread.php?t=3D60320<= /a>
They solved their own problems with NAT46 on the handset, and it
worked.

I can't argue with results and running code.

CB

> Regards,
> Wojciech
>
>
> On 3 February 2012 21:17, Cameron Byrne <cb.list6@gmail.com> wrote:
>>
>> Hi,
>>
>> I have recently concluded a simple initial experimental deployment=
>> 464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an And= roid
>> Nexus S phone.
>>
>> The high level summary is that a sample of the top ~200 free Andro= id
>> apps that use network services (ie not a calculator with no ads),<= br> >> ~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a=
>> stock Android 4.0 (ICS) on a stock Nexus S phone.
>>
>> When using custom 464XLAT code [3] on Android, 100% of =A0the ~15%= of
>> apps that failed in the initial test now work. The 464XLAT CLAT co= de
>> on the Android allowed for IPv4 socket bindings and IPv4 referrals= to
>> proceed on the IPv6-only network by doing RFC 6145 protocol
>> translation locally on the phone. =A0The tested application sample= set
>> is at [4].
>>
>> I believe this simple experiment running real code on a real netwo= rk
>> shows the value of draft-mawatari-v6ops-464xlat for enabling netwo= rk
>> operators to embrace IPv6-only networks as the going forward futur= e of
>> access networks. 464XLAT, like NAT64/DNS64, is a bridge technology=
>> that makes IPv6 deployment feasible without harming the customer >> experience. =A0464XLAT, like DNS64/NAT64, is not used when apps an= d
>> service are IPv6 native. =A0Thus, as IPv6 deployment progresses ac= ross
>> the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of >> service.
>>
>> I hope the problem statement that draft-mawatari-v6ops-464xlat
>> addresses is clear as it applies to this trial: 15% of application= s
>> for this sample in the Android market require IPv4 addresses.
>>
>> And, i hope the proposed applicability and usefulness of 464XLAT i= s
>> clear as it applies to this trial: =A0464XLAT allows for 100%
>> functionality of all applications in the sample and is only used w= hen
>> IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...). >>
>> I do have 2 requests of =A0the group. =A0First, please read and co= mment on
>> draft-mawatari-v6ops-464xlat [1]. =A0We are looking for working gr= oup
>> adoption of this draft since we believe it will broadly support th= e
>> ability of network operators to move forward with IPv6 in the near=
>> term (code is running, network is deployed). =A0Right now, some ne= tworks
>> feel they are held back by "IPv6 spoilers" like Skype th= at require
>> IPv4. =A0But now, even Skype works on IPv6 with the help of 464XLA= T :) .
>> =A0I would like to emphasize that Skype and others MUST still depl= oy and
>> support IPv6. =A0That said, we cannot let their failure hold the r= est of
>> us back. =A0Second, the IPv4 exhaustion problem is real and now, t= he
>> urgency must be high. =A0Please also comment to the folks at Andro= id
>> that this code should be brought into the Android main line
>> distribution because network operators (v6ops) need it to continue=
>> growing the Internet and restoring the end-to-end principle [5]. >>
>> Thanks,
>>
>> Cameron
>>
>> ps. =A0Big thanks to Dan Drown for open-sourcing his CLAT code! >>
>>
>> [1] http://tools.ietf.org/html/draft-mawatari-v6ops-464= xlat
>>
>> [2] http://goo.g= l/HGmsy or
>> https://sites.google.com/site/tmoipv6/lg-mytouch
>>
>> [3] =A0http://code.google.com/p/android-clat/ and
>> h= ttp://dan.drown.org/android/clat/ =A0and
>>
>> [4] http://goo.g= l/z3j3q =A0or
>>
>> https://docs.google.= com/spreadsheet/ccc?key=3D0AnVbRg3DotzFdGVwZWlWeG5wXzVMcG5qczZEZloxWGc<= br> >>
>> [5] =A0http://go= o.gl/W55YQ or http
>>
>> ://www.androidpolice.com/2012/01/29/t-mobile-usa-testin= g-ipv6-on-select-devices-here-is-what-it-all-means-and-yes-no-more-nat/=
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>

--002354470ab05f355704b9118905-- From azael@redes.unam.mx Thu Feb 16 11:58:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAFA21F886C for ; Thu, 16 Feb 2012 11:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.536 X-Spam-Level: X-Spam-Status: No, score=0.536 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_MX=0.535] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM5oJHLTvNg2 for ; Thu, 16 Feb 2012 11:58:20 -0800 (PST) Received: from necti.redes.unam.mx (necti.redes.unam.mx [132.248.115.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8432521E8022 for ; Thu, 16 Feb 2012 11:58:18 -0800 (PST) Received: from necti.redes.unam.mx (unknown [132.248.115.83]) by necti.redes.unam.mx (Postfix) with ESMTP id D27CC504003 for ; Thu, 16 Feb 2012 14:09:07 -0600 (CST) Date: Thu, 16 Feb 2012 14:09:07 -0600 (CST) From: Azael Fernandez Alcantara To: v6ops WG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [v6ops] MIPv6 use cases and equipment suggestions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:58:24 -0000 Hi all, We have been trying to get some references of MIPv6 use cases, but not yet enough information. And we have been using some simulation models such as: http://www.kn.e-technik.tu-dortmund.de/de/forschung/ausstattung/xmipv6.html Any suggestion of equipment and use cases you can share with us, would be greatly appreciate. Thanks in advance. BEST, SALUDOS, _________________________ Azael Fernandez Alcantara Special Projects Manager National Autonomous University of Mexico (UNAM) Telecommunications Direction (DT)-NETLab Circuito Exterior S/N, Ciudad Universitaria C.P. 04510, Mexico, D.F. Phone (52) 55 56 22 88 57 __________________________________________ url: www.netlab.unam.mx url: www.ipv6.unam.mx From victor.kuarsingh@gmail.com Thu Feb 16 16:31:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC8D21E8079 for ; Thu, 16 Feb 2012 16:31:10 -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.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p39ynAekJphP for ; Thu, 16 Feb 2012 16:31:06 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C02621F874A for ; Thu, 16 Feb 2012 16:31:06 -0800 (PST) Received: by iagf6 with SMTP id f6so4277610iag.31 for ; Thu, 16 Feb 2012 16:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=NppeNi4zYgSXY9HbzwnDEUQkS+o2f8Vc7MkXzzMszEo=; b=GvPaYeA0pJoWTcv45FJUQMQmgiSQ5hvqxbuZdHF0HC5HH+if3cESJbue+6yPAsuAHL ZBdLZK6Q0gf6YtW8VXCJWiEzV4l/oKyGn9YMRgPlQA3k/7WTy5PlgvuALoV11ZDtI2DV jXjQYqojR2fMxp/rcUwLmmQjU6WSEdxUc0Ezg= Received: by 10.42.177.133 with SMTP id bi5mr5483357icb.40.1329438665771; Thu, 16 Feb 2012 16:31:05 -0800 (PST) Received: from [192.168.100.89] ([67.224.83.162]) by mx.google.com with ESMTPS id l28sm13097018ibc.3.2012.02.16.16.31.04 (version=SSLv3 cipher=OTHER); Thu, 16 Feb 2012 16:31:05 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 16 Feb 2012 19:31:02 -0500 From: Victor Kuarsingh To: , Message-ID: Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-464xlat In-Reply-To: <201202151455.q1FEt0K02883@ftpeng-update.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 00:31:10 -0000 Fred, This work in my mind represents important work that should continue. Putting a mobile operator hat on, it provides the last bit of functionally to make IPv6 with NAT64 a real and workable option for Wireless deployments based on known behaviours in commercially available product (I.e. Infrequent, but need for IPv4 connections). Given the content in the draft and testing/results provided thus far, it appears to be a viable option with a number of benefits (especially in the mobile space related to PCC complacence). I would support this work in whichever forum (group) it should exist. Regards, Victor K On 12-02-15 9:55 AM, "fred@cisco.com" wrote: > >A new draft has been posted, at >http://tools.ietf.org/html/draft-ietf-v6ops-464xlat. Please take a look >at it and comment. >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From tsavo.stds@gmail.com Fri Feb 17 00:42:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC80621F852A for ; Fri, 17 Feb 2012 00:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8bhAMLdKqjG for ; Fri, 17 Feb 2012 00:42:48 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D528521F8503 for ; Fri, 17 Feb 2012 00:42:48 -0800 (PST) Received: by obbwd15 with SMTP id wd15so4717761obb.31 for ; Fri, 17 Feb 2012 00:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=ccuhAJ3KwdhDlb5fRMdi9QfxGShSoIYQvEjuROVjbQs=; b=R+AJLfY4jhHOYUJA3uFdv1nFt/clqegpKpm8hgtUYNyVAJGkBhCTHKik/aHLsBBWc9 lEkPEy9gcpcYBAmAaVnOHFU5D/mufEGwo6vxm4Ze/MqqI6/Pr6zVM0d/UdEvvNRrnzoB h6zPUFu2hjBigIsebQ/sAu8rtlsuOlFa+ROyA= MIME-Version: 1.0 Received: by 10.182.88.70 with SMTP id be6mr4484265obb.36.1329468168359; Fri, 17 Feb 2012 00:42:48 -0800 (PST) Received: by 10.60.30.34 with HTTP; Fri, 17 Feb 2012 00:42:48 -0800 (PST) Date: Fri, 17 Feb 2012 10:42:48 +0200 Message-ID: From: Teemu Savolainen To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=14dae9399097ea50a304b924ede9 Subject: [v6ops] PD-exclude was approved by the IESG -> should be included into 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 08:42:49 -0000 --14dae9399097ea50a304b924ede9 Content-Type: text/plain; charset=ISO-8859-1 Hi v6ops, You may have already noticed that draft-ietf-dhc-pd-exclude-04 was yesterday approved by the IESG. I would like to add to the draft-ietf-v6ops-6204bis section 4.2 a new requirement (to W-4, or maybe to the WPD-x series) that says support for pd-exclude is a SHALL for IPv6 CE router. Best regards, Teemu FYI: --- State changed to Approved-announcement to be sent from IESG Evaluation. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dhc-pd-exclude/ --14dae9399097ea50a304b924ede9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi v6ops,

You may have already noticed that draft-ietf-dhc-pd-exclud= e-04 was yesterday approved by the IESG.

I would like to add to the = draft-ietf-v6ops-6204bis section 4.2 a new requirement (to W-4, or maybe to= the WPD-x series) that says support for pd-exclude is a SHALL for IPv6 CE = router.

Best regards,

Teemu


FYI: ---

State changed to Approved-announcement to be sent= from IESG Evaluation.

ID Tracker URL: http://datatracker.ietf.org/doc/draft= -ietf-dhc-pd-exclude/


--14dae9399097ea50a304b924ede9-- From ales.vizdal@t-mobile.cz Fri Feb 17 00:49:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C25921F8720 for ; Fri, 17 Feb 2012 00:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnPpxhAInQjq for ; Fri, 17 Feb 2012 00:49:05 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id AA3D821F870A for ; Fri, 17 Feb 2012 00:49:04 -0800 (PST) Received: from srvhk504.rdm.cz (unknown [10.246.143.96]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 544F8285802; Fri, 17 Feb 2012 09:49:03 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk504.rdm.cz ([fe80::744e:351e:b5b:fd01%12]) with mapi; Fri, 17 Feb 2012 09:49:03 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Teemu Savolainen , "v6ops@ietf.org" Date: Fri, 17 Feb 2012 09:50:12 +0100 Thread-Topic: [v6ops] PD-exclude was approved by the IESG -> should be included into 6204bis Thread-Index: AcztUDZmGBPV+U9jRoGznMN87rYj6gAANzCA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC67E419127@SRVHKE02.rdm.cz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1808340F7EC362469DDFFB112B37E2FCC67E419127SRVHKE02rdmcz_" MIME-Version: 1.0 Subject: Re: [v6ops] PD-exclude was approved by the IESG -> should be included into 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 08:49:05 -0000 --_000_1808340F7EC362469DDFFB112B37E2FCC67E419127SRVHKE02rdmcz_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable +1 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= eemu Savolainen Sent: Friday, February 17, 2012 9:43 AM To: v6ops@ietf.org Subject: [v6ops] PD-exclude was approved by the IESG -> should be included = into 6204bis Hi v6ops, You may have already noticed that draft-ietf-dhc-pd-exclude-04 was yesterda= y approved by the IESG. I would like to add to the draft-ietf-v6ops-6204bis section 4.2 a new requi= rement (to W-4, or maybe to the WPD-x series) that says support for pd-excl= ude is a SHALL for IPv6 CE router. Best regards, Teemu FYI: --- State changed to Approved-announcement to be sent from IESG Evaluation. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dhc-pd-exclude/ --_000_1808340F7EC362469DDFFB112B37E2FCC67E419127SRVHKE02rdmcz_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

+1

 

From: v6ops-b= ounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Teemu S= avolainen
Sent: Friday, February 17, 2012 9:43 AM
To: v= 6ops@ietf.org
Subject: [v6ops] PD-exclude was approved by the IES= G -> should be included into 6204bis

 

Hi v6ops,
<= br>You may have already noticed that draft-ietf-dhc-pd-exclude-04 was yeste= rday approved by the IESG.

I would like to add to the draft-ietf-v6o= ps-6204bis section 4.2 a new requirement (to W-4, or maybe to the WPD-x ser= ies) that says support for pd-exclude is a SHALL for IPv6 CE router.
Best regards,

Teemu


FYI: ---

State changed to Approved-announcement to be sent from IESG Eva= luation.

ID Tracker URL: http://datatrack= er.ietf.org/doc/draft-ietf-dhc-pd-exclude/

 

= --_000_1808340F7EC362469DDFFB112B37E2FCC67E419127SRVHKE02rdmcz_-- From shemant@cisco.com Fri Feb 17 04:23:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863FD21F853E for ; Fri, 17 Feb 2012 04:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.371 X-Spam-Level: X-Spam-Status: No, score=-8.371 tagged_above=-999 required=5 tests=[AWL=1.627, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j2ghbNn4R2S for ; Fri, 17 Feb 2012 04:23:22 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id AC6CC21F853B for ; Fri, 17 Feb 2012 04:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8907; q=dns/txt; s=iport; t=1329481402; x=1330691002; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=fl1uwp5aIvkoqK5uiMbDz9hseU8N/z7LDcbL1MWVGUA=; b=l+HoTfToCSYj5rXk5B9D8Rb521zPl5xq0S1Z2R26n06X5ERaKBXMMA6q SxPvW3wwRCOuBa38533JgGVZuXwE802DACOFb3I2SFlsa9tDRBsH0dgo7 ca12si/YrQXoMFXiRn9GAS8zCdlORLeqzti6d94Mw9vF/2kjPOUIcza06 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4FAI9FPk+tJXG+/2dsb2JhbABEgk2dUogTAYhSgQeBdQEBAQQSAQkLBgNZAgEIDgMEAQELBhcBBgFFCQgBAQQBEggah2eaAgGecYtugQIDgyUtBAQLGIJRYwSITp9w X-IronPort-AV: E=Sophos;i="4.73,437,1325462400"; d="scan'208,217";a="59745711" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 17 Feb 2012 12:23:22 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1HCNMGo003405; Fri, 17 Feb 2012 12:23:22 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 06:23:22 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: CLKp DqZA D5Yz E5OE E+gs Gv9L I1LY LUzz NP8J QvYJ SG9E S1Ib TTNg Uxir XChJ XDYw; 2; dABzAGEAdgBvAC4AcwB0AGQAcwBAAGcAbQBhAGkAbAAuAGMAbwBtADsAdgA2AG8AcABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {C4198E87-256C-4252-9103-FE23BBF476BD}; cwBoAGUAbQBhAG4AdABAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Fri, 17 Feb 2012 12:23:16 GMT; UgBFADoAIABbAHYANgBvAHAAcwBdACAAUABEAC0AZQB4AGMAbAB1AGQAZQAgAHcAYQBzACAAYQBwAHAAcgBvAHYAZQBkACAAYgB5ACAAdABoAGUAIABJAEUAUwBHACAALQA+ACAAcwBoAG8AdQBsAGQAIABiAGUAIABpAG4AYwBsAHUAZABlAGQAaQBuAHQAbwAgADYAMgAwADQAYgBpAHMA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCED6E.F016573B" x-cr-puzzleid: {C4198E87-256C-4252-9103-FE23BBF476BD} Content-class: urn:content-classes:message Date: Fri, 17 Feb 2012 06:23:16 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304075A3F@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] PD-exclude was approved by the IESG -> should be includedinto 6204bis Thread-Index: AcztUDEWpnq+N5dbSICqfPYGRTjzIAAHp/oQ References: From: "Hemant Singh (shemant)" To: "Teemu Savolainen" , X-OriginalArrivalTime: 17 Feb 2012 12:23:22.0125 (UTC) FILETIME=[F055EBD0:01CCED6E] Subject: Re: [v6ops] PD-exclude was approved by the IESG -> should be includedinto 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 12:23:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCED6E.F016573B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Teemu, =20 When we update the rfc6204bis for PCP related text, we will consider this request from you as well. =20 Thanks, =20 Hemant =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Teemu Savolainen Sent: Friday, February 17, 2012 3:43 AM To: v6ops@ietf.org Subject: [v6ops] PD-exclude was approved by the IESG -> should be includedinto 6204bis =20 Hi v6ops, You may have already noticed that draft-ietf-dhc-pd-exclude-04 was yesterday approved by the IESG. I would like to add to the draft-ietf-v6ops-6204bis section 4.2 a new requirement (to W-4, or maybe to the WPD-x series) that says support for pd-exclude is a SHALL for IPv6 CE router.=20 Best regards, Teemu FYI: --- State changed to Approved-announcement to be sent from IESG Evaluation. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dhc-pd-exclude/ =20 ------_=_NextPart_001_01CCED6E.F016573B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Teemu,

 

When we update the rfc6204bis for PCP related text, we will consider = this request from you as well.

 

Thanks,

 

Hemant

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Teemu Savolainen
Sent: Friday, February 17, 2012 3:43 = AM
To: v6ops@ietf.org
Subject: [v6ops] PD-exclude = was approved by the IESG -> should be includedinto = 6204bis

 

Hi = v6ops,

You may have already noticed that = draft-ietf-dhc-pd-exclude-04 was yesterday approved by the = IESG.

I would like to add to the draft-ietf-v6ops-6204bis section = 4.2 a new requirement (to W-4, or maybe to the WPD-x series) that says = support for pd-exclude is a SHALL for IPv6 CE router.

Best = regards,

Teemu


FYI: ---

State changed to Approved-announcement to be sent = from IESG Evaluation.

ID Tracker = URL: http:= //datatracker.ietf.org/doc/draft-ietf-dhc-pd-exclude/

<= p class=3DMsoNormal> 

------_=_NextPart_001_01CCED6E.F016573B-- From despres.remi@laposte.net Sun Feb 19 06:29:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B9721F8473 for ; Sun, 19 Feb 2012 06:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olFQjqOk0xLE for ; Sun, 19 Feb 2012 06:29:07 -0800 (PST) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB4121F846A for ; Sun, 19 Feb 2012 06:29:06 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8504-out with ME id bqV31i00737Y3f403qV33M; Sun, 19 Feb 2012 15:29:05 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Priority: 1 Date: Sun, 19 Feb 2012 15:29:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: To: Russell Housley , Jari Arkko , Ralph Droms , Fred Baker X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 14:29:08 -0000 Russ, Jari, Ralph, Fred, On February 15, tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00.html = was re-posted as a v6ops WG document = (tools.ietf.org/html/draft-ietf-v6ops-464xlat-00.html). Interpreting past v6ops discussion as a consensus for this to happen is = AFAIK quite excessive (see in particular = www.ietf.org/mail-archive/web/v6ops/current/msg11979), and besides that = is inappropriate in view of WG charters and other existing drafts.=20 Reasons AGAINST making it a v6ops document include AFAIK: (1) There is an active 464XLAT draft IN SOFTWIRE = (tools.ietf.org/html/draft-mawatari-softwire-464xlat-02.html), very = similar, and still being discussed in this WG. (2) Although the draft was presented in v6 pops as a "trial deployment = report" (www.ietf.org/mail-archive/web/v6ops/current/msg11907.html), its = only reference to a deployment is "Incidentally, Japan Internet = Exchange(JPIX) is providing 464XLAT trial service since July 2010" (it = doesn't say how IPv6 /96 prefixes were assigned to customers, whether = tested UEs included routers or not, whether they included DNS proxies or = not, etc. etc.). On the contrary, it essentially includes specification = of a NEW SOLUTION (in particular a new IPv6 address format). (3) The v6ops charter does say "Solicit input from network operators = and users to identify operational issues with the IPv4/IPv6 Internet, = and determine solutions or workarounds to those issues", BUT it also = says "This work should PRIMARILY be conducted by those areas and WGs = which are responsible and best fit to analyze these problems."=20 (4) Softwire's charter has "Developments for stateless legacy IPv4 = carried over IPv6".=20 464XLAT introduces in user devices a new stateless behavior, but one = that is based on private IPv4 addresses like DS-lite, and one that uses = IPv4 packet formats like those of MA-T or 4rd-U (three Softwire = designs). SOFTWIRE therefore continues to be the right WG to pursue this = work. To conclude, a rectification of the situation would be to: - cancel the ietf-v6ops-464xlat draft - continue to work on the Softwire 464XLAT, in relationship with other = stateless user-device solutions (hopefully with an updated draft version = reflecting recent additions made in the v6ops draft) =20 Besides, and authors are willing to, a real "trial deployment report", = with more deployment information, would be very welcome as an = individually submitted draft. Regards, RD From cb.list6@gmail.com Sun Feb 19 07:58:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070F321F857F for ; Sun, 19 Feb 2012 07:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhB2Lwef3UfO for ; Sun, 19 Feb 2012 07:58:41 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB54521F8572 for ; Sun, 19 Feb 2012 07:58:40 -0800 (PST) Received: by dakl33 with SMTP id l33so5178339dak.31 for ; Sun, 19 Feb 2012 07:58:40 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.221.137 as permitted sender) client-ip=10.68.221.137; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.221.137 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.221.137]) by 10.68.221.137 with SMTP id qe9mr52205722pbc.71.1329667120648 (num_hops = 1); Sun, 19 Feb 2012 07:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+XRKlrHldo0rfNzOA0avVje7KHlBafmy/vNnvmjLG4k=; b=WEnLmsL/dipL78HyUZWIi5g4AIJLS5/P/6+E9lIb8pa4zfBneFU5GWEHmPqATv+US6 z1mfaiWOuZJxq0DSMhJPyxLz/DYWq/pHawdmR9EDReJoHxrAYEY8488wjd8/OF6V3+ae wxc4sEnG3akfMUkeWYjvlWppMj3StLZdw1qW8= MIME-Version: 1.0 Received: by 10.68.221.137 with SMTP id qe9mr43062403pbc.71.1329667120592; Sun, 19 Feb 2012 07:58:40 -0800 (PST) Received: by 10.142.99.12 with HTTP; Sun, 19 Feb 2012 07:58:40 -0800 (PST) In-Reply-To: References: Date: Sun, 19 Feb 2012 07:58:40 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 15:58:42 -0000 Remi, I am sorry there has been confusion. Allow me to attempt to clarify On Sun, Feb 19, 2012 at 6:29 AM, R=E9mi Despr=E9s wrote: > Russ, Jari, Ralph, Fred, > > On February 15, tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00.html = was re-posted as a v6ops WG document (tools.ietf.org/html/draft-ietf-v6ops-= 464xlat-00.html). > Interpreting past v6ops discussion as a consensus for this to happen is A= FAIK quite excessive (see in particular www.ietf.org/mail-archive/web/v6ops= /current/msg11979), and besides that is inappropriate in view of WG charter= s and other existing drafts. > The 464XLAT draft was posted as WG draft on Feb 15 at the direction of the v6ops co-chairs Please note the draft was first brought to v6ops for review on Jan 16, link below http://www.ietf.org/mail-archive/web/v6ops/current/msg11830.html > > Reasons AGAINST making it a v6ops document include AFAIK: > > (1) There is an active 464XLAT draft IN SOFTWIRE (tools.ietf.org/html/dra= ft-mawatari-softwire-464xlat-02.html), very similar, and still being discus= sed in this WG. > I believe there is an active discussion in v6ops, not in Softwires. On v6ops 464XLAT appears in email titles 55 times from today back till December 1 There have been ZERO emails with 464XLAT in the title during the same period softwires In consultation with the co-chairs, we have moved the 464XLAT from softwires to v6ops. If you think the discussion is still going on in softwires despite 3 months of silence where 464XLAT was in the title, then i can send an email to softwiress making it clear that 464XLAT has moved due to lack of interest and no charter scope within Softwires to support further discussion. > (2) Although the draft was presented in v6 pops as a "trial deployment re= port" (www.ietf.org/mail-archive/web/v6ops/current/msg11907.html), its only= reference to a deployment is "Incidentally, Japan Internet Exchange(JPIX) = is providing 464XLAT trial service since July 2010" (it doesn't say how IPv= 6 /96 prefixes were assigned to customers, whether tested UEs included rout= ers or not, whether they included DNS proxies or not, etc. etc.). On the co= ntrary, it essentially includes specification of a NEW SOLUTION (in particu= lar a new IPv6 address format). > You seem to have some technical questions about address assignment that are all clear in the draft, and if not clear in the draft then clear in the code. I won't address them hear since they have already been discussed in the draft and v6ops archive. Feel free to start another thread on specific technical clarifications after reviewing the draft and discussion archive. Allow me to clarify again the evolution of some of this. I sent this email as a report on my trial of the 464XLAT draft. http://www.ietf.org/mail-archive/web/v6ops/current/msg11906.html The *draft* is not a trial report, the draft describes an architecture that has been deployed in the USA and Japan. That much is clear in the first few lines of the draft. The *email* describes a trial that i have done where 464XLAT resolves the 15% persistent brokenness for Android phones in an IPv6-only NAT64/DNS64 network due to IPv4 referrals and so on. I understand that became unclear as the v6ops discussion evolved. Specifically, Fred forwarded the trial report email and asked for WG consideration of the draft. But, you will please understand that my representation was that the *email* was a trial report of the *draft* that describes an architecture. > (3) The v6ops charter does say =A0"Solicit input from network operators a= nd users to identify operational issues with the IPv4/IPv6 Internet, and de= termine solutions or workarounds to those issues", BUT it also says "This w= ork should PRIMARILY be conducted by those areas and WGs which are responsi= ble and best fit to analyze these problems." > Agreed, that is the v6ops charter. 464XLAT does not define any new standards. It is an informational document that simply describes how to use RFC6145 and RFC6146 to achieve the desired result of making IPv6-only network acceptable for subscribers today. The email i sent regarding deployment report confirms the goals of the 464XLAT draft can and are achieved. We have running code, it is open source, and all code has been contributed upstream pending acceptance. This is all live and working today because no new technologies are used. It is simply reusing existing capabilities. > (4) Softwire's charter has "Developments for stateless legacy IPv4 carrie= d over IPv6". > 464XLAT introduces in user devices a =A0new stateless behavior, but one t= hat is based on private IPv4 addresses like DS-lite, and one that uses IPv4= packet formats like those of MA-T or 4rd-U (three Softwire designs). SOFTW= IRE therefore continues to be the right WG to pursue this work. > This is NOT a stateless solution, it uses stateful RFC6146 AND stateless RFC6145. Please read the draft. RFC6145 is not MAP or 4RD. > > To conclude, a rectification of the situation would be to: > - cancel the ietf-v6ops-464xlat draft > - continue to work on the Softwire 464XLAT, in relationship with other st= ateless user-device solutions (hopefully with an updated draft version refl= ecting recent additions made in the v6ops draft) > I hope my clarification has made it clear that nothing needs to be retracted and that Softwires is not the right place since no new technology is being created and that 464XLAT is indeed both stateless on the CPE/UE and stateful in the network, therefore Softwires is not the right place. 464XLAT is an operator focused solution created and deployed already by operators using existing IETF standards. > Besides, and authors are willing to, a real "trial deployment report", wi= th more deployment information, would be very welcome as an individually su= bmitted draft. > My hope is that the trial deployment email was clear enough and yet another ID would not be helpful. The email on the trial deployment report of 464XLAT referenced nearly 200 tested applications and all the code and functions are open source, so anyone can repeat and validate them. For folks with a T-Mobile USA SIM and a Nexus S phone, the steps are as simple as flash the provided images or compile from source yourself. Please accept that this draft is running code, open sourced, validated in deployment, and solves a VERY REAL problem for network operators that do not have IPv4 addresses and MUST continue to grow their networks. RIR exhaustion is real in Asia today and will be real in North America this year. The trial deployment has made clear, i hope, that 464XLAT enables a mobile wireless provider to deploy Android phones as IPv6-only and have service parity with existing IPv4-only phones. >From my perspective, this is a substantial achievement that the IETF should support and expedite instead of slow. I once again call on folks to read the draft and contribute to make it bett= er http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00 If you can, also please review and trial the code yourself http://dan.drown.org/android/clat/ CB > Regards, > RD > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Sun Feb 19 08:37:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1529E21F857A for ; Sun, 19 Feb 2012 08:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.275 X-Spam-Level: X-Spam-Status: No, score=-102.275 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMUErXzwYV1A for ; Sun, 19 Feb 2012 08:37:52 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6E82A21F8575 for ; Sun, 19 Feb 2012 08:37:52 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q1JGbl0W049709 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 19 Feb 2012 16:37:48 GMT (envelope-from joelja@bogus.com) Message-ID: <4F41255B.3020103@bogus.com> Date: Sun, 19 Feb 2012 08:37:47 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 19 Feb 2012 16:37:49 +0000 (UTC) Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 16:37:53 -0000 So, when I read 464xlat what I see is a stack of existing RFCs used in a specific fashion which the draft describes. I don't see any new standards work. There is comentary on the v6ops list from the map-t about deriving the prefix of the core nat-64 translator in a consistent fashion across draft, there is perhaps work to be done there though it is likely that behave is the place for that, e.g. (http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-05) On 2/19/12 06:29 , Rémi Després wrote: > (4) Softwire's charter has "Developments for stateless legacy IPv4 > carried over IPv6". 464XLAT introduces in user devices a new > stateless behavior, but one that is based on private IPv4 addresses > like DS-lite, and one that uses IPv4 packet formats like those of > MA-T or 4rd-U (three Softwire designs). SOFTWIRE therefore continues > to be the right WG to pursue this work. softwires charter also says: IPv4/IPv6 translation mechanisms, new addressing schemes, and block address assignments are out of scope which ought to rule out pretty much anything that has employs an rfc 6146 translator. > To conclude, a rectification of the situation would be to: - cancel > the ietf-v6ops-464xlat draft - continue to work on the Softwire > 464XLAT, in relationship with other stateless user-device solutions > (hopefully with an updated draft version reflecting recent additions > made in the v6ops draft) I'm not particularly wedded to the idea of it being in v6ops. I am interested in seeing it get a fair hearing, the lack of novelty has some relevance in an operational context. From brian.e.carpenter@gmail.com Sun Feb 19 11:23:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D5621F84CD for ; Sun, 19 Feb 2012 11:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwyRXUDdcjKQ for ; Sun, 19 Feb 2012 11:23:32 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE4621F84C5 for ; Sun, 19 Feb 2012 11:23:32 -0800 (PST) Received: by eaal12 with SMTP id l12so1941134eaa.31 for ; Sun, 19 Feb 2012 11:23:31 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.99.195 as permitted sender) client-ip=10.14.99.195; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.99.195 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.14.99.195]) by 10.14.99.195 with SMTP id x43mr9141719eef.46.1329679411742 (num_hops = 1); Sun, 19 Feb 2012 11:23:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nbnDAiwrcxS40yw4zumpRGS4ULJ26Hq/pSvb3FXiNz4=; b=Ysv2SJjP0EYOaCx0RpFpNxp6hf9uHbQFR7wFLpZ3RaeNAwvwx7TWSxL1Gn0NmqMiBv S2PLuS3X9tchP0SFw2iOAxQoXIrhv43DTCMW05dKgNjBPc0rNmvYqdgbD6yHW1AzCV6d Zg7p6r2Vt5lT5kxDInCAKWrsut6dzd/44Lpds= Received: by 10.14.99.195 with SMTP id x43mr7302503eef.46.1329679411644; Sun, 19 Feb 2012 11:23:31 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id w60sm68321540eeb.4.2012.02.19.11.23.27 (version=SSLv3 cipher=OTHER); Sun, 19 Feb 2012 11:23:30 -0800 (PST) Message-ID: <4F414C28.8040606@gmail.com> Date: Mon, 20 Feb 2012 08:23:20 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel jaeggli References: <4F41255B.3020103@bogus.com> In-Reply-To: <4F41255B.3020103@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Russell Housley , v6ops WG Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 19:23:33 -0000 On 2012-02-20 05:37, Joel jaeggli wrote: > So, when I read 464xlat what I see is a stack of existing RFCs used in > a specific fashion which the draft describes. I don't see any new > standards work. fwiw I agree with that. I think v6ops is the appropriate venue for descriptions of how to knit existing protocol specs together in operational scenarios. I do object slightly to the way draft-ietf-v6ops-464xlat uses the word "architecture". It's an operational scenario, not an architecture, IMHO. Brian From victor.kuarsingh@gmail.com Sun Feb 19 13:45:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335E221F8504 for ; Sun, 19 Feb 2012 13:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj04rfFaytX3 for ; Sun, 19 Feb 2012 13:45:09 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8AEC21F84D9 for ; Sun, 19 Feb 2012 13:45:08 -0800 (PST) Received: by iagf6 with SMTP id f6so8257143iag.31 for ; Sun, 19 Feb 2012 13:45:08 -0800 (PST) Received-SPF: pass (google.com: domain of victor.kuarsingh@gmail.com designates 10.50.15.234 as permitted sender) client-ip=10.50.15.234; Authentication-Results: mr.google.com; spf=pass (google.com: domain of victor.kuarsingh@gmail.com designates 10.50.15.234 as permitted sender) smtp.mail=victor.kuarsingh@gmail.com; dkim=pass header.i=victor.kuarsingh@gmail.com Received: from mr.google.com ([10.50.15.234]) by 10.50.15.234 with SMTP id a10mr8944567igd.29.1329687908477 (num_hops = 1); Sun, 19 Feb 2012 13:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=tFS8q3abP/GTRSubsY32HwDtdm2uLPC4BVPSTdszJso=; b=O8fcY6Rb2NOqoMfdB0EMlpRQ7t6v4h3v/S5Y7u6fff5b4urTtiKhDdqo0GY34V+YMp x7wARhIiW+iZNBvefPnZhnZ/XrQ6J2fF9Bg+J1rUVgcf8/dGcCDCY8ikuX4sf79C32Rn KAcUNme9jgtx+vRyAwCFiCWG1Z0schsLT1VPg= Received: by 10.50.15.234 with SMTP id a10mr7268759igd.29.1329687908408; Sun, 19 Feb 2012 13:45:08 -0800 (PST) Received: from [192.168.1.2] ([74.198.164.28]) by mx.google.com with ESMTPS id em2sm5199855igc.0.2012.02.19.13.45.01 (version=SSLv3 cipher=OTHER); Sun, 19 Feb 2012 13:45:07 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 19 Feb 2012 16:44:55 -0500 From: Victor Kuarsingh To: Brian E Carpenter , Joel jaeggli Message-ID: Thread-Topic: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. In-Reply-To: <4F414C28.8040606@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 21:45:10 -0000 On 12-02-19 2:23 PM, "Brian E Carpenter" wrote: >On 2012-02-20 05:37, Joel jaeggli wrote: >> So, when I read 464xlat what I see is a stack of existing RFCs used in >> a specific fashion which the draft describes. I don't see any new >> standards work. > >fwiw I agree with that. I think v6ops is the appropriate venue >for descriptions of how to knit existing protocol specs together >in operational scenarios. I would agree as well. No new protocols. We are using what's in the tool kit to make things work. Ops seems to be the right area for this type of work > >I do object slightly to the way draft-ietf-v6ops-464xlat uses >the word "architecture". It's an operational scenario, not an >architecture, IMHO. Are you concerned that the use of "architecture" may be interpreted as protocol architecture vs. network architecture? IMHO, I would suggest what's in the document reflects a network/deployment architecture (my opinion). Perhaps authors can clarify what they meant. Regards, Victor K > > Brian >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Sun Feb 19 17:35:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848B921F8467 for ; Sun, 19 Feb 2012 17:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RpL7cbIUr2H for ; Sun, 19 Feb 2012 17:35:09 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A26921F8453 for ; Sun, 19 Feb 2012 17:35:09 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so5971944pbc.31 for ; Sun, 19 Feb 2012 17:35:09 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.237.232 as permitted sender) client-ip=10.68.237.232; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.237.232 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.237.232]) by 10.68.237.232 with SMTP id vf8mr38154035pbc.50.1329701709448 (num_hops = 1); Sun, 19 Feb 2012 17:35:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=y1T05gpbDbj6GnomnV1Dz6fnTM1cvGcUh9Fjo20inzA=; b=M9ngbS1vjfPF9VSuaAEpLC8qikPh5hFcEElKJNmyy0oQDxuYOvVBzKYupcdFpEcWny dNftU4avk4JFE4SjWtY4G5hfCdQFGmTJ8LlvagDnfQMRqIOXizpeyVG/uaUMENM4pQmU XFJxH/bD6lNIQw8MLPxcfLfsB+oFPU0FM4zSA= MIME-Version: 1.0 Received: by 10.68.237.232 with SMTP id vf8mr31738959pbc.50.1329701709410; Sun, 19 Feb 2012 17:35:09 -0800 (PST) Received: by 10.142.99.12 with HTTP; Sun, 19 Feb 2012 17:35:09 -0800 (PST) Date: Sun, 19 Feb 2012 17:35:09 -0800 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] 464XLAT and the term "architecture" -- WAS draft-464XLAT not a "trial deployment report" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 01:35:10 -0000 New title to focus on the taxonomy and term "architecture" On Sun, Feb 19, 2012 at 1:44 PM, Victor Kuarsingh wrote: > > > On 12-02-19 2:23 PM, "Brian E Carpenter" > wrote: > >>I do object slightly to the way draft-ietf-v6ops-464xlat uses >>the word "architecture". It's an operational scenario, not an >>architecture, IMHO. > > Are you concerned that the use of "architecture" may be interpreted as > protocol architecture vs. network architecture? =A0IMHO, I would suggest > what's in the document reflects a network/deployment architecture (my > opinion). > > Perhaps authors can clarify what they meant. > Gladly. I will call on the TOGAF definitions: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_0= 8 Architecture: 1) A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (source: ISO/IEC 42010:2007). 2) The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. I believe the 464XLAT draft fits pretty well in this definition. We look to describe the system, guide implementation, and show how the pieces fit together. I believe the term framework is too broad (but close) and solution and scenario are too specific for the context of this draft to cover both wireline and wireless. In a few cases, for example address assignment to the CPE / UE and Pref64/n discovery, we supply multiple methods that the desired outcome can be achieved to accommodate and not limit how 464XLAT can be applied now and in the future. We took care to not be overly prescriptive in defining how a network operator shall design their network. One of the key values we believe publishing the draft will bring is the ability to describe succinctly yet generically how traffic is treated in a 464XLAT network so that all parties (software, hardware, application, peers...) can have a common understanding of the network capabilities and the way in which traffic will be treated. CB From satoru.matsushima@gmail.com Sun Feb 19 23:11:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB4521F8698 for ; Sun, 19 Feb 2012 23:11:27 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4DmpL5HVsvn for ; Sun, 19 Feb 2012 23:11:23 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 420A521F84B2 for ; Sun, 19 Feb 2012 23:11:23 -0800 (PST) Received: by dakl33 with SMTP id l33so5721407dak.31 for ; Sun, 19 Feb 2012 23:11:23 -0800 (PST) Received-SPF: pass (google.com: domain of satoru.matsushima@gmail.com designates 10.68.189.162 as permitted sender) client-ip=10.68.189.162; Authentication-Results: mr.google.com; spf=pass (google.com: domain of satoru.matsushima@gmail.com designates 10.68.189.162 as permitted sender) smtp.mail=satoru.matsushima@gmail.com; dkim=pass header.i=satoru.matsushima@gmail.com Received: from mr.google.com ([10.68.189.162]) by 10.68.189.162 with SMTP id gj2mr47886262pbc.145.1329721883106 (num_hops = 1); Sun, 19 Feb 2012 23:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=sjuGsbda5KPHJXYnOsssCmh/I2PflmY1a6XKKsZ9Cus=; b=gH620kaTDYag+RbQV+4qZEWVfHwZqRlJxfvEyq6qr3Aj/BWgna71CtFy5Pe+6bJKF+ bzqmQT7e1ITWfTFtflBaUabRP/Uap+1PACeAjcXaSt73uqKCgPKQMYr+zLshBD6RZKOg c2VXt8/SK6qifLm/ZsLDU0nXj1BmylWtSyFDk= Received: by 10.68.189.162 with SMTP id gj2mr40171635pbc.145.1329721883072; Sun, 19 Feb 2012 23:11:23 -0800 (PST) Received: from [10.201.80.50] ([202.45.12.141]) by mx.google.com with ESMTPS id d7sm12482902pbh.59.2012.02.19.23.11.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Feb 2012 23:11:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <4F414C28.8040606@gmail.com> Date: Mon, 20 Feb 2012 16:11:17 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F41255B.3020103@bogus.com> <4F414C28.8040606@gmail.com> To: v6ops WG X-Mailer: Apple Mail (2.1257) Cc: Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 07:11:27 -0000 On 2012/02/20, at 4:23, Brian E Carpenter wrote: > On 2012-02-20 05:37, Joel jaeggli wrote: >> So, when I read 464xlat what I see is a stack of existing RFCs used = in >> a specific fashion which the draft describes. I don't see any new >> standards work. >=20 > fwiw I agree with that. I think v6ops is the appropriate venue > for descriptions of how to knit existing protocol specs together > in operational scenarios. >=20 > I do object slightly to the way draft-ietf-v6ops-464xlat uses > the word "architecture". It's an operational scenario, not an > architecture, IMHO. >=20 I can see a strong statement that double protocol translation is an = architecture which is not recommended by the IETF. (http://tools.ietf.org/html/draft-ietf-behave-v4v6-bih-09) I'd like to hear from chairs that does v6ops consent to be opposed to = that statement. cheers, --satoru= From despres.remi@laposte.net Mon Feb 20 01:52:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B4921F8598 for ; Mon, 20 Feb 2012 01:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jZs1merQNwo for ; Mon, 20 Feb 2012 01:52:45 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id BD8B921F86F1 for ; Mon, 20 Feb 2012 01:52:42 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 95D7794007A; Mon, 20 Feb 2012 10:52:29 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 20 Feb 2012 10:52:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 09:52:50 -0000 cameron, Le 2012-02-19 =E0 16:58, Cameron Byrne a =E9crit : > Remi, >=20 > I am sorry there has been confusion. Allow me to attempt to clarify >=20 > On Sun, Feb 19, 2012 at 6:29 AM, R=E9mi Despr=E9s = wrote: >> Russ, Jari, Ralph, Fred, >>=20 >> On February 15, = tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00.html was re-posted = as a v6ops WG document = (tools.ietf.org/html/draft-ietf-v6ops-464xlat-00.html). >> Interpreting past v6ops discussion as a consensus for this to happen = is AFAIK quite excessive (see in particular = www.ietf.org/mail-archive/web/v6ops/current/msg11979), and besides that = is inappropriate in view of WG charters and other existing drafts. >>=20 >=20 > The 464XLAT draft was posted as WG draft on Feb 15 at the direction of > the v6ops co-chairs That's why a lack of consensus is relevant. > Please note the draft was first brought to v6ops for review on Jan 16, > link below Well known, but since then a number of comments suggested to send the = document to some other WG. > http://www.ietf.org/mail-archive/web/v6ops/current/msg11830.html >> Reasons AGAINST making it a v6ops document include AFAIK: >>=20 >> (1) There is an active 464XLAT draft IN SOFTWIRE = (tools.ietf.org/html/draft-mawatari-softwire-464xlat-02.html), very = similar, and still being discussed in this WG. >>=20 >=20 > I believe there is an active discussion in v6ops, not in Softwires. >=20 > On v6ops 464XLAT appears in email titles 55 times from today back till > December 1 >=20 > There have been ZERO emails with 464XLAT in the title during the same > period softwires Fair enough, but it was never closed, and I do believe it is useful to = pursue it ("resume it" if you prefer). There is room I think to include the concept (which BTW I find quite = interesting) in the unified stateless solution under study in Softwire. It seems to find a natural place there.=20 > In consultation with the co-chairs, we have moved the 464XLAT from > softwires to v6ops. If you think the discussion is still going on in > softwires despite 3 months of silence where 464XLAT was in the title, > then i can send an email to softwiress making it clear that 464XLAT > has moved due to lack of interest True, little interest was expressed then, but this was when the work on = MAP and 4rd-U was really beginning. The work on these two has now progressed in Softwire, and considering = functional requirements of 464XLAT in this context makes in my = undesrtsnding a lot of sense. =20 > and no charter scope within > Softwires to support further discussion. Debatable I suppose since 464XLAT was first submitted there. >> (2) Although the draft was presented in v6 pops as a "trial = deployment report" = (www.ietf.org/mail-archive/web/v6ops/current/msg11907.html), its only = reference to a deployment is "Incidentally, Japan Internet = Exchange(JPIX) is providing 464XLAT trial service since July 2010" (it = doesn't say how IPv6 /96 prefixes were assigned to customers, whether = tested UEs included routers or not, whether they included DNS proxies or = not, etc. etc.). On the contrary, it essentially includes specification = of a NEW SOLUTION (in particular a new IPv6 address format). >>=20 >=20 > You seem to have some technical questions about address assignment > that are all clear in the draft, and if not clear in the draft then > clear in the code. Well, reading code is AFAIK a way to check that it complies to a spec, = but not the right way to understand what a specification means.=20 Specifications must be clear by themselves. In any case, my question isn't about understanding the specification = (clear enough IMHO for this level of discussion). It reflects interest = for a more complete draft describing the trial configuration, with its = configuration parameters. (The specification describes a number of = options: with or without DNS64; possibility that an "access networks = that does not allow for a dedicated translation prefix"; CLATs that may = get /64s via DHCPv6 or by other means; inclusion fragment headers = possibly systematic but optional; possibility for some CLATs to get = longer than /64 IPv6 prefixes). I just say that a real "trial deployment report" would be nice to have, = but of course no obligation. > I won't address them hear since they have already > been discussed in the draft and v6ops archive. Feel free to start > another thread on specific technical clarifications after reviewing > the draft and discussion archive. >=20 > Allow me to clarify again the evolution of some of this. >=20 > I sent this email as a report on my trial of the 464XLAT draft. >=20 > http://www.ietf.org/mail-archive/web/v6ops/current/msg11906.html >=20 > The *draft* is not a trial report, the draft describes an architecture > that has been deployed in the USA and Japan. That much is clear in > the first few lines of the draft. >=20 > The *email* describes a trial that i have done where 464XLAT resolves > the 15% persistent brokenness for Android phones in an IPv6-only > NAT64/DNS64 network due to IPv4 referrals and so on. >=20 > I understand that became unclear as the v6ops discussion evolved. > Specifically, Fred forwarded the trial report email and asked for WG > consideration of the draft. I agree that it is how confusion started.=20 > But, you will please understand that my > representation was that the *email* was a trial report of the *draft* > that describes an architecture. I do understand this, yes. >> (3) The v6ops charter does say "Solicit input from network operators = and users to identify operational issues with the IPv4/IPv6 Internet, = and determine solutions or workarounds to those issues", BUT it also = says "This work should PRIMARILY be conducted by those areas and WGs = which are responsible and best fit to analyze these problems." >>=20 >=20 > Agreed, that is the v6ops charter. 464XLAT does not define any new > standards. It is an informational document that simply describes how > to use RFC6145 and RFC6146 to achieve the desired result of making > IPv6-only network acceptable for subscribers today. =20 The draft does include SHOULDs and MAYs that belong to standardization = vocabulary, e.g.: "In cases where the access network does not allow for a dedicated = translation prefix, the CLAT SHOULD take ownership of the lowest /96 = from an attached interface's /64 to source and receive translation = traffic. Establishing ownership of the /96 requires that the CLAT SHOULD = perform NDP so that no other nodes on the /64 may use the lowest /96."=20= > The email i sent > regarding deployment report confirms the goals of the 464XLAT draft > can and are achieved. =20 "IPv4 access service to mobile AND WIRELINE IPv6-only edge networks"?=20 (=46rom the abstract, upper cases added.) > We have running code, it is open source, and > all code has been contributed upstream pending acceptance. This is > all live and working today because no new technologies are used. It > is simply reusing existing capabilities. Close to that, but not "simply" (see above). >> (4) Softwire's charter has "Developments for stateless legacy IPv4 = carried over IPv6". >> 464XLAT introduces in user devices a new stateless behavior, but one = that is based on private IPv4 addresses like DS-lite, and one that uses = IPv4 packet formats like those of MA-T or 4rd-U (three Softwire = designs). SOFTWIRE therefore continues to be the right WG to pursue this = work. >>=20 >=20 > This is NOT a stateless solution, it uses stateful RFC6146 AND > stateless RFC6145. =20 AFAIK, it adds rigorously nothing to NAT64 (RFC6146). OTOH, it introduces a new CPE behavior that uses RFC6145, but adds few = design choices to it, like MAP-T. > Please read the draft. Your suggesting that I didn't read the draft could advantageously have = been avoided (IMHO). =20 > RFC6145 is not MAP or > 4RD. Why you say this is unclear. AFAIK nobody ever suggested that. =20 >> To conclude, a rectification of the situation would be to: >> - cancel the ietf-v6ops-464xlat draft >> - continue to work on the Softwire 464XLAT, in relationship with = other stateless user-device solutions (hopefully with an updated draft = version reflecting recent additions made in the v6ops draft) >>=20 >=20 > I hope my clarification has made it clear that nothing needs to be > retracted and that Softwires is not the right place since no new > technology is being created and that 464XLAT is indeed both stateless > on the CPE/UE and stateful in the network, therefore Softwires is not > the right place. 464XLAT is an operator focused solution created and > deployed already by operators using existing IETF standards. The claim that nothing new is specified is the main point that is = challenged (see above) >=20 >> Besides, and authors are willing to, a real "trial deployment = report", with more deployment information, would be very welcome as an = individually submitted draft. >>=20 >=20 > My hope is that the trial deployment email was clear enough and yet > another ID would not be helpful. The email on the trial deployment > report of 464XLAT referenced nearly 200 tested applications and all > the code and functions are open source, so anyone can repeat and > validate them. For folks with a T-Mobile USA SIM and a Nexus S phone, > the steps are as simple as flash the provided images or compile from > source yourself. The draft is about mobile AND "wireline" (understood to include DSL). > Please accept that this draft is running code, open sourced, > validated in deployment, and solves a VERY REAL problem for network > operators that do not have IPv4 addresses and MUST continue to grow > their networks. RIR exhaustion is real in Asia today and will be real > in North America this year. The trial deployment has made clear, i > hope, that 464XLAT enables a mobile wireless provider to deploy > Android phones as IPv6-only and have service parity with existing > IPv4-only phones. This isn't sufficient to say that the specification is complete for all = its use cases. Besides, I would say that these phones are in some sense dual-stack: - they are in all cases IPv4 aware, at least for IPv4-only applications - if acting as routers, they "SHOULD" include IPv4-aware DNS proxies. > =46rom my perspective, this is a substantial achievement that the IETF > should support and expedite instead of slow. The idea is quite interesting, and quickly dealing with it in = relationship with current work on MAP-T and 4rd-U makes a lot of sense = (IMHO). Regards, RD =20 >=20 > I once again call on folks to read the draft and contribute to make it = better >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00 >=20 > If you can, also please review and trial the code yourself >=20 > http://dan.drown.org/android/clat/ >=20 > CB >=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From tsavo.stds@gmail.com Mon Feb 20 01:59:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B0B21F86E2 for ; Mon, 20 Feb 2012 01:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XbyFxC6DfHo for ; Mon, 20 Feb 2012 01:59:18 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 359E721F8688 for ; Mon, 20 Feb 2012 01:59:18 -0800 (PST) Received: by qan41 with SMTP id 41so5709459qan.10 for ; Mon, 20 Feb 2012 01:59:17 -0800 (PST) Received-SPF: pass (google.com: domain of tsavo.stds@gmail.com designates 10.229.137.18 as permitted sender) client-ip=10.229.137.18; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tsavo.stds@gmail.com designates 10.229.137.18 as permitted sender) smtp.mail=tsavo.stds@gmail.com; dkim=pass header.i=tsavo.stds@gmail.com Received: from mr.google.com ([10.229.137.18]) by 10.229.137.18 with SMTP id u18mr15378326qct.153.1329731957769 (num_hops = 1); Mon, 20 Feb 2012 01:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:mime-version:date:subject:from:reply-to:to:cc :content-type:content-transfer-encoding; bh=YqRccuD9WABqk3mt0CbJXMGfHmZcBrVIkXiaP4e34kw=; b=SQVnbVQzmNClIe233Ol2YUa7PZgGjGsTKc7+9DsmN8eC1z3zAW4OF/2jmEg9A6XD6H U/2cJEKjAbCXYZmERpe4Bd0nH11ay5gRQw4vK0MgHBrB+xosr54Gbu3jkhjLriOYhaPB XwPKy4PMDzwZSReOBh3WkvuPTBPiMQfnBDrSs= Received: by 10.229.137.18 with SMTP id u18mr13067972qct.153.1329731957438; Mon, 20 Feb 2012 01:59:17 -0800 (PST) Received: from nokia.com ([66.54.67.184]) by mx.google.com with ESMTPS id dm8sm48661239qab.18.2012.02.20.01.59.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Feb 2012 01:59:16 -0800 (PST) Message-ID: <4f421974.88bfe00a.48cf.367f@mx.google.com> MIME-Version: 1.0 Date: Mon, 20 Feb 2012 09:59:15 +0000 From: "tsavo.stds@gmail.com" To: "v6ops@ietf.org" , "satoru.matsushima@gmail.com" Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "housley@vigilsec.com" Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "tsavo.stds@gmail.com" List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 09:59:22 -0000 I have to say I am really interested on this as well, as during BIH-work we= were explicitly forbidden to define how BIH would work if destination has = an A record (instead of only AAAA). E.g. we could not write that if there is A record, it is passed as is to ap= plication and following IPv4 packet then translated to Ipv6.... I understand that times change, but this change is quite fast (document say= ing not allowed in RFC editor queue while new document saying allowed adopt= ed as wg document..). Maybe this document should state that described approach still is not recom= mended. Or IETF(IESG) should make their mind:) Teemu L=C3=A4hetetty Nokia-puhelimestani ---- alkuper=C3=A4inen viesti ---- L=C3=A4hett.: Satoru Matsushima L=C3=A4het.: 20.02.2012, 09:11=20 V.ottaja: v6ops WG Kopio: Russell Housley Aihe: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be= an ietf-v6ops I.D. On 2012/02/20, at 4:23, Brian E Carpenter wrote: > On 2012-02-20 05:37, Joel jaeggli wrote: >> So, when I read 464xlat what I see is a stack of existing RFCs used in >> a specific fashion which the draft describes. I don't see any new >> standards work. >=20 > fwiw I agree with that. I think v6ops is the appropriate venue > for descriptions of how to knit existing protocol specs together > in operational scenarios. >=20 > I do object slightly to the way draft-ietf-v6ops-464xlat uses > the word "architecture". It's an operational scenario, not an > architecture, IMHO. >=20 I can see a strong statement that double protocol translation is an archite= cture which is not recommended by the IETF. (http://tools.ietf.org/html/draft-ietf-behave-v4v6-bih-09) I'd like to hear from chairs that does v6ops consent to be opposed to that = statement. cheers, --satoru _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Mon Feb 20 02:27:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5ED821F8720 for ; Mon, 20 Feb 2012 02:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2C4ljUXF4pr for ; Mon, 20 Feb 2012 02:27:16 -0800 (PST) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB5121F8731 for ; Mon, 20 Feb 2012 02:27:15 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id cATB1i00E37Y3f403ATCYF; Mon, 20 Feb 2012 11:27:14 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F41255B.3020103@bogus.com> Date: Mon, 20 Feb 2012 11:27:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6021B525-A576-45A7-936C-E32F51D0169C@laposte.net> References: <4F41255B.3020103@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 10:27:20 -0000 Hi Joel, Thanks for your comments. More below. Le 2012-02-19 =E0 17:37, Joel jaeggli a =E9crit : > So, when I read 464xlat what I see is a stack of existing RFCs used = in > a specific fashion which the draft describes. I don't see any new > standards work. As answered to Cameron, the fact is that there are some new = specification pieces, with SHOULDs and MAYs, e.g.: "In cases where the access network does not allow for a dedicated = translation prefix, the CLAT SHOULD take ownership of the lowest /96 = from an attached interface's /64 to source and receive translation = traffic. Establishing ownership of the /96 requires that the CLAT SHOULD = perform NDP so that no other nodes on the /64 may use the lowest /96."=20= > There is comentary on the v6ops list from the map-t about deriving the > prefix of the core nat-64 translator in a consistent fashion across > draft, there is perhaps work to be done there though it is likely that > behave is the place for that, e.g. > = (http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-05= ) >=20 > On 2/19/12 06:29 , R=E9mi Despr=E9s wrote: >=20 > >=20 >> (4) Softwire's charter has "Developments for stateless legacy IPv4 >> carried over IPv6". 464XLAT introduces in user devices a new >> stateless behavior, but one that is based on private IPv4 addresses >> like DS-lite, and one that uses IPv4 packet formats like those of >> MA-T or 4rd-U (three Softwire designs). SOFTWIRE therefore continues >> to be the right WG to pursue this work. >=20 > softwires charter also says: >=20 > IPv4/IPv6 translation mechanisms, new addressing schemes, and block > address assignments are out of scope >=20 > which ought to rule out pretty much anything that has employs an rfc > 6146 translator. Well, there is indeed ambiguity here because it also says: "- develop a solution motivation document to be published as an RFC=20 - develop a protocol specification response to the solution motivation = document". The MAP-T proposed solution is based on double RFC6145 translation, and = 4rd-U uses some pieces that are specified only in RFC6145.=20 >> To conclude, a rectification of the situation would be to: - cancel >> the ietf-v6ops-464xlat draft - continue to work on the Softwire >> 464XLAT, in relationship with other stateless user-device solutions >> (hopefully with an updated draft version reflecting recent additions >> made in the v6ops draft) >=20 > I'm not particularly wedded to the idea of it being in v6ops. I am > interested in seeing it get a fair hearing, I share this interest in fair hearing. Actually, that's why what it specifies should better be discussed where = there is current work on stateless CPEs (hosts and/or routers) that do = IPv4 via IPv6, i.e. in Softwire. =20 > the lack of novelty has some > relevance in an operational context. I do share the view that using existing specifications to avoid = reinventing the wheel is always good, but the fact is that there is some = novelty in the 464XLAT specification. Regards, RD= From wdec.ietf@gmail.com Mon Feb 20 02:36:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F49421F872F for ; Mon, 20 Feb 2012 02:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.832 X-Spam-Level: X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQupVJVJgJoV for ; Mon, 20 Feb 2012 02:36:17 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFEB121F872D for ; Mon, 20 Feb 2012 02:36:16 -0800 (PST) Received: by qafi29 with SMTP id i29so2958100qaf.10 for ; Mon, 20 Feb 2012 02:36:16 -0800 (PST) Received-SPF: pass (google.com: domain of wdec.ietf@gmail.com designates 10.229.77.79 as permitted sender) client-ip=10.229.77.79; Authentication-Results: mr.google.com; spf=pass (google.com: domain of wdec.ietf@gmail.com designates 10.229.77.79 as permitted sender) smtp.mail=wdec.ietf@gmail.com; dkim=pass header.i=wdec.ietf@gmail.com Received: from mr.google.com ([10.229.77.79]) by 10.229.77.79 with SMTP id f15mr15677521qck.121.1329734176501 (num_hops = 1); Mon, 20 Feb 2012 02:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ilpMABhbMLNGEsgIei+BOMeF4HLxByIDTt6r58RRm70=; b=hNhjs1GJ5hNjnPwFt9ZUTKIEdQLs1sZRQkqk4AeCemRn1LZGDP/uLTWaBWKXqx06bo NQF7O6e2ue/5h0iUCXHuBWiyh9OOjF7oyTK3sjY7atlYpwCzR1Q5LRJaAxcv1sKHhhZm dDyLGI/PNSCsIEm4+y4hiVn504WQ3epJbLsNU= MIME-Version: 1.0 Received: by 10.229.77.79 with SMTP id f15mr13305053qck.121.1329734175368; Mon, 20 Feb 2012 02:36:15 -0800 (PST) Received: by 10.229.82.201 with HTTP; Mon, 20 Feb 2012 02:36:15 -0800 (PST) In-Reply-To: <4F414C28.8040606@gmail.com> References: <4F41255B.3020103@bogus.com> <4F414C28.8040606@gmail.com> Date: Mon, 20 Feb 2012 11:36:15 +0100 Message-ID: From: Wojciech Dec To: Brian E Carpenter Content-Type: multipart/alternative; boundary=002354470fc42b28db04b962dd8d Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 10:36:21 -0000 --002354470fc42b28db04b962dd8d Content-Type: text/plain; charset=ISO-8859-1 On 19 February 2012 20:23, Brian E Carpenter wrote: > On 2012-02-20 05:37, Joel jaeggli wrote: > > So, when I read 464xlat what I see is a stack of existing RFCs used in > > a specific fashion which the draft describes. I don't see any new > > standards work. > > fwiw I agree with that. I think v6ops is the appropriate venue > for descriptions of how to knit existing protocol specs together > in operational scenarios. > > I do object slightly to the way draft-ietf-v6ops-464xlat uses > the word "architecture". It's an operational scenario, not an > architecture, IMHO. > The operational experiment is something that deserves to be documented, however it's as per my reading current quite a bit more given: a) the presence of normative terms in the document b) the emphasis on effectively specifying/casting the use of a very specific subset of the stateless NAT64 spec eg just allowing the /96 address format to be used c) the assumption that a stateless NAT64 client will always be used with a stateful NAT64 core element Based on my reading (and as exemplified in earlier email), should an implementation follow this spec "as is", it would result in impaired communication should a device supporting this spec "move" to a network where b) and c) are different. Cheers, Wojciech. > > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --002354470fc42b28db04b962dd8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 19 February 2012 20:23, Brian E Carpe= nter <b= rian.e.carpenter@gmail.com> wrote:
On 2012-02-20 05:37, Joel jaeggli wrote:
> So, when I read =A0464xlat what I see is a stack of existing RFCs used= in
> a specific fashion which the draft describes. I don't see any new<= br> > standards work.

fwiw I agree with that. I think v6ops is the appropriate venue
for descriptions of how to knit existing protocol specs together
in operational scenarios.

I do object slightly to the way draft-ietf-v6ops-464xlat uses
the word "architecture". It's an operational scenario, not an=
architecture, IMHO.

The operational experiment is = something that deserves to be documented, however it's as per my readin= g current quite a bit more given:
a) the presence of normative terms in = the document
b) the emphasis on effectively specifying/casting the use of a very specifi= c subset of the stateless NAT64 spec eg just allowing the /96 address forma= t to be used
c) the assumption that a stateless NAT64 client will always= be used with a stateful NAT64 core element

Based on my reading (and as exemplified in earlier email), should an im= plementation follow this spec "as is", it would result in impaire= d communication should a device supporting this spec "move" to a = network where b) and c) are different.

Cheers,
Wojciech.
=A0

=A0 Brian
_____________________= __________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--002354470fc42b28db04b962dd8d-- From despres.remi@laposte.net Mon Feb 20 03:05:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673F521F867D for ; Mon, 20 Feb 2012 03:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsWgZkkA0O+j for ; Mon, 20 Feb 2012 03:05:35 -0800 (PST) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24C21F8610 for ; Mon, 20 Feb 2012 03:05:34 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id cB5W1i00437Y3f403B5W2d; Mon, 20 Feb 2012 12:05:33 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F414C28.8040606@gmail.com> Date: Mon, 20 Feb 2012 12:05:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82A0D21F-4038-4EAA-8490-A68D30C92D0A@laposte.net> References: <4F41255B.3020103@bogus.com> <4F414C28.8040606@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 11:05:36 -0000 Hi Brian, Le 2012-02-19 =E0 20:23, Brian E Carpenter a =E9crit : > On 2012-02-20 05:37, Joel jaeggli wrote: >> So, when I read 464xlat what I see is a stack of existing RFCs used = in >> a specific fashion which the draft describes. I don't see any new >> standards work. >=20 > fwiw I agree with that. I think v6ops is the appropriate venue > for descriptions of how to knit existing protocol specs together > in operational scenarios. >=20 > I do object slightly to the way draft-ietf-v6ops-464xlat uses > the word "architecture". It's an operational scenario, not an > architecture, IMHO. The draft says "No new protocol required", but: 1.=20 Section 7.5 says: "In the best case, the CLAT will have a dedicated /64 via DHCPv6 or = other means to source and receive IPv6 packets associated with the = [RFC6145] stateless translation of IPv4 packets to the local clients." How this is provided via DHCPv6 has AFAIK to be specified.=20 Note that RFC5969 says "6rd specifies a protocol mechanism" although it = is also using just a stack of previously available protocols, with new = parameters obtained in DHCP. 2. The same section says: "In cases where the access network does not allow for a dedicated = translation prefix, the CLAT SHOULD take ownership of the lowest /96 = from an attached interface's /64 to source and receive translation = traffic. Establishing ownership of the /96 requires that the CLAT SHOULD = perform NDP so that no other nodes on the /64 may use the lowest /96."=20= This is AFAIK a new specification, which requires specific code. If not, I am interested in learning why. 3. Section 7.6 says: "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 = Fragment Header, since IPv4 host does not set the DF bit." AFAIK, this isn't in existing RFCs. 4. Section 7.7 says: "The CLAT SHOULD set itself as the DNS server via DHCP or other means = and proxy DNS queries for IPv4 and IPv6 clients" I find the "other means" confusing here (a new protocol?).=20 "The CLAT SHOULD allow for a client to query any DNS server of its = choice and bypass the proxy." What the CLAT has to do for this isn't specified. (Also whether this = DNS has to synthesize A records or not isn't specified.) =20 To me this shows that, Devil being in details, this draft isn't just an = operational scenario with existing RFC specifications. Yet, as I said, there is in this draft a very valuable idea, worth = treating rigorously. Kind regards, RD =20 >=20 > Brian From ales.vizdal@t-mobile.cz Mon Feb 20 04:11:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0AF21F8630 for ; Mon, 20 Feb 2012 04:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.55 X-Spam-Level: X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPS7v2kGxt3P for ; Mon, 20 Feb 2012 04:11:21 -0800 (PST) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 9A26221F8646 for ; Mon, 20 Feb 2012 04:11:20 -0800 (PST) Received: from srvhk503.rdm.cz (unknown [10.246.143.95]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id A5450285802; Mon, 20 Feb 2012 13:11:17 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::2cec:9ace:94f2:601a]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Mon, 20 Feb 2012 13:11:17 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: Victor Kuarsingh , "fred@cisco.com" , "v6ops@ietf.org" Date: Mon, 20 Feb 2012 13:07:20 +0100 Thread-Topic: [v6ops] new draft: draft-ietf-v6ops-464xlat Thread-Index: AcztC49Shzcn3KjrTTiJT9GF4H89rgCu3dRw Message-ID: <1808340F7EC362469DDFFB112B37E2FCC67E419632@SRVHKE02.rdm.cz> References: <201202151455.q1FEt0K02883@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-v6ops-464xlat@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 12:11:25 -0000 +1 I fully agree with Victor's words as this draft is providing a real solutio= n to THE IPv4 exhaustion problem. I do support it and would like to see this= =20 work continued. Cheers, Ales > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Victor > Kuarsingh > Sent: Friday, February 17, 2012 1:31 AM > To: fred@cisco.com; v6ops@ietf.org > Cc: draft-ietf-v6ops-464xlat@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-ietf-v6ops-464xlat >=20 > Fred, >=20 > This work in my mind represents important work that should continue. > Putting a mobile operator hat on, it provides the last bit of functionall= y > to make IPv6 with NAT64 a real and workable option for Wireless > deployments based on known behaviours in commercially available product > (I.e. Infrequent, but need for IPv4 connections). >=20 > Given the content in the draft and testing/results provided thus far, it > appears to be a viable option with a number of benefits (especially in th= e > mobile space related to PCC complacence). >=20 > I would support this work in whichever forum (group) it should exist. >=20 > Regards, >=20 > Victor K >=20 >=20 >=20 > On 12-02-15 9:55 AM, "fred@cisco.com" wrote: >=20 > > > >A new draft has been posted, at > >http://tools.ietf.org/html/draft-ietf-v6ops-464xlat. Please take a look > >at it and comment. > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From marc.lampo@eurid.eu Mon Feb 20 06:32:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A396121F8697 for ; Mon, 20 Feb 2012 06:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7auK-+Ho5M9 for ; Mon, 20 Feb 2012 06:32:02 -0800 (PST) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA4B21F8680 for ; Mon, 20 Feb 2012 06:32:02 -0800 (PST) X-ASG-Debug-ID: 1329748510-0369490e9a40890001-b2NLKh Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id BLmrYcUnTdJDtS3V; Mon, 20 Feb 2012 15:35:10 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 91C02E408B; Mon, 20 Feb 2012 15:32:00 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9cnLggzzGiJ; Mon, 20 Feb 2012 15:32:00 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 7F86CE4050; Mon, 20 Feb 2012 15:32:00 +0100 (CET) From: "Marc Lampo" To: References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> In-Reply-To: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> Date: Mon, 20 Feb 2012 15:32:00 +0100 (CET) X-ASG-Orig-Subj: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Message-ID: <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Aczg83O386MCjRztTKmEcXn2PnRYGAO5mMuQ Content-Language: en-za X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1329748510 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:32:06 -0000 Hello, (sorry to be late with my comments, bit overloaded on my side) 6.1 Security Considerations - paragraph 2 (on DNSSEC) The text states : "there should not be any negative impact on DNSSEC" In my opinion, this is *wrong* : It is correct that, if an AAAA record exists (in a DNSSEC's zone), the appropriate RRSIG will be known to authoritative NS's. If, via white listing, the decision is taken not to present the AAAA record (and its signature), this seems OK. However : not returning an AAAA record seems identical to : there is no AAAA record. And that - there is no AAAA record - yields to "Next Secure" changes ! If no AAAA record exists, for a name, the corresponding NSEC (NSEC3) record should not hold a reference to AAAA. But if that AAAA record does exist, the authoritative NS will have NSEC (NSEC3) data that shows so. A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but due to whitelisting will not be returned), cannot be proven by accompanying (and required) NSEC (NSEC3) information. Hence : this draft will/might make DNSSEC validating name servers fail. If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) in detail, please observe : 1) the caching name server (and "stub resolver") ask 2 queries (there is only one line, but it are two queries : one for "A", one for "AAAA") 2) if the caching name server (or stub resolver) performs DNSSEC validation, it will never accept a reply of "NODATA" to the query of AAAA (because the NSEC (NSEC3) information will not prove that non-existance) ((and the validating name server will repeat the query to all authoritative NS's, looking for a validatable answer)) (the final result, to the user might be that only the A record is useable - mission accomplished ? But the side effect will be that validating caching name servers will hit *all* authoritative servers for the domain, "in search of" a correctly validating answer.) So, while for the end-user, the result might be identical, one "security impact" of this approach is additional (useless) DNS traffic and additional load on authoritative NS's (that implement whitelisting) Kind regards, Marc Lampo Security Officer EURid -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: 01 February 2012 04:09 PM To: IETF-Announce Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Considerations for Transitioning Content to IPv6' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-15. 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 describes considerations for the transition of end user content on the Internet to IPv6. While this is tailored to address end user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impl ications/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impl ications/ No IPR declarations have been submitted directly on this I-D. From rbonica@juniper.net Mon Feb 20 07:21:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B056521F856A for ; Mon, 20 Feb 2012 07:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.229 X-Spam-Level: X-Spam-Status: No, score=-106.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srMMNTX7fODr for ; Mon, 20 Feb 2012 07:21:36 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 3B38921F855D for ; Mon, 20 Feb 2012 07:21:36 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT0Jk/a7gRUR9rIywe0OlesblzyJrdFpF@postini.com; Mon, 20 Feb 2012 07:21:36 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 20 Feb 2012 07:18:25 -0800 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 Feb 2012 07:18:24 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 20 Feb 2012 10:18:23 -0500 From: Ronald Bonica To: Marc Lampo , "jason_livingood@cable.comcast.com" Date: Mon, 20 Feb 2012 10:18:36 -0500 Thread-Topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-Index: Aczg83O386MCjRztTKmEcXn2PnRYGAO5mMuQAAIvihA= Message-ID: <13205C286662DE4387D9AF3AC30EF456D7671A210C@EMBX01-WF.jnpr.net> References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> In-Reply-To: <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> 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-EXCLAIMER-MD-CONFIG: f8e27f27-03b2-4c3e-9447-119194e72cb6 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 15:21:41 -0000 Marco, The IESG has already approved this drat for publication. However, I think t= hat your comment is significant if you can make a case that the DNS informa= tion returned to the user is less trustworthy than it would have been had t= he authoritative DNS not been practicing whitelisiting. Can you make this c= ase? Ron > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Marc Lampo > Sent: Monday, February 20, 2012 9:32 AM > To: jason_livingood@cable.comcast.com > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Last Call: implications-08.txt> (Considerations for Transitioning Content to IPv6) > to Informational RFC >=20 > Hello, >=20 > (sorry to be late with my comments, bit overloaded on my side) >=20 > 6.1 Security Considerations - paragraph 2 (on DNSSEC) > The text states : "there should not be any negative impact on DNSSEC" > In my opinion, this is *wrong* : >=20 >=20 > It is correct that, if an AAAA record exists (in a DNSSEC's zone), > the appropriate RRSIG will be known to authoritative NS's. > If, via white listing, the decision is taken not to present the AAAA > record > (and its signature), this seems OK. >=20 > However : not returning an AAAA record seems identical to : there is no > AAAA record. > And that - there is no AAAA record - yields to "Next Secure" changes ! > If no AAAA record exists, for a name, the corresponding NSEC (NSEC3) > record > should not hold a reference to AAAA. > But if that AAAA record does exist, the authoritative NS will have NSEC > (NSEC3) > data that shows so. >=20 > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but due > to > whitelisting > will not be returned), cannot be proven by accompanying (and required) > NSEC (NSEC3) > information. > Hence : this draft will/might make DNSSEC validating name servers fail. >=20 >=20 > If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) in > detail, > please observe : > 1) the caching name server (and "stub resolver") ask 2 queries > (there is only one line, > but it are two queries : one for "A", one for "AAAA") > 2) if the caching name server (or stub resolver) performs DNSSEC > validation, > it will never accept a reply of "NODATA" to the query of AAAA > (because the NSEC (NSEC3) information will not prove that > non-existance) > ((and the validating name server will repeat the query to all > authoritative NS's, looking for a validatable answer)) >=20 > (the final result, to the user might be that only the A record is > useable > - mission accomplished ? > But the side effect will be that validating caching name servers will > hit > *all* authoritative servers for the domain, > "in search of" a correctly validating answer.) >=20 > So, while for the end-user, the result might be identical, > one "security impact" of this approach is > additional (useless) DNS traffic and > additional load on authoritative NS's (that implement whitelisting) >=20 >=20 > Kind regards, >=20 > Marc Lampo > Security Officer > EURid >=20 >=20 > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: 01 February 2012 04:09 PM > To: IETF-Announce > Cc: v6ops@ietf.org > Subject: [v6ops] Last Call: > > (Considerations for Transitioning Content to IPv6) to Informational RFC >=20 >=20 > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'Considerations for Transitioning Content to IPv6' > as an > Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-15. 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. >=20 > Abstract >=20 >=20 > This document describes considerations for the transition of end > user > content on the Internet to IPv6. While this is tailored to address > end user content, which is typically web-based, many aspects of this > document may be more broadly applicable to the transition to IPv6 of > other applications and services. This document explores the > challenges involved in the transition to IPv6, potential migration > tactics, possible migration phases, and other considerations. The > audience for this document is the Internet community generally, > particularly IPv6 implementers. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting- > impl > ications/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting- > impl > ications/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Mon Feb 20 07:32:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2F421F861E for ; Mon, 20 Feb 2012 07:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.984 X-Spam-Level: X-Spam-Status: No, score=-2.984 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-n1rBTUgqnV for ; Mon, 20 Feb 2012 07:32:05 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E58D21F861B for ; Mon, 20 Feb 2012 07:32:05 -0800 (PST) Received: by dakl33 with SMTP id l33so6146777dak.31 for ; Mon, 20 Feb 2012 07:32:05 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.125.193 as permitted sender) client-ip=10.68.125.193; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.125.193 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.125.193]) by 10.68.125.193 with SMTP id ms1mr10736380pbb.71.1329751925199 (num_hops = 1); Mon, 20 Feb 2012 07:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3jbxCk2yR3IQCx6JGU9CjIu2rYy533wwjUBOkMvGXf0=; b=S+ZmZfAiFbW9tqPzcfmfW8nMPHChi3rEOcazG6VNA+xABGK3EwKMB4n8+kLdQUplXS kiYRjCFRalErAeHYFdCJ20Gry7GnSJP/+4zrvRrLpAPcPyGCJntf3EWjpNmLsis1GzlA bBvrUZy1bOJTBuDTNSY74m7si7PKyDu+/M16g= MIME-Version: 1.0 Received: by 10.68.125.193 with SMTP id ms1mr8979066pbb.71.1329751924619; Mon, 20 Feb 2012 07:32:04 -0800 (PST) Received: by 10.142.99.12 with HTTP; Mon, 20 Feb 2012 07:32:04 -0800 (PST) In-Reply-To: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> Date: Mon, 20 Feb 2012 07:32:04 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 15:32:10 -0000 On Mon, Feb 20, 2012 at 1:52 AM, R=E9mi Despr=E9s wrote: > cameron, > > Le 2012-02-19 =E0 16:58, Cameron Byrne a =E9crit : > >> Remi, >> >> I am sorry there has been confusion. =A0Allow me to attempt to clarify >> >> On Sun, Feb 19, 2012 at 6:29 AM, R=E9mi Despr=E9s wrote: >>> Russ, Jari, Ralph, Fred, >>> >>> On February 15, tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00.htm= l was re-posted as a v6ops WG document (tools.ietf.org/html/draft-ietf-v6op= s-464xlat-00.html). >>> Interpreting past v6ops discussion as a consensus for this to happen is= AFAIK quite excessive (see in particular www.ietf.org/mail-archive/web/v6o= ps/current/msg11979), and besides that is inappropriate in view of WG chart= ers and other existing drafts. >>> >> >> The 464XLAT draft was posted as WG draft on Feb 15 at the direction of >> the v6ops co-chairs > > That's why a lack of consensus is relevant. > >> Please note the draft was first brought to v6ops for review on Jan 16, >> link below > > Well known, but since then a number of comments suggested to send the doc= ument to some other WG. > >> http://www.ietf.org/mail-archive/web/v6ops/current/msg11830.html > > >>> Reasons AGAINST making it a v6ops document include AFAIK: >>> >>> (1) There is an active 464XLAT draft IN SOFTWIRE (tools.ietf.org/html/d= raft-mawatari-softwire-464xlat-02.html), very similar, and still being disc= ussed in this WG. >>> >> >> I believe there is an active discussion in v6ops, not in Softwires. >> >> On v6ops 464XLAT appears in email titles 55 times from today back till >> December 1 >> >> There have been ZERO emails with 464XLAT in the title during the same >> period softwires > > Fair enough, but it was never closed, and I do believe it is useful to pu= rsue it ("resume it" if you prefer). > There is room I think to include the concept (which BTW I find quite inte= resting) in the unified stateless solution under study in Softwire. > It seems to find a natural place there. > >> In consultation with the co-chairs, we have moved the 464XLAT from >> softwires to v6ops. =A0If you think the discussion is still going on in >> softwires despite 3 months of silence where 464XLAT was in the title, >> then i can send an email to softwiress making it clear that 464XLAT >> has moved due to lack of interest > > True, little interest was expressed then, but this was when the work on M= AP and 4rd-U was really beginning. > The work on these two has now progressed in Softwire, and considering fun= ctional requirements of 464XLAT in this context makes in my undesrtsnding a= lot of sense. > > >> and no charter scope within >> Softwires to support further discussion. > > Debatable I suppose since 464XLAT was first submitted there. > >>> (2) Although the draft was presented in v6 pops as a "trial deployment = report" (www.ietf.org/mail-archive/web/v6ops/current/msg11907.html), its on= ly reference to a deployment is "Incidentally, Japan Internet Exchange(JPIX= ) is providing 464XLAT trial service since July 2010" (it doesn't say how I= Pv6 /96 prefixes were assigned to customers, whether tested UEs included ro= uters or not, whether they included DNS proxies or not, etc. etc.). On the = contrary, it essentially includes specification of a NEW SOLUTION (in parti= cular a new IPv6 address format). >>> >> >> You seem to have some technical questions about address assignment >> that are all clear in the draft, and if not clear in the draft then >> clear in the code. > > Well, reading code is AFAIK a way to check that it complies to a spec, bu= t not the right way to understand what a specification means. > Specifications must be clear by themselves. > > In any case, my question isn't about understanding the specification (cle= ar enough IMHO for this level of discussion). It reflects interest for a mo= re complete draft describing the trial configuration, with its configuratio= n parameters. (The specification describes a number of options: with or wit= hout DNS64; possibility that an "access networks that does not allow for a = dedicated translation prefix"; CLATs that may get /64s via DHCPv6 or by oth= er means; inclusion fragment headers possibly systematic but optional; poss= ibility for some CLATs to get longer than /64 IPv6 prefixes). > Glad to clarify this here. My trial required no change to the IPv6-only DNS64/NAT64 network beta service that i have offered to by customers for close to 2 years now. Adding 464XLAT was purely a CPE function layered onto that existing network "as is". 1. Yes, we use DNS64 2. A dedicated translation prefix was not used. Since my 3GPP Release 7 network does not support DHCP at all, the address is pushed to the UE as part of PDP setup in the PCO IE. This is how all IPv4 and IPv6 addresses are assigned to UEs in my network. 3. The UE, which is also the CLAT, received a single /64 of IPv6 from the network and no IPv4. This is the only address scheme that was used or can be used in my network 4. There was no change to the RFC 6146/6145 behavior, fragment headers were included. 5. Pref64/n was discovered using draft-ietf-behave-nat64-discovery-heurist= ic > I just say that a real "trial deployment report" would be nice to have, b= ut of course no obligation. > I am attempting to operate as transparently as possible. Please feel free to query me further. > >> =A0I won't address them hear since they have already >> been discussed in the draft and v6ops archive. =A0Feel free to start >> another thread on specific technical clarifications after reviewing >> the draft and discussion archive. >> >> Allow me to clarify again the evolution of some of this. >> >> I sent this email as a report on my trial of the 464XLAT draft. >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg11906.html >> >> The *draft* is not a trial report, the draft describes an architecture >> that has been deployed in the USA and Japan. =A0That much is clear in >> the first few lines of the draft. >> >> The *email* =A0describes a trial that i have done where 464XLAT resolves >> the 15% persistent brokenness for Android phones in an IPv6-only >> NAT64/DNS64 network due to IPv4 referrals and so on. >> > >> I understand that became unclear as the v6ops discussion evolved. >> Specifically, Fred forwarded the trial report email and asked for WG >> consideration of the draft. > > I agree that it is how confusion started. > >> =A0But, you will please understand that my >> representation was that the *email* was a trial report of the *draft* >> that describes an architecture. > > I do understand this, yes. > >>> (3) The v6ops charter does say =A0"Solicit input from network operators= and users to identify operational issues with the IPv4/IPv6 Internet, and = determine solutions or workarounds to those issues", BUT it also says "This= work should PRIMARILY be conducted by those areas and WGs which are respon= sible and best fit to analyze these problems." >>> >> >> Agreed, that is the v6ops charter. =A0464XLAT does not define any new >> standards. It is an informational document that simply describes how > >> to use RFC6145 and RFC6146 to achieve the desired result of making >> IPv6-only network acceptable for subscribers today. > > The draft does include SHOULDs and MAYs that belong to standardization vo= cabulary, e.g.: > "In cases where the access network does not allow for a dedicated transla= tion prefix, the CLAT SHOULD take ownership of the lowest /96 from an attac= hed interface's /64 to source and receive translation traffic. Establishing= ownership of the /96 requires that the CLAT SHOULD perform NDP so that no = other nodes on the /64 may use the lowest /96." > Correct. The authors, including myself, are not as experience as you, but i believe informational I-D may use this language. Just looking, RFC6092 is informational and uses this language. Also, we are open to changing the document type to BCP or Standard Track if that is a better fit. It has been recommended on list that this draft go standards track. So, i believe there is an open discussion here. We can adjust as the WG sees fit. Right now, i feel most comfortable with informational. I don't think experimental is helpful to network operators that trying to solve a near term problem with "no new technology". >> The email i sent >> regarding deployment report confirms the goals of the 464XLAT draft >> can and are achieved. > > "IPv4 access service to mobile AND WIRELINE IPv6-only edge networks"? > (From the abstract, upper cases added.) > >> We have running code, it is open source, and >> all code has been contributed upstream pending acceptance. =A0This is >> all live and working today because no new technologies are used. =A0It >> is simply reusing existing capabilities. > > Close to that, but not "simply" (see above). > > >>> (4) Softwire's charter has "Developments for stateless legacy IPv4 carr= ied over IPv6". >>> 464XLAT introduces in user devices a =A0new stateless behavior, but one= that is based on private IPv4 addresses like DS-lite, and one that uses IP= v4 packet formats like those of MA-T or 4rd-U (three Softwire designs). SOF= TWIRE therefore continues to be the right WG to pursue this work. >>> >> >> This is NOT a stateless solution, it uses stateful RFC6146 AND >> stateless RFC6145. > > AFAIK, it adds rigorously nothing to NAT64 (RFC6146). > OTOH, it introduces a new CPE behavior that uses RFC6145, but adds few de= sign choices to it, like MAP-T. >> Please read the draft. > CPE is not an IETF standard. So, changing its behavior to include RFC6145 should not be controversial. > Your suggesting that I didn't read the draft could advantageously have be= en avoided (IMHO). > Agreed. >> =A0 =A0RFC6145 is not MAP or >> 4RD. > > Why you say this is unclear. AFAIK nobody ever suggested that. > I keep getting the feeling like 464XLAT should be abandoned and the use cases should be folded into MAP-T by the MAP-T author or 4RD-U from the 4RD-U authors, both on and off list. It seems the softwire folks see 464XLAT as a competing technology. IMHO, MAP-T and 4RD-U do not solve *my* problems. We took time to document how 464XLAT is unique in the draft. I have brought to softwires the concern that stateless core NAT64 is not acceptable given the address efficiency issues (please don't blast me about how my issues are non-issues). On the softwire list, i brought this up and was told a /14 of IPv4 was probably needed to meet a mid to large size wireless operator. Unfortunately, these address are not available in APNIC today and will not be available in ARIN or RIPE in the very near future.... considering the timeline scope the IETF operates at. That said, the stateless solutions have an audience with network operators that already have large allocations and wish to be more efficient. That's great, live and let live. Also, the MAP family is quite complicated for me and lack of trial deployment at scale is a concern since the IPv4 exhaustion issue is pressing. I hope you see that 464XLAT is an operational solution without any novel technology. >>> To conclude, a rectification of the situation would be to: >>> - cancel the ietf-v6ops-464xlat draft >>> - continue to work on the Softwire 464XLAT, in relationship with other = stateless user-device solutions (hopefully with an updated draft version re= flecting recent additions made in the v6ops draft) >>> >> >> I hope my clarification has made it clear that nothing needs to be >> retracted and that Softwires is not the right place since no new >> technology is being created and that 464XLAT is indeed both stateless >> on the CPE/UE and stateful in the network, therefore Softwires is not >> the right place. 464XLAT is an operator focused solution created and >> deployed already by operators using existing IETF standards. > > The claim that nothing new is specified is the main point that is challen= ged (see above) I am still unclear on your overall concerns with 464XLAT. Are these your concerns? 1. We add RFC6145 functions to a "CPE" 2. We use SHOULD and MAY in an informational document? >> >>> Besides, and authors are willing to, a real "trial deployment report", = with more deployment information, would be very welcome as an individually = submitted draft. >>> >> >> My hope is that the trial deployment email was clear enough and yet >> another ID would not be helpful. =A0The email on the trial deployment >> report of 464XLAT referenced nearly 200 tested applications and all >> the code and functions are open source, so anyone can repeat and >> validate them. =A0For folks with a T-Mobile USA SIM and a Nexus S phone, >> the steps are as simple as flash the provided images or compile from >> source yourself. > > The draft is about mobile AND "wireline" (understood to include DSL). > Yes, i was commenting on my validation work in mobile. It works in wireline as well. CB >> Please accept that this draft is running code, open sourced, >> validated in deployment, and solves a VERY REAL problem for network >> operators that do not have IPv4 addresses and MUST continue to grow >> their networks. =A0RIR exhaustion is real in Asia today and will be real >> in North America this year. =A0The trial deployment has made clear, i >> hope, that 464XLAT enables a mobile wireless provider to deploy >> Android phones as IPv6-only and have service parity with existing >> IPv4-only phones. > > This isn't sufficient to say that the specification is complete for all i= ts use cases. > Besides, I would say that these phones are in some sense dual-stack: > - they are in all cases IPv4 aware, at least for IPv4-only applications > - if acting as routers, they "SHOULD" include IPv4-aware DNS proxies. > >> From my perspective, this is a substantial achievement that the IETF >> should support and expedite instead of slow. > > The idea is quite interesting, and quickly dealing with it in relationshi= p with current work on MAP-T and 4rd-U makes a lot of sense (IMHO). > > Regards, > RD > > >> >> I once again call on folks to read the draft and contribute to make it b= etter >> >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00 >> >> If you can, also please review and trial the code yourself >> >> http://dan.drown.org/android/clat/ >> >> CB >> >>> Regards, >>> RD >>> >>> >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Mon Feb 20 07:45:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EC221F8584 for ; Mon, 20 Feb 2012 07:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO7ihTUb340U for ; Mon, 20 Feb 2012 07:45:25 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42E4E21F85D8 for ; Mon, 20 Feb 2012 07:45:24 -0800 (PST) Received: by dakl33 with SMTP id l33so6158012dak.31 for ; Mon, 20 Feb 2012 07:45:24 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.236.167 as permitted sender) client-ip=10.68.236.167; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.236.167 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.236.167]) by 10.68.236.167 with SMTP id uv7mr18791684pbc.113.1329752724170 (num_hops = 1); Mon, 20 Feb 2012 07:45:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1BCVZVvhgchtaq1D8UOjHL+SbOAdVMyd7B/zLFLilSY=; b=vVWXmJKzYGQO255tJnjsOR4IwMR0MgTiP0Em0+aJls4YXeuHj9TrGLmx89alJDrZz2 4dqqdBEF0++EzAH382r++MBc53uG0sHV4YbtMXRhp1YcP9FLOuWOlObyINhO/yzaQ/p6 J0zXiD8bJlPNh9XKcn/sky0IUOYJCpdDE5QwA= MIME-Version: 1.0 Received: by 10.68.236.167 with SMTP id uv7mr15966041pbc.113.1329752724110; Mon, 20 Feb 2012 07:45:24 -0800 (PST) Received: by 10.142.99.12 with HTTP; Mon, 20 Feb 2012 07:45:23 -0800 (PST) In-Reply-To: <82A0D21F-4038-4EAA-8490-A68D30C92D0A@laposte.net> References: <4F41255B.3020103@bogus.com> <4F414C28.8040606@gmail.com> <82A0D21F-4038-4EAA-8490-A68D30C92D0A@laposte.net> Date: Mon, 20 Feb 2012 07:45:23 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 15:45:29 -0000 On Mon, Feb 20, 2012 at 3:05 AM, R=E9mi Despr=E9s wrote: > Hi Brian, > > Le 2012-02-19 =E0 20:23, Brian E Carpenter a =E9crit : > >> On 2012-02-20 05:37, Joel jaeggli wrote: >>> So, when I read =A0464xlat what I see is a stack of existing RFCs used = in >>> a specific fashion which the draft describes. I don't see any new >>> standards work. >> >> fwiw I agree with that. I think v6ops is the appropriate venue >> for descriptions of how to knit existing protocol specs together >> in operational scenarios. >> >> I do object slightly to the way draft-ietf-v6ops-464xlat uses >> the word "architecture". It's an operational scenario, not an >> architecture, IMHO. > > The draft says "No new protocol required", but: > > 1. > Section 7.5 says: > "In the best case, the CLAT will have a dedicated /64 via DHCPv6 or other= means to source and receive IPv6 packets associated with the [RFC6145] sta= teless translation of IPv4 packets to the local clients." > How this is provided via DHCPv6 has AFAIK to be specified. > If i may clarify, DHCPv6 PD may provide the CPE with many /64. The CPE may choose any /64 that it is delegated for this purpose. Nothing new here. No special DHCP parameters. > Note that RFC5969 says "6rd specifies a protocol mechanism" although it i= s also using just a stack of previously available protocols, with new param= eters obtained in DHCP. > > 2. > The same section says: > "In cases where the access network does not allow for a dedicated transla= tion prefix, the CLAT SHOULD take ownership of the lowest /96 from an attac= hed interface's /64 to source and receive translation traffic. Establishing= ownership of the /96 requires that the CLAT SHOULD perform NDP so that no = other nodes on the /64 may use the lowest /96." > > This is AFAIK a new specification, which requires specific code. > If not, I am interested in learning why. > I can tell you have seen this behavior before on a NAT-PT platform. But, also nothing new IMHO. The /96 is logically owned by the CPE as a virtual address. Thus, the CPE does NDP to avoid collisions. > 3. > Section 7.6 says: > "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 Fra= gment Header, since IPv4 host does not set the DF bit." > AFAIK, this isn't in existing RFCs. > Fragment header treatment is discussed here http://tools.ietf.org/html/rfc6145#section-4 Does this answer your question? > Section 7.7 says: > "The CLAT SHOULD set itself as the DNS server via DHCP or other means and= proxy DNS queries for IPv4 and IPv6 clients" > =A0I find the "other means" confusing here (a new protocol?). We are trying to keep the architecture open for new standards track work that may come some day. > "The CLAT SHOULD allow for a client to query any DNS server of its choice= and bypass the proxy." > =A0What the CLAT has to do for this isn't specified. (Also whether this D= NS has to synthesize A records or not isn't specified.) > We don't mention synthesized because it is not required. The CLAT just has to do the defined CLAT functions including RFC6145 CB > > To me this shows that, Devil being in details, this draft isn't just an o= perational scenario with existing RFC specifications. > > Yet, as I said, there is in this draft a very valuable idea, worth treati= ng rigorously. > > Kind regards, > RD > > > > >> >> =A0 Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From he@uninett.no Mon Feb 20 08:02:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BB421F86E0 for ; Mon, 20 Feb 2012 08:02:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrUxQVgDidZW for ; Mon, 20 Feb 2012 08:02:19 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id D302821F874C for ; Mon, 20 Feb 2012 08:02:18 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 9D1833D0B4; Mon, 20 Feb 2012 17:02:16 +0100 (CET) Date: Mon, 20 Feb 2012 17:02:16 +0100 (CET) Message-Id: <20120220.170216.446120856.he@uninett.no> To: rbonica@juniper.net From: Havard Eidnes In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D7671A210C@EMBX01-WF.jnpr.net> References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> <13205C286662DE4387D9AF3AC30EF456D7671A210C@EMBX01-WF.jnpr.net> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marc.lampo@eurid.eu, v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 16:02:19 -0000 > The IESG has already approved this drat for publication. However, I > think that your comment is significant if you can make a case that > the DNS information returned to the user is less trustworthy than it > would have been had the authoritative DNS not been practicing > whitelisiting. Can you make this case? "Less trustworthy" would be an imprecise euphemistic term to use in this case. Instead, the returned data would fail cryptographic validation as performed by DNSSEC, and would therefore be discarded as invalid ("incorrect") by a DNSSEC-validating resolver. Therefore, it would seem to me that you can either do AAAA whitelisting or DNSSEC, but not successfully do both. Regards, - H=E5vard From cb.list6@gmail.com Mon Feb 20 08:32:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C3B21F8796 for ; Mon, 20 Feb 2012 08:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.115 X-Spam-Level: X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWqxkOnn90MI for ; Mon, 20 Feb 2012 08:32:21 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A0EBD21F867C for ; Mon, 20 Feb 2012 08:32:21 -0800 (PST) Received: by dakl33 with SMTP id l33so6198992dak.31 for ; Mon, 20 Feb 2012 08:32:21 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.213.232 as permitted sender) client-ip=10.68.213.232; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.213.232 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.213.232]) by 10.68.213.232 with SMTP id nv8mr56728732pbc.155.1329755541547 (num_hops = 1); Mon, 20 Feb 2012 08:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nVeFGIG6jChf0qhaKT0nSHDTMH1UcUn8LLkpPaEoIQE=; b=bfrMQ/SsMohXg5uPgQS+l5kRsCL2VODaRpspKIDviQqpXhyjIEnllsQy8oDtb2NA// jPT3rsObNNB9TXUQdtKaJZPQqgHeFKc7fTvVNeVcDCFH+ipr81V3lXoIoW+TAZSb7pV0 OU4sm/6cZuHv1ZNnAkpG3dvkJKA8CuiqxG8fI= MIME-Version: 1.0 Received: by 10.68.213.232 with SMTP id nv8mr47410879pbc.155.1329755541479; Mon, 20 Feb 2012 08:32:21 -0800 (PST) Received: by 10.142.99.12 with HTTP; Mon, 20 Feb 2012 08:32:21 -0800 (PST) In-Reply-To: <4f421974.88bfe00a.48cf.367f@mx.google.com> References: <4f421974.88bfe00a.48cf.367f@mx.google.com> Date: Mon, 20 Feb 2012 08:32:21 -0800 Message-ID: From: Cameron Byrne To: "tsavo.stds@gmail.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "housley@vigilsec.com" , "v6ops@ietf.org" Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 16:32:26 -0000 On Mon, Feb 20, 2012 at 1:59 AM, tsavo.stds@gmail.com wrote: > I have to say I am really interested on this as well, as during BIH-work = we were explicitly forbidden to define how BIH would work if destination ha= s an A record (instead of only AAAA). > > E.g. we could not write that if there is A record, it is passed as is to = application and following IPv4 packet then translated to Ipv6.... > > I understand that times change, but this change is quite fast (document s= aying not allowed in RFC editor queue while new document saying allowed ado= pted as wg document..). > I see no reason to pause progress towards enabling proven functionality and leveraging existing standards and working code for the purpose of posterity > Maybe this document should state that described approach still is not rec= ommended. > That would be quite unfortunate. I made the case for double translation with BIH almost a year ago http://www.ietf.org/mail-archive/web/behave/current/msg09480.html > Or IETF(IESG) should make their mind:) > Either that or we deliver the solutions to customers without them. My hope is that reality and the IETF specs do not part ways, yet again. CB > Teemu > > L=E4hetetty Nokia-puhelimestani > ---- alkuper=E4inen viesti ---- > L=E4hett.: Satoru Matsushima > L=E4het.: =A020.02.2012, 09:11 > V.ottaja: v6ops WG > Kopio: Russell Housley > Aihe: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to = be an ietf-v6ops I.D. > > > On 2012/02/20, at 4:23, Brian E Carpenter wrote: > >> On 2012-02-20 05:37, Joel jaeggli wrote: >>> So, when I read =A0464xlat what I see is a stack of existing RFCs used = in >>> a specific fashion which the draft describes. I don't see any new >>> standards work. >> >> fwiw I agree with that. I think v6ops is the appropriate venue >> for descriptions of how to knit existing protocol specs together >> in operational scenarios. >> >> I do object slightly to the way draft-ietf-v6ops-464xlat uses >> the word "architecture". It's an operational scenario, not an >> architecture, IMHO. >> > > I can see a strong statement that double protocol translation is an archi= tecture which is not recommended by the IETF. > (http://tools.ietf.org/html/draft-ietf-behave-v4v6-bih-09) > > I'd like to hear from chairs that does v6ops consent to be opposed to tha= t statement. > > cheers, > --satoru > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From wdec.ietf@gmail.com Mon Feb 20 08:45:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3656821F87AD for ; Mon, 20 Feb 2012 08:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.865 X-Spam-Level: X-Spam-Status: No, score=-2.865 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HATHCsDs7tEh for ; Mon, 20 Feb 2012 08:45:26 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4763321F87B5 for ; Mon, 20 Feb 2012 08:45:26 -0800 (PST) Received: by qan41 with SMTP id 41so6075796qan.10 for ; Mon, 20 Feb 2012 08:45:25 -0800 (PST) Received-SPF: pass (google.com: domain of wdec.ietf@gmail.com designates 10.229.76.139 as permitted sender) client-ip=10.229.76.139; Authentication-Results: mr.google.com; spf=pass (google.com: domain of wdec.ietf@gmail.com designates 10.229.76.139 as permitted sender) smtp.mail=wdec.ietf@gmail.com; dkim=pass header.i=wdec.ietf@gmail.com Received: from mr.google.com ([10.229.76.139]) by 10.229.76.139 with SMTP id c11mr16679828qck.1.1329756325918 (num_hops = 1); Mon, 20 Feb 2012 08:45:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=985psfQl3rhKMQwY+VfyprGkNFE/YROYdD6fWOJElIA=; b=BVnLOvQvGiMomlbs8gXnKixDuusaOzOzBdYOZfz3Ai9QSxx2UOmx5qGOZG1mYPUnDa k/jx60IDWmYiA+s+Mq4Y4gN3Syi/sLGzokTXphvP662/drwmD5EB3ufrfgIj7BOxSrlh yjFi7KzT6cr3a/MH4MaMVf+rjWqB0+DNmdrQg= MIME-Version: 1.0 Received: by 10.229.76.139 with SMTP id c11mr14178196qck.1.1329756325784; Mon, 20 Feb 2012 08:45:25 -0800 (PST) Received: by 10.229.82.201 with HTTP; Mon, 20 Feb 2012 08:45:25 -0800 (PST) In-Reply-To: References: <4F41255B.3020103@bogus.com> <4F414C28.8040606@gmail.com> <82A0D21F-4038-4EAA-8490-A68D30C92D0A@laposte.net> Date: Mon, 20 Feb 2012 17:45:25 +0100 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=002354470ab06facfc04b9680507 Cc: Russell Housley , v6ops WG Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 16:45:33 -0000 --002354470ab06facfc04b9680507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20 February 2012 16:45, Cameron Byrne wrote: > On Mon, Feb 20, 2012 at 3:05 AM, R=E9mi Despr=E9s > wrote: > > Hi Brian, > > > > Le 2012-02-19 =E0 20:23, Brian E Carpenter a =E9crit : > > > >> On 2012-02-20 05:37, Joel jaeggli wrote: > >>> So, when I read 464xlat what I see is a stack of existing RFCs used = in > >>> a specific fashion which the draft describes. I don't see any new > >>> standards work. > >> > >> fwiw I agree with that. I think v6ops is the appropriate venue > >> for descriptions of how to knit existing protocol specs together > >> in operational scenarios. > >> > >> I do object slightly to the way draft-ietf-v6ops-464xlat uses > >> the word "architecture". It's an operational scenario, not an > >> architecture, IMHO. > > > > The draft says "No new protocol required", but: > > > > 1. > > Section 7.5 says: > > "In the best case, the CLAT will have a dedicated /64 via DHCPv6 or > other means to source and receive IPv6 packets associated with the > [RFC6145] stateless translation of IPv4 packets to the local clients." > > How this is provided via DHCPv6 has AFAIK to be specified. > > > > If i may clarify, DHCPv6 PD may provide the CPE with many /64. The > CPE may choose any /64 that it is delegated for this purpose. Nothing > new here. No special DHCP parameters. > > > Note that RFC5969 says "6rd specifies a protocol mechanism" although it > is also using just a stack of previously available protocols, with new > parameters obtained in DHCP. > > > > 2. > > The same section says: > > "In cases where the access network does not allow for a dedicated > translation prefix, the CLAT SHOULD take ownership of the lowest /96 from > an attached interface's /64 to source and receive translation traffic. > Establishing ownership of the /96 requires that the CLAT SHOULD perform N= DP > so that no other nodes on the /64 may use the lowest /96." > > > > This is AFAIK a new specification, which requires specific code. > > If not, I am interested in learning why. > > > > I can tell you have seen this behavior before on a NAT-PT platform. > But, also nothing new IMHO. The /96 is logically owned by the CPE as > a virtual address. Thus, the CPE does NDP to avoid collisions. > As far as I can tell, there is no specification except the xlat464 draft which (attempts to) define that a device with /64, or a PD, prefix should derive a /96 from it and use the lower 32 bits for stateless mapping an(y) received arbitrary source IPv4 addresses. Yes there is clear use of existing stateless NAT64 here, applied in a very specific way; the proof point being that any regular NAT64 capable device that one would put on a network would, afaik, not accomplish all of the above "auto magically" when connecting to the network. -Woj. > > > 3. > > Section 7.6 says: > > "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 > Fragment Header, since IPv4 host does not set the DF bit." > > AFAIK, this isn't in existing RFCs. > > > > Fragment header treatment is discussed here > http://tools.ietf.org/html/rfc6145#section-4 > > Does this answer your question? > > > Section 7.7 says: > > "The CLAT SHOULD set itself as the DNS server via DHCP or other means > and proxy DNS queries for IPv4 and IPv6 clients" > > I find the "other means" confusing here (a new protocol?). > > We are trying to keep the architecture open for new standards track > work that may come some day. > > > "The CLAT SHOULD allow for a client to query any DNS server of its > choice and bypass the proxy." > > What the CLAT has to do for this isn't specified. (Also whether this > DNS has to synthesize A records or not isn't specified.) > > > > We don't mention synthesized because it is not required. > > The CLAT just has to do the defined CLAT functions including RFC6145 > > CB > > > > To me this shows that, Devil being in details, this draft isn't just an > operational scenario with existing RFC specifications. > > > > Yet, as I said, there is in this draft a very valuable idea, worth > treating rigorously. > > > > Kind regards, > > RD > > > > > > > > > >> > >> Brian > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --002354470ab06facfc04b9680507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 20 February 2012 16:45, Cameron Byrne= <cb.list6@gmail= .com> wrote:
On Mon, Feb 20, 2012 at 3:05 AM, R=E9mi Despr=E9s <despres.remi@laposte.net> w= rote:
> Hi Brian,
>
> Le 2012-02-19 =E0 20:23, Brian E Carpenter a =E9crit :
>
>> On 2012-02-20 05:37, Joel jaeggli wrote:
>>> So, when I read =A0464xlat what I see is a stack of existing R= FCs used in
>>> a specific fashion which the draft describes. I don't see = any new
>>> standards work.
>>
>> fwiw I agree with that. I think v6ops is the appropriate venue
>> for descriptions of how to knit existing protocol specs together >> in operational scenarios.
>>
>> I do object slightly to the way draft-ietf-v6ops-464xlat uses
>> the word "architecture". It's an operational scenari= o, not an
>> architecture, IMHO.
>
> The draft says "No new protocol required", but:
>
> 1.
> Section 7.5 says:
> "In the best case, the CLAT will have a dedicated /64 via DHCPv6 = or other means to source and receive IPv6 packets associated with the [RFC6= 145] stateless translation of IPv4 packets to the local clients."
> How this is provided via DHCPv6 has AFAIK to be specified.
>

If i may clarify, =A0DHCPv6 PD may provide the CPE with many /64. =A0= The
CPE may choose any /64 that it is delegated for this purpose. =A0Nothing new here. No special DHCP parameters.

> Note that RFC5969 says "6rd specifies a protocol mechanism" = although it is also using just a stack of previously available protocols, w= ith new parameters obtained in DHCP.
>
> 2.
> The same section says:
> "In cases where the access network does not allow for a dedicated= translation prefix, the CLAT SHOULD take ownership of the lowest /96 from = an attached interface's /64 to source and receive translation traffic. = Establishing ownership of the /96 requires that the CLAT SHOULD perform NDP= so that no other nodes on the /64 may use the lowest /96."
>
> This is AFAIK a new specification, which requires specific code.
> If not, I am interested in learning why.
>

I can tell you have seen this behavior before on a NAT-PT platform. But, also nothing new IMHO. =A0The /96 is logically owned by the CPE as
a virtual address. =A0Thus, the CPE does NDP to avoid collisions.

As far as I can tell, there is no specification except the = xlat464 draft which (attempts to) define that a device with /64, or a PD, p= refix should derive a /96 from it and use the lower 32 bits for stateless m= apping an(y) received arbitrary source IPv4 addresses.
Yes there is clear use of existing stateless NAT64 here, applied in a very = specific way; the proof point being that any regular NAT64 capable device t= hat one would put on a network would, afaik, not accomplish all of the abov= e "auto magically" when connecting to the network.

-Woj.
=A0

> 3.
> Section 7.6 says:
> "In the 464XLAT environment, the PLAT and CLAT SHOULD include an = IPv6 Fragment Header, since IPv4 host does not set the DF bit."
> AFAIK, this isn't in existing RFCs.
>

Fragment header treatment is discussed here
= http://tools.ietf.org/html/rfc6145#section-4

Does this answer your question?

> Section 7.7 says:
> "The CLAT SHOULD set itself as the DNS server via DHCP or other m= eans and proxy DNS queries for IPv4 and IPv6 clients"
> =A0I find the "other means" confusing here (a new protocol?)= .

We are trying to keep the architecture open for new standards track work that may come some day.

> "The CLAT SHOULD allow for a client to query any DNS server of it= s choice and bypass the proxy."
> =A0What the CLAT has to do for this isn't specified. (Also whether= this DNS has to synthesize A records or not isn't specified.)
>

We don't mention synthesized because it is not required.

The CLAT just has to do the defined CLAT functions including RFC6145

CB
>
> To me this shows that, Devil being in details, this draft isn't ju= st an operational scenario with existing RFC specifications.
>
> Yet, as I said, there is in this draft a very valuable idea, worth tre= ating rigorously.
>
> Kind regards,
> RD
>
>
>
>
>>
>> =A0 Brian
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--002354470ab06facfc04b9680507-- From despres.remi@laposte.net Mon Feb 20 09:23:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BE121F87A0 for ; Mon, 20 Feb 2012 09:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+wblvFRijJk for ; Mon, 20 Feb 2012 09:23:24 -0800 (PST) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 305E321F8792 for ; Mon, 20 Feb 2012 09:23:23 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id cHPK1i00737Y3f403HPKbT; Mon, 20 Feb 2012 18:23:22 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 20 Feb 2012 18:23:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:23:28 -0000 Cameron, Thanks for the additional information below. More comments in line. Le 2012-02-20 =E0 16:32, Cameron Byrne a =E9crit : > On Mon, Feb 20, 2012 at 1:52 AM, R=E9mi Despr=E9s = wrote: ... >> In any case, my question isn't about understanding the specification = (clear enough IMHO for this level of discussion). It reflects interest = for a more complete draft describing the trial configuration, with its = configuration parameters. (The specification describes a number of = options: with or without DNS64; possibility that an "access networks = that does not allow for a dedicated translation prefix"; CLATs that may = get /64s via DHCPv6 or by other means; inclusion fragment headers = possibly systematic but optional; possibility for some CLATs to get = longer than /64 IPv6 prefixes). >=20 > Glad to clarify this here. My trial required no change to the > IPv6-only DNS64/NAT64 network beta service that i have offered to by > customers for close to 2 years now. Adding 464XLAT was purely a CPE > function layered onto that existing network "as is". >=20 > 1. Yes, we use DNS64 OK.=20 Could you clarify then what justifies that "It does not require DNS64". > 2. A dedicated translation prefix was not used. Since my 3GPP Release > 7 network does not support DHCP at all, the address is pushed to the > UE as part of PDP setup in the PCO IE. Why, then, say "In the best case, the CLAT will have a dedicated /64" =20= > This is how all IPv4 and IPv6 > addresses are assigned to UEs in my network. Is this with a standard format (if yes, a reference would make it = clear). > 3. The UE, which is also the CLAT, received a single /64 of IPv6 from > the network OK. > and no IPv4. (Already understood, otherwise nothing new would be needed) > This is the only address scheme that was > used or can be used in my network >=20 > 4. There was no change to the RFC 6146/6145 behavior, fragment > headers were included. Then why to add a section which describes two variants. Besides, I didn't understand this sentence "In the 464XLAT environment, = the PLAT and CLAT SHOULD include an IPv6 Fragment Header, *since IPv4 = host does not set the DF bit*" (asterisks added).=20 >=20 > 5. Pref64/n was discovered using = draft-ietf-behave-nat64-discovery-heuristic OK. >> I just say that a real "trial deployment report" would be nice to = have, but of course no obligation. >>=20 >=20 > I am attempting to operate as transparently as possible. =20 > Please feel > free to query me further. There is some of this of this above, thanks. ... >> The draft does include SHOULDs and MAYs that belong to = standardization vocabulary, e.g.: >> "In cases where the access network does not allow for a dedicated = translation prefix, the CLAT SHOULD take ownership of the lowest /96 = from an attached interface's /64 to source and receive translation = traffic. Establishing ownership of the /96 requires that the CLAT SHOULD = perform NDP so that no other nodes on the /64 may use the lowest /96." >>=20 >=20 > Correct. The authors, including myself, are not as experience as you, I am not as much experienced in IETF procedures as you seem to believe. Like yourself, I try to understand and apply BCPs. > but i believe informational I-D may use this language. >=20 > Just looking, RFC6092 is informational and uses this language. Personally, I find it confusing in RFC6092, but this is another subject. > Also, > we are open to changing the document type to BCP or Standard Track if > that is a better fit. It has been recommended on list that this draft > go standards track. So, i believe there is an open discussion here. > We can adjust as the WG sees fit. Right now, i feel most comfortable > with informational. I don't think experimental is helpful to network > operators that trying to solve a near term problem with "no new > technology". My point is that it includes some behavior specification (464XLAT = compliance is more than just compliance with RFCs it refers to). ... >=20 >>> RFC6145 is not MAP or >>> 4RD. >>=20 >> Why you say this is unclear. AFAIK nobody ever suggested that. >>=20 >=20 > I keep getting the feeling like 464XLAT should be abandoned and the > use cases should be folded into MAP-T by the MAP-T author or 4RD-U > from the 4RD-U authors, both on and off list. I don't know about off-list, but to say differently what think: - abandoning the new idea expressed in the 464XLAT would be a very bad = idea - OTOH, dealing with it in the context of 4rd-U seems to me a good idea = (unify stateless UE behaviors so that they can work consistently both in = networks using stateful NAT64s and those using using with stateless ISP = nodes) - working together for this to happen in Softwire would be welcome on my = side. BTW, if you can take the time to read the 4rd-U draft, your questions = and comments will be most welcome.=20 > It seems the softwire > folks see 464XLAT as a competing technology. I am an active Softwire guy, and don't see it that way. > IMHO, MAP-T and 4RD-U do > not solve *my* problems. 4rd-U isn't frozen yet. I see solving your problem as an objective. > We took time to document how 464XLAT is > unique in the draft. >=20 > I have brought to softwires the concern that stateless core NAT64 is > not acceptable given the address efficiency issues (please don't blast > me about how my issues are non-issues). I never did, I hope, but I think I rather asked about real order of = magnitudes of your problem. Didn't get it yet. Ideally that would include the number of simultaneous devices to be = supported, and the size of the IPv4 space available, with lengths of = IPv4 prefixes that compose it. In any case, your requirement is yours, and some other operators do = have different requirements = (tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-00.html)= . That's why some coordination makes sense. =20 > On the softwire list, i > brought this up and was told a /14 of IPv4 was probably needed to meet > a mid to large size wireless operator. =20 > Unfortunately, these address > are not available in APNIC today and will not be available in ARIN or > RIPE in the very near future.... considering the timeline scope the > IETF operates at. That said, the stateless solutions have an audience > with network operators that already have large allocations and wish to > be more efficient. That's great, live and let live. >=20 > Also, the MAP family is quite complicated for me and lack of trial > deployment at scale is a concern since the IPv4 exhaustion issue is > pressing. I share this view on current MAP documents. OTOH, I do think that making UEs that would support a 4rd-U, completed = with permitted RFC1918 addresses in customer sites, would largely = increase their applicability with a limited enough added complexity. > I hope you see that 464XLAT is an operational solution without any > novel technology. In my understanding, 464XLAT does introduce a quite useful technology = that is almost completely based on existing pieces, like 6rd, but this = doesn't exclude these two from being NEW technologies.=20 Regards, RD From joelja@bogus.com Mon Feb 20 09:43:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D3921F87A0 for ; Mon, 20 Feb 2012 09:43:00 -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.223, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVJpVl93w5XC for ; Mon, 20 Feb 2012 09:42:56 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 67FD521F86D1 for ; Mon, 20 Feb 2012 09:42:56 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q1KHgq2R076583 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 20 Feb 2012 17:42:53 GMT (envelope-from joelja@bogus.com) Message-ID: <4F42861C.20208@bogus.com> Date: Mon, 20 Feb 2012 09:42:52 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> In-Reply-To: <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 20 Feb 2012 17:42:54 +0000 (UTC) Cc: Russell Housley , v6ops WG Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:43:01 -0000 On 2/20/12 09:23 , Rémi Després wrote: > Cameron, > Le 2012-02-20 à 16:32, Cameron Byrne a écrit : >> >> I have brought to softwires the concern that stateless core NAT64 is >> not acceptable given the address efficiency issues (please don't blast >> me about how my issues are non-issues). > > I never did, I hope, but I think I rather asked about real order of magnitudes of your problem. > Didn't get it yet. Running a network with 30 million users and a /15 ip addresses is the right order of magnitude to describe tmob. There are networks that are larger but with proportionally fewer and smaller networks with a lot less. > Ideally that would include the number of simultaneous devices to be supported, and the size of the IPv4 space available, with lengths of IPv4 prefixes that compose it. > In any case, your requirement is yours, and some other operators do have different requirements (tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-00.html). > That's why some coordination makes sense. > >> On the softwire list, i >> brought this up and was told a /14 of IPv4 was probably needed to meet >> a mid to large size wireless operator. >> Unfortunately, these address >> are not available in APNIC today and will not be available in ARIN or >> RIPE in the very near future.... considering the timeline scope the >> IETF operates at. That said, the stateless solutions have an audience >> with network operators that already have large allocations and wish to >> be more efficient. That's great, live and let live. From v6ops@globis.net Mon Feb 20 09:45:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81E721F8795 for ; Mon, 20 Feb 2012 09:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PT014JlGqO3g for ; Mon, 20 Feb 2012 09:45:20 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5651821F85E4 for ; Mon, 20 Feb 2012 09:45:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id EF14F870069; Mon, 20 Feb 2012 18:45:16 +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 o-tOKpJQfft5; Mon, 20 Feb 2012 18:45:04 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id A01A387005E; Mon, 20 Feb 2012 18:45:04 +0100 (CET) Message-ID: <4F4286A0.6040203@globis.net> Date: Mon, 20 Feb 2012 18:45:04 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> In-Reply-To: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> Content-Type: multipart/alternative; boundary="------------030801020101020105050609" Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:45:24 -0000 This is a multi-part message in MIME format. --------------030801020101020105050609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have read this document. I find it well written and easy to follow. I also think it contains important information for the operational community. Thanks. One thing I do not find satisfactory is one of the MUST drop rules: > 3. If the layer-2 device is unable to identify whether the packet is > an ICMPv6 Router Advertisement message or not (i.e., the packet > is a fragment, and the necessary information is missing), the > IPv6 Source Address of the packet is a link-local address or the > unspecified address (::), and the Hop Limit is 255, silently drop > the packet. I understand the logic of the rule. But to me this suggests that the RA Guard filtering mechanism may well exceed its raison d'etre of layer 2 filtering of unauthorized RA messages. I get the feeling therefore that the detection/definition of what is an unauthorized RA message may currently be underspecified. Or else the RA message itself is currently specified in such a way that the RA Guard filtering approach is not viable, as it may be circumvented by other yet-to-be-discovered cloaking mechanisms. This rule we may also be in danger of heralding in a "drop all source hop-limit 255 unless" layer-2 filter to cover a multitude of evils for various protocols and messages. What other legitimate traffic would/could this rule potentially break? regards RayH fred@cisco.com wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation. Please take a look at it and comment. > > --------------030801020101020105050609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have read this document. I find it well written and easy to follow. I also think it contains important information for the operational community. Thanks.

One thing I do not find satisfactory is one of the MUST drop rules:

3.  If the layer-2 device is unable to identify whether the packet is
       an ICMPv6 Router Advertisement message or not (i.e., the packet
       is a fragment, and the necessary information is missing), the
       IPv6 Source Address of the packet is a link-local address or the
       unspecified address (::), and the Hop Limit is 255, silently drop
       the packet.
I understand the logic of the rule. But to me this suggests that the RA Guard filtering mechanism may well exceed its raison d'etre of layer 2 filtering of unauthorized RA messages. I get the feeling therefore that the detection/definition of what is an unauthorized RA message may currently be underspecified. Or else the RA message itself is currently specified in such a way that the RA Guard filtering approach is not viable, as it may be circumvented by other yet-to-be-discovered cloaking mechanisms.

This rule we may also be in danger of heralding in a "drop all source <link-local-address> hop-limit 255 unless" layer-2 filter to cover a multitude of evils for various protocols and messages.

What other legitimate traffic would/could this rule potentially break?

regards
RayH

fred@cisco.com wrote: 
A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation. Please take a look at it and comment.
--------------030801020101020105050609-- From cb.list6@gmail.com Mon Feb 20 10:44:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CCA21F869D for ; Mon, 20 Feb 2012 10:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.262 X-Spam-Level: X-Spam-Status: No, score=-3.262 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIe--nTRoP7W for ; Mon, 20 Feb 2012 10:44:46 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9451421F87D8 for ; Mon, 20 Feb 2012 10:44:46 -0800 (PST) Received: by dakl33 with SMTP id l33so6305690dak.31 for ; Mon, 20 Feb 2012 10:44:46 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.125.193 as permitted sender) client-ip=10.68.125.193; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.125.193 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.125.193]) by 10.68.125.193 with SMTP id ms1mr12690230pbb.71.1329763486476 (num_hops = 1); Mon, 20 Feb 2012 10:44:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JrT86y20lcJl4HAEaBOQHKPYePPLz6fYsyjHmQCBCOE=; b=ivhgfaAIHyBhT8LIg/yx/wBJUBjfW7tnfecM1VrpphWaomP5iKC+8QtHA3E4Fm52EE QyvBCF3wRvzaPWvy9PI87+70ne0pU1cqEjoV94+JfVH4z90cEO2lU5oF3vmaRD0jSMpJ BkdI0Jz5iEXo+EZeqOCD/SAWUZbg06AMDtN4c= MIME-Version: 1.0 Received: by 10.68.125.193 with SMTP id ms1mr10456571pbb.71.1329763486383; Mon, 20 Feb 2012 10:44:46 -0800 (PST) Received: by 10.142.99.12 with HTTP; Mon, 20 Feb 2012 10:44:46 -0800 (PST) In-Reply-To: <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> Date: Mon, 20 Feb 2012 10:44:46 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:44:50 -0000 inline On Mon, Feb 20, 2012 at 9:23 AM, R=E9mi Despr=E9s wrote: > Cameron, > > Thanks for the additional information below. > More comments in line. > > Le 2012-02-20 =E0 16:32, Cameron Byrne a =E9crit : >> On Mon, Feb 20, 2012 at 1:52 AM, R=E9mi Despr=E9s wrote: > ... >>> In any case, my question isn't about understanding the specification (c= lear enough IMHO for this level of discussion). It reflects interest for a = more complete draft describing the trial configuration, with its configurat= ion parameters. (The specification describes a number of options: with or w= ithout DNS64; possibility that an "access networks that does not allow for = a dedicated translation prefix"; CLATs that may get /64s via DHCPv6 or by o= ther means; inclusion fragment headers possibly systematic but optional; po= ssibility for some CLATs to get longer than /64 IPv6 prefixes). >> >> Glad to clarify this here. =A0My trial required no change to the >> IPv6-only DNS64/NAT64 network beta service that i have offered to by >> customers for close to 2 years now. =A0Adding 464XLAT was purely a CPE >> function layered onto that existing network "as is". >> >> 1. Yes, we use DNS64 > > OK. > Could you clarify then what justifies that "It does not require DNS64". > 464XLAT works fine without DNS64. Meaning, the CLAT may do stateless RFC 6145 NAT46 to the IPv6-only access network destine for RFC 6146 NAT64 towards the Internet This is a complete solution for any IPv4-only hosts behind the CLAT. For me, DNS64 is advantageous to use for the following reasons in *my* netw= ork 1. DNS64 is already deployed in my network as part of the NAT64/DNS64 service i offer today 2. DNS64 allows for the discovery of the Pref64 using draft-ietf-behave-nat64-discovery-heuristic 3. DNS64 allows for single translation in cases where the host and application are capable of doing IPv6 but the server does not have a AAAA record. This is a very common case for my scenario. Regarding discovery of the Pref64, the draft discusses that Pref64 may be discovered through others means. DHCP options in the future, manual configuration, proprietary methods ... are all possible in the future... Today i have draft-ietf-behave-nat64-discovery-heuristic working but i do not want to constrain implementations to just those that use DNS64. >> 2. A dedicated translation prefix was not used. =A0Since my 3GPP Release >> 7 network does not support DHCP at all, the address is pushed to the >> UE as part of PDP setup in the PCO IE. > > Why, then, say "In the best case, the CLAT will have a dedicated /64" > It just seems cleaner to me to have a dedicated /64 if it is available. Operationally, aside from the NDP claiming the /96, there is no difference to have dedicated or not dedicated. >> =A0This is how all IPv4 and IPv6 >> addresses are assigned to UEs in my network. > > Is this with a standard format (if yes, a reference would make it clear). > I was mistaken before, here is the reference for SLAAC being used for address configurations. http://tools.ietf.org/html/rfc6459#section-5.2 >> 3. =A0The UE, which is also the CLAT, received a single /64 of IPv6 from >> the network > > OK. > >> and no IPv4. > > (Already understood, otherwise nothing new would be needed) > > >> =A0This is the only address scheme that was >> used or can be used in my network >> >> 4. =A0There was no change to the RFC 6146/6145 behavior, fragment >> headers were included. > > Then why to add a section which describes two variants. > Besides, I didn't understand this sentence "In the 464XLAT environment, t= he PLAT and CLAT SHOULD include an IPv6 Fragment Header, *since IPv4 host d= oes not set the DF bit*" (asterisks added). I think it may be wise to remove that language. Let me check with my co-authors. >> >> 5. =A0Pref64/n was discovered using draft-ietf-behave-nat64-discovery-he= uristic > > OK. > > >>> I just say that a real "trial deployment report" would be nice to have,= but of course no obligation. >>> >> >> I am attempting to operate as transparently as possible. > >> Please feel >> free to query me further. > > There is some of this of this above, thanks. > > ... >>> The draft does include SHOULDs and MAYs that belong to standardization = vocabulary, e.g.: >>> "In cases where the access network does not allow for a dedicated trans= lation prefix, the CLAT SHOULD take ownership of the lowest /96 from an att= ached interface's /64 to source and receive translation traffic. Establishi= ng ownership of the /96 requires that the CLAT SHOULD perform NDP so that n= o other nodes on the /64 may use the lowest /96." >>> >> >> Correct. =A0The authors, including myself, are not as experience as you, > > I am not as much experienced in IETF procedures as you seem to believe. > Like yourself, I try to understand and apply BCPs. > >> but i believe informational I-D may use this language. >> >> Just looking, RFC6092 is informational and uses this language. > > Personally, I find it confusing in RFC6092, but this is another subject. > >> Also, >> we are open to changing the document type to BCP or Standard Track if >> that is a better fit. =A0It has been recommended on list that this draft >> go standards track. =A0So, i believe there is an open discussion here. >> We can adjust as the WG sees fit. =A0Right now, i feel most comfortable >> with informational. =A0I don't think experimental is helpful to network >> operators that trying to solve a near term problem with "no new >> technology". > > My point is that it includes some behavior specification (464XLAT complia= nce is more than just compliance with RFCs it refers to). > > ... > >> >>>> =A0 =A0RFC6145 is not MAP or >>>> 4RD. >>> >>> Why you say this is unclear. AFAIK nobody ever suggested that. >>> >> >> I keep getting the feeling like 464XLAT should be abandoned and the >> use cases should be folded into MAP-T by the MAP-T author or 4RD-U >> from the 4RD-U authors, both on and off list. > > I don't know about off-list, but to say differently what think: > - abandoning the new idea expressed in the 464XLAT would be a very bad id= ea > - OTOH, dealing with it in the context of 4rd-U seems to me a good idea (= unify stateless UE behaviors so that they can work consistently both in net= works using stateful NAT64s and those using using with stateless ISP nodes) > - working together for this to happen in Softwire would be welcome on my = side. > > BTW, if you can take the time to read the 4rd-U draft, your questions and= comments will be most welcome. > >> =A0It seems the softwire >> folks see 464XLAT as a competing technology. > > I am an active Softwire guy, and don't see it that way. > >> IMHO, MAP-T and 4RD-U do >> not solve *my* problems. > > 4rd-U isn't frozen yet. > I see solving your problem as an objective. > >> =A0We took time to document how 464XLAT is >> unique in the draft. >> >> I have brought to softwires the concern that stateless core NAT64 is >> not acceptable given the address efficiency issues (please don't blast >> me about how my issues are non-issues). > > I never did, I hope, but I think I rather asked about real order of magni= tudes of your problem. Publicly available information is that T-Mobile USA has 30+ Million subscribers and about 100,000 IPv4 addresses, total. Not just for subscribers, 100k IP addresses to run the whole business (data centers, web sites, DNS servers, ...). About 1/3 of those subscribers are actively attached to the data network and consuming an IPv4 address, data network attachment is growing You can assume we are ~100% utilized on our IPv4 addresses, and that nearly all subscribers reside behind existing 19 /25 public IPv4 pools. My own Android phone has ~20 active TCP sessions at steady-state (push updates from email, twitter, facebook, ...). When i do tethering, it goes up substantially. As you can see, things are pretty tight. They are going to get more tight. We chose stateful NAT64 as a path forward since it was a simple feature add that leverages the existing NAT44 hardware and /25 ipv4 NAT blocks. This means that deploying NAT64 required no new IPv4 public addresses. Going to 4RD-U and MAP-T would require a substantial re-work of the network to provide a suitable pool of IPv4 addresses for the stateless translation. We want 464XLAT since it enables us to make IPv6-only a feasible service option to our subscribers in the near term, the only missing piece from generally available code (shipping products) is the CPE / UE to do the CLAT functions of RFC6145 and Pref64 discovery. The functions have been submitted to the Android Open Source Project. That said, please don't try to re-engineer this network scenario on the list. This is a real scenario, lets not make it a diversion. I tried to have this generic scenario discussion on softwires here http://www.ietf.org/mail-archive/web/softwires/current/msg03402.html > Didn't get it yet. > Ideally that would include the number of simultaneous devices to be suppo= rted, and the size of the IPv4 space available, with lengths of IPv4 prefix= es that compose it. > In any case, your requirement is yours, =A0and some other operators do ha= ve different requirements (tools.ietf.org/html/draft-ietf-softwire-stateles= s-4v6-motivation-00.html). > That's why some coordination makes sense. > >> =A0On the softwire list, i >> brought this up and was told a /14 of IPv4 was probably needed to meet >> a mid to large size wireless operator. >> Unfortunately, these address >> are not available in APNIC today and will not be available in ARIN or >> RIPE in the very near future.... considering the timeline scope the >> IETF operates at. =A0That said, the stateless solutions have an audience >> with network operators that already have large allocations and wish to >> be more efficient. =A0That's great, live and let live. >> >> Also, the MAP family is quite complicated for me and lack of trial >> deployment at scale is a concern since the IPv4 exhaustion issue is >> pressing. > > I share this view on current MAP documents. > > OTOH, I do think that making UEs that would support a 4rd-U, completed wi= th permitted RFC1918 addresses in customer sites, would largely increase th= eir applicability with a limited enough added complexity. > > >> I hope you see that 464XLAT is an operational solution without any >> novel technology. > > In my understanding, 464XLAT does introduce a quite useful technology tha= t is almost completely based on existing pieces, like 6rd, =A0but this does= n't exclude these two from being NEW technologies. > > > Regards, > RD > > From brian.e.carpenter@gmail.com Mon Feb 20 12:22:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D613F21F87B6 for ; Mon, 20 Feb 2012 12:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.137 X-Spam-Level: X-Spam-Status: No, score=-103.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4gEi28EmKrT for ; Mon, 20 Feb 2012 12:22:23 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B46321F851C for ; Mon, 20 Feb 2012 12:22:23 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8774904obb.31 for ; Mon, 20 Feb 2012 12:22:23 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.140.105 as permitted sender) client-ip=10.50.140.105; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.140.105 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.50.140.105]) by 10.50.140.105 with SMTP id rf9mr15269917igb.24.1329769343213 (num_hops = 1); Mon, 20 Feb 2012 12:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hlAD2iwUmSNKBmzCmHnFH2qYGhHn6Kcd+7sAjxXnA3w=; b=bjUHbzMwxfjm+pHUeffoSQSzn/He26nAXdrxNGulv+NHtWOdzODegRdsHLmJiJvjl2 ShsNpTT8tcn7sNKY28wqV1l6rZ89JS58MTsWBAXBMMk0NBrwsBsn/aSKR+y+nFNI1hR7 2ZcYCHkbO1Ol1knFrqMuBbmQSgB3mcepXfYLo= Received: by 10.50.140.105 with SMTP id rf9mr12371236igb.24.1329769341591; Mon, 20 Feb 2012 12:22:21 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id az9sm3372116igb.2.2012.02.20.12.22.18 (version=SSLv3 cipher=OTHER); Mon, 20 Feb 2012 12:22:20 -0800 (PST) Message-ID: <4F42AB72.1030304@gmail.com> Date: Tue, 21 Feb 2012 09:22:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cameron Byrne References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT and the term "architecture" -- WAS draft-464XLAT not a "trial deployment report" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:22:25 -0000 Cameron, I did say that I object *slightly* to the choice of word. I've been a bit suspicious of the word "architecture" for many years, probably the result of serving in the Internet Architecture Board while living next door to an actual architect who designed buildings, and who lectured me at length about the proper meaning ;-). Basically the word means different things to different people, whatever the Open Group says. But let's not waste more time on it. Regards Brian On 2012-02-20 14:35, Cameron Byrne wrote: > New title to focus on the taxonomy and term "architecture" > > On Sun, Feb 19, 2012 at 1:44 PM, Victor Kuarsingh > wrote: >> >> On 12-02-19 2:23 PM, "Brian E Carpenter" >> wrote: >> > > > >>> I do object slightly to the way draft-ietf-v6ops-464xlat uses >>> the word "architecture". It's an operational scenario, not an >>> architecture, IMHO. >> Are you concerned that the use of "architecture" may be interpreted as >> protocol architecture vs. network architecture? IMHO, I would suggest >> what's in the document reflects a network/deployment architecture (my >> opinion). >> >> Perhaps authors can clarify what they meant. >> > > Gladly. > > I will call on the TOGAF definitions: > > http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_08 > > Architecture: > > 1) A formal description of a system, or a detailed plan of the > system at component level, to guide its implementation (source: > ISO/IEC 42010:2007). > 2) The structure of components, their inter-relationships, and > the principles and guidelines governing their design and evolution > over time. > > I believe the 464XLAT draft fits pretty well in this definition. We > look to describe the system, guide implementation, and show how the > pieces fit together. > > I believe the term framework is too broad (but close) and solution and > scenario are too specific for the context of this draft to cover both > wireline and wireless. In a few cases, for example address assignment > to the CPE / UE and Pref64/n discovery, we supply multiple methods > that the desired outcome can be achieved to accommodate and not limit > how 464XLAT can be applied now and in the future. > > We took care to not be overly prescriptive in defining how a network > operator shall design their network. One of the key values we believe > publishing the draft will bring is the ability to describe succinctly > yet generically how traffic is treated in a 464XLAT network so that > all parties (software, hardware, application, peers...) can have a > common understanding of the network capabilities and the way in which > traffic will be treated. > > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Mon Feb 20 12:32:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0881D21F8546 for ; Mon, 20 Feb 2012 12:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.749 X-Spam-Level: X-Spam-Status: No, score=-101.749 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pI93QGLM-R+p for ; Mon, 20 Feb 2012 12:32:23 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 73E6821F8526 for ; Mon, 20 Feb 2012 12:32:23 -0800 (PST) Received: from Joels-MacBook-Pro.local (89.sub-166-250-32.myvzw.com [166.250.32.89]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q1KKWIt7079623 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 20 Feb 2012 20:32:19 GMT (envelope-from joelja@bogus.com) Message-ID: <4F42ADCC.9070806@bogus.com> Date: Mon, 20 Feb 2012 12:32:12 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?windows-1252?Q?V=EDzdal_Ale=9A?= References: <201202151455.q1FEt0K02883@ftpeng-update.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC67E419632@SRVHKE02.rdm.cz> In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC67E419632@SRVHKE02.rdm.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 20 Feb 2012 20:32:21 +0000 (UTC) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-464xlat@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:32:24 -0000 On 2/20/12 04:07 , Vízdal Aleš wrote: > +1 > > I fully agree with Victor's words as this draft is providing a real solution > to THE IPv4 exhaustion problem. I do support it and would like to see this > work continued. I would probably construe that more narrowly... The draft provides a solution to an aspect of a providers ipv4 exhaustion problem. It appears on the face of it to provide effective cover for the deployment of ipv6 only networks which have limited pools of available ipv4 addresses. > Cheers, > Ales > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Victor >> Kuarsingh >> Sent: Friday, February 17, 2012 1:31 AM >> To: fred@cisco.com; v6ops@ietf.org >> Cc: draft-ietf-v6ops-464xlat@tools.ietf.org >> Subject: Re: [v6ops] new draft: draft-ietf-v6ops-464xlat >> >> Fred, >> >> This work in my mind represents important work that should continue. >> Putting a mobile operator hat on, it provides the last bit of functionally >> to make IPv6 with NAT64 a real and workable option for Wireless >> deployments based on known behaviours in commercially available product >> (I.e. Infrequent, but need for IPv4 connections). >> >> Given the content in the draft and testing/results provided thus far, it >> appears to be a viable option with a number of benefits (especially in the >> mobile space related to PCC complacence). >> >> I would support this work in whichever forum (group) it should exist. >> >> Regards, >> >> Victor K >> >> >> >> On 12-02-15 9:55 AM, "fred@cisco.com" wrote: >> >>> >>> A new draft has been posted, at >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat. Please take a look >>> at it and comment. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Mon Feb 20 12:34:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2415321F85B7 for ; Mon, 20 Feb 2012 12:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.135 X-Spam-Level: X-Spam-Status: No, score=-103.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcbRWKtwtEqp for ; Mon, 20 Feb 2012 12:34:51 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 08EEB21F852A for ; Mon, 20 Feb 2012 12:34:46 -0800 (PST) Received: by iagf6 with SMTP id f6so9888917iag.31 for ; Mon, 20 Feb 2012 12:34:46 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.89.196 as permitted sender) client-ip=10.50.89.196; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.89.196 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.50.89.196]) by 10.50.89.196 with SMTP id bq4mr15277533igb.26.1329770086790 (num_hops = 1); Mon, 20 Feb 2012 12:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8wEdoiegr10pBlnuLII/iQ8d73RBz49gQC1CaakkU5w=; b=E+jRQyx6/YURIehu0FqFyCYIvgQaBiAxwNc5yBJV14ccOXTIOs4ftbw2rxwt8dQGYA 0TDcG3K8jnEhsRnjfN5A83HownMyE3p7mPIein1bPzNkpi6Srz+nJOc9zJ7jLNZxAF2d XFDptLBk9d7tg/u1slAJQ25DL7iHWaHfQVnvo= Received: by 10.50.89.196 with SMTP id bq4mr12366656igb.26.1329770084900; Mon, 20 Feb 2012 12:34:44 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id d15sm29512157ibf.7.2012.02.20.12.34.41 (version=SSLv3 cipher=OTHER); Mon, 20 Feb 2012 12:34:43 -0800 (PST) Message-ID: <4F42AE5F.702@gmail.com> Date: Tue, 21 Feb 2012 09:34:39 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Satoru Matsushima References: <4F41255B.3020103@bogus.com> <4F414C28.8040606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:34:52 -0000 On 2012-02-20 20:11, Satoru Matsushima wrote: ... > I can see a strong statement that double protocol translation is an architecture which is not recommended by the IETF. > (http://tools.ietf.org/html/draft-ietf-behave-v4v6-bih-09) > > I'd like to hear from chairs that does v6ops consent to be opposed to that statement. Well, that's for the WG as a whole to say, not the chairs. I hate translation, and I've hated it since RFC 1671. Therefore, I hate double translation more. However, we are going to get double translation anyway - via CPE NAT and CGN, or via 464XLAT. It is a consequence of running out of IPv4 before the universal deployment of IPv6. I don't see one being more evil than the other, so it makes sense to document the mechanisms. Brian From marka@isc.org Mon Feb 20 12:49:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4522321F85BD for ; Mon, 20 Feb 2012 12:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcyjaHYE3dCR for ; Mon, 20 Feb 2012 12:49:13 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4D921F854E for ; Mon, 20 Feb 2012 12:49:07 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id AA7FB5F98AF; Mon, 20 Feb 2012 20:48:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:f4e3:78f1:fc50:1cf2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5575C216C31; Mon, 20 Feb 2012 20:48:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 556861DA0095; Tue, 21 Feb 2012 07:48:42 +1100 (EST) To: Havard Eidnes From: Mark Andrews References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> <13205C286662DE4387D9AF3AC30EF456D7671A210C@EMBX01-WF.jnpr.net> <20120220.170216.446120856.he@uninett.no> In-reply-to: Your message of "Mon, 20 Feb 2012 17:02:16 BST." <20120220.170216.446120856.he@uninett.no> Date: Tue, 21 Feb 2012 07:48:42 +1100 Message-Id: <20120220204842.556861DA0095@drugs.dv.isc.org> Cc: marc.lampo@eurid.eu, v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:49:14 -0000 One can whitelist with DNSSEC at the source. It just requires having two nsec/nsec3 chains if the zone is signed. One with AAAA records in the bit map field and one without. There are a number of ways to implement this. It's just a matter of returning consistent answers. In named this can be done with views. view "aaaa" { match-clients { key aaaa; !key noaaaa; whitelist; }; zone "example.com" { type master; file "aaaa/example.com.signed"; }; }; view "noaaaa" { match-clients { key noaaaa; !key aaaa; !whitelist; any; }; zone "example.com" { type master; file "noaaaa/example.com.signed"; }; }; If you want to whitelist in the resolver, then DO=1 + signed AAAA disables whitelisting. There is no point when the client can detect that it is happening. This is what we did for filter-aaaa in named. In message <20120220.170216.446120856.he@uninett.no>, Havard Eidnes writes: > > The IESG has already approved this drat for publication. However, I > > think that your comment is significant if you can make a case that > > the DNS information returned to the user is less trustworthy than it > > would have been had the authoritative DNS not been practicing > > whitelisiting. Can you make this case? > > "Less trustworthy" would be an imprecise euphemistic term to use in > this case. Instead, the returned data would fail cryptographic > validation as performed by DNSSEC, and would therefore be discarded as > invalid ("incorrect") by a DNSSEC-validating resolver. > > Therefore, it would seem to me that you can either do AAAA > whitelisting or DNSSEC, but not successfully do both. > > Regards, > > - H=E5vard > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From joelja@bogus.com Mon Feb 20 13:59:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113DF21F85A0 for ; Mon, 20 Feb 2012 13:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzsAd-ZRfSIz for ; Mon, 20 Feb 2012 13:59:52 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2B321F8504 for ; Mon, 20 Feb 2012 13:59:52 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q1KLvwJ4081240 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 20 Feb 2012 21:57:59 GMT (envelope-from joelja@bogus.com) Message-ID: <4F42C1E6.7010606@bogus.com> Date: Mon, 20 Feb 2012 13:57:58 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Marc Lampo References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> In-Reply-To: <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 20 Feb 2012 21:57:59 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:59:53 -0000 On 2/20/12 06:32 , Marc Lampo wrote: > Hello, > > (sorry to be late with my comments, bit overloaded on my side) > > 6.1 Security Considerations - paragraph 2 (on DNSSEC) > The text states : "there should not be any negative impact on DNSSEC" > In my opinion, this is *wrong* : > IMHO the following applies. if you have one zone yeah I agree. If you have two zones one with aaaa and one without (assuming this is done with dns views style implementation) you can sign both and they'll both be valid and complete from the vantage point of a client which resolves one or the other of them but not both. this is a traditional split horizon problem. it's just not inside/outside. joel > It is correct that, if an AAAA record exists (in a DNSSEC's zone), > the appropriate RRSIG will be known to authoritative NS's. > If, via white listing, the decision is taken not to present the AAAA > record > (and its signature), this seems OK. > > However : not returning an AAAA record seems identical to : there is no > AAAA record. > And that - there is no AAAA record - yields to "Next Secure" changes ! > If no AAAA record exists, for a name, the corresponding NSEC (NSEC3) > record > should not hold a reference to AAAA. > But if that AAAA record does exist, the authoritative NS will have NSEC > (NSEC3) > data that shows so. > > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but due to > whitelisting > will not be returned), cannot be proven by accompanying (and required) > NSEC (NSEC3) > information. > Hence : this draft will/might make DNSSEC validating name servers fail. > > > If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) in > detail, > please observe : > 1) the caching name server (and "stub resolver") ask 2 queries > (there is only one line, > but it are two queries : one for "A", one for "AAAA") > 2) if the caching name server (or stub resolver) performs DNSSEC > validation, > it will never accept a reply of "NODATA" to the query of AAAA > (because the NSEC (NSEC3) information will not prove that > non-existance) > ((and the validating name server will repeat the query to all > authoritative NS's, looking for a validatable answer)) > > (the final result, to the user might be that only the A record is useable > - mission accomplished ? > But the side effect will be that validating caching name servers will hit > *all* authoritative servers for the domain, > "in search of" a correctly validating answer.) > > So, while for the end-user, the result might be identical, > one "security impact" of this approach is > additional (useless) DNS traffic and > additional load on authoritative NS's (that implement whitelisting) > > > Kind regards, > > Marc Lampo > Security Officer > EURid > > > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: 01 February 2012 04:09 PM > To: IETF-Announce > Cc: v6ops@ietf.org > Subject: [v6ops] Last Call: > > (Considerations for Transitioning Content to IPv6) to Informational RFC > > > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'Considerations for Transitioning Content to IPv6' > as an > Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-15. 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 describes considerations for the transition of end user > content on the Internet to IPv6. While this is tailored to address > end user content, which is typically web-based, many aspects of this > document may be more broadly applicable to the transition to IPv6 of > other applications and services. This document explores the > challenges involved in the transition to IPv6, potential migration > tactics, possible migration phases, and other considerations. The > audience for this document is the Internet community generally, > particularly IPv6 implementers. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impl > ications/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impl > ications/ > > > No IPR declarations have been submitted directly on this I-D. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From shemant@cisco.com Mon Feb 20 14:28:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE3F21E8012; Mon, 20 Feb 2012 14:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.233 X-Spam-Level: X-Spam-Status: No, score=-8.233 tagged_above=-999 required=5 tests=[AWL=1.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x7=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A93v4kMVVv-v; Mon, 20 Feb 2012 14:28:35 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C121E800C; Mon, 20 Feb 2012 14:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=14468; q=dns/txt; s=iport; t=1329776915; x=1330986515; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=BPixA7dxfS869dHhBjSgUjyOx/zy37AJfss3cTSmHF0=; b=L6OfNZ7j7vZmVGC/T0JkbaNU9Kmy4T4XjovKGhwylZA5FmKPqwB/hxnn 6aNzSUwj6QaovFKcrl6y6C0q8fNsTtJTVVp3xsuGeYQsoToVz+/6dhVcL 7wMGKx34j7AzzvxdgFbca1z88gnlXnEakpJpKejPxdY76G6MPU8z91HEW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFACTIQk+tJV2Z/2dsb2JhbABDgk2tJIIMgQeBcwEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUDAQUIAQEEEwgaoXgBnn+LfxqEZhyCSmMEiE6fdQ X-IronPort-AV: E=Sophos;i="4.73,453,1325462400"; d="scan'208,217";a="60426823" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 20 Feb 2012 22:28:35 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q1KMSZiQ028403; Mon, 20 Feb 2012 22:28:35 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 16:28:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF01E.FBDB007A" Date: Mon, 20 Feb 2012 16:28:34 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3040761AD@XMB-RCD-109.cisco.com> In-Reply-To: <30931DE1-9E57-4296-B0FE-FA98F840D78F@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] PCP server in draft-ietf-v6ops-6204bis Thread-Index: Aczfm8f6mJMPiYxsTdCfMvc/CFtiqAQgm1ng References: "29 Jan 2012 09:51:52 PST."<85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com><201201301936.q0UJaEft000156@givry.fdupont.fr><2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com><4A687585-399D-4077-91AC-A1DC4F101E03@apple.com><2D09D61DDFA73D4C884805CC7865E611025BFE@GAALPA1MSGUSR9N.ITServices.sbc.com> <30931DE1-9E57-4296-B0FE-FA98F840D78F@apple.com> From: "Hemant Singh (shemant)" To: "james woodyatt" , "STARK, BARBARA H" X-OriginalArrivalTime: 20 Feb 2012 22:28:35.0436 (UTC) FILETIME=[FBFEB2C0:01CCF01E] Cc: IPv6 Operations , PCP , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:28:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF01E.FBDB007A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable James, =20 Sorry for the delay. Along the lines of what Barbara already said, I would like to add that major host OS's such as Microsoft Windows nor MAC OS (?) support a PCP client yet? At least till a few months back - vendors can keep me honest. If a host does not support a PCP client, what host will issue PCP requests to a PCP server in the IPv6 CPE router? Thus it makes sense to let the homenet WG deal with the PCP server req on the CPE router LAN and we ship rfc6204bis with the PCP client req that Alain Durand agreed with for DS-Lite use. Thanks to Dave Thaler who helped prepare text for the specific PCP client req in the CPE. =20 Thanks, =20 Hemant =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Monday, January 30, 2012 5:09 PM To: STARK, BARBARA H Cc: IPv6 Operations; PCP; draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis =20 =20 On Jan 30, 2012, at 12:59 , STARK, BARBARA H wrote: =20 If I were to make a technical argument about the harmfulness of RFC 6092, I would start with a lengthy review of its Security Considerations, in section 6. =20 I think it's a debatable question of procedure, whether it was an error at the time for V6OPS to publish RFC 6204 with its S-1 "requirement" to recommend implementation of RFC 6092. There was a clamor for the timely publication of a document, and neither HOMENET nor PCP were remotely close to usable when RFC 6204 was in WGLC. =20 I do think it shouldn't be controversial *now* to say that HOMENET is the venue where any further IETF recommendations about the implementation of RFC 6092 in IPv6 CE routers should originate. If you disagree, then once again, I have to ask for an explanation of your reasoning. I'm very interested to know. =20 If V6OPS wishes to continue stepping on HOMENET's charter, on the grounds that it already has its footprints there from before HOMENET was launched, then I suppose that's fine- but, if so, then I don't see why V6OPS shouldn't also take this opportunity to revise RFC 6204 to recommend a PCP server to meet REC-48 in RFC 6092. Again, as a purely technical matter- I know, technical matters are so boring- IETF has a standards-track protocol for ""host applications to solicit inbound traffic without advance knowledge of the addresses of exterior nodes with which they expect to communicate" as RFC 6092 recommends. We did not have this protocol when either RFC 6092 or RFC 6204 were ready for publication, but we do now. I fail to see any technical basis for leaving this unspecified in RFC 6204bis. Is there one? =20 Alternatively, if this is primarily a procedural dispute, then we could open RFC6092bis in order to update REC-48 accordingly, then cite the RFC6092bis in RFC6204bis with a publication in lockstep. Which would you prefer? =20 =20 -- j h woodyatt =20 ------_=_NextPart_001_01CCF01E.FBDB007A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

James,

 

Sorry for the delay.   Along the lines of what Barbara = already said, I would like to add that major host OS’s  such = as Microsoft Windows nor MAC OS (?) support a PCP client yet?  At = least till a few months back -  vendors can keep me = honest.   If a host does not support a PCP client, what host = will issue PCP requests to a PCP server in the IPv6 CPE = router?   Thus it makes sense to let the homenet WG deal with = the PCP server req on the CPE router LAN and we ship rfc6204bis with the = PCP client req that Alain Durand agreed with for DS-Lite use. =  Thanks to Dave Thaler who helped prepare text for the specific PCP = client req in the CPE.

 

Thanks,

 

Hemant

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = james woodyatt
Sent: Monday, January 30, 2012 5:09 = PM
To: STARK, BARBARA H
Cc: IPv6 Operations; PCP; = draft-ietf-v6ops-6204bis@tools.ietf.org
Subject: Re: [v6ops] = PCP server in = draft-ietf-v6ops-6204bis

 

 

On = Jan 30, 2012, at 12:59 , STARK, BARBARA H wrote:



 

If I were to make a technical argument about the = harmfulness of RFC 6092, I would start with a lengthy review of its = Security Considerations, in section 6.

 

I = think it's a debatable question of procedure, whether it was an error at = the time for V6OPS to publish RFC 6204 with its S-1 = "requirement" to recommend implementation of RFC 6092. =  There was a clamor for the timely publication of a document, and = neither HOMENET nor PCP were remotely close to usable when RFC 6204 was = in WGLC.

 

I = do think it shouldn't be controversial *now* to say that HOMENET is the = venue where any further IETF recommendations about the implementation of = RFC 6092 in IPv6 CE routers should originate.  If you disagree, = then once again, I have to ask for an explanation of your reasoning. =  I'm very interested to know.

 

If V6OPS wishes to continue stepping on HOMENET's = charter, on the grounds that it already has its footprints there from = before HOMENET was launched, then I suppose that's fine— but, if = so, then I don't see why V6OPS shouldn't also take this opportunity to = revise RFC 6204 to recommend a PCP server to meet REC-48 in RFC 6092. =  Again, as a purely technical matter— I know, technical = matters are so boring— IETF has a standards-track protocol for = ""host applications to solicit inbound traffic without advance = knowledge of the addresses of exterior nodes with which they expect to = communicate" as RFC 6092 recommends.  We did not have this = protocol when either RFC 6092 or RFC 6204 were ready for publication, = but we do now.  I fail to see any technical basis for leaving this = unspecified in RFC 6204bis.  Is there = one?

 

Alternatively, if this is primarily a procedural = dispute, then we could open RFC6092bis in order to update REC-48 = accordingly, then cite the RFC6092bis in RFC6204bis with a publication = in lockstep.  Which would you prefer?

 

&nbs= p;

--=

j h = woodyatt <jhw@apple.com>



<= /span>

 

------_=_NextPart_001_01CCF01E.FBDB007A-- From marka@isc.org Mon Feb 20 14:45:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6C821F85C5 for ; Mon, 20 Feb 2012 14:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-hKIryjE-I8 for ; Mon, 20 Feb 2012 14:45:43 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id BA23F21F85B7 for ; Mon, 20 Feb 2012 14:45:43 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id DF31C5F989F; Mon, 20 Feb 2012 22:45:29 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:f4e3:78f1:fc50:1cf2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E9363216C31; Mon, 20 Feb 2012 22:45:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7D3A61DA139E; Tue, 21 Feb 2012 09:45:21 +1100 (EST) To: Joel jaeggli From: Mark Andrews References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> <4F42C1E6.7010606@bogus.com> In-reply-to: Your message of "Mon, 20 Feb 2012 13:57:58 -0800." <4F42C1E6.7010606@bogus.com> Date: Tue, 21 Feb 2012 09:45:20 +1100 Message-Id: <20120220224521.7D3A61DA139E@drugs.dv.isc.org> Cc: Marc Lampo , v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:45:44 -0000 In message <4F42C1E6.7010606@bogus.com>, Joel jaeggli writes: > On 2/20/12 06:32 , Marc Lampo wrote: > > Hello, > > > > (sorry to be late with my comments, bit overloaded on my side) > > > > 6.1 Security Considerations - paragraph 2 (on DNSSEC) > > The text states : "there should not be any negative impact on DNSSEC" > > In my opinion, this is *wrong* : > > > > IMHO the following applies. > > if you have one zone yeah I agree. > > If you have two zones one with aaaa and one without (assuming this is > done with dns views style implementation) you can sign both and they'll > both be valid and complete from the vantage point of a client which > resolves one or the other of them but not both. It will still valid and complete even if you ask both servers. The answer just won't be deterministic. The important thing is that the DNSKEY RRset holds all the DNSKEY records in use. Note you can sign the zone with different DNSKEYs. > this is a traditional split horizon problem. it's just not inside/outside. > > joel -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rbonica@juniper.net Mon Feb 20 14:57:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044CB21F85FC for ; Mon, 20 Feb 2012 14:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AteiiHVbikTq for ; Mon, 20 Feb 2012 14:57:03 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id E70B821F85FB for ; Mon, 20 Feb 2012 14:57:02 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKT0LPu5rCXP50qJ3GspbyuWCpDhBY3X0X@postini.com; Mon, 20 Feb 2012 14:57:03 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 20 Feb 2012 14:55:37 -0800 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 20 Feb 2012 14:55:36 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 20 Feb 2012 17:55:36 -0500 From: Ronald Bonica To: "EXT - joelja@bogus.com" , Marc Lampo Date: Mon, 20 Feb 2012 17:55:28 -0500 Thread-Topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-Index: AczwGv1RylzOYikrSOiJPgXVBRSCpgAB5Bzw Message-ID: <13205C286662DE4387D9AF3AC30EF456D7671A227B@EMBX01-WF.jnpr.net> References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> <4F42C1E6.7010606@bogus.com> In-Reply-To: <4F42C1E6.7010606@bogus.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-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 22:57:04 -0000 Marc, Havard, Are you satisfied with the answers provided by Joel and Mark? Ron > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of EXT - joelja@bogus.com > Sent: Monday, February 20, 2012 4:58 PM > To: Marc Lampo > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Last Call: implications-08.txt> (Considerations for Transitioning Content to IPv6) > to Informational RFC >=20 > On 2/20/12 06:32 , Marc Lampo wrote: > > Hello, > > > > (sorry to be late with my comments, bit overloaded on my side) > > > > 6.1 Security Considerations - paragraph 2 (on DNSSEC) > > The text states : "there should not be any negative impact on DNSSEC" > > In my opinion, this is *wrong* : > > >=20 > IMHO the following applies. >=20 > if you have one zone yeah I agree. >=20 > If you have two zones one with aaaa and one without (assuming this is > done with dns views style implementation) you can sign both and they'll > both be valid and complete from the vantage point of a client which > resolves one or the other of them but not both. >=20 > this is a traditional split horizon problem. it's just not > inside/outside. >=20 > joel >=20 > > It is correct that, if an AAAA record exists (in a DNSSEC's zone), > > the appropriate RRSIG will be known to authoritative NS's. > > If, via white listing, the decision is taken not to present the AAAA > > record > > (and its signature), this seems OK. > > > > However : not returning an AAAA record seems identical to : there is > no > > AAAA record. > > And that - there is no AAAA record - yields to "Next Secure" changes > ! > > If no AAAA record exists, for a name, the corresponding NSEC (NSEC3) > > record > > should not hold a reference to AAAA. > > But if that AAAA record does exist, the authoritative NS will have > NSEC > > (NSEC3) > > data that shows so. > > > > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but due > to > > whitelisting > > will not be returned), cannot be proven by accompanying (and > required) > > NSEC (NSEC3) > > information. > > Hence : this draft will/might make DNSSEC validating name servers > fail. > > > > > > If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) in > > detail, > > please observe : > > 1) the caching name server (and "stub resolver") ask 2 queries > > (there is only one line, > > but it are two queries : one for "A", one for "AAAA") > > 2) if the caching name server (or stub resolver) performs DNSSEC > > validation, > > it will never accept a reply of "NODATA" to the query of AAAA > > (because the NSEC (NSEC3) information will not prove that > > non-existance) > > ((and the validating name server will repeat the query to all > > authoritative NS's, looking for a validatable answer)) > > > > (the final result, to the user might be that only the A record is > useable > > - mission accomplished ? > > But the side effect will be that validating caching name servers > will hit > > *all* authoritative servers for the domain, > > "in search of" a correctly validating answer.) > > > > So, while for the end-user, the result might be identical, > > one "security impact" of this approach is > > additional (useless) DNS traffic and > > additional load on authoritative NS's (that implement whitelisting) > > > > > > Kind regards, > > > > Marc Lampo > > Security Officer > > EURid > > > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: 01 February 2012 04:09 PM > > To: IETF-Announce > > Cc: v6ops@ietf.org > > Subject: [v6ops] Last Call: > > > > (Considerations for Transitioning Content to IPv6) to Informational > RFC > > > > > > The IESG has received a request from the IPv6 Operations WG (v6ops) > to > > consider the following document: > > - 'Considerations for Transitioning Content to IPv6' > > as an > > Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to > the > > ietf@ietf.org mailing lists by 2012-02-15. 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 describes considerations for the transition of end > user > > content on the Internet to IPv6. While this is tailored to > address > > end user content, which is typically web-based, many aspects of > this > > document may be more broadly applicable to the transition to IPv6 > of > > other applications and services. This document explores the > > challenges involved in the transition to IPv6, potential migration > > tactics, possible migration phases, and other considerations. The > > audience for this document is the Internet community generally, > > particularly IPv6 implementers. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > whitelisting-impl > > ications/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > whitelisting-impl > > ications/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jhw@apple.com Mon Feb 20 16:29:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4733A21E802E; Mon, 20 Feb 2012 16:29:47 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guBosixztZsV; Mon, 20 Feb 2012 16:29:46 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1813421E8016; Mon, 20 Feb 2012 16:29:46 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_joStrLDg7w+TI2x4CMgxtQ)" Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0LZP009JBW024DX1@mail-out.apple.com>; Mon, 20 Feb 2012 16:29:45 -0800 (PST) X-AuditID: 11807136-b7b1aae0000062d9-80-4f42e578d107 Received: from [17.153.48.205] (Unknown_Domain [17.153.48.205]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 37.A2.25305.975E24F4; Mon, 20 Feb 2012 16:29:45 -0800 (PST) From: james woodyatt In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C3040761AD@XMB-RCD-109.cisco.com> Date: Mon, 20 Feb 2012 16:29:44 -0800 Message-id: References: "29 Jan 2012 09:51:52 PST." <85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com> <201201301936.q0UJaEft000156@givry.fdupont.fr> <2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com> <4A687585-399D-4077-91AC-A1DC4F101E03@apple.com> <2D09D61DDFA73D4C884805CC7865E611025BFE@GAALPA1MSGUSR9N.ITServices.sbc.com> <30931DE1-9E57-4296-B0FE-FA98F840D78F@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3040761AD@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1257) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUiONPgrG7lUyd/g9VbBSwm/f3JaHHz6kUW i8nHfrNa3Pp1jc3i9LG9zA6sHi/75zB6TPm9kdVjyZKfTB5fLn9mC2CJ4rJJSc3JLEst0rdL 4Mo48n0Ja8ETvYofs+cwNTAu0ehi5OSQEDCRuH5sARuELSZx4d56IJuLQ0hgKpNE85l5LCAJ YQFrib3tj1hBbF4BQ4mZr9rBbGaBBImPl96D1bAJqEh8u3yXCcTmFPCVmL+9FyzOIqAqMe/B L2aQocwCPYwS/QdmQw2ykXgw6SQTxLZDzBLX+6cxgiREBPQkHu98wApxkqzE7YP7mSYw8s1C snwWkuUQtrbEsoWvmSFsA4mnna9YMcX1Jd68m8O0gJFtFaNgUWpOYqWhqV5iQUFOql5yfu4m RlBwNxSa7WDc8VfuEKMAB6MSD29iuZO/EGtiWXFl7iFGCQ5mJRHesqVAId6UxMqq1KL8+KLS nNTiQ4zSHCxK4ry8hkApgfTEktTs1NSC1CKYLBMHp1QDY8edm++Pt1lPyU/6zbdk8YxJhddm lO5bpH27uDJLxu/n4g05qzjZ2q5lqfo/YZknlBV+tX7R9MAbc1ew/zmnu29J6w9Th/+ySwR1 3df2S8y+eF9HkKVWpubf6tsKzfzid+aLmJ3bFGiuLlDwim/nh4K+/cJLCgJObVKysOhYs2dC 23GtTRqT9iuxFGckGmoxFxUnAgDNzuKtagIAAA== Cc: IPv6 Operations , PCP , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 00:29:47 -0000 --Boundary_(ID_joStrLDg7w+TI2x4CMgxtQ) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable On Feb 20, 2012, at 14:28 , Hemant Singh (shemant) wrote: > =20 > Sorry for the delay. Along the lines of what Barbara already said, I = would like to add that major host OS=92s such as Microsoft Windows nor = MAC OS (?) support a PCP client yet? At least till a few months back - = vendors can keep me honest. If a host does not support a PCP client, = what host will issue PCP requests to a PCP server in the IPv6 CPE = router? Thus it makes sense to let the homenet WG deal with the PCP = server req on the CPE router LAN and we ship rfc6204bis with the PCP = client req that Alain Durand agreed with for DS-Lite use. Thanks to = Dave Thaler who helped prepare text for the specific PCP client req in = the CPE. In other words, you're telling me there's no point in implementing a PCP = client for IPv6 simple security in a host operating system, because none = of the IPv6 Ready CE routers will have PCP servers. Good to know. -- james woodyatt member of technical staff, core os networking --Boundary_(ID_joStrLDg7w+TI2x4CMgxtQ) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable
On Feb 20, 2012, at 14:28 , Hemant Singh = (shemant) wrote:
Sorry = for the delay.   Along the lines of what Barbara already said, = I would like to add that major host OS=92s  such as Microsoft = Windows nor MAC OS (?) support a PCP client yet?  At least till a = few months back -  vendors can keep me honest.   If a = host does not support a PCP client, what host will issue PCP requests to = a PCP server in the IPv6 CPE router?   Thus it makes sense to = let the homenet WG deal with the PCP server req on the CPE router LAN = and we ship rfc6204bis with the PCP client req that Alain Durand agreed = with for DS-Lite use.  Thanks to Dave Thaler who helped prepare = text for the specific PCP client req in the = CPE.

In other = words, you're telling me there's no point in implementing a PCP client = for IPv6 simple security in a host operating system, because none of the = IPv6 Ready CE routers will have PCP servers.  Good to = know.


--
james woodyatt <jhw@apple.com>
member of technical staff, core os = networking



= --Boundary_(ID_joStrLDg7w+TI2x4CMgxtQ)-- From mawatari@jpix.ad.jp Mon Feb 20 18:55:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A5821F856F for ; Mon, 20 Feb 2012 18:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.01 X-Spam-Level: * X-Spam-Status: No, score=1.01 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWqbiP-pzmN2 for ; Mon, 20 Feb 2012 18:55:27 -0800 (PST) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3621421F856D for ; Mon, 20 Feb 2012 18:55:26 -0800 (PST) Received: from [10.10.31.235] (eth3-1-bb-fw-34.jpix.ad.jp [210.171.226.102]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 9556FFC021 for ; Tue, 21 Feb 2012 11:55:25 +0900 (JST) Date: Tue, 21 Feb 2012 11:55:27 +0900 From: MAWATARI Masataka To: v6ops@ietf.org In-Reply-To: <4F42ADCC.9070806@bogus.com> References: <1808340F7EC362469DDFFB112B37E2FCC67E419632@SRVHKE02.rdm.cz> <4F42ADCC.9070806@bogus.com> Message-Id: <20120221115526.0320.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.03 [ja] Subject: Re: [v6ops] new draft: draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 02:55:33 -0000 Dear all, I wrote my thoughts. Basically, there are different requirement and applicable situation between 4rd and MAP and 464XLAT. 4rd and MAP are stateless solutions due to sharing expanded address space spliting. These can solve requirements from ISPs that have much global IPv4 address pool. 464XLAT is stateful solution due to dynamic sharing by session time spliting. This can solve requirements from mobile careers that will enlarge the number of end-users or ISPs that do not have much global IPv4 address pool. For example, it may be difficult for advancing countries to enough deploy IPv4/IPv6 dual stack network, I think. Incidentally, such ISPs I heard from at least in Japan is thinking they would not like to operate IPv4/IPv6 coexistence techniques on each their backbone network and would like to operate IPv6-only access network. I would like to support them. As all really know, 464XLAT remove 4rd and MAP, and vice versa, I also really think. What I really want to realize is faster deploying IPv6 network and IPv6 service on the internet. Kind Regards, Masataka MAWATARI * On Mon, 20 Feb 2012 12:32:12 -0800 * Joel jaeggli wrote: > On 2/20/12 04:07 , Vizdal Ale? wrote: > > +1 > > > > I fully agree with Victor's words as this draft is providing a real solution > > to THE IPv4 exhaustion problem. I do support it and would like to see this > > work continued. > > I would probably construe that more narrowly... > > The draft provides a solution to an aspect of a providers ipv4 > exhaustion problem. It appears on the face of it to provide effective > cover for the deployment of ipv6 only networks which have limited pools > of available ipv4 addresses. > > > Cheers, > > Ales > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Victor > >> Kuarsingh > >> Sent: Friday, February 17, 2012 1:31 AM > >> To: fred@cisco.com; v6ops@ietf.org > >> Cc: draft-ietf-v6ops-464xlat@tools.ietf.org > >> Subject: Re: [v6ops] new draft: draft-ietf-v6ops-464xlat > >> > >> Fred, > >> > >> This work in my mind represents important work that should continue. > >> Putting a mobile operator hat on, it provides the last bit of functionally > >> to make IPv6 with NAT64 a real and workable option for Wireless > >> deployments based on known behaviours in commercially available product > >> (I.e. Infrequent, but need for IPv4 connections). > >> > >> Given the content in the draft and testing/results provided thus far, it > >> appears to be a viable option with a number of benefits (especially in the > >> mobile space related to PCC complacence). > >> > >> I would support this work in whichever forum (group) it should exist. > >> > >> Regards, > >> > >> Victor K > >> > >> > >> > >> On 12-02-15 9:55 AM, "fred@cisco.com" wrote: > >> > >>> > >>> A new draft has been posted, at > >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat. Please take a look > >>> at it and comment. > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From satoru.matsushima@gmail.com Mon Feb 20 19:05:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA46721E8035 for ; Mon, 20 Feb 2012 19:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c56IyftlpnMw for ; Mon, 20 Feb 2012 19:05:38 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD0421E802F for ; Mon, 20 Feb 2012 19:05:38 -0800 (PST) Received: by dakl33 with SMTP id l33so6662483dak.31 for ; Mon, 20 Feb 2012 19:05:37 -0800 (PST) Received-SPF: pass (google.com: domain of satoru.matsushima@gmail.com designates 10.68.211.195 as permitted sender) client-ip=10.68.211.195; Authentication-Results: mr.google.com; spf=pass (google.com: domain of satoru.matsushima@gmail.com designates 10.68.211.195 as permitted sender) smtp.mail=satoru.matsushima@gmail.com; dkim=pass header.i=satoru.matsushima@gmail.com Received: from mr.google.com ([10.68.211.195]) by 10.68.211.195 with SMTP id ne3mr61988343pbc.147.1329793537953 (num_hops = 1); Mon, 20 Feb 2012 19:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=gSk2Dw1Q3klM/8OqsM8Ou5U0+Twx8xRWYsK25Lr5LnM=; b=unMixnplLnOCfmzwMOz/dlzpzG/YJFbTDpQz4S1mTvu7phJ+mzTUuk+ap0Jl/5pmys cXqSyRiVG5khkTMu8fb3sWzt/+cATh6FpdU+/MSQ4BGuPMJ6eVIH2hq+XB3/4RjO8m4x oIypIWTEipScUO8pyg+9ZGDSXd9TdwJfskVKU= Received: by 10.68.211.195 with SMTP id ne3mr51557380pbc.147.1329793537920; Mon, 20 Feb 2012 19:05:37 -0800 (PST) Received: from [10.201.80.50] ([202.45.12.141]) by mx.google.com with ESMTPS id 3sm14785418pbx.66.2012.02.20.19.05.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Feb 2012 19:05:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Satoru Matsushima In-Reply-To: <4F42AE5F.702@gmail.com> Date: Tue, 21 Feb 2012 12:05:31 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <81FFB44C-81F7-4C02-996A-80ABDCB1B402@gmail.com> References: <4F41255B.3020103@bogus.com> <4F414C28.8040606@gmail.com> <4F42AE5F.702@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1257) Cc: Russell Housley , v6ops WG Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 03:05:38 -0000 On 2012/02/21, at 5:34, Brian E Carpenter wrote: > On 2012-02-20 20:11, Satoru Matsushima wrote: > ... >> I can see a strong statement that double protocol translation is an = architecture which is not recommended by the IETF. >> (http://tools.ietf.org/html/draft-ietf-behave-v4v6-bih-09) >>=20 >> I'd like to hear from chairs that does v6ops consent to be opposed to = that statement. >=20 > Well, that's for the WG as a whole to say, not the chairs. >=20 It can be done by wg last call that is a chair's role. > I hate translation, and I've hated it since RFC 1671. Therefore, > I hate double translation more. However, we are going to get > double translation anyway - via CPE NAT and CGN, or via 464XLAT. > It is a consequence of running out of IPv4 before the universal > deployment of IPv6. >=20 > I don't see one being more evil than the other, so it makes sense > to document the mechanisms. >=20 > Brian The mechanisms are well known already, I'm interested in that the = document elaborate how the past IETF(IESG) statement doesn't make sense = which statement should be disappeared consequently. cheers, --satoru= From cb.list6@gmail.com Mon Feb 20 20:47:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3200D21E8034 for ; Mon, 20 Feb 2012 20:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdL+FtrlOM7X for ; Mon, 20 Feb 2012 20:47:24 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E72421E802F for ; Mon, 20 Feb 2012 20:47:24 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so7241479pbc.31 for ; Mon, 20 Feb 2012 20:47:24 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.236.167 as permitted sender) client-ip=10.68.236.167; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.236.167 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.236.167]) by 10.68.236.167 with SMTP id uv7mr25306393pbc.113.1329799644349 (num_hops = 1); Mon, 20 Feb 2012 20:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VqsC3OpotHvBPypWAeS9eV2Mudjuz+oqNHcwxyT8b48=; b=VnrTa51/E7ApoMTnuknu1aLCJ1T8xFcJHJuSlcDh2Psoy3TXydZkcLGoDj27HOQOgR 2hVd0aVeAPMLyAv3tfn9poaADN8uC/nAfSgx8eE/kWlWxqzbEqxVYF+KsJHIoJpZYAeK bMZ7/Tj+UHy367xMsavwOkhpnb2KbUvLD8rBo= MIME-Version: 1.0 Received: by 10.68.236.167 with SMTP id uv7mr21111107pbc.113.1329799644305; Mon, 20 Feb 2012 20:47:24 -0800 (PST) Received: by 10.142.99.12 with HTTP; Mon, 20 Feb 2012 20:47:24 -0800 (PST) In-Reply-To: <81FFB44C-81F7-4C02-996A-80ABDCB1B402@gmail.com> References: <4F41255B.3020103@bogus.com> <4F414C28.8040606@gmail.com> <4F42AE5F.702@gmail.com> <81FFB44C-81F7-4C02-996A-80ABDCB1B402@gmail.com> Date: Mon, 20 Feb 2012 20:47:24 -0800 Message-ID: From: Cameron Byrne To: Satoru Matsushima Content-Type: multipart/alternative; boundary=047d7b33cc026bd89904b9721bf0 Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 04:47:25 -0000 --047d7b33cc026bd89904b9721bf0 Content-Type: text/plain; charset=ISO-8859-1 On Feb 20, 2012 7:05 PM, "Satoru Matsushima" wrote: > > On 2012/02/21, at 5:34, Brian E Carpenter wrote: > > > On 2012-02-20 20:11, Satoru Matsushima wrote: > > ... > >> I can see a strong statement that double protocol translation is an architecture which is not recommended by the IETF. > >> (http://tools.ietf.org/html/draft-ietf-behave-v4v6-bih-09) > >> > >> I'd like to hear from chairs that does v6ops consent to be opposed to that statement. > > > > Well, that's for the WG as a whole to say, not the chairs. > > > > It can be done by wg last call that is a chair's role. > > > > I hate translation, and I've hated it since RFC 1671. Therefore, > > I hate double translation more. However, we are going to get > > double translation anyway - via CPE NAT and CGN, or via 464XLAT. > > It is a consequence of running out of IPv4 before the universal > > deployment of IPv6. > > > > I don't see one being more evil than the other, so it makes sense > > to document the mechanisms. > > > > Brian > > The mechanisms are well known already, I'm interested in that the document elaborate how the past IETF(IESG) statement doesn't make sense which statement should be disappeared consequently. > That decision might be best fit for draft-weil http://tools.ietf.org/html/draft-weil-shared-transition-space-request-15 That draft is nat444 space allocation, does not require any ipv6 strategy, and it is in last call. In the IESG notes I read, double translation was not the core issue the IESG was concerned with. MAP-T also fits the double/triple translation profile. 1. 464XLAT is not the first nor the last to use double translation. That said, double translation is only a corner case in 464XLAT when DNS64 is used. See section 7.3 of 464XLAT draft for traffic treatment scenarios. 2. 464XLAT explicitly evolves to remove double and single translation where possible, more v6 capable software and content as time goes on. 3. 464XLAT enables IPv6-only deployment in cases that would otherwise be NAT444, including squat space usage. 4. On my network, after World IPv6 Launch, over 50% of the traffic delivered to the average user on a mobile will be IPv6 end-to-end, if the subscriber is IPv6 enabled. They cannot be IPv6 enabled until 464XLAT is implemented (see motivations for draft-464XLAT on reasons why dual-stack and tunnels do not work for my scenarios) CB --047d7b33cc026bd89904b9721bf0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 20, 2012 7:05 PM, "Satoru Matsushima" <satoru.matsushima@gmail.co= m> wrote:
>
> On 2012/02/21, at 5:34, Brian E Carpenter wrote:
>
> > On 2012-02-20 20:11, Satoru Matsushima wrote:
> > ...
> >> I can see a strong statement that double protocol translation= is an architecture which is not recommended by the IETF.
> >> (http://tools.ietf.org/html/draft-ietf-behave-v4v= 6-bih-09)
> >>
> >> I'd like to hear from chairs that does v6ops consent to b= e opposed to that statement.
> >
> > Well, that's for the WG as a whole to say, not the chairs. > >
>
> It can be done by wg last call that is a chair's role.
>
>
> > I hate translation, and I've hated it since RFC 1671. Therefo= re,
> > I hate double translation more. However, we are going to get
> > double translation anyway - via CPE NAT and CGN, or via 464XLAT.<= br> > > It is a consequence of running out of IPv4 before the universal > > deployment of IPv6.
> >
> > I don't see one being more evil than the other, so it makes s= ense
> > to document the mechanisms.
> >
> > =A0 Brian
>
> The mechanisms are well known already, I'm interested in that the = document elaborate how the past IETF(IESG) statement doesn't make sense= which statement should be disappeared consequently.
>

That decision might be best fit for draft-weil

http://tools.ietf.org/html/draft-weil-shared= -transition-space-request-15

That draft is nat444 space allocation, does not require any ipv6 strateg= y, and it is in last call.=A0 In the IESG notes I read, double translation = was not the core issue the IESG was concerned with. MAP-T also fits the dou= ble/triple translation profile.

1.=A0 464XLAT is not the first nor the last to use double translation. = That said, double translation is only a corner case in 464XLAT when DNS64 i= s used.=A0 See section 7.3 of 464XLAT draft for traffic treatment scenarios= .

2.=A0 464XLAT explicitly evolves to remove double and single translation= where possible, more v6 capable software and content as time goes on.
<= /p>

3.=A0 464XLAT enables IPv6-only deployment in cases that would otherw= ise be NAT444, including squat space usage.=A0

4.=A0 On my network, after World IPv6 Launch, over 50% of the traffi= c delivered to the average user on a mobile will be IPv6 end-to-end, if the= subscriber is IPv6 enabled.=A0 They cannot be IPv6 enabled until 464XLAT i= s implemented (see motivations for draft-464XLAT on reasons why dual-stack = and tunnels do not work for my scenarios)=A0


CB

--047d7b33cc026bd89904b9721bf0-- From marc.lampo@eurid.eu Mon Feb 20 23:02:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5201F21E8046 for ; Mon, 20 Feb 2012 23:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gyj-sFmn9mkL for ; Mon, 20 Feb 2012 23:02:45 -0800 (PST) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1021E21E803F for ; Mon, 20 Feb 2012 23:02:43 -0800 (PST) X-ASG-Debug-ID: 1329807945-0369490e9a41a40001-b2NLKh Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id kOn54qpeq5TT52Tn; Tue, 21 Feb 2012 08:05:45 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 97828E408B; Tue, 21 Feb 2012 08:02:31 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Uy25HADZ0C9; Tue, 21 Feb 2012 08:02:31 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 84459E407C; Tue, 21 Feb 2012 08:02:31 +0100 (CET) From: "Marc Lampo" To: "'Ronald Bonica'" , References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> <4F42C1E6.7010606@bogus.com> <13205C286662DE4387D9AF3AC30EF456D7671A227B@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D7671A227B@EMBX01-WF.jnpr.net> Date: Tue, 21 Feb 2012 08:02:31 +0100 (CET) X-ASG-Orig-Subj: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Message-ID: <008301ccf066$c7b96c10$572c4430$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AczwGv1RylzOYikrSOiJPgXVBRSCpgAB5BzwABD1LWA= Content-Language: en-za X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1329807945 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 07:02:46 -0000 Hello, I had assumed : 1 zone file (and Mark Andrews correctly pointed at "views"). Would adding this piece of information, directly in the RFC, be useful to avoid confusion for future readers ? Thanks and kind regards, Marc Lampo -----Original Message----- From: Ronald Bonica [mailto:rbonica@juniper.net] Sent: 20 February 2012 11:55 PM To: EXT - joelja@bogus.com; Marc Lampo Cc: v6ops@ietf.org Subject: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Marc, Havard, Are you satisfied with the answers provided by Joel and Mark? Ron > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of EXT - joelja@bogus.com > Sent: Monday, February 20, 2012 4:58 PM > To: Marc Lampo > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Last Call: implications-08.txt> (Considerations for Transitioning Content to IPv6) > to Informational RFC > > On 2/20/12 06:32 , Marc Lampo wrote: > > Hello, > > > > (sorry to be late with my comments, bit overloaded on my side) > > > > 6.1 Security Considerations - paragraph 2 (on DNSSEC) > > The text states : "there should not be any negative impact on DNSSEC" > > In my opinion, this is *wrong* : > > > > IMHO the following applies. > > if you have one zone yeah I agree. > > If you have two zones one with aaaa and one without (assuming this is > done with dns views style implementation) you can sign both and they'll > both be valid and complete from the vantage point of a client which > resolves one or the other of them but not both. > > this is a traditional split horizon problem. it's just not > inside/outside. > > joel > > > It is correct that, if an AAAA record exists (in a DNSSEC's zone), > > the appropriate RRSIG will be known to authoritative NS's. > > If, via white listing, the decision is taken not to present the AAAA > > record > > (and its signature), this seems OK. > > > > However : not returning an AAAA record seems identical to : there is > no > > AAAA record. > > And that - there is no AAAA record - yields to "Next Secure" changes > ! > > If no AAAA record exists, for a name, the corresponding NSEC (NSEC3) > > record > > should not hold a reference to AAAA. > > But if that AAAA record does exist, the authoritative NS will have > NSEC > > (NSEC3) > > data that shows so. > > > > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but due > to > > whitelisting > > will not be returned), cannot be proven by accompanying (and > required) > > NSEC (NSEC3) > > information. > > Hence : this draft will/might make DNSSEC validating name servers > fail. > > > > > > If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) in > > detail, > > please observe : > > 1) the caching name server (and "stub resolver") ask 2 queries > > (there is only one line, > > but it are two queries : one for "A", one for "AAAA") > > 2) if the caching name server (or stub resolver) performs DNSSEC > > validation, > > it will never accept a reply of "NODATA" to the query of AAAA > > (because the NSEC (NSEC3) information will not prove that > > non-existance) > > ((and the validating name server will repeat the query to all > > authoritative NS's, looking for a validatable answer)) > > > > (the final result, to the user might be that only the A record is > useable > > - mission accomplished ? > > But the side effect will be that validating caching name servers > will hit > > *all* authoritative servers for the domain, > > "in search of" a correctly validating answer.) > > > > So, while for the end-user, the result might be identical, > > one "security impact" of this approach is > > additional (useless) DNS traffic and > > additional load on authoritative NS's (that implement whitelisting) > > > > > > Kind regards, > > > > Marc Lampo > > Security Officer > > EURid > > > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: 01 February 2012 04:09 PM > > To: IETF-Announce > > Cc: v6ops@ietf.org > > Subject: [v6ops] Last Call: > > > > (Considerations for Transitioning Content to IPv6) to Informational > RFC > > > > > > The IESG has received a request from the IPv6 Operations WG (v6ops) > to > > consider the following document: > > - 'Considerations for Transitioning Content to IPv6' > > as an > > Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to > the > > ietf@ietf.org mailing lists by 2012-02-15. 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 describes considerations for the transition of end > user > > content on the Internet to IPv6. While this is tailored to > address > > end user content, which is typically web-based, many aspects of > this > > document may be more broadly applicable to the transition to IPv6 > of > > other applications and services. This document explores the > > challenges involved in the transition to IPv6, potential migration > > tactics, possible migration phases, and other considerations. The > > audience for this document is the Internet community generally, > > particularly IPv6 implementers. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > whitelisting-impl > > ications/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > whitelisting-impl > > ications/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From satoru.matsushima@gmail.com Mon Feb 20 23:12:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4769721F8526 for ; Mon, 20 Feb 2012 23:12:37 -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, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M63fWf2M0ZU2 for ; Mon, 20 Feb 2012 23:12:36 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6820621F8523 for ; Mon, 20 Feb 2012 23:12:36 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so7365076pbc.31 for ; Mon, 20 Feb 2012 23:12:36 -0800 (PST) Received-SPF: pass (google.com: domain of satoru.matsushima@gmail.com designates 10.68.219.234 as permitted sender) client-ip=10.68.219.234; Authentication-Results: mr.google.com; spf=pass (google.com: domain of satoru.matsushima@gmail.com designates 10.68.219.234 as permitted sender) smtp.mail=satoru.matsushima@gmail.com; dkim=pass header.i=satoru.matsushima@gmail.com Received: from mr.google.com ([10.68.219.234]) by 10.68.219.234 with SMTP id pr10mr71805903pbc.11.1329808356192 (num_hops = 1); Mon, 20 Feb 2012 23:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=R8viBUF8bh1zMLXxse5/9O7F7ufZWtl3e1dyvD2XfsE=; b=tMzW2p9+aQ3zar0JDxOgjpNh4N4K2WdPA3FIi8+gzMq32AgzZKjPmk77rXdOhq/VGu yJlG673pCwslxFwWN3JxO/4dRBnovRPDxpa9d1u/cAcN1kkt/hml3dhEu9okqiOFemy9 o8w8vZNOb6HGAY6OdyQWe82o1ibm5kLl9Sz+A= Received: by 10.68.219.234 with SMTP id pr10mr59120918pbc.11.1329808356140; Mon, 20 Feb 2012 23:12:36 -0800 (PST) Received: from [10.201.80.50] ([202.45.12.141]) by mx.google.com with ESMTPS id u1sm15327120pbh.75.2012.02.20.23.12.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Feb 2012 23:12:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: Date: Tue, 21 Feb 2012 16:12:31 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <3D693F0C-0C63-4571-897F-6AF8DBD98F34@gmail.com> References: <4F41255B.3020103@bogus.com> <4F414C28.8040606@gmail.com> <4F42AE5F.702@gmail.com> <81FFB44C-81F7-4C02-996A-80ABDCB1B402@gmail.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1257) Cc: Russell Housley , v6ops WG Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 07:12:37 -0000 First, I'd like to see that the authors request wg last call. On 2012/02/21, at 13:47, Cameron Byrne wrote: > [--snip--] > > > > The mechanisms are well known already, I'm interested in that the = document elaborate how the past IETF(IESG) statement doesn't make sense = which statement should be disappeared consequently. > > >=20 > That decision might be best fit for draft-weil=20 >=20 > = http://tools.ietf.org/html/draft-weil-shared-transition-space-request-15 >=20 > That draft is nat444 space allocation, does not require any ipv6 = strategy, and it is in last call. In the IESG notes I read, double = translation was not the core issue the IESG was concerned with. MAP-T = also fits the double/triple translation profile. I won't argue that which statement is best fit to which document. > 1. 464XLAT is not the first nor the last to use double translation. = That said, double translation is only a corner case in 464XLAT when = DNS64 is used. See section 7.3 of 464XLAT draft for traffic treatment = scenarios. One clarification. Is it true that double translation is a corner case = in 464XLAT _when DNS64 is used_? > 2. 464XLAT explicitly evolves to remove double and single translation = where possible, more v6 capable software and content as time goes on. BIH and MAT-T are same on that aspect. >=20 > 3. 464XLAT enables IPv6-only deployment in cases that would otherwise = be NAT444, including squat space usage. =20 > 4. On my network, after World IPv6 Launch, over 50% of the traffic = delivered to the average user on a mobile will be IPv6 end-to-end, if = the subscriber is IPv6 enabled. They cannot be IPv6 enabled until = 464XLAT is implemented (see motivations for draft-464XLAT on reasons why = dual-stack and tunnels do not work for my scenarios)=20 >=20 >=20 Great. Good lack to see that at June 6. cheers, --satoru From satoru.matsushima@gmail.com Mon Feb 20 23:42:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A9321E8036 for ; Mon, 20 Feb 2012 23:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WZxOQqWr2WU for ; Mon, 20 Feb 2012 23:42:41 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 86FBE21F85C9 for ; Mon, 20 Feb 2012 23:42:41 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so7392866pbc.31 for ; Mon, 20 Feb 2012 23:42:41 -0800 (PST) Received-SPF: pass (google.com: domain of satoru.matsushima@gmail.com designates 10.68.217.170 as permitted sender) client-ip=10.68.217.170; Authentication-Results: mr.google.com; spf=pass (google.com: domain of satoru.matsushima@gmail.com designates 10.68.217.170 as permitted sender) smtp.mail=satoru.matsushima@gmail.com; dkim=pass header.i=satoru.matsushima@gmail.com Received: from mr.google.com ([10.68.217.170]) by 10.68.217.170 with SMTP id oz10mr23472785pbc.121.1329810161413 (num_hops = 1); Mon, 20 Feb 2012 23:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=KnJ1Kxi31pi5o4cjHyH1F7WyjH/oWzaIVamKI7LAEw8=; b=wDmkBmxx/XtroB4EZdXjxT7WpAaNNWwXZvbA4Jqgx0ufl6bG+XprQB9QnW5U8vOCjI KDIhehspOVa48eZZQCpdEOj8wwnpGDXpOWCPvha4L1DzwStSOLOkJmm17NumTeMEGS7W E4zbqVb7czlqYVb70c9P+jj5puJAbrvrO/zdc= Received: by 10.68.217.170 with SMTP id oz10mr19502248pbc.121.1329810161381; Mon, 20 Feb 2012 23:42:41 -0800 (PST) Received: from [10.201.80.50] ([202.45.12.141]) by mx.google.com with ESMTPS id y3sm15387679pbr.46.2012.02.20.23.42.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Feb 2012 23:42:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Satoru Matsushima In-Reply-To: <3D693F0C-0C63-4571-897F-6AF8DBD98F34@gmail.com> Date: Tue, 21 Feb 2012 16:42:36 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4A0ACBB6-4598-43FE-9003-CD45AB6C18B7@gmail.com> References: <4F41255B.3020103@bogus.com> <4F414C28.8040606@gmail.com> <4F42AE5F.702@gmail.com> <81FFB44C-81F7-4C02-996A-80ABDCB1B402@gmail.com> <3D693F0C-0C63-4571-897F-6AF8DBD98F34@gmail.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1257) Cc: Russell Housley , v6ops WG Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 07:42:42 -0000 On 2012/02/21, at 16:12, Satoru Matsushima wrote: >> 1. 464XLAT is not the first nor the last to use double translation. = That said, double translation is only a corner case in 464XLAT when = DNS64 is used. See section 7.3 of 464XLAT draft for traffic treatment = scenarios. >=20 > One clarification. Is it true that double translation is a corner case = in 464XLAT _when DNS64 is used_? Now I got what you mean 'a corner case'. Thanks. --satoru= From lorenzo@google.com Mon Feb 20 23:54:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F228921F85ED for ; Mon, 20 Feb 2012 23:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zerWPblRPSys for ; Mon, 20 Feb 2012 23:54:53 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC17E21F85EA for ; Mon, 20 Feb 2012 23:54:52 -0800 (PST) Received: by obbwd15 with SMTP id wd15so9441180obb.31 for ; Mon, 20 Feb 2012 23:54:52 -0800 (PST) Received-SPF: pass (google.com: domain of lorenzo@google.com designates 10.182.86.201 as permitted sender) client-ip=10.182.86.201; Authentication-Results: mr.google.com; spf=pass (google.com: domain of lorenzo@google.com designates 10.182.86.201 as permitted sender) smtp.mail=lorenzo@google.com; dkim=pass header.i=lorenzo@google.com Received: from mr.google.com ([10.182.86.201]) by 10.182.86.201 with SMTP id r9mr11546674obz.8.1329810892384 (num_hops = 1); Mon, 20 Feb 2012 23:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=pl2aBo8/+kOfCbr1UrJnhJkPjNYk+qxWEsGdRGaKS/A=; b=b9EgbeeL/V05TyjsN5rgUavwOb8rCBYmQjt5NfYILukPcdJvt+D0seOoeRTm3NAqpb fyzI2u7cY8K2Aml23M91sXjZjDucuaSyJooNRHA1mrB7cmuM/RH9eO75VLX1/Gh1a3xK rxbaDu75Br86zS9NpWLfopIxMxEejtQ/cw9I4= Received: by 10.182.86.201 with SMTP id r9mr9847667obz.8.1329810892319; Mon, 20 Feb 2012 23:54:52 -0800 (PST) Received: by 10.182.86.201 with SMTP id r9mr9847659obz.8.1329810892215; Mon, 20 Feb 2012 23:54:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.5.67 with HTTP; Mon, 20 Feb 2012 23:54:32 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Tue, 21 Feb 2012 16:54:32 +0900 Message-ID: To: "Livingood, Jason" Content-Type: multipart/alternative; boundary=f46d0445183bd954b704b974b9de X-System-Of-Record: true X-Gm-Message-State: ALoCoQmZwUrlMv13eoCUJxJj4ZYJp0uyObnP6An8avHsds4cnL3sNLGLiy0cVYvKpwhCLlZvOAGYihPlQZAMQ+kEEHbd135lzZFin+0CbvcuHYW5/BBUAXjy/LASFnkiMuBQzczUs+mc Cc: v6ops v6ops WG , IETF Discussion Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 07:54:54 -0000 --f46d0445183bd954b704b974b9de Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 16, 2012 at 00:52, Livingood, Jason < Jason_Livingood@cable.comcast.com> wrote: > To be more specific, at least section 5.5 ("it is unclear > how implementers will judge when the network conditions will have > changed sufficiently to justify turning off DNS Resolver Whitelisting > and/or what the process and timing will be for discontinuing this > practice") is now incorrect. It *is* clear, and it's what those > implementers are doing as part of World IPv6 Launch. > > Does that make more sense? > > > As the author, if it helps I plan to make the following change to > Section 5.5 following the conclusion of IETF Last Call. I ran this by a few > folks already and it seems broadly acceptable (have not heard from Lorenzo > yet though). > > Jason > > *CURRENT 5.5: * > 5.5. Turning Off DNS Resolver Whitelisting > > Domains that choose to implement DNS Resolver Whitelisting generally > consider it to be a temporary measure. It is unclear how implementers will > judge when the network conditions will have changed sufficiently to justify > turning off DNS Resolver Whitelisting and/or what the process and timing > will be for discontinuing this practice, though the extent of IPv6 > deployment to end users in networks, the state of IPv6-related impairment, > and the maturity of IPv6 operations are all clearly factors. However, > implementers may wish to take into consideration that, as a practical > matter, it will be impossible to get to a point where there are no longer > any IPv6-related impairments; some reasonably small number of hosts will > inevitably be left behind as end users elect not to upgrade them or as some > hosts are incapable of being upgraded. > *PROPOSED 5.5 (NEW TEXT IN ALL CAPS):* > 5.5. Turning Off DNS Resolver Whitelisting > > Domains that choose to implement DNS Resolver Whitelisting generally > consider it to be a temporary measure. It is unclear how implementers will > judge when the network conditions will have changed sufficiently to justify > turning off DNS Resolver Whitelisting and/or what the process and timing > will be for discontinuing this practice, though the extent of IPv6 > deployment to end users in networks, the state of IPv6-related impairment, > and the maturity of IPv6 operations are all clearly factors. However, *SOME > IMPLEMENTERS HAVE ANNOUNCED THAT THEY PLAN TO PERMANENTLY TURN OFF > WHITELISTING BEGINNING ON WORLD IPV6 DAY IN JUNE 2012 [REFERENCE]. IN ANY > CASE*, implementers may wish to take into consideration that, as a > practical matter, it will be impossible to get to a point where there are > no longer any IPv6-related impairments; some reasonably small number of > hosts will inevitably be left behind as end users elect not to upgrade them > or as some hosts are incapable of being upgraded. > > I think the suggested change does not go far enough. The "high-service-level domains" that prompted this draft to be written, and all the implementers I'm currently aware of, are decommissioning the practice. So the paragraph that states, "It is unclear how implementers will judge when the network conditions will have changed sufficiently to justify turning off DNS Resolver Whitelisting and/or what the process and timing will be for discontinuing this practice" is still incorrect. Can you just remove the paragraph and start the section with "Many implementers have announced that they plan to permanently turn off whitelisting beginning on..." ? --f46d0445183bd954b704b974b9de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 16, 2012 at 00:52, Livingood= , Jason <Jason_Livingood@cable.comcast.com> wrote:
To be more specific, at least section 5.5 ("it is unclear how=A0i= mplementers will judge when the network conditions will have changed=A0suff= iciently to justify turning off DNS Resolver Whitelisting and/or=A0what the= process and timing will be for discontinuing this practice") is now incorrect. It *is* clear, and it's what th= ose implementers are doing as part of World IPv6 Launch.

Does that make more sense?

As the author, if it helps I plan to make the following change to Sect= ion 5.5 following the conclusion of IETF Last Call. I ran this by a few fol= ks already and it seems broadly acceptable (have not heard from Lorenzo yet= though).=A0

Jason

CURRENT 5.5:=A0

5.5.=A0 Turning Off DNS Resolver Whitelisting

Domains that choose to implement DNS Resolver Whitelisting generally consid= er it to be a temporary measure. It is unclear how implementers will judge = when the network conditions will have changed sufficiently to justify turni= ng off DNS Resolver Whitelisting and/or what the process and timing will be for discontinuing this practice= , though the extent of IPv6 deployment to end users in networks, the state = of IPv6-related impairment, and the maturity of IPv6 operations are all cle= arly factors. However, implementers may wish to take into consideration that, as a practical matter, it will b= e impossible to get to a point where there are no longer any IPv6-related i= mpairments; some reasonably small number of hosts will inevitably be left b= ehind as end users elect not to upgrade them or as some hosts are incapable of being upgraded.

PROPOSED 5.5 (NEW TEXT IN ALL CAPS):

5.5.=A0 Turning Off DNS Resolver Whitelisting

Domains that choose to implement DNS Resolver Whitelisting generally consid= er it to be a temporary measure. It is unclear how implementers will judge = when the network conditions will have changed sufficiently to justify turni= ng off DNS Resolver Whitelisting and/or what the process and timing will be for discontinuing this practice= , though the extent of IPv6 deployment to end users in networks, the state = of IPv6-related impairment, and the maturity of IPv6 operations are all cle= arly factors. However,=A0SOME IMPLEMENTERS HAVE ANNOUNCED THAT THEY PLAN TO PERMANENTLY TURN OFF WHITELISTING BEGINNI= NG ON WORLD IPV6 DAY IN JUNE 2012 [REFERENCE]. IN ANY CASE, implementer= s may wish to take into consideration that, as a practical matter, it will = be impossible to get to a point where there are no longer any IPv6-related impairments; some reasonably sm= all number of hosts will inevitably be left behind as end users elect not t= o upgrade them or as some hosts are incapable of being upgraded.

<eom>

I think the suggested change does not go far e= nough. The "high-service-level domains" that prompted this draft = to be written, and all the implementers I'm currently aware of, are dec= ommissioning the practice.

So the paragraph that states, "It is unclear how i= mplementers will judge when the network conditions will have changed suffic= iently to justify turning off DNS Resolver Whitelisting and/or what the pro= cess and timing will be for discontinuing this practice" is still inco= rrect. Can you just remove the paragraph and start the section with "M= any implementers have announced that they plan to permanently turn off whit= elisting beginning on..." ?
--f46d0445183bd954b704b974b9de-- From internet-drafts@ietf.org Tue Feb 21 01:14:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FDE21F8574; Tue, 21 Feb 2012 01:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-Mqx0nmYPtd; Tue, 21 Feb 2012 01:14:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BB721F8535; Tue, 21 Feb 2012 01:14:34 -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 X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120221091434.26717.92773.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 01:14:34 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 09:14:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : IPv6 Multihoming without Network Address Translation Author(s) : Ole Troan David Miles Satoru Matsushima Tadahisa Okimoto Dan Wing Filename : draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt Pages : 23 Date : 2012-02-21 Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of NPTv6. However, NAT should be avoided, if at all possible, to permit transparent end-to- end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria. We conclude that DHCPv6 based solutions are suitable to solve the multihoming issues, described in this document, while NPTv6 may be required as an intermediate solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-witho= ut-ipv6nat-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-withou= t-ipv6nat-04.txt From ichiroumakino@gmail.com Tue Feb 21 01:31:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEBB21F85DF for ; Tue, 21 Feb 2012 01:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.973 X-Spam-Level: X-Spam-Status: No, score=-2.973 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWOe8pFZrisL for ; Tue, 21 Feb 2012 01:31:46 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF0121F855B for ; Tue, 21 Feb 2012 01:31:46 -0800 (PST) Received: by werg1 with SMTP id g1so3631577wer.31 for ; Tue, 21 Feb 2012 01:31:45 -0800 (PST) Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.86.9 as permitted sender) client-ip=10.180.86.9; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.86.9 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com Received: from mr.google.com ([10.180.86.9]) by 10.180.86.9 with SMTP id l9mr24105542wiz.15.1329816705627 (num_hops = 1); Tue, 21 Feb 2012 01:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZPpvJFdhL554OZtPGMEuxj1wdExUyrJ5bx8w5hLu+R4=; b=MrFvquWDI58VVwsXjMbKbtmycyAB44RHHKMHPwyd0WVbdl6v6WVf6nIBP7KICXkZfi 613ZC5Pxn8aOTdKUoJOtPZiRcIN7qn1P9U2DqekP3T3CrVfHaQAOHrCmFwvgkz2m0Zcp GMENivvn3EuoLFjL8inX4xaCRADtun678pCio= Received: by 10.180.86.9 with SMTP id l9mr20099974wiz.15.1329816705584; Tue, 21 Feb 2012 01:31:45 -0800 (PST) Received: from [10.147.11.77] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id hb10sm52930433wib.10.2012.02.21.01.31.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 01:31:44 -0800 (PST) Sender: Ole Troan Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <20120221091434.26717.92773.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 10:31:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <33E92F0C-064A-423C-B6D2-621E2387499E@employees.org> References: <20120221091434.26717.92773.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1257) Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 09:31:50 -0000 this is an update in response to IESG comments. see diffs here: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ipv6-multihoming-wit= hout-ipv6nat-04.txt cheers, Ole On Feb 21, 2012, at 10:14 , internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Operations Working = Group of the IETF. >=20 > Title : IPv6 Multihoming without Network Address = Translation > Author(s) : Ole Troan > David Miles > Satoru Matsushima > Tadahisa Okimoto > Dan Wing > Filename : = draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt > Pages : 23 > Date : 2012-02-21 >=20 > Network Address and Port Translation (NAPT) works well for = conserving > global addresses and addressing multihoming requirements, because an > IPv4 NAPT router implements three functions: source address > selection, next-hop resolution and optionally DNS resolution. For > IPv6 hosts one approach could be the use of NPTv6. However, NAT > should be avoided, if at all possible, to permit transparent end-to- > end connectivity. In this document, we analyze the use cases of > multihoming. We also describe functional requirements and possible > solutions for multihoming without the use of NAT in IPv6 for hosts > and small IPv6 networks that would otherwise be unable to meet > minimum IPv6 allocation criteria. We conclude that DHCPv6 based > solutions are suitable to solve the multihoming issues, described in > this document, while NPTv6 may be required as an intermediate > solution. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-with= out-ipv6nat-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-witho= ut-ipv6nat-04.txt >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rbonica@juniper.net Tue Feb 21 05:46:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2702421F8733 for ; Tue, 21 Feb 2012 05:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.226 X-Spam-Level: X-Spam-Status: No, score=-106.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qwO3nNfVtyP for ; Tue, 21 Feb 2012 05:46:17 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id C993721F855B for ; Tue, 21 Feb 2012 05:46:16 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT0Of9pmGsRrzJ2+kxLcyPfER74usTjb9@postini.com; Tue, 21 Feb 2012 05:46:16 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Feb 2012 05:44:45 -0800 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Feb 2012 05:44:45 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 21 Feb 2012 08:44:45 -0500 From: Ronald Bonica To: Marc Lampo , "EXT - joelja@bogus.com" Date: Tue, 21 Feb 2012 08:44:11 -0500 Thread-Topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-Index: AczwGv1RylzOYikrSOiJPgXVBRSCpgAB5BzwABD1LWAADht0UA== Message-ID: <13205C286662DE4387D9AF3AC30EF456D7671A23BD@EMBX01-WF.jnpr.net> References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> <4F42C1E6.7010606@bogus.com> <13205C286662DE4387D9AF3AC30EF456D7671A227B@EMBX01-WF.jnpr.net> <008301ccf066$c7b96c10$572c4430$@lampo@eurid.eu> In-Reply-To: <008301ccf066$c7b96c10$572c4430$@lampo@eurid.eu> 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-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 13:46:21 -0000 Authors, What do you think? Ron > -----Original Message----- > From: Marc Lampo [mailto:marc.lampo@eurid.eu] > Sent: Tuesday, February 21, 2012 2:03 AM > To: Ronald Bonica; EXT - joelja@bogus.com > Cc: v6ops@ietf.org > Subject: RE: [v6ops] Last Call: implications-08.txt> (Considerations for Transitioning Content to IPv6) > to Informational RFC >=20 > Hello, >=20 > I had assumed : 1 zone file (and Mark Andrews correctly pointed at > "views"). >=20 > Would adding this piece of information, directly in the RFC, > be useful to avoid confusion for future readers ? >=20 > Thanks and kind regards, >=20 > Marc Lampo >=20 >=20 > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: 20 February 2012 11:55 PM > To: EXT - joelja@bogus.com; Marc Lampo > Cc: v6ops@ietf.org > Subject: RE: [v6ops] Last Call: > > (Considerations for Transitioning Content to IPv6) to Informational RFC >=20 > Marc, Havard, >=20 > Are you satisfied with the answers provided by Joel and Mark? >=20 > Ron >=20 >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf > > Of EXT - joelja@bogus.com > > Sent: Monday, February 20, 2012 4:58 PM > > To: Marc Lampo > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] Last Call: whitelisting- > > implications-08.txt> (Considerations for Transitioning Content to > IPv6) > > to Informational RFC > > > > On 2/20/12 06:32 , Marc Lampo wrote: > > > Hello, > > > > > > (sorry to be late with my comments, bit overloaded on my side) > > > > > > 6.1 Security Considerations - paragraph 2 (on DNSSEC) > > > The text states : "there should not be any negative impact on > DNSSEC" > > > In my opinion, this is *wrong* : > > > > > > > IMHO the following applies. > > > > if you have one zone yeah I agree. > > > > If you have two zones one with aaaa and one without (assuming this is > > done with dns views style implementation) you can sign both and > they'll > > both be valid and complete from the vantage point of a client which > > resolves one or the other of them but not both. > > > > this is a traditional split horizon problem. it's just not > > inside/outside. > > > > joel > > > > > It is correct that, if an AAAA record exists (in a DNSSEC's zone), > > > the appropriate RRSIG will be known to authoritative NS's. > > > If, via white listing, the decision is taken not to present the > AAAA > > > record > > > (and its signature), this seems OK. > > > > > > However : not returning an AAAA record seems identical to : there > is > > no > > > AAAA record. > > > And that - there is no AAAA record - yields to "Next Secure" > changes > > ! > > > If no AAAA record exists, for a name, the corresponding NSEC > (NSEC3) > > > record > > > should not hold a reference to AAAA. > > > But if that AAAA record does exist, the authoritative NS will have > > NSEC > > > (NSEC3) > > > data that shows so. > > > > > > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but > due > > to > > > whitelisting > > > will not be returned), cannot be proven by accompanying (and > > required) > > > NSEC (NSEC3) > > > information. > > > Hence : this draft will/might make DNSSEC validating name servers > > fail. > > > > > > > > > If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) > in > > > detail, > > > please observe : > > > 1) the caching name server (and "stub resolver") ask 2 queries > > > (there is only one line, > > > but it are two queries : one for "A", one for "AAAA") > > > 2) if the caching name server (or stub resolver) performs DNSSEC > > > validation, > > > it will never accept a reply of "NODATA" to the query of AAAA > > > (because the NSEC (NSEC3) information will not prove that > > > non-existance) > > > ((and the validating name server will repeat the query to all > > > authoritative NS's, looking for a validatable answer)) > > > > > > (the final result, to the user might be that only the A record is > > useable > > > - mission accomplished ? > > > But the side effect will be that validating caching name servers > > will hit > > > *all* authoritative servers for the domain, > > > "in search of" a correctly validating answer.) > > > > > > So, while for the end-user, the result might be identical, > > > one "security impact" of this approach is > > > additional (useless) DNS traffic and > > > additional load on authoritative NS's (that implement whitelisting) > > > > > > > > > Kind regards, > > > > > > Marc Lampo > > > Security Officer > > > EURid > > > > > > > > > -----Original Message----- > > > From: The IESG [mailto:iesg-secretary@ietf.org] > > > Sent: 01 February 2012 04:09 PM > > > To: IETF-Announce > > > Cc: v6ops@ietf.org > > > Subject: [v6ops] Last Call: > > > > > > (Considerations for Transitioning Content to IPv6) to Informational > > RFC > > > > > > > > > The IESG has received a request from the IPv6 Operations WG (v6ops) > > to > > > consider the following document: > > > - 'Considerations for Transitioning Content to IPv6' > > > as an > > > Informational RFC > > > > > > The IESG plans to make a decision in the next few weeks, and > solicits > > > final comments on this action. Please send substantive comments to > > the > > > ietf@ietf.org mailing lists by 2012-02-15. 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 describes considerations for the transition of end > > user > > > content on the Internet to IPv6. While this is tailored to > > address > > > end user content, which is typically web-based, many aspects of > > this > > > document may be more broadly applicable to the transition to > IPv6 > > of > > > other applications and services. This document explores the > > > challenges involved in the transition to IPv6, potential > migration > > > tactics, possible migration phases, and other considerations. > The > > > audience for this document is the Internet community generally, > > > particularly IPv6 implementers. > > > > > > > > > > > > > > > The file can be obtained via > > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > > whitelisting-impl > > > ications/ > > > > > > IESG discussion can be tracked via > > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > > whitelisting-impl > > > ications/ > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From simon.perreault@viagenie.ca Tue Feb 21 05:56:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E6B21F87F3 for ; Tue, 21 Feb 2012 05:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZOrNdJshjrC for ; Tue, 21 Feb 2012 05:56:41 -0800 (PST) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 84C6521F87D3 for ; Tue, 21 Feb 2012 05:56:41 -0800 (PST) Received: from eeepc.viagenie.ca (unknown [64.235.195.26]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4725A20D1E for ; Tue, 21 Feb 2012 08:56:40 -0500 (EST) Message-ID: <4F43A296.2070207@viagenie.ca> Date: Tue, 21 Feb 2012 08:56:38 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; OpenBSD i386; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: v6ops@ietf.org References: "29 Jan 2012 09:51:52 PST."<85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com><201201301936.q0UJaEft000156@givry.fdupont.fr><2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com><4A687585-399D-4077-91AC-A1DC4F101E03@apple.com><2D09D61DDFA73D4C884805CC7865E611025BFE@GAALPA1MSGUSR9N.ITServices.sbc.com> <30931DE1-9E57-4296-B0FE-FA98F840D78F@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3040761AD@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3040761AD@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 13:56:51 -0000 On 02/20/12 17:28, Hemant Singh (shemant) wrote: > Sorry for the delay. Along the lines of what Barbara already said, I > would like to add that major host OS’s such as Microsoft Windows nor MAC > OS (?) support a PCP client yet? At least till a few months back - > vendors can keep me honest. If a host does not support a PCP client, OS support is almost irrelevant. Applications today do UPnP and NAT-PMP without OS support. They just send the packets themselves, using UPnP/NAT-PMP in a third-party (often open source) library. I would expect the same for PCP. Applications evolve much faster than the IETF is accustomed to. You could wake up one day to one or two new open source PCP libraries, and then wake up the next with the major BitTorrent apps supporting PCP, and then everything else follows (games, etc.). Simon From despres.remi@laposte.net Tue Feb 21 07:21:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3DE21F880F for ; Tue, 21 Feb 2012 07:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlvB+t+a-V8X for ; Tue, 21 Feb 2012 07:21:20 -0800 (PST) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id F11F721F8806 for ; Tue, 21 Feb 2012 07:21:18 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id cfME1i00537Y3f403fMECg; Tue, 21 Feb 2012 16:21:16 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 21 Feb 2012 16:21:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 15:21:24 -0000 Cameron, Thanks for these answers, More questions and comments below. Le 2012-02-20 =E0 19:44, Cameron Byrne a =E9crit : ... >>> My trial required no change to the >>> IPv6-only DNS64/NAT64 network beta service that i have offered to by >>> customers for close to 2 years now. Adding 464XLAT was purely a CPE >>> function layered onto that existing network "as is". >>>=20 >>> 1. Yes, we use DNS64 >>=20 >> OK. >> Could you clarify then what justifies that "It does not require = DNS64". >>=20 >=20 > 464XLAT works fine without DNS64. Well, the discovery heuristic that you used implies DNS64 (ref. the = quote just below from draft-ietf-behave-nat64-discovery-heuristic). Without DNS64, some more assumptions seem to be needed for IPv4 hosts to = get A records, but I couldn't figure out which ones on my own.=20 "When sending AAAA query for the known name a host MUST set "Checking = Disabled (CD)" bit to zero, as otherwise the DNS64 will not perform IPv6 = address synthesis hence does not reveal the IPv6 prefix(es) used for = protocol translation." > Meaning, the CLAT may do stateless RFC 6145 NAT46 to the IPv6-only > access network destine for RFC 6146 NAT64 towards the Internet Aren't NAT64s always coupled with DNS64s, as seems to be implied by all = scenarios of RFC6144? =20 > This is a complete solution for any IPv4-only hosts behind the CLAT. >=20 > For me, DNS64 is advantageous to use for the following reasons in *my* = network >=20 > 1. DNS64 is already deployed in my network as part of the NAT64/DNS64 > service i offer today >=20 > 2. DNS64 allows for the discovery of the Pref64 using > draft-ietf-behave-nat64-discovery-heuristic >=20 > 3. DNS64 allows for single translation in cases where the host and > application are capable of doing IPv6 but the server does not have a > AAAA record. This is a very common case for my scenario. >=20 > Regarding discovery of the Pref64, the draft discusses that Pref64 may > be discovered through others means. DHCP options in the future, > manual configuration, proprietary methods ... are all possible in the > future... Today i have draft-ietf-behave-nat64-discovery-heuristic > working but i do not want to constrain implementations to just those > that use DNS64. >=20 >>> 2. A dedicated translation prefix was not used. Since my 3GPP = Release >>> 7 network does not support DHCP at all, the address is pushed to the >>> UE as part of PDP setup in the PCO IE. >>=20 >> Why, then, say "In the best case, the CLAT will have a dedicated /64" >>=20 >=20 > It just seems cleaner to me to have a dedicated /64 if it is > available. Operationally, aside from the NDP claiming the /96, there > is no difference to have dedicated or not dedicated. Understood, but: - Claiming a /96 on a link seems new to me (is there an existing = reference?) - Avoiding the need to do it is AFAIK an improvement, proposed in 4rd-U = thanks to the V-octet discriminator of 4rd addresses. - If DNS64s are parametrized to synthesize addresses that have the V = octet, finding IPv4 addresses in IPv6 addresses can become deterministic = instead of heuristic.=20 >>> This is how all IPv4 and IPv6 >>> addresses are assigned to UEs in my network. >>=20 >> Is this with a standard format (if yes, a reference would make it = clear). >>=20 >=20 > I was mistaken before, here is the reference for SLAAC being used for > address configurations. >=20 > http://tools.ietf.org/html/rfc6459#section-5.2 Thanks. >>> 3. The UE, which is also the CLAT, received a single /64 of IPv6 = from >>> the network >>=20 >> OK. >>=20 >>> and no IPv4. >>=20 >> (Already understood, otherwise nothing new would be needed) >>=20 >>=20 >>> This is the only address scheme that was >>> used or can be used in my network >>>=20 >>> 4. There was no change to the RFC 6146/6145 behavior, fragment >>> headers were included. >>=20 >> Then why to add a section which describes two variants. >> Besides, I didn't understand this sentence "In the 464XLAT = environment, the PLAT and CLAT SHOULD include an IPv6 Fragment Header, = *since IPv4 host does not set the DF bit*" (asterisks added). >=20 > I think it may be wise to remove that language. Let me check with my > co-authors. OK >=20 >>>=20 >>> 5. Pref64/n was discovered using = draft-ietf-behave-nat64-discovery-heuristic >>=20 >> OK. >>=20 >>=20 >>>> I just say that a real "trial deployment report" would be nice to = have, but of course no obligation. >>>>=20 >>>=20 >>> I am attempting to operate as transparently as possible. >>=20 >>> Please feel >>> free to query me further. >>=20 >> There is some of this of this above, thanks. >>=20 >> ... >>>> The draft does include SHOULDs and MAYs that belong to = standardization vocabulary, e.g.: >>>> "In cases where the access network does not allow for a dedicated = translation prefix, the CLAT SHOULD take ownership of the lowest /96 = from an attached interface's /64 to source and receive translation = traffic. Establishing ownership of the /96 requires that the CLAT SHOULD = perform NDP so that no other nodes on the /64 may use the lowest /96." >>>>=20 >>>=20 >>> Correct. The authors, including myself, are not as experience as = you, >>=20 >> I am not as much experienced in IETF procedures as you seem to = believe. >> Like yourself, I try to understand and apply BCPs. >>=20 >>> but i believe informational I-D may use this language. >>>=20 >>> Just looking, RFC6092 is informational and uses this language. >>=20 >> Personally, I find it confusing in RFC6092, but this is another = subject. >>=20 >>> Also, >>> we are open to changing the document type to BCP or Standard Track = if >>> that is a better fit. It has been recommended on list that this = draft >>> go standards track. So, i believe there is an open discussion here. >>> We can adjust as the WG sees fit. Right now, i feel most = comfortable >>> with informational. I don't think experimental is helpful to = network >>> operators that trying to solve a near term problem with "no new >>> technology". >>=20 >> My point is that it includes some behavior specification (464XLAT = compliance is more than just compliance with RFCs it refers to). >>=20 >> ... >>=20 >>>=20 >>>>> RFC6145 is not MAP or >>>>> 4RD. >>>>=20 >>>> Why you say this is unclear. AFAIK nobody ever suggested that. >>>>=20 >>>=20 >>> I keep getting the feeling like 464XLAT should be abandoned and the >>> use cases should be folded into MAP-T by the MAP-T author or 4RD-U >>> from the 4RD-U authors, both on and off list. >>=20 >> I don't know about off-list, but to say differently what think: >> - abandoning the new idea expressed in the 464XLAT would be a very = bad idea >> - OTOH, dealing with it in the context of 4rd-U seems to me a good = idea (unify stateless UE behaviors so that they can work consistently = both in networks using stateful NAT64s and those using using with = stateless ISP nodes) >> - working together for this to happen in Softwire would be welcome on = my side. >>=20 >> BTW, if you can take the time to read the 4rd-U draft, your questions = and comments will be most welcome. Renewed statement. >>> It seems the softwire >>> folks see 464XLAT as a competing technology. >>=20 >> I am an active Softwire guy, and don't see it that way. >>=20 >>> IMHO, MAP-T and 4RD-U do >>> not solve *my* problems. >>=20 >> 4rd-U isn't frozen yet. >> I see solving your problem as an objective. >>=20 >>> We took time to document how 464XLAT is >>> unique in the draft. >>>=20 >>> I have brought to softwires the concern that stateless core NAT64 is >>> not acceptable given the address efficiency issues (please don't = blast >>> me about how my issues are non-issues). >>=20 >> I never did, I hope, but I think I rather asked about real order of = magnitudes of your problem. >=20 > Publicly available information is that T-Mobile USA has 30+ Million > subscribers and about 100,000 IPv4 addresses, total. Not just for > subscribers, 100k IP addresses to run the whole business (data > centers, web sites, DNS servers, ...). >=20 > About 1/3 of those subscribers are actively attached to the data > network and consuming an IPv4 address, data network attachment is > growing >=20 > You can assume we are ~100% utilized on our IPv4 addresses, and that > nearly all subscribers reside behind existing 19 /25 public IPv4 > pools. I suppose that these 19 prefixes were derived by you from a smaller = number of shorter allocated prefixes, right? That is these shorter prefixes that are relevant. =20 > My own Android phone has ~20 active TCP sessions at steady-state (push > updates from email, twitter, facebook, ...). A key complementary information is the proportion of these that will = work in IPv6 where IPv6 is available. Any idea of this proportion? > When i do tethering, it > goes up substantially. BTW, did the trial include tethering? In the model, is tethering to be supported with a NAT44 in the UE?=20 If not, how? =20 >=20 > As you can see, things are pretty tight. Agreed, but not impossible, see near the end of this email. > They are going to get more tight. Not so sure as far as IPv4 is concerned: as IPv6 gets really deployed, = less and less sessions will consume IPv4 ports. > We chose stateful NAT64 as a path forward since it was a simple > feature add that leverages the existing NAT44 hardware and /25 ipv4 > NAT blocks. This means that deploying NAT64 required no new IPv4 > public addresses. =20 > Going to 4RD-U and MAP-T would require a > substantial re-work of the network to provide a suitable pool of IPv4 > addresses for the stateless translation. How substantial this rework is does depend on each operator's starting = point, but AFAIK it is quite feasible (see the example near the end of = this email) > We want 464XLAT since it enables us to make IPv6-only a feasible > service option to our subscribers in the near term, > the only missing > piece from generally available code (shipping products) is the CPE / > UE to do the CLAT functions of RFC6145 and Pref64 discovery. Right, there is _little_ to add to what exists, but still _something_. That much has to be rigorously specified (the Devil is in details). > The > functions have been submitted to the Android Open Source Project. Well done. > That said, please don't try to re-engineer this network scenario on > the list. I just try to understand what you mean, and which part has been = validated. I am also interested in simplifications that result from unifying good = designs. Suggesting I try to re-engineer is something that could have been = avoided (IMHO). > This is a real scenario, No doubt about this. > lets not make it a diversion. There is no intent to divert, only to work for progress. =20 > I tried to have this generic scenario discussion on softwires here > http://www.ietf.org/mail-archive/web/softwires/current/msg03402.html Indeed and you did receive several answers, including one from me = (http://www.ietf.org/mail-archive/web/softwires/current/msg03406.html). Note that this contradicts your previous assertion that there was no = discussion about 464XLAT in Softwire in the last 3 months (9 e-mails in = early February do contain "464XLAT") >=20 >> Didn't get it yet. >> Ideally that would include the number of simultaneous devices to be = supported, and the size of the IPv4 space available, with lengths of = IPv4 prefixes that compose it. >> In any case, your requirement is yours, and some other operators do = have different requirements = (tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-00.html)= . >> That's why some coordination makes sense. Your reasons are obviously legitimate in _your_ environment.=20 Yet, it is IMHO interesting to note that, with figures you gave above = (30+ million subscribers, 1/3 active, 100k IPv4 addresses), static = address sharing a la 4rd-U might realistically be introduced: - Move a fraction of the IPv4 addresses from dynamic to static sharing = say 32K addresses, i.e. 33%. (NAT 64 usage will naturally be reduced as = UEs start using their statically assigned shared addresses instead of = NAT64s). - Choose a sharing ratio of 512, in order to support 32K*5124=3D = 16,777,216 UEs (more than 1/3 * 30+ millions) - Thus, without losing the benefit of NAT64 for UEs that don't support = 4rd-U, each UE gets a shared public IPv4 address, with 120 reserved = ports for sessions that can't be IPv6. Please consider that there is no aggressiveness in pointing this out, = just the wish to see realities as they are. My wish is cooperation, not useless competition without understanding = valid points others have made. >>> On the softwire list, i >>> brought this up and was told a /14 of IPv4 was probably needed to = meet >>> a mid to large size wireless operator. What is important is the total size of the available IPv4 space, not the = length of the shortest prefix.=20 Regards, RD >>> Unfortunately, these address >>> are not available in APNIC today and will not be available in ARIN = or >>> RIPE in the very near future.... considering the timeline scope the >>> IETF operates at. That said, the stateless solutions have an = audience >>> with network operators that already have large allocations and wish = to >>> be more efficient. That's great, live and let live. >>>=20 >>> Also, the MAP family is quite complicated for me and lack of trial >>> deployment at scale is a concern since the IPv4 exhaustion issue is >>> pressing. >>=20 >> I share this view on current MAP documents. >>=20 >> OTOH, I do think that making UEs that would support a 4rd-U, = completed with permitted RFC1918 addresses in customer sites, would = largely increase their applicability with a limited enough added = complexity. >>=20 >>=20 >>> I hope you see that 464XLAT is an operational solution without any >>> novel technology. >>=20 >> In my understanding, 464XLAT does introduce a quite useful technology = that is almost completely based on existing pieces, like 6rd, but this = doesn't exclude these two from being NEW technologies. >>=20 >>=20 >> Regards, >> RD >>=20 >>=20 From despres.remi@laposte.net Tue Feb 21 08:06:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA38121F87FF for ; Tue, 21 Feb 2012 08:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axNSMsQzNilf for ; Tue, 21 Feb 2012 08:06:27 -0800 (PST) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id CC9AB21F8834 for ; Tue, 21 Feb 2012 08:06:26 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8507-out with ME id cg6N1i00N37Y3f403g6P3n; Tue, 21 Feb 2012 17:06:25 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120221115526.0320.8FE1F57E@jpix.ad.jp> Date: Tue, 21 Feb 2012 17:06:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1808340F7EC362469DDFFB112B37E2FCC67E419632@SRVHKE02.rdm.cz> <4F42ADCC.9070806@bogus.com> <20120221115526.0320.8FE1F57E@jpix.ad.jp> To: MAWATARI Masataka X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , v6ops WG Subject: Re: [v6ops] new draft: draft-ietf-v6ops-464xlat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 16:06:28 -0000 Masataka-san, Please see in line. Le 2012-02-21 =E0 03:55, MAWATARI Masataka a =E9crit : ... > As all really know, 464XLAT remove 4rd and MAP, and vice versa, I > also really think. I don't understand this sentence because what 464XLAT introduces is (in = 4rd/MAP) vocabulary, a variant of stateless CE (one that only works wit = stateful BRs whereas those of 4rd/MAP permit BRs to also be stateless).=20= Isn't it natural to quickly look whether IETF-specified stateless CEs = can work indifferently with stateful and stateless BRs?=20 AFAIK, there is little to add to 4rd-U so that its CEs can work = according to the generic 464XLAT scenario. - I plan to work on it in Softwire. - Would be available to share views on the proposed solution? > What I really want to realize is faster deploying IPv6 network and > IPv6 service on the internet. Same objective (that was that of 6rd, and is also that of 4rd) Kind regards, RD From cb.list6@gmail.com Tue Feb 21 09:21:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8A321F86DB for ; Tue, 21 Feb 2012 09:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgZfHTGKdLFU for ; Tue, 21 Feb 2012 09:21:31 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38B8C21F85F9 for ; Tue, 21 Feb 2012 09:21:31 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so7915015pbc.31 for ; Tue, 21 Feb 2012 09:21:31 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.213.232 as permitted sender) client-ip=10.68.213.232; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.213.232 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.213.232]) by 10.68.213.232 with SMTP id nv8mr69872436pbc.155.1329844891136 (num_hops = 1); Tue, 21 Feb 2012 09:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=smoHppT56JMQyr6K9KVN5BC9bWAMjTYNDzyqqrt0Eco=; b=hXTL5yAhMdBOTN1+fhKPAmzAzxM+r6lY/VlQVWcVGo6Ee1feCA076g7rfUiTR8yTwb r9WQuPhGZzsHmf6dh7CVnzmyrlXiqpXWWXfWK0SwEnuTUZCqjApV8iz0Mrtak7sTsuC/ vCZievHCYj4FLw2sp0q6lYqnPGyOakKVuEqRw= MIME-Version: 1.0 Received: by 10.68.213.232 with SMTP id nv8mr58135333pbc.155.1329844891050; Tue, 21 Feb 2012 09:21:31 -0800 (PST) Received: by 10.142.99.12 with HTTP; Tue, 21 Feb 2012 09:21:30 -0800 (PST) In-Reply-To: <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> Date: Tue, 21 Feb 2012 09:21:30 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 17:21:35 -0000 On Tue, Feb 21, 2012 at 7:21 AM, R=E9mi Despr=E9s wrote: > Cameron, > > Thanks for these answers, > More questions and comments below. Remi, thanks again for you rigorous review. > > =A0Le 2012-02-20 =E0 19:44, Cameron Byrne a =E9crit : > ... >>>> =A0 My trial required no change to the >>>> IPv6-only DNS64/NAT64 network beta service that i have offered to by >>>> customers for close to 2 years now. =A0Adding 464XLAT was purely a CPE >>>> function layered onto that existing network "as is". >>>> >>>> 1. Yes, we use DNS64 >>> >>> OK. >>> Could you clarify then what justifies that "It does not require DNS64". >>> >> >> 464XLAT works fine without DNS64. > I don't really understand the below clearly, I will try to answer the best = i can > Well, =A0the discovery heuristic that you used implies DNS64 (ref. the qu= ote just below from draft-ietf-behave-nat64-discovery-heuristic). > Without DNS64, some more assumptions seem to be needed for IPv4 hosts to = get A records, but I couldn't figure out which ones on my own. Without DNS64, the draft-ietf-behave-nat64-discovery-heuristic is not used to discover Pref64. Some other means must be used. draft-ietf-behave-nat64-discovery-heuristic is a known working case today, others may emerge. > =A0"When sending AAAA query for the known name a host MUST set "Checking = Disabled (CD)" bit to zero, as otherwise the DNS64 will not perform IPv6 ad= dress synthesis hence does not reveal the IPv6 prefix(es) used for protocol= translation." > > >> Meaning, the CLAT may do stateless RFC 6145 NAT46 to the IPv6-only >> access network destine for RFC 6146 NAT64 towards the Internet > > Aren't NAT64s always coupled with DNS64s, as seems to be implied by all s= cenarios of RFC6144? > >> This is a complete solution for any IPv4-only hosts behind the CLAT. >> >> For me, DNS64 is advantageous to use for the following reasons in *my* n= etwork >> >> 1. =A0DNS64 is already deployed in my network as part of the NAT64/DNS64 >> service i offer today >> >> 2. =A0DNS64 allows for the discovery of the Pref64 using >> draft-ietf-behave-nat64-discovery-heuristic >> >> 3. =A0DNS64 allows for single translation in cases where the host and >> application are capable of doing IPv6 but the server does not have a >> AAAA record. =A0This is a very common case for my scenario. >> >> Regarding discovery of the Pref64, the draft discusses that Pref64 may >> be discovered through others means. =A0DHCP options in the future, >> manual configuration, proprietary methods ... are all possible in the >> future... Today i have draft-ietf-behave-nat64-discovery-heuristic >> working but i do not want to constrain implementations to just those >> that use DNS64. >> >>>> 2. A dedicated translation prefix was not used. =A0Since my 3GPP Relea= se >>>> 7 network does not support DHCP at all, the address is pushed to the >>>> UE as part of PDP setup in the PCO IE. >>> >>> Why, then, say "In the best case, the CLAT will have a dedicated /64" >>> >> >> It just seems cleaner to me to have a dedicated /64 if it is >> available. =A0Operationally, aside from the NDP claiming the /96, there >> is no difference to have dedicated or not dedicated. > > Understood, but: > - Claiming a /96 on a link seems new to me (is there an existing referenc= e?) It does not need to claim the /96 as a whole. The CLAT will do NDP with the idea that each /128 in the /96 is owned by the CLAT as a virtual address. I have seen this behavior in NAT-PT deployments, but i do not see it specifically declared in the NAT-PT RFC. > - Avoiding the need to do it is AFAIK an improvement, proposed in 4rd-U t= hanks to the V-octet discriminator of 4rd addresses. > - If DNS64s are parametrized to synthesize addresses that have the V octe= t, finding IPv4 addresses in IPv6 addresses can become deterministic instea= d of heuristic. > > >>>> =A0This is how all IPv4 and IPv6 >>>> addresses are assigned to UEs in my network. >>> >>> Is this with a standard format (if yes, a reference would make it clear= ). >>> >> >> I was mistaken before, here is the reference for SLAAC being used for >> address configurations. >> >> http://tools.ietf.org/html/rfc6459#section-5.2 > > Thanks. > > >>>> 3. =A0The UE, which is also the CLAT, received a single /64 of IPv6 fr= om >>>> the network >>> >>> OK. >>> >>>> and no IPv4. >>> >>> (Already understood, otherwise nothing new would be needed) >>> >>> >>>> =A0This is the only address scheme that was >>>> used or can be used in my network >>>> >>>> 4. =A0There was no change to the RFC 6146/6145 behavior, fragment >>>> headers were included. >>> >>> Then why to add a section which describes two variants. >>> Besides, I didn't understand this sentence "In the 464XLAT environment,= the PLAT and CLAT SHOULD include an IPv6 Fragment Header, *since IPv4 host= does not set the DF bit*" (asterisks added). >> >> I think it may be wise to remove that language. =A0Let me check with my >> co-authors. > > OK > >> >>>> >>>> 5. =A0Pref64/n was discovered using draft-ietf-behave-nat64-discovery-= heuristic >>> >>> OK. >>> >>> >>>>> I just say that a real "trial deployment report" would be nice to hav= e, but of course no obligation. >>>>> >>>> >>>> I am attempting to operate as transparently as possible. >>> >>>> Please feel >>>> free to query me further. >>> >>> There is some of this of this above, thanks. >>> >>> ... >>>>> The draft does include SHOULDs and MAYs that belong to standardizatio= n vocabulary, e.g.: >>>>> "In cases where the access network does not allow for a dedicated tra= nslation prefix, the CLAT SHOULD take ownership of the lowest /96 from an a= ttached interface's /64 to source and receive translation traffic. Establis= hing ownership of the /96 requires that the CLAT SHOULD perform NDP so that= no other nodes on the /64 may use the lowest /96." >>>>> >>>> >>>> Correct. =A0The authors, including myself, are not as experience as yo= u, >>> >>> I am not as much experienced in IETF procedures as you seem to believe. >>> Like yourself, I try to understand and apply BCPs. >>> >>>> but i believe informational I-D may use this language. >>>> >>>> Just looking, RFC6092 is informational and uses this language. >>> >>> Personally, I find it confusing in RFC6092, but this is another subject= . >>> >>>> Also, >>>> we are open to changing the document type to BCP or Standard Track if >>>> that is a better fit. =A0It has been recommended on list that this dra= ft >>>> go standards track. =A0So, i believe there is an open discussion here. >>>> We can adjust as the WG sees fit. =A0Right now, i feel most comfortabl= e >>>> with informational. =A0I don't think experimental is helpful to networ= k >>>> operators that trying to solve a near term problem with "no new >>>> technology". >>> >>> My point is that it includes some behavior specification (464XLAT compl= iance is more than just compliance with RFCs it refers to). >>> >>> ... >>> >>>> >>>>>> =A0 =A0RFC6145 is not MAP or >>>>>> 4RD. >>>>> >>>>> Why you say this is unclear. AFAIK nobody ever suggested that. >>>>> >>>> >>>> I keep getting the feeling like 464XLAT should be abandoned and the >>>> use cases should be folded into MAP-T by the MAP-T author or 4RD-U >>>> from the 4RD-U authors, both on and off list. >>> >>> I don't know about off-list, but to say differently what think: >>> - abandoning the new idea expressed in the 464XLAT would be a very bad = idea >>> - OTOH, dealing with it in the context of 4rd-U seems to me a good idea= (unify stateless UE behaviors so that they can work consistently both in n= etworks using stateful NAT64s and those using using with stateless ISP node= s) >>> - working together for this to happen in Softwire would be welcome on m= y side. >>> > >>> BTW, if you can take the time to read the 4rd-U draft, your questions a= nd comments will be most welcome. > > Renewed statement. > > >>>> =A0It seems the softwire >>>> folks see 464XLAT as a competing technology. >>> >>> I am an active Softwire guy, and don't see it that way. >>> >>>> IMHO, MAP-T and 4RD-U do >>>> not solve *my* problems. >>> >>> 4rd-U isn't frozen yet. >>> I see solving your problem as an objective. >>> >>>> =A0We took time to document how 464XLAT is >>>> unique in the draft. >>>> >>>> I have brought to softwires the concern that stateless core NAT64 is >>>> not acceptable given the address efficiency issues (please don't blast >>>> me about how my issues are non-issues). >>> >>> I never did, I hope, but I think I rather asked about real order of mag= nitudes of your problem. >> >> Publicly available information is that T-Mobile USA has 30+ Million >> subscribers and about 100,000 IPv4 addresses, total. =A0Not just for >> subscribers, 100k IP addresses to run the whole business (data >> centers, web sites, DNS servers, ...). >> >> About 1/3 of those subscribers are actively attached to the data >> network and consuming an IPv4 address, data network attachment is >> growing >> >> You can assume we are ~100% utilized on our IPv4 addresses, and that >> nearly all subscribers reside behind existing 19 /25 public IPv4 >> pools. > > I suppose that these 19 prefixes were derived by you from a smaller numbe= r of shorter allocated prefixes, right? > That is these shorter prefixes that are relevant. > IPv4 allocations are frequently fragmented as they are assigned piece meal. So yes, there are shorter prefix, but it is a fragmented set of prefixes. >> My own Android phone has ~20 active TCP sessions at steady-state (push >> updates from email, twitter, facebook, ...). > > A key complementary information is the proportion of these that will work= in IPv6 where IPv6 is available. > Any idea of this proportion? > No, but i am optimistic. >> =A0When i do tethering, it >> goes up substantially. > > BTW, did the trial include tethering? No, that is a feature that is still lacking in the code. I hope to have it covered soon. > In the model, is tethering to be supported with a NAT44 in the UE? > If not, how? > >From the draft: CLAT: CLAT is Customer side translator(XLAT) that complies with [RFC6145]. It algorithmically translates 1:1 private IPv4 packets to global IPv6 packets, and vice versa. The CLAT function is applicable to a router or an end-node such as a mobile phone. CLAT SHOULD perform router function to facilitate packets forwarding through the stateless translation even if it is an end-node. In addition to stateless translation, the CLAT as a common home router or 3G router is expected to perform gateway functions such as DHCP server and DNS proxy for local clients I hope this makes it clear why NAT44 on the tethered phone / mobile router is not required. The PC that is tethered passes IPv4 packets that are immediately translated on the CLAT using 6145 to the IPv6-only access network. This is the same in the case for wireline CPE. >> >> As you can see, things are pretty tight. > > Agreed, but not impossible, see near the end of this email. > >> They are going to get more tight. > > Not so sure as far as IPv4 is concerned: as IPv6 gets really deployed, le= ss and less sessions will consume IPv4 ports. > > >> We chose stateful NAT64 as a path forward since it was a simple >> feature add that leverages the existing NAT44 hardware and /25 ipv4 >> NAT blocks. =A0This means that deploying NAT64 required no new IPv4 >> public addresses. > >> Going to 4RD-U and MAP-T would require a >> substantial re-work of the network to provide a suitable pool of IPv4 >> addresses for the stateless translation. > > > How substantial this rework is does depend on each operator's starting po= int, but AFAIK it is quite feasible (see the example near the end of this e= mail) > > >> We want 464XLAT since it enables us to make IPv6-only a feasible >> service option to our subscribers in the near term, > >> the only missing >> piece from generally available code (shipping products) is the CPE / >> UE to do the CLAT functions of RFC6145 and Pref64 discovery. > > Right, there is _little_ to add to what exists, =A0but still _something_. > That much has to be rigorously specified (the Devil is in details). > >> =A0The >> functions have been submitted to the Android Open Source Project. > > Well done. > > >> That said, please don't try to re-engineer this network scenario on >> the list. > > I just try to understand what you mean, and which part has been validated= . > I am also interested in simplifications that result from unifying good de= signs. > > Suggesting I try to re-engineer is something that could have been avoided= (IMHO). > > Agreed, since you are going to change the inputs substantially regardless of my request. >> =A0This is a real scenario, > > No doubt about this. > >> lets not make it a diversion. > > There is no intent to divert, only to work for progress. > >> I tried to have this generic scenario discussion on softwires here >> http://www.ietf.org/mail-archive/web/softwires/current/msg03402.html > > Indeed and you did receive several answers, including one from me (http:/= /www.ietf.org/mail-archive/web/softwires/current/msg03406.html). > > Note that this contradicts your previous assertion that there was no disc= ussion about 464XLAT in Softwire in the last 3 months (9 e-mails in early F= ebruary do contain "464XLAT") > No contradiction, i said 464XLAT appeared in 0 email titles. >> >>> Didn't get it yet. >>> Ideally that would include the number of simultaneous devices to be sup= ported, and the size of the IPv4 space available, with lengths of IPv4 pref= ixes that compose it. > >>> In any case, your requirement is yours, =A0and some other operators do = have different requirements (tools.ietf.org/html/draft-ietf-softwire-statel= ess-4v6-motivation-00.html). >>> That's why some coordination makes sense. > > Your reasons are obviously legitimate in _your_ environment. > > Yet, it is IMHO interesting to note that, with figures you gave above (30= + million subscribers, 1/3 active, 100k IPv4 addresses), static address sha= ring a la 4rd-U might realistically be introduced: > - Move a fraction of the IPv4 addresses from dynamic to static sharing = =A0say 32K addresses, i.e. 33%. (NAT 64 usage will naturally be reduced as = UEs start using their statically assigned shared addresses instead of NAT64= s). > - Choose a sharing ratio of 512, in order to support 32K*5124=3D 16,777,2= 16 UEs (more than 1/3 * 30+ millions) > - Thus, without losing the benefit of NAT64 for UEs that don't support 4r= d-U, each UE gets a shared public IPv4 address, with 120 reserved ports for= sessions that can't be IPv6. > > Please consider that there is no aggressiveness in pointing this out, jus= t the wish to see realities as they are. I said that 100% of the IPv4 addresses are utilized in place, and you are suggesting above that 32% of my total IPv4 address holdings can be made available for a stateless BR. That is not realistic. Please note this section of the draft well http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00#section-4 CB > My wish is cooperation, not useless competition without understanding val= id points others have made. > >>>> =A0On the softwire list, i >>>> brought this up and was told a /14 of IPv4 was probably needed to meet >>>> a mid to large size wireless operator. > > What is important is the total size of the available IPv4 space, not the = length of the shortest prefix. > > Regards, > RD > > > > >>>> Unfortunately, these address >>>> are not available in APNIC today and will not be available in ARIN or >>>> RIPE in the very near future.... considering the timeline scope the >>>> IETF operates at. =A0That said, the stateless solutions have an audien= ce >>>> with network operators that already have large allocations and wish to >>>> be more efficient. =A0That's great, live and let live. >>>> >>>> Also, the MAP family is quite complicated for me and lack of trial >>>> deployment at scale is a concern since the IPv4 exhaustion issue is >>>> pressing. >>> >>> I share this view on current MAP documents. >>> >>> OTOH, I do think that making UEs that would support a 4rd-U, completed = with permitted RFC1918 addresses in customer sites, would largely increase = their applicability with a limited enough added complexity. >>> >>> >>>> I hope you see that 464XLAT is an operational solution without any >>>> novel technology. >>> >>> In my understanding, 464XLAT does introduce a quite useful technology t= hat is almost completely based on existing pieces, like 6rd, =A0but this do= esn't exclude these two from being NEW technologies. >>> >>> >>> Regards, >>> RD >>> >>> > From shemant@cisco.com Tue Feb 21 09:46:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFA621F87D7 for ; Tue, 21 Feb 2012 09:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.94 X-Spam-Level: X-Spam-Status: No, score=-8.94 tagged_above=-999 required=5 tests=[AWL=1.659, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3azgMeJhm4zO for ; Tue, 21 Feb 2012 09:46:51 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 480B221F85AE for ; Tue, 21 Feb 2012 09:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=968; q=dns/txt; s=iport; t=1329846411; x=1331056011; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=2RZ84dgFTrrTeNsprAi35ICrvR14+DGQMQRudXT6dnA=; b=l+QnPnKlLatrIElPPYY/GxVY1xnjQH0yuwcDddtiTWvUFof92/RZtmcQ TjfYgNbfu5zZHtDulSMis7ztGMWo7MSvlhj35aaCMUyr/bphpwX9rF/ls CgoAfLwqNXrqlJRTd4tjvjq27okcMZ52huYXgLmtN0LjgkA64gJqTobLA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFXXQ0+tJV2Y/2dsb2JhbABDskeBB4FzAQEBBBIBHQpLBAIBCBEEAQELBhcBBgFFCQgBAQQBEggaqAQBlyyLdhoVOgMDAoZ1YwSIT591 X-IronPort-AV: E=Sophos;i="4.73,458,1325462400"; d="scan'208";a="60658918" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 21 Feb 2012 17:46:51 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1LHkoFl030439; Tue, 21 Feb 2012 17:46:50 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 11:46:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Feb 2012 11:46:48 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304076437@XMB-RCD-109.cisco.com> In-Reply-To: <4F43A296.2070207@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] PCP server in draft-ietf-v6ops-6204bis Thread-Index: AczwoK+uB16NN03URDWj/g12p79TIAAH7rVw References: "29 Jan 2012 09:51:52PST."<85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com><201201301936.q0UJaEft000156@givry.fdupont.fr><2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com><4A687585-399D-4077-91AC-A1DC4F101E03@apple.com><2D09D61DDFA73D4C884805CC7865E611025BFE@GAALPA1MSGUSR9N.ITServices.sbc.com><30931DE1-9E57-4296-B0FE-FA98F840D78F@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C3040761AD@XMB-RCD-109.cisco.com> <4F43A296.2070207@viagenie.ca> From: "Hemant Singh (shemant)" To: "Simon Perreault" , X-OriginalArrivalTime: 21 Feb 2012 17:46:50.0999 (UTC) FILETIME=[CA941070:01CCF0C0] Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 17:46:55 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Simon Perreault Sent: Tuesday, February 21, 2012 8:57 AM To: v6ops@ietf.org Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis >OS support is almost irrelevant. Applications today do UPnP and NAT-PMP >without OS support. They just send the packets themselves, using=20 >UPnP/NAT-PMP in a third-party (often open source) library. I would=20 >expect the same for PCP. >Applications evolve much faster than the IETF is accustomed to. You=20 >could wake up one day to one or two new open source PCP libraries, and=20 >then wake up the next with the major BitTorrent apps supporting PCP, and=20 >then everything else follows (games, etc.). The other reason is that the LAN behavior of a CPE router is under the homenet WG charter for over one year back. Rfc6204bis stays away from any new LAN behavior for the CPE router. Hemant From despres.remi@laposte.net Tue Feb 21 10:42:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FDC21F88E5 for ; Tue, 21 Feb 2012 10:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7ffojfmG3Th for ; Tue, 21 Feb 2012 10:42:12 -0800 (PST) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 937E421F88E1 for ; Tue, 21 Feb 2012 10:42:07 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8504-out with ME id cii41i00537Y3f403ii4Bo; Tue, 21 Feb 2012 19:42:05 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 21 Feb 2012 19:42:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 18:42:16 -0000 Le 2012-02-21 =E0 18:21, Cameron Byrne a =E9crit : > On Tue, Feb 21, 2012 at 7:21 AM, R=E9mi Despr=E9s = wrote: ... >>>> Could you clarify then what justifies that "It does not require = DNS64". >>>>=20 >>>=20 >>> 464XLAT works fine without DNS64. >>=20 >=20 > I don't really understand the below clearly, I will try to answer the = best i can >=20 >> Well, the discovery heuristic that you used implies DNS64 (ref. the = quote just below from draft-ietf-behave-nat64-discovery-heuristic). >> Without DNS64, some more assumptions seem to be needed for IPv4 hosts = to get A records, but I couldn't figure out which ones on my own. >=20 > Without DNS64, the draft-ietf-behave-nat64-discovery-heuristic is not > used to discover Pref64. Some other means must be used. > draft-ietf-behave-nat64-discovery-heuristic is a known working case > today, others may emerge. "May emerge" is good enough an answer. Thanks. ... >> Aren't NAT64s always coupled with DNS64s, as seems to be implied by = all scenarios of RFC6144? An answer to this? ... >>>> Why, then, say "In the best case, the CLAT will have a dedicated = /64" >>>>=20 >>>=20 >>> It just seems cleaner to me to have a dedicated /64 if it is >>> available. Operationally, aside from the NDP claiming the /96, = there >>> is no difference to have dedicated or not dedicated. >>=20 >> Understood, but: >> - Claiming a /96 on a link seems new to me (is there an existing = reference?) >=20 > It does not need to claim the /96 as a whole. The CLAT will do NDP > with the idea that each /128 in the /96 is owned by the CLAT as a > virtual address. Was understood. > I have seen this behavior in NAT-PT deployments, but i do not see it > specifically declared in the NAT-PT RFC. Right, it seems to be new material as far as IETF is concerned. ... >>> Publicly available information is that T-Mobile USA has 30+ Million >>> subscribers and about 100,000 IPv4 addresses, total. Not just for >>> subscribers, 100k IP addresses to run the whole business (data >>> centers, web sites, DNS servers, ...). >>>=20 >>> About 1/3 of those subscribers are actively attached to the data >>> network and consuming an IPv4 address, data network attachment is >>> growing >>>=20 >>> You can assume we are ~100% utilized on our IPv4 addresses, and that >>> nearly all subscribers reside behind existing 19 /25 public IPv4 >>> pools. >>=20 >> I suppose that these 19 prefixes were derived by you from a smaller = number of shorter allocated prefixes, right? >> That is these shorter prefixes that are relevant. >>=20 >=20 > IPv4 allocations are frequently fragmented as they are assigned piece > meal. Indeed. This is why 4rd-U can, with several mapping rules, assign shared = addresses that start with prefixes of a fragmented IPv4 space.=20 > So yes, there are shorter prefix, but it is a fragmented set of > prefixes. OK. >>> My own Android phone has ~20 active TCP sessions at steady-state = (push >>> updates from email, twitter, facebook, ...). >>=20 >> A key complementary information is the proportion of these that will = work in IPv6 where IPv6 is available. >> Any idea of this proportion? >>=20 >=20 > No, but i am optimistic. So am I. The number of ports needed for IPv4 should very quickly decrease = wherever IPv6 is enabled. >>> When i do tethering, it >>> goes up substantially. >>=20 >> BTW, did the trial include tethering? >=20 > No, that is a feature that is still lacking in the code. I hope to > have it covered soon. OK. >> In the model, is tethering to be supported with a NAT44 in the UE? >> If not, how? >>=20 >=20 > =46rom the draft: >=20 > CLAT: CLAT is Customer side translator(XLAT) that complies with > [RFC6145]. It algorithmically translates 1:1 private IPv4 > packets to global IPv6 packets, and vice versa. The CLAT > function is applicable to a router or an end-node such as a > mobile phone. CLAT SHOULD perform router function to > facilitate packets forwarding through the stateless > translation even if it is an end-node. In addition to > stateless translation, the CLAT as a common home router or = 3G > router is expected to perform gateway functions such as DHCP > server and DNS proxy for local clients OK. (Apologies for having asked a superfluous question.)=20 =20 > I hope this makes it clear why NAT44 on the tethered phone / mobile > router is not required. The PC that is tethered passes IPv4 packets > that are immediately translated on the CLAT using 6145 to the > IPv6-only access network. This is the same in the case for wireline > CPE. Understood. There may be some issues about hosts that query the NAT, e.g. with = multicast for UPnP. This is similar to DS-lite, but RFC6333 only says "Discussion of = multicast is out of scope for this document."=20 >>> That said, please don't try to re-engineer this network scenario on >>> the list. >>=20 >> I just try to understand what you mean, and which part has been = validated. >> I am also interested in simplifications that result from unifying = good designs. >>=20 >> Suggesting I try to re-engineer is something that could have been = avoided (IMHO) > Agreed, since you are going to change the inputs substantially > regardless of my request. Sorry, I don't understand what you are talking about. It sounds like a disapproval of something I do here, but I can't follow = what that is. ... >>> I tried to have this generic scenario discussion on softwires here >>> http://www.ietf.org/mail-archive/web/softwires/current/msg03402.html >>=20 >> Indeed and you did receive several answers, including one from me = (http://www.ietf.org/mail-archive/web/softwires/current/msg03406.html). >>=20 >> Note that this contradicts your previous assertion that there was no = discussion about 464XLAT in Softwire in the last 3 months (9 e-mails in = early February do contain "464XLAT") >>=20 >=20 > No contradiction, i said 464XLAT appeared in 0 email titles. OK. (Apologies for having missed you were talking only about titles.) =20 ... >> Yet, it is IMHO interesting to note that, with figures you gave above = (30+ million subscribers, 1/3 active, 100k IPv4 addresses), static = address sharing a la 4rd-U might realistically be introduced: >> - Move a fraction of the IPv4 addresses from dynamic to static = sharing say 32K addresses, i.e. 33%. (NAT 64 usage will naturally be = reduced as UEs start using their statically assigned shared addresses = instead of NAT64s). >> - Choose a sharing ratio of 512, in order to support 32K*5124=3D = 16,777,216 UEs (more than 1/3 * 30+ millions) >> - Thus, without losing the benefit of NAT64 for UEs that don't = support 4rd-U, each UE gets a shared public IPv4 address, with 120 = reserved ports for sessions that can't be IPv6. >>=20 >> Please consider that there is no aggressiveness in pointing this out, = just the wish to see realities as they are. >=20 > I said that 100% of the IPv4 addresses are utilized in place, and you > are suggesting above that 32% of my total IPv4 address holdings can be > made available for a stateless BR. That is not realistic. Well, I suppose it is possible in NAT64s to change the set of IPv4 = addresses they use. Reducing these sets when many customers will cease using NAT64s (because = they now use statically shared IPv4 addresses instead), seems to me = quite reasonable. Note that for an operator that hasn't deployed NAT64s, and can go = directly the stateless way, the problem is a lot simpler. With the same numbers of customers and IPv4 addresses, each UE could = easily be assigned twice as many ports per CE. > Please note this section of the draft well > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00#section-4 I think I understand your motivations, and hope you can understand those = of draft-ietf-softwire-stateless-4v6-motivation. Regards, RD From cb.list6@gmail.com Tue Feb 21 11:34:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7009421E8076 for ; Tue, 21 Feb 2012 11:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMfbM6tMr1Un for ; Tue, 21 Feb 2012 11:34:51 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DDA2221E8075 for ; Tue, 21 Feb 2012 11:34:46 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so8039988pbc.31 for ; Tue, 21 Feb 2012 11:34:46 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.134.198 as permitted sender) client-ip=10.68.134.198; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.134.198 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.134.198]) by 10.68.134.198 with SMTP id pm6mr78764866pbb.8.1329852886784 (num_hops = 1); Tue, 21 Feb 2012 11:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YWn1c7GYVuwlg1oI2GW1mvlpIsR1rVfQuz/EmA/Z5AM=; b=djSAt7B/I+T3bTghAyUxV58NnHez0JMXSrEL3xjgn5z+7AF0yW81REB9BzNtQzXfp1 RKXJVOnvHhReC4YgzyLVepx5rqdZ/MkPkDAQ/n4o8zfC9qE4p00zGDmO7HW0XXTmPlmF wKxQAz+YPEcVOOzZqWFuQarDbvvXFnMsGxLrE= MIME-Version: 1.0 Received: by 10.68.134.198 with SMTP id pm6mr64914934pbb.8.1329852886701; Tue, 21 Feb 2012 11:34:46 -0800 (PST) Received: by 10.142.99.12 with HTTP; Tue, 21 Feb 2012 11:34:46 -0800 (PST) In-Reply-To: References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> Date: Tue, 21 Feb 2012 11:34:46 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 19:34:55 -0000 Remi On Tue, Feb 21, 2012 at 10:42 AM, R=E9mi Despr=E9s wrote: > > Le 2012-02-21 =E0 18:21, Cameron Byrne a =E9crit : > >> On Tue, Feb 21, 2012 at 7:21 AM, R=E9mi Despr=E9s wrote: > ... >>>>> Could you clarify then what justifies that "It does not require DNS64= ". >>>>> >>>> >>>> 464XLAT works fine without DNS64. >>> >> >> I don't really understand the below clearly, I will try to answer the be= st i can >> >>> Well, =A0the discovery heuristic that you used implies DNS64 (ref. the = quote just below from draft-ietf-behave-nat64-discovery-heuristic). >>> Without DNS64, some more assumptions seem to be needed for IPv4 hosts t= o get A records, but I couldn't figure out which ones on my own. >> >> Without DNS64, the draft-ietf-behave-nat64-discovery-heuristic is not >> used to discover Pref64. Some other means must be used. >> draft-ietf-behave-nat64-discovery-heuristic is a known working case >> today, others may emerge. > > "May emerge" is good enough an answer. > Thanks. > > ... >>> Aren't NAT64s always coupled with DNS64s, as seems to be implied by all= scenarios of RFC6144? > > An answer to this? > Sorry i missed this earlier. In the case for RFC6144 to replace NAT-PT functionality, yes a DNS64 and NAT64 must be coupled to replace NAT-PT functions. But, RFC6146 and RFC6147 stand on their own. There is no explicit coupling required or shared state between NAT64 and DNS64 for them to perform their atomic functions. Meaning, any conforming packet (Pref64+32bit IPv4 destination address) may be received by an RFC6146 stateful NAT64 and be translated. A properly configured CLAT that knows the Pref64 may received IPv4 packets and translate them via RFC6145 to a PLAT without any queries or interactions with the DNS64. > ... >>>>> Why, then, say "In the best case, the CLAT will have a dedicated /64" >>>>> >>>> >>>> It just seems cleaner to me to have a dedicated /64 if it is >>>> available. =A0Operationally, aside from the NDP claiming the /96, ther= e >>>> is no difference to have dedicated or not dedicated. >>> >>> Understood, but: >>> - Claiming a /96 on a link seems new to me (is there an existing refere= nce?) >> >> It does not need to claim the /96 as a whole. =A0The CLAT will do NDP >> with the idea that each /128 in the /96 is owned by the CLAT as a >> virtual address. > > Was understood. > >> I have seen this behavior in NAT-PT deployments, but i do not see it >> specifically declared in the NAT-PT RFC. > > Right, it seems to be new material as far as IETF is concerned. > NDP for a host address should not be new material. As i mentioned before, we can treat each address in the /96 as a host address on the CLAT, and the interactions are normal for NDP host addresses. Alternatively, we may view the CLAT in terms of proxy NDP http://tools.ietf.org/html/rfc4861#section-7.2.8 The CLAT is willing to accept packet destine to the /96 on behalf of the IPv4 internet, and the NDP actions are defined as existing Proxy NDP. Thoughts on one verse the other? > > ... >>>> Publicly available information is that T-Mobile USA has 30+ Million >>>> subscribers and about 100,000 IPv4 addresses, total. =A0Not just for >>>> subscribers, 100k IP addresses to run the whole business (data >>>> centers, web sites, DNS servers, ...). >>>> >>>> About 1/3 of those subscribers are actively attached to the data >>>> network and consuming an IPv4 address, data network attachment is >>>> growing >>>> >>>> You can assume we are ~100% utilized on our IPv4 addresses, and that >>>> nearly all subscribers reside behind existing 19 /25 public IPv4 >>>> pools. >>> >>> I suppose that these 19 prefixes were derived by you from a smaller num= ber of shorter allocated prefixes, right? >>> That is these shorter prefixes that are relevant. >>> >> >> IPv4 allocations are frequently fragmented as they are assigned piece >> meal. > > Indeed. > This is why 4rd-U can, with several mapping rules, assign shared addresse= s that start with prefixes of a fragmented IPv4 space. > >> So yes, there are shorter prefix, but it is a fragmented set of >> prefixes. > > OK. > > >>>> My own Android phone has ~20 active TCP sessions at steady-state (push >>>> updates from email, twitter, facebook, ...). >>> >>> A key complementary information is the proportion of these that will wo= rk in IPv6 where IPv6 is available. >>> Any idea of this proportion? >>> >> >> No, but i am optimistic. > > So am I. > The number of ports needed for IPv4 should very quickly decrease wherever= IPv6 is enabled. > > >>>> =A0When i do tethering, it >>>> goes up substantially. >>> >>> BTW, did the trial include tethering? >> >> No, that is a feature that is still lacking in the code. =A0I hope to >> have it covered soon. > > OK. > >>> In the model, is tethering to be supported with a NAT44 in the UE? >>> If not, how? >>> >> >> From the draft: >> >> =A0 CLAT: =A0 CLAT is Customer side translator(XLAT) that complies with >> =A0 =A0 =A0 =A0 =A0 [RFC6145]. =A0It algorithmically translates 1:1 priv= ate IPv4 >> =A0 =A0 =A0 =A0 =A0 packets to global IPv6 packets, and vice versa. =A0T= he CLAT >> =A0 =A0 =A0 =A0 =A0 function is applicable to a router or an end-node su= ch as a >> =A0 =A0 =A0 =A0 =A0 mobile phone. =A0CLAT SHOULD perform router function= to >> =A0 =A0 =A0 =A0 =A0 facilitate packets forwarding through the stateless >> =A0 =A0 =A0 =A0 =A0 translation even if it is an end-node. =A0In additio= n to >> =A0 =A0 =A0 =A0 =A0 stateless translation, the CLAT as a common home rou= ter or 3G >> =A0 =A0 =A0 =A0 =A0 router is expected to perform gateway functions such= as DHCP >> =A0 =A0 =A0 =A0 =A0 server and DNS proxy for local clients > > OK. > (Apologies for having asked a superfluous question.) > > >> I hope this makes it clear why NAT44 on the tethered phone / mobile >> router is not required. =A0The PC that is tethered passes IPv4 packets >> that are immediately translated on the CLAT using 6145 to the >> IPv6-only access network. =A0This is the same in the case for wireline >> CPE. > > Understood. > There may be some issues about hosts that query the NAT, e.g. with multic= ast for UPnP. > This is similar to DS-lite, but RFC6333 only says "Discussion of multicas= t is out of scope for this document." > > >>>> That said, please don't try to re-engineer this network scenario on >>>> the list. >>> >>> I just try to understand what you mean, and which part has been validat= ed. >>> I am also interested in simplifications that result from unifying good = designs. >>> >>> Suggesting I try to re-engineer is something that could have been avoid= ed (IMHO) > >> Agreed, since you are going to change the inputs substantially >> regardless of my request. > > Sorry, I don't understand what you are talking about. > It sounds like a disapproval of something I do here, but I can't follow w= hat that is. > > ... >>>> I tried to have this generic scenario discussion on softwires here >>>> http://www.ietf.org/mail-archive/web/softwires/current/msg03402.html >>> >>> Indeed and you did receive several answers, including one from me (http= ://www.ietf.org/mail-archive/web/softwires/current/msg03406.html). >>> >>> Note that this contradicts your previous assertion that there was no di= scussion about 464XLAT in Softwire in the last 3 months (9 e-mails in early= February do contain "464XLAT") >>> >> >> No contradiction, i said 464XLAT appeared in 0 email titles. > > OK. > (Apologies for having missed you were talking only about titles.) > > > ... >>> Yet, it is IMHO interesting to note that, with figures you gave above (= 30+ million subscribers, 1/3 active, 100k IPv4 addresses), static address s= haring a la 4rd-U might realistically be introduced: >>> - Move a fraction of the IPv4 addresses from dynamic to static sharing = =A0say 32K addresses, i.e. 33%. (NAT 64 usage will naturally be reduced as = UEs start using their statically assigned shared addresses instead of NAT64= s). >>> - Choose a sharing ratio of 512, in order to support 32K*5124=3D 16,777= ,216 UEs (more than 1/3 * 30+ millions) >>> - Thus, without losing the benefit of NAT64 for UEs that don't support = 4rd-U, each UE gets a shared public IPv4 address, with 120 reserved ports f= or sessions that can't be IPv6. >>> >>> Please consider that there is no aggressiveness in pointing this out, j= ust the wish to see realities as they are. >> >> I said that 100% of the IPv4 addresses are utilized in place, and you >> are suggesting above that 32% of my total IPv4 address holdings can be >> made available for a stateless BR. =A0That is not realistic. > > Well, I suppose it is possible in NAT64s to change the set of IPv4 addres= ses they use. > Reducing these sets when many customers will cease using NAT64s (because = they now use statically shared IPv4 addresses instead), seems to me quite r= easonable. > > Note that for an operator that hasn't deployed NAT64s, and can go directl= y the stateless way, the problem is a lot simpler. > With the same numbers of customers and IPv4 addresses, each UE could easi= ly be assigned twice as many ports per CE. > > >> Please note this section of the draft well >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00#section-4 > > I think I understand your motivations, and hope you can understand those = of draft-ietf-softwire-stateless-4v6-motivation. > Yes, and thanks again for your careful review and attention to the 464XLAT = draft CB > Regards, > RD > > > From jason_livingood@cable.comcast.com Tue Feb 21 11:38:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C6621E807E; Tue, 21 Feb 2012 11:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.164 X-Spam-Level: X-Spam-Status: No, score=-103.164 tagged_above=-999 required=5 tests=[AWL=-1.934, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6GyP-mpV8Ri; Tue, 21 Feb 2012 11:38:10 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id A636921E807B; Tue, 21 Feb 2012 11:38:10 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.6844449; Tue, 21 Feb 2012 12:27:44 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Tue, 21 Feb 2012 14:38:05 -0500 From: "Livingood, Jason" To: Lorenzo Colitti Thread-Topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-Index: AQHM6/nKbjYam0no7UGRxd2Rv+MjlJZHV/UAgABwwIA= Date: Tue, 21 Feb 2012 19:38:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: multipart/alternative; boundary="_000_CB6958DA51145jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: v6ops v6ops WG , IETF Discussion Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 19:38:11 -0000 --_000_CB6958DA51145jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 2/21/12 2:54 AM, "Lorenzo Colitti" > wrote: I think the suggested change does not go far enough. The "high-service-leve= l domains" that prompted this draft to be written, and all the implementers= I'm currently aware of, are decommissioning the practice. So the paragraph that states, "It is unclear how implementers will judge wh= en the network conditions will have changed sufficiently to justify turning= off DNS Resolver Whitelisting and/or what the process and timing will be f= or discontinuing this practice" is still incorrect. Can you just remove the= paragraph and start the section with "Many implementers have announced tha= t they plan to permanently turn off whitelisting beginning on..." ? I've changed it around to the following: Domains that choose to implement DNS Resolver Whitelisting generally consid= er it to be a temporary measure. Many implementers have announced that they= plan to permanently turn off DNS Resolver Whitelisting beginning on the da= te of the World IPv6 Launch, on June 6, 2012 . For any implementers that do not turn off DNS Resolver Whitelisting= at that time, it may be unclear how each and every one will judge when the= network conditions to have changed sufficiently to justify turning off DNS= Resolver Whitelisting. That being said, it is clear that the extent of IPv= 6 deployment to end users in networks, the state of IPv6-related impairment= , and the maturity of IPv6 operations are all important factors. Any such i= mplementers may wish to take into consideration that, as a practical matter= , it will be impossible to get to a point where there are no longer any IPv= 6-related impairments; some reasonably small number of hosts will inevitabl= y be left behind as end users elect not to upgrade them or as some hosts ar= e incapable of being upgraded. Thanks for your input, Jason --_000_CB6958DA51145jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On 2/21/12 2:54 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
I think the suggested change does not go far enough. The "high-se= rvice-level domains" that prompted this draft to be written, and all t= he implementers I'm currently aware of, are decommissioning the practice.

So the paragraph that states, "It is unclear how implementers wil= l judge when the network conditions will have changed sufficiently to justi= fy turning off DNS Resolver Whitelisting and/or what the process and timing= will be for discontinuing this practice" is still incorrect. Can you just remove the paragraph and start the sectio= n with "Many implementers have announced that they plan to permanently= turn off whitelisting beginning on..." ?

I've changed it around to the following:

Domains that choose to implement DNS Resolver Whitelisting generall= y consider it to be a temporary measure. Many implementers have announced t= hat they plan to permanently turn off DNS Resolver Whitelisting beginning o= n the date of the World IPv6 Launch, on June 6, 2012 <xref target=3D'World IPv6 Launch'/>. For any implem= enters that do not turn off DNS Resolver Whitelisting at that time, it may = be unclear how each and every one will judge when the network conditions to= have changed sufficiently to justify turning off DNS Resolver Whitelisting. That being said, it is clear that the exten= t of IPv6 deployment to end users in networks, the state of IPv6-related im= pairment, and the maturity of IPv6 operations are all important factors. An= y such implementers may wish to take into consideration that, as a practical matter, it will be impossible= to get to a point where there are no longer any IPv6-related impairments; = some reasonably small number of hosts will inevitably be left behind as end= users elect not to upgrade them or as some hosts are incapable of being upgraded.


Thanks for your input,
Jason
--_000_CB6958DA51145jasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Feb 21 11:45:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBC721E805B for ; Tue, 21 Feb 2012 11:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.136 X-Spam-Level: X-Spam-Status: No, score=-106.136 tagged_above=-999 required=5 tests=[AWL=2.327, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+gPlK0CV9Gd for ; Tue, 21 Feb 2012 11:45:33 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id B63DD21F8501 for ; Tue, 21 Feb 2012 11:45:32 -0800 (PST) Received: from ([24.40.56.114]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.151920482; Tue, 21 Feb 2012 14:44:51 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Tue, 21 Feb 2012 14:44:51 -0500 From: "Livingood, Jason" To: Joel jaeggli , Marc Lampo , Ronald Bonica Thread-Topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-Index: AQHM8NFGCTjaobpzcUWNbcVExb7NGw== Date: Tue, 21 Feb 2012 19:44:51 +0000 Message-ID: In-Reply-To: <4F42C1E6.7010606@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: multipart/alternative; boundary="_000_CB695DB05117Ajasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 19:45:34 -0000 --_000_CB695DB05117Ajasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 2/20/12 4:57 PM, "Joel jaeggli" > wrote: IMHO the following applies. if you have one zone yeah I agree. If you have two zones one with aaaa and one without (assuming this is done = with dns views style implementation) you can sign both and they'll both be = valid and complete from the vantage point of a client which resolves one or= the other of them but not both. this is a traditional split horizon problem. it's just not inside/outside. Exactly, which is one of the reasons section 4.3.4 is there (Similarities t= o Split DNS). This is two zones (or 'views' of the zone data). Both can be = signed. Jason --_000_CB695DB05117Ajasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5DCDFC0FE95AD040AF6446E2F5062B7F@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
On 2/20/12 4:57 PM, "Joel jaeggli" <joelja@bogus.com> wrote:
IMHO the following applies.

if you have one zone yeah I agree.

If you have two zones one with aaaa and one without (assuming this is&= nbsp;done with dns views style implementation) you can sign both and they'l= l both be valid and complete from the vantage point of a client which&= nbsp;resolves one or the other of them but not both.

this is a traditional split horizon problem. it's just not inside/outs= ide.

Exactly, which is one of the reasons section 4.3.4 is there (Similarit= ies to Split DNS). This is two zones (or 'views' of the zone data). Both ca= n be signed.

Jason
--_000_CB695DB05117Ajasonlivingoodcablecomcastcom_-- From jason_livingood@cable.comcast.com Tue Feb 21 11:47:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE4021F8503 for ; Tue, 21 Feb 2012 11:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.801 X-Spam-Level: X-Spam-Status: No, score=-102.801 tagged_above=-999 required=5 tests=[AWL=-2.171, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfHYe2VAtXX6 for ; Tue, 21 Feb 2012 11:47:29 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id A25B321E808B for ; Tue, 21 Feb 2012 11:47:29 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.6846027; Tue, 21 Feb 2012 12:36:26 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Tue, 21 Feb 2012 14:46:48 -0500 From: "Livingood, Jason" To: Ronald Bonica , Marc Lampo , "EXT - joelja@bogus.com" Thread-Topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-Index: AQHM8NGMkD00gtDZEUSP/1IDM55exQ== Date: Tue, 21 Feb 2012 19:46:48 +0000 Message-ID: In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D7671A23BD@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: multipart/alternative; boundary="_000_CB695E6D51184jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 19:47:33 -0000 --_000_CB695E6D51184jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good idea and it is quick & easy edit. Making the change now. Will send tex= t momentarily. Jason On 2/21/12 8:44 AM, "Ronald Bonica" > wrote: Authors, What do you think? Ron -----Original Message----- From: Marc Lampo [mailto:marc.lampo@eurid.eu] Sent: Tuesday, February 21, 2012 2:03 AM To: Ronald Bonica; EXT - joelja@bogus.com Cc: v6ops@ietf.org Subject: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Hello, I had assumed : 1 zone file (and Mark Andrews correctly pointed at "views"). Would adding this piece of information, directly in the RFC, be useful to avoid confusion for future readers ? Thanks and kind regards, Marc Lampo -----Original Message----- From: Ronald Bonica [mailto:rbonica@juniper.net] Sent: 20 February 2012 11:55 PM To: EXT - joelja@bogus.com; Marc Lampo Cc: v6ops@ietf.org Subject: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Marc, Havard, Are you satisfied with the answers provided by Joel and Mark? Ron > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops= -bounces@ietf.org] On Behalf > Of EXT - joelja@bogus.com > Sent: Monday, February 20, 2012 4:58 PM > To: Marc Lampo > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Last Call: implications-08.txt> (Considerations for Transitioning Content to IPv6) > to Informational RFC > > On 2/20/12 06:32 , Marc Lampo wrote: > > Hello, > > > > (sorry to be late with my comments, bit overloaded on my side) > > > > 6.1 Security Considerations - paragraph 2 (on DNSSEC) > > The text states : "there should not be any negative impact on DNSSEC" > > In my opinion, this is *wrong* : > > > > IMHO the following applies. > > if you have one zone yeah I agree. > > If you have two zones one with aaaa and one without (assuming this is > done with dns views style implementation) you can sign both and they'll > both be valid and complete from the vantage point of a client which > resolves one or the other of them but not both. > > this is a traditional split horizon problem. it's just not > inside/outside. > > joel > > > It is correct that, if an AAAA record exists (in a DNSSEC's zone), > > the appropriate RRSIG will be known to authoritative NS's. > > If, via white listing, the decision is taken not to present the AAAA > > record > > (and its signature), this seems OK. > > > > However : not returning an AAAA record seems identical to : there is > no > > AAAA record. > > And that - there is no AAAA record - yields to "Next Secure" changes > ! > > If no AAAA record exists, for a name, the corresponding NSEC (NSEC3) > > record > > should not hold a reference to AAAA. > > But if that AAAA record does exist, the authoritative NS will have > NSEC > > (NSEC3) > > data that shows so. > > > > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but due > to > > whitelisting > > will not be returned), cannot be proven by accompanying (and > required) > > NSEC (NSEC3) > > information. > > Hence : this draft will/might make DNSSEC validating name servers > fail. > > > > > > If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) in > > detail, > > please observe : > > 1) the caching name server (and "stub resolver") ask 2 queries > > (there is only one line, > > but it are two queries : one for "A", one for "AAAA") > > 2) if the caching name server (or stub resolver) performs DNSSEC > > validation, > > it will never accept a reply of "NODATA" to the query of AAAA > > (because the NSEC (NSEC3) information will not prove that > > non-existance) > > ((and the validating name server will repeat the query to all > > authoritative NS's, looking for a validatable answer)) > > > > (the final result, to the user might be that only the A record is > useable > > - mission accomplished ? > > But the side effect will be that validating caching name servers > will hit > > *all* authoritative servers for the domain, > > "in search of" a correctly validating answer.) > > > > So, while for the end-user, the result might be identical, > > one "security impact" of this approach is > > additional (useless) DNS traffic and > > additional load on authoritative NS's (that implement whitelisting) > > > > > > Kind regards, > > > > Marc Lampo > > Security Officer > > EURid > > > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: 01 February 2012 04:09 PM > > To: IETF-Announce > > Cc: v6ops@ietf.org > > Subject: [v6ops] Last Call: > > > > (Considerations for Transitioning Content to IPv6) to Informational > RFC > > > > > > The IESG has received a request from the IPv6 Operations WG (v6ops) > to > > consider the following document: > > - 'Considerations for Transitioning Content to IPv6' > > as an > > Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to > the > > ietf@ietf.org mailing lists by 2012-02-15. Except= ionally, comments > may be > > sent to iesg@ietf.org instead. In either case, pl= ease retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document describes considerations for the transition of end > user > > content on the Internet to IPv6. While this is tailored to > address > > end user content, which is typically web-based, many aspects of > this > > document may be more broadly applicable to the transition to IPv6 > of > > other applications and services. This document explores the > > challenges involved in the transition to IPv6, potential migration > > tactics, possible migration phases, and other considerations. The > > audience for this document is the Internet community generally, > > particularly IPv6 implementers. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > whitelisting-impl > > ications/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > whitelisting-impl > > ications/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_CB695E6D51184jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Good idea= and it is quick & easy edit. Making the change now. Will send text mom= entarily.

Jason

On 2/21/= 12 8:44 AM, "Ronald Bonica" <rbonica@juniper.net> wrote:

Authors,

What do you think?

           &nbs= p;    Ron

-----Original Message-----
From: Marc Lampo [mailto:marc.l= ampo@eurid.eu]
Sent: Tuesday, February 21, 2012 2:03 AM
To: Ronald Bonica; EXT - joelja@bo= gus.com
Subject: RE: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelist= ing-
implications-08.txt> (Considerations for Transitioning Content to I= Pv6)
to Informational RFC
Hello,
I had assumed : 1 zone file (and Mark Andrews correctly pointed at
"views").
Would adding this piece of information, directly in the RFC,
be useful to avoid confusion for future readers ?
Thanks and kind regards,
Marc Lampo
-----Original Message-----
From: Ronald Bonica [mailto:rbo= nica@juniper.net]
Sent: 20 February 2012 11:55 PM
To: EXT - joelja@bogus.com; Ma= rc Lampo
Subject: RE: [v6ops] Last Call:
<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt>
(Considerations for Transitioning Content to IPv6) to Informational RF= C
Marc, Havard,
Are you satisfied with the answers provided by Joel and Mark?
           &nbs= p;            &= nbsp;           &nbs= p; Ron
> -----Original Message-----
Behalf
> Of EXT - joelja@bogus.com=
> Sent: Monday, February 20, 2012 4:58 PM
> To: Marc Lampo
> Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-
whitelisting-
> implications-08.txt> (Considerations for Transitioning Content= to
IPv6)
> to Informational RFC
>
> On 2/20/12 06:32 , Marc Lampo wrote:
> > Hello,
> >
> > (sorry to be late with my comments, bit overloaded on my sid= e)
> >
> > 6.1 Security Considerations - paragraph 2 (on DNSSEC)
> > The text states : "there should not be any negative imp= act on
DNSSEC"
> > In my opinion, this is *wrong* :
> >
>
> IMHO the following applies.
>
> if you have one zone yeah I agree.
>
> If you have two zones one with aaaa and one without (assuming thi= s is
> done with dns views style implementation) you can sign both and
they'll
> both be valid and complete from the vantage point of a client whi= ch
> resolves one or the other of them but not both.
>
> this is a traditional split horizon problem. it's just not
> inside/outside.
>
> joel
>
> > It is correct that, if an AAAA record exists (in a DNSSEC's = zone),
> > the appropriate RRSIG will be known to authoritative NS's.
> > If, via white listing, the decision is taken not to present = the
AAAA
> > record
> > (and its signature), this seems OK.
> >
> > However : not returning an AAAA record seems identical to : = there
is
> no
> > AAAA record.
> > And that - there is no AAAA record - yields to "Next Se= cure"
changes
> !
> > If no AAAA record exists, for a name, the corresponding NSEC=
(NSEC3)
> > record
> > should not hold a reference to AAAA.
> > But if that AAAA record does exist, the authoritative NS wil= l have
> NSEC
> > (NSEC3)
> > data that shows so.
> >
> > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA e= xists but
due
> to
> > whitelisting
> > will not be returned), cannot be proven by accompanying (and=
> required)
> > NSEC (NSEC3)
> > information.
> > Hence : this draft will/might make DNSSEC validating name se= rvers
> fail.
> >
> >
> > If you look at 4.3.1.1 (Description of DNS Resolver Whitelis= ting)
in
> > detail,
> > please observe :
> > 1) the caching name server (and "stub resolver") a= sk 2 queries
> >     (there is only one line,
> >      but it are two queries : = one for "A", one for "AAAA")
> > 2) if the caching name server (or stub resolver) performs DN= SSEC
> > validation,
> >     it will never accept a reply of &quo= t;NODATA" to the query of AAAA
> >     (because the NSEC (NSEC3) informatio= n will not prove that
> > non-existance)
> >     ((and the validating name server wil= l repeat the query to all
> >       authoritative NS's, look= ing for a validatable answer))
> >
> > (the final result, to the user might be that only the A reco= rd is
> useable
> >  - mission accomplished ?
> >  But the side effect will be that validating cachi= ng name servers
> will hit
> >   *all* authoritative servers for the domain,
> >   "in search of" a correctly validating = answer.)
> >
> > So, while for the end-user, the result might be identical,
> > one "security impact" of this approach is
> > additional (useless) DNS traffic and
> > additional load on authoritative NS's (that implement whitel= isting)
> >
> >
> > Kind regards,
> >
> > Marc Lampo
> > Security Officer
> > EURid
> >
> >
> > -----Original Message-----
> > Sent: 01 February 2012 04:09 PM
> > To: IETF-Announce
> > Cc: v6ops@ietf.org
> > Subject: [v6ops] Last Call:
> > <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.tx= t>
> > (Considerations for Transitioning Content to IPv6) to Inform= ational
> RFC
> >
> >
> > The IESG has received a request from the IPv6 Operations WG = (v6ops)
> to
> > consider the following document:
> > - 'Considerations for Transitioning Content to IPv6'
> >   <draft-ietf-v6ops-v6-aaaa-whitelisting-implic= ations-08.txt> as an
> > Informational RFC
> >
> > The IESG plans to make a decision in the next few weeks, and=
solicits
> > final comments on this action. Please send substantive comme= nts to
> the
> > ietf@ietf.org mailing l= ists by 2012-02-15. Exceptionally, comments
> may be
> > sent to iesg@ietf.org i= nstead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >    This document describes consideration= s for the transition of end
> user
> >    content on the Internet to IPv6. = ; While this is tailored to
> address
> >    end user content, which is typically = web-based, many aspects of
> this
> >    document may be more broadly applicab= le to the transition to
IPv6
> of
> >    other applications and services. = ; This document explores the
> >    challenges involved in the transition= to IPv6, potential
migration
> >    tactics, possible migration phases, a= nd other considerations.
The
> >    audience for this document is the Int= ernet community generally,
> >    particularly IPv6 implementers.
> >
> >
> >
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-
> whitelisting-impl
> > ications/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-
> whitelisting-impl
> > ications/
> >
> >
> > No IPR declarations have been submitted directly on this I-D= .
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> >
>
> _______________________________________________
> v6ops mailing list
_______________________________________________
v6ops mailing list

--_000_CB695E6D51184jasonlivingoodcablecomcastcom_-- From rbonica@juniper.net Tue Feb 21 11:54:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E9221E8071 for ; Tue, 21 Feb 2012 11:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.517 X-Spam-Level: X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wliJ078rOojR for ; Tue, 21 Feb 2012 11:54:47 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCE321E8088 for ; Tue, 21 Feb 2012 11:54:39 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT0P2QlRADbm9ejMcbx4fJHSDXGvQdt80@postini.com; Tue, 21 Feb 2012 11:54:42 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Feb 2012 11:51:31 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 21 Feb 2012 14:51:04 -0500 From: Ronald Bonica To: "Livingood, Jason" , "EXT - joelja@bogus.com" , Marc Lampo Date: Tue, 21 Feb 2012 14:51:03 -0500 Thread-Topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-Index: AQHM8NFGCTjaobpzcUWNbcVExb7NG5ZHwiJA Message-ID: <13205C286662DE4387D9AF3AC30EF456D7671A2C69@EMBX01-WF.jnpr.net> References: <4F42C1E6.7010606@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456D7671A2C69EMBX01WFjnprn_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 19:54:48 -0000 --_000_13205C286662DE4387D9AF3AC30EF456D7671A2C69EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jason, Please post the most recent version of the draft. If I hear no objections b= y COB Friday, I will send that version on to the RFC editor for publication= . = Ron From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Sent: Tuesday, February 21, 2012 2:45 PM To: EXT - joelja@bogus.com; Marc Lampo; Ronald Bonica Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Info= rmational RFC On 2/20/12 4:57 PM, "Joel jaeggli" > wrote: IMHO the following applies. if you have one zone yeah I agree. If you have two zones one with aaaa and one without (assuming this is done = with dns views style implementation) you can sign both and they'll both be = valid and complete from the vantage point of a client which resolves one or= the other of them but not both. this is a traditional split horizon problem. it's just not inside/outside. Exactly, which is one of the reasons section 4.3.4 is there (Similarities t= o Split DNS). This is two zones (or 'views' of the zone data). Both can be = signed. Jason --_000_13205C286662DE4387D9AF3AC30EF456D7671A2C69EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jason,

&nb= sp;

Please post the most recent= version of the draft. If I hear no objections by COB Friday, I will send t= hat version on to the RFC editor for publication.

 

           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        Ron

 

<= p class=3DMsoNormal>From: Livingood, Jason [mailto:Jason_Livingood@cable.comc= ast.com]
Sent: Tuesday, February 21, 2012 2:45 PM
To: = EXT - joelja@bogus.com; Marc Lampo; Ronald Bonica
Cc: v6ops@ietf.= org
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-= whitelisting-implications-08.txt> (Considerations for Transitioning Cont= ent to IPv6) to Informational RFC

 

On 2/20/12 4:57 PM, "Joel jaeggli" <joelja@bogus.com> wrote:

IMHO= the following applies.

 =

if you have one zone yeah I agree.

 

If you have two zones one with aaaa and one = without (assuming this is done with dns views style implementation) yo= u can sign both and they'll both be valid and complete from the vantag= e point of a client which resolves one or the other of them but not bo= th.

 

this is a = traditional split horizon problem. it's just not inside/outside.=

 

Exactly, which is one of the reasons section 4.3.4 is ther= e (Similarities to Split DNS). This is two zones (or 'views' of the zone da= ta). Both can be signed.

&nbs= p;

Jason

= --_000_13205C286662DE4387D9AF3AC30EF456D7671A2C69EMBX01WFjnprn_-- From jason_livingood@cable.comcast.com Tue Feb 21 11:55:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772FC21E8071 for ; Tue, 21 Feb 2012 11:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=-1.904, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtN8kc3hcQ6Z for ; Tue, 21 Feb 2012 11:55:18 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 0128611E8073 for ; Tue, 21 Feb 2012 11:55:17 -0800 (PST) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.4339730; Tue, 21 Feb 2012 14:49:59 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Tue, 21 Feb 2012 14:54:38 -0500 From: "Livingood, Jason" To: Ronald Bonica , Marc Lampo , "EXT - joelja@bogus.com" , Mark Andrews Thread-Topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-Index: AQHM8NGMkD00gtDZEUSP/1IDM55exZZHw6MA Date: Tue, 21 Feb 2012 19:54:38 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.56.165] Content-Type: multipart/alternative; boundary="_000_CB69602351192jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 19:55:20 -0000 --_000_CB69602351192jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I made this addition in the relevant section (6.1). Let me know if it does = not capture this sufficiently (or does so inelegantly). Thanks Jason In practical terms this means that two separate views or zones are used, ea= ch of which is signed, so that whether or not particular resource records e= xist, the existence or non-existence of the record can still be validated u= sing DNSSEC. On 2/21/12 2:46 PM, "Livingood, Jason" > wrote: Good idea and it is quick & easy edit. Making the change now. Will send tex= t momentarily. Jason On 2/21/12 8:44 AM, "Ronald Bonica" > wrote: Authors, What do you think? Ron -----Original Message----- From: Marc Lampo [mailto:marc.lampo@eurid.eu] Sent: Tuesday, February 21, 2012 2:03 AM To: Ronald Bonica; EXT - joelja@bogus.com Cc: v6ops@ietf.org Subject: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Hello, I had assumed : 1 zone file (and Mark Andrews correctly pointed at "views"). Would adding this piece of information, directly in the RFC, be useful to avoid confusion for future readers ? Thanks and kind regards, Marc Lampo -----Original Message----- From: Ronald Bonica [mailto:rbonica@juniper.net] Sent: 20 February 2012 11:55 PM To: EXT - joelja@bogus.com; Marc Lampo Cc: v6ops@ietf.org Subject: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Marc, Havard, Are you satisfied with the answers provided by Joel and Mark? Ron > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops= -bounces@ietf.org] On Behalf > Of EXT - joelja@bogus.com > Sent: Monday, February 20, 2012 4:58 PM > To: Marc Lampo > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Last Call: implications-08.txt> (Considerations for Transitioning Content to IPv6) > to Informational RFC > > On 2/20/12 06:32 , Marc Lampo wrote: > > Hello, > > > > (sorry to be late with my comments, bit overloaded on my side) > > > > 6.1 Security Considerations - paragraph 2 (on DNSSEC) > > The text states : "there should not be any negative impact on DNSSEC" > > In my opinion, this is *wrong* : > > > > IMHO the following applies. > > if you have one zone yeah I agree. > > If you have two zones one with aaaa and one without (assuming this is > done with dns views style implementation) you can sign both and they'll > both be valid and complete from the vantage point of a client which > resolves one or the other of them but not both. > > this is a traditional split horizon problem. it's just not > inside/outside. > > joel > > > It is correct that, if an AAAA record exists (in a DNSSEC's zone), > > the appropriate RRSIG will be known to authoritative NS's. > > If, via white listing, the decision is taken not to present the AAAA > > record > > (and its signature), this seems OK. > > > > However : not returning an AAAA record seems identical to : there is > no > > AAAA record. > > And that - there is no AAAA record - yields to "Next Secure" changes > ! > > If no AAAA record exists, for a name, the corresponding NSEC (NSEC3) > > record > > should not hold a reference to AAAA. > > But if that AAAA record does exist, the authoritative NS will have > NSEC > > (NSEC3) > > data that shows so. > > > > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but due > to > > whitelisting > > will not be returned), cannot be proven by accompanying (and > required) > > NSEC (NSEC3) > > information. > > Hence : this draft will/might make DNSSEC validating name servers > fail. > > > > > > If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) in > > detail, > > please observe : > > 1) the caching name server (and "stub resolver") ask 2 queries > > (there is only one line, > > but it are two queries : one for "A", one for "AAAA") > > 2) if the caching name server (or stub resolver) performs DNSSEC > > validation, > > it will never accept a reply of "NODATA" to the query of AAAA > > (because the NSEC (NSEC3) information will not prove that > > non-existance) > > ((and the validating name server will repeat the query to all > > authoritative NS's, looking for a validatable answer)) > > > > (the final result, to the user might be that only the A record is > useable > > - mission accomplished ? > > But the side effect will be that validating caching name servers > will hit > > *all* authoritative servers for the domain, > > "in search of" a correctly validating answer.) > > > > So, while for the end-user, the result might be identical, > > one "security impact" of this approach is > > additional (useless) DNS traffic and > > additional load on authoritative NS's (that implement whitelisting) > > > > > > Kind regards, > > > > Marc Lampo > > Security Officer > > EURid > > > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: 01 February 2012 04:09 PM > > To: IETF-Announce > > Cc: v6ops@ietf.org > > Subject: [v6ops] Last Call: > > > > (Considerations for Transitioning Content to IPv6) to Informational > RFC > > > > > > The IESG has received a request from the IPv6 Operations WG (v6ops) > to > > consider the following document: > > - 'Considerations for Transitioning Content to IPv6' > > as an > > Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to > the > > ietf@ietf.org mailing lists by 2012-02-15. Except= ionally, comments > may be > > sent to iesg@ietf.org instead. In either case, pl= ease retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document describes considerations for the transition of end > user > > content on the Internet to IPv6. While this is tailored to > address > > end user content, which is typically web-based, many aspects of > this > > document may be more broadly applicable to the transition to IPv6 > of > > other applications and services. This document explores the > > challenges involved in the transition to IPv6, potential migration > > tactics, possible migration phases, and other considerations. The > > audience for this document is the Internet community generally, > > particularly IPv6 implementers. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > whitelisting-impl > > ications/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > whitelisting-impl > > ications/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_CB69602351192jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5FAD9DB0ACEF6E4D8A4C21DEBB38BEC5@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
I made this addition in the relevant section (6.1). Let me know if it = does not capture this sufficiently (or does so inelegantly). 

Thanks
Jason

In practical terms this means that two separate views or zones are = used, each of which is signed, so that whether or not particular resource r= ecords exist, the existence or non-existence of the record can still be val= idated using DNSSEC. 




On 2/21/12 2:46 PM, "Livingood, Jason" <Jason_Livingood@cable.comcast.com&g= t; wrote:

Good idea= and it is quick & easy edit. Making the change now. Will send text mom= entarily.

Jason

On 2/21/= 12 8:44 AM, "Ronald Bonica" <rbonica@juniper.net> wrote:

Authors,

What do you think?

           &nbs= p;    Ron

-----Original Message-----
From: Marc Lampo [mailto:marc.l= ampo@eurid.eu]
Sent: Tuesday, February 21, 2012 2:03 AM
To: Ronald Bonica; EXT - joelja@bo= gus.com
Subject: RE: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelist= ing-
implications-08.txt> (Considerations for Transitioning Content to I= Pv6)
to Informational RFC
Hello,
I had assumed : 1 zone file (and Mark Andrews correctly pointed at
"views").
Would adding this piece of information, directly in the RFC,
be useful to avoid confusion for future readers ?
Thanks and kind regards,
Marc Lampo
-----Original Message-----
From: Ronald Bonica [mailto:rbo= nica@juniper.net]
Sent: 20 February 2012 11:55 PM
To: EXT - joelja@bogus.com; Ma= rc Lampo
Subject: RE: [v6ops] Last Call:
<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt>
(Considerations for Transitioning Content to IPv6) to Informational RF= C
Marc, Havard,
Are you satisfied with the answers provided by Joel and Mark?
           &nbs= p;            &= nbsp;           &nbs= p; Ron
> -----Original Message-----
Behalf
> Of EXT - joelja@bogus.com=
> Sent: Monday, February 20, 2012 4:58 PM
> To: Marc Lampo
> Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-
whitelisting-
> implications-08.txt> (Considerations for Transitioning Content= to
IPv6)
> to Informational RFC
>
> On 2/20/12 06:32 , Marc Lampo wrote:
> > Hello,
> >
> > (sorry to be late with my comments, bit overloaded on my sid= e)
> >
> > 6.1 Security Considerations - paragraph 2 (on DNSSEC)
> > The text states : "there should not be any negative imp= act on
DNSSEC"
> > In my opinion, this is *wrong* :
> >
>
> IMHO the following applies.
>
> if you have one zone yeah I agree.
>
> If you have two zones one with aaaa and one without (assuming thi= s is
> done with dns views style implementation) you can sign both and
they'll
> both be valid and complete from the vantage point of a client whi= ch
> resolves one or the other of them but not both.
>
> this is a traditional split horizon problem. it's just not
> inside/outside.
>
> joel
>
> > It is correct that, if an AAAA record exists (in a DNSSEC's = zone),
> > the appropriate RRSIG will be known to authoritative NS's.
> > If, via white listing, the decision is taken not to present = the
AAAA
> > record
> > (and its signature), this seems OK.
> >
> > However : not returning an AAAA record seems identical to : = there
is
> no
> > AAAA record.
> > And that - there is no AAAA record - yields to "Next Se= cure"
changes
> !
> > If no AAAA record exists, for a name, the corresponding NSEC=
(NSEC3)
> > record
> > should not hold a reference to AAAA.
> > But if that AAAA record does exist, the authoritative NS wil= l have
> NSEC
> > (NSEC3)
> > data that shows so.
> >
> > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA e= xists but
due
> to
> > whitelisting
> > will not be returned), cannot be proven by accompanying (and=
> required)
> > NSEC (NSEC3)
> > information.
> > Hence : this draft will/might make DNSSEC validating name se= rvers
> fail.
> >
> >
> > If you look at 4.3.1.1 (Description of DNS Resolver Whitelis= ting)
in
> > detail,
> > please observe :
> > 1) the caching name server (and "stub resolver") a= sk 2 queries
> >     (there is only one line,
> >      but it are two queries : = one for "A", one for "AAAA")
> > 2) if the caching name server (or stub resolver) performs DN= SSEC
> > validation,
> >     it will never accept a reply of &quo= t;NODATA" to the query of AAAA
> >     (because the NSEC (NSEC3) informatio= n will not prove that
> > non-existance)
> >     ((and the validating name server wil= l repeat the query to all
> >       authoritative NS's, look= ing for a validatable answer))
> >
> > (the final result, to the user might be that only the A reco= rd is
> useable
> >  - mission accomplished ?
> >  But the side effect will be that validating cachi= ng name servers
> will hit
> >   *all* authoritative servers for the domain,
> >   "in search of" a correctly validating = answer.)
> >
> > So, while for the end-user, the result might be identical,
> > one "security impact" of this approach is
> > additional (useless) DNS traffic and
> > additional load on authoritative NS's (that implement whitel= isting)
> >
> >
> > Kind regards,
> >
> > Marc Lampo
> > Security Officer
> > EURid
> >
> >
> > -----Original Message-----
> > Sent: 01 February 2012 04:09 PM
> > To: IETF-Announce
> > Cc: v6ops@ietf.org
> > Subject: [v6ops] Last Call:
> > <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.tx= t>
> > (Considerations for Transitioning Content to IPv6) to Inform= ational
> RFC
> >
> >
> > The IESG has received a request from the IPv6 Operations WG = (v6ops)
> to
> > consider the following document:
> > - 'Considerations for Transitioning Content to IPv6'
> >   <draft-ietf-v6ops-v6-aaaa-whitelisting-implic= ations-08.txt> as an
> > Informational RFC
> >
> > The IESG plans to make a decision in the next few weeks, and=
solicits
> > final comments on this action. Please send substantive comme= nts to
> the
> > ietf@ietf.org mailing l= ists by 2012-02-15. Exceptionally, comments
> may be
> > sent to iesg@ietf.org i= nstead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >    This document describes consideration= s for the transition of end
> user
> >    content on the Internet to IPv6. = ; While this is tailored to
> address
> >    end user content, which is typically = web-based, many aspects of
> this
> >    document may be more broadly applicab= le to the transition to
IPv6
> of
> >    other applications and services. = ; This document explores the
> >    challenges involved in the transition= to IPv6, potential
migration
> >    tactics, possible migration phases, a= nd other considerations.
The
> >    audience for this document is the Int= ernet community generally,
> >    particularly IPv6 implementers.
> >
> >
> >
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-
> whitelisting-impl
> > ications/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-
> whitelisting-impl
> > ications/
> >
> >
> > No IPR declarations have been submitted directly on this I-D= .
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> >
>
> _______________________________________________
> v6ops mailing list
_______________________________________________
v6ops mailing list

_______________________________________________ v6ops mailing list v6ops@ietf.org = https://www.ietf.org/mailman/listinfo/v6ops
--_000_CB69602351192jasonlivingoodcablecomcastcom_-- From iesg-secretary@ietf.org Tue Feb 21 12:56:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C4621F861F; Tue, 21 Feb 2012 12:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nutQwcZD+0Cb; Tue, 21 Feb 2012 12:56:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9454D21F8648; Tue, 21 Feb 2012 12:56:23 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120221205623.28889.32286.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 12:56:23 -0800 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'IPv6 Multihoming without Network Address Translation' to Informational RFC (draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 20:56:32 -0000 The IESG has approved the following document: - 'IPv6 Multihoming without Network Address Translation' (draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt) as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat/ Technical Summary Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of IPv6 NAT. However, NAT should be avoided, if at all possible, to permit transparent host-to- host connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements for multihoming without the use of NAPT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria. Working Group Summary This was originally posted in May 2010 discussed at IETF-78 in Maastricht, and reported on in IETF-79 at Beijing. The working group requested that it become a working group draft; it was originally posted as draft-ietf-v6ops-multihoming-without-nat66 in December 2010, and reposted as draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat in March 2011. It has in essence been a requirement document feeding into 6MAN and MIF. Related work in those working groups has been proceeding to bring the issues to closure. Document Quality The document describes a network paradigm being used by certain networks in Japan, and describes the issues that prevent them from deployment. As such, its intent and result has been to focus action on the resolution of those problems. Personnel Fred Baker is shepherd. From internet-drafts@ietf.org Tue Feb 21 13:37:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E626321E8085; Tue, 21 Feb 2012 13:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0+sALiHgZDP; Tue, 21 Feb 2012 13:37:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C61B21E807A; Tue, 21 Feb 2012 13:37:02 -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 X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120221213702.10572.90162.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 13:37:02 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 21:37:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Considerations for Transitioning Content to IPv6 Author(s) : Jason Livingood Filename : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-09.txt Pages : 31 Date : 2012-02-21 This document describes considerations for the transition of end user content on the Internet to IPv6. While this is tailored to address end user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-i= mplications-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-im= plications-09.txt From dwing@cisco.com Tue Feb 21 15:49:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF69C21E8059 for ; Tue, 21 Feb 2012 15:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.65 X-Spam-Level: X-Spam-Status: No, score=-108.65 tagged_above=-999 required=5 tests=[AWL=1.949, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 703xRvxt74FN for ; Tue, 21 Feb 2012 15:49:52 -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 80B8721E8033 for ; Tue, 21 Feb 2012 15:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1712; q=dns/txt; s=iport; t=1329868192; x=1331077792; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=ADg6em/3fgGkHkzmvUUzrA+l5idjQB/2IqSJAr+3/Hs=; b=M2Epd95e7vWdxvGW6nXuybGUWm4Hv7eeR6Kc0sVNT0udyQaoEp+bVwHT HpxyIbm89OVmuUJk6reVz6jdS1UKzOZKQO2cds+p0h+C8SNzqKDjIAYEB erLCnLVYFM4M/ncgSWcbdvN3aPQE3RTQs1jaYA1uMXJTROH9ld5glXbAS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIssRE+rRDoJ/2dsb2JhbABEok+Pd4EHgXoICgEXED8NBRhQIxwBBB4Xh2egDgGXLYt2GhIEAQEsAwsDAgEBAYQRJoMeBIhPhQeacA X-IronPort-AV: E=Sophos;i="4.73,460,1325462400"; d="scan'208";a="31655314" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 21 Feb 2012 23:49:52 +0000 Received: from dwingWS ([10.154.160.50]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1LNnqRI027934; Tue, 21 Feb 2012 23:49:52 GMT From: "Dan Wing" To: Date: Tue, 21 Feb 2012 15:49:52 -0800 Message-ID: <021601ccf0f3$812952f0$837bf8d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQ== Content-Language: en-us Cc: draft-ietf-v6ops-6204bis@tools.ietf.org Subject: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 23:49:57 -0000 Reading draft-ietf-v6ops-6204bis-05, I couldn't determine what the CE router should do if, after it acquires an IPv6 prefix from its WAN interface, the WAN interface later goes down. Requirement G-4 in the specification (http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-05#section-4.1) requires the CE router (immediately?) withdraw the prefix on the LAN interface, but if this text (from draft-ietf-v6ops-6204bis-05) is true: 1. Link-local addresses may be insufficient for allowing IPv6 applications to communicate with each other in the end-user network. The IPv6 CE router will need to enable this communication by providing globally scoped unicast addresses or ULAs [RFC4193], whether or not WAN connectivity exists. then withdrawing the globally scoped unicast addresses will break communication within the home. This means if my WAN link goes down, IPv6 streaming between my NAS and my speakers breaks which ruins my dinner party. Can draft-ietf-v6ops-6204bis be more precise describing what happens when the WAN link fails (should the globally scoped prefix be withdrawn on the LAN? Immediately? After several days? What about after a reboot of the CPE?), and can it be more precise to discuss if the CE router has to provide a globally scoped unicast address or has to provide ULA, or has to provide both. As written, devices in the home that rely on the globally-scoped address will fail if the WAN link fails, and it should not be necessary for host and CE router implementers to read the tea leaves of draft-ietf-v6ops-6204bis that ULA is necessary for successful operation of home network equipment when the WAN fails. -d From lorenzo@google.com Tue Feb 21 19:59:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E40C21E8030 for ; Tue, 21 Feb 2012 19:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.656 X-Spam-Level: X-Spam-Status: No, score=-102.656 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CWUYK80Syno for ; Tue, 21 Feb 2012 19:59:47 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E0AB721E800F for ; Tue, 21 Feb 2012 19:59:46 -0800 (PST) Received: by obbwd15 with SMTP id wd15so10870995obb.31 for ; Tue, 21 Feb 2012 19:59:46 -0800 (PST) Received-SPF: pass (google.com: domain of lorenzo@google.com designates 10.182.216.41 as permitted sender) client-ip=10.182.216.41; Authentication-Results: mr.google.com; spf=pass (google.com: domain of lorenzo@google.com designates 10.182.216.41 as permitted sender) smtp.mail=lorenzo@google.com; dkim=pass header.i=lorenzo@google.com Received: from mr.google.com ([10.182.216.41]) by 10.182.216.41 with SMTP id on9mr17652102obc.18.1329883186394 (num_hops = 1); Tue, 21 Feb 2012 19:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=nZIS/mhT+jZS9DLE4u7zSl7taa0j7mvJGqGYwn/pHUY=; b=0a+YbNxMktaDujIZDSVelqVarbTMffqbUt6fgPX7AYuQ72U+FvFev6YL8NPYzNju2R 3RwDoMM//y+Kaejei3aPnBc/R1TSZiqJjGUZPFaZpHGlgMf27sWXafqB/xtiD3XZ1PDk xu/JnuvYLgxx4kX9eBnwz8oJlUEjffadhuQVo= Received: by 10.182.216.41 with SMTP id on9mr14976771obc.18.1329883186350; Tue, 21 Feb 2012 19:59:46 -0800 (PST) Received: by 10.182.216.41 with SMTP id on9mr14976761obc.18.1329883186222; Tue, 21 Feb 2012 19:59:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.5.67 with HTTP; Tue, 21 Feb 2012 19:59:26 -0800 (PST) In-Reply-To: <021601ccf0f3$812952f0$837bf8d0$@com> References: <021601ccf0f3$812952f0$837bf8d0$@com> From: Lorenzo Colitti Date: Wed, 22 Feb 2012 12:59:26 +0900 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=f46d04478a7fe8583304b9858e15 X-System-Of-Record: true X-Gm-Message-State: ALoCoQljzAmtQpSnuLVcoC2Hrl4omxOWD9M+oFjhCDEtqclH8L1Qjx0N41vGu7AjMUu1sYujR7FAu07op8YYiclhKioKijP/a72YR8dccI1vdjPkUIc7cPlyEV+zbd+3ZCIdRW/8QAgi Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 03:59:47 -0000 --f46d04478a7fe8583304b9858e15 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 22, 2012 at 08:49, Dan Wing wrote: > then withdrawing the globally scoped unicast addresses will break > communication within the home. This means if my WAN link goes down, > IPv6 streaming between my NAS and my speakers breaks which ruins my dinner > party. > Losing connectivity on the WAN won't immediately break your stream, since the global addresses will not go away, they'll just be deprecated. (If the outage persists for more than two hours, then yes, it will stop). That said, I would argue that if you're relying on globally-scoped IPv6 addresses expecting that they will never go away, you're Doing It Wrong. It's not just that the WAN link could go down - the ISP could decide to renumber your prefix, or the lease might expire and never be renewed (e.g., if you didn't pay your bill). --f46d04478a7fe8583304b9858e15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 22, 2012 at 08:49, Dan Wing <dwing@cisco.com> wrote:
then withdrawing the globally scoped unicast addresses will break
communication within the home. =A0This means if my WAN link goes down, IPv6= =A0streaming between my NAS and my speakers breaks which ruins my dinner pa= rty.

Losing connectivity on the WAN won= 't immediately break your stream, since the global addresses will not g= o away, they'll just be deprecated. (If the outage persists for more th= an two hours, then yes, it will stop).

That said, I would argue that if you're relyin= g on globally-scoped IPv6 addresses expecting that they will never go away,= you're Doing It Wrong. It's not just that the WAN link could go do= wn - the ISP could decide to renumber your prefix, or the lease might expir= e and never be renewed (e.g., if you didn't pay your bill).
--f46d04478a7fe8583304b9858e15-- From tore.anderson@redpill-linpro.com Wed Feb 22 00:25:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8878E21E8088 for ; Wed, 22 Feb 2012 00:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERff6OUfZQmG for ; Wed, 22 Feb 2012 00:25:37 -0800 (PST) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id E295B21E806D for ; Wed, 22 Feb 2012 00:25:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id B3B47103000B; Wed, 22 Feb 2012 09:25:34 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+AdtkbZUfDQ; Wed, 22 Feb 2012 09:25:33 +0100 (CET) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id A71AB1030006; Wed, 22 Feb 2012 09:25:33 +0100 (CET) Message-ID: <4F44A67D.2070203@redpill-linpro.com> Date: Wed, 22 Feb 2012 09:25:33 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Dan Wing References: <021601ccf0f3$812952f0$837bf8d0$@com> In-Reply-To: <021601ccf0f3$812952f0$837bf8d0$@com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 08:25:42 -0000 * Dan Wing > Reading draft-ietf-v6ops-6204bis-05, I couldn't determine what the CE router > should do if, after it acquires an IPv6 prefix from its WAN interface, the > WAN interface later goes down. Requirement G-4 in the specification > (http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-05#section-4.1) > requires the CE router (immediately?) withdraw the prefix on the LAN > interface Dan, That's not what G-4 (or G-5) says. It says that if the CE router loses its WAN interface (or default route on a still-enabled WAN interface for that matter), it needs to withdraw itself as a *default router* for the nodes connected to the LAN. It does *not* say anything about the prefixes/addresses advertised to the LAN - they should not be impacted by the WAN interface going down, except for the fact that the the DHCPv6-PD lease cannot be renewed, which means that the lifetimes of the lease and the addresses themselves will eventually reach zero. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From despres.remi@laposte.net Wed Feb 22 00:29:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C53921F867E for ; Wed, 22 Feb 2012 00:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.728 X-Spam-Level: X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUwxBO9Huu7X for ; Wed, 22 Feb 2012 00:29:05 -0800 (PST) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 6865A21F8671 for ; Wed, 22 Feb 2012 00:29:01 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8507-out with ME id cwUr1i00637Y3f403wUrC0; Wed, 22 Feb 2012 09:28:59 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <021601ccf0f3$812952f0$837bf8d0$@com> Date: Wed, 22 Feb 2012 09:28:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <86662113-9DC0-405C-986B-9DC979F5FD93@laposte.net> References: <021601ccf0f3$812952f0$837bf8d0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 08:29:06 -0000 Le 2012-02-22 =E0 00:49, Dan Wing a =E9crit : > Reading draft-ietf-v6ops-6204bis-05, I couldn't determine what the CE = router > should do if, after it acquires an IPv6 prefix from its WAN interface, = the > WAN interface later goes down. Requirement G-4 in the specification > (http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-05#section-4.1) > requires the CE router (immediately?) withdraw the prefix on the LAN > interface, but if this text (from draft-ietf-v6ops-6204bis-05) is = true: >=20 > 1. Link-local addresses may be insufficient for allowing IPv6 > applications to communicate with each other in the end-user > network. The IPv6 CE router will need to enable this > communication by providing globally scoped unicast addresses or > ULAs [RFC4193], whether or not WAN connectivity exists. >=20 > then withdrawing the globally scoped unicast addresses will break > communication within the home. This means if my WAN link goes down, = IPv6 > streaming between my NAS and my speakers breaks which ruins my dinner = party. >=20 >=20 > Can draft-ietf-v6ops-6204bis be more precise describing what happens = when > the WAN link fails (should the globally scoped prefix be withdrawn on = the > LAN? Immediately? After several days? What about after a reboot of = the > CPE?), and can it be more precise to discuss if the CE router has to = provide > a globally scoped unicast address or has to provide ULA, or has to = provide > both. As written, devices in the home that rely on the = globally-scoped > address will fail if the WAN link fails, and > it should not be necessary for > host and CE router implementers to read the tea leaves of > draft-ietf-v6ops-6204bis that ULA is necessary for successful = operation of > home network equipment when the WAN fails. +1 If the WAN link fails, its last assigned global prefix can = advantageously be used locally until the link comes back: - If it comes back with the same prefix, great. - If it doesn't, consequences of a prefix change have indeed to be = supported, but for a reason that has no relation to link failure. Now, if an IPv6 LAN starts operation before having any WAN access, any = prefix could work that is never routed to any customer site.=20 It could be fd00::/48 (neither a ULA prefix, nor a publicly routable = prefix, ref the ULA RFC4193). RD >=20 > -d >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From marc.lampo@eurid.eu Wed Feb 22 01:20:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEE121F8961 for ; Wed, 22 Feb 2012 01:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.775 X-Spam-Level: X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VBPE6eqRpRr for ; Wed, 22 Feb 2012 01:20:24 -0800 (PST) Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7511321F8820 for ; Wed, 22 Feb 2012 01:20:19 -0800 (PST) X-ASG-Debug-ID: 1329902616-0369490e9c44770001-b2NLKh Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id tZ7FZEaQyHarByU5; Wed, 22 Feb 2012 10:23:36 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 4E4F2E4075; Wed, 22 Feb 2012 10:20:16 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pdm+1dztMXDL; Wed, 22 Feb 2012 10:20:16 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 379D1E4052; Wed, 22 Feb 2012 10:20:16 +0100 (CET) From: "Marc Lampo" To: "'Livingood, Jason'" , "'Ronald Bonica'" , , "'Mark Andrews'" References: In-Reply-To: Date: Wed, 22 Feb 2012 10:20:16 +0100 (CET) X-ASG-Orig-Subj: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Message-ID: <00e401ccf143$303934a0$90ab9de0$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: AQHM8NGMkD00gtDZEUSP/1IDM55exZZHw6MAgADeEzA= Content-Language: en-za X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1329902616 X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 09:20:27 -0000 Hello, (my time zone implies I see your replies only “the next day”) 1) I assume one cannot, in this RFC, elaborate too much on how “aaaa-whitelisting” can be implemented, so I can live with this sentence (though "view" is a term from the Bind implementation, other implementations might use different wording). 2) regarding the previous sentence : "So even though an authoritative DNS server will selectively return AAAA resource records and/or A resource records, these resource records can certainly still be signed." In this context - assuming we are talking about a signed domain with chain-of-trust appropriately in place - I'd propose : "So even though an authoritative DNS server will selectively return AAAA resource records and/or A resource records, these resource records must be signed, as well as any accompanying NextSecure information that proves existence and/or not-existence of AAAA resource records." So : -> it's a *must* -> it's not only the A and/or AAAA RRs, but also the NSEC/NSEC3 RRs. Kind regards, Marc Lampo Security Officer EURid (for .eu) From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Sent: 21 February 2012 08:55 PM To: Ronald Bonica; Marc Lampo; EXT - joelja@bogus.com; Mark Andrews Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC I made this addition in the relevant section (6.1). Let me know if it does not capture this sufficiently (or does so inelegantly).  Thanks Jason In practical terms this means that two separate views or zones are used, each of which is signed, so that whether or not particular resource records exist, the existence or non-existence of the record can still be validated using DNSSEC.  On 2/21/12 2:46 PM, "Livingood, Jason" wrote: Good idea and it is quick & easy edit. Making the change now. Will send text momentarily. Jason On 2/21/12 8:44 AM, "Ronald Bonica" wrote: Authors, What do you think?                 Ron -----Original Message----- From: Marc Lampo [mailto:marc.lampo@eurid.eu] Sent: Tuesday, February 21, 2012 2:03 AM To: Ronald Bonica; EXT - joelja@bogus.com Cc: v6ops@ietf.org Subject: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Hello, I had assumed : 1 zone file (and Mark Andrews correctly pointed at "views"). Would adding this piece of information, directly in the RFC, be useful to avoid confusion for future readers ? Thanks and kind regards, Marc Lampo -----Original Message----- From: Ronald Bonica [mailto:rbonica@juniper.net] Sent: 20 February 2012 11:55 PM To: EXT - joelja@bogus.com; Marc Lampo Cc: v6ops@ietf.org Subject: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Marc, Havard, Are you satisfied with the answers provided by Joel and Mark?                                       Ron > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of EXT - joelja@bogus.com > Sent: Monday, February 20, 2012 4:58 PM > To: Marc Lampo > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Last Call: implications-08.txt> (Considerations for Transitioning Content to IPv6) > to Informational RFC > > On 2/20/12 06:32 , Marc Lampo wrote: > > Hello, > > > > (sorry to be late with my comments, bit overloaded on my side) > > > > 6.1 Security Considerations - paragraph 2 (on DNSSEC) > > The text states : "there should not be any negative impact on DNSSEC" > > In my opinion, this is *wrong* : > > > > IMHO the following applies. > > if you have one zone yeah I agree. > > If you have two zones one with aaaa and one without (assuming this is > done with dns views style implementation) you can sign both and they'll > both be valid and complete from the vantage point of a client which > resolves one or the other of them but not both. > > this is a traditional split horizon problem. it's just not > inside/outside. > > joel > > > It is correct that, if an AAAA record exists (in a DNSSEC's zone), > > the appropriate RRSIG will be known to authoritative NS's. > > If, via white listing, the decision is taken not to present the AAAA > > record > > (and its signature), this seems OK. > > > > However : not returning an AAAA record seems identical to : there is > no > > AAAA record. > > And that - there is no AAAA record - yields to "Next Secure" changes > ! > > If no AAAA record exists, for a name, the corresponding NSEC (NSEC3) > > record > > should not hold a reference to AAAA. > > But if that AAAA record does exist, the authoritative NS will have > NSEC > > (NSEC3) > > data that shows so. > > > > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but due > to > > whitelisting > > will not be returned), cannot be proven by accompanying (and > required) > > NSEC (NSEC3) > > information. > > Hence : this draft will/might make DNSSEC validating name servers > fail. > > > > > > If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) in > > detail, > > please observe : > > 1) the caching name server (and "stub resolver") ask 2 queries > >     (there is only one line, > >      but it are two queries : one for "A", one for "AAAA") > > 2) if the caching name server (or stub resolver) performs DNSSEC > > validation, > >     it will never accept a reply of "NODATA" to the query of AAAA > >     (because the NSEC (NSEC3) information will not prove that > > non-existance) > >     ((and the validating name server will repeat the query to all > >       authoritative NS's, looking for a validatable answer)) > > > > (the final result, to the user might be that only the A record is > useable > >  - mission accomplished ? > >  But the side effect will be that validating caching name servers > will hit > >   *all* authoritative servers for the domain, > >   "in search of" a correctly validating answer.) > > > > So, while for the end-user, the result might be identical, > > one "security impact" of this approach is > > additional (useless) DNS traffic and > > additional load on authoritative NS's (that implement whitelisting) > > > > > > Kind regards, > > > > Marc Lampo > > Security Officer > > EURid > > > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: 01 February 2012 04:09 PM > > To: IETF-Announce > > Cc: v6ops@ietf.org > > Subject: [v6ops] Last Call: > > > > (Considerations for Transitioning Content to IPv6) to Informational > RFC > > > > > > The IESG has received a request from the IPv6 Operations WG (v6ops) > to > > consider the following document: > > - 'Considerations for Transitioning Content to IPv6' > >   as an > > Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to > the > > ietf@ietf.org mailing lists by 2012-02-15. 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 describes considerations for the transition of end > user > >    content on the Internet to IPv6.  While this is tailored to > address > >    end user content, which is typically web-based, many aspects of > this > >    document may be more broadly applicable to the transition to IPv6 > of > >    other applications and services.  This document explores the > >    challenges involved in the transition to IPv6, potential migration > >    tactics, possible migration phases, and other considerations. The > >    audience for this document is the Internet community generally, > >    particularly IPv6 implementers. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > whitelisting-impl > > ications/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > whitelisting-impl > > ications/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Wed Feb 22 01:58:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD8B21F896F for ; Wed, 22 Feb 2012 01:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.064 X-Spam-Level: X-Spam-Status: No, score=-7.064 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+FEhguyFFn1 for ; Wed, 22 Feb 2012 01:58:18 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C46F321F85FB for ; Wed, 22 Feb 2012 01:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=6358; q=dns/txt; s=iport; t=1329904698; x=1331114298; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=rCMrdiggwXYPM3VpIBgXLbDfJFze0Q2CdKjLmZdd1Ds=; b=AmkN9qNvo5yNiUp5yQ6ZdjlYny0NmJVwDJEPGqt6rA557goTRJWUxhqO jr/wxuEKYbeHtwD3IvYLtIpma9g8JY0MqZ+VlMBqKOJ22LmD6EBbkMt3C ko5MZFzLxyL65m9UlMeUjyh/BcwbTr6j1fOTi2LAuRGNlFtA3VLB6PwzE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgJAEW7RE+tJXG//2dsb2JhbABEhSykJQGIHnUCgQeBdAEBBAEBAQ8BEEsLEAIBCEICAgIlMAEBBBMih2ifcgGMZYpKjEw4AQI3HQqEURkjRwwEAggSgiYzYwSIHDOMaZML X-IronPort-AV: E=Sophos;i="4.73,463,1325462400"; d="scan'208,217";a="60875670" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 22 Feb 2012 09:58:18 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1M9wIa3002551; Wed, 22 Feb 2012 09:58:18 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 03:58:18 -0600 Received: from 72.163.63.13 ([72.163.63.13]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Feb 2012 09:58:17 +0000 References: <021601ccf0f3$812952f0$837bf8d0$@com> <4F44A67D.2070203@redpill-linpro.com> Content-Transfer-Encoding: 7bit From: "Rajiv Asati (rajiva)" Content-Type: multipart/alternative; boundary="Apple-Mail-13BA599D-5AB7-47A6-99BE-10132557CBC3"; charset="iso-8859-1" thread-topic: [v6ops] 6204bis and WAN disappearing In-Reply-To: <4F44A67D.2070203@redpill-linpro.com> thread-index: AczxSH/llDecLU9WSvehuGkrVOMgcw== Message-ID: <5E8BCCE6-E48A-4D67-BB4C-3CD7AD029BAD@cisco.com> Date: Wed, 22 Feb 2012 04:58:13 -0500 To: "Tore Anderson" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 22 Feb 2012 09:58:18.0287 (UTC) FILETIME=[808263F0:01CCF148] Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 09:58:20 -0000 --Apple-Mail-13BA599D-5AB7-47A6-99BE-10132557CBC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree. Separately, shouldn't G3 also say prefix acquisition ? G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between its LAN i= nterface(s) and its WAN interface until the router has successfully complete= d the IPv6 address acquisition process. Cheers, Rajiv Sent from my Phone On Feb 22, 2012, at 3:25 AM, "Tore Anderson" wrote: > * Dan Wing >=20 >> Reading draft-ietf-v6ops-6204bis-05, I couldn't determine what the CE rou= ter >> should do if, after it acquires an IPv6 prefix from its WAN interface, th= e >> WAN interface later goes down. Requirement G-4 in the specification >> (http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-05#section-4.1) >> requires the CE router (immediately?) withdraw the prefix on the LAN >> interface >=20 > Dan, >=20 > That's not what G-4 (or G-5) says. It says that if the CE router loses > its WAN interface (or default route on a still-enabled WAN interface for > that matter), it needs to withdraw itself as a *default router* for the > nodes connected to the LAN. >=20 > It does *not* say anything about the prefixes/addresses advertised to > the LAN - they should not be impacted by the WAN interface going down, > except for the fact that the the DHCPv6-PD lease cannot be renewed, > which means that the lifetimes of the lease and the addresses themselves > will eventually reach zero. >=20 > --=20 > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-13BA599D-5AB7-47A6-99BE-10132557CBC3 Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+SSBhZ3JlZS4g U2VwYXJhdGVseSwgc2hvdWxkbid0IEczIGFsc28gc2F5IHByZWZpeCBhY3F1aXNpdGlvbiA/PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj4mbmJzcDsgICBHLTM6ICBUaGUgSVB2NiBDRSByb3V0ZXIg TVVTVCBOT1QgZm9yd2FyZCBhbnkgSVB2NiB0cmFmZmljIGJldHdlZW4mbmJzcDs8c3BhbiBjbGFz cz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9Ii13ZWJraXQtdGFwLWhpZ2hsaWdodC1jb2xvcjog cmdiYSgyNiwgMjYsIDI2LCAwLjI5Njg3NSk7IC13ZWJraXQtY29tcG9zaXRpb24tZmlsbC1jb2xv cjogcmdiYSgxNzUsIDE5MiwgMjI3LCAwLjIzMDQ2OSk7IC13ZWJraXQtY29tcG9zaXRpb24tZnJh bWUtY29sb3I6IHJnYmEoNzcsIDEyOCwgMTgwLCAwLjIzMDQ2OSk7ICI+aXRzIExBTiBpbnRlcmZh Y2UocykgYW5kIGl0cyBXQU4gaW50ZXJmYWNlIHVudGlsIHRoZSByb3V0ZXIgaGFzDQogICAgICAg ICBzdWNjZXNzZnVsbHkgY29tcGxldGVkIHRoZSBJUHY2IGFkZHJlc3MgYWNxdWlzaXRpb24gcHJv Y2Vzcy48L3NwYW4+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IFRpbWVzOyBmb250LXNpemU6IG1l ZGl1bTsgLXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMjky OTY5KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1maWxsLWNvbG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcs IDAuMjMwNDY5KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1mcmFtZS1jb2xvcjogcmdiYSg3NywgMTI4 LCAxODAsIDAuMjMwNDY5KTsgIj48YnI+PC9kaXY+PGJyPkNoZWVycyw8ZGl2PlJhaml2PC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj5TZW50IGZyb20gbXkgUGhvbmU8L2Rpdj48L2Rpdj48ZGl2Pjxi cj5PbiBGZWIgMjIsIDIwMTIsIGF0IDM6MjUgQU0sICJUb3JlIEFuZGVyc29uIiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRvcmUuYW5kZXJzb25AcmVkcGlsbC1saW5wcm8uY29tIj50b3JlLmFuZGVyc29u QHJlZHBpbGwtbGlucHJvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGRpdj48L2Rp dj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPiogRGFuIFdpbmc8L3NwYW4+PGJy PjxzcGFuPjwvc3Bhbj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+UmVhZGluZyBk cmFmdC1pZXRmLXY2b3BzLTYyMDRiaXMtMDUsIEkgY291bGRuJ3QgZGV0ZXJtaW5lIHdoYXQgdGhl IENFIHJvdXRlcjwvc3Bhbj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuPnNob3VsZCBkbyBpZiwgYWZ0ZXIgaXQgYWNxdWlyZXMgYW4gSVB2NiBwcmVmaXggZnJv bSBpdHMgV0FOIGludGVyZmFjZSwgdGhlPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PHNwYW4+V0FOIGludGVyZmFjZSBsYXRlciBnb2VzIGRvd24uICZuYnNw O1JlcXVpcmVtZW50IEctNCBpbiB0aGUgc3BlY2lmaWNhdGlvbjwvc3Bhbj48YnI+PC9ibG9ja3F1 b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPig8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLTYyMDRiaXMtMDUjc2VjdGlvbi00LjEiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtNjIwNGJpcy0wNSNzZWN0 aW9uLTQuMTwvYT4pPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PHNwYW4+cmVxdWlyZXMgdGhlIENFIHJvdXRlciAoaW1tZWRpYXRlbHk/KSB3aXRoZHJhdyB0 aGUgcHJlZml4IG9uIHRoZSBMQU48L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48c3Bhbj5pbnRlcmZhY2U8L3NwYW4+PGJyPjwvYmxvY2txdW90ZT48c3Bhbj48 L3NwYW4+PGJyPjxzcGFuPkRhbiw8L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+VGhh dCdzIG5vdCB3aGF0IEctNCAob3IgRy01KSBzYXlzLiBJdCBzYXlzIHRoYXQgaWYgdGhlIENFIHJv dXRlciBsb3Nlczwvc3Bhbj48YnI+PHNwYW4+aXRzIFdBTiBpbnRlcmZhY2UgKG9yIGRlZmF1bHQg cm91dGUgb24gYSBzdGlsbC1lbmFibGVkIFdBTiBpbnRlcmZhY2UgZm9yPC9zcGFuPjxicj48c3Bh bj50aGF0IG1hdHRlciksIGl0IG5lZWRzIHRvIHdpdGhkcmF3IGl0c2VsZiBhcyBhICpkZWZhdWx0 IHJvdXRlciogZm9yIHRoZTwvc3Bhbj48YnI+PHNwYW4+bm9kZXMgY29ubmVjdGVkIHRvIHRoZSBM QU4uPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPkl0IGRvZXMgKm5vdCogc2F5IGFu eXRoaW5nIGFib3V0IHRoZSBwcmVmaXhlcy9hZGRyZXNzZXMgYWR2ZXJ0aXNlZCB0bzwvc3Bhbj48 YnI+PHNwYW4+dGhlIExBTiAtIHRoZXkgc2hvdWxkIG5vdCBiZSBpbXBhY3RlZCBieSB0aGUgV0FO IGludGVyZmFjZSBnb2luZyBkb3duLDwvc3Bhbj48YnI+PHNwYW4+ZXhjZXB0IGZvciB0aGUgZmFj dCB0aGF0IHRoZSB0aGUgREhDUHY2LVBEIGxlYXNlIGNhbm5vdCBiZSByZW5ld2VkLDwvc3Bhbj48 YnI+PHNwYW4+d2hpY2ggbWVhbnMgdGhhdCB0aGUgbGlmZXRpbWVzIG9mIHRoZSBsZWFzZSBhbmQg dGhlIGFkZHJlc3NlcyB0aGVtc2VsdmVzPC9zcGFuPjxicj48c3Bhbj53aWxsIGV2ZW50dWFsbHkg cmVhY2ggemVyby48L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+LS0gPC9zcGFuPjxi cj48c3Bhbj5Ub3JlIEFuZGVyc29uPC9zcGFuPjxicj48c3Bhbj5SZWRwaWxsIExpbnBybyBBUyAt IDxhIGhyZWY9Imh0dHA6Ly93d3cucmVkcGlsbC1saW5wcm8uY29tIj5odHRwOi8vd3d3LnJlZHBp bGwtbGlucHJvLmNvbTwvYT48L3NwYW4+PGJyPjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj48c3Bhbj52Nm9wcyBtYWlsaW5nIGxp c3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNA aWV0Zi5vcmc8L2E+PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Y2b3BzPC9hPjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0 bWw+ --Apple-Mail-13BA599D-5AB7-47A6-99BE-10132557CBC3-- From despres.remi@laposte.net Wed Feb 22 02:40:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C7321F896F for ; Wed, 22 Feb 2012 02:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rvRTDeRGr3T for ; Wed, 22 Feb 2012 02:40:24 -0800 (PST) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABC221F896D for ; Wed, 22 Feb 2012 02:40:23 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id cygK1i00P37Y3f403ygKig; Wed, 22 Feb 2012 11:40:22 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 22 Feb 2012 11:40:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <190FFDFA-2901-437A-BFBF-E598F56A6120@laposte.net> References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 10:40:25 -0000 Cameron, It seems we are close to common understanding. More below.=20 Le 2012-02-21 =E0 20:34, Cameron Byrne a =E9crit : ... > On Tue, Feb 21, 2012 at 10:42 AM, R=E9mi Despr=E9s = wrote: ... >>>> Aren't NAT64s always coupled with DNS64s, as seems to be implied by = all scenarios of RFC6144? >>=20 >> An answer to this? >>=20 >=20 > Sorry i missed this earlier. >=20 > In the case for RFC6144 to replace NAT-PT functionality, yes a DNS64 > and NAT64 must be coupled to replace NAT-PT functions. >=20 > But, RFC6146 and RFC6147 stand on their own. There is no explicit > coupling required or shared state between NAT64 and DNS64 for them to > perform their atomic functions. Meaning, any conforming packet > (Pref64+32bit IPv4 destination address) may be received by an RFC6146 > stateful NAT64 and be translated. A properly configured CLAT that > knows the Pref64 may received IPv4 packets and translate them via > RFC6145 to a PLAT without any queries or interactions with the DNS64. I don't think a NAT64 that wouldn't work for IPv6-only hosts is a = scenario that needs to be mentioned, especially since it contradicts an = existing RFC. IMHO, stating that, with a CE architecture like that of the 464XLAT = draft, a stateless CE can work with a stateful NAT64 is enough. Adding that it can work without DNS64 is AFAIK at best unnecessary, at = worst confusing. That could advantageously be deleted (IMHO).=20 =20 ... >>>>>> Why, then, say "In the best case, the CLAT will have a dedicated = /64" >>>>>>=20 >>>>>=20 >>>>> It just seems cleaner to me to have a dedicated /64 if it is >>>>> available. Operationally, aside from the NDP claiming the /96, = there >>>>> is no difference to have dedicated or not dedicated. >>>>=20 >>>> Understood, but: >>>> - Claiming a /96 on a link seems new to me (is there an existing = reference?) >>>=20 >>> It does not need to claim the /96 as a whole. The CLAT will do NDP >>> with the idea that each /128 in the /96 is owned by the CLAT as a >>> virtual address. >>=20 >> Was understood. >>=20 >>> I have seen this behavior in NAT-PT deployments, but i do not see it >>> specifically declared in the NAT-PT RFC. >>=20 >> Right, it seems to be new material as far as IETF is concerned. >>=20 >=20 > NDP for a host address should not be new material. =20 Nothing is new in your proposal for hosts, right, but NDP operation IS = modified in CE routers.=20 > As i mentioned > before, we can treat each address in the /96 as a host address on the > CLAT, and the interactions are normal for NDP host addresses. Understood.=20 The fact that this is new in the router CE is not a problem AFAIAC, but = provided new pieces of design are clearly identified. > Alternatively, we may view the CLAT in terms of proxy NDP > http://tools.ietf.org/html/rfc4861#section-7.2.8 Doesn't this require support of RFC3810 (Multicast Listener Discovery = Version 2 (MLDv2) for IPv6)? That could be part of the specification, but would AFAIK would be a = constraint.=20 > The CLAT is willing to accept packet destine to the /96 on behalf of > the IPv4 internet, and the NDP actions are defined as existing Proxy > NDP. >=20 > Thoughts on one verse the other? My thought is that BOTH can be AVOIDED. It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix that = differs from all valid native IPv6 prefixes. This is easy to have, and is part of the 4rd-U proposal. The architecture you propose can easily benefit from it, simply by = adding its scenario as a particular one of the 4rd-U general scheme.=20 >> I think I understand your motivations, and hope you can understand = those of draft-ietf-softwire-stateless-4v6-motivation. >>=20 >=20 > Yes, and thanks again for your careful review and attention to the = 464XLAT draft I confirm that IMHO your draft brings quite useful new material. If you can take time to look at = http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03, my hope is = that you will understand that coordination between its contents and that = of your draft should be useful. Regards, RD=20 >=20 > CB >=20 >> Regards, >> RD >>=20 >>=20 >>=20 From he@uninett.no Wed Feb 22 03:58:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECD021F8890 for ; Wed, 22 Feb 2012 03:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4oftuIqkyYZ for ; Wed, 22 Feb 2012 03:58:06 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 3838421F8881 for ; Wed, 22 Feb 2012 03:58:06 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id BE9463D0B5; Wed, 22 Feb 2012 12:58:03 +0100 (CET) Date: Wed, 22 Feb 2012 12:58:03 +0100 (CET) Message-Id: <20120222.125803.195585131.he@uninett.no> To: marka@isc.org From: Havard Eidnes In-Reply-To: <20120220204842.556861DA0095@drugs.dv.isc.org> References: <13205C286662DE4387D9AF3AC30EF456D7671A210C@EMBX01-WF.jnpr.net> <20120220.170216.446120856.he@uninett.no> <20120220204842.556861DA0095@drugs.dv.isc.org> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marc.lampo@eurid.eu, v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 11:58:07 -0000 > One can whitelist with DNSSEC at the source. I stand corrected, thanks. Regards, - H=E5vard From he@uninett.no Wed Feb 22 04:05:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9707B21F8769 for ; Wed, 22 Feb 2012 04:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEsvNQ5w+HBA for ; Wed, 22 Feb 2012 04:05:32 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id B598C21F8760 for ; Wed, 22 Feb 2012 04:05:31 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 76F713D0B4; Wed, 22 Feb 2012 13:05:30 +0100 (CET) Date: Wed, 22 Feb 2012 13:05:30 +0100 (CET) Message-Id: <20120222.130530.244797321.he@uninett.no> To: rbonica@juniper.net From: Havard Eidnes In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D7671A227B@EMBX01-WF.jnpr.net> References: <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> <4F42C1E6.7010606@bogus.com> <13205C286662DE4387D9AF3AC30EF456D7671A227B@EMBX01-WF.jnpr.net> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: marc.lampo@eurid.eu, v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 12:05:32 -0000 > Marc, Havard, > > Are you satisfied with the answers provided by Joel and Mark? I am. Regards, - H=E5vard From bs7652@att.com Wed Feb 22 05:55:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD5921F8758 for ; Wed, 22 Feb 2012 05:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfbscg8ZhJMl for ; Wed, 22 Feb 2012 05:55:13 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id B247521F874F for ; Wed, 22 Feb 2012 05:55:13 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1329918910!64835730!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28997 invoked from network); 22 Feb 2012 13:55:11 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Feb 2012 13:55:11 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1MDrcHj008517; Wed, 22 Feb 2012 08:53:38 -0500 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1MDrV2V008260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 08:53:31 -0500 Received: from GAALPA1MSGHUB9B.ITServices.sbc.com (gaalpa1msghub9b.itservices.sbc.com [130.8.36.88]) by sflint03.pst.cso.att.com (RSA Interceptor); Wed, 22 Feb 2012 08:54:54 -0500 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.249]) by GAALPA1MSGHUB9B.ITServices.sbc.com ([130.8.36.88]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 08:54:53 -0500 From: "STARK, BARBARA H" To: Tore Anderson , Dan Wing Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAcfMqAAADK0NA= Date: Wed, 22 Feb 2012 13:54:52 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611042179@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <021601ccf0f3$812952f0$837bf8d0$@com> <4F44A67D.2070203@redpill-linpro.com> In-Reply-To: <4F44A67D.2070203@redpill-linpro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.164.202.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 13:55:17 -0000 > * Dan Wing >=20 > > Reading draft-ietf-v6ops-6204bis-05, I couldn't determine what the CE > router > > should do if, after it acquires an IPv6 prefix from its WAN > interface, the > > WAN interface later goes down. Requirement G-4 in the specification > > (http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-05#section-4.1) > > requires the CE router (immediately?) withdraw the prefix on the LAN > > interface >=20 > Dan, >=20 > That's not what G-4 (or G-5) says. It says that if the CE router loses > its WAN interface (or default route on a still-enabled WAN interface > for that matter), it needs to withdraw itself as a *default router* for t= he > nodes connected to the LAN. >=20 > It does *not* say anything about the prefixes/addresses advertised to > the LAN - they should not be impacted by the WAN interface going down, > except for the fact that the the DHCPv6-PD lease cannot be renewed, > which means that the lifetimes of the lease and the addresses > themselves will eventually reach zero. >=20 > -- > Tore Anderson I agree with what Tore says the draft says. That's definitely what I unders= tood it to say. Barbara From twinters@iol.unh.edu Wed Feb 22 06:06:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D96B21F8693 for ; Wed, 22 Feb 2012 06:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9MpfQQk3UEY for ; Wed, 22 Feb 2012 06:06:01 -0800 (PST) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with SMTP id CCA4821F8690 for ; Wed, 22 Feb 2012 06:05:42 -0800 (PST) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKT0T2NUACrXmvAeCMcI7/X0TgAHX4+6r+@postini.com; Wed, 22 Feb 2012 06:06:01 PST Received: from optimus.iol.unh.edu (optimus.iol.unh.edu [132.177.118.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id 521348F0067; Wed, 22 Feb 2012 09:05:40 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Timothy Winters In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611042179@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Wed, 22 Feb 2012 09:05:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <348ECA23-D21C-4F10-BB28-708CE3B86249@iol.unh.edu> References: <021601ccf0f3$812952f0$837bf8d0$@com> <4F44A67D.2070203@redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E611042179@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1257) Cc: "draft-ietf-v6ops-6204bis@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 14:06:11 -0000 Hello, The CE Routers that have participated in the IPv6 CE Events have = implemented Tore/Barbara have stated. The CE Routers transmit an RA = with a lifetime 0 but don't withdraw prefixes. Regards, Tim On Feb 22, 2012, at 8:54 AM, STARK, BARBARA H wrote: >=20 >> * Dan Wing >>=20 >>> Reading draft-ietf-v6ops-6204bis-05, I couldn't determine what the = CE >> router >>> should do if, after it acquires an IPv6 prefix from its WAN >> interface, the >>> WAN interface later goes down. Requirement G-4 in the specification >>> (http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-05#section-4.1) >>> requires the CE router (immediately?) withdraw the prefix on the LAN >>> interface >>=20 >> Dan, >>=20 >> That's not what G-4 (or G-5) says. It says that if the CE router = loses >> its WAN interface (or default route on a still-enabled WAN interface >> for that matter), it needs to withdraw itself as a *default router* = for the >> nodes connected to the LAN. >>=20 >> It does *not* say anything about the prefixes/addresses advertised to >> the LAN - they should not be impacted by the WAN interface going = down, >> except for the fact that the the DHCPv6-PD lease cannot be renewed, >> which means that the lifetimes of the lease and the addresses >> themselves will eventually reach zero. >>=20 >> -- >> Tore Anderson >=20 > I agree with what Tore says the draft says. That's definitely what I = understood it to say. > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Wed Feb 22 06:11:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E956921F859A for ; Wed, 22 Feb 2012 06:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.619 X-Spam-Level: X-Spam-Status: No, score=-8.619 tagged_above=-999 required=5 tests=[AWL=1.080, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4MivpR7dSwC for ; Wed, 22 Feb 2012 06:11:20 -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 E4CD521F85EE for ; Wed, 22 Feb 2012 06:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5421; q=dns/txt; s=iport; t=1329919879; x=1331129479; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=y+9QBfS6cR1LPA60BmK0q14rGusuz+n/Qey4tgT6Vxc=; b=Oea1nXAiOrqqIPmEnzztwX9vlXt0+FoDAcugO749XJ1rFY1kVq85m/vD tv0lE2k5+XFAMEF4f+B96/9xIpvgQlui6c93wa2hm81VClDEX6fc5fT8h UC0QeV0exhSmGb/zBbjfgaIMv7gakWa5NgxQgMGa/K0kqAmBM8G3+l0A8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHv2RE+tJV2a/2dsb2JhbABEsmqBB4FzAQEBAwEBAQEPAR0+CwwEAgEIEQEDAQEBCgYXAQYBJh8DBggBAQQBEggah18Jn3YBlx+JV4JwBgMBBgEBAQIJAQECAwEJBgEBBT4KEIVeDAYIEgyCTWMEiBwzn3WBNA X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="60933457" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 22 Feb 2012 14:10:59 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1MEAxiG018408; Wed, 22 Feb 2012 14:10:59 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 08:10:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Feb 2012 08:10:59 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0778D46C@XMB-RCD-111.cisco.com> In-Reply-To: <190FFDFA-2901-437A-BFBF-E598F56A6120@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe an ietf-v6ops I.D. Thread-Index: AczxTnpv2p2+O1vhQHSI+Jjutr5MUwABBjIw References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net><36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net><76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> <190FFDFA-2901-437A-BFBF-E598F56A6120@laposte.net> From: "Rajiv Asati (rajiva)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Cameron Byrne" X-OriginalArrivalTime: 22 Feb 2012 14:10:59.0691 (UTC) FILETIME=[CD690BB0:01CCF16B] Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 14:11:25 -0000 > > Alternatively, we may view the CLAT in terms of proxy NDP I think that pNDP is unnecessary. NDP is good enough here.=20 Also, when we move to using DHCP-PD, then NDP on WAN int will not be = necessary either. > > NDP for a host address should not be new material. >=20 > Nothing is new in your proposal for hosts, right, but NDP operation IS = modified > in CE routers. Remi, what is modified in your view? Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of > R=E9mi Despr=E9s > Sent: Wednesday, February 22, 2012 5:40 AM > To: Cameron Byrne > Cc: v6ops WG; Russell Housley > Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - = not tobe an > ietf-v6ops I.D. >=20 > Cameron, > It seems we are close to common understanding. > More below. >=20 > Le 2012-02-21 =E0 20:34, Cameron Byrne a =E9crit : > ... > > On Tue, Feb 21, 2012 at 10:42 AM, R=E9mi Despr=E9s > wrote: > ... > >>>> Aren't NAT64s always coupled with DNS64s, as seems to be implied = by all > scenarios of RFC6144? > >> > >> An answer to this? > >> > > > > Sorry i missed this earlier. > > > > In the case for RFC6144 to replace NAT-PT functionality, yes a DNS64 > > and NAT64 must be coupled to replace NAT-PT functions. > > > > But, RFC6146 and RFC6147 stand on their own. There is no explicit > > coupling required or shared state between NAT64 and DNS64 for them = to > > perform their atomic functions. Meaning, any conforming packet > > (Pref64+32bit IPv4 destination address) may be received by an = RFC6146 > > stateful NAT64 and be translated. A properly configured CLAT that > > knows the Pref64 may received IPv4 packets and translate them via > > RFC6145 to a PLAT without any queries or interactions with the = DNS64. >=20 > I don't think a NAT64 that wouldn't work for IPv6-only hosts is a = scenario that > needs to be mentioned, especially since it contradicts an existing = RFC. > IMHO, stating that, with a CE architecture like that of the 464XLAT = draft, a > stateless CE can work with a stateful NAT64 is enough. > Adding that it can work without DNS64 is AFAIK at best unnecessary, at = worst > confusing. > That could advantageously be deleted (IMHO). >=20 > ... > >>>>>> Why, then, say "In the best case, the CLAT will have a = dedicated /64" > >>>>>> > >>>>> > >>>>> It just seems cleaner to me to have a dedicated /64 if it is > >>>>> available. Operationally, aside from the NDP claiming the /96, = there > >>>>> is no difference to have dedicated or not dedicated. > >>>> > >>>> Understood, but: > >>>> - Claiming a /96 on a link seems new to me (is there an existing > reference?) > >>> > >>> It does not need to claim the /96 as a whole. The CLAT will do = NDP > >>> with the idea that each /128 in the /96 is owned by the CLAT as a > >>> virtual address. > >> > >> Was understood. > >> > >>> I have seen this behavior in NAT-PT deployments, but i do not see = it > >>> specifically declared in the NAT-PT RFC. > >> > >> Right, it seems to be new material as far as IETF is concerned. > >> > > > > NDP for a host address should not be new material. >=20 > Nothing is new in your proposal for hosts, right, but NDP operation IS = modified > in CE routers. >=20 > > As i mentioned > > before, we can treat each address in the /96 as a host address on = the > > CLAT, and the interactions are normal for NDP host addresses. >=20 > Understood. > The fact that this is new in the router CE is not a problem AFAIAC, = but provided > new pieces of design are clearly identified. >=20 > > Alternatively, we may view the CLAT in terms of proxy NDP > > http://tools.ietf.org/html/rfc4861#section-7.2.8 >=20 > Doesn't this require support of RFC3810 (Multicast Listener Discovery = Version 2 > (MLDv2) for IPv6)? > That could be part of the specification, but would AFAIK would be a = constraint. >=20 > > The CLAT is willing to accept packet destine to the /96 on behalf of > > the IPv4 internet, and the NDP actions are defined as existing Proxy > > NDP. > > > > Thoughts on one verse the other? >=20 > My thought is that BOTH can be AVOIDED. > It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix = that differs from all > valid native IPv6 prefixes. > This is easy to have, and is part of the 4rd-U proposal. > The architecture you propose can easily benefit from it, simply by = adding its > scenario as a particular one of the 4rd-U general scheme. >=20 > >> I think I understand your motivations, and hope you can understand = those of > draft-ietf-softwire-stateless-4v6-motivation. > >> > > > > Yes, and thanks again for your careful review and attention to the = 464XLAT > draft >=20 > I confirm that IMHO your draft brings quite useful new material. >=20 > If you can take time to look at = http://tools.ietf.org/html/draft-despres-softwire- > 4rd-u-03, my hope is that you will understand that coordination = between its > contents and that of your draft should be useful. >=20 > Regards, > RD >=20 >=20 >=20 >=20 > > > > CB > > > >> Regards, > >> RD > >> > >> > >> >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Wed Feb 22 07:03:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50A921F880C for ; Wed, 22 Feb 2012 07:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eyzjq4G0Acy4 for ; Wed, 22 Feb 2012 07:03:42 -0800 (PST) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 7C93521F87DF for ; Wed, 22 Feb 2012 07:03:41 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id d33e1i00C37Y3f40333exT; Wed, 22 Feb 2012 16:03:39 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0778D46C@XMB-RCD-111.cisco.com> Date: Wed, 22 Feb 2012 16:03:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <592C29F3-56B0-4319-BD94-B1A520CF2A5E@laposte.net> References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net><36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net><76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> <190FFDFA-2901-437A-BFBF-E598F56A6120@laposte.net> <067E6CE33034954AAC05C9EC85E2577C0778D46C@XMB-RCD-111.cisco.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1084) Cc: Russell Housley , v6ops WG Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 15:03:46 -0000 Le 2012-02-22 =E0 15:10, Rajiv Asati (rajiva) a =E9crit : >>> Alternatively, we may view the CLAT in terms of proxy NDP >=20 > I think that pNDP is unnecessary. NDP is good enough here.=20 >=20 > Also, when we move to using DHCP-PD, then NDP on WAN int will not be = necessary either. >=20 >>> NDP for a host address should not be new material. >> Nothing is new in your proposal for hosts, right, but NDP operation = IS modified >> in CE routers. >=20 > Remi, what is modified in your view? Compliance with the 464XLAT draft requires specific code that none of = the referenced RFCs specifies. This code is to prevent other LAN hosts not only to avoid the router's = address, as usual, BUT all addresses starting with the chosen /95.=20 Cheers, RD >=20 > Cheers, > Rajiv >=20 >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >> R=E9mi Despr=E9s >> Sent: Wednesday, February 22, 2012 5:40 AM >> To: Cameron Byrne >> Cc: v6ops WG; Russell Housley >> Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - = not tobe an >> ietf-v6ops I.D. >>=20 >> Cameron, >> It seems we are close to common understanding. >> More below. >>=20 >> Le 2012-02-21 =E0 20:34, Cameron Byrne a =E9crit : >> ... >>> On Tue, Feb 21, 2012 at 10:42 AM, R=E9mi Despr=E9s >> wrote: >> ... >>>>>> Aren't NAT64s always coupled with DNS64s, as seems to be implied = by all >> scenarios of RFC6144? >>>>=20 >>>> An answer to this? >>>>=20 >>>=20 >>> Sorry i missed this earlier. >>>=20 >>> In the case for RFC6144 to replace NAT-PT functionality, yes a DNS64 >>> and NAT64 must be coupled to replace NAT-PT functions. >>>=20 >>> But, RFC6146 and RFC6147 stand on their own. There is no explicit >>> coupling required or shared state between NAT64 and DNS64 for them = to >>> perform their atomic functions. Meaning, any conforming packet >>> (Pref64+32bit IPv4 destination address) may be received by an = RFC6146 >>> stateful NAT64 and be translated. A properly configured CLAT that >>> knows the Pref64 may received IPv4 packets and translate them via >>> RFC6145 to a PLAT without any queries or interactions with the = DNS64. >>=20 >> I don't think a NAT64 that wouldn't work for IPv6-only hosts is a = scenario that >> needs to be mentioned, especially since it contradicts an existing = RFC. >> IMHO, stating that, with a CE architecture like that of the 464XLAT = draft, a >> stateless CE can work with a stateful NAT64 is enough. >> Adding that it can work without DNS64 is AFAIK at best unnecessary, = at worst >> confusing. >> That could advantageously be deleted (IMHO). >>=20 >> ... >>>>>>>> Why, then, say "In the best case, the CLAT will have a = dedicated /64" >>>>>>>>=20 >>>>>>>=20 >>>>>>> It just seems cleaner to me to have a dedicated /64 if it is >>>>>>> available. Operationally, aside from the NDP claiming the /96, = there >>>>>>> is no difference to have dedicated or not dedicated. >>>>>>=20 >>>>>> Understood, but: >>>>>> - Claiming a /96 on a link seems new to me (is there an existing >> reference?) >>>>>=20 >>>>> It does not need to claim the /96 as a whole. The CLAT will do = NDP >>>>> with the idea that each /128 in the /96 is owned by the CLAT as a >>>>> virtual address. >>>>=20 >>>> Was understood. >>>>=20 >>>>> I have seen this behavior in NAT-PT deployments, but i do not see = it >>>>> specifically declared in the NAT-PT RFC. >>>>=20 >>>> Right, it seems to be new material as far as IETF is concerned. >>>>=20 >>>=20 >>> NDP for a host address should not be new material. >>=20 >> Nothing is new in your proposal for hosts, right, but NDP operation = IS modified >> in CE routers. >>=20 >>> As i mentioned >>> before, we can treat each address in the /96 as a host address on = the >>> CLAT, and the interactions are normal for NDP host addresses. >>=20 >> Understood. >> The fact that this is new in the router CE is not a problem AFAIAC, = but provided >> new pieces of design are clearly identified. >>=20 >>> Alternatively, we may view the CLAT in terms of proxy NDP >>> http://tools.ietf.org/html/rfc4861#section-7.2.8 >>=20 >> Doesn't this require support of RFC3810 (Multicast Listener Discovery = Version 2 >> (MLDv2) for IPv6)? >> That could be part of the specification, but would AFAIK would be a = constraint. >>=20 >>> The CLAT is willing to accept packet destine to the /96 on behalf of >>> the IPv4 internet, and the NDP actions are defined as existing Proxy >>> NDP. >>>=20 >>> Thoughts on one verse the other? >>=20 >> My thought is that BOTH can be AVOIDED. >> It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix = that differs from all >> valid native IPv6 prefixes. >> This is easy to have, and is part of the 4rd-U proposal. >> The architecture you propose can easily benefit from it, simply by = adding its >> scenario as a particular one of the 4rd-U general scheme. >>=20 >>>> I think I understand your motivations, and hope you can understand = those of >> draft-ietf-softwire-stateless-4v6-motivation. >>>>=20 >>>=20 >>> Yes, and thanks again for your careful review and attention to the = 464XLAT >> draft >>=20 >> I confirm that IMHO your draft brings quite useful new material. >>=20 >> If you can take time to look at = http://tools.ietf.org/html/draft-despres-softwire- >> 4rd-u-03, my hope is that you will understand that coordination = between its >> contents and that of your draft should be useful. >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>=20 >>>=20 >>> CB >>>=20 >>>> Regards, >>>> RD >>>>=20 >>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Wed Feb 22 07:06:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9867521F87CA for ; Wed, 22 Feb 2012 07:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2-L5E-dH7mD for ; Wed, 22 Feb 2012 07:06:12 -0800 (PST) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id D260921F8742 for ; Wed, 22 Feb 2012 07:06:11 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id d3661i00237Y3f403366Ht; Wed, 22 Feb 2012 16:06:10 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-15--571352131 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <5E8BCCE6-E48A-4D67-BB4C-3CD7AD029BAD@cisco.com> Date: Wed, 22 Feb 2012 16:06:05 +0100 Message-Id: References: <021601ccf0f3$812952f0$837bf8d0$@com> <4F44A67D.2070203@redpill-linpro.com> <5E8BCCE6-E48A-4D67-BB4C-3CD7AD029BAD@cisco.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 15:06:16 -0000 --Apple-Mail-15--571352131 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-02-22 =E0 10:58, Rajiv Asati (rajiva) a =E9crit : > I agree. Separately, shouldn't G3 also say prefix acquisition ? >=20 > G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between = its LAN interface(s) and its WAN interface until the router has = successfully completed the IPv6 address acquisition process. +1 RD >=20 >=20 > Cheers, > Rajiv >=20 > Sent from my Phone >=20 > On Feb 22, 2012, at 3:25 AM, "Tore Anderson" = wrote: >=20 >> * Dan Wing >>=20 >>> Reading draft-ietf-v6ops-6204bis-05, I couldn't determine what the = CE router >>> should do if, after it acquires an IPv6 prefix from its WAN = interface, the >>> WAN interface later goes down. Requirement G-4 in the specification >>> (http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-05#section-4.1) >>> requires the CE router (immediately?) withdraw the prefix on the LAN >>> interface >>=20 >> Dan, >>=20 >> That's not what G-4 (or G-5) says. It says that if the CE router = loses >> its WAN interface (or default route on a still-enabled WAN interface = for >> that matter), it needs to withdraw itself as a *default router* for = the >> nodes connected to the LAN. >>=20 >> It does *not* say anything about the prefixes/addresses advertised to >> the LAN - they should not be impacted by the WAN interface going = down, >> except for the fact that the the DHCPv6-PD lease cannot be renewed, >> which means that the lifetimes of the lease and the addresses = themselves >> will eventually reach zero. >>=20 >> --=20 >> Tore Anderson >> Redpill Linpro AS - http://www.redpill-linpro.com >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-15--571352131 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
I agree. Separately, = shouldn't G3 also say prefix acquisition = ?

  G-3: The IPv6 CE router MUST NOT = forward any IPv6 traffic between its LAN = interface(s) and its WAN interface until the router has successfully completed the IPv6 address acquisition = process.

+1

RD


tore.anderson@redpill-lin= pro.com> wrote:

* Dan = Wing

Reading = draft-ietf-v6ops-6204bis-05, I couldn't determine what the CE = router
should do = if, after it acquires an IPv6 prefix from its WAN interface, = the
WAN interface = later goes down.  Requirement G-4 in the = specification
(http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-05#section-4.1)<= /span>
requires the CE = router (immediately?) withdraw the prefix on the = LAN
interface

Dan,

That's not what G-4 (or G-5) = says. It says that if the CE router loses
its WAN = interface (or default route on a still-enabled WAN interface = for
that matter), it needs to withdraw itself as a = *default router* for the
nodes connected to the = LAN.

It does *not* say anything about = the prefixes/addresses advertised to
the LAN - they = should not be impacted by the WAN interface going = down,
except for the fact that the the DHCPv6-PD lease = cannot be renewed,
which means that the lifetimes of the = lease and the addresses themselves
will eventually reach = zero.

--
Tore = Anderson
Redpill Linpro AS - http://www.redpill-linpro.com<= /span>
_______________________________________________
= v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops
____________= ___________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail-15--571352131-- From dwing@cisco.com Wed Feb 22 07:07:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1C21F8814 for ; Wed, 22 Feb 2012 07:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.383 X-Spam-Level: X-Spam-Status: No, score=-108.383 tagged_above=-999 required=5 tests=[AWL=1.616, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if9lGH3xqQ-H for ; Wed, 22 Feb 2012 07:07:20 -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 E7CF721F8815 for ; Wed, 22 Feb 2012 07:07:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2529; q=dns/txt; s=iport; t=1329923241; x=1331132841; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=mg0Nzq+DicoCnCT2eFHVjTkm4M70FpaFEHAO0HIzO2Y=; b=RZFsn0jk3/Vk7j5Gppzmgb0BAs15q9HrkarIxSf0X6mbGxVI8ZiIy2ba dqk8x9uBg+d+C69SLxe8u+n6Ez6VL0piJbswWj2zi0W8nO8TpfymT/dz/ nOtXGg0XVeenJbgZYDOYSw6jOz5qAPVHbrMryku1qq5KFlgmFgtBRme4E U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABgERU+rRDoJ/2dsb2JhbABDDqJhj3iBB4FzAQEBAwEBAQEFCgEXEDQLBQcBAwIJDgECBAEBAScHGQ4VCgkIAQEEEwsXh18JmHUBnwqMWSgDAQJDAwQKCAIBAQGFHzIMBgUDEoM8BIhPhQeaGFg X-IronPort-AV: E=Sophos;i="4.73,464,1325462400"; d="scan'208";a="31780719" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 22 Feb 2012 15:07:20 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1MF7KXS010031; Wed, 22 Feb 2012 15:07:20 GMT From: "Dan Wing" To: "'Timothy Winters'" , "'STARK, BARBARA H'" References: <021601ccf0f3$812952f0$837bf8d0$@com> <4F44A67D.2070203@redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E611042179@GAALPA1MSGUSR9N.ITServices.sbc.com> <348ECA23-D21C-4F10-BB28-708CE3B86249@iol.unh.edu> In-Reply-To: <348ECA23-D21C-4F10-BB28-708CE3B86249@iol.unh.edu> Date: Wed, 22 Feb 2012 07:07:18 -0800 Message-ID: <03c301ccf173$ac9d3a20$05d7ae60$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Aczxaxv5V3d7wlBqTkOSegmpe54DcgAB+aQw Content-Language: en-us Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 15:07:25 -0000 > -----Original Message----- > From: Timothy Winters [mailto:twinters@iol.unh.edu] > Sent: Wednesday, February 22, 2012 6:06 AM > To: STARK, BARBARA H > Cc: Tore Anderson; Dan Wing; v6ops@ietf.org; draft-ietf-v6ops- > 6204bis@tools.ietf.org > Subject: Re: [v6ops] 6204bis and WAN disappearing > > Hello, > The CE Routers that have participated in the IPv6 CE Events have > implemented Tore/Barbara have stated. The CE Routers transmit an RA > with a lifetime 0 but don't withdraw prefixes. I am glad there is high confidence that the spec is accurate. My worry, though, is it provides insufficient clarity towards hosts, specifically that hosts should/shouldn't use ULA for communication amongst themselves within the local network, and should/shouldn't use ULA when advertising their presence via their rendezvous protocol (e.g., mDNS). A sentence such as "With this functionality, hosts using ULA will be able to continue normal operation during a lengthy WAN outage" would be a nice addition. -d > Regards, > Tim > > On Feb 22, 2012, at 8:54 AM, STARK, BARBARA H wrote: > > > > >> * Dan Wing > >> > >>> Reading draft-ietf-v6ops-6204bis-05, I couldn't determine what the > CE > >> router > >>> should do if, after it acquires an IPv6 prefix from its WAN > >> interface, the > >>> WAN interface later goes down. Requirement G-4 in the > specification > >>> (http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-05#section- > 4.1) > >>> requires the CE router (immediately?) withdraw the prefix on the > LAN > >>> interface > >> > >> Dan, > >> > >> That's not what G-4 (or G-5) says. It says that if the CE router > loses > >> its WAN interface (or default route on a still-enabled WAN interface > >> for that matter), it needs to withdraw itself as a *default router* > for the > >> nodes connected to the LAN. > >> > >> It does *not* say anything about the prefixes/addresses advertised > to > >> the LAN - they should not be impacted by the WAN interface going > down, > >> except for the fact that the the DHCPv6-PD lease cannot be renewed, > >> which means that the lifetimes of the lease and the addresses > >> themselves will eventually reach zero. > >> > >> -- > >> Tore Anderson > > > > I agree with what Tore says the draft says. That's definitely what I > understood it to say. > > Barbara > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From jason.weil@twcable.com Wed Feb 22 08:38:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0CC21F8878 for ; Wed, 22 Feb 2012 08:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYUUQp6V98yf for ; Wed, 22 Feb 2012 08:38:13 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 206AF21F885D for ; Wed, 22 Feb 2012 08:38:13 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,463,1325480400"; d="scan'208";a="326434800" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Feb 2012 11:37:31 -0500 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.44]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 22 Feb 2012 11:38:12 -0500 From: "Weil, Jason" To: Dan Wing , Timothy Winters , "'STARK, BARBARA H'" Date: Wed, 22 Feb 2012 11:38:11 -0500 Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: AczxgF15cI6U0K2hSBy0toP9YhbhyA== Message-ID: In-Reply-To: <03c301ccf173$ac9d3a20$05d7ae60$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 16:38:17 -0000 Dan, I believe it is still up for discussion what the CE router should do when the WAN interface transitions to the Down state and may just be an implementation decision. Two immediate options come to mind including the one you suggest. 1. Use ULA, if present for home network communication. This requires a single ULA across a multi-subnet home network (otherwise Link Local would be sufficient) which does not exist today. 2. Use the last known GUA for home network communication. This requires adjusting the Valid lifetime on a Link Down Event on the PIO advertised on the LAN to a sufficiently large number to allow continued communications until the CE Router either Rebinds the PD Prefix or learns a new one. I'm still not sold that ULA is the correct solution in this case. This is more in the domain of a Homenet discussion, although granted the line is blurry here. Jason On 2/22/12 7:07 AM, "Dan Wing" wrote: >> -----Original Message----- >> From: Timothy Winters [mailto:twinters@iol.unh.edu] >> Sent: Wednesday, February 22, 2012 6:06 AM >> To: STARK, BARBARA H >> Cc: Tore Anderson; Dan Wing; v6ops@ietf.org; draft-ietf-v6ops- >> 6204bis@tools.ietf.org >> Subject: Re: [v6ops] 6204bis and WAN disappearing >> >> Hello, >> The CE Routers that have participated in the IPv6 CE Events have >> implemented Tore/Barbara have stated. The CE Routers transmit an RA >> with a lifetime 0 but don't withdraw prefixes. > >I am glad there is high confidence that the spec is accurate. > >My worry, though, is it provides insufficient clarity towards hosts, >specifically that hosts should/shouldn't use ULA for communication >amongst themselves within the local network, and should/shouldn't use >ULA when advertising their presence via their rendezvous protocol >(e.g., mDNS). A sentence such as "With this functionality, hosts >using ULA will be able to continue normal operation during a lengthy >WAN outage" would be a nice addition. > >-d > > >> Regards, >> Tim >> >> On Feb 22, 2012, at 8:54 AM, STARK, BARBARA H wrote: >> >> > >> >> * Dan Wing >> >> >> >>> Reading draft-ietf-v6ops-6204bis-05, I couldn't determine what the >> CE >> >> router >> >>> should do if, after it acquires an IPv6 prefix from its WAN >> >> interface, the >> >>> WAN interface later goes down. Requirement G-4 in the >> specification >> >>> (http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-05#section- >> 4.1) >> >>> requires the CE router (immediately?) withdraw the prefix on the >> LAN >> >>> interface >> >> >> >> Dan, >> >> >> >> That's not what G-4 (or G-5) says. It says that if the CE router >> loses >> >> its WAN interface (or default route on a still-enabled WAN interface >> >> for that matter), it needs to withdraw itself as a *default router* >> for the >> >> nodes connected to the LAN. >> >> >> >> It does *not* say anything about the prefixes/addresses advertised >> to >> >> the LAN - they should not be impacted by the WAN interface going >> down, >> >> except for the fact that the the DHCPv6-PD lease cannot be renewed, >> >> which means that the lifetimes of the lease and the addresses >> >> themselves will eventually reach zero. >> >> >> >> -- >> >> Tore Anderson >> > >> > I agree with what Tore says the draft says. That's definitely what I >> understood it to say. >> > Barbara >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops 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 ichiroumakino@gmail.com Wed Feb 22 08:50:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A576321F874C for ; Wed, 22 Feb 2012 08:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZktywTDOkl2 for ; Wed, 22 Feb 2012 08:50:15 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F29521F871A for ; Wed, 22 Feb 2012 08:50:14 -0800 (PST) Received: by wibhm9 with SMTP id hm9so199040wib.31 for ; Wed, 22 Feb 2012 08:50:13 -0800 (PST) Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.216.137.25 as permitted sender) client-ip=10.216.137.25; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.216.137.25 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com Received: from mr.google.com ([10.216.137.25]) by 10.216.137.25 with SMTP id x25mr9383710wei.55.1329929413765 (num_hops = 1); Wed, 22 Feb 2012 08:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=MLrxS/RpbiOy2tb5PIcVqBUDirWV/I+JvN0sLRJz/C0=; b=RI9xiCwzHpZXhhT7ss7tFvndb/9V6ORik811BP4ky273Ahwtbvoq81W6/GivIciaCa oMjMeKuQJZm3m8tAq/BmBbVCDDu/Z4qSiZnTECfeVx5X77JEDhEx+9XhjN77+ZMKv0hR os1YJ2U3KLvQObq+F3idcTJ8Fx1qVVghLGSZ4= Received: by 10.216.137.25 with SMTP id x25mr7726527wei.55.1329929413630; Wed, 22 Feb 2012 08:50:13 -0800 (PST) Received: from dhcp-10-61-98-101.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id cs4sm73416773wib.8.2012.02.22.08.50.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 08:50:12 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 22 Feb 2012 17:50:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3A06CE7B-40BE-4D1F-B73D-5A6300F00E1C@employees.org> References: To: "Weil, Jason" X-Mailer: Apple Mail (2.1257) Cc: "draft-ietf-v6ops-6204bis@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 16:50:15 -0000 Jason, > I believe it is still up for discussion what the CE router should do = when > the WAN interface transitions to the Down state and may just be an > implementation decision. Two immediate options come to mind including = the > one you suggest. I disagree. on a WAN interface down event according to RFC6204, nothing happens with = prefixes/addresses. > 1. Use ULA, if present for home network communication. This requires a > single ULA across a multi-subnet home network (otherwise Link Local = would > be sufficient) which does not exist today. >=20 > 2. Use the last known GUA for home network communication. This = requires > adjusting the Valid lifetime on a Link Down Event on the PIO = advertised on > the LAN to a sufficiently large number to allow continued = communications > until the CE Router either Rebinds the PD Prefix or learns a new one. >=20 > I'm still not sold that ULA is the correct solution in this case. This = is > more in the domain of a Homenet discussion, although granted the line = is > blurry here. you are talking about the case where WAN is down and prefix times out? the 6204 assumption is that you then have the ULA, that you have had the = whole time, i.e. no introduction of a new prefix just because of a WAN = down/prefix timeout event. 2 is certainly an option as well. cheers, Ole From Ted.Lemon@nominum.com Wed Feb 22 09:02:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD0321E8056 for ; Wed, 22 Feb 2012 09:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.509 X-Spam-Level: X-Spam-Status: No, score=-106.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to3EemdS6USD for ; Wed, 22 Feb 2012 09:02:09 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6174121E803D for ; Wed, 22 Feb 2012 09:02:09 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKT0UfkAAdhJ9nI5QnN8+3O5hNT1B8i6Uj@postini.com; Wed, 22 Feb 2012 09:02:09 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 43E3E1B839E for ; Wed, 22 Feb 2012 09:02:08 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 33B09190097; Wed, 22 Feb 2012 09:02:08 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Wed, 22 Feb 2012 09:02:08 -0800 From: Ted Lemon To: Jason Weil Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAixh6AAAuAUgAAAGCPAAACJwsAAAMskIAAANWIAA== Date: Wed, 22 Feb 2012 17:02:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-v6ops-6204bis@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 17:02:11 -0000 Various people have made the claim that continuing to use the GUA after its= lifetime expires is okay as long as you remain disconnected, but this isn'= t correct. The reason it isn't correct is that a GUA, used beyond its valid lifetime, = has the potential to be immediately invalidated when the WAN reappears. W= hen I say potential, it might seem like I mean that it's something that cou= ld happen, but is unlikely. But we as protocol wonks have no way to make = that statement, because it depends on circumstances we don't control=97it d= epends on the provider's upstream policy. So this means that if we arrange to kill the GUA when the WAN comes back, i= f the GUA is no longer valid, then perfectly valid in-home streams will be = interrupted. We might say "oh, that's no problem, let the streams that ar= e running keep using the GUA." This is still a problem, though, because a device configured with a GUA who= se lifetime has expired will not know that its lifetime has expired, becaus= e there is no way to communicate this: in IPv6, an address is valid or it i= s not. We do get to play with preferred versus valid, and maybe we could = deprecate the address and hope that the node wouldn't try to use it to conn= ect anymore, but there's no mechanism for doing this in the IPv6 protocol s= uite. So it's quite likely that when the WAN does reappear, the device will try t= o use its GUA to communicate with devices off the local wire. If the GUA = is no longer valid, it will fail. Whereas a ULA has limited scope; if a device is configured with a ULA, and = the WAN comes back, then the device can immediately get a valid GUA and sta= rt communicating with it. Because all in-home connections are using the U= LA, they are not interrupted. Of course, in-home connections that started out using the GUA and survived = the loss of the WAN connection will die when the valid lifetime of the GUA = expires. This is a good reason to try to arrange for all in-home connecti= ons to use ULAs always, even when we have a WAN connection. I realize I'm just reiterating things that have been said before, but given= that we are still hearing the notion of keeping the GUA on WAN loss, I thi= nk it's worth walking through the argument again. From jason.weil@twcable.com Wed Feb 22 09:13:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E6921F8646 for ; Wed, 22 Feb 2012 09:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaE0G5fBPgei for ; Wed, 22 Feb 2012 09:13:25 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 175C921F870B for ; Wed, 22 Feb 2012 09:13:24 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,465,1325480400"; d="scan'208";a="342814602" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Feb 2012 12:13:05 -0500 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.44]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Wed, 22 Feb 2012 12:13:24 -0500 From: "Weil, Jason" To: =?iso-8859-1?Q?Ole_Tr=F8an?= Date: Wed, 22 Feb 2012 12:13:23 -0500 Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: AczxhUh7jQxEFQXJQq6tZ2mj0boUMw== Message-ID: In-Reply-To: <3A06CE7B-40BE-4D1F-B73D-5A6300F00E1C@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-v6ops-6204bis@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 17:13:25 -0000 On 2/22/12 8:50 AM, "Ole Tr=F8an" wrote: >Jason, > >> I believe it is still up for discussion what the CE router should do >>when >> the WAN interface transitions to the Down state and may just be an >> implementation decision. Two immediate options come to mind including >>the >> one you suggest. > >I disagree. >on a WAN interface down event according to RFC6204, nothing happens with >prefixes/addresses. I should have been more specific. I was referring to what steps the CE Router takes regarding prefixes it generates for use on the LAN interface/s. I agree with your disagreement that nothing happens to the original prefix learned on the WAN other than timer countdowns. > >> 1. Use ULA, if present for home network communication. This requires a >> single ULA across a multi-subnet home network (otherwise Link Local >>would >> be sufficient) which does not exist today. >> >> 2. Use the last known GUA for home network communication. This requires >> adjusting the Valid lifetime on a Link Down Event on the PIO advertised >>on >> the LAN to a sufficiently large number to allow continued communications >> until the CE Router either Rebinds the PD Prefix or learns a new one. >> >> I'm still not sold that ULA is the correct solution in this case. This >>is >> more in the domain of a Homenet discussion, although granted the line is >> blurry here. > >you are talking about the case where WAN is down and prefix times out? Correct. > >the 6204 assumption is that you then have the ULA, that you have had the >whole time, i.e. no introduction of a new prefix just because of a WAN >down/prefix timeout event. > >2 is certainly an option as well. > >cheers, >Ole > 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 rajiva@cisco.com Wed Feb 22 10:12:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE12821F874F for ; Wed, 22 Feb 2012 10:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.673 X-Spam-Level: X-Spam-Status: No, score=-8.673 tagged_above=-999 required=5 tests=[AWL=1.026, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TTPr6LgnP-v for ; Wed, 22 Feb 2012 10:12:29 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5067A21F87F8 for ; Wed, 22 Feb 2012 10:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=7305; q=dns/txt; s=iport; t=1329934349; x=1331143949; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=UE847PTkcLWjkdNzQo+sDZusJgt0EwzJcRSP7+sEd2g=; b=Ebl1vRa1BH1aUK5PghNZFNvSPNuYcxM0/jf9PWNi7vTVgwL38G1cDOir H5hYECdIoT8dg9uNWDytNt5xJZRIrIgN7hUeXNPLLOT4fbA18c6PXH30Z 0jPIXOVCfkLwTHz4m7Hu4SGfuaY9m58d0da2UWs6BAtrmOgR2N8DZ1Kh7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAF0vRU+tJXG//2dsb2JhbABEskaBB4FzAQEBAwEBAQEPAR0+CwUHBAIBCBEBAwEBAQoGFwEGASYfAwYIAQEEEwgah18JmSQBnw2JV4JwBgMBBgEBAQIJAQECAwEJBgEBBT4ahV4MBggSDIJNYwSIHDOfdYE0 X-IronPort-AV: E=Sophos;i="4.73,465,1325462400"; d="scan'208";a="60999503" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 22 Feb 2012 18:12:28 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1MICRdo000324; Wed, 22 Feb 2012 18:12:28 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 12:12:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Feb 2012 12:12:26 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0778D61A@XMB-RCD-111.cisco.com> In-Reply-To: <592C29F3-56B0-4319-BD94-B1A520CF2A5E@laposte.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe an ietf-v6ops I.D. Thread-Index: Aczxcyqn0FXHJ+KqQw6XY5fYXGj8kAAGZtTQ References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net><36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net><76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> <190FFDFA-2901-437A-BFBF-E598F56A6120@laposte.net> <067E6CE33034954AAC05C9EC85E2577C0778D46C@XMB-RCD-111.cisco.com> <592C29F3-56B0-4319-BD94-B1A520CF2A5E@laposte.net> From: "Rajiv Asati (rajiva)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-OriginalArrivalTime: 22 Feb 2012 18:12:27.0901 (UTC) FILETIME=[890E72D0:01CCF18D] Cc: Russell Housley , v6ops WG Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:12:34 -0000 Hi Remi, > Compliance with the 464XLAT draft requires specific code that none of = the > referenced RFCs specifies. > This code is to prevent other LAN hosts not only to avoid the router's > address, as usual, BUT all addresses starting with the chosen /95. Well, the code is nothing special, since it is part of typical NDP/DAD = to prohibit a LAN host from using router's addresses (say). However, the valid point you have is that if the LAN host duplicated the = same address as that of the router (/96 based addresses, say), then the = LAN host would be deprived of the address (and possibly global IPv6 = connectivity). Of course, if there is no host in the LAN, then this problem is moot. = Perhaps, 464XLAT deployment assumes the lack of LAN hosts. Cheers, Rajiv > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net] > Sent: Wednesday, February 22, 2012 10:04 AM > To: Rajiv Asati (rajiva) > Cc: Cameron Byrne; v6ops WG; Russell Housley > Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - = not tobe > an ietf-v6ops I.D. >=20 >=20 > Le 2012-02-22 =E0 15:10, Rajiv Asati (rajiva) a =E9crit : >=20 > >>> Alternatively, we may view the CLAT in terms of proxy NDP > > > > I think that pNDP is unnecessary. NDP is good enough here. > > > > Also, when we move to using DHCP-PD, then NDP on WAN int will not be > necessary either. > > > >>> NDP for a host address should not be new material. >=20 >=20 > >> Nothing is new in your proposal for hosts, right, but NDP operation = IS > modified > >> in CE routers. > > > > Remi, what is modified in your view? >=20 > Compliance with the 464XLAT draft requires specific code that none of = the > referenced RFCs specifies. > This code is to prevent other LAN hosts not only to avoid the router's > address, as usual, BUT all addresses starting with the chosen /95. >=20 > Cheers, > RD >=20 >=20 > > > > Cheers, > > Rajiv > > > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf Of > >> R=E9mi Despr=E9s > >> Sent: Wednesday, February 22, 2012 5:40 AM > >> To: Cameron Byrne > >> Cc: v6ops WG; Russell Housley > >> Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" = - not > tobe an > >> ietf-v6ops I.D. > >> > >> Cameron, > >> It seems we are close to common understanding. > >> More below. > >> > >> Le 2012-02-21 =E0 20:34, Cameron Byrne a =E9crit : > >> ... > >>> On Tue, Feb 21, 2012 at 10:42 AM, R=E9mi Despr=E9s > >> wrote: > >> ... > >>>>>> Aren't NAT64s always coupled with DNS64s, as seems to be = implied > by all > >> scenarios of RFC6144? > >>>> > >>>> An answer to this? > >>>> > >>> > >>> Sorry i missed this earlier. > >>> > >>> In the case for RFC6144 to replace NAT-PT functionality, yes a = DNS64 > >>> and NAT64 must be coupled to replace NAT-PT functions. > >>> > >>> But, RFC6146 and RFC6147 stand on their own. There is no explicit > >>> coupling required or shared state between NAT64 and DNS64 for them > to > >>> perform their atomic functions. Meaning, any conforming packet > >>> (Pref64+32bit IPv4 destination address) may be received by an = RFC6146 > >>> stateful NAT64 and be translated. A properly configured CLAT that > >>> knows the Pref64 may received IPv4 packets and translate them via > >>> RFC6145 to a PLAT without any queries or interactions with the = DNS64. > >> > >> I don't think a NAT64 that wouldn't work for IPv6-only hosts is a = scenario > that > >> needs to be mentioned, especially since it contradicts an existing = RFC. > >> IMHO, stating that, with a CE architecture like that of the 464XLAT = draft, a > >> stateless CE can work with a stateful NAT64 is enough. > >> Adding that it can work without DNS64 is AFAIK at best unnecessary, = at > worst > >> confusing. > >> That could advantageously be deleted (IMHO). > >> > >> ... > >>>>>>>> Why, then, say "In the best case, the CLAT will have a = dedicated > /64" > >>>>>>>> > >>>>>>> > >>>>>>> It just seems cleaner to me to have a dedicated /64 if it is > >>>>>>> available. Operationally, aside from the NDP claiming the = /96, there > >>>>>>> is no difference to have dedicated or not dedicated. > >>>>>> > >>>>>> Understood, but: > >>>>>> - Claiming a /96 on a link seems new to me (is there an = existing > >> reference?) > >>>>> > >>>>> It does not need to claim the /96 as a whole. The CLAT will do = NDP > >>>>> with the idea that each /128 in the /96 is owned by the CLAT as = a > >>>>> virtual address. > >>>> > >>>> Was understood. > >>>> > >>>>> I have seen this behavior in NAT-PT deployments, but i do not = see it > >>>>> specifically declared in the NAT-PT RFC. > >>>> > >>>> Right, it seems to be new material as far as IETF is concerned. > >>>> > >>> > >>> NDP for a host address should not be new material. > >> > >> Nothing is new in your proposal for hosts, right, but NDP operation = IS > modified > >> in CE routers. > >> > >>> As i mentioned > >>> before, we can treat each address in the /96 as a host address on = the > >>> CLAT, and the interactions are normal for NDP host addresses. > >> > >> Understood. > >> The fact that this is new in the router CE is not a problem AFAIAC, = but > provided > >> new pieces of design are clearly identified. > >> > >>> Alternatively, we may view the CLAT in terms of proxy NDP > >>> http://tools.ietf.org/html/rfc4861#section-7.2.8 > >> > >> Doesn't this require support of RFC3810 (Multicast Listener = Discovery > Version 2 > >> (MLDv2) for IPv6)? > >> That could be part of the specification, but would AFAIK would be a > constraint. > >> > >>> The CLAT is willing to accept packet destine to the /96 on behalf = of > >>> the IPv4 internet, and the NDP actions are defined as existing = Proxy > >>> NDP. > >>> > >>> Thoughts on one verse the other? > >> > >> My thought is that BOTH can be AVOIDED. > >> It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix = that differs > from all > >> valid native IPv6 prefixes. > >> This is easy to have, and is part of the 4rd-U proposal. > >> The architecture you propose can easily benefit from it, simply by = adding > its > >> scenario as a particular one of the 4rd-U general scheme. > >> > >>>> I think I understand your motivations, and hope you can = understand > those of > >> draft-ietf-softwire-stateless-4v6-motivation. > >>>> > >>> > >>> Yes, and thanks again for your careful review and attention to the > 464XLAT > >> draft > >> > >> I confirm that IMHO your draft brings quite useful new material. > >> > >> If you can take time to look at = http://tools.ietf.org/html/draft-despres- > softwire- > >> 4rd-u-03, my hope is that you will understand that coordination = between > its > >> contents and that of your draft should be useful. > >> > >> Regards, > >> RD > >> > >> > >> > >> > >>> > >>> CB > >>> > >>>> Regards, > >>>> RD > >>>> > >>>> > >>>> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Wed Feb 22 10:23:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F3F21F86B9 for ; Wed, 22 Feb 2012 10:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nlo5u6h3L5M for ; Wed, 22 Feb 2012 10:23:27 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2B521F86B5 for ; Wed, 22 Feb 2012 10:23:27 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so454116pbc.31 for ; Wed, 22 Feb 2012 10:23:27 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.234.132 as permitted sender) client-ip=10.68.234.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.234.132 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.234.132]) by 10.68.234.132 with SMTP id ue4mr91702244pbc.29.1329935007405 (num_hops = 1); Wed, 22 Feb 2012 10:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=P5SfAgHK9jIQCfIsNiRAATA31wXC7qVKFB37CBDtm8Q=; b=ij0sIInVZEN7USFUdHQVnchCkM8HAs7Pab/oRzA7qKvUcH5Tvv0Hg6oa+JJt6otxAl XH1DfgSwPrW5jbJNlSQ4c/qr44HlNDd+juyO8ExLHt8w8F4enxG0kWa/1yWZl3RkJcfA 8Qs79H59safDBY++I8c2waSB0geaKB3j0+X9g= MIME-Version: 1.0 Received: by 10.68.234.132 with SMTP id ue4mr75481935pbc.29.1329935007294; Wed, 22 Feb 2012 10:23:27 -0800 (PST) Received: by 10.142.99.12 with HTTP; Wed, 22 Feb 2012 10:23:27 -0800 (PST) In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0778D61A@XMB-RCD-111.cisco.com> References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> <190FFDFA-2901-437A-BFBF-E598F56A6120@laposte.net> <067E6CE33034954AAC05C9EC85E2577C0778D46C@XMB-RCD-111.cisco.com> <592C29F3-56B0-4319-BD94-B1A520CF2A5E@laposte.net> <067E6CE33034954AAC05C9EC85E2577C0778D61A@XMB-RCD-111.cisco.com> Date: Wed, 22 Feb 2012 10:23:27 -0800 Message-ID: From: Cameron Byrne To: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Russell Housley , v6ops WG Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:23:32 -0000 On Wed, Feb 22, 2012 at 10:12 AM, Rajiv Asati (rajiva) w= rote: > Hi Remi, > >> Compliance with the 464XLAT draft requires specific code that none of th= e >> referenced RFCs specifies. >> This code is to prevent other LAN hosts not only to avoid the router's >> address, as usual, BUT all addresses starting with the chosen /95. > > Well, the code is nothing special, since it is part of typical NDP/DAD to= prohibit a LAN host from using router's addresses (say). > Yes. This is clear, and this behavior has been demonstrated in commercial NAT-PT systems. > However, the valid point you have is that if the LAN host duplicated the = same address as that of the router (/96 based addresses, say), then the LAN= host would be deprived of the address (and possibly global IPv6 connectivi= ty). > It will not be deprived, it will be made aware via NDP that that address is in use therefore it must select another address. As described in the draft, the CLAT may also serve as a DHCPv6 server and therefore will avoid the situation entirely for DHCPv6 clients since the CLAT is capable and aware that the /96 is already in use. > Of course, if there is no host in the LAN, then this problem is moot. Per= haps, 464XLAT deployment assumes the lack of LAN hosts. > No, we definitely make it clear in the draft that LAN hosts are in scope. CB > Cheers, > Rajiv > > >> -----Original Message----- >> From: R=E9mi Despr=E9s [mailto:despres.remi@laposte.net] >> Sent: Wednesday, February 22, 2012 10:04 AM >> To: Rajiv Asati (rajiva) >> Cc: Cameron Byrne; v6ops WG; Russell Housley >> Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not= tobe >> an ietf-v6ops I.D. >> >> >> Le 2012-02-22 =E0 15:10, Rajiv Asati (rajiva) a =E9crit : >> >> >>> Alternatively, we may view the CLAT in terms of proxy NDP >> > >> > I think that pNDP is unnecessary. NDP is good enough here. >> > >> > Also, when we move to using DHCP-PD, then NDP on WAN int will not be >> necessary either. >> > >> >>> NDP for a host address should not be new material. >> >> >> >> Nothing is new in your proposal for hosts, right, but NDP operation I= S >> modified >> >> in CE routers. >> > >> > Remi, what is modified in your view? >> >> Compliance with the 464XLAT draft requires specific code that none of th= e >> referenced RFCs specifies. >> This code is to prevent other LAN hosts not only to avoid the router's >> address, as usual, BUT all addresses starting with the chosen /95. >> >> Cheers, >> RD >> >> >> > >> > Cheers, >> > Rajiv >> > >> > >> >> -----Original Message----- >> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On >> Behalf Of >> >> R=E9mi Despr=E9s >> >> Sent: Wednesday, February 22, 2012 5:40 AM >> >> To: Cameron Byrne >> >> Cc: v6ops WG; Russell Housley >> >> Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - = not >> tobe an >> >> ietf-v6ops I.D. >> >> >> >> Cameron, >> >> It seems we are close to common understanding. >> >> More below. >> >> >> >> Le 2012-02-21 =E0 20:34, Cameron Byrne a =E9crit : >> >> ... >> >>> On Tue, Feb 21, 2012 at 10:42 AM, R=E9mi Despr=E9s >> >> wrote: >> >> ... >> >>>>>> Aren't NAT64s always coupled with DNS64s, as seems to be implied >> by all >> >> scenarios of RFC6144? >> >>>> >> >>>> An answer to this? >> >>>> >> >>> >> >>> Sorry i missed this earlier. >> >>> >> >>> In the case for RFC6144 to replace NAT-PT functionality, yes a DNS64 >> >>> and NAT64 must be coupled to replace NAT-PT functions. >> >>> >> >>> But, RFC6146 and RFC6147 stand on their own. =A0There is no explicit >> >>> coupling required or shared state between NAT64 and DNS64 for them >> to >> >>> perform their atomic functions. =A0Meaning, any conforming packet >> >>> (Pref64+32bit IPv4 destination address) may be received by an RFC614= 6 >> >>> stateful NAT64 and be translated. =A0A properly configured CLAT that >> >>> knows the Pref64 may received IPv4 packets and translate them via >> >>> RFC6145 to a PLAT without any queries or interactions with the DNS64= . >> >> >> >> I don't think a NAT64 that wouldn't work for IPv6-only hosts is a sce= nario >> that >> >> needs to be mentioned, especially since it contradicts an existing RF= C. >> >> IMHO, stating that, with a CE architecture like that of the 464XLAT d= raft, a >> >> stateless CE can work with a stateful NAT64 is enough. >> >> Adding that it can work without DNS64 is AFAIK at best unnecessary, a= t >> worst >> >> confusing. >> >> That could advantageously be deleted (IMHO). >> >> >> >> ... >> >>>>>>>> Why, then, say "In the best case, the CLAT will have a dedicate= d >> /64" >> >>>>>>>> >> >>>>>>> >> >>>>>>> It just seems cleaner to me to have a dedicated /64 if it is >> >>>>>>> available. =A0Operationally, aside from the NDP claiming the /96= , there >> >>>>>>> is no difference to have dedicated or not dedicated. >> >>>>>> >> >>>>>> Understood, but: >> >>>>>> - Claiming a /96 on a link seems new to me (is there an existing >> >> reference?) >> >>>>> >> >>>>> It does not need to claim the /96 as a whole. =A0The CLAT will do = NDP >> >>>>> with the idea that each /128 in the /96 is owned by the CLAT as a >> >>>>> virtual address. >> >>>> >> >>>> Was understood. >> >>>> >> >>>>> I have seen this behavior in NAT-PT deployments, but i do not see = it >> >>>>> specifically declared in the NAT-PT RFC. >> >>>> >> >>>> Right, it seems to be new material as far as IETF is concerned. >> >>>> >> >>> >> >>> NDP for a host address should not be new material. >> >> >> >> Nothing is new in your proposal for hosts, right, but NDP operation I= S >> modified >> >> in CE routers. >> >> >> >>> As i mentioned >> >>> before, we can treat each address in the /96 as a host address on th= e >> >>> CLAT, and the interactions are normal for NDP host addresses. >> >> >> >> Understood. >> >> The fact that this is new in the router CE is not a problem AFAIAC, b= ut >> provided >> >> new pieces of design are clearly identified. >> >> >> >>> Alternatively, we may view the CLAT in terms of proxy NDP >> >>> http://tools.ietf.org/html/rfc4861#section-7.2.8 >> >> >> >> Doesn't this require support of RFC3810 (Multicast Listener Discovery >> Version 2 >> >> (MLDv2) for IPv6)? >> >> That could be part of the specification, but would AFAIK would be a >> constraint. >> >> >> >>> The CLAT is willing to accept packet destine to the /96 on behalf of >> >>> the IPv4 internet, and the NDP actions are defined as existing Proxy >> >>> NDP. >> >>> >> >>> Thoughts on one verse the other? >> >> >> >> My thought is that BOTH can be AVOIDED. >> >> It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix th= at differs >> from all >> >> valid native IPv6 prefixes. >> >> This is easy to have, and is part of the 4rd-U proposal. >> >> The architecture you propose can easily benefit from it, simply by ad= ding >> its >> >> scenario as a particular one of the 4rd-U general scheme. >> >> >> >>>> I think I understand your motivations, and hope you can understand >> those of >> >> draft-ietf-softwire-stateless-4v6-motivation. >> >>>> >> >>> >> >>> Yes, and thanks again for your careful review and attention to the >> 464XLAT >> >> draft >> >> >> >> I confirm that IMHO your draft brings quite useful new material. >> >> >> >> If you can take time to look at http://tools.ietf.org/html/draft-desp= res- >> softwire- >> >> 4rd-u-03, my hope is that you will understand that coordination betwe= en >> its >> >> contents and that of your draft should be useful. >> >> >> >> Regards, >> >> RD >> >> >> >> >> >> >> >> >> >>> >> >>> CB >> >>> >> >>>> Regards, >> >>>> RD >> >>>> >> >>>> >> >>>> >> >> >> >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops > From despres.remi@laposte.net Wed Feb 22 10:42:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AD921F8732 for ; Wed, 22 Feb 2012 10:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5xWQEe7xWjI for ; Wed, 22 Feb 2012 10:42:19 -0800 (PST) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 658DA21F8742 for ; Wed, 22 Feb 2012 10:42:18 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id d6i71i00A37Y3f4036i77l; Wed, 22 Feb 2012 19:42:16 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 22 Feb 2012 18:22:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> References: To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:42:20 -0000 Le 2012-02-22 =E0 18:02, Ted Lemon a =E9crit : > Various people have made the claim that continuing to use the GUA = after its lifetime expires is okay as long as you remain disconnected, = but this isn't correct. >=20 > The reason it isn't correct is that a GUA, used beyond its valid = lifetime, has the potential to be immediately invalidated when the WAN = reappears. Wouldn't it be possible, if it is invalidated to wait, before opening = again routes to the WAN, until the internal lifetime of the old one has = expired? Renumbering after a link outage shouldn't be very frequent, right?=20 > When I say potential, it might seem like I mean that it's something = that could happen, but is unlikely. But we as protocol wonks have no = way to make that statement, because it depends on circumstances we don't = control=97it depends on the provider's upstream policy. >=20 > So this means that if we arrange to kill the GUA when the WAN comes = back, if the GUA is no longer valid, then perfectly valid in-home = streams will be interrupted. We might say "oh, that's no problem, let = the streams that are running keep using the GUA." >=20 > This is still a problem, though, because a device configured with a = GUA whose lifetime has expired will not know that its lifetime has = expired, because there is no way to communicate this: in IPv6, an = address is valid or it is not. We do get to play with preferred versus = valid, and maybe we could deprecate the address and hope that the node = wouldn't try to use it to connect anymore, but there's no mechanism for = doing this in the IPv6 protocol suite. >=20 > So it's quite likely that when the WAN does reappear, the device will = try to use its GUA to communicate with devices off the local wire. If = the GUA is no longer valid, it will fail. >=20 > Whereas a ULA has limited scope; if a device is configured with a ULA, = and the WAN comes back, then the device can immediately get a valid GUA = and start communicating with it. Because all in-home connections are = using the ULA, they are not interrupted. >=20 > Of course, in-home connections that started out using the GUA and = survived the loss of the WAN connection will die when the valid lifetime = of the GUA expires. This is a good reason to try to arrange for all = in-home connections to use ULAs always, even when we have a WAN = connection. >=20 > I realize I'm just reiterating things that have been said before, but = given that we are still hearing the notion of keeping the GUA on WAN = loss, I think it's worth walking through the argument again. There is AFAIK the implicit assumption that all hosts support two IPv6 = addresses on a single interface. I don't think that OS X, for example, does it today. Then, If the WAN link breaks, all internal sessions are broken, even if = the IPv6 prefix doesn't change when the link comes back. If this point has already been made and answered, please excuse me, a = pointer to the answer will be sufficient. Thanks, RD >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Ted.Lemon@nominum.com Wed Feb 22 10:50:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCFD21E8010 for ; Wed, 22 Feb 2012 10:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.363 X-Spam-Level: X-Spam-Status: No, score=-106.363 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf4ZmfdBL5Ry for ; Wed, 22 Feb 2012 10:50:41 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id DA0BE21E8011 for ; Wed, 22 Feb 2012 10:50:39 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT0U4/wDzpcT9FKzVwLvoy8/Hfefz/6XX@postini.com; Wed, 22 Feb 2012 10:50:41 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EE1EB1B838F for ; Wed, 22 Feb 2012 10:50:38 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E5E41190097; Wed, 22 Feb 2012 10:50:38 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Wed, 22 Feb 2012 10:50:38 -0800 From: Ted Lemon To: =?Windows-1252?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAixh6AAAuAUgAAAGCPAAACJwsAAAMskIAAANWIAAAAtOcAAAMVnYA= Date: Wed, 22 Feb 2012 18:50:37 +0000 Message-ID: <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> In-Reply-To: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:50:42 -0000 On Feb 22, 2012, at 12:22 PM, R=E9mi Despr=E9s w= rote: > Wouldn't it be possible, if it is invalidated to wait, before opening aga= in routes to the WAN, until the internal lifetime of the old one has expire= d? > Renumbering after a link outage shouldn't be very frequent, right?=20 What I'm saying is that we don't have the capacity to say that this is the = case. It is dependent both on the connectivity model and ISP policy. > There is AFAIK the implicit assumption that all hosts support two IPv6 ad= dresses on a single interface. > I don't think that OS X, for example, does it today. > Then, If the WAN link breaks, all internal sessions are broken, even if t= he IPv6 prefix doesn't change when the link comes back. As far as I know OS X supports multiple IPv6 addresses. I don't know how = well it does at address selection, but the OSX guys are pretty smart, so I = assume that they implemented ULA correctly. Might be worth checking out= =97I have to admit I haven't tried it. From Ted.Lemon@nominum.com Wed Feb 22 10:52:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BBB21E8011 for ; Wed, 22 Feb 2012 10:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.36 X-Spam-Level: X-Spam-Status: No, score=-106.36 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+DEoyHIo9zQ for ; Wed, 22 Feb 2012 10:52:55 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id A81F021E8010 for ; Wed, 22 Feb 2012 10:52:53 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT0U5hYuXdLOOXGBBuBh3Y8BtvQ7neqPP@postini.com; Wed, 22 Feb 2012 10:52:53 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 83EE41B838F for ; Wed, 22 Feb 2012 10:52:49 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7C143190097; Wed, 22 Feb 2012 10:52:49 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Wed, 22 Feb 2012 10:52:43 -0800 From: Ted Lemon To: =?Windows-1252?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAixh6AAAuAUgAAAGCPAAACJwsAAAMskIAAANWIAAAAtOcAAAMoPQA= Date: Wed, 22 Feb 2012 18:52:42 +0000 Message-ID: <95424EA2-77A4-4A7D-8689-E269822CD7C3@nominum.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> In-Reply-To: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_95424EA277A44A7D8689E269822CD7C3nominumcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:52:57 -0000 --_000_95424EA277A44A7D8689E269822CD7C3nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Feb 22, 2012, at 12:22 PM, R=E9mi Despr=E9s > wrote: Wouldn't it be possible, if it is invalidated to wait, before opening again= routes to the WAN, until the internal lifetime of the old one has expired? Oh, forgot to reply to this. The answer is that no, you can't, because th= at is almost necessarily a long time. You can change the RA to deprecate = the old GUA, but then you pretty much have to cross your fingers and hope t= hat the host takes the new prefix lifetimes before it attempts any outgoing= connections. --_000_95424EA277A44A7D8689E269822CD7C3nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <38B4AA18C2D55E4A81B84568EE21F99B@nominum.com> Content-Transfer-Encoding: quoted-printable
On Feb 22, 2012, at 12:22 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
W= ouldn't it be possible, if it is invalidated to wait, before opening again routes = to the WAN, until the internal lifetime of the old one has expired?<= br style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal= ; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h= eight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text= -transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webki= t-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium= ; ">

Oh, forgot to reply to this.   The answer is that no, you can't, = because that is almost necessarily a long time.   You can change the R= A to deprecate the old GUA, but then you pretty much have to cross your fin= gers and hope that the host takes the new prefix lifetimes before it attempts any outgoing connections.

--_000_95424EA277A44A7D8689E269822CD7C3nominumcom_-- From jason.weil@twcable.com Wed Feb 22 10:54:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95C121F864E for ; Wed, 22 Feb 2012 10:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlUjaFg9YEfW for ; Wed, 22 Feb 2012 10:54:41 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6D021F864D for ; Wed, 22 Feb 2012 10:54:40 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,465,1325480400"; d="scan'208";a="326520408" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Feb 2012 13:53:34 -0500 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.44]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 22 Feb 2012 13:54:14 -0500 From: "Weil, Jason" To: Ted Lemon Date: Wed, 22 Feb 2012 13:54:13 -0500 Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczxk16sjmpWQGdOTymQZvdHUiIOqg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-v6ops-6204bis@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:54:42 -0000 Might as well continue the age old discussion for us new to the game and trying to actually implement this stuff... On 2/22/12 9:02 AM, "Ted Lemon" wrote: >Various people have made the claim that continuing to use the GUA after >its lifetime expires is okay as long as you remain disconnected, but this >isn't correct. > >The reason it isn't correct is that a GUA, used beyond its valid >lifetime, has the potential to be immediately invalidated when the WAN >reappears. When I say potential, it might seem like I mean that it's >something that could happen, but is unlikely. But we as protocol wonks >have no way to make that statement, because it depends on circumstances >we don't control=8Bit depends on the provider's upstream policy. > >So this means that if we arrange to kill the GUA when the WAN comes back, >if the GUA is no longer valid, then perfectly valid in-home streams will >be interrupted. We might say "oh, that's no problem, let the streams >that are running keep using the GUA." > >This is still a problem, though, because a device configured with a GUA >whose lifetime has expired will not know that its lifetime has expired, >because there is no way to communicate this: in IPv6, an address is valid >or it is not. We do get to play with preferred versus valid, and maybe >we could deprecate the address and hope that the node wouldn't try to use >it to connect anymore, but there's no mechanism for doing this in the >IPv6 protocol suite. > >So it's quite likely that when the WAN does reappear, the device will try >to use its GUA to communicate with devices off the local wire. If the >GUA is no longer valid, it will fail. OK I was following but now you are losing me. As soon as the WAN comes back up, the CE Router advertises itself as a Default router once again. If the GUA remains unchanged per a successful Rebind of the IA-PD then communication proceeds off the wire successfully. If the prefix changes or is no Longer Valid (see Side Question) communication off the wire breaks. How is this any different from any renumbering event today which requires breaking old connections? I see a valid point in here for using ULA for communication to avoid a renumbering event breaking in-home sessions, but I fail to see how using a GUA after its lease lifetime expires prior to link up resulting in any different action than using a GUA whose lease is still valid but which is no longer routed due to a renumbering event encountered when the link comes up assuming no explicit reply to the REBIND with valid timer equal to 0? Side Question: Is the expected response to a Requesting Router Rebind event on link bounce for the Server to respond with NotOnLink status as per 18.1.8 of RCC3315 CONFIRM process? This is for a Confirm messages but since Confirm is not supported in RFC3633 it is a bit unclear what the Requesting Router is expected to do next, but I personally would expect a new SOLICIT. > >Whereas a ULA has limited scope; if a device is configured with a ULA, >and the WAN comes back, then the device can immediately get a valid GUA >and start communicating with it. Because all in-home connections are >using the ULA, they are not interrupted. > >Of course, in-home connections that started out using the GUA and >survived the loss of the WAN connection will die when the valid lifetime >of the GUA expires. This is a good reason to try to arrange for all >in-home connections to use ULAs always, even when we have a WAN >connection. > >I realize I'm just reiterating things that have been said before, but >given that we are still hearing the notion of keeping the GUA on WAN >loss, I think it's worth walking through the argument again. > Jason 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 cb.list6@gmail.com Wed Feb 22 10:59:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB4A21F862D for ; Wed, 22 Feb 2012 10:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bBuGneeys2a for ; Wed, 22 Feb 2012 10:59:13 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id BFC7621F85B8 for ; Wed, 22 Feb 2012 10:59:09 -0800 (PST) Received: by dakl33 with SMTP id l33so341560dak.31 for ; Wed, 22 Feb 2012 10:59:09 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.194.8 as permitted sender) client-ip=10.68.194.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.194.8 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.194.8]) by 10.68.194.8 with SMTP id hs8mr1322923pbc.113.1329937149672 (num_hops = 1); Wed, 22 Feb 2012 10:59:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HK3khJUNeakCTaz/opbVBojJOdob0jkhj5uno9iYWqA=; b=U1XXUaE+KhDzoaW66IWMPqfWwlafMBge/TQ7ly2bRPBw8Juk5MHiMdgMU4nZtNMMCz dxmPJivVWZ5bGjFGitoH5O4FjAtogD5+PHBUFAKJuP3OgVo8K2IVHwKPtiRCuf07i8a6 ZUmSOBYy3d9z9XqTOqNwlPGmeUaTmXVvuXqOY= MIME-Version: 1.0 Received: by 10.68.194.8 with SMTP id hs8mr1023572pbc.113.1329937149597; Wed, 22 Feb 2012 10:59:09 -0800 (PST) Received: by 10.142.99.12 with HTTP; Wed, 22 Feb 2012 10:59:09 -0800 (PST) In-Reply-To: <190FFDFA-2901-437A-BFBF-E598F56A6120@laposte.net> References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> <190FFDFA-2901-437A-BFBF-E598F56A6120@laposte.net> Date: Wed, 22 Feb 2012 10:59:09 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:59:18 -0000 On Wed, Feb 22, 2012 at 2:40 AM, R=E9mi Despr=E9s wrote: > Cameron, > It seems we are close to common understanding. > More below. > Yes, I do believe that is the case. Once again, thanks for your time in reviewing this work. If i may summarize your remaining technical concerns: 1. The CLAT will claim the /96 on the LAN via NDP or by marking the /96 as used in the local DHCPv6 server of the CLAT. In the case of non-DHCPv6 LAN clients, I believe this is normal NDP action for a router to claim it's addresses to avoid address conflict. I believe you said you are OK with this action as long as the draft is clear on it. 2. You believe the scenario for operation without the DNS64 is confusing in its current form. We can add a section that explicitly explains this scenario vs DNS64 scenario, is that ok? 3. Cameron will do a detailed technical review of 4RD-U and submit comments to Softwire. More in line > Le 2012-02-21 =E0 20:34, Cameron Byrne a =E9crit : > ... >> On Tue, Feb 21, 2012 at 10:42 AM, R=E9mi Despr=E9s wrote: > ... >>>>> Aren't NAT64s always coupled with DNS64s, as seems to be implied by a= ll scenarios of RFC6144? >>> >>> An answer to this? >>> >> >> Sorry i missed this earlier. >> >> In the case for RFC6144 to replace NAT-PT functionality, yes a DNS64 >> and NAT64 must be coupled to replace NAT-PT functions. >> >> But, RFC6146 and RFC6147 stand on their own. =A0There is no explicit >> coupling required or shared state between NAT64 and DNS64 for them to >> perform their atomic functions. =A0Meaning, any conforming packet >> (Pref64+32bit IPv4 destination address) may be received by an RFC6146 >> stateful NAT64 and be translated. =A0A properly configured CLAT that >> knows the Pref64 may received IPv4 packets and translate them via >> RFC6145 to a PLAT without any queries or interactions with the DNS64. > > I don't think a NAT64 that wouldn't work for IPv6-only hosts is a scenari= o that needs to be mentioned, especially since it contradicts an existing R= FC. > IMHO, stating that, with a CE architecture like that of the 464XLAT draft= , a stateless CE can work with a stateful NAT64 is enough. > Adding that it can work without DNS64 is AFAIK at best unnecessary, at wo= rst confusing. > That could advantageously be deleted (IMHO). > We'd like to keep it, since DNS64 is not always available or fit for a given network. Others have submitted feedback on list that they believe it is important for hosts to be able to use the DNS server of their choice, not the provider DNS64. We can add a section that makes the packet flow for operation without a DNS64 clear, would that help? > ... >>>>>>> Why, then, say "In the best case, the CLAT will have a dedicated /6= 4" >>>>>>> >>>>>> >>>>>> It just seems cleaner to me to have a dedicated /64 if it is >>>>>> available. =A0Operationally, aside from the NDP claiming the /96, th= ere >>>>>> is no difference to have dedicated or not dedicated. >>>>> >>>>> Understood, but: >>>>> - Claiming a /96 on a link seems new to me (is there an existing refe= rence?) >>>> >>>> It does not need to claim the /96 as a whole. =A0The CLAT will do NDP >>>> with the idea that each /128 in the /96 is owned by the CLAT as a >>>> virtual address. >>> >>> Was understood. >>> >>>> I have seen this behavior in NAT-PT deployments, but i do not see it >>>> specifically declared in the NAT-PT RFC. >>> >>> Right, it seems to be new material as far as IETF is concerned. >>> >> >> NDP for a host address should not be new material. > > Nothing is new in your proposal for hosts, right, but NDP operation IS mo= dified in CE routers. > >> As i mentioned >> before, we can treat each address in the /96 as a host address on the >> CLAT, and the interactions are normal for NDP host addresses. > > Understood. > The fact that this is new in the router CE is not a problem AFAIAC, but p= rovided new pieces of design are clearly identified. > To be clear, you are OK with the NDP action on the CE? We can add language to make it more clear in the draft. >> Alternatively, we may view the CLAT in terms of proxy NDP >> http://tools.ietf.org/html/rfc4861#section-7.2.8 > > Doesn't this require support of RFC3810 (Multicast Listener Discovery Ver= sion 2 (MLDv2) for IPv6)? > That could be part of the specification, but would AFAIK would be a const= raint. > I am open to discussion on the right path forward for this. >> The CLAT is willing to accept packet destine to the /96 on behalf of >> the IPv4 internet, and the NDP actions are defined as existing Proxy >> NDP. >> >> Thoughts on one verse the other? > > My thought is that BOTH can be AVOIDED. > It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix that d= iffers from all valid native IPv6 prefixes. Yes, in the draft, we state a dedicated /64 for the purpose of translation is best. But, we also recognize that is not always available, such is the case for mobile networks. > This is easy to have, and is part of the 4rd-U proposal. > The architecture you propose can easily benefit from it, simply by adding= its scenario as a particular one of the 4rd-U general scheme. > >>> I think I understand your motivations, and hope you can understand thos= e of draft-ietf-softwire-stateless-4v6-motivation. >>> >> >> Yes, and thanks again for your careful review and attention to the 464XL= AT draft > > I confirm that IMHO your draft brings quite useful new material. > > If you can take time to look at http://tools.ietf.org/html/draft-despres-= softwire-4rd-u-03, my hope is that you will understand that coordination be= tween its contents and that of your draft should be useful. > I will do this, but first my time is prioritized in resolving technical issues of 464XLAT CB > Regards, > RD > > > > >> >> CB >> >>> Regards, >>> RD >>> >>> >>> > From bs7652@att.com Wed Feb 22 11:01:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED75021E8026 for ; Wed, 22 Feb 2012 11:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEYQSKqhPnag for ; Wed, 22 Feb 2012 11:01:11 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id CAC5821E8028 for ; Wed, 22 Feb 2012 11:01:10 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1329937269!16894903!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22467 invoked from network); 22 Feb 2012 19:01:09 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Feb 2012 19:01:09 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1MIxZjq011794; Wed, 22 Feb 2012 13:59:37 -0500 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1MIxT4c011592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 13:59:29 -0500 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint03.pst.cso.att.com (RSA Interceptor); Wed, 22 Feb 2012 14:00:42 -0500 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.249]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 14:00:42 -0500 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Ted Lemon Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAcfMqAAADK0NAACxYSAAACJwsAAAMsj4AAANXVAAAAtJsAAAd7FHA= Date: Wed, 22 Feb 2012 19:00:41 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110424C7@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> In-Reply-To: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.164.202.123] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:01:12 -0000 > > The reason it isn't correct is that a GUA, used beyond its valid > lifetime, has the potential to be immediately invalidated when the WAN > reappears. A GUA has the potential to be immediately invalidated when the WAN re-appea= rs, no matter what its valid lifetime is. Consider the following real-life scenario: IPv6 connection is via 6rd. IPv4 address changes every time the IPv4 connection goes down and then up, = no matter what the lease was on the original IPv4 address. This happens a l= ot in the IPv4 world. IPv6 is down when IPv4 is down. IPv6 prefix is based on the IPv4 address, so it will change every time the = IPv4 address changes. So the original IPv6 prefix may no longer be useful for Internet connectivi= ty, even if it has time left on the original "valid" timer. If sudden GUA address/prefix changes are a problem, then I think it would b= e best to consider this independent of whether or not GUAs are used beyond = their valid lifetimes, when the WAN is down. I don't think that such use ma= kes the problem any worse. Barbara From bs7652@att.com Wed Feb 22 11:02:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D34F21F86A6 for ; Wed, 22 Feb 2012 11:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.374 X-Spam-Level: X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ2WQsCiu2uu for ; Wed, 22 Feb 2012 11:02:50 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id C72D021F869D for ; Wed, 22 Feb 2012 11:02:50 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-12.tower-120.messagelabs.com!1329937369!50846784!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24252 invoked from network); 22 Feb 2012 19:02:50 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Feb 2012 19:02:50 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1MJ1FbM014834; Wed, 22 Feb 2012 14:01:16 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1MJ1Dun014754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 14:01:13 -0500 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint04.pst.cso.att.com (RSA Interceptor); Wed, 22 Feb 2012 14:02:41 -0500 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.249]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 14:02:41 -0500 From: "STARK, BARBARA H" To: Ted Lemon , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAcfMqAAADK0NAACxYSAAACJwsAAAMsj4AAANXVAAAAtJsAAAMVnIAAChYmUA== Date: Wed, 22 Feb 2012 19:02:40 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110424E7@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> In-Reply-To: <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.164.202.123] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:02:51 -0000 > > Renumbering after a link outage shouldn't be very frequent, right? With 6rd, on dynamically assigned IPv4 connections, we're seeing it a lot. Barbara From Ted.Lemon@nominum.com Wed Feb 22 11:19:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CA021F8562 for ; Wed, 22 Feb 2012 11:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.508 X-Spam-Level: X-Spam-Status: No, score=-106.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXbXEdkLSvVB for ; Wed, 22 Feb 2012 11:19:28 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 87C4B21F855F for ; Wed, 22 Feb 2012 11:19:28 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT0U/wFHVOUXf+4zQxmxGUotj+BquI2Kl@postini.com; Wed, 22 Feb 2012 11:19:28 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AC2791B8341 for ; Wed, 22 Feb 2012 11:19:27 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A5252190097; Wed, 22 Feb 2012 11:19:27 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Wed, 22 Feb 2012 11:19:27 -0800 From: Ted Lemon To: "STARK, BARBARA H" Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAixh6AAAuAUgAAAGCPAAACJwsAAAMskIAAANWIAAAAtOcAAANvnYAAAKekAA== Date: Wed, 22 Feb 2012 19:19:27 +0000 Message-ID: References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <2D09D61DDFA73D4C884805CC7865E6110424C7@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110424C7@GAALPA1MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_CDCC1511227C4180A3F2C6F1A4BB0187nominumcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:19:29 -0000 --_000_CDCC1511227C4180A3F2C6F1A4BB0187nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Feb 22, 2012, at 2:00 PM, "STARK, BARBARA H" > wrote: If sudden GUA address/prefix changes are a problem, then I think it would b= e best to consider this independent of whether or not GUAs are used beyond = their valid lifetimes, when the WAN is down. I don't think that such use ma= kes the problem any worse. This argument isn't valid because you are using as an example a transition = technology with performance characteristics outside the intended envelope o= f the IPv6 protocol, and with it you are justifying an assumption about the= behavior of applications that are within the intended envelope of the IPv6= protocol. So yes, this is a real problem, but no, the fact that it is a problem does = not mean that instant deprecation of expired GUAs causes no additional harm= . --_000_CDCC1511227C4180A3F2C6F1A4BB0187nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <04669A4703E6AF47979C45406FAB90E7@nominum.com> Content-Transfer-Encoding: quoted-printable
On Feb 22, 2012, at 2:00 PM, "STARK, BARBARA H" <bs7652@att.com> wrote:
I= f sudden GUA address/prefix changes are a problem, then I think it would be = best to consider this independent of whether or not GUAs are used beyond th= eir valid lifetimes, when the WAN is down. I don't think that such use make= s the problem any worse.

This argument isn't valid because you are using as an example a transi= tion technology with performance characteristics outside the intended envel= ope of the IPv6 protocol, and with it you are justifying an assumption abou= t the behavior of applications that are within the intended envelope of the IPv6 protocol.

So yes, this is a real problem, but no, the fact that it is a problem = does not mean that instant deprecation of expired GUAs causes no additional= harm.

--_000_CDCC1511227C4180A3F2C6F1A4BB0187nominumcom_-- From brian.e.carpenter@gmail.com Wed Feb 22 11:41:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6DD21F8642 for ; Wed, 22 Feb 2012 11:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.503 X-Spam-Level: X-Spam-Status: No, score=-103.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMjLa2iMbsKC for ; Wed, 22 Feb 2012 11:41:40 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3183D21F8569 for ; Wed, 22 Feb 2012 11:41:36 -0800 (PST) Received: by eekc41 with SMTP id c41so139965eek.31 for ; Wed, 22 Feb 2012 11:41:35 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.213.21.208 as permitted sender) client-ip=10.213.21.208; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.213.21.208 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.213.21.208]) by 10.213.21.208 with SMTP id k16mr296440ebb.74.1329939695273 (num_hops = 1); Wed, 22 Feb 2012 11:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Gvil9OFKoPX0GKDGZRjLZI1WLIg+wkz3+YdGr/bS4s4=; b=oNgSMJXEmTVI6/HXyrDKZTLS8cUpwUwAVNv0sWEqZRngmWaeaiA1CntLPkZboLrBJk RpzUMbOy7Lve5qILvpSKqTXYTX8PTO4XF/OtHY6fa9pvpTBJH4cA9BUxd+1YusfWgits NgoeV4zQ68ngzEQhAhoty9u3kDpexh4/bBVWI= Received: by 10.213.21.208 with SMTP id k16mr241941ebb.74.1329939694985; Wed, 22 Feb 2012 11:41:34 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id c16sm105998144eei.1.2012.02.22.11.41.30 (version=SSLv3 cipher=OTHER); Wed, 22 Feb 2012 11:41:34 -0800 (PST) Message-ID: <4F4544E3.3090907@gmail.com> Date: Thu, 23 Feb 2012 08:41:23 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <021601ccf0f3$812952f0$837bf8d0$@com> <4F44A67D.2070203@redpill-linpro.com> <2D09D61DDFA73D4C884805CC7865E611042179@GAALPA1MSGUSR9N.ITServices.sbc.com> <348ECA23-D21C-4F10-BB28-708CE3B86249@iol.unh.edu> <03c301ccf173$ac9d3a20$05d7ae60$@com> In-Reply-To: <03c301ccf173$ac9d3a20$05d7ae60$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:41:42 -0000 On 2012-02-23 04:07, Dan Wing wrote: >> -----Original Message----- >> From: Timothy Winters [mailto:twinters@iol.unh.edu] >> Sent: Wednesday, February 22, 2012 6:06 AM >> To: STARK, BARBARA H >> Cc: Tore Anderson; Dan Wing; v6ops@ietf.org; draft-ietf-v6ops- >> 6204bis@tools.ietf.org >> Subject: Re: [v6ops] 6204bis and WAN disappearing >> >> Hello, >> The CE Routers that have participated in the IPv6 CE Events have >> implemented Tore/Barbara have stated. The CE Routers transmit an RA >> with a lifetime 0 but don't withdraw prefixes. > > I am glad there is high confidence that the spec is accurate. > > My worry, though, is it provides insufficient clarity towards hosts, > specifically that hosts should/shouldn't use ULA for communication > amongst themselves within the local network, and should/shouldn't use > ULA when advertising their presence via their rendezvous protocol > (e.g., mDNS). A sentence such as "With this functionality, hosts > using ULA will be able to continue normal operation during a lengthy > WAN outage" would be a nice addition. There's no doubt that homenets, and SOHOs, need to treat prefix renumbering as a normal event. This is just one of the scenarios that may cause it. However, I don't think the CPE spec should deal with this, beyond requiring ULA support in case that is part of the chosen solution. I'd rather see it as a homenet issue, with possible overlap with 6renum, although that is chartered for enterprise networks. Brian From bs7652@att.com Wed Feb 22 11:47:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8719121E802C for ; Wed, 22 Feb 2012 11:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsinNtZNUxrZ for ; Wed, 22 Feb 2012 11:47:30 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 880DA21E8025 for ; Wed, 22 Feb 2012 11:47:30 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1329940049!16970659!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3563 invoked from network); 22 Feb 2012 19:47:29 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Feb 2012 19:47:29 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1MJjt2u021354; Wed, 22 Feb 2012 14:45:56 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1MJjpl5021261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 14:45:51 -0500 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (gaalpa1msghub9a.itservices.sbc.com [130.8.36.87]) by sflint04.pst.cso.att.com (RSA Interceptor); Wed, 22 Feb 2012 14:47:05 -0500 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.249]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 14:47:05 -0500 From: "STARK, BARBARA H" To: Ted Lemon Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAcfMqAAADK0NAACxYSAAACJwsAAAMsj4AAANXVAAAAtJsAAAd7FHD//+TigIAAUk8Q Date: Wed, 22 Feb 2012 19:47:04 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110425A1@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <2D09D61DDFA73D4C884805CC7865E6110424C7@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.164.202.123] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6110425A1GAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:47:32 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6110425A1GAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The IPv6 hosts (and applications that reside on them) inside the home netwo= rk won't know the difference. CE-router originated native vs 6rd IPv6 inter= faces all look alike from inside the LAN. Therefore, I believe that my assu= mption that LAN-based apps will behave the same, no matter what the WAN IPv= 6 mechanism is, is well-justified. Instant deprecation of GUAs does appear to cause problems. Whether or not t= he original valid lifetime (as set by the access network) has expired, whil= e the WAN is down. It is the instant deprecation of GUAs that apps had been= told would be valid for awhile yet, that causes problems. Preventing CE ro= uters from extending the valid lifetime of expired GUAs when the WAN is dow= n will not make the problem go away. Barbara If sudden GUA address/prefix changes are a problem, then I think it would b= e best to consider this independent of whether or not GUAs are used beyond = their valid lifetimes, when the WAN is down. I don't think that such use ma= kes the problem any worse. This argument isn't valid because you are using as an example a transition = technology with performance characteristics outside the intended envelope o= f the IPv6 protocol, and with it you are justifying an assumption about the= behavior of applications that are within the intended envelope of the IPv6= protocol. So yes, this is a real problem, but no, the fact that it is a problem does = not mean that instant deprecation of expired GUAs causes no additional harm= . --_000_2D09D61DDFA73D4C884805CC7865E6110425A1GAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The IPv6 hosts (and appli= cations that reside on them) inside the home network won’t know the d= ifference. CE-router originated native vs 6rd IPv6 interfaces all look alike from inside the LAN. Therefore, I believe that my assumptio= n that LAN-based apps will behave the same, no matter what the WAN IPv6 mec= hanism is, is well-justified.

 <= /p>

Instant deprecation of GU= As does appear to cause problems. Whether or not the original valid lifetim= e (as set by the access network) has expired, while the WAN is down. It is the instant deprecation of GUAs that apps had been told= would be valid for awhile yet, that causes problems. Preventing CE routers= from extending the valid lifetime of expired GUAs when the WAN is down wil= l not make the problem go away.

Barbara=

 <= /p>

If sudden GUA address/pre= fix changes are a problem, then I think it would be best to consider this i= ndependent of whether or not GUAs are used beyond their valid lifetimes, when the WAN is down. I don't think that such use makes t= he problem any worse.

 

This argument isn't valid because you are using as a= n example a transition technology with performance characteristics outside = the intended envelope of the IPv6 protocol, and with it you are justifying = an assumption about the behavior of applications that are within the intended envelope of the IPv6 protocol.

 

So yes, this is a real problem, but no, the fact tha= t it is a problem does not mean that instant deprecation of expired GUAs ca= uses no additional harm.

 

--_000_2D09D61DDFA73D4C884805CC7865E6110425A1GAALPA1MSGUSR9NIT_-- From Ted.Lemon@nominum.com Wed Feb 22 12:27:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2BE21E804A for ; Wed, 22 Feb 2012 12:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.514 X-Spam-Level: X-Spam-Status: No, score=-106.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHyIZhMscLOc for ; Wed, 22 Feb 2012 12:27:39 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 362D421E8014 for ; Wed, 22 Feb 2012 12:27:39 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKT0VPurIE5S1A4akim87u3BnTLsg3hJ9P@postini.com; Wed, 22 Feb 2012 12:27:39 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2D9751B8389 for ; Wed, 22 Feb 2012 12:27:38 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2416F19005D; Wed, 22 Feb 2012 12:27:38 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Wed, 22 Feb 2012 12:27:38 -0800 From: Ted Lemon To: "STARK, BARBARA H" Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAixh6AAAuAUgAAAGCPAAACJwsAAAMskIAAANWIAAAAtOcAAANvnYAAAKekAAAA9w8AAAFqQIA= Date: Wed, 22 Feb 2012 20:27:37 +0000 Message-ID: <80717816-FFE2-4D16-9B45-FB6439401F2F@nominum.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <2D09D61DDFA73D4C884805CC7865E6110424C7@GAALPA1MSGUSR9N.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6110425A1@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110425A1@GAALPA1MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_80717816FFE24D169B45FB6439401F2Fnominumcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 20:27:40 -0000 --_000_80717816FFE24D169B45FB6439401F2Fnominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Feb 22, 2012, at 2:47 PM, "STARK, BARBARA H" > wrote: The IPv6 hosts (and applications that reside on them) inside the home netwo= rk won=92t know the difference. CE-router originated native vs 6rd IPv6 int= erfaces all look alike from inside the LAN. Therefore, I believe that my as= sumption that LAN-based apps will behave the same, no matter what the WAN I= Pv6 mechanism is, is well-justified. That's not what I meant. What I meant is that the fact that a network pro= visioned with 6rd behaves in a suboptimal way isn't something we need to co= nsider as significant in the long run. 6rd is a transition technology. = So we should optimize our solution for the long term, and not use the bad b= ehavior of transition technology as a justification for allowing the soluti= on to continue to be broken once the transition technology is no longer in = use. --_000_80717816FFE24D169B45FB6439401F2Fnominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Feb 22, 2012, at 2:47 PM, "STARK, BARBARA H" <bs7652@att.com> wrote:
The IPv6 hosts (and applications that reside on them) inside the home network = won=92t know the difference. CE-router originated native vs 6rd IPv6 interf= aces all look alike from inside the LAN. Therefore, I believe that my assum= ption that LAN-based apps will behave the same, no matter what the WAN IPv6 mechanism is, is well-justified.

That's not what I meant.   What I meant is that the fact that a n= etwork provisioned with 6rd behaves in a suboptimal way isn't something we = need to consider as significant in the long run.   6rd is a transition= technology.   So we should optimize our solution for the long term, and not use the bad behavior of transition technology a= s a justification for allowing the solution to continue to be broken once t= he transition technology is no longer in use.

--_000_80717816FFE24D169B45FB6439401F2Fnominumcom_-- From shemant@cisco.com Wed Feb 22 12:56:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D427821E8014 for ; Wed, 22 Feb 2012 12:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.078 X-Spam-Level: X-Spam-Status: No, score=-9.078 tagged_above=-999 required=5 tests=[AWL=1.520, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWvgBLz67bvd for ; Wed, 22 Feb 2012 12:56:54 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A7BB521E800F for ; Wed, 22 Feb 2012 12:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=15205; q=dns/txt; s=iport; t=1329944214; x=1331153814; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=1rpUF5Th1Xlg6i4iy5+9IbCTdW/+Q7rbiKHv6F45k7o=; b=Yimu4RQaHaTrx7RIIrKgfpf9JhLiUll7YXK4oLXTRAebFffNZmlz1BrF S84SCB8aOl5Cduj9AB2RJ71M+DCcKWEvf4fzXY8wpm+oFcssaFxj0kHEx qYClDtsdc3C0nkux2AZ9Baa3pmhv0w4OUudZ1hrByf/2Yd81hNfpoAkXl A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMZVRU+tJV2d/2dsb2JhbABEsk2BB4FzAQEBBBIBCREDSQwEAgEIEQQBAQsGFwEGAUUJCAIEARIIGqElAZ58iWKCbAkCEwMFCQNBGoULfwyCTWMEiE+fdYE0 X-IronPort-AV: E=Sophos;i="4.73,466,1325462400"; d="scan'208,217";a="61028972" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 22 Feb 2012 20:56:54 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q1MKusfn013540; Wed, 22 Feb 2012 20:56:54 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 14:56:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF1A4.819EDFFA" Date: Wed, 22 Feb 2012 14:56:52 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3041164B5@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAixh6AAAuAUgAAAGCPAAACJwsAAAMskIAAANWIAAAJBDJA References: From: "Hemant Singh (shemant)" To: "Ted Lemon" , "Jason Weil" X-OriginalArrivalTime: 22 Feb 2012 20:56:54.0100 (UTC) FILETIME=[81C4F140:01CCF1A4] Cc: draft-ietf-v6ops-6204bis@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 20:56:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF1A4.819EDFFA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Folks, please read RFC 4862 for timing out a prefix on prefix Valid Lifetime expiry and the 2 hours rule from section 5.5.3. Further read section 5.5.4 of the same RFC and this text between squared braces below. [A preferred address becomes deprecated when its preferred lifetime expires. A deprecated address SHOULD continue to be used as a source address in existing communications, but SHOULD NOT be used to initiate new communications if an alternate (non-deprecated) address of sufficient scope can easily be used instead.] Then read this bullet from RFC6204bis. [L-14: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable message, code 5 (Source address failed ingress/egress policy) for packets forwarded to it that use an address from a prefix that has been deprecated.] Lastly, the LAN requirements of RFC6204 were agreed upon when RFC6204 was published and also nailed down when RFC6204bis was split into WAN and LAN documents but RFC 6204 LAN sections were retained. Thus the ULA stays in rfc6204bis but no new LAN requirements qualify for rfc6204bis without new consensus from the WG. I do not see any issue with rfc6204bis there we are sending so many emails on this thread. Regards, Hemant =20 -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: Wednesday, February 22, 2012 12:02 PM To: Jason Weil Cc: Dan Wing (dwing); Timothy Winters; STARK, BARBARA H; v6ops@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing Various people have made the claim that continuing to use the GUA after its lifetime expires is okay as long as you remain disconnected, but this isn't correct. The reason it isn't correct is that a GUA, used beyond its valid lifetime, has the potential to be immediately invalidated when the WAN reappears. When I say potential, it might seem like I mean that it's something that could happen, but is unlikely. But we as protocol wonks have no way to make that statement, because it depends on circumstances we don't control-it depends on the provider's upstream policy. So this means that if we arrange to kill the GUA when the WAN comes back, if the GUA is no longer valid, then perfectly valid in-home streams will be interrupted. We might say "oh, that's no problem, let the streams that are running keep using the GUA." This is still a problem, though, because a device configured with a GUA whose lifetime has expired will not know that its lifetime has expired, because there is no way to communicate this: in IPv6, an address is valid or it is not. We do get to play with preferred versus valid, and maybe we could deprecate the address and hope that the node wouldn't try to use it to connect anymore, but there's no mechanism for doing this in the IPv6 protocol suite. So it's quite likely that when the WAN does reappear, the device will try to use its GUA to communicate with devices off the local wire. If the GUA is no longer valid, it will fail. Whereas a ULA has limited scope; if a device is configured with a ULA, and the WAN comes back, then the device can immediately get a valid GUA and start communicating with it. Because all in-home connections are using the ULA, they are not interrupted. Of course, in-home connections that started out using the GUA and survived the loss of the WAN connection will die when the valid lifetime of the GUA expires. This is a good reason to try to arrange for all in-home connections to use ULAs always, even when we have a WAN connection. I realize I'm just reiterating things that have been said before, but given that we are still hearing the notion of keeping the GUA on WAN loss, I think it's worth walking through the argument again. ------_=_NextPart_001_01CCF1A4.819EDFFA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [v6ops] 6204bis and WAN disappearing

Folks, = please read RFC 4862 for timing out a prefix on prefix Valid Lifetime expiry and the 2 hours rule from section = 5.5.3.  Further read section 5.5.4 of the same RFC and this text = between squared braces below.

[A preferred address becomes = deprecated when its preferred lifetime

 expires.  A deprecated address SHOULD continue to be = used as a source

 address in existing communications, but SHOULD NOT be used = to

 initiate new communications if an alternate (non-deprecated) = address

 of = sufficient scope can easily be used instead.]

Then read this bullet from = RFC6204bis.

[L-14:  The IPv6 CE router MUST send an ICMPv6 Destination = Unreachable

        message, code 5 (Source = address failed ingress/egress policy)

        for packets forwarded to = it that use an address from a prefix

        = that has been = deprecated.]

Lastly, the LAN requirements of RFC6204 were agreed upon when RFC6204 was published and also = nailed down when RFC6204bis was split into WAN and LAN = documents but RFC 6204 LAN sections were retained.  Thus the ULA stays in = rfc6204bis but no new LAN requirements qualify for rfc6204bis without = new consensus from the WG.

I do not see any issue with rfc6204bis there we are = sending so many emails on this thread.

Regards,

Hemant

 

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, February 22, 2012 12:02 PM
To: Jason Weil
Cc: Dan Wing (dwing); Timothy Winters; STARK, BARBARA H; v6ops@ietf.org; = draft-ietf-v6ops-6204bis@tools.ietf.org
Subject: Re: [v6ops] 6204bis and WAN disappearing

Various people have made the claim that continuing = to use the GUA after its lifetime expires is okay as long as you remain = disconnected, but this isn't correct.

The reason = it isn't correct is that a GUA, used beyond its valid lifetime, has the = potential to be immediately invalidated when the WAN = reappears.   When I say potential, it might seem like I mean = that it's something that could happen, but is unlikely.   But = we as protocol wonks have no way to make that statement, because it = depends on circumstances we don't control—it depends on the = provider's upstream policy.

So this = means that if we arrange to kill the GUA when the WAN comes back, if the = GUA is no longer valid, then perfectly valid in-home streams will be = interrupted.   We might say "oh, that's no problem, let = the streams that are running keep using the GUA."

This is = still a problem, though, because a device configured with a GUA whose = lifetime has expired will not know that its lifetime has expired, = because there is no way to communicate this: in IPv6, an address is = valid or it is not.   We do get to play with preferred versus = valid, and maybe we could deprecate the address and hope that the node = wouldn't try to use it to connect anymore, but there's no mechanism for = doing this in the IPv6 protocol suite.

So it's = quite likely that when the WAN does reappear, the device will try to use = its GUA to communicate with devices off the local wire.   If = the GUA is no longer valid, it will fail.

Whereas a = ULA has limited scope; if a device is configured with a ULA, and the WAN = comes back, then the device can immediately get a valid GUA and start = communicating with it.   Because all in-home connections are = using the ULA, they are not interrupted.

Of course, = in-home connections that started out using the GUA and survived the loss = of the WAN connection will die when the valid lifetime of the GUA = expires.   This is a good reason to try to arrange for all = in-home connections to use ULAs always, even when we have a WAN = connection.

I realize = I'm just reiterating things that have been said before, but given that = we are still hearing the notion of keeping the GUA on WAN loss, I think = it's worth walking through the argument again.

------_=_NextPart_001_01CCF1A4.819EDFFA-- From bs7652@att.com Wed Feb 22 13:03:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E3621E8028 for ; Wed, 22 Feb 2012 13:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFeRDTGy-CTg for ; Wed, 22 Feb 2012 13:03:33 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 277B321F864D for ; Wed, 22 Feb 2012 13:03:32 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1329944610!14369485!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26236 invoked from network); 22 Feb 2012 21:03:30 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Feb 2012 21:03:30 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1ML1u2i013753; Wed, 22 Feb 2012 16:01:57 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1ML1tEB013730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 16:01:55 -0500 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint04.pst.cso.att.com (RSA Interceptor); Wed, 22 Feb 2012 16:03:15 -0500 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.249]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.01.0355.002; Wed, 22 Feb 2012 16:03:15 -0500 From: "STARK, BARBARA H" To: Ted Lemon Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAcfMqAAADK0NAACxYSAAACJwsAAAMsj4AAANXVAAAAtJsAAAd7FHD//+TigIAAUk8Q///AvYCAAEvnsA== Date: Wed, 22 Feb 2012 21:03:13 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61104266B@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <2D09D61DDFA73D4C884805CC7865E6110424C7@GAALPA1MSGUSR9N.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6110425A1@GAALPA1MSGUSR9N.ITServices.sbc.com> <80717816-FFE2-4D16-9B45-FB6439401F2F@nominum.com> In-Reply-To: <80717816-FFE2-4D16-9B45-FB6439401F2F@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [90.164.202.123] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E61104266BGAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 21:03:35 -0000 --_000_2D09D61DDFA73D4C884805CC7865E61104266BGAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks. I understand now. But I disagree. I have no direct knowledge of suc= h things, but my crystal ball leads me to believe that transition technolog= ies like 6rd will be around for many years. Longer than the average lifespa= n of a CE router. As Brian suggested, I would like to see homenet tackle the question of LAN = renumbering. And I think it is outside the scope of 6204bis to say anything= on this topic that it doesn't already say. Barbara From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, February 22, 2012 3:28 PM To: STARK, BARBARA H Cc: R=E9mi Despr=E9s; Jason Weil; draft-ietf-v6ops-6204bis@tools.ietf.org; = v6ops@ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing On Feb 22, 2012, at 2:47 PM, "STARK, BARBARA H" > wrote: The IPv6 hosts (and applications that reside on them) inside the home netwo= rk won't know the difference. CE-router originated native vs 6rd IPv6 inter= faces all look alike from inside the LAN. Therefore, I believe that my assu= mption that LAN-based apps will behave the same, no matter what the WAN IPv= 6 mechanism is, is well-justified. That's not what I meant. What I meant is that the fact that a network pro= visioned with 6rd behaves in a suboptimal way isn't something we need to co= nsider as significant in the long run. 6rd is a transition technology. = So we should optimize our solution for the long term, and not use the bad b= ehavior of transition technology as a justification for allowing the soluti= on to continue to be broken once the transition technology is no longer in = use. --_000_2D09D61DDFA73D4C884805CC7865E61104266BGAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks. I understand now. But I disagre= e. I have no direct knowledge of such things, but my crystal ball leads me = to believe that transition technologies like 6rd will be around for many years. Longer than the average lifespan of a CE router.

 

As Brian suggested, I would like to see= homenet tackle the question of LAN renumbering. And I think it is outside = the scope of 6204bis to say anything on this topic that it doesn’t already say.

Barbara

 <= /p>

From: Ted Lemo= n [mailto:Ted.Lemon@nominum.com]
Sent: Wednesday, February 22, 2012 3:28 PM
To: STARK, BARBARA H
Cc: R=E9mi Despr=E9s; Jason Weil; draft-ietf-v6ops-6204bis@tools.iet= f.org; v6ops@ietf.org
Subject: Re: [v6ops] 6204bis and WAN disappearing<= /p>

 

On Feb 22, 2012, at 2:47 PM, "STARK, BARBARA H&= quot; <bs7652@att.com> wrote:

The IPv6 hosts (and appli= cations that reside on them) inside the home network won’t know the d= ifference. CE-router originated native vs 6rd IPv6 interfaces all look alike from inside the LAN. Therefore, I believe that my assumptio= n that LAN-based apps will behave the same, no matter what the WAN IPv6 mec= hanism is, is well-justified.

 

That's not what I meant.   What I meant is that= the fact that a network provisioned with 6rd behaves in a suboptimal way i= sn't something we need to consider as significant in the long run.   6= rd is a transition technology.   So we should optimize our solution for the long term, and not use the bad behavior of t= ransition technology as a justification for allowing the solution to contin= ue to be broken once the transition technology is no longer in use.

 

--_000_2D09D61DDFA73D4C884805CC7865E61104266BGAALPA1MSGUSR9NIT_-- From ichiroumakino@gmail.com Wed Feb 22 13:14:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507C821F85FD for ; Wed, 22 Feb 2012 13:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eps0023x9tj for ; Wed, 22 Feb 2012 13:14:43 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6CE21F85E5 for ; Wed, 22 Feb 2012 13:14:43 -0800 (PST) Received: by wibhm9 with SMTP id hm9so402329wib.31 for ; Wed, 22 Feb 2012 13:14:42 -0800 (PST) Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.99.100 as permitted sender) client-ip=10.180.99.100; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.180.99.100 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com Received: from mr.google.com ([10.180.99.100]) by 10.180.99.100 with SMTP id ep4mr18935wib.7.1329945282245 (num_hops = 1); Wed, 22 Feb 2012 13:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=n4D8HK4EPdprlObW+xns6hyTHxYtdJ+GE3G/XssjzLE=; b=Y4R3DmNDOcVP4fp0/u1A3frmyqNdA8XHFgjW7R3iL7IszA0INAvHdWa4YWhylHK7pF 3yo07HLEpujrbfQWFPsdImXcHURqP41m8n2ZcTExCFyMwertg5QGk9N+GF4kdmOEEZ6W /rwkKmqwa8faxlfLAfKbkHlUbCgF4TgRVUt+0= Received: by 10.180.99.100 with SMTP id ep4mr14458wib.7.1329945282141; Wed, 22 Feb 2012 13:14:42 -0800 (PST) Received: from dhcp-10-61-97-161.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fw5sm283504wib.0.2012.02.22.13.14.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 13:14:41 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61104266B@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Wed, 22 Feb 2012 22:14:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <2D09D61DDFA73D4C884805CC7865E6110424C7@GAALPA1MSGUSR9N.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6110425A1@GAALPA1MSGUSR9N.ITServices.sbc.com> <80717816-FFE2-4D16-9B45-FB6439401F2F@nominum.com> <2D09D61DDFA73D4C884805CC7865E61104266B@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1257) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 21:14:44 -0000 > Thanks. I understand now. But I disagree. I have no direct knowledge = of such things, but my crystal ball leads me to believe that transition = technologies like 6rd will be around for many years. Longer than the = average lifespan of a CE router. > =20 > As Brian suggested, I would like to see homenet tackle the question of = LAN renumbering. And I think it is outside the scope of 6204bis to say = anything on this topic that it doesn=92t already say. right, and regardless of transition technologies you will have two = variants of renumbering in the home. flash/instant or controlled/overlapping. cheers, Ole= From jason.weil@twcable.com Wed Feb 22 16:26:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BA521F85F2 for ; Wed, 22 Feb 2012 16:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2nY+ACGD9lz for ; Wed, 22 Feb 2012 16:26:43 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1336C21F85F1 for ; Wed, 22 Feb 2012 16:26:42 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,466,1325480400"; d="scan'208";a="326707092" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Feb 2012 19:26:00 -0500 Received: from PRVPEXVS12.corp.twcable.com ([10.136.163.44]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 22 Feb 2012 19:26:42 -0500 From: "Weil, Jason" To: "Hemant Singh (shemant)" , Ted Lemon Date: Wed, 22 Feb 2012 19:26:42 -0500 Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: AczxwdDUY7SAEatYSDSxdIaDS4kHaA== Message-ID: In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3041164B5@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-v6ops-6204bis@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 00:26:44 -0000 Hemant, I don't believe any substantive changes to 6204bis have been suggested. The= only suggestion was the inclusion of the sentence that Dan suggested would= be useful. Here was Dan's suggestion: A sentence such as "With this functionality, hosts using ULA will be able to continue normal operation during a lengthy WAN outage" would be a nice addition. Thanks, Jason From: Hemant Singh > Date: Wed, 22 Feb 2012 15:56:52 -0500 To: Ted Lemon >, jason = weil > Cc: "Dan Wing (dwing)" >, Timothy W= inters >, "STARK, BARBARA= H" >, "v6ops@ietf.org" >, "draft-ietf-v6ops-6204bi= s@tools.ietf.org" > Subject: RE: [v6ops] 6204bis and WAN disappearing Folks, please read RFC 4862 for timing out a prefix on prefix Valid Lifetim= e expiry and the 2 hours rule from section 5.5.3. Further read section 5.5= .4 of the same RFC and this text between squared braces below. [A preferred address becomes deprecated when its preferred lifetime expires. A deprecated address SHOULD continue to be used as a source address in existing communications, but SHOULD NOT be used to initiate new communications if an alternate (non-deprecated) address of sufficient scope can easily be used instead.] Then read this bullet from RFC6204bis. [L-14: The IPv6 CE router MUST send an ICMPv6 Destination Unreachable message, code 5 (Source address failed ingress/egress policy) for packets forwarded to it that use an address from a prefix that has been deprecated.] Lastly, the LAN requirements of RFC6204 were agreed upon when RFC6204 was p= ublished and also nailed down when RFC6204bis was split into WAN and LAN do= cuments but RFC 6204 LAN sections were retained. Thus the ULA stays in rfc= 6204bis but no new LAN requirements qualify for rfc6204bis without new cons= ensus from the WG. I do not see any issue with rfc6204bis there we are sending so many emails = on this thread. Regards, Hemant -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, February 22, 2012 12:02 PM To: Jason Weil Cc: Dan Wing (dwing); Timothy Winters; STARK, BARBARA H; v6ops@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing Various people have made the claim that continuing to use the GUA after its= lifetime expires is okay as long as you remain disconnected, but this isn'= t correct. The reason it isn't correct is that a GUA, used beyond its valid lifetime, = has the potential to be immediately invalidated when the WAN reappears. W= hen I say potential, it might seem like I mean that it's something that cou= ld happen, but is unlikely. But we as protocol wonks have no way to make = that statement, because it depends on circumstances we don't control=97it d= epends on the provider's upstream policy. So this means that if we arrange to kill the GUA when the WAN comes back, i= f the GUA is no longer valid, then perfectly valid in-home streams will be = interrupted. We might say "oh, that's no problem, let the streams that ar= e running keep using the GUA." This is still a problem, though, because a device configured with a GUA who= se lifetime has expired will not know that its lifetime has expired, becaus= e there is no way to communicate this: in IPv6, an address is valid or it i= s not. We do get to play with preferred versus valid, and maybe we could = deprecate the address and hope that the node wouldn't try to use it to conn= ect anymore, but there's no mechanism for doing this in the IPv6 protocol s= uite. So it's quite likely that when the WAN does reappear, the device will try t= o use its GUA to communicate with devices off the local wire. If the GUA = is no longer valid, it will fail. Whereas a ULA has limited scope; if a device is configured with a ULA, and = the WAN comes back, then the device can immediately get a valid GUA and sta= rt communicating with it. Because all in-home connections are using the U= LA, they are not interrupted. Of course, in-home connections that started out using the GUA and survived = the loss of the WAN connection will die when the valid lifetime of the GUA = expires. This is a good reason to try to arrange for all in-home connecti= ons to use ULAs always, even when we have a WAN connection. I realize I'm just reiterating things that have been said before, but given= that we are still hearing the notion of keeping the GUA on WAN loss, I thi= nk it's worth walking through the argument again. ________________________________ 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 brian.e.carpenter@gmail.com Wed Feb 22 19:41:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCD311E8072 for ; Wed, 22 Feb 2012 19:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.504 X-Spam-Level: X-Spam-Status: No, score=-103.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orBhu-TznM92 for ; Wed, 22 Feb 2012 19:41:18 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC3121F850F for ; Wed, 22 Feb 2012 19:41:18 -0800 (PST) Received: by eekc41 with SMTP id c41so287510eek.31 for ; Wed, 22 Feb 2012 19:41:17 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.213.31.67 as permitted sender) client-ip=10.213.31.67; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.213.31.67 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.213.31.67]) by 10.213.31.67 with SMTP id x3mr91993ebc.73.1329968477836 (num_hops = 1); Wed, 22 Feb 2012 19:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=YIf7QUcB2AFJmJgNTJz4RjJqXLYiP1bdJejuM1TEKl4=; b=mRiSyfPcCtaK5VyRu8MIC4BvDvb1k1nZlNOq8TF+xZIHCyYAmXNCaT0drMVpcfHYSe kW1jd02Yk+CSTNKwOtWgwnwv+k98lVoKkGMBl4vpizh3W3o+EvwJdJcsLSrw5cHTRAU/ NTcP0S8ffCQi6m2jjeKDoLYRfcWcXD9t45OIY= Received: by 10.213.31.67 with SMTP id x3mr72604ebc.73.1329968477664; Wed, 22 Feb 2012 19:41:17 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n17sm340563eei.3.2012.02.22.19.41.15 (version=SSLv3 cipher=OTHER); Wed, 22 Feb 2012 19:41:17 -0800 (PST) Message-ID: <4F45B554.2060103@gmail.com> Date: Thu, 23 Feb 2012 16:41:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 03:41:19 -0000 Hi, This version has various updates due to comments from the WG. We are not asking for a meeting slot in Paris, but we'd like the chairs to put the question whether the WG wants to adopt this draft. In any case we still want more input to correct and expand the draft. Brian + Sheng -------- Original Message -------- Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt Date: Wed, 22 Feb 2012 14:30:09 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Guidance for Internet Content and Application Service Providers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-carpenter-v6ops-icp-guidance-03.txt Pages : 18 Date : 2012-02-22 This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to any enterprise network preparing for IPv6 users. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt _______________________________________________ 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 despres.remi@laposte.net Thu Feb 23 00:26:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E0321E8038 for ; Thu, 23 Feb 2012 00:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X23jvBNMQW0W for ; Thu, 23 Feb 2012 00:26:57 -0800 (PST) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id B4AEB21E8024 for ; Thu, 23 Feb 2012 00:26:55 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id dLSj1i00F37Y3f403LSjyR; Thu, 23 Feb 2012 09:26:45 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> Date: Thu, 23 Feb 2012 09:26:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 08:26:58 -0000 1. 2012-02-22 19:50, Ted Lemon: > On Feb 22, 2012, at 12:22 PM, R=E9mi Despr=E9s = wrote: >> Wouldn't it be possible, if it is invalidated to wait, before opening = again routes to the WAN, until the internal lifetime of the old one has = expired? >> Renumbering after a link outage shouldn't be very frequent, right?=20 >=20 > What I'm saying is that we don't have the capacity to say that this is = the case. It is dependent both on the connectivity model and ISP = policy. >=20 >> There is AFAIK the implicit assumption that all hosts support two = IPv6 addresses on a single interface. >> I don't think that OS X, for example, does it today. >> Then, If the WAN link breaks, all internal sessions are broken, even = if the IPv6 prefix doesn't change when the link comes back. >=20 > As far as I know OS X supports multiple IPv6 addresses. AFAIK, not for an ordinary user like me. > I don't know how well it does at address selection, but the OSX guys = are pretty smart, so I assume that they implemented ULA correctly. =20 > Might be worth checking out Indeed. 2. 2012-02-22 19:52, Ted Lemon: > On Feb 22, 2012, at 12:22 PM, R=E9mi Despr=E9s = wrote: >> Wouldn't it be possible, if it is invalidated to wait, before opening = again routes to the WAN, until the internal lifetime of the old one has = expired? >=20 > Oh, forgot to reply to this. The answer is that no, you can't, = because that is almost necessarily a long time. Doesn't the next sentence say the opposite, based on the existing = specification? > You can change the RA to deprecate the old GUA, > but then you pretty much have to cross your fingers and hope that the = host takes the new prefix lifetimes before it attempts any outgoing = connections. Even if it doesn't, it isn't a serious problem: the host is informed in = ICMPv6 that unreachability of the destination is due to ingress or = egress filtering (Type 1 code 5 per RFC4443). What it does next is implementation dependent, but checking its source = address makes sense. Besides, this only happens when ISPs change IPv6 prefix assignments, = which is always a problem for external connections. RD =20 From despres.remi@laposte.net Thu Feb 23 01:00:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F38721F8620 for ; Thu, 23 Feb 2012 01:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1OrFJ+JNlQR for ; Thu, 23 Feb 2012 01:00:27 -0800 (PST) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 4F80E21F861E for ; Thu, 23 Feb 2012 01:00:26 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id dM0P1i00D37Y3f403M0PJG; Thu, 23 Feb 2012 10:00:25 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 23 Feb 2012 10:00:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75C7DA3D-D5CA-440E-B39C-4342B877D15D@laposte.net> References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> <190FFDFA-2901-437A-BFBF-E598F56A6120@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 09:00:28 -0000 Cameron, Le 2012-02-22 =E0 19:59, Cameron Byrne a =E9crit : > On Wed, Feb 22, 2012 at 2:40 AM, R=E9mi Despr=E9s = wrote: >> Cameron, >> It seems we are close to common understanding. >> More below. >>=20 >=20 > Yes, I do believe that is the case. >=20 > Once again, thanks for your time in reviewing this work. >=20 > If i may summarize your remaining technical concerns: >=20 > 1. The CLAT will claim the /96 on the LAN via NDP or by marking the > /96 as used in the local DHCPv6 server of the CLAT. =20 Even if it does the second, it must do the first because hosts MAY use = SLAAC. Right? > In the case of > non-DHCPv6 LAN clients, I believe this is normal NDP action for a > router to claim it's addresses to avoid address conflict. The router claims its address, yes, but not 2^(128-96) addresses (more = than 4 billions) > I believe > you said you are OK with this action as long as the draft is clear on > it. I understand it can work, yes. I also say that the need for it can easily be avoided. For this, just make sure IPv6 addresses that represent IPv4 addresses = are, in hosts that support IPv4 applications, distinguishable from = native addresses. The V octet of R24 in = http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03 does it. >=20 > 2. You believe the scenario for operation without the DNS64 is > confusing in its current form. We can add a section that explicitly > explains this scenario vs DNS64 scenario, is that ok? If you still find it useful to say that there may be no DNS64, yes, an = explanation would be welcome. Yet, in view of RFC6144 in which all scenarios have DNS64 where there = are NAT64s, I would personally suggest to avoid dealing with this = independent problem in your draft (a minor point though). >=20 > 3. Cameron will do a detailed technical review of 4RD-U and submit > comments to Softwire. I do look forward to it.=20 > More in line >=20 >=20 >> Le 2012-02-21 =E0 20:34, Cameron Byrne a =E9crit : >> ... >>> On Tue, Feb 21, 2012 at 10:42 AM, R=E9mi Despr=E9s = wrote: ... >> IMHO, stating that, with a CE architecture like that of the 464XLAT = draft, a stateless CE can work with a stateful NAT64 is enough. >> Adding that it can work without DNS64 is AFAIK at best unnecessary, = at worst confusing. >> That could advantageously be deleted (IMHO). >>=20 >=20 > We'd like to keep it, since DNS64 is not always available or fit for a > given network. Others have submitted feedback on list that they > believe it is important for hosts to be able to use the DNS server of > their choice, not the provider DNS64. AFAIK, having a DNS64 deployed doesn't force all hosts to use it. A sentence reminding it would make no harm. > We can add a section that makes the packet flow for operation without > a DNS64 clear, would that help? Same answer as above. >> ... >>>>>>>> Why, then, say "In the best case, the CLAT will have a = dedicated /64" >>>>>>>>=20 >>>>>>>=20 >>>>>>> It just seems cleaner to me to have a dedicated /64 if it is >>>>>>> available. Operationally, aside from the NDP claiming the /96, = there >>>>>>> is no difference to have dedicated or not dedicated. >>>>>>=20 >>>>>> Understood, but: >>>>>> - Claiming a /96 on a link seems new to me (is there an existing = reference?) >>>>>=20 >>>>> It does not need to claim the /96 as a whole. The CLAT will do = NDP >>>>> with the idea that each /128 in the /96 is owned by the CLAT as a >>>>> virtual address. >>>>=20 >>>> Was understood. >>>>=20 >>>>> I have seen this behavior in NAT-PT deployments, but i do not see = it >>>>> specifically declared in the NAT-PT RFC. >>>>=20 >>>> Right, it seems to be new material as far as IETF is concerned. >>>>=20 >>>=20 >>> NDP for a host address should not be new material. >>=20 >> Nothing is new in your proposal for hosts, right, but NDP operation = IS modified in CE routers. >>=20 >>> As i mentioned >>> before, we can treat each address in the /96 as a host address on = the >>> CLAT, and the interactions are normal for NDP host addresses. >>=20 >> Understood. >> The fact that this is new in the router CE is not a problem AFAIAC, = but provided new pieces of design are clearly identified. >>=20 >=20 > To be clear, you are OK with the NDP action on the CE? We can add > language to make it more clear in the draft. Same answer as above. >>> Alternatively, we may view the CLAT in terms of proxy NDP >>> http://tools.ietf.org/html/rfc4861#section-7.2.8 >>=20 >> Doesn't this require support of RFC3810 (Multicast Listener Discovery = Version 2 (MLDv2) for IPv6)? >> That could be part of the specification, but would AFAIK would be a = constraint. >>=20 >=20 > I am open to discussion on the right path forward for this. As already suggested, the easiest path to get rid of this problem would = be to permit hosts that support IPv4 applications to distinguish native = IPv6 addresses from those that represent IPv4 addresses, even with a = single assigned IPv6 prefix. Your comments on this are welcome. >>> The CLAT is willing to accept packet destine to the /96 on behalf of >>> the IPv4 internet, and the NDP actions are defined as existing Proxy >>> NDP. >>>=20 >>> Thoughts on one verse the other? >>=20 >> My thought is that BOTH can be AVOIDED. >> It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix = that differs from all valid native IPv6 prefixes. >=20 > Yes, in the draft, we state a dedicated /64 for the purpose of > translation is best. But, we also recognize that is not always > available, such is the case for mobile networks. As said, the V octet of 4rd-U brings the benefit of a dedicated /64 = without needing to have one. Regards, RD From despres.remi@laposte.net Thu Feb 23 01:08:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE0D21F863D for ; Thu, 23 Feb 2012 01:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tA-SB3tJHUze for ; Thu, 23 Feb 2012 01:08:11 -0800 (PST) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id D57D321F8630 for ; Thu, 23 Feb 2012 01:08:10 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8504-out with ME id dM821i00337Y3f403M82dD; Thu, 23 Feb 2012 10:08:09 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110424C7@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Thu, 23 Feb 2012 10:08:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <2D09D61DDFA73D4C884805CC7865E6110424C7@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 09:08:12 -0000 Le 2012-02-22 =E0 20:00, STARK, BARBARA H a =E9crit : >>> The reason it isn't correct is that a GUA, used beyond its valid >> lifetime, has the potential to be immediately invalidated when the = WAN >> reappears. >=20 > A GUA has the potential to be immediately invalidated when the WAN = re-appears, no matter what its valid lifetime is. >=20 > Consider the following real-life scenario: > IPv6 connection is via 6rd. > IPv4 address changes every time the IPv4 connection goes down and then = up, no matter what the lease was on the original IPv4 address. This = happens a lot in the IPv4 world. But probably not a lot where 6rd is deployed. (Personally, my IPv6 = prefix hasn't changed since 2008). In any case, address instability breaks external connections, be they in = IPv6 or IPv4.=20 > IPv6 is down when IPv4 is down. > IPv6 prefix is based on the IPv4 address, so it will change every time = the IPv4 address changes. > So the original IPv6 prefix may no longer be useful for Internet = connectivity, even if it has time left on the original "valid" timer. >=20 > If sudden GUA address/prefix changes are a problem, then I think it = would be best to consider this independent of whether or not GUAs are = used beyond their valid lifetimes, when the WAN is down. I don't think = that such use makes the problem any worse. Please see also my answer to Ted. RD >=20 > Barbara From despres.remi@laposte.net Thu Feb 23 01:14:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA3B21F85CE for ; Thu, 23 Feb 2012 01:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFmsVHBaVdI8 for ; Thu, 23 Feb 2012 01:14:08 -0800 (PST) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id E17E621F84D8 for ; Thu, 23 Feb 2012 01:14:06 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id dMDy1i00837Y3f403MDzwS; Thu, 23 Feb 2012 10:14:04 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-22--506079311 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <80717816-FFE2-4D16-9B45-FB6439401F2F@nominum.com> Date: Thu, 23 Feb 2012 10:13:58 +0100 Message-Id: <9CE807A7-055D-484B-A734-5D7BF433636F@laposte.net> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <2D09D61DDFA73D4C884805CC7865E6110424C7@GAALPA1MSGUSR9N.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6110425A1@GAALPA1MSGUSR9N.ITServices.sbc.com> <80717816-FFE2-4D16-9B45-FB6439401F2F@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 09:14:08 -0000 --Apple-Mail-22--506079311 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2012-02-22 =E0 21:27, Ted Lemon a =E9crit : > On Feb 22, 2012, at 2:47 PM, "STARK, BARBARA H" = wrote: >> The IPv6 hosts (and applications that reside on them) inside the home = network won=92t know the difference. CE-router originated native vs 6rd = IPv6 interfaces all look alike from inside the LAN. Therefore, I believe = that my assumption that LAN-based apps will behave the same, no matter = what the WAN IPv6 mechanism is, is well-justified. >=20 > That's not what I meant. What I meant is that the fact that a = network provisioned with 6rd behaves in a suboptimal way isn't something = we need to consider as significant in the long run. Well, if the 6rd network has stable IPv4 addresses and generalized CPEs = that support 6rd, it does work as well as one that would use dual-satck = routing. > 6rd is a transition technology. So we should optimize our solution = for the long term, and not use the bad behavior of transition technology = as a justification for allowing the solution to continue to be broken = once the transition technology is no longer in use. There is bad behavior only if misused. Instability of IPv4 addresses isn't a property of 6rd, just one of = IPv4-service characteristic. RD --Apple-Mail-22--506079311 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Feb 22, 2012, at 2:47 PM, "STARK, BARBARA H" <bs7652@att.com> wrote:
The IPv6 hosts (and applications that reside on them) inside the home = network won=92t know the difference. CE-router originated native vs 6rd = IPv6 interfaces all look alike from inside the LAN. Therefore, I believe = that my assumption that LAN-based apps will behave the same, no matter what the WAN IPv6 mechanism is, is = well-justified.

That's not what I meant.   What I meant is that the fact that = a network provisioned with 6rd behaves in a suboptimal way isn't = something we need to consider as significant in the long run. =

Well, if the 6rd network has = stable IPv4 addresses and generalized CPEs that support 6rd, it does = work as well as one that would use dual-satck = routing.

  6rd is a transition technology.   = So we should optimize our solution for the long term, and not use the bad behavior of transition = technology as a justification for allowing the solution to continue to = be broken once the transition technology is no longer in = use.

There is bad behavior only = if misused.
Instability of IPv4 addresses isn't a property of = 6rd, just one of IPv4-service = characteristic.

RD


= --Apple-Mail-22--506079311-- From jason_livingood@cable.comcast.com Thu Feb 23 05:07:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734E721F8794 for ; Thu, 23 Feb 2012 05:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.666 X-Spam-Level: X-Spam-Status: No, score=-105.666 tagged_above=-999 required=5 tests=[AWL=2.196, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSB7tQqgAo9q for ; Thu, 23 Feb 2012 05:07:33 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 630E521F8750 for ; Thu, 23 Feb 2012 05:07:33 -0800 (PST) Received: from ([24.40.56.114]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.152035597; Thu, 23 Feb 2012 08:06:54 -0500 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Thu, 23 Feb 2012 08:06:54 -0500 From: "Livingood, Jason" To: Marc Lampo , 'Ronald Bonica' , "joelja@bogus.com" , 'Mark Andrews' Thread-Topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-Index: AQHM8NGMkD00gtDZEUSP/1IDM55exZZHw6MAgADeEzCAAdSqgA== Date: Thu, 23 Feb 2012 13:06:52 +0000 Message-ID: In-Reply-To: <00e401ccf143$303934a0$90ab9de0$@lampo@eurid.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.71] Content-Type: multipart/alternative; boundary="_000_CB6BA2F95161Bjasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 13:07:35 -0000 --_000_CB6BA2F95161Bjasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 2/22/12 4:20 AM, "Marc Lampo" > wrote: 2) regarding the previous sentence : "So even though an authoritative DNS server will selectively return AAAA resource records and/or A resource records, these resource records can= certainly still be signed." In this context - assuming we are talking about a signed domain with chain-= of-trust appropriately in place - I'd propose : "So even though an authoritative DNS server will selectively return AAAA resource records and/or A resource records, these resource records mus= t be signed, as well as any accompanying NextSecure information that proves= existence and/or not-existence of AAAA resource records." Great suggestion, thank you for suggesting actual text! Correction to that = sentence made and will publish momentarily in a =9610. - Jason So : -> it's a *must* -> it's not only the A and/or AAAA RRs, but also the NSEC/NSEC3 RRs. Kind regards, Marc Lampo Security Officer EURid (for .eu) From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Sent: 21 February 2012 08:55 PM To: Ronald Bonica; Marc Lampo; EXT - joelja@bogus.com; Mark Andrews Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC I made this addition in the relevant section (6.1). Let me know if it does not capture this sufficiently (or does so inelegantly). Thanks Jason In practical terms this means that two separate views or zones are used, each of which is signed, so that whether or not particular resource records exist, the existence or non-existence of the record can still be validated using DNSSEC. On 2/21/12 2:46 PM, "Livingood, Jason" > wrote: Good idea and it is quick & easy edit. Making the change now. Will send text momentarily. Jason On 2/21/12 8:44 AM, "Ronald Bonica" > wrote: Authors, What do you think? Ron -----Original Message----- From: Marc Lampo [mailto:marc.lampo@eurid.eu] Sent: Tuesday, February 21, 2012 2:03 AM To: Ronald Bonica; EXT - joelja@bogus.com Cc: v6ops@ietf.org Subject: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Hello, I had assumed : 1 zone file (and Mark Andrews correctly pointed at "views"). Would adding this piece of information, directly in the RFC, be useful to avoid confusion for future readers ? Thanks and kind regards, Marc Lampo -----Original Message----- From: Ronald Bonica [mailto:rbonica@juniper.net] Sent: 20 February 2012 11:55 PM To: EXT - joelja@bogus.com; Marc Lampo Cc: v6ops@ietf.org Subject: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Marc, Havard, Are you satisfied with the answers provided by Joel and Mark? Ron -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of EXT - joelja@bogus.com Sent: Monday, February 20, 2012 4:58 PM To: Marc Lampo Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC On 2/20/12 06:32 , Marc Lampo wrote: > Hello, > > (sorry to be late with my comments, bit overloaded on my side) > > 6.1 Security Considerations - paragraph 2 (on DNSSEC) > The text states : "there should not be any negative impact on DNSSEC" > In my opinion, this is *wrong* : > IMHO the following applies. if you have one zone yeah I agree. If you have two zones one with aaaa and one without (assuming this is done with dns views style implementation) you can sign both and they'll both be valid and complete from the vantage point of a client which resolves one or the other of them but not both. this is a traditional split horizon problem. it's just not inside/outside. joel > It is correct that, if an AAAA record exists (in a DNSSEC's zone), > the appropriate RRSIG will be known to authoritative NS's. > If, via white listing, the decision is taken not to present the AAAA > record > (and its signature), this seems OK. > > However : not returning an AAAA record seems identical to : there is no > AAAA record. > And that - there is no AAAA record - yields to "Next Secure" changes ! > If no AAAA record exists, for a name, the corresponding NSEC (NSEC3) > record > should not hold a reference to AAAA. > But if that AAAA record does exist, the authoritative NS will have NSEC > (NSEC3) > data that shows so. > > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but due to > whitelisting > will not be returned), cannot be proven by accompanying (and required) > NSEC (NSEC3) > information. > Hence : this draft will/might make DNSSEC validating name servers fail. > > > If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) in > detail, > please observe : > 1) the caching name server (and "stub resolver") ask 2 queries > (there is only one line, > but it are two queries : one for "A", one for "AAAA") > 2) if the caching name server (or stub resolver) performs DNSSEC > validation, > it will never accept a reply of "NODATA" to the query of AAAA > (because the NSEC (NSEC3) information will not prove that > non-existance) > ((and the validating name server will repeat the query to all > authoritative NS's, looking for a validatable answer)) > > (the final result, to the user might be that only the A record is useable > - mission accomplished ? > But the side effect will be that validating caching name servers will hit > *all* authoritative servers for the domain, > "in search of" a correctly validating answer.) > > So, while for the end-user, the result might be identical, > one "security impact" of this approach is > additional (useless) DNS traffic and > additional load on authoritative NS's (that implement whitelisting) > > > Kind regards, > > Marc Lampo > Security Officer > EURid > > > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: 01 February 2012 04:09 PM > To: IETF-Announce > Cc: v6ops@ietf.org > Subject: [v6ops] Last Call: > > (Considerations for Transitioning Content to IPv6) to Informational RFC > > > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'Considerations for Transitioning Content to IPv6' > as an > Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-15. Exceptio= nally, comments may be > sent to iesg@ietf.org instead. In either case, plea= se retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes considerations for the transition of end user > content on the Internet to IPv6. While this is tailored to address > end user content, which is typically web-based, many aspects of this > document may be more broadly applicable to the transition to IPv6 of > other applications and services. This document explores the > challenges involved in the transition to IPv6, potential migration > tactics, possible migration phases, and other considerations. The > audience for this document is the Internet community generally, > particularly IPv6 implementers. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- whitelisting-impl > ications/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- whitelisting-impl > ications/ > > > No IPR declarations have been submitted directly on this I-D. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo= /v6ops --_000_CB6BA2F95161Bjasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 2/= 22/12 4:20 AM, "Marc Lampo" <marc.lampo@eurid.eu> wrote:
2) regarding the previous sentence :
"So even though an authoritative DNS server will selectively retu= rn
AAAA resource records and/or A resource records, these resource r= ecords can certainly still be signed."

In this context - assuming we are talking about a signed domain with&n= bsp;chain-of-trust appropriately in place - I'd propose :
"So even though an authoritative DNS server will selectively retu= rn
AAAA resource records and/or A resource records, these resource r= ecords must be signed, as well as any accompanying NextSecure informat= ion that proves existence and/or not-existence of AAAA resource record= s."

Great suggestion, thank you for suggesting actual text! Correction to = that sentence made and will publish momentarily in a =9610.

- Jason



So :
-> it's a *must*
-> it's not only the A and/or AAAA RRs, but also the NSEC/NSEC3 RRs= .


Kind regards,

Marc Lampo
Security Officer
EURid (for .eu)


Sent: 21 February 2012 08:55 PM
To: Ronald Bonica; Marc Lampo; EXT - joelja@bogus.com; Mark Andrews
Subject: Re: [v6ops] Last Call:
<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt>
(Considerations for Transitioning Content to IPv6) to Informational RF= C

I made this addition in the relevant section (6.1). Let me know if it = does
not capture this sufficiently (or does so inelegantly). 

Thanks
Jason

In practical terms this means that two separate views or zones are use= d,
each of which is signed, so that whether or not particular resource
records exist, the existence or non-existence of the record can still = be
validated using DNSSEC. 




On 2/21/12 2:46 PM, "Livingood, Jason" <Jason_Livingood@cable.comcast.com&g= t;
wrote:

Good idea and it is quick & easy edit. Making the change now. Will= send
text momentarily.

Jason

On 2/21/12 8:44 AM, "Ronald Bonica" <rbonica@juniper.net> wrote:

Authors,

What do you think?

           &nbs= p;    Ron

-----Original Message-----
From: Marc Lampo [mailto:marc.l= ampo@eurid.eu]
Sent: Tuesday, February 21, 2012 2:03 AM
To: Ronald Bonica; EXT - joelja@bo= gus.com
Subject: RE: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelist= ing-
implications-08.txt> (Considerations for Transitioning Content to I= Pv6)
to Informational RFC
Hello,
I had assumed : 1 zone file (and Mark Andrews correctly pointed at
"views").
Would adding this piece of information, directly in the RFC,
be useful to avoid confusion for future readers ?
Thanks and kind regards,
Marc Lampo
-----Original Message-----
From: Ronald Bonica [mailto:rbo= nica@juniper.net]
Sent: 20 February 2012 11:55 PM
To: EXT - joelja@bogus.com; Ma= rc Lampo
Subject: RE: [v6ops] Last Call:
<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt>
(Considerations for Transitioning Content to IPv6) to Informational RF= C
Marc, Havard,
Are you satisfied with the answers provided by Joel and Mark?
           &nbs= p;            &= nbsp;           &nbs= p; Ron
-----Original Message-----
Behalf
Of EXT - joelja@bogus.com
Sent: Monday, February 20, 2012 4:58 PM
To: Marc Lampo
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-
whitelisting-
implications-08.txt> (Considerations for Transitioning Content to
IPv6)
to Informational RFC

On 2/20/12 06:32 , Marc Lampo wrote:
> Hello,
>
> (sorry to be late with my comments, bit overloaded on my side)
>
> 6.1 Security Considerations - paragraph 2 (on DNSSEC)
> The text states : "there should not be any negative impact o= n
DNSSEC"
> In my opinion, this is *wrong* :
>

IMHO the following applies.

if you have one zone yeah I agree.

If you have two zones one with aaaa and one without (assuming this is<= /div>
done with dns views style implementation) you can sign both and
they'll
both be valid and complete from the vantage point of a client which
resolves one or the other of them but not both.

this is a traditional split horizon problem. it's just not
inside/outside.

joel

> It is correct that, if an AAAA record exists (in a DNSSEC's zone)= ,
> the appropriate RRSIG will be known to authoritative NS's.
> If, via white listing, the decision is taken not to present the
AAAA
> record
> (and its signature), this seems OK.
>
> However : not returning an AAAA record seems identical to : there=
is
no
> AAAA record.
> And that - there is no AAAA record - yields to "Next Secure&= quot;
changes
!
> If no AAAA record exists, for a name, the corresponding NSEC
(NSEC3)
> record
> should not hold a reference to AAAA.
> But if that AAAA record does exist, the authoritative NS will hav= e
NSEC
> (NSEC3)
> data that shows so.
>
> A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists= but
due
to
> whitelisting
> will not be returned), cannot be proven by accompanying (and
required)
> NSEC (NSEC3)
> information.
> Hence : this draft will/might make DNSSEC validating name servers=
fail.
>
>
> If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting)=
in
> detail,
> please observe :
> 1) the caching name server (and "stub resolver") ask 2 = queries
>     (there is only one line,
>      but it are two queries : one f= or "A", one for "AAAA")
> 2) if the caching name server (or stub resolver) performs DNSSEC<= /div>
> validation,
>     it will never accept a reply of "NOD= ATA" to the query of AAAA
>     (because the NSEC (NSEC3) information wil= l not prove that
> non-existance)
>     ((and the validating name server will rep= eat the query to all
>       authoritative NS's, looking f= or a validatable answer))
>
> (the final result, to the user might be that only the A record is=
useable
>  - mission accomplished ?
>  But the side effect will be that validating caching na= me servers
will hit
>   *all* authoritative servers for the domain,
>   "in search of" a correctly validating answe= r.)
>
> So, while for the end-user, the result might be identical,
> one "security impact" of this approach is
> additional (useless) DNS traffic and
> additional load on authoritative NS's (that implement whitelistin= g)
>
>
> Kind regards,
>
> Marc Lampo
> Security Officer
> EURid
>
>
> -----Original Message-----
> Sent: 01 February 2012 04:09 PM
> To: IETF-Announce
> Subject: [v6ops] Last Call:
> <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt>=
> (Considerations for Transitioning Content to IPv6) to Information= al
RFC
>
>
> The IESG has received a request from the IPv6 Operations WG (v6op= s)
to
> consider the following document:
> - 'Considerations for Transitioning Content to IPv6'
>   <draft-ietf-v6ops-v6-aaaa-whitelisting-implication= s-08.txt> as an
> Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and
solicits
> final comments on this action. Please send substantive comments t= o
the
> ietf@ietf.org mailing lists = by 2012-02-15. Exceptionally, comments
may be
> sent to iesg@ietf.org instea= d. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document describes considerations for= the transition of end
user
>    content on the Internet to IPv6. &nbs= p;While this is tailored to
address
>    end user content, which is typically web-b= ased, many aspects of
this
>    document may be more broadly applicable to= the transition to
IPv6
of
>    other applications and services. &nbs= p;This document explores the
>    challenges involved in the transition to I= Pv6, potential
migration
>    tactics, possible migration phases, and ot= her considerations.
The
>    audience for this document is the Internet= community generally,
>    particularly IPv6 implementers.
>
>
>
>
> The file can be obtained via
whitelisting-impl
> ications/
>
> IESG discussion can be tracked via
whitelisting-impl
> ications/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
> _______________________________________________
> v6ops mailing list
>

_______________________________________________
v6ops mailing list
_______________________________________________
v6ops mailing list

_______________________________________________ v6ops mailing list

--_000_CB6BA2F95161Bjasonlivingoodcablecomcastcom_-- From washam.fan@gmail.com Thu Feb 23 05:07:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2E921F87D8 for ; Thu, 23 Feb 2012 05:07:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVBpbN8lVprW for ; Thu, 23 Feb 2012 05:07:56 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E98A21F8750 for ; Thu, 23 Feb 2012 05:07:55 -0800 (PST) Received: by werg1 with SMTP id g1so958834wer.31 for ; Thu, 23 Feb 2012 05:07:54 -0800 (PST) Received-SPF: pass (google.com: domain of washam.fan@gmail.com designates 10.180.80.226 as permitted sender) client-ip=10.180.80.226; Authentication-Results: mr.google.com; spf=pass (google.com: domain of washam.fan@gmail.com designates 10.180.80.226 as permitted sender) smtp.mail=washam.fan@gmail.com; dkim=pass header.i=washam.fan@gmail.com Received: from mr.google.com ([10.180.80.226]) by 10.180.80.226 with SMTP id u2mr3146045wix.0.1330002474883 (num_hops = 1); Thu, 23 Feb 2012 05:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zEVsqhU/ou/1rA7ojsmOPHoX+GHAch8//brG5p2tMGY=; b=BZWNjuWE/H0VTnGPGR6Hk9RUerNaAmmVpPgXk+3aAUhm1DwmkhmZRPVJ3ZqTnSqkIH V3d4ECUZT3iXc0BraoM8ZePkdloTxE4/wn0BcQXZ5DL7lnIIEhOXbqvtxVuIPXNfMf2k 49tpu3DQyXCize8WeNYoYPGTzyYz6Wap1+J/Q= MIME-Version: 1.0 Received: by 10.180.80.226 with SMTP id u2mr2590074wix.0.1330002474846; Thu, 23 Feb 2012 05:07:54 -0800 (PST) Received: by 10.216.1.6 with HTTP; Thu, 23 Feb 2012 05:07:54 -0800 (PST) In-Reply-To: References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> <190FFDFA-2901-437A-BFBF-E598F56A6120@laposte.net> <067E6CE33034954AAC05C9EC85E2577C0778D46C@XMB-RCD-111.cisco.com> <592C29F3-56B0-4319-BD94-B1A520CF2A5E@laposte.net> <067E6CE33034954AAC05C9EC85E2577C0778D61A@XMB-RCD-111.cisco.com> Date: Thu, 23 Feb 2012 21:07:54 +0800 Message-ID: From: Washam Fan To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 13:07:56 -0000 Hi Cameron, Just one point. See below please. >>> Compliance with the 464XLAT draft requires specific code that none of t= he >>> referenced RFCs specifies. >>> This code is to prevent other LAN hosts not only to avoid the router's >>> address, as usual, BUT all addresses starting with the chosen /95. >> >> Well, the code is nothing special, since it is part of typical NDP/DAD t= o prohibit a LAN host from using router's addresses (say). >> > > Yes. =A0This is clear, and this behavior has been demonstrated in > commercial NAT-PT systems. > >> However, the valid point you have is that if the LAN host duplicated the= same address as that of the router (/96 based addresses, say), then the LA= N host would be deprived of the address (and possibly global IPv6 connectiv= ity). >> > > It will not be deprived, it will be made aware via NDP that that > address is in use therefore it must select another address. DAD failure would cause the address invalid,i.e., you can not use this address for any purpose. at least, i observed this on Linux. Thanks, washam From internet-drafts@ietf.org Thu Feb 23 05:10:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D94221F87ED; Thu, 23 Feb 2012 05:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3umRTNMlavZ; Thu, 23 Feb 2012 05:10:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACC321F87F2; Thu, 23 Feb 2012 05:10:10 -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 X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120223131010.28738.19399.idtracker@ietfa.amsl.com> Date: Thu, 23 Feb 2012 05:10:10 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 13:10:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Considerations for Transitioning Content to IPv6 Author(s) : Jason Livingood Filename : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-10.txt Pages : 31 Date : 2012-02-23 This document describes considerations for the transition of end user content on the Internet to IPv6. While this is tailored to address end user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-i= mplications-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-im= plications-10.txt From Ted.Lemon@nominum.com Thu Feb 23 05:37:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B041221F8804 for ; Thu, 23 Feb 2012 05:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.368 X-Spam-Level: X-Spam-Status: No, score=-106.368 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUfagqInj-SB for ; Thu, 23 Feb 2012 05:37:20 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id BA1FC21F8803 for ; Thu, 23 Feb 2012 05:37:19 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT0ZBD0DD40waz8/tZ0EtHlQ/OXAoA1A0@postini.com; Thu, 23 Feb 2012 05:37:19 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B7CAB1B83CB for ; Thu, 23 Feb 2012 05:37:18 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id AA40A19005D; Thu, 23 Feb 2012 05:37:18 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 23 Feb 2012 05:37:18 -0800 From: Ted Lemon To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAixh6AAAuAUgAAAGCPAAACJwsAAAMskIAAANWIAAAAtOcAAAMVnYAAHICAgAAK2K+A Date: Thu, 23 Feb 2012 13:37:17 +0000 Message-ID: <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> In-Reply-To: <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_4667B6CE6E674613ACDFE1A6CD8EE1BFnominumcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 13:37:20 -0000 --_000_4667B6CE6E674613ACDFE1A6CD8EE1BFnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Feb 23, 2012, at 3:26 AM, R=E9mi Despr=E9s > wrote: Even if it doesn't, it isn't a serious problem: the host is informed in ICM= Pv6 that unreachability of the destination is due to ingress or egress filt= ering (Type 1 code 5 per RFC4443). What it does next is implementation dependent, but checking its source addr= ess makes sense. This is true, but it leaves the problem of what happens to net-local commun= ication when this happens. As a reminder, the original point I was making= was simply that it is in fact necessary, or at least desirable, to use ULA= s for internal communication. Besides, this only happens when ISPs change IPv6 prefix assignments, which = is always a problem for external connections. If this is true, it seems like a pretty big problem. It's bad enough when= ISPs change my IP address; now they are going to renumber my entire networ= k? DHCP has generally been designed to prevent this: when you renew your = address, you get the same address, not a different one, and when you renew = your prefix, the same is true. --_000_4667B6CE6E674613ACDFE1A6CD8EE1BFnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <6E99A92F30A3F24283F841B1B74C55BA@nominum.com> Content-Transfer-Encoding: quoted-printable
On Feb 23, 2012, at 3:26 AM, R=E9mi Despr=E9s <despres.remi@laposte.net>
 wrote:
E= ven if it doesn't, it isn't a serious problem: the host is informed in ICMPv6 = that unreachability of the destination is due to ingress or egress filterin= g (Type 1 code 5 per RFC4443).
What it does next is implementation dependent, but checking its source address = makes sense.

This is true, but it leaves the problem of what happens to net-local commun= ication when this happens.   As a reminder, the original point I was m= aking was simply that it is in fact necessary, or at least desirable, to us= e ULAs for internal communication.

B= esides, this only happens when ISPs change IPv6 prefix assignments, which is alway= s a problem for external connections.

If this is true, it seems like a pretty big problem.   It's bad e= nough when ISPs change my IP address; now they are going to renumber my ent= ire network?   DHCP has generally been designed to prevent this: when = you renew your address, you get the same address, not a different one, and when you renew your prefix, the same is true.

--_000_4667B6CE6E674613ACDFE1A6CD8EE1BFnominumcom_-- From despres.remi@laposte.net Thu Feb 23 06:08:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408FE21F8822 for ; Thu, 23 Feb 2012 06:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIU+8fyG9zSu for ; Thu, 23 Feb 2012 06:07:59 -0800 (PST) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id D9FAC21F881A for ; Thu, 23 Feb 2012 06:07:58 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8504-out with ME id dS7q1i00537Y3f403S7q8o; Thu, 23 Feb 2012 15:07:57 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-24--488448250 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> Date: Thu, 23 Feb 2012 15:07:49 +0100 Message-Id: References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:08:00 -0000 --Apple-Mail-24--488448250 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-02-23 =E0 14:37, Ted Lemon a =E9crit : > On Feb 23, 2012, at 3:26 AM, R=E9mi Despr=E9s = > wrote: >> Even if it doesn't, it isn't a serious problem: the host is informed = in ICMPv6 that unreachability of the destination is due to ingress or = egress filtering (Type 1 code 5 per RFC4443). >> What it does next is implementation dependent, but checking its = source address makes sense. >=20 > This is true, but it leaves the problem of what happens to net-local = communication when this happens. If local communication uses GUAs and, as I suggest, GUAs remain valid in = case of WAN-link failure, local communication continues undisrupted. > As a reminder, the original point I was making was simply that it is = in fact necessary, or at least desirable, to use ULAs for internal = communication. AFAIK, it creates more problems than it solves. My home site uses IPv6 without ULAs. It has no problem, and I don't know = how I could use ULAs today if I wanted to. Wanting to use ULA it in my understanding against the keep-it-simple = principle. >> Besides, this only happens when ISPs change IPv6 prefix assignments, = which is always a problem for external connections. >=20 > If this is true, it seems like a pretty big problem. It's bad enough = when ISPs change my IP address; now they are going to renumber my entire = network? =20 At least on a single-link, changing an IPv6 prefix isn't more complex = than changing the external address of a NAT44: It breaks current = connections but everything else is automatically fixed. For instance, when Free obtained a /26 instead of its initial /32, in = 2008, my IPv6 prefix changed but I didn't notice it before examining = which IPv6 address (GUA) my Mac was using.=20 > DHCP has generally been designed to prevent this: when you renew your = address, you get the same address, not a different one, and when you = renew your prefix, the same is true. If I get it right, you assume that each host has both a ULA, for local = sessions, and a GUA, have Internet e2e transparency. But, as noticed, not all hosts can do this, so that this model less = workable than the current one where only GUAs are used. RD --Apple-Mail-24--488448250 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Feb 23, 2012, at 3:26 AM, R=E9mi Despr=E9s <despres.remi@laposte.net><= /div>
 wrote:
Even if it doesn't, it isn't a serious problem: the host is informed in = ICMPv6 that unreachability of the destination is due to ingress or = egress filtering (Type 1 code 5 per RFC4443).
What it does next is implementation dependent, but checking its source = address makes sense.

This is true, but it leaves the problem of what happens to net-local = communication when this happens. =

If local communication uses = GUAs and, as I suggest, GUAs remain valid in case of WAN-link failure, = local communication continues undisrupted.

 As a = reminder, the original point I was making was simply that it is in fact = necessary, or at least desirable, to use ULAs for internal = communication.

AFAIK, it creates = more problems than it solves.
My home site uses IPv6 without = ULAs. It has no problem, and I don't know how I could use ULAs today if = I wanted to.

Wanting to use ULA it in my = understanding against the keep-it-simple = principle.


Besides, this only happens when ISPs change IPv6 prefix assignments, which is = always a problem for external connections.

If this is true, it seems like a pretty big problem.   It's = bad enough when ISPs change my IP address; now they are going to = renumber my entire network?   =

At least on a single-link, = changing an IPv6 prefix isn't more complex than changing the external = address of a NAT44: It breaks current connections but everything else is = automatically fixed.

For instance, when Free = obtained a /26 instead of its initial /32, in 2008, my IPv6 prefix = changed but I didn't notice it before examining which IPv6 address (GUA) = my Mac was = using. 


DHCP has generally = been designed to prevent this: when you renew your address, you get the = same address, not a different one, and when you renew your prefix, the same is = true.

If I get it right, = you assume that each host has both a ULA, for local sessions, and a GUA, = have Internet e2e transparency.
But, as noticed, not all hosts can = do this, so that this model less workable than the current one where = only GUAs are = used.

RD


= --Apple-Mail-24--488448250-- From Carl.Wuyts@technicolor.com Thu Feb 23 06:18:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5899E21F87FE for ; Thu, 23 Feb 2012 06:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhlTXsMosWIF for ; Thu, 23 Feb 2012 06:18:45 -0800 (PST) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id E906E21F86DF for ; Thu, 23 Feb 2012 06:18:31 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKT0ZKt7gxQDqWw6p3ywE9ZYSlhsmEp6xC@postini.com; Thu, 23 Feb 2012 06:18:45 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 23 Feb 2012 15:15:12 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Thu, 23 Feb 2012 15:15:19 +0100 From: Wuyts Carl To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Ted Lemon Date: Thu, 23 Feb 2012 15:15:17 +0100 Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: AczyNJiSa5U+IVA0QQu0/CfEpEdhTQAACjIQ Message-ID: <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0E9AFBC07AMOPESMBX01eut_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:18:48 -0000 --_000_867F4B6A1672E541A94676D556793ACD0E9AFBC07AMOPESMBX01eut_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, you have people pro and contra ULA-support. Lots of people question = the real need for ULA as well. I tend to agree you don't really need it, at least not in the most common d= eployments (we're mainly doing residential CPEs), although our CPE supports= it today (configurable). It indeed adds a little extra complexity, as you= get more and more addresses. In a residential scenario, you often only ha= ve 1 LAN segment, hence the need for ULA becomes less important I guess. It's there for people who want to use it, I guess, and can be maybe useful = in some more advanced roll-outs or future home-net solutions with multiple = LAN segments in the home. As we're deploying in a managed CPE, it's up to = our customer to either enable or not the ULA creation on the advertising in= terface(s). Regs Carl From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of R= =E9mi Despr=E9s Sent: donderdag 23 februari 2012 15:08 To: Ted Lemon Cc: v6ops@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing Le 2012-02-23 =E0 14:37, Ted Lemon a =E9crit : On Feb 23, 2012, at 3:26 AM, R=E9mi Despr=E9s > wrote: Even if it doesn't, it isn't a serious problem: the host is informed in ICM= Pv6 that unreachability of the destination is due to ingress or egress filt= ering (Type 1 code 5 per RFC4443). What it does next is implementation dependent, but checking its source addr= ess makes sense. This is true, but it leaves the problem of what happens to net-local commun= ication when this happens. If local communication uses GUAs and, as I suggest, GUAs remain valid in ca= se of WAN-link failure, local communication continues undisrupted. As a reminder, the original point I was making was simply that it is in fa= ct necessary, or at least desirable, to use ULAs for internal communication= . AFAIK, it creates more problems than it solves. My home site uses IPv6 without ULAs. It has no problem, and I don't know ho= w I could use ULAs today if I wanted to. Wanting to use ULA it in my understanding against the keep-it-simple princi= ple. Besides, this only happens when ISPs change IPv6 prefix assignments, which = is always a problem for external connections. If this is true, it seems like a pretty big problem. It's bad enough when= ISPs change my IP address; now they are going to renumber my entire networ= k? At least on a single-link, changing an IPv6 prefix isn't more complex than = changing the external address of a NAT44: It breaks current connections but= everything else is automatically fixed. For instance, when Free obtained a /26 instead of its initial /32, in 2008,= my IPv6 prefix changed but I didn't notice it before examining which IPv6 = address (GUA) my Mac was using. DHCP has generally been designed to prevent this: when you renew your addre= ss, you get the same address, not a different one, and when you renew your = prefix, the same is true. If I get it right, you assume that each host has both a ULA, for local sess= ions, and a GUA, have Internet e2e transparency. But, as noticed, not all hosts can do this, so that this model less workabl= e than the current one where only GUAs are used. RD --_000_867F4B6A1672E541A94676D556793ACD0E9AFBC07AMOPESMBX01eut_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Well, you= have people pro and contra ULA-support.=A0 Lots of people question the rea= l need for ULA as well.

I = tend to agree you don’t really need it, at least not in the most comm= on deployments (we’re mainly doing residential CPEs), although our CP= E supports it today (configurable).=A0 It indeed adds a little extra comple= xity, as you get more and more addresses.=A0 In a residential scenario, you= often only have 1 LAN segment, hence the need for ULA becomes less importa= nt I guess.

 

It’s there for people who w= ant to use it, I guess, and can be maybe useful in some more advanced roll-= outs or future home-net solutions with multiple LAN segments in the home.= =A0 As we’re deploying in a managed CPE, it’s up to our custome= r to either enable or not the ULA creation on the advertising interface(s).=

 <= /p>

Regs

Carl

 

 =

From: v6ops-bounces@ietf.org [m= ailto:v6ops-bounces@ietf.org] On Behalf Of R=E9mi Despr=E9s
Se= nt: donderdag 23 februari 2012 15:08
To: Ted Lemon
Cc:<= /b> v6ops@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org
Subject:<= /b> Re: [v6ops] 6204bis and WAN disappearing

 

&nbs= p;

Le 2012-02-23 =E0 14:37, Ted Lem= on a =E9crit :



=

On Feb 23, 2012, at 3:26 AM, R=E9mi= Despr=E9s <despres.remi@lap= oste.net>

 wrote:=

Even if it doesn't, it isn't a serious pro= blem: the host is informed in ICMPv6 that unreachability of the destination= is due to ingress or egress filtering (Type 1 code 5 per RFC4443).
What= it does next is implementation dependent, but checking its source address = makes sense.

 

This is true, but it leaves t= he problem of what happens to net-local communication when this happens.

 

If local communication uses GUAs and, as I sug= gest, GUAs remain valid in case of WAN-link failure, local communication co= ntinues undisrupted.



=

 As a reminder, the original = point I was making was simply that it is in fact necessary, or at least des= irable, to use ULAs for internal communication.

<= div>

 

AF= AIK, it creates more problems than it solves.

My home site uses IPv6 without ULAs. It has no problem, an= d I don't know how I could use ULAs today if I wanted to.

 

Wanting to use ULA it in my understanding against the keep-it-simple= principle.

 =

 

B= esides, this only happens when ISPs change IPv6 prefix assignments, which i= s always a problem for external connections.

 

If this is true, it seems like a pretty big problem.   It's bad eno= ugh when ISPs change my IP address; now they are going to renumber my entir= e network?  

 

At least on a sing= le-link, changing an IPv6 prefix isn't more complex than changing the exter= nal address of a NAT44: It breaks current connections but everything else i= s automatically fixed.

&= nbsp;

For instance, when Free obta= ined a /26 instead of its initial /32, in 2008, my IPv6 prefix changed but = I didn't notice it before examining which IPv6 address (GUA) my Mac was usi= ng. 

 

 

DHCP has generally been designed to prevent this: when you renew your= address, you get the same address, not a different one, and when you renew= your prefix, the same is true.

 

If I get it right, you assume that each host has both a ULA, for local ses= sions, and a GUA, have Internet e2e transparency.

But, as noticed, not all hosts can do this, so that this mod= el less workable than the current one where only GUAs are used.<= /p>

 

RD

 

 

= --_000_867F4B6A1672E541A94676D556793ACD0E9AFBC07AMOPESMBX01eut_-- From cb.list6@gmail.com Thu Feb 23 06:25:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DD121F85FC for ; Thu, 23 Feb 2012 06:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.259 X-Spam-Level: X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNiMUfJQmJ7P for ; Thu, 23 Feb 2012 06:25:20 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8EB021F85EC for ; Thu, 23 Feb 2012 06:25:20 -0800 (PST) Received: by dakl33 with SMTP id l33so1376645dak.31 for ; Thu, 23 Feb 2012 06:25:20 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.194.8 as permitted sender) client-ip=10.68.194.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.194.8 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.194.8]) by 10.68.194.8 with SMTP id hs8mr4632467pbc.113.1330007120655 (num_hops = 1); Thu, 23 Feb 2012 06:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fXiXcn1oPquO+nEy1WrY59p42Gq6b0eak+Vueq79zNE=; b=B6d0EwymuH4J6k94sF7wvT+/vHASa6fdjJ2o/9y4t46TBaQ5hvCAzZDZUKy/D7tbHo GXzJQw2yVmApMVG2hwb4lerV+vIe+GzEjSLnMRnP8RnDPEScSKxSpVTyv1b9B4clPfRW 7m+vljY6hRppyJsaGqoyKfTV4oulZv09arJJ4= MIME-Version: 1.0 Received: by 10.68.194.8 with SMTP id hs8mr3938827pbc.113.1330007120595; Thu, 23 Feb 2012 06:25:20 -0800 (PST) Received: by 10.142.99.12 with HTTP; Thu, 23 Feb 2012 06:25:20 -0800 (PST) Received: by 10.142.99.12 with HTTP; Thu, 23 Feb 2012 06:25:20 -0800 (PST) In-Reply-To: <75C7DA3D-D5CA-440E-B39C-4342B877D15D@laposte.net> References: <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net> <190FFDFA-2901-437A-BFBF-E598F56A6120@laposte.net> <75C7DA3D-D5CA-440E-B39C-4342B877D15D@laposte.net> Date: Thu, 23 Feb 2012 06:25:20 -0800 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b15aeb3f8cb0f04b9a26992 Cc: v6ops WG , Russell Housley Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:25:22 -0000 --047d7b15aeb3f8cb0f04b9a26992 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Remi. It sounds like all technical issues have been resolved. We will update the draft for based on the groups feedback. Thanks again. On Feb 23, 2012 1:00 AM, "R=E9mi Despr=E9s" wrot= e: > > Cameron, > > Le 2012-02-22 =E0 19:59, Cameron Byrne a =E9crit : > > > On Wed, Feb 22, 2012 at 2:40 AM, R=E9mi Despr=E9s wrote: > >> Cameron, > >> It seems we are close to common understanding. > >> More below. > >> > > > > Yes, I do believe that is the case. > > > > Once again, thanks for your time in reviewing this work. > > > > If i may summarize your remaining technical concerns: > > > > 1. The CLAT will claim the /96 on the LAN via NDP or by marking the > > /96 as used in the local DHCPv6 server of the CLAT. > > Even if it does the second, it must do the first because hosts MAY use SLAAC. > Right? > Yes > > In the case of > > non-DHCPv6 LAN clients, I believe this is normal NDP action for a > > router to claim it's addresses to avoid address conflict. > > The router claims its address, yes, but not 2^(128-96) addresses (more than 4 billions) > Yes > > I believe > > you said you are OK with this action as long as the draft is clear on > > it. > > I understand it can work, yes. > Great > I also say that the need for it can easily be avoided. > For this, just make sure IPv6 addresses that represent IPv4 addresses are, in hosts that support IPv4 applications, distinguishable from native addresses. > The V octet of R24 in http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03 does it. > I will study this > > > > 2. You believe the scenario for operation without the DNS64 is > > confusing in its current form. We can add a section that explicitly > > explains this scenario vs DNS64 scenario, is that ok? > > If you still find it useful to say that there may be no DNS64, yes, an explanation would be welcome. We will add more clarity > Yet, in view of RFC6144 in which all scenarios have DNS64 where there are NAT64s, I would personally suggest to avoid dealing with this independent problem in your draft (a minor point though). > ack > > > > 3. Cameron will do a detailed technical review of 4RD-U and submit > > comments to Softwire. > > I do look forward to it. > > Me too > > More in line > > > > > >> Le 2012-02-21 =E0 20:34, Cameron Byrne a =E9crit : > >> ... > >>> On Tue, Feb 21, 2012 at 10:42 AM, R=E9mi Despr=E9s < despres.remi@laposte.net> wrote: > ... > >> IMHO, stating that, with a CE architecture like that of the 464XLAT draft, a stateless CE can work with a stateful NAT64 is enough. > >> Adding that it can work without DNS64 is AFAIK at best unnecessary, at worst confusing. > >> That could advantageously be deleted (IMHO). > >> > > > > We'd like to keep it, since DNS64 is not always available or fit for a > > given network. Others have submitted feedback on list that they > > believe it is important for hosts to be able to use the DNS server of > > their choice, not the provider DNS64. > > AFAIK, having a DNS64 deployed doesn't force all hosts to use it. > A sentence reminding it would make no harm. > > > > We can add a section that makes the packet flow for operation without > > a DNS64 clear, would that help? > > Same answer as above. > > > >> ... > >>>>>>>> Why, then, say "In the best case, the CLAT will have a dedicated /64" > >>>>>>>> > >>>>>>> > >>>>>>> It just seems cleaner to me to have a dedicated /64 if it is > >>>>>>> available. Operationally, aside from the NDP claiming the /96, there > >>>>>>> is no difference to have dedicated or not dedicated. > >>>>>> > >>>>>> Understood, but: > >>>>>> - Claiming a /96 on a link seems new to me (is there an existing reference?) > >>>>> > >>>>> It does not need to claim the /96 as a whole. The CLAT will do NDP > >>>>> with the idea that each /128 in the /96 is owned by the CLAT as a > >>>>> virtual address. > >>>> > >>>> Was understood. > >>>> > >>>>> I have seen this behavior in NAT-PT deployments, but i do not see i= t > >>>>> specifically declared in the NAT-PT RFC. > >>>> > >>>> Right, it seems to be new material as far as IETF is concerned. > >>>> > >>> > >>> NDP for a host address should not be new material. > >> > >> Nothing is new in your proposal for hosts, right, but NDP operation IS modified in CE routers. > >> > >>> As i mentioned > >>> before, we can treat each address in the /96 as a host address on the > >>> CLAT, and the interactions are normal for NDP host addresses. > >> > >> Understood. > >> The fact that this is new in the router CE is not a problem AFAIAC, but provided new pieces of design are clearly identified. > >> > > > > To be clear, you are OK with the NDP action on the CE? We can add > > language to make it more clear in the draft. > > Same answer as above. > > >>> Alternatively, we may view the CLAT in terms of proxy NDP > >>> http://tools.ietf.org/html/rfc4861#section-7.2.8 > >> > >> Doesn't this require support of RFC3810 (Multicast Listener Discovery Version 2 (MLDv2) for IPv6)? > >> That could be part of the specification, but would AFAIK would be a constraint. > >> > > > > I am open to discussion on the right path forward for this. > > As already suggested, the easiest path to get rid of this problem would be to permit hosts that support IPv4 applications to distinguish native IPv6 addresses from those that represent IPv4 addresses, even with a single assigned IPv6 prefix. > Your comments on this are welcome. > > > >>> The CLAT is willing to accept packet destine to the /96 on behalf of > >>> the IPv4 internet, and the NDP actions are defined as existing Proxy > >>> NDP. > >>> > >>> Thoughts on one verse the other? > >> > >> My thought is that BOTH can be AVOIDED. > >> It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix that differs from all valid native IPv6 prefixes. > > > > Yes, in the draft, we state a dedicated /64 for the purpose of > > translation is best. But, we also recognize that is not always > > available, such is the case for mobile networks. > > As said, the V octet of 4rd-U brings the benefit of a dedicated /64 without needing to have one. > > This again for detailed review. Cb > Regards, > RD > --047d7b15aeb3f8cb0f04b9a26992 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks Remi. It sounds like all technical issues have been resolved. We = will update the draft for based on the groups feedback.=A0 Thanks again. On Feb 23, 2012 1:00 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
> Cameron,
>
> Le 2012-02-22 =E0 19:59, Cameron Byrne a =E9crit :
>
> > On Wed, Feb 22, 2012 at 2:40 AM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote: > >> Cameron,
> >> It seems we are close to common understanding.
> >> More below.
> >>
> >
> > Yes, I do believe that is the case.
> >
> > Once again, thanks for your time in reviewing this work.
> >
> > If i may summarize your remaining technical concerns:
> >
> > 1. =A0The CLAT will claim the /96 on the LAN via NDP or by markin= g the
> > /96 as used in the local DHCPv6 server of the CLAT.
>
> Even if it does the second, it must do the first because hosts MAY use= SLAAC.
> Right?
>

Yes

> > =A0In the case of
> > non-DHCPv6 LAN clients, I believe this is normal NDP action for a=
> > router to claim it's addresses to avoid address conflict.
>
> The router claims its address, yes, but not 2^(128-96) addresses (more= than 4 billions)
>

Yes

> > I believe
> > you said you are OK with this action as long as the draft is clea= r on
> > it.
>
> I understand it can work, yes.
>

Great

> I also say that the need for it can easily be avoided.
> For this, just make sure IPv6 addresses that represent IPv4 addresses = are, in hosts that support IPv4 applications, distinguishable from native a= ddresses.
> The V octet of R24 in http://tools.ietf.org/html/draft-despres-softwire-4r= d-u-03 does it.
>

I will study this

> >
> > 2. You believe the scenario for operation without the DNS64 is > > confusing in its current form. We can add a section that explicit= ly
> > explains this scenario vs DNS64 scenario, is that ok?
>
> If you still find it useful to say that there may be no DNS64, yes, an= explanation would be welcome.

We will add more clarity

> Yet, in view of RFC6144 in which all scenarios have DNS64 where the= re are NAT64s, I would personally suggest to avoid dealing with this indepe= ndent problem in your draft (a minor point though).
>

ack

> >
> > 3. =A0Cameron will do a detailed technical review of 4RD-U and su= bmit
> > comments to Softwire.
>
> I do look forward to it.
>
>

Me too

> > More in line
> >
> >
> >> Le 2012-02-21 =E0 20:34, Cameron Byrne a =E9crit :
> >> ...
> >>> On Tue, Feb 21, 2012 at 10:42 AM, R=E9mi Despr=E9s <despres.remi@laposte.net> = wrote:
> ...
> >> IMHO, stating that, with a CE architecture like that of the 4= 64XLAT draft, a stateless CE can work with a stateful NAT64 is enough.
> >> Adding that it can work without DNS64 is AFAIK at best unnece= ssary, at worst confusing.
> >> That could advantageously be deleted (IMHO).
> >>
> >
> > We'd like to keep it, since DNS64 is not always available or = fit for a
> > given network. =A0Others have submitted feedback on list that the= y
> > believe it is important for hosts to be able to use the DNS serve= r of
> > their choice, not the provider DNS64.
>
> AFAIK, having a DNS64 deployed doesn't force all hosts to use it.<= br> > A sentence reminding it would make no harm.
>
>
> > We can add a section that makes the packet flow for operation wit= hout
> > a DNS64 clear, would that help?
>
> Same answer as above.
>
>
> >> ...
> >>>>>>>> Why, then, say "In the best case= , the CLAT will have a dedicated /64"
> >>>>>>>>
> >>>>>>>
> >>>>>>> It just seems cleaner to me to have a ded= icated /64 if it is
> >>>>>>> available. =A0Operationally, aside from t= he NDP claiming the /96, there
> >>>>>>> is no difference to have dedicated or not= dedicated.
> >>>>>>
> >>>>>> Understood, but:
> >>>>>> - Claiming a /96 on a link seems new to me (i= s there an existing reference?)
> >>>>>
> >>>>> It does not need to claim the /96 as a whole. =A0= The CLAT will do NDP
> >>>>> with the idea that each /128 in the /96 is owned = by the CLAT as a
> >>>>> virtual address.
> >>>>
> >>>> Was understood.
> >>>>
> >>>>> I have seen this behavior in NAT-PT deployments, = but i do not see it
> >>>>> specifically declared in the NAT-PT RFC.
> >>>>
> >>>> Right, it seems to be new material as far as IETF is = concerned.
> >>>>
> >>>
> >>> NDP for a host address should not be new material.
> >>
> >> Nothing is new in your proposal for hosts, right, but NDP ope= ration IS modified in CE routers.
> >>
> >>> As i mentioned
> >>> before, we can treat each address in the /96 as a host ad= dress on the
> >>> CLAT, and the interactions are normal for NDP host addres= ses.
> >>
> >> Understood.
> >> The fact that this is new in the router CE is not a problem A= FAIAC, but provided new pieces of design are clearly identified.
> >>
> >
> > To be clear, you are OK with the NDP action on the CE? =A0We can = add
> > language to make it more clear in the draft.
>
> Same answer as above.
>
> >>> Alternatively, we may view the CLAT in terms of proxy NDP=
> >>> http://tools.ietf.org/html/rfc4861#section-7.2.8
> >>
> >> Doesn't this require support of RFC3810 (Multicast Listen= er Discovery Version 2 (MLDv2) for IPv6)?
> >> That could be part of the specification, but would AFAIK woul= d be a constraint.
> >>
> >
> > I am open to discussion on the right path forward for this.
>
> As already suggested, the easiest path to get rid of this problem woul= d be to permit hosts that support IPv4 applications to distinguish native I= Pv6 addresses from those that represent IPv4 addresses, even with a single = assigned IPv6 prefix.
> Your comments on this are welcome.
>
>
> >>> The CLAT is willing to accept packet destine to the /96 o= n behalf of
> >>> the IPv4 internet, and the NDP actions are defined as exi= sting Proxy
> >>> NDP.
> >>>
> >>> Thoughts on one verse the other?
> >>
> >> My thought is that BOTH can be AVOIDED.
> >> It is sufficient for this to use, for IPv4 traffic, an IPv6 p= refix that differs from all valid native IPv6 prefixes.
> >
> > Yes, in the draft, we state a dedicated /64 for the purpose of > > translation is best. =A0But, we also recognize that is not always=
> > available, such is the case for mobile networks.
>
> As said, the V octet of 4rd-U brings the benefit of a dedicated /64 wi= thout needing to have one.
>
>

This again for detailed review.

Cb

> Regards,
> RD
>

--047d7b15aeb3f8cb0f04b9a26992-- From despres.remi@laposte.net Thu Feb 23 06:30:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F304421F876F for ; Thu, 23 Feb 2012 06:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjhjv88+9TjX for ; Thu, 23 Feb 2012 06:30:08 -0800 (PST) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6541E21F876E for ; Thu, 23 Feb 2012 06:30:06 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id dSVw1i00837Y3f403SVw7y; Thu, 23 Feb 2012 15:30:05 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-25--487122062 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> Date: Thu, 23 Feb 2012 15:29:56 +0100 Message-Id: References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:30:09 -0000 --Apple-Mail-25--487122062 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2012-02-23 =E0 15:15, Wuyts Carl a =E9crit : > Well, you have people pro and contra ULA-support. Lots of people = question the real need for ULA as well. > I tend to agree you don=92t really need it, at least not in the most = common deployments (we=92re mainly doing residential CPEs), although our = CPE supports it today (configurable). It indeed adds a little extra = complexity, as you get more and more addresses. In a residential = scenario, you often only have 1 LAN segment, hence the need for ULA = becomes less important I guess. > =20 > It=92s there for people who want to use it, I guess, and can be maybe = useful in some more advanced roll-outs or future home-net solutions with = multiple LAN segments in the home. As we=92re deploying in a managed = CPE, it=92s up to our customer to either enable or not the ULA creation = on the advertising interface(s). Right. Thanks, RD > =20 > Regs > Carl > =20 > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of R=E9mi Despr=E9s > Sent: donderdag 23 februari 2012 15:08 > To: Ted Lemon > Cc: v6ops@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org > Subject: Re: [v6ops] 6204bis and WAN disappearing > =20 > =20 > Le 2012-02-23 =E0 14:37, Ted Lemon a =E9crit : >=20 >=20 > On Feb 23, 2012, at 3:26 AM, R=E9mi Despr=E9s = > wrote: > Even if it doesn't, it isn't a serious problem: the host is informed = in ICMPv6 that unreachability of the destination is due to ingress or = egress filtering (Type 1 code 5 per RFC4443). > What it does next is implementation dependent, but checking its source = address makes sense. > =20 > This is true, but it leaves the problem of what happens to net-local = communication when this happens. > =20 > If local communication uses GUAs and, as I suggest, GUAs remain valid = in case of WAN-link failure, local communication continues undisrupted. >=20 >=20 > As a reminder, the original point I was making was simply that it is = in fact necessary, or at least desirable, to use ULAs for internal = communication. > =20 > AFAIK, it creates more problems than it solves. > My home site uses IPv6 without ULAs. It has no problem, and I don't = know how I could use ULAs today if I wanted to. > =20 > Wanting to use ULA it in my understanding against the keep-it-simple = principle. > =20 > =20 > Besides, this only happens when ISPs change IPv6 prefix assignments, = which is always a problem for external connections. > =20 > If this is true, it seems like a pretty big problem. It's bad enough = when ISPs change my IP address; now they are going to renumber my entire = network? =20 > =20 > At least on a single-link, changing an IPv6 prefix isn't more complex = than changing the external address of a NAT44: It breaks current = connections but everything else is automatically fixed. > =20 > For instance, when Free obtained a /26 instead of its initial /32, in = 2008, my IPv6 prefix changed but I didn't notice it before examining = which IPv6 address (GUA) my Mac was using.=20 > =20 > =20 > DHCP has generally been designed to prevent this: when you renew your = address, you get the same address, not a different one, and when you = renew your prefix, the same is true. > =20 > If I get it right, you assume that each host has both a ULA, for local = sessions, and a GUA, have Internet e2e transparency. > But, as noticed, not all hosts can do this, so that this model less = workable than the current one where only GUAs are used. > =20 > RD > =20 > =20 --Apple-Mail-25--487122062 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Well, = you have people pro and contra ULA-support.  Lots of people = question the real need for ULA as well.
I tend to agree you don=92t = really need it, at least not in the most common deployments (we=92re = mainly doing residential CPEs), although our CPE supports it today = (configurable).  It indeed adds a little extra complexity, as you = get more and more addresses.  In a residential scenario, you often = only have 1 LAN segment, hence the need for ULA becomes less important I = guess.
It=92s = there for people who want to use it, I guess, and can be maybe useful in = some more advanced roll-outs or future home-net solutions with multiple = LAN segments in the home.  As we=92re deploying in a managed CPE, = it=92s up to our customer to either enable or not the ULA creation on = the advertising = interface(s).

<= div>Right.
Thanks,
RD


From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or= g] On Behalf = Of R=E9mi = Despr=E9s
Sent: donderdag 23 februari 2012 = 15:08
To: Ted = Lemon
Cc: v6ops@ietf.org;  Re: [v6ops] 6204bis and WAN = disappearing
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> Date: Thu, 23 Feb 2012 14:32:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1251.1) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:33:06 -0000 I would be interested to hear from anyone who has any experience with = current IPv6 host implementations and the scenarios we are discussing = here: specifically: * ULA prefix with GUA advertised only when WAN connectivity is operable. = What happens when the availability of the GUA flaps? Do hosts operate = as expected and continue to communicate with other hosts using the ULA = prefixes? Are any problems attributable to implementation issues or are = there protocol problems? * GUA with no ULA and a flash changeover when the WAN link comes back = up. How are the RAs manipulated and is it possible to cause all hosts = to switch to the new prefix immediately? - Ralph On Feb 23, 2012, at 2:15 PM 2/23/12, Wuyts Carl wrote: > Well, you have people pro and contra ULA-support. Lots of people = question the real need for ULA as well. > I tend to agree you don=92t really need it, at least not in the most = common deployments (we=92re mainly doing residential CPEs), although our = CPE supports it today (configurable). It indeed adds a little extra = complexity, as you get more and more addresses. In a residential = scenario, you often only have 1 LAN segment, hence the need for ULA = becomes less important I guess. > =20 > It=92s there for people who want to use it, I guess, and can be maybe = useful in some more advanced roll-outs or future home-net solutions with = multiple LAN segments in the home. As we=92re deploying in a managed = CPE, it=92s up to our customer to either enable or not the ULA creation = on the advertising interface(s). > =20 > Regs > Carl > =20 > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of R=E9mi Despr=E9s > Sent: donderdag 23 februari 2012 15:08 > To: Ted Lemon > Cc: v6ops@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org > Subject: Re: [v6ops] 6204bis and WAN disappearing > =20 > =20 > Le 2012-02-23 =E0 14:37, Ted Lemon a =E9crit : >=20 >=20 > On Feb 23, 2012, at 3:26 AM, R=E9mi Despr=E9s = > wrote: > Even if it doesn't, it isn't a serious problem: the host is informed = in ICMPv6 that unreachability of the destination is due to ingress or = egress filtering (Type 1 code 5 per RFC4443). > What it does next is implementation dependent, but checking its source = address makes sense. > =20 > This is true, but it leaves the problem of what happens to net-local = communication when this happens. > =20 > If local communication uses GUAs and, as I suggest, GUAs remain valid = in case of WAN-link failure, local communication continues undisrupted. >=20 >=20 > As a reminder, the original point I was making was simply that it is = in fact necessary, or at least desirable, to use ULAs for internal = communication. > =20 > AFAIK, it creates more problems than it solves. > My home site uses IPv6 without ULAs. It has no problem, and I don't = know how I could use ULAs today if I wanted to. > =20 > Wanting to use ULA it in my understanding against the keep-it-simple = principle. > =20 > =20 > Besides, this only happens when ISPs change IPv6 prefix assignments, = which is always a problem for external connections. > =20 > If this is true, it seems like a pretty big problem. It's bad enough = when ISPs change my IP address; now they are going to renumber my entire = network? =20 > =20 > At least on a single-link, changing an IPv6 prefix isn't more complex = than changing the external address of a NAT44: It breaks current = connections but everything else is automatically fixed. > =20 > For instance, when Free obtained a /26 instead of its initial /32, in = 2008, my IPv6 prefix changed but I didn't notice it before examining = which IPv6 address (GUA) my Mac was using.=20 > =20 > =20 > DHCP has generally been designed to prevent this: when you renew your = address, you get the same address, not a different one, and when you = renew your prefix, the same is true. > =20 > If I get it right, you assume that each host has both a ULA, for local = sessions, and a GUA, have Internet e2e transparency. > But, as noticed, not all hosts can do this, so that this model less = workable than the current one where only GUAs are used. > =20 > RD > =20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From twinters@iol.unh.edu Thu Feb 23 06:51:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1956921F880B for ; Thu, 23 Feb 2012 06:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7dGvhkA85IY for ; Thu, 23 Feb 2012 06:51:15 -0800 (PST) Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by ietfa.amsl.com (Postfix) with SMTP id 12A5721F87F1 for ; Thu, 23 Feb 2012 06:51:07 -0800 (PST) Received: from postal.iol.unh.edu ([132.177.123.84]) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKT0ZSW1ryym+FfAT2l9nyJoWcv0pOXmuy@postini.com; Thu, 23 Feb 2012 06:51:14 PST Received: from optimus.iol.unh.edu (optimus.iol.unh.edu [132.177.118.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by postal.iol.unh.edu (Postfix) with ESMTPSA id A21ED8F0067; Thu, 23 Feb 2012 09:51:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Timothy Winters In-Reply-To: Date: Thu, 23 Feb 2012 09:51:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0084149E-B037-4988-8AE4-0DE55D78E9B1@iol.unh.edu> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> To: Ralph Droms X-Mailer: Apple Mail (2.1257) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:51:16 -0000 Hi Ralph, On Feb 23, 2012, at 9:32 AM, Ralph Droms wrote: > I would be interested to hear from anyone who has any experience with = current IPv6 host implementations and the scenarios we are discussing = here: specifically: >=20 > * ULA prefix with GUA advertised only when WAN connectivity is = operable. What happens when the availability of the GUA flaps? Do = hosts operate as expected and continue to communicate with other hosts = using the ULA prefixes? Are any problems attributable to implementation = issues or are there protocol problems? We haven't tried the first scenario at the CE Events yet, but we are = holding an event in April and I will make sure to try this out. I will = report back to v6ops with what we find. > * GUA with no ULA and a flash changeover when the WAN link comes back = up. How are the RAs manipulated and is it possible to cause all hosts = to switch to the new prefix immediately? If the CE Router is not rebooted, it will transmit Router Advertisements = with the new prefix and set the valid lifetime to 0 on the deprecated = prefix. Most host implementations that we have used will properly = deprecate the old prefix and not use it for new sessions. Regards, Tim >=20 > - Ralph >=20 > On Feb 23, 2012, at 2:15 PM 2/23/12, Wuyts Carl wrote: >=20 >> Well, you have people pro and contra ULA-support. Lots of people = question the real need for ULA as well. >> I tend to agree you don=92t really need it, at least not in the most = common deployments (we=92re mainly doing residential CPEs), although our = CPE supports it today (configurable). It indeed adds a little extra = complexity, as you get more and more addresses. In a residential = scenario, you often only have 1 LAN segment, hence the need for ULA = becomes less important I guess. >>=20 >> It=92s there for people who want to use it, I guess, and can be maybe = useful in some more advanced roll-outs or future home-net solutions with = multiple LAN segments in the home. As we=92re deploying in a managed = CPE, it=92s up to our customer to either enable or not the ULA creation = on the advertising interface(s). >>=20 >> Regs >> Carl >>=20 >>=20 >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of R=E9mi Despr=E9s >> Sent: donderdag 23 februari 2012 15:08 >> To: Ted Lemon >> Cc: v6ops@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org >> Subject: Re: [v6ops] 6204bis and WAN disappearing >>=20 >>=20 >> Le 2012-02-23 =E0 14:37, Ted Lemon a =E9crit : >>=20 >>=20 >> On Feb 23, 2012, at 3:26 AM, R=E9mi Despr=E9s = >> wrote: >> Even if it doesn't, it isn't a serious problem: the host is informed = in ICMPv6 that unreachability of the destination is due to ingress or = egress filtering (Type 1 code 5 per RFC4443). >> What it does next is implementation dependent, but checking its = source address makes sense. >>=20 >> This is true, but it leaves the problem of what happens to net-local = communication when this happens. >>=20 >> If local communication uses GUAs and, as I suggest, GUAs remain valid = in case of WAN-link failure, local communication continues undisrupted. >>=20 >>=20 >> As a reminder, the original point I was making was simply that it is = in fact necessary, or at least desirable, to use ULAs for internal = communication. >>=20 >> AFAIK, it creates more problems than it solves. >> My home site uses IPv6 without ULAs. It has no problem, and I don't = know how I could use ULAs today if I wanted to. >>=20 >> Wanting to use ULA it in my understanding against the keep-it-simple = principle. >>=20 >>=20 >> Besides, this only happens when ISPs change IPv6 prefix assignments, = which is always a problem for external connections. >>=20 >> If this is true, it seems like a pretty big problem. It's bad = enough when ISPs change my IP address; now they are going to renumber my = entire network? =20 >>=20 >> At least on a single-link, changing an IPv6 prefix isn't more complex = than changing the external address of a NAT44: It breaks current = connections but everything else is automatically fixed. >>=20 >> For instance, when Free obtained a /26 instead of its initial /32, in = 2008, my IPv6 prefix changed but I didn't notice it before examining = which IPv6 address (GUA) my Mac was using.=20 >>=20 >>=20 >> DHCP has generally been designed to prevent this: when you renew your = address, you get the same address, not a different one, and when you = renew your prefix, the same is true. >>=20 >> If I get it right, you assume that each host has both a ULA, for = local sessions, and a GUA, have Internet e2e transparency. >> But, as noticed, not all hosts can do this, so that this model less = workable than the current one where only GUAs are used. >>=20 >> RD >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Thu Feb 23 07:24:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1317021F8525 for ; Thu, 23 Feb 2012 07:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMlc8vyqQJ1K for ; Thu, 23 Feb 2012 07:24:20 -0800 (PST) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id F221A21F854A for ; Thu, 23 Feb 2012 07:24:19 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id dTQJ1i00437Y3f403TQJ3v; Thu, 23 Feb 2012 16:24:18 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 23 Feb 2012 16:24:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> To: Ralph Droms X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:24:21 -0000 Hello Ralph, Le 2012-02-23 =E0 15:32, Ralph Droms a =E9crit : > I would be interested to hear from anyone who has any experience with = current IPv6 host implementations and the scenarios we are discussing = here: specifically: >=20 > * ULA prefix with GUA advertised only when WAN connectivity is = operable. What happens when the availability of the GUA flaps? Do = hosts operate as expected and continue to communicate with other hosts = using the ULA prefixes? Are any problems attributable to implementation = issues or are there protocol problems? No personal experience with this. > * GUA with no ULA and a flash changeover when the WAN link comes back = up. How are the RAs manipulated and is it possible to cause all hosts = to switch to the new prefix immediately? 1. If a host attempts to establish an outgoing session before having = noticed the newly advertised WAN prefix, it will normally get an ICMPv6 = error message with Type 1 and Code 5 (unreachable destination due to = ingress or egress filtering). - This message should be returned by the CPE, and if not by the ISP = network. - When this host receives an RA with the new prefix, be it solicited or = not, everything is normal again.=20 2. I have no experience of local IPv6 sessions that would have existed = in case of WAN link failure. Yet, it is clear that using the last global = prefix as a local prefix until the link comes back provides a better = service in this respect than switching to a new prefix, with no known = drawback AFAIAC. 3. The need to CHANGE addresses after the WAN link comes back should = remain exceptional.=20 - In my personal experience, it happened only once in more than 4 years. - I have no count of WAN link outages, but I know that it is much larger = than just one (DSL cable unplugged ...).=20 Regards, RD =20 >=20 > - Ralph >=20 > On Feb 23, 2012, at 2:15 PM 2/23/12, Wuyts Carl wrote: >=20 >> Well, you have people pro and contra ULA-support. Lots of people = question the real need for ULA as well. >> I tend to agree you don=92t really need it, at least not in the most = common deployments (we=92re mainly doing residential CPEs), although our = CPE supports it today (configurable). It indeed adds a little extra = complexity, as you get more and more addresses. In a residential = scenario, you often only have 1 LAN segment, hence the need for ULA = becomes less important I guess. >>=20 >> It=92s there for people who want to use it, I guess, and can be maybe = useful in some more advanced roll-outs or future home-net solutions with = multiple LAN segments in the home. As we=92re deploying in a managed = CPE, it=92s up to our customer to either enable or not the ULA creation = on the advertising interface(s). >>=20 >> Regs >> Carl >>=20 >>=20 >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of R=E9mi Despr=E9s >> Sent: donderdag 23 februari 2012 15:08 >> To: Ted Lemon >> Cc: v6ops@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org >> Subject: Re: [v6ops] 6204bis and WAN disappearing >>=20 >>=20 >> Le 2012-02-23 =E0 14:37, Ted Lemon a =E9crit : >>=20 >>=20 >> On Feb 23, 2012, at 3:26 AM, R=E9mi Despr=E9s = >> wrote: >> Even if it doesn't, it isn't a serious problem: the host is informed = in ICMPv6 that unreachability of the destination is due to ingress or = egress filtering (Type 1 code 5 per RFC4443). >> What it does next is implementation dependent, but checking its = source address makes sense. >>=20 >> This is true, but it leaves the problem of what happens to net-local = communication when this happens. >>=20 >> If local communication uses GUAs and, as I suggest, GUAs remain valid = in case of WAN-link failure, local communication continues undisrupted. >>=20 >>=20 >> As a reminder, the original point I was making was simply that it is = in fact necessary, or at least desirable, to use ULAs for internal = communication. >>=20 >> AFAIK, it creates more problems than it solves. >> My home site uses IPv6 without ULAs. It has no problem, and I don't = know how I could use ULAs today if I wanted to. >>=20 >> Wanting to use ULA it in my understanding against the keep-it-simple = principle. >>=20 >>=20 >> Besides, this only happens when ISPs change IPv6 prefix assignments, = which is always a problem for external connections. >>=20 >> If this is true, it seems like a pretty big problem. It's bad = enough when ISPs change my IP address; now they are going to renumber my = entire network? =20 >>=20 >> At least on a single-link, changing an IPv6 prefix isn't more complex = than changing the external address of a NAT44: It breaks current = connections but everything else is automatically fixed. >>=20 >> For instance, when Free obtained a /26 instead of its initial /32, in = 2008, my IPv6 prefix changed but I didn't notice it before examining = which IPv6 address (GUA) my Mac was using.=20 >>=20 >>=20 >> DHCP has generally been designed to prevent this: when you renew your = address, you get the same address, not a different one, and when you = renew your prefix, the same is true. >>=20 >> If I get it right, you assume that each host has both a ULA, for = local sessions, and a GUA, have Internet e2e transparency. >> But, as noticed, not all hosts can do this, so that this model less = workable than the current one where only GUAs are used. >>=20 >> RD >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From rbonica@juniper.net Thu Feb 23 07:24:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A02D21F855E for ; Thu, 23 Feb 2012 07:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.218 X-Spam-Level: X-Spam-Status: No, score=-106.218 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oQR3ftkwhac for ; Thu, 23 Feb 2012 07:24:16 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2611221F8526 for ; Thu, 23 Feb 2012 07:24:16 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKT0ZaGAIZAf08wEL/9TO6j/5tx9Vzl9DL@postini.com; Thu, 23 Feb 2012 07:24:16 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 23 Feb 2012 07:22:35 -0800 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 23 Feb 2012 07:22:34 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 23 Feb 2012 10:22:11 -0500 From: Ronald Bonica To: "Livingood, Jason" , Marc Lampo , "EXT - joelja@bogus.com" , "'Mark Andrews'" Date: Thu, 23 Feb 2012 10:22:10 -0500 Thread-Topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-Index: AQHM8NGMkD00gtDZEUSP/1IDM55exZZHw6MAgADeEzCAAdSqgIAAJYzA Message-ID: <13205C286662DE4387D9AF3AC30EF456D7674BFE2D@EMBX01-WF.jnpr.net> References: <00e401ccf143$303934a0$90ab9de0$@lampo@eurid.eu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456D7674BFE2DEMBX01WFjnprn_" MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:24:21 -0000 --_000_13205C286662DE4387D9AF3AC30EF456D7674BFE2DEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I will allow the dust to settle for another 24 hours and then send the draf= t on for publication. Ron From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Sent: Thursday, February 23, 2012 8:07 AM To: Marc Lampo; Ronald Bonica; EXT - joelja@bogus.com; 'Mark Andrews' Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Info= rmational RFC On 2/22/12 4:20 AM, "Marc Lampo" > wrote: 2) regarding the previous sentence : "So even though an authoritative DNS server will selectively return AAAA resource records and/or A resource records, these resource records can= certainly still be signed." In this context - assuming we are talking about a signed domain with chain-= of-trust appropriately in place - I'd propose : "So even though an authoritative DNS server will selectively return AAAA resource records and/or A resource records, these resource records mus= t be signed, as well as any accompanying NextSecure information that proves= existence and/or not-existence of AAAA resource records." Great suggestion, thank you for suggesting actual text! Correction to that = sentence made and will publish momentarily in a -10. - Jason So : -> it's a *must* -> it's not only the A and/or AAAA RRs, but also the NSEC/NSEC3 RRs. Kind regards, Marc Lampo Security Officer EURid (for .eu) From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] Sent: 21 February 2012 08:55 PM To: Ronald Bonica; Marc Lampo; EXT - joelja@bogus.com; Mark Andrews Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC I made this addition in the relevant section (6.1). Let me know if it does not capture this sufficiently (or does so inelegantly). Thanks Jason In practical terms this means that two separate views or zones are used, each of which is signed, so that whether or not particular resource records exist, the existence or non-existence of the record can still be validated using DNSSEC. On 2/21/12 2:46 PM, "Livingood, Jason" > wrote: Good idea and it is quick & easy edit. Making the change now. Will send text momentarily. Jason On 2/21/12 8:44 AM, "Ronald Bonica" > wrote: Authors, What do you think? Ron -----Original Message----- From: Marc Lampo [mailto:marc.lampo@eurid.eu] Sent: Tuesday, February 21, 2012 2:03 AM To: Ronald Bonica; EXT - joelja@bogus.com Cc: v6ops@ietf.org Subject: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Hello, I had assumed : 1 zone file (and Mark Andrews correctly pointed at "views"). Would adding this piece of information, directly in the RFC, be useful to avoid confusion for future readers ? Thanks and kind regards, Marc Lampo -----Original Message----- From: Ronald Bonica [mailto:rbonica@juniper.net] Sent: 20 February 2012 11:55 PM To: EXT - joelja@bogus.com; Marc Lampo Cc: v6ops@ietf.org Subject: RE: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Marc, Havard, Are you satisfied with the answers provided by Joel and Mark? Ron -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of EXT - joelja@bogus.com Sent: Monday, February 20, 2012 4:58 PM To: Marc Lampo Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC On 2/20/12 06:32 , Marc Lampo wrote: > Hello, > > (sorry to be late with my comments, bit overloaded on my side) > > 6.1 Security Considerations - paragraph 2 (on DNSSEC) > The text states : "there should not be any negative impact on DNSSEC" > In my opinion, this is *wrong* : > IMHO the following applies. if you have one zone yeah I agree. If you have two zones one with aaaa and one without (assuming this is done with dns views style implementation) you can sign both and they'll both be valid and complete from the vantage point of a client which resolves one or the other of them but not both. this is a traditional split horizon problem. it's just not inside/outside. joel > It is correct that, if an AAAA record exists (in a DNSSEC's zone), > the appropriate RRSIG will be known to authoritative NS's. > If, via white listing, the decision is taken not to present the AAAA > record > (and its signature), this seems OK. > > However : not returning an AAAA record seems identical to : there is no > AAAA record. > And that - there is no AAAA record - yields to "Next Secure" changes ! > If no AAAA record exists, for a name, the corresponding NSEC (NSEC3) > record > should not hold a reference to AAAA. > But if that AAAA record does exist, the authoritative NS will have NSEC > (NSEC3) > data that shows so. > > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but due to > whitelisting > will not be returned), cannot be proven by accompanying (and required) > NSEC (NSEC3) > information. > Hence : this draft will/might make DNSSEC validating name servers fail. > > > If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) in > detail, > please observe : > 1) the caching name server (and "stub resolver") ask 2 queries > (there is only one line, > but it are two queries : one for "A", one for "AAAA") > 2) if the caching name server (or stub resolver) performs DNSSEC > validation, > it will never accept a reply of "NODATA" to the query of AAAA > (because the NSEC (NSEC3) information will not prove that > non-existance) > ((and the validating name server will repeat the query to all > authoritative NS's, looking for a validatable answer)) > > (the final result, to the user might be that only the A record is useable > - mission accomplished ? > But the side effect will be that validating caching name servers will hit > *all* authoritative servers for the domain, > "in search of" a correctly validating answer.) > > So, while for the end-user, the result might be identical, > one "security impact" of this approach is > additional (useless) DNS traffic and > additional load on authoritative NS's (that implement whitelisting) > > > Kind regards, > > Marc Lampo > Security Officer > EURid > > > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org] > Sent: 01 February 2012 04:09 PM > To: IETF-Announce > Cc: v6ops@ietf.org > Subject: [v6ops] Last Call: > > (Considerations for Transitioning Content to IPv6) to Informational RFC > > > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'Considerations for Transitioning Content to IPv6' > as an > Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-15. Exceptio= nally, comments may be > sent to iesg@ietf.org instead. In either case, plea= se retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes considerations for the transition of end user > content on the Internet to IPv6. While this is tailored to address > end user content, which is typically web-based, many aspects of this > document may be more broadly applicable to the transition to IPv6 of > other applications and services. This document explores the > challenges involved in the transition to IPv6, potential migration > tactics, possible migration phases, and other considerations. The > audience for this document is the Internet community generally, > particularly IPv6 implementers. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- whitelisting-impl > ications/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- whitelisting-impl > ications/ > > > No IPR declarations have been submitted directly on this I-D. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo= /v6ops --_000_13205C286662DE4387D9AF3AC30EF456D7674BFE2DEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

&nb= sp;

I will allow the dust to se= ttle for another 24 hours and then send the draft on for publication.<= /o:p>

 

         &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;Ron

 

 

From: Livingood, Jason [mailto:Jason_Livingoo= d@cable.comcast.com]
Sent: Thursday, February 23, 2012 8:07 AMTo: Marc Lampo; Ronald Bonica; EXT - joelja@bogus.com; 'Mark Andre= ws'
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Last Call: = <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Consider= ations for Transitioning Content to IPv6) to Informational RFC

 

2) regarding the previous= sentence :

"So even though an authoritativ= e DNS server will selectively return

AAAA resour= ce records and/or A resource records, these resource records can certa= inly still be signed."

 

In this context - assuming we are talking about a signed doma= in with chain-of-trust appropriately in place - I'd propose :

"So even though an authoritative DNS server wi= ll selectively return

= AAAA resource records and/= or A resource records, these resource records must be signed, as = well as any accompanying NextSecure information that proves existence = and/or not-existence of AAAA resource records."

<= /div>

 

Great suggestion, thank you for suggesting actual text! Correctio= n to that sentence made and will publish momentarily in a –10.

=  

- Jason

<= span style=3D'color:black'> 

 

=

 

So :

-> it's a *must*

-> it's not on= ly the A and/or AAAA RRs, but also the NSEC/NSEC3 RRs.

 

 

=

= Kind regards,

 

=

= Marc Lampo

Security Officer

EURid (for .eu)

 <= /p>

 

Sent: 21 February 2012 08:55 PM=

To: Ronald Bonica; Marc Lampo; EXT - joelja@bogus.com; Mark Andrews

Cc: v6ops@ietf.org<= /o:p>

Subject: Re: [v6ops] Last Call:

=

<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt>

(Considerations for Transitioning Content to IPv6) = to Informational RFC

<= span style=3D'font-family:Consolas;color:black'> 

I made this addition in the relevant section (6.1). Let me know if i= t does

not capture this sufficiently (or does so= inelegantly). 

<= span style=3D'font-family:Consolas;color:black'> 

Thanks

Jason

<= div>

<= o:p> 

In practical terms this means that two sep= arate views or zones are used,

each of which is = signed, so that whether or not particular resource

records exist, the existence or non-existence of the record can still be=

validated using DNSSEC. =

 

 

 

 

On = 2/21/12 2:46 PM, "Livingood, Jason" <Jason_Livingood@cable.comcast.com><= /o:p>

wrote:

 

Good idea and it is quick & easy edit. Making the change= now. Will send

text momentarily.

 

Jason

<= /div>

 

On 2/21/12 8:44 AM, "Ronald Bon= ica" <rbonica@juniper.net> wrote:

<= div>

A= uthors,

<= div>

&= nbsp;           &nbs= p;   Ron

Subject: = RE: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-

implications-08.txt> (Considerations for Transitioning= Content to IPv6)

to Informational RFC

Hello,

I had assumed : 1 zone = file (and Mark Andrews correctly pointed at

&quo= t;views").

Would adding this piece of infor= mation, directly in the RFC,

be useful to avoid = confusion for future readers ?

Thanks and kind r= egards,

Marc Lampo

--= ---Original Message-----

From: Ronald Bonica [mailto:rbonica@juniper.net]

Sent: 20 February 2012 11:55 PM

<= /div>

To: EXT - joelja@bogus.com; Ma= rc Lampo

Subject: RE: [v6ops] Last Ca= ll:

<draft-ietf-v6ops-v6-aaaa-whitelisting-im= plications-08.txt>

= (Considerations for Transi= tioning Content to IPv6) to Informational RFC

Ma= rc, Havard,

Are you satisfied with the answers p= rovided by Joel and Mark?

   &nbs= p;            &= nbsp;           &nbs= p;         Ron

-----Original Message-----

Behalf<= /span>

Sent: Monday, Febru= ary 20, 2012 4:58 PM

<= span style=3D'font-family:Consolas;color:black'>To: Marc Lampo

Subject: Re: [v6ops] Last Call: <draft-ietf-v6op= s-v6-aaaa-

whitelisting-=

implications-08.txt> (Consideratio= ns for Transitioning Content to

IPv= 6)

to Informational RFC=

 

On 2/20/12 06:32 ,= Marc Lampo wrote:

> Hello,=

> 

<= span style=3D'font-family:Consolas;color:black'>> (sorry to be late with= my comments, bit overloaded on my side)

> 

> 6.1 Security Considerations - paragraph= 2 (on DNSSEC)

> The text states : "ther= e should not be any negative impact on

DNSSEC"

> In my = opinion, this is *wrong* :

> =

 

IMHO the following appli= es.

 

if you hav= e one zone yeah I agree.

 

If you have two zones one with aaaa and one without (assuming th= is is

done with dns views style implementation) = you can sign both and

they'll<= /o:p>

both be valid and complete from t= he vantage point of a client which

resolves one = or the other of them but not both.

 

this is a traditional split horizon problem. it's just= not

inside/outside.

=

=  

joel

&nbs= p;

> It is correct that, if an AAAA record exists = (in a DNSSEC's zone),

= > the appropriate RRSIG= will be known to authoritative NS's.

> If, v= ia white listing, the decision is taken not to present the

AAAA

> record

> (and its signature), this se= ems OK.

> 

&g= t; However : not returning an AAAA record seems identical to : there

is

no

> AAAA record.<= /p>

> And that - there is no AAAA record - yields to "Next Sec= ure"

changes=

!

> If no AAAA = record exists, for a name, the corresponding NSEC

(NSEC3)

=

> = record

> should not hold a reference to AAAA.=

> But if that AAAA record does exist, the au= thoritative NS will have

NSEC<= /p>

> (NSEC3)

= > data that shows so.

> 

> A DNSS= EC query (ENDS0 + DO set) for AAAA (and the AAAA exists but

due

to

> whitelisting

> will not be returned), cannot be proven by accompanying (and

required)

> NSEC (NSEC3)=

> information.

&g= t; Hence : this draft will/might make DNSSEC validating name servers

fail.

> =

> 

> If you look at = 4.3.1.1 (Description of DNS Resolver Whitelisting)

in

> deta= il,

> please observe :

<= /div>

> 1) the caching name server (and "stub resolver") ask 2 = queries

>     (there is o= nly one line,

>     =  but it are two queries : one for "A", one for "AAAA&qu= ot;)

> 2) if the caching name server (or stub= resolver) performs DNSSEC

> validation,=

>     it will never accept a = reply of "NODATA" to the query of AAAA

>     (because the NSEC (NSEC3) information will no= t prove that

> non-existance)

>     ((and the validating name server w= ill repeat the query to all

>  &nbs= p;    authoritative NS's, looking for a validatable answer))=

> 

> (the= final result, to the user might be that only the A record is

useable

= >  - mission = accomplished ?

>  But the side effe= ct will be that validating caching name servers

=

= will hit

>   *all* authoritative = servers for the domain,

>   "i= n search of" a correctly validating answer.)

> 

> So, while for the end-user, th= e result might be identical,

> one "secu= rity impact" of this approach is

> addit= ional (useless) DNS traffic and

> additional = load on authoritative NS's (that implement whitelisting)<= /p>

> 

> =

> Kind regards,

> 

> Marc Lampo

> Security= Officer

> EURid

> 

> 

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

> Sent: 01 February 2012 04:09 PM=

> To: IETF-Announce

> Subject: [v6ops] Last Call:

> <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt>

> (Considerations for Transitioning Content to = IPv6) to Informational

RFC

=

> 

> 

> The IESG has received a request from the IPv6 Operations WG (v6= ops)

to

> consider= the following document:

> - 'Considerations = for Transitioning Content to IPv6'

> &nb= sp; <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> as an=

> Informational RFC

> 

> The IESG plans to make a deci= sion in the next few weeks, and

sol= icits

> final comments on= this action. Please send substantive comments to

the

> ietf= @ietf.org mailing lists by 2012-02-15. Exceptionally, comments

may be

> sent to iesg@ietf.org instead. In either case, please= retain the

> beginning of the Subject line t= o allow automated sorting.

> =

> Abstract

> 

> 

>  =   This document describes considerations for the transition of en= d

user

> &nb= sp;  content on the Internet to IPv6.  While this is ta= ilored to

address

&g= t;    end user content, which is typically web-based, m= any aspects of

this

<= div>

&= gt;    document may be more broadly applicable to the t= ransition to

IPv6=

of

> &nb= sp;  other applications and services.  This document ex= plores the

>    challenge= s involved in the transition to IPv6, potential

=

migration

=

>&= nbsp;   tactics, possible migration phases, and other consid= erations.

The

=

>    audience for this doc= ument is the Internet community generally,

=

>&= nbsp;   particularly IPv6 implementers.

> 

> 

> 

> <= /p>

> The file can be obtained via

whitelisting-impl

> ications/

> 

> IESG discus= sion can be tracked via

whitelisti= ng-impl

> ications/

> 

> 

> No IPR declarations have been submitted directly on this I-D.<= /o:p>

> 

>&nbs= p;

> 

> _______= ________________________________________

> v6= ops mailing list

> 

 

_____________________________________= __________

v6ops mailing list<= /p>

_______________________________________________

v6ops mailing list

 

<= div>

_= ______________________________________________ v6ops mailing list

 

= --_000_13205C286662DE4387D9AF3AC30EF456D7674BFE2DEMBX01WFjnprn_-- From marka@isc.org Thu Feb 23 12:51:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151F821F88A6 for ; Thu, 23 Feb 2012 12:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.558 X-Spam-Level: *** X-Spam-Status: No, score=3.558 tagged_above=-999 required=5 tests=[AWL=-6.043, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, MANGLED_DOMAIN=2.3, MANGLED_EFFEX=2.3, MANGLED_MEDS=2.3, MANGLED_PLEASE=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfNLRMoKNdfz for ; Thu, 23 Feb 2012 12:51:29 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 28DB321F87C3 for ; Thu, 23 Feb 2012 12:51:14 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id D7BA75F98B9; Thu, 23 Feb 2012 20:50:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:968:e107:e473:6b83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 979E9216C36; Thu, 23 Feb 2012 20:50:46 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 0D1841DC357A; Fri, 24 Feb 2012 07:50:43 +1100 (EST) To: Ronald Bonica From: Mark Andrews References: <00e401ccf143$303934a0$90ab9de0$@lampo@eurid.eu> <13205C286662DE4387D9AF3AC30EF456D7674BFE2D@EMBX01-WF.jnpr.net> In-reply-to: Your message of "Thu, 23 Feb 2012 10:22:10 CDT." <13205C286662DE4387D9AF3AC30EF456D7674BFE2D@EMBX01-WF.jnpr.net> Date: Fri, 24 Feb 2012 07:50:42 +1100 Message-Id: <20120223205043.0D1841DC357A@drugs.dv.isc.org> Cc: Marc Lampo , "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 20:51:34 -0000 So even though an authoritative DNS server will selectively return AAAA resource records and/or A resource records, these resource records must be signed, as well as any accompanying NextSECure (NSEC) information that proves existence and/or not- existence of AAAA resource records. So even though an authoritative DNS server will selectively return AAAA resource records or a non existance response both types of response will be signed and will validate. ("non existance" covers both name error responses and NOERROR no data responses depending apon the presence or absence of data other than AAAA records at the name. Usually there will be at least a A records so one would expect a NOERROR no data.) In message <13205C286662DE4387D9AF3AC30EF456D7674BFE2D@EMBX01-WF.jnpr.net>, Ronald Bonica writes: > --_000_13205C286662DE4387D9AF3AC30EF456D7674BFE2DEMBX01WFjnprn_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Folks, > > I will allow the dust to settle for another 24 hours and then send the draf= > t on for publication. > > Ron > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: Thursday, February 23, 2012 8:07 AM > To: Marc Lampo; Ronald Bonica; EXT - joelja@bogus.com; 'Mark Andrews' > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Last Call: ications-08.txt> (Considerations for Transitioning Content to IPv6) to Info= > rmational RFC > > On 2/22/12 4:20 AM, "Marc Lampo" id.eu>> wrote: > 2) regarding the previous sentence : > "So even though an authoritative DNS server will selectively return > AAAA resource records and/or A resource records, these resource records can= > certainly still be signed." > > In this context - assuming we are talking about a signed domain with chain-= > of-trust appropriately in place - I'd propose : > "So even though an authoritative DNS server will selectively return > AAAA resource records and/or A resource records, these resource records mus= > t be signed, as well as any accompanying NextSecure information that proves= > existence and/or not-existence of AAAA resource records." > > Great suggestion, thank you for suggesting actual text! Correction to that = > sentence made and will publish momentarily in a -10. > > - Jason > > > > So : > -> it's a *must* > -> it's not only the A and/or AAAA RRs, but also the NSEC/NSEC3 RRs. > > > Kind regards, > > Marc Lampo > Security Officer > EURid (for .eu) > > > From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com] > Sent: 21 February 2012 08:55 PM > To: Ronald Bonica; Marc Lampo; EXT - joelja@bogus.com om>; Mark Andrews > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Last Call: > > (Considerations for Transitioning Content to IPv6) to Informational RFC > > I made this addition in the relevant section (6.1). Let me know if it does > not capture this sufficiently (or does so inelegantly). > > Thanks > Jason > > In practical terms this means that two separate views or zones are used, > each of which is signed, so that whether or not particular resource > records exist, the existence or non-existence of the record can still be > validated using DNSSEC. > > > > > On 2/21/12 2:46 PM, "Livingood, Jason" ailto:Jason_Livingood@cable.comcast.com>> > wrote: > > Good idea and it is quick & easy edit. Making the change now. Will send > text momentarily. > > Jason > > On 2/21/12 8:44 AM, "Ronald Bonica" iper.net>> wrote: > > Authors, > > What do you think? > > Ron > > -----Original Message----- > From: Marc Lampo [mailto:marc.lampo@eurid.eu] > Sent: Tuesday, February 21, 2012 2:03 AM > To: Ronald Bonica; EXT - joelja@bogus.com > Cc: v6ops@ietf.org > Subject: RE: [v6ops] Last Call: implications-08.txt> (Considerations for Transitioning Content to IPv6) > to Informational RFC > Hello, > I had assumed : 1 zone file (and Mark Andrews correctly pointed at > "views"). > Would adding this piece of information, directly in the RFC, > be useful to avoid confusion for future readers ? > Thanks and kind regards, > Marc Lampo > -----Original Message----- > From: Ronald Bonica [mailto:rbonica@juniper.net] > Sent: 20 February 2012 11:55 PM > To: EXT - joelja@bogus.com; Marc Lampo > Cc: v6ops@ietf.org > Subject: RE: [v6ops] Last Call: > > (Considerations for Transitioning Content to IPv6) to Informational RFC > Marc, Havard, > Are you satisfied with the answers provided by Joel and Mark? > Ron > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-b= > ounces@ietf.org] On > Behalf > Of EXT - joelja@bogus.com > Sent: Monday, February 20, 2012 4:58 PM > To: Marc Lampo > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Last Call: whitelisting- > implications-08.txt> (Considerations for Transitioning Content to > IPv6) > to Informational RFC > > On 2/20/12 06:32 , Marc Lampo wrote: > > Hello, > > > > (sorry to be late with my comments, bit overloaded on my side) > > > > 6.1 Security Considerations - paragraph 2 (on DNSSEC) > > The text states : "there should not be any negative impact on > DNSSEC" > > In my opinion, this is *wrong* : > > > > IMHO the following applies. > > if you have one zone yeah I agree. > > If you have two zones one with aaaa and one without (assuming this is > done with dns views style implementation) you can sign both and > they'll > both be valid and complete from the vantage point of a client which > resolves one or the other of them but not both. > > this is a traditional split horizon problem. it's just not > inside/outside. > > joel > > > It is correct that, if an AAAA record exists (in a DNSSEC's zone), > > the appropriate RRSIG will be known to authoritative NS's. > > If, via white listing, the decision is taken not to present the > AAAA > > record > > (and its signature), this seems OK. > > > > However : not returning an AAAA record seems identical to : there > is > no > > AAAA record. > > And that - there is no AAAA record - yields to "Next Secure" > changes > ! > > If no AAAA record exists, for a name, the corresponding NSEC > (NSEC3) > > record > > should not hold a reference to AAAA. > > But if that AAAA record does exist, the authoritative NS will have > NSEC > > (NSEC3) > > data that shows so. > > > > A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but > due > to > > whitelisting > > will not be returned), cannot be proven by accompanying (and > required) > > NSEC (NSEC3) > > information. > > Hence : this draft will/might make DNSSEC validating name servers > fail. > > > > > > If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) > in > > detail, > > please observe : > > 1) the caching name server (and "stub resolver") ask 2 queries > > (there is only one line, > > but it are two queries : one for "A", one for "AAAA") > > 2) if the caching name server (or stub resolver) performs DNSSEC > > validation, > > it will never accept a reply of "NODATA" to the query of AAAA > > (because the NSEC (NSEC3) information will not prove that > > non-existance) > > ((and the validating name server will repeat the query to all > > authoritative NS's, looking for a validatable answer)) > > > > (the final result, to the user might be that only the A record is > useable > > - mission accomplished ? > > But the side effect will be that validating caching name servers > will hit > > *all* authoritative servers for the domain, > > "in search of" a correctly validating answer.) > > > > So, while for the end-user, the result might be identical, > > one "security impact" of this approach is > > additional (useless) DNS traffic and > > additional load on authoritative NS's (that implement whitelisting) > > > > > > Kind regards, > > > > Marc Lampo > > Security Officer > > EURid > > > > > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: 01 February 2012 04:09 PM > > To: IETF-Announce > > Cc: v6ops@ietf.org > > Subject: [v6ops] Last Call: > > > > (Considerations for Transitioning Content to IPv6) to Informational > RFC > > > > > > The IESG has received a request from the IPv6 Operations WG (v6ops) > to > > consider the following document: > > - 'Considerations for Transitioning Content to IPv6' > > as an > > Informational RFC > > > > The IESG plans to make a decision in the next few weeks, and > solicits > > final comments on this action. Please send substantive comments to > the > > ietf@ietf.org mailing lists by 2012-02-15. Exceptio= > nally, comments > may be > > sent to iesg@ietf.org instead. In either case, plea= > se retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document describes considerations for the transition of end > user > > content on the Internet to IPv6. While this is tailored to > address > > end user content, which is typically web-based, many aspects of > this > > document may be more broadly applicable to the transition to > IPv6 > of > > other applications and services. This document explores the > > challenges involved in the transition to IPv6, potential > migration > > tactics, possible migration phases, and other considerations. > The > > audience for this document is the Internet community generally, > > particularly IPv6 implementers. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > whitelisting-impl > > ications/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa- > whitelisting-impl > > ications/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo= > /v6ops > > > --_000_13205C286662DE4387D9AF3AC30EF456D7674BFE2DEMBX01WFjnprn_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= > //www.w3.org/TR/REC-html40"> =3D"text/html; charset=3Dus-ascii"> oft Word 12 (filtered medium)"> nk=3Dpurple style=3D'word-wrap: break-word;-webkit-nbsp-mode: space;-webkit= > -line-break: after-white-space'>

mal> r:#1F497D'>Folks,

font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nb= > sp;

nt-family:"Calibri","sans-serif";color:#1F497D'>I will allow the dust to se= > ttle for another 24 hours and then send the draft on for publication.<= > /o:p>

amily:"Calibri","sans-serif";color:#1F497D'> 

class=3DMsoNormal> ns-serif";color:#1F497D'>         &= > nbsp;           &nbs= > p;            &= > nbsp;           &nbs= > p;            &= > nbsp;           &nbs= > p;Ron

.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>  pan>

alibri","sans-serif";color:#1F497D'> 

=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'> v>
n 0in 0in'>

ily:"Tahoma","sans-serif"'>From: font-family:"Tahoma","sans-serif"'> Livingood, Jason [mailto:Jason_Livingoo= > d@cable.comcast.com]
Sent: Thursday, February 23, 2012 8:07 AM r>To: Marc Lampo; Ronald Bonica; EXT - joelja@bogus.com; 'Mark Andre= > ws'
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Last Call: = > <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Consider= > ations for Transitioning Content to IPv6) to Informational RFC span>

 

class=3DMsoNormal> y:Consolas;color:black'>On 2/22/12 4:20 AM, "Marc Lampo" < ref=3D"mailto:marc.lampo@eurid.eu">marc.lampo@eurid.eu> wrote: > >

solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-rig= > ht:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">

>2) regarding the previous= > sentence :

e=3D'font-family:Consolas;color:black'>"So even though an authoritativ= > e DNS server will selectively return

ss=3DMsoNormal>AAAA resour= > ce records and/or A resource records, these resource records can certa= > inly still be signed."

ormal>  pan>

;color:black'>In this context - assuming we are talking about a signed doma= > in with chain-of-trust appropriately in place - I'd propose : >

y:Consolas;color:black'>"So even though an authoritative DNS server wi= > ll selectively return

= > AAAA resource records and/= > or A resource records, these resource records must be signed, as = > well as any accompanying NextSecure information that proves existence = > and/or not-existence of AAAA resource records."

<= > /div>

p> 

or:black'>Great suggestion, thank you for suggesting actual text! Correctio= > n to that sentence made and will publish momentarily in a –10. o:p>

= >  

color:black'>- Jason

<= > span style=3D'color:black'> 

=3DMsoNormal> 

= >
n 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTR= > IBUTION_BLOCKQUOTE">

nsolas;color:black'> 

rmal>So : >

lor:black'>-> it's a *must*

soNormal>-> it's not on= > ly the A and/or AAAA RRs, but also the NSEC/NSEC3 RRs. >

black'> 

yle=3D'font-family:Consolas;color:black'> 

= >

= > Kind regards,

yle=3D'font-family:Consolas;color:black'> 

= >

= > Marc Lampo

=3D'font-family:Consolas;color:black'>Security Officer >

black'>EURid (for .eu)

> <= > /p>

r:black'> 

style=3D'font-family:Consolas;color:black'>From: Livingood, Jason [ =3D"mailto:Jason_Livingood@cable.comcast.com">mailto:Jason_Livingood@cable.= > comcast.com]

style=3D'font-family:Consolas;color:black'>Sent: 21 February 2012 08:55 PM= >

amily:Consolas;color:black'>To: Ronald Bonica; Marc Lampo; EXT - "mailto:joelja@bogus.com">joelja@bogus.com; Mark Andrews an>

color:black'>Cc: v6ops@ietf.org<= > /o:p>

Consolas;color:black'>Subject: Re: [v6ops] Last Call:

= >

lack'><draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> >

y:Consolas;color:black'>(Considerations for Transitioning Content to IPv6) = > to Informational RFC

<= > span style=3D'font-family:Consolas;color:black'>  >

black'>I made this addition in the relevant section (6.1). Let me know if i= > t does

font-family:Consolas;color:black'>not capture this sufficiently (or does so= > inelegantly). 

<= > span style=3D'font-family:Consolas;color:black'>  >

black'>Thanks

yle=3D'font-family:Consolas;color:black'>Jason

<= > div>

<= > o:p> 

ont-family:Consolas;color:black'>In practical terms this means that two sep= > arate views or zones are used,

soNormal>each of which is = > signed, so that whether or not particular resource

iv>

k'>records exist, the existence or non-existence of the record can still be= >

amily:Consolas;color:black'>validated using DNSSEC. = >

or:black'> 

style=3D'font-family:Consolas;color:black'> 

iv>

k'> 

=3D'font-family:Consolas;color:black'> 

v>

On = > 2/21/12 2:46 PM, "Livingood, Jason" < ivingood@cable.comcast.com">Jason_Livingood@cable.comcast.com><= > /o:p>

Consolas;color:black'>wrote:

Normal>  span>

s;color:black'>Good idea and it is quick & easy edit. Making the change= > now. Will send

style=3D'font-family:Consolas;color:black'>text momentarily. an>

color:black'> 

pan style=3D'font-family:Consolas;color:black'>Jason

<= > /div>

ack'> 

e=3D'font-family:Consolas;color:black'>On 2/21/12 8:44 AM, "Ronald Bon= > ica" <rbonica@juniper.net >> wrote:

<= > div>

A= > uthors,

<= > div>

&= > nbsp;           &nbs= > p;   Ron

lass=3DMsoNormal>Subject: = > RE: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting- >

olas;color:black'>implications-08.txt> (Considerations for Transitioning= > Content to IPv6)

n style=3D'font-family:Consolas;color:black'>to Informational RFC >

olas;color:black'>Hello,

al>I had assumed : 1 zone = > file (and Mark Andrews correctly pointed at

>

&quo= > t;views").

style=3D'font-family:Consolas;color:black'>Would adding this piece of infor= > mation, directly in the RFC,

Normal>be useful to avoid = > confusion for future readers ?

soNormal>Thanks and kind r= > egards,

'font-family:Consolas;color:black'>Marc Lampo

iv>

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

al>From: Ronald Bonica [ href=3D"mailto:rbonica@juniper.net">mailto:rbonica@juniper.net] o:p>

onsolas;color:black'>Sent: 20 February 2012 11:55 PM

<= > /div>

ack'>To: EXT - joelja@bogus.com; Ma= > rc Lampo

=3D'font-family:Consolas;color:black'>Cc: >v6ops@ietf.org

pan style=3D'font-family:Consolas;color:black'>Subject: RE: [v6ops] Last Ca= > ll:

t-family:Consolas;color:black'><draft-ietf-v6ops-v6-aaaa-whitelisting-im= > plications-08.txt>

= > (Considerations for Transi= > tioning Content to IPv6) to Informational RFC

iv>

Ma= > rc, Havard,

e=3D'font-family:Consolas;color:black'>Are you satisfied with the answers p= > rovided by Joel and Mark?

mal>   &nbs= > p;            &= > nbsp;           &nbs= > p;         Ron n>

t;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_= > OUTLOOK_ATTRIBUTION_BLOCKQUOTE">

nt-family:Consolas;color:black'>-----Original Message----- >

oNormal>Behalf<= > /span>

4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"= > MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">

=3D'font-family:Consolas;color:black'>Of EXT - us.com">joelja@bogus.com

Normal>Sent: Monday, Febru= > ary 20, 2012 4:58 PM

<= > span style=3D'font-family:Consolas;color:black'>To: Marc Lampo span>

s;color:black'>Cc: v6ops@ietf.org >

y:Consolas;color:black'>Subject: Re: [v6ops] Last Call: <draft-ietf-v6op= > s-v6-aaaa-

l>whitelisting-= >

4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D= > "MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">

=3D'font-family:Consolas;color:black'>implications-08.txt> (Consideratio= > ns for Transitioning Content to

v>

IPv= > 6)

solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-rig= > ht:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">

>to Informational RFC= >

:Consolas;color:black'> 

oNormal>On 2/20/12 06:32 ,= > Marc Lampo wrote:

an style=3D'font-family:Consolas;color:black'>> Hello,= >

or:black'>> 

<= > span style=3D'font-family:Consolas;color:black'>> (sorry to be late with= > my comments, bit overloaded on my side)

class=3DMsoNormal>> p> 

t-family:Consolas;color:black'>> 6.1 Security Considerations - paragraph= > 2 (on DNSSEC)

tyle=3D'font-family:Consolas;color:black'>> The text states : "ther= > e should not be any negative impact on

ote>

ck'>DNSSEC"

e;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.7= > 5pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">

ss=3DMsoNormal>> In my = > opinion, this is *wrong* :

rmal>> = >

las;color:black'> 

l>IMHO the following appli= > es.

t-family:Consolas;color:black'> 

ass=3DMsoNormal>if you hav= > e one zone yeah I agree.

al>  >

lor:black'>If you have two zones one with aaaa and one without (assuming th= > is is

ont-family:Consolas;color:black'>done with dns views style implementation) = > you can sign both and

=3DMsoNormal>they'll<= > /o:p>

5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' = > id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">

tyle=3D'font-family:Consolas;color:black'>both be valid and complete from t= > he vantage point of a client which

=3DMsoNormal>resolves one = > or the other of them but not both.

=3DMsoNormal>  o:p>

onsolas;color:black'>this is a traditional split horizon problem. it's just= > not

nt-family:Consolas;color:black'>inside/outside.

= >

= >  

font-family:Consolas;color:black'>joel

lass=3DMsoNormal>&nbs= > p;

ly:Consolas;color:black'>> It is correct that, if an AAAA record exists = > (in a DNSSEC's zone),

= > > the appropriate RRSIG= > will be known to authoritative NS's.

ass=3DMsoNormal>> If, v= > ia white listing, the decision is taken not to present the >

y:Consolas;color:black'>AAAA

=3D'border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;m= > argin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOT= > E">

k'>> record

tyle=3D'font-family:Consolas;color:black'>> (and its signature), this se= > ems OK.

'font-family:Consolas;color:black'>> 

iv>

&g= > t; However : not returning an AAAA record seems identical to : there o:p>

font-family:Consolas;color:black'>is

style=3D'border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4= > .0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLO= > CKQUOTE">

r:black'>no

e=3D'font-family:Consolas;color:black'>> AAAA record.<= > /p>

r:black'>> And that - there is no AAAA record - yields to "Next Sec= > ure"

>changes= >

padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OU= > TLOOK_ATTRIBUTION_BLOCKQUOTE">

-family:Consolas;color:black'>!

MsoNormal>> If no AAAA = > record exists, for a name, the corresponding NSEC

v>

s;color:black'>(NSEC3)

er:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-le= > ft:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
= >

> = > record

font-family:Consolas;color:black'>> should not hold a reference to AAAA.= >

amily:Consolas;color:black'>> But if that AAAA record does exist, the au= > thoritative NS will have

al>NSEC<= > /p>

r:black'>> (NSEC3)

= > > data that shows so. :p>

ily:Consolas;color:black'>> 

ss=3DMsoNormal>> A DNSS= > EC query (ENDS0 + DO set) for AAAA (and the AAAA exists but n>

ly:Consolas;color:black'>due

=3D'border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;m= > argin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOT= > E">

k'>to

ont-family:Consolas;color:black'>> whitelisting

iv>

k'>> will not be returned), cannot be proven by accompanying (and o:p>

onsolas;color:black'>required)

soNormal>> NSEC (NSEC3)= >

amily:Consolas;color:black'>> information.

iv>

&g= > t; Hence : this draft will/might make DNSSEC validating name servers o:p>

onsolas;color:black'>fail.

rmal>> = >

las;color:black'>> 

ormal>> If you look at = > 4.3.1.1 (Description of DNS Resolver Whitelisting)

iv>

as;color:black'>in

one;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3= > .75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">

lass=3DMsoNormal>> deta= > il,

t-family:Consolas;color:black'>> please observe :

<= > /div>

ack'>> 1) the caching name server (and "stub resolver") ask 2 = > queries

'font-family:Consolas;color:black'>>     (there is o= > nly one line,

yle=3D'font-family:Consolas;color:black'>>     = >  but it are two queries : one for "A", one for "AAAA&qu= > ot;)

nt-family:Consolas;color:black'>> 2) if the caching name server (or stub= > resolver) performs DNSSEC

rmal>> validation,= >

:Consolas;color:black'>>     it will never accept a = > reply of "NODATA" to the query of AAAA

>

>>     (because the NSEC (NSEC3) information will no= > t prove that

le=3D'font-family:Consolas;color:black'>> non-existance) n>

olor:black'>>     ((and the validating name server w= > ill repeat the query to all

ormal>>  &nbs= > p;    authoritative NS's, looking for a validatable answer))= >

amily:Consolas;color:black'>> 

lass=3DMsoNormal>> (the= > final result, to the user might be that only the A record is pan>

;color:black'>useable

= > >  - mission = > accomplished ?

tyle=3D'font-family:Consolas;color:black'>>  But the side effe= > ct will be that validating caching name servers

= >

= > will hit

=3D'font-family:Consolas;color:black'>>   *all* authoritative = > servers for the domain,

l>>   "i= > n search of" a correctly validating answer.)

v>

'>> 

le=3D'font-family:Consolas;color:black'>> So, while for the end-user, th= > e result might be identical,

Normal>> one "secu= > rity impact" of this approach is

ass=3DMsoNormal>> addit= > ional (useless) DNS traffic and

MsoNormal>> additional = > load on authoritative NS's (that implement whitelisting)<= > /p>

r:black'>> 

pan style=3D'font-family:Consolas;color:black'>> = >

or:black'>> Kind regards,

Normal>>  p>

solas;color:black'>> Marc Lampo

=3DMsoNormal>> Security= > Officer

=3D'font-family:Consolas;color:black'>> EURid

>

>> 

e=3D'font-family:Consolas;color:black'>> 

v>

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

=3DMsoNormal>> From: Th= > e IESG [mailto:iesg-secretary@ie= > tf.org]

e=3D'font-family:Consolas;color:black'>> Sent: 01 February 2012 04:09 PM= >

amily:Consolas;color:black'>> To: IETF-Announce

iv>

k'>> Cc: v6ops@ietf.org= >

las;color:black'>> Subject: [v6ops] Last Call:

v>

'>> <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> p>

ly:Consolas;color:black'>> (Considerations for Transitioning Content to = > IPv6) to Informational

>RFC

= >

lack'>> 

style=3D'font-family:Consolas;color:black'>>  >

black'>> The IESG has received a request from the IPv6 Operations WG (v6= > ops)

nt-family:Consolas;color:black'>to

=3DMsoNormal>> consider= > the following document:

al>> - 'Considerations = > for Transitioning Content to IPv6'

=3DMsoNormal>> &nb= > sp; <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> as an= >

amily:Consolas;color:black'>> Informational RFC

iv>

k'>> 

yle=3D'font-family:Consolas;color:black'>> The IESG plans to make a deci= > sion in the next few weeks, and

v>

sol= > icits

ft:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-= > right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">

mal>> final comments on= > this action. Please send substantive comments to

v>

'>the

ont-family:Consolas;color:black'>> ietf= > @ietf.org mailing lists by 2012-02-15. Exceptionally, comments p>

solas;color:black'>may be

mal>> sent to =3D"mailto:iesg@ietf.org">iesg@ietf.org instead. In either case, please= > retain the

e=3D'font-family:Consolas;color:black'>> beginning of the Subject line t= > o allow automated sorting.

rmal>> = >

las;color:black'>> Abstract

soNormal>>  o:p>

onsolas;color:black'>> 

MsoNormal>>  = >   This document describes considerations for the transition of en= > d

family:Consolas;color:black'>user

=3DMsoNormal>> &nb= > sp;  content on the Internet to IPv6.  While this is ta= > ilored to

=3D'font-family:Consolas;color:black'>address

iv>

&g= > t;    end user content, which is typically web-based, m= > any aspects of

tyle=3D'font-family:Consolas;color:black'>this

<= > div>

&= > gt;    document may be more broadly applicable to the t= > ransition to

mal>IPv6= >

padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OU= > TLOOK_ATTRIBUTION_BLOCKQUOTE">

-family:Consolas;color:black'>of

=3DMsoNormal>> &nb= > sp;  other applications and services.  This document ex= > plores the

=3D'font-family:Consolas;color:black'>>    challenge= > s involved in the transition to IPv6, potential

= >

color:black'>migration

er:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-le= > ft:3.75pt;margin-right:0in' id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
= >

>&= > nbsp;   tactics, possible migration phases, and other consid= > erations.

>The

= >
ing:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in' id=3D"MAC_OUTLOO= > K_ATTRIBUTION_BLOCKQUOTE">

ily:Consolas;color:black'>>    audience for this doc= > ument is the Internet community generally,

= >

>&= > nbsp;   particularly IPv6 implementers. >

black'>> 

n style=3D'font-family:Consolas;color:black'>>  p>

:black'>> 

an style=3D'font-family:Consolas;color:black'>> <= > /p>

r:black'>> The file can be obtained via

r:black'>whitelisting-impl

rmal>> ications/ o:p>

onsolas;color:black'>> 

MsoNormal>> IESG discus= > sion can be tracked via

ass=3DMsoNormal>whitelisti= > ng-impl

'font-family:Consolas;color:black'>> ications/

v>

'>> 

le=3D'font-family:Consolas;color:black'>> 

iv>

k'>> No IPR declarations have been submitted directly on this I-D.<= > /o:p>

Consolas;color:black'>> 

=3DMsoNormal>>&nbs= > p;

ly:Consolas;color:black'>> 

s=3DMsoNormal>> _______= > ________________________________________

class=3DMsoNormal>> v6= > ops mailing list

style=3D'font-family:Consolas;color:black'>> tf.org">v6ops@ietf.org

le=3D'font-family:Consolas;color:black'>> 

iv>

k'> 

=3D'font-family:Consolas;color:black'>_____________________________________= > __________

=3D'font-family:Consolas;color:black'>v6ops mailing list<= > /p>

r:black'>v6ops@ietf.org pan>

ckquote>

:black'>_______________________________________________ p>

:black'>v6ops mailing list

le=3D'font-family:Consolas;color:black'> 

<= > div>

_= > ______________________________________________ v6ops mailing list >

al>  >

= > > --_000_13205C286662DE4387D9AF3AC30EF456D7674BFE2DEMBX01WFjnprn_-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ted.Lemon@nominum.com Thu Feb 23 13:08:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F6121F88A9 for ; Thu, 23 Feb 2012 13:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.521 X-Spam-Level: X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxSQdvrvbkxt for ; Thu, 23 Feb 2012 13:08:04 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id DCFBE21F87A1 for ; Thu, 23 Feb 2012 13:07:56 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT0aqq2pHRYm8aTpYTSRTdN0dFcil3Mn5@postini.com; Thu, 23 Feb 2012 13:07:56 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8A7E11B83BE for ; Thu, 23 Feb 2012 13:07:55 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7AAAA19005C; Thu, 23 Feb 2012 13:07:55 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Thu, 23 Feb 2012 13:07:55 -0800 From: Ted Lemon To: Ralph Droms Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAixh6AAAuAUgAAAGCPAAACJwsAAAMskIAAANWIAAAAtOcAAAMVnYAAHICAgAAK2K+AAAEQ/YAAAELCgAAAnOkAAA3MLAA= Date: Thu, 23 Feb 2012 21:07:54 +0000 Message-ID: <3D40B569-062C-43DE-A059-69976FFFF7CB@nominum.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_3D40B569062C43DEA05969976FFFF7CBnominumcom_" MIME-Version: 1.0 Cc: "draft-ietf-v6ops-6204bis@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 21:08:05 -0000 --_000_3D40B569062C43DEA05969976FFFF7CBnominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Feb 23, 2012, at 9:32 AM, Ralph Droms > wrote: * ULA prefix with GUA advertised only when WAN connectivity is operable. W= hat happens when the availability of the GUA flaps? Do hosts operate as ex= pected and continue to communicate with other hosts using the ULA prefixes?= Are any problems attributable to implementation issues or are there proto= col problems? Linux and OSX both seem to support this correctly, at least according to th= e brief test I just did. Both operating systems use the ULA source addres= s when attempting to communicate with a destination address that uses the s= ame prefix. I don't have a windows box here to test it on, but I don't se= e any reason to think they get it wrong. One slight concern about the Linux implementation is that the ULA is marked= as global in ifconfig; I don't know whether this is a kernel bug or an ifc= onfig bug, and I've only tried it on Ubuntu Meerkat, so I don't have a broa= d sample to work from. --_000_3D40B569062C43DEA05969976FFFF7CBnominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4DBEED8695D4A4439CE14A4113807862@nominum.com> Content-Transfer-Encoding: quoted-printable
On Feb 23, 2012, at 9:32 AM, Ralph Droms <rdroms@cisco.com>
 wrote:
* ULA prefix with GUA advertised only when WAN connectivity is operable. &nb= sp;What happens when the availability of the GUA flaps?  Do hosts oper= ate as expected and continue to communicate with other hosts using the ULA = prefixes?  Are any problems attributable to implementation issues or are there protocol problems?

Linux and OSX both seem to support this correctly, at least according = to the brief test I just did.   Both operating systems use the ULA sou= rce address when attempting to communicate with a destination address that = uses the same prefix.   I don't have a windows box here to test it on, but I don't see any reason to think they= get it wrong.

One slight concern about the Linux implementation is that the ULA is m= arked as global in ifconfig; I don't know whether this is a kernel bug or a= n ifconfig bug, and I've only tried it on Ubuntu Meerkat, so I don't have a= broad sample to work from.

--_000_3D40B569062C43DEA05969976FFFF7CBnominumcom_-- From brian.e.carpenter@gmail.com Thu Feb 23 13:22:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC8321F84DA for ; Thu, 23 Feb 2012 13:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.507 X-Spam-Level: X-Spam-Status: No, score=-103.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnEk6wwIsgtO for ; Thu, 23 Feb 2012 13:22:07 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6182B21F8899 for ; Thu, 23 Feb 2012 13:22:05 -0800 (PST) Received: by eekc41 with SMTP id c41so672045eek.31 for ; Thu, 23 Feb 2012 13:22:05 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.213.2.73 as permitted sender) client-ip=10.213.2.73; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.213.2.73 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.213.2.73]) by 10.213.2.73 with SMTP id 9mr4982ebi.92.1330032125413 (num_hops = 1); Thu, 23 Feb 2012 13:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qNvddQU0KFSazgscsolmIyuaLvfnSNLFTOFv3s6pzmk=; b=xm4NlnTm/s6SNDRtn2rpZQ1wuZSWqFHfEdvAgXK6Wdn4u0y/tlkmmKivZLtLyTsduC mgPrmOvSK7PNni/hGO0T0c7Kdxju3KJsGoXXDvMbbG6KiV+H9jDheF7/ousdiVzh9fI4 naPBoT+JwqJiM0xkOQRqPs/09YfGw+ElUPZdQ= Received: by 10.213.2.73 with SMTP id 9mr3351ebi.92.1330032125244; Thu, 23 Feb 2012 13:22:05 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n17sm9743747eei.3.2012.02.23.13.22.01 (version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 13:22:04 -0800 (PST) Message-ID: <4F46ADF4.6000500@gmail.com> Date: Fri, 24 Feb 2012 10:21:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> <3D40B569-062C-43DE-A059-69976FFFF7CB@nominum.com> In-Reply-To: <3D40B569-062C-43DE-A059-69976FFFF7CB@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 21:22:08 -0000 On 2012-02-24 10:07, Ted Lemon wrote: ... > One slight concern about the Linux implementation is that the ULA is marked as global in ifconfig; I don't know whether this is a kernel bug or an ifconfig bug, and I've only tried it on Ubuntu Meerkat, so I don't have a broad sample to work from. What bug? ULAs are *defined* as global. Brian From marka@isc.org Thu Feb 23 13:35:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FA521F881E for ; Thu, 23 Feb 2012 13:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VffXOnBPYIX for ; Thu, 23 Feb 2012 13:35:04 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id BD17B21F87FC for ; Thu, 23 Feb 2012 13:35:04 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 6C5DB5F9891; Thu, 23 Feb 2012 21:34:51 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:968:e107:e473:6b83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5216F216C33; Thu, 23 Feb 2012 21:34:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B441E1DC3938; Fri, 24 Feb 2012 08:34:40 +1100 (EST) To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= From: Mark Andrews References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> In-reply-to: Your message of "Thu, 23 Feb 2012 16:24:17 BST." Date: Fri, 24 Feb 2012 08:34:40 +1100 Message-Id: <20120223213440.B441E1DC3938@drugs.dv.isc.org> Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 21:35:05 -0000 I've been using ULA + GUA for a couple of years now. It works with FreeBSD, Mac OS 10.[67], Windows XP and Windows Vista. My machines are using a HE's whitelisted resolvers so I get Googles AAAA records as well as work's AAAA records. The border router is configured to send ICMPv6 messages if a ULA source address is used on a outbound packet. The longest match rule, fortuitously, works to select the correct source address (F != 2). The default address selection rules do need to be made aware of ULA address and to prefer ULA/48 over GUA over ULA/7. ULA address *will* leak and the default address selection rules need to handle such leakages. With properly configured address selection rules the internal comunication mostly uses ULA addresses. We do need a mechanism so that CPE connected to a ISP can be made aware that the upstream interface is *not* part of site. A DHCP / RA option, annouced by the ISP, would do this nicely perhaps with a AS number or other unique identifier so that multiple upstream from the same ISP can be identified. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ted.Lemon@nominum.com Thu Feb 23 13:43:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8947321F888B for ; Thu, 23 Feb 2012 13:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwtzZqVfpCX0 for ; Thu, 23 Feb 2012 13:43:37 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 73FF321F87AA for ; Thu, 23 Feb 2012 13:43:37 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKT0azCK9+GjE8x7tSf6N/uDZa9wtLvPNT@postini.com; Thu, 23 Feb 2012 13:43:37 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2ADC11B83BF for ; Thu, 23 Feb 2012 13:43:36 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1D8D119005C; Thu, 23 Feb 2012 13:43:36 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 23 Feb 2012 13:43:36 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAixh6AAAuAUgAAAGCPAAACJwsAAAMskIAAANWIAAAAtOcAAAMVnYAAHICAgAAK2K+AAAEQ/YAAAELCgAAAnOkAAA3MLAAAAH13AAAAwWsA Date: Thu, 23 Feb 2012 21:43:35 +0000 Message-ID: References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> <3D40B569-062C-43DE-A059-69976FFFF7CB@nominum.com> <4F46ADF4.6000500@gmail.com> In-Reply-To: <4F46ADF4.6000500@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_DB0E8603A1764D75BE6E2BBD6D396C2Fnominumcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 21:43:38 -0000 --_000_DB0E8603A1764D75BE6E2BBD6D396C2Fnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 23, 2012, at 4:21 PM, Brian E Carpenter > wrote: What bug? ULAs are *defined* as global. Heh, I suppose you're right. Globally unique, despite not being globally = routed. --_000_DB0E8603A1764D75BE6E2BBD6D396C2Fnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <69D963AA6A14EF42907A63DAF9535FA1@nominum.com> Content-Transfer-Encoding: quoted-printable
On Feb 23, 2012, at 4:21 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
W= hat bug? ULAs are *defined* as global.

Heh, I suppose you're right.   Globally unique, despite not being= globally routed.

--_000_DB0E8603A1764D75BE6E2BBD6D396C2Fnominumcom_-- From jhw@apple.com Thu Feb 23 16:16:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E647821F887C for ; Thu, 23 Feb 2012 16:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.201 X-Spam-Level: X-Spam-Status: No, score=-110.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75CSeGa4ALZ5 for ; Thu, 23 Feb 2012 16:16:02 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 42BD921F87BE for ; Thu, 23 Feb 2012 16:16:01 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0LZV00F7NFDBF4Y1@mail-out.apple.com> for v6ops@ietf.org; Thu, 23 Feb 2012 16:15:50 -0800 (PST) X-AuditID: 1180711d-b7b88ae00000602c-5e-4f46d6b5deed Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 4C.ED.24620.6B6D64F4; Thu, 23 Feb 2012 16:15:50 -0800 (PST) From: james woodyatt In-reply-to: Date: Thu, 23 Feb 2012 16:15:49 -0800 Message-id: References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> <3D40B569-062C-43DE-A059-69976FFFF7CB@nominum.com> <4F46ADF4.6000500@gmail.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1427) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUieJDXQXfbNTd/g1ctrBY3r15ksTh9bC+z A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJXR9+g7c0E3W8XkW79ZGhjfs3QxcnJICJhI zL/0mB3CFpO4cG89WxcjF4eQwGwmieMdJxhBEswCWhI3/r1kArF5BfQkbl/8BxYXFjCUWPt9 CVgzm4CKxLfLd8FqOAXsJWatmc0MYrMIqEp8bN3NCjFHW+LDviYmGHvZwtfMEDNtJD48eMQO sfgBi8T5vulgQ0UEhCR2PANp4AC6Tlbi7Hv5CYz8s5CcNAvJSbOQjF3AyLyKUbAoNSex0tBY L7GgICdVLzk/dxMjKOwaCmV3MO7/yX+IUYCDUYmH92Ksm78Qa2JZcWXuIUYJDmYlEV6zxUAh 3pTEyqrUovz4otKc1OJDjNIcLErivB/yXP2FBNITS1KzU1MLUotgskwcnFINjLP4P35S3V/a FBZ6pEwlVi5u2yOzs9ueal2UmOlxctLSSXsnXTc7Ee5R0VCwrsRh0quN0mvqpitXrX1Zwf4/ tFE/p9l77hrbGXoWt+5817sqIu4bfpqpwzU9me+vgU3PrjpBwaYze10PbJjHXtCX77TDqrJf v7NBZYuU5GUO/Y5Dt2f3duw7qsRSnJFoqMVcVJwIAMYNiIM3AgAA Cc: draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 00:16:03 -0000 On Feb 23, 2012, at 13:43 , Ted Lemon wrote: > > Heh, I suppose you're right. Globally unique, despite not being globally routed. I wish people would remember that even this isn't true. The ULA addresses are globally unique and are globally routable by private bilateral agreement. The prohibition in the specification is only against routing them in the public Internet default free zone. Think of it as IETF saying to the global public Internet transit operators: "All these unicast address prefixes are yours except fc00::/7; attempt no advertisements there." I hope I don't need to explain the importance of this point. -- james woodyatt member of technical staff, core os networking From Ted.Lemon@nominum.com Thu Feb 23 18:25:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5124111E80AA for ; Thu, 23 Feb 2012 18:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.525 X-Spam-Level: X-Spam-Status: No, score=-106.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEazkTmRFs3X for ; Thu, 23 Feb 2012 18:25:43 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9054011E809A for ; Thu, 23 Feb 2012 18:25:41 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT0b1JeZxmxk0OOFEPbJ0uchE1BKSaGlY@postini.com; Thu, 23 Feb 2012 18:25:41 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 673691B83BD for ; Thu, 23 Feb 2012 18:25:40 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5D5E419005C; Thu, 23 Feb 2012 18:25:40 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 23 Feb 2012 18:25:40 -0800 From: Ted Lemon To: james woodyatt Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczw84ECxzzuwPVYQ0aM/GWBoA4FXQAixh6AAAuAUgAAAGCPAAACJwsAAAMskIAAANWIAAAAtOcAAAMVnYAAHICAgAAK2K+AAAEQ/YAAAELCgAAAnOkAAA3MLAAAAH13AAAAwWsAAAVROYAABIjNgA== Date: Fri, 24 Feb 2012 02:25:40 +0000 Message-ID: <87243FF4-B2ED-4590-96DB-353226672DFF@nominum.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> <3D40B569-062C-43DE-A059-69976FFFF7CB@nominum.com> <4F46ADF4.6000500@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_87243FF4B2ED459096DB353226672DFFnominumcom_" MIME-Version: 1.0 Cc: "" , "" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 02:25:44 -0000 --_000_87243FF4B2ED459096DB353226672DFFnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 23, 2012, at 7:15 PM, james woodyatt > wrote: globally routable by private bilateral agreement That's not what "globally" means, or at least not what I mean when I say it= . Globally means reachable from anywhere on the globe. If a private bil= ateral agreement is required to reach the ULA, it's not globally reachable. I hope I don't need to explain the importance of this point. The Star Child will destroy the earth if we disobey? Seriously, if your point is that these addresses have to be globally unique= , we already covered that. If your point is that they *could* wind up bei= ng routed to anywhere, I think we covered that. If you have some addition= al point to make, I'm curious what it is, although no doubt everybody else = is holding their fingers in their ears by this point and yelling "shut up s= hut up shut up!!!" :) --_000_87243FF4B2ED459096DB353226672DFFnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Feb 23, 2012, at 7:15 PM, james woodyatt <jhw@apple.com> wrote:
g= lobally routable by private bilateral agreement

That's not what "globally" means, or at least not what I mea= n when I say it.   Globally means reachable from anywhere on the globe= .   If a private bilateral agreement is required to reach the ULA, it'= s not globally reachable.

I hope I don't need to explain the importance of = this point.

The Star Child will destroy the earth if we disobey?

Seriously, if your point is that these addresses have to be globally u= nique, we already covered that.   If your point is that they *could* w= ind up being routed to anywhere, I think we covered that.   If you hav= e some additional point to make, I'm curious what it is, although no doubt everybody else is holding their fingers in t= heir ears by this point and yelling "shut up shut up shut up!!!"<= /div>

:)

--_000_87243FF4B2ED459096DB353226672DFFnominumcom_-- From joelja@bogus.com Thu Feb 23 23:33:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0219A21E8028 for ; Thu, 23 Feb 2012 23:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.326 X-Spam-Level: X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpBaOVzCp9zu for ; Thu, 23 Feb 2012 23:33:56 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 88B3C21E800C for ; Thu, 23 Feb 2012 23:33:56 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q1O7Xt2s078325 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 24 Feb 2012 07:33:55 GMT (envelope-from joelja@bogus.com) Message-ID: <4F473D62.3010408@bogus.com> Date: Thu, 23 Feb 2012 23:33:54 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: IPv6 Ops WG References: <20120223195555.29640.48519.idtracker@ietfa.amsl.com> In-Reply-To: <20120223195555.29640.48519.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120223195555.29640.48519.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 24 Feb 2012 07:33:56 +0000 (UTC) Subject: [v6ops] FYI Fwd: v6ops - Requested sessions have been scheduled for IETF 83 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 07:33:57 -0000 The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the original request. v6ops Session 1 (2.5 hours) Monday, Morning Session I 0930-1130 Room Name: Maillot --------------------------------------------- v6ops Session 2 (2 hours) Thursday, Afternoon Session II 1520-1720 Room Name: Maillot --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Wanda Lo Number of Sessions: 2 Length of Session(s): 2.5 hours, 2 hours Number of Attendees: 300 Conflicts to Avoid: First Priority: 6man opsawg behave softwire homenet Second Priority: 6lowpan 6renum Third Priority: opsarea Special Requests: --------------------------------------------------------- From despres.remi@laposte.net Fri Feb 24 00:48:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B4121F87BF for ; Fri, 24 Feb 2012 00:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.585 X-Spam-Level: X-Spam-Status: No, score=-1.585 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0065toFT4qvw for ; Fri, 24 Feb 2012 00:48:11 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id E980821F87BE for ; Fri, 24 Feb 2012 00:48:10 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2207.sfr.fr (SMTP Server) with ESMTP id 52A0370000DA; Fri, 24 Feb 2012 09:48:09 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2207.sfr.fr (SMTP Server) with ESMTP id 0174570000D4; Fri, 24 Feb 2012 09:48:05 +0100 (CET) X-SFR-UUID: 20120224084806606.0174570000D4@msfrf2207.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120223213440.B441E1DC3938@drugs.dv.isc.org> Date: Fri, 24 Feb 2012 09:48:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> <20120223213440.B441E1DC3938@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 08:48:11 -0000 Hello Mark, Thanks for this information. More in line. Le 2012-02-23 =E0 22:34, Mark Andrews a =E9crit : >=20 > I've been using ULA + GUA for a couple of years now. It works with > FreeBSD, Mac OS 10.[67], Windows XP and Windows Vista. You are clearly a more sophisticated user of these OSes than I am. With Mac OS 10.6.8, I just enabled IPv6 with automatic address = configuration. The fact that my displayed "IPv6 address" is singular doesn't prove, I = must admit, that the OS wouldn't handle a ULA if provided a ULA prefix.. To check it, I would have needed a network where RAs announce GUA+ULA, = which isn't the case.=20 =20 > My machines > are using a HE's whitelisted resolvers so I get Googles AAAA records > as well as work's AAAA records. The border router is configured to > send ICMPv6 messages if a ULA source address is used on a outbound > packet. >=20 > The longest match rule, fortuitously, works to select the correct > source address (F !=3D 2). The default address selection rules do > need to be made aware of ULA address and to prefer ULA/48 over GUA > over ULA/7. ULA address *will* leak and the default address selection > rules need to handle such leakages. With properly configured address > selection rules the internal comunication mostly uses ULA addresses. Is this configuration available by default in common OSes, or is it = something you had to configure or some of them (in which case which = ones)? > We do need a mechanism so that CPE connected to a ISP can be made > aware that the upstream interface is *not* part of site. Well, that could be nice to have, but, I see no important difference = between unreachability due to a local WAN link and unreachability due to = a remote link). IMHO, we can live without such a mechanism, and therefore don't need = that ULAs indirectly provide this information. The idea that, thanks to IPv6, each interface can again have a universal = address, and can this address can be used to communicate with all other = hosts seems to me the kind of simple idea that shouldn't be abandoned = for ordinary users.=20 Regards, RD > A DHCP / > RA option, annouced by the ISP, would do this nicely perhaps with > a AS number or other unique identifier so that multiple upstream > from the same ISP can be identified. >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rdroms@cisco.com Fri Feb 24 01:50:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEFC21F876A for ; Fri, 24 Feb 2012 01:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEzHJOrskMKw for ; Fri, 24 Feb 2012 01:50:16 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 04EE621F875E for ; Fri, 24 Feb 2012 01:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=1427; q=dns/txt; s=iport; t=1330077016; x=1331286616; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=YS4DqFbsk5Ga3qvcaiyisDtygeNcom0gMKmZWLlby0o=; b=KxngjG7T0ZukSKSNM+cfp04rnIGalY5BdjPKMDwtRPMNFQZB8nEzepsG swcPmp6TjNH5FT8RYJt+fYbejOl/wwcDEZBavlfVSflQGr77nDzGKTDcC IKd9fTfz7rWSO6nw+gP6thkhzSA0aIE4xQqxjycXtVnoMBjs2zyVCL9pq U=; X-IronPort-AV: E=Sophos;i="4.73,475,1325462400"; d="scan'208";a="61502373" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 24 Feb 2012 09:50:15 +0000 Received: from [10.86.245.179] ([10.86.245.179]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1O9oEXB017608; Fri, 24 Feb 2012 09:50:14 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Ralph Droms In-Reply-To: <3D40B569-062C-43DE-A059-69976FFFF7CB@nominum.com> Date: Fri, 24 Feb 2012 09:50:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> <3D40B569-062C-43DE-A059-69976FFFF7CB@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1251.1) Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 09:50:17 -0000 On Feb 23, 2012, at 9:07 PM 2/23/12, Ted Lemon wrote: > On Feb 23, 2012, at 9:32 AM, Ralph Droms > wrote: >> * ULA prefix with GUA advertised only when WAN connectivity is = operable. What happens when the availability of the GUA flaps? Do = hosts operate as expected and continue to communicate with other hosts = using the ULA prefixes? Are any problems attributable to implementation = issues or are there protocol problems? >=20 > Linux and OSX both seem to support this correctly, at least according = to the brief test I just did. Both operating systems use the ULA = source address when attempting to communicate with a destination address = that uses the same prefix. I don't have a windows box here to test it = on, but I don't see any reason to think they get it wrong. Excellent. So, presumably, if the GUA prefix is withdrawn (advertised = with lifetimes of 0?) from the RAs, Linux and OS X will continue to = communicate with other hosts using the same ULA. Did you happen to = actually try the experiment? Anyone have experience with dedicated devices like a webcam, printer, = NAS? - Ralph > One slight concern about the Linux implementation is that the ULA is = marked as global in ifconfig; I don't know whether this is a kernel bug = or an ifconfig bug, and I've only tried it on Ubuntu Meerkat, so I don't = have a broad sample to work from. From HahnC@t-systems.com Fri Feb 24 02:09:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA28221F85BD for ; Fri, 24 Feb 2012 02:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2pFzDc97-hs for ; Fri, 24 Feb 2012 02:09:41 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 970C221F85B1 for ; Fri, 24 Feb 2012 02:09:40 -0800 (PST) From: HahnC@t-systems.com Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 24 Feb 2012 11:06:53 +0100 Received: from HE101453.emea1.cds.t-internal.com ([169.254.3.95]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Fri, 24 Feb 2012 11:06:52 +0100 To: , Date: Fri, 24 Feb 2012 11:06:51 +0100 Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczy2cLQoZaanFATTvym/aa7aLcYRwAAMPSA Message-ID: <901586CA8F92D543BFFFD6E1122F5A3602733EFD0C97@HE101453.emea1.cds.t-internal.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> <3D40B569-062C-43DE-A059-69976FFFF7CB@nominum.com> In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 10:09:42 -0000 Hi folks, >-----Original Message----- >On Feb 23, 2012, at 9:07 PM 2/23/12, Ted Lemon wrote: > >> On Feb 23, 2012, at 9:32 AM, Ralph Droms >> wrote: >>> * ULA prefix with GUA advertised only when WAN connectivity=20 >is operable. What happens when the availability of the GUA=20 >flaps? Do hosts operate as expected and continue to=20 >communicate with other hosts using the ULA prefixes? Are any=20 >problems attributable to implementation issues or are there=20 >protocol problems? >>=20 >> Linux and OSX both seem to support this correctly, at least=20 >according to the brief test I just did. Both operating=20 >systems use the ULA source address when attempting to=20 >communicate with a destination address that uses the same=20 >prefix. I don't have a windows box here to test it on, but I=20 >don't see any reason to think they get it wrong. > >Excellent. So, presumably, if the GUA prefix is withdrawn=20 >(advertised with lifetimes of 0?) from the RAs, Linux and OS X=20 >will continue to communicate with other hosts using the same=20 >ULA. Did you happen to actually try the experiment? I run a similar setup at home for over one year now. In addtition to that w= e also use Windows XP and 7 machines. I can only say that I saw the above d= escribed behaviour when I looked closly at it. During normal operation we h= ad no major impact by using ULAs at home. Local network communication (I ha= ve localy delivered web and mail), if it uses IPv6, utilizes ULA. If the GU= A disappears (which was the case 2 or 3 times) local communcation continues= to run stable. > >Anyone have experience with dedicated devices like a webcam,=20 >printer, NAS? Unfortunatley, I don't have such devices with IPv6 support. cheers, Christian Hahn ---------------------------------- T-Systems International GmbH Supervisory Board: Ren=E9 Obermann (Chairman) Board of Management: Reinhard Clemens (Chairman), Dr. Ferri Abolhassan, Ola= f Heyden, Joachim Langmack, Georg Pepping, Klaus Werner Commercial register: Amtsgericht Frankfurt am Main HRB 55933 Registered office: Frankfurt am Main WEEE-Reg.-No. DE87523644 > >- Ralph > >> One slight concern about the Linux implementation is that=20 >the ULA is marked as global in ifconfig; I don't know whether=20 >this is a kernel bug or an ifconfig bug, and I've only tried=20 >it on Ubuntu Meerkat, so I don't have a broad sample to work from. > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops >= From lorenzo@google.com Fri Feb 24 02:31:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AA321F891A for ; Fri, 24 Feb 2012 02:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.692 X-Spam-Level: X-Spam-Status: No, score=-102.692 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBIbHtMLEXx0 for ; Fri, 24 Feb 2012 02:31:16 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AAEC321F86EE for ; Fri, 24 Feb 2012 02:31:10 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3067609obb.31 for ; Fri, 24 Feb 2012 02:31:10 -0800 (PST) Received-SPF: pass (google.com: domain of lorenzo@google.com designates 10.182.8.69 as permitted sender) client-ip=10.182.8.69; Authentication-Results: mr.google.com; spf=pass (google.com: domain of lorenzo@google.com designates 10.182.8.69 as permitted sender) smtp.mail=lorenzo@google.com; dkim=pass header.i=lorenzo@google.com Received: from mr.google.com ([10.182.8.69]) by 10.182.8.69 with SMTP id p5mr674277oba.28.1330079470365 (num_hops = 1); Fri, 24 Feb 2012 02:31:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=sguNSwuzr1nwm+2BbY+C0JhNTDXrW34o+YVIdQ1qa38=; b=pIVf5azBU3rY3zDb/QfgDRHVUuB73gDIKt33FH08quZUu9lviJw70naTY1rxZrADac HzqJkzrBVzAngBkNeJ1I/GGVL7lSVilT/psbFRmMcSuHXoDuHMcLDRcLKDmxB+fkA4s7 IPr7uEZZYiwdnKcaAOFH57/RqQoOLUCIqL1DY= Received: by 10.182.8.69 with SMTP id p5mr587126oba.28.1330079470321; Fri, 24 Feb 2012 02:31:10 -0800 (PST) Received: by 10.182.8.69 with SMTP id p5mr587119oba.28.1330079470174; Fri, 24 Feb 2012 02:31:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.5.67 with HTTP; Fri, 24 Feb 2012 02:30:50 -0800 (PST) In-Reply-To: <20120215104232kawashimam@mail.jp.nec.com> References: <20120215011928.4651.7195.idtracker@ietfa.amsl.com> <20120215104232kawashimam@mail.jp.nec.com> From: Lorenzo Colitti Date: Fri, 24 Feb 2012 19:30:50 +0900 Message-ID: To: Masanobu Kawashima Content-Type: multipart/alternative; boundary=f46d0444ec4b57c3f004b9b342ea X-System-Of-Record: true X-Gm-Message-State: ALoCoQk6hz6rvToQKd7qFp1srqeeIJoV37hLXkB+YwHMdgAEb4W1GeaCRq+W435p+A8xuz4fr+G4Q1SWk0WtX+H8zFeZ2ZREoQcJfMnlyt38TPwPeie+kHoPNbGoFbwFUzBm9Ftmc1Ce Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 10:31:17 -0000 --f46d0444ec4b57c3f004b9b342ea Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 15, 2012 at 10:42, Masanobu Kawashima wrote: > We have published draft-ietf-v6ops-464xlat-00 as WG draft. > We welcome all your comments. > I like this, because it makes it relatively easy to provide legacy IPv4 connectivity on a device that has IPv6-only connectivity. It's a particularly good fit for 3GPP devices like mobile phones because it's relatively simple, can be implemented entirely in userspace, and requires no provisioning that isn't already provided by 3GPP (a /64 and a DNS server). And it's just a combination of existing standards. By comparison, I think solutions like 4rd require a more complex device implementation, need the kernel to pick ports in a way that will be understood by the translator, and require provisioning as to what mapping algorithm and port ranges to use. I can see why you would use something like 4rd in a wireline CPE, but on something like a smartphone, which is already behind an IPv4 NAT today and most applications already support IPv6, the IPv4 connectivity is only really used for a few apps anyway. I have one question, though: why does the CLAT require a /96? Wouldn't it be simpler if it uses just one /128 and performed NAT44 for clients behind it? That way, if the CLAT have one /64 like in the 3GPP case, you don't have to worry about DAD and NDP proxying. --f46d0444ec4b57c3f004b9b342ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 15, 2012 at 10:42, Masanobu Kawashim= a <kawashi= mam@vx.jp.nec.com> wrote:
We have published draft-ietf-v6ops-464xlat-00 as WG draft.
We welcome all your comments.

I like th= is, because it makes it relatively easy to provide legacy IPv4 connectivity= on a device that has IPv6-only connectivity.

It's a particularly good fit for 3GPP devices like mobile phones becaus= e it's relatively simple, can be implemented entirely in userspace, and= requires no provisioning that isn't already provided by 3GPP (a /64 an= d a DNS server). And it's just a combination of existing standards.

By comparison, I think solutions like 4rd require a mor= e complex device implementation, need the kernel to pick ports in a way tha= t will be understood by the translator, and require provisioning as to what= mapping algorithm and port ranges to use. I can see why you would use some= thing like 4rd in a wireline CPE, but on something like=A0a smartphone, whi= ch is already behind an IPv4 NAT today and most applications already suppor= t IPv6, the IPv4 connectivity is only really used for a few apps anyway.

I have one question, though: why does the CLAT require = a /96? Wouldn't it be simpler if it uses just one /128 and performed NA= T44 for clients behind it?

That way, if the CLAT h= ave one /64 like in the 3GPP case, you don't have to worry about DAD an= d NDP proxying.
--f46d0444ec4b57c3f004b9b342ea-- From cb.list6@gmail.com Fri Feb 24 03:01:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB7E21F87B3 for ; Fri, 24 Feb 2012 03:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmGvM4OS8uqc for ; Fri, 24 Feb 2012 03:01:29 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C86D421F8746 for ; Fri, 24 Feb 2012 03:01:17 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2596821pbc.31 for ; Fri, 24 Feb 2012 03:01:17 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.129.130 as permitted sender) client-ip=10.68.129.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.129.130 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.129.130]) by 10.68.129.130 with SMTP id nw2mr6252168pbb.8.1330081277660 (num_hops = 1); Fri, 24 Feb 2012 03:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=clakMlCl6GK2YD3j165mBCxT758ftsErjLWoo12Z3BQ=; b=VmQFDQqx7j0x+0CTlHV8Tmi9WGl9KM5+735bIroKQb3ye9eR2pZxyL92MK+ejAwywm YBYM1gYy+H/zocNntQsHxE45diiCSCXnz9nfEiqhOF9dWU75LevCi2k5GmviIf2k9GaE 3xLGMvxGltRSdIoy3JfiPRlVWCZ4wbd8P+l50= MIME-Version: 1.0 Received: by 10.68.129.130 with SMTP id nw2mr5189240pbb.8.1330081277552; Fri, 24 Feb 2012 03:01:17 -0800 (PST) Received: by 10.142.99.12 with HTTP; Fri, 24 Feb 2012 03:01:17 -0800 (PST) Received: by 10.142.99.12 with HTTP; Fri, 24 Feb 2012 03:01:17 -0800 (PST) In-Reply-To: References: <20120215011928.4651.7195.idtracker@ietfa.amsl.com> <20120215104232kawashimam@mail.jp.nec.com> Date: Fri, 24 Feb 2012 03:01:17 -0800 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=047d7b10ccb512278904b9b3aeb9 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 11:01:31 -0000 --047d7b10ccb512278904b9b3aeb9 Content-Type: text/plain; charset=ISO-8859-1 On Feb 24, 2012 2:31 AM, "Lorenzo Colitti" wrote: > > On Wed, Feb 15, 2012 at 10:42, Masanobu Kawashima < kawashimam@vx.jp.nec.com> wrote: >> >> We have published draft-ietf-v6ops-464xlat-00 as WG draft. >> We welcome all your comments. > > > I like this, because it makes it relatively easy to provide legacy IPv4 connectivity on a device that has IPv6-only connectivity. > > It's a particularly good fit for 3GPP devices like mobile phones because it's relatively simple, can be implemented entirely in userspace, and requires no provisioning that isn't already provided by 3GPP (a /64 and a DNS server). And it's just a combination of existing standards. > > By comparison, I think solutions like 4rd require a more complex device implementation, need the kernel to pick ports in a way that will be understood by the translator, and require provisioning as to what mapping algorithm and port ranges to use. I can see why you would use something like 4rd in a wireline CPE, but on something like a smartphone, which is already behind an IPv4 NAT today and most applications already support IPv6, the IPv4 connectivity is only really used for a few apps anyway. > > I have one question, though: why does the CLAT require a /96? Wouldn't it be simpler if it uses just one /128 and performed NAT44 for clients behind it? > > That way, if the CLAT have one /64 like in the 3GPP case, you don't have to worry about DAD and NDP proxying. > Remi and Washam have brought up similar concerns regarding NDP. Our thinking was that the /96 allows the CPE to remain stateless. If the benefits of being stateless at the cpe are not seen as truly meaningful in all cases, would it be acceptable to the group to offer implementation options of doing DAD/NDP, proxy NDP, or nat446? I think the overall scope of the draft is best served by outlining the structure of how the architecture works and allowing implementation to make the appropriate solution selection. Thoughts? Cb > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b10ccb512278904b9b3aeb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 24, 2012 2:31 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Wed, Feb 15, 2012 at 10:42, Masanobu Kawashima <kawashimam@vx.jp.nec.com> wrote:
>>
>> We have published draft-ietf-v6ops-464xlat-00 as WG draft.
>> We welcome all your comments.
>
>
> I like this, because it makes it relatively easy to provide legacy IPv= 4 connectivity on a device that has IPv6-only connectivity.
>
> It's a particularly good fit for 3GPP devices like mobile phones b= ecause it's relatively simple, can be implemented entirely in userspace= , and requires no provisioning that isn't already provided by 3GPP (a /= 64 and a DNS server). And it's just a combination of existing standards= .
>
> By comparison, I think solutions like 4rd require a more complex devic= e implementation, need the kernel to pick ports in a way that will be under= stood by the translator, and require provisioning as to what mapping algori= thm and port ranges to use. I can see why you would use something like 4rd = in a wireline CPE, but on something like=A0a smartphone, which is already b= ehind an IPv4 NAT today and most applications already support IPv6, the IPv= 4 connectivity is only really used for a few apps anyway.
>
> I have one question, though: why does the CLAT require a /96? Wouldn&#= 39;t it be simpler if it uses just one /128 and performed NAT44 for clients= behind it?
>
> That way, if the CLAT have one /64 like in the 3GPP case, you don'= t have to worry about DAD and NDP proxying.
>

Remi and Washam have brought up similar concerns regarding NDP.=A0 Our t= hinking was that the /96 allows the CPE to remain stateless.=A0

If the benefits of being stateless at the cpe are not seen as truly mean= ingful in all cases, would it be acceptable to the group to offer implement= ation options of doing DAD/NDP, proxy NDP, or nat446?

I think=A0 the overall scope of the draft is best served by outlining th= e structure of how the architecture works and allowing implementation to ma= ke the appropriate solution selection.

Thoughts?

Cb

> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--047d7b10ccb512278904b9b3aeb9-- From lorenzo@google.com Fri Feb 24 03:33:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A4321F8958 for ; Fri, 24 Feb 2012 03:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.72 X-Spam-Level: X-Spam-Status: No, score=-102.72 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cg0CjM9saF9a for ; Fri, 24 Feb 2012 03:33:31 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF5B421F8953 for ; Fri, 24 Feb 2012 03:33:31 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3151187obb.31 for ; Fri, 24 Feb 2012 03:33:31 -0800 (PST) Received-SPF: pass (google.com: domain of lorenzo@google.com designates 10.182.216.41 as permitted sender) client-ip=10.182.216.41; Authentication-Results: mr.google.com; spf=pass (google.com: domain of lorenzo@google.com designates 10.182.216.41 as permitted sender) smtp.mail=lorenzo@google.com; dkim=pass header.i=lorenzo@google.com Received: from mr.google.com ([10.182.216.41]) by 10.182.216.41 with SMTP id on9mr762884obc.18.1330083211457 (num_hops = 1); Fri, 24 Feb 2012 03:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=3H6g7snE840ii9yHMrfV6dpWjiIYHvxUelqMxP+CE6c=; b=w2ezUuAnpxFOl9X0NdNP+ExCNQWoKnEzH6JZuu/hoPWZtkNqTRJU45Mdhm7HNHFk8i T4ajWsbuSmSGCBGpw0j+5smESCdoW0tpu7NSAmbHYV++tdqPzVWvZ32v4kCEMI5m25Xa ez1sfb/l8WCRnXLEZBYfzxShXvq/eO7qsdVHs= Received: by 10.182.216.41 with SMTP id on9mr661249obc.18.1330083211381; Fri, 24 Feb 2012 03:33:31 -0800 (PST) Received: by 10.182.216.41 with SMTP id on9mr661242obc.18.1330083211203; Fri, 24 Feb 2012 03:33:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.5.67 with HTTP; Fri, 24 Feb 2012 03:33:11 -0800 (PST) In-Reply-To: References: <20120215011928.4651.7195.idtracker@ietfa.amsl.com> <20120215104232kawashimam@mail.jp.nec.com> From: Lorenzo Colitti Date: Fri, 24 Feb 2012 20:33:11 +0900 Message-ID: To: Cameron Byrne Content-Type: multipart/alternative; boundary=f46d04478a7f53540604b9b4213c X-System-Of-Record: true X-Gm-Message-State: ALoCoQmiDw+SaYWWRTEJzhbHl9oaG2+sf7gR29A1G8233guSVk22IwZFPVKoTIG2hE6Ow5S3hyEY3gzqesekdYv9SAuNIHNaY8rx+IfSDnR3K3KP+mj9JcW/zdkkx625j2qiLLGp+mzz Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 11:33:33 -0000 --f46d04478a7f53540604b9b4213c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 24, 2012 at 20:01, Cameron Byrne wrote: > Remi and Washam have brought up similar concerns regarding NDP. Our > thinking was that the /96 allows the CPE to remain stateless. > Today's CPE are basically never stateless. Your home router is a NAT44 box, your phone is a NAT44 box, even your enterprise router might be a NAT box or firewall. >From the perspective of a mobile phone... if it implements tethering, it already has a NAT44, so requiring NAT44 doesn't introduce additional complexity. On the other hand, introducing a requirement for proxy NDP does add complexity (and I'm not even sure if that behaviour is fully specified). It's true that an additional NAT44 does slightly degrade the quality of IPv6 connectivity due to the fact that it does double NAT. However, in mobile networks tethered devices are already double NATed. And if you're positioning 464xlat as a legacy IPv4 compatibility method for smartphones where most applications already support IPv6, then that slight extra degradation isn't a big concern. After all, if the application developer wants to, he can always use the native IPv6 path with no NATs in it. If you still have the test setup running, can you test with a /128 and see if anything else breaks compared to having a /96? --f46d04478a7f53540604b9b4213c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 24, 2012 at 20:01, Cameron Byrne <cb.list6@gmail.com= > wrote:

Remi and Washam have brought up = similar concerns regarding NDP.=A0 Our thinking was that the /96 allows the= CPE to remain stateless.=A0

Today's C= PE are basically never stateless. Your home router is a NAT44 box, your pho= ne is a NAT44 box, even your enterprise router might be a NAT box or firewa= ll.

From the perspective of a mobile phone... if it impleme= nts tethering, it already has a NAT44, so requiring NAT44 doesn't intro= duce additional complexity. On the other hand, introducing a requirement fo= r proxy NDP does add complexity (and I'm not even sure if that behaviou= r is fully specified).

It's true that an additional NAT44 does slightly de= grade the quality of IPv6 connectivity due to the fact that it does double = NAT. However, in mobile networks tethered devices are already double NATed.= And if you're positioning 464xlat as a legacy IPv4 compatibility metho= d for smartphones where most applications already support IPv6, then that s= light extra degradation isn't a big concern. After all, if the applicat= ion developer wants to, he can always use the native IPv6 path with no NATs= in it.

If you still have the test setup running, can you test = with a /128 and see if anything else breaks compared to having a /96?
=
--f46d04478a7f53540604b9b4213c-- From cb.list6@gmail.com Fri Feb 24 04:37:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C690621F87E6 for ; Fri, 24 Feb 2012 04:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6RCWfXPtVEy for ; Fri, 24 Feb 2012 04:37:48 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C881821F8881 for ; Fri, 24 Feb 2012 04:37:39 -0800 (PST) Received: by dakl33 with SMTP id l33so2555978dak.31 for ; Fri, 24 Feb 2012 04:37:39 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.130.233 as permitted sender) client-ip=10.68.130.233; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.130.233 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.130.233]) by 10.68.130.233 with SMTP id oh9mr7088068pbb.92.1330087059658 (num_hops = 1); Fri, 24 Feb 2012 04:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SnUwBqGOlHA56eAF0giCKHRl+jbWkY8H5GTHIX7psnk=; b=hSgyd8r0//8SA0kzek5C5jdijBOEKzTCYJf7zhUWmL3QiLh9Y8lqDpylzS2TgkENpk zs+c6pu2kt7uICNSGSb5SlkQrB87cpI+MnhCqAthu1Nel3zY3njAQyshShAs6Jj8v+yG wt3Embtp8vOTZj7vCruT5c/TLJEhN9QM4WyCk= MIME-Version: 1.0 Received: by 10.68.130.233 with SMTP id oh9mr5975242pbb.92.1330087059518; Fri, 24 Feb 2012 04:37:39 -0800 (PST) Received: by 10.142.99.12 with HTTP; Fri, 24 Feb 2012 04:37:39 -0800 (PST) In-Reply-To: References: <20120215011928.4651.7195.idtracker@ietfa.amsl.com> <20120215104232kawashimam@mail.jp.nec.com> Date: Fri, 24 Feb 2012 04:37:39 -0800 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 12:37:48 -0000 On Fri, Feb 24, 2012 at 3:33 AM, Lorenzo Colitti wrote= : > On Fri, Feb 24, 2012 at 20:01, Cameron Byrne wrote: >> >> Remi and Washam have brought up similar concerns regarding NDP.=A0 Our >> thinking was that the /96 allows the CPE to remain stateless. > > Today's CPE are basically never stateless. Your home router is a NAT44 bo= x, > your phone is a NAT44 box, even your enterprise router might be a NAT box= or > firewall. > > From the perspective of a mobile phone... if it implements tethering, it > already has a NAT44, so requiring NAT44 doesn't introduce additional > complexity. On the other hand, introducing a requirement for proxy NDP do= es > add complexity (and I'm not even sure if that behaviour is fully specifie= d). > > It's true that an additional NAT44 does slightly degrade the quality of I= Pv6 You mean degrade IPv4, right? In all cases IPv6 is end to end, no compromises, right? > connectivity due to the fact that it does double NAT. However, in mobile > networks tethered devices are already double NATed. And if you're > positioning 464xlat as a legacy IPv4 compatibility method for smartphones > where most applications already support IPv6, then that slight extra > degradation isn't a big concern. After all, if the application developer > wants to, he can always use the native IPv6 path with no NATs in it. > This is an important point. IPv4 does not have to be pure and perfect. If people want pure and perfect, IPv6 is the right solution and that is available. > If you still have the test setup running, can you test with a /128 and se= e > if anything else breaks compared to having a /96? Well, for my case of 3GPP, it is only tethering that would be impacted for scenarios where DNS64 is not effective (ie...IPv4 literals, ...) on a tethered LAN. So, it is more of a corner case for me, but not a corner case for others. I would have to get some code changes to the Android CLAT, as the tethering is not there yet. We'll see what we can do. Regarding draft language, i would like the group to help close this out since multiple folks have been interested in this. Today's language is here: http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00#section-7.5 =3D=3D=3D=3D=3D=3D Proposed new text: In the best case, the CLAT will have a dedicated /64 via DHCPv6 or other means to source and receive IPv6 packets associated with the [RFC6145] stateless translation of IPv4 packets to the local clients. In suboptimal cases where the access network does not allow for a dedica= ted translation prefix, CLAT MAY take ownership of a /96 from an attached interface's /64 to source and receive translation traffic. If this case, the CLAT SHOULD actively avoid LAN address conflicts for this claimed /96. Alternatively, the CLAT MAY do NAT44 such that all private IPv4 sourced LAN packets appears from one private IPv4 address which is statelessly translated to one IPv6 address that the CLAT will own as a host IPv6 address from an IPv6 /64 interface. =3D=3D=3D=3D=3D=3D=3D=3D Thoughts? Again, the goal is not to be perfect. The goal is to close the basic functionality gap the prevents IPv6-only access networks from being viable. CB From rajiva@cisco.com Fri Feb 24 05:36:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB7621F87B3 for ; Fri, 24 Feb 2012 05:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.871 X-Spam-Level: X-Spam-Status: No, score=-8.871 tagged_above=-999 required=5 tests=[AWL=1.128, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy3d0oc7rrE3 for ; Fri, 24 Feb 2012 05:36:05 -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 152F221F87B0 for ; Fri, 24 Feb 2012 05:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3702; q=dns/txt; s=iport; t=1330090565; x=1331300165; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=KqYa+rf7/iPul2MMiptslgXBBZFBX9yhQCbEQQyj0AQ=; b=eSXeVK/JVlvFtSouf6Hp9gXjIXosaWVmGscqimLDf25Jurepy4Sbam5v HnATBgyoiw47EfxGUhPJU4RTAcdWcr3afQuTYtnA9myX+U5fWYu1oQIrv XC0VglVqwqpcWJHa5K2TAzpn4XwXFyM1ZxcunzJt2x5XQchgbNRa++8F9 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADORR0+tJV2c/2dsb2JhbABCsxmBB4FzAQEBAwEBAQEPAR0+CwUHBAIBCBEEAQEBCgYXAQYBJh8DAQUIAQEEARIIGodfBQugSwGWeQSJeIMEDxUGET4aCoVUGhIMA4JKYwSIHDOfeoE9 X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="61540888" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 24 Feb 2012 13:36:04 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q1ODa44G018478; Fri, 24 Feb 2012 13:36:04 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Feb 2012 07:36:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2012 07:36:03 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0778DE49@XMB-RCD-111.cisco.com> In-Reply-To: <901586CA8F92D543BFFFD6E1122F5A3602733EFD0C97@HE101453.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczy2cLQoZaanFATTvym/aa7aLcYRwAAMPSAAAeTglA= References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net><18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com><93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net><4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com><867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com><3D40B569-062C-43DE-A059-69976FFFF7CB@nominum.com> <901586CA8F92D543BFFFD6E1122F5A3602733EFD0C97@HE101453.emea1.cds.t-internal.com> From: "Rajiv Asati (rajiva)" To: , "Ralph Droms (rdroms)" , X-OriginalArrivalTime: 24 Feb 2012 13:36:04.0536 (UTC) FILETIME=[416D4380:01CCF2F9] Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 13:36:06 -0000 Hi Christian , > described behaviour when I looked closly at it. During normal = operation we > had no major impact by using ULAs at home. Local network communication = (I > have localy delivered web and mail), if it uses IPv6, utilizes ULA. If = the GUA What's causing them to prefer ULA for local communication when GUA is = available?=20 Is the locally delivered web/mail destination IP address (i.e. ULA) is = hardcoded on the source devices (or some DNS muck-up)? Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of HahnC@t-systems.com > Sent: Friday, February 24, 2012 5:07 AM > To: Ralph Droms (rdroms); Ted.Lemon@nominum.com > Cc: v6ops@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org > Subject: Re: [v6ops] 6204bis and WAN disappearing >=20 > Hi folks, >=20 > >-----Original Message----- > >On Feb 23, 2012, at 9:07 PM 2/23/12, Ted Lemon wrote: > > > >> On Feb 23, 2012, at 9:32 AM, Ralph Droms > >> wrote: > >>> * ULA prefix with GUA advertised only when WAN connectivity > >is operable. What happens when the availability of the GUA > >flaps? Do hosts operate as expected and continue to > >communicate with other hosts using the ULA prefixes? Are any > >problems attributable to implementation issues or are there > >protocol problems? > >> > >> Linux and OSX both seem to support this correctly, at least > >according to the brief test I just did. Both operating > >systems use the ULA source address when attempting to > >communicate with a destination address that uses the same > >prefix. I don't have a windows box here to test it on, but I > >don't see any reason to think they get it wrong. > > > >Excellent. So, presumably, if the GUA prefix is withdrawn > >(advertised with lifetimes of 0?) from the RAs, Linux and OS X > >will continue to communicate with other hosts using the same > >ULA. Did you happen to actually try the experiment? >=20 > I run a similar setup at home for over one year now. In addtition to = that we > also use Windows XP and 7 machines. I can only say that I saw the = above > described behaviour when I looked closly at it. During normal = operation we > had no major impact by using ULAs at home. Local network communication = (I > have localy delivered web and mail), if it uses IPv6, utilizes ULA. If = the GUA > disappears (which was the case 2 or 3 times) local communcation = continues > to run stable. >=20 > > > >Anyone have experience with dedicated devices like a webcam, > >printer, NAS? >=20 > Unfortunatley, I don't have such devices with IPv6 support. >=20 > cheers, > Christian Hahn >=20 > ---------------------------------- > T-Systems International GmbH > Supervisory Board: Ren=E9 Obermann (Chairman) > Board of Management: Reinhard Clemens (Chairman), Dr. Ferri = Abolhassan, > Olaf Heyden, Joachim Langmack, Georg Pepping, Klaus Werner > Commercial register: Amtsgericht Frankfurt am Main HRB 55933 > Registered office: Frankfurt am Main > WEEE-Reg.-No. DE87523644 > > > >- Ralph > > > >> One slight concern about the Linux implementation is that > >the ULA is marked as global in ifconfig; I don't know whether > >this is a kernel bug or an ifconfig bug, and I've only tried > >it on Ubuntu Meerkat, so I don't have a broad sample to work from. > > > >_______________________________________________ > >v6ops mailing list > >v6ops@ietf.org > >https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From HahnC@t-systems.com Fri Feb 24 06:16:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A8B21F87D8 for ; Fri, 24 Feb 2012 06:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-Ni-BcYXbjF for ; Fri, 24 Feb 2012 06:16:42 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id EEBDE21F87D4 for ; Fri, 24 Feb 2012 06:16:41 -0800 (PST) From: HahnC@t-systems.com Received: from he111297.emea1.cds.t-internal.com ([10.125.90.15]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 24 Feb 2012 15:16:36 +0100 Received: from HE101453.emea1.cds.t-internal.com ([169.254.3.95]) by HE111297.EMEA1.CDS.T-INTERNAL.COM ([fe80::9835:b110:c489:6d64%16]) with mapi; Fri, 24 Feb 2012 15:16:36 +0100 To: , , Date: Fri, 24 Feb 2012 15:16:34 +0100 Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: Aczy2cLQoZaanFATTvym/aa7aLcYRwAAMPSAAAeTglAAAWZ70A== Message-ID: <901586CA8F92D543BFFFD6E1122F5A3602733F06308A@HE101453.emea1.cds.t-internal.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net><18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com><93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net><4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com><867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com><3D40B569-062C-43DE-A059-69976FFFF7CB@nominum.com> <901586CA8F92D543BFFFD6E1122F5A3602733EFD0C97@HE101453.emea1.cds.t-internal.com> <067E6CE33034954AAC05C9EC85E2577C0778DE49@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0778DE49@XMB-RCD-111.cisco.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 14:16:43 -0000 Hi Rajiv >Hi Christian , > >> described behaviour when I looked closly at it. During normal=20 >> operation we had no major impact by using ULAs at home.=20 >Local network=20 >> communication (I have localy delivered web and mail), if it=20 >uses IPv6,=20 >> utilizes ULA. If the GUA > >What's causing them to prefer ULA for local communication when=20 >GUA is available?=20 > >Is the locally delivered web/mail destination IP address (i.e.=20 >ULA) is hardcoded on the source devices (or some DNS muck-up)? Yes, forgot to mention that I run an internal DNS myself and "internal serv= ices" have both, ULA and GUA AAAA entries. cheers, Christian > > >Cheers, >Rajiv > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 >On Behalf=20 >> Of HahnC@t-systems.com >> Sent: Friday, February 24, 2012 5:07 AM >> To: Ralph Droms (rdroms); Ted.Lemon@nominum.com >> Cc: v6ops@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org >> Subject: Re: [v6ops] 6204bis and WAN disappearing >>=20 >> Hi folks, >>=20 >> >-----Original Message----- >> >On Feb 23, 2012, at 9:07 PM 2/23/12, Ted Lemon wrote: >> > >> >> On Feb 23, 2012, at 9:32 AM, Ralph Droms >> >> wrote: >> >>> * ULA prefix with GUA advertised only when WAN connectivity >> >is operable. What happens when the availability of the GUA flaps? =20 >> >Do hosts operate as expected and continue to communicate with other=20 >> >hosts using the ULA prefixes? Are any problems attributable to=20 >> >implementation issues or are there protocol problems? >> >> >> >> Linux and OSX both seem to support this correctly, at least >> >according to the brief test I just did. Both operating >> >systems use the ULA source address when attempting to communicate=20 >> >with a destination address that uses the same >> >prefix. I don't have a windows box here to test it on, but I >> >don't see any reason to think they get it wrong. >> > >> >Excellent. So, presumably, if the GUA prefix is withdrawn=20 >> >(advertised with lifetimes of 0?) from the RAs, Linux and OS X will=20 >> >continue to communicate with other hosts using the same=20 >ULA. Did you=20 >> >happen to actually try the experiment? >>=20 >> I run a similar setup at home for over one year now. In addtition to=20 >> that we also use Windows XP and 7 machines. I can only say=20 >that I saw=20 >> the above described behaviour when I looked closly at it. During=20 >> normal operation we had no major impact by using ULAs at home. Local=20 >> network communication (I have localy delivered web and mail), if it=20 >> uses IPv6, utilizes ULA. If the GUA disappears (which was the case 2=20 >> or 3 times) local communcation continues to run stable. >>=20 >> > >> >Anyone have experience with dedicated devices like a=20 >webcam, printer,=20 >> >NAS? >>=20 >> Unfortunatley, I don't have such devices with IPv6 support. >>=20 >> cheers, >> Christian Hahn >>=20 >> ---------------------------------- >> T-Systems International GmbH >> Supervisory Board: Ren=E9 Obermann (Chairman) Board of Management:=20 >> Reinhard Clemens (Chairman), Dr. Ferri Abolhassan, Olaf Heyden,=20 >> Joachim Langmack, Georg Pepping, Klaus Werner Commercial register:=20 >> Amtsgericht Frankfurt am Main HRB 55933 Registered office: Frankfurt=20 >> am Main WEEE-Reg.-No. DE87523644 >> > >> >- Ralph >> > >> >> One slight concern about the Linux implementation is that >> >the ULA is marked as global in ifconfig; I don't know=20 >whether this is=20 >> >a kernel bug or an ifconfig bug, and I've only tried it on Ubuntu=20 >> >Meerkat, so I don't have a broad sample to work from. >> > >> >_______________________________________________ >> >v6ops mailing list >> >v6ops@ietf.org >> >https://www.ietf.org/mailman/listinfo/v6ops >> > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >= From rajiva@cisco.com Fri Feb 24 07:16:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2B421F87BE for ; Fri, 24 Feb 2012 07:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.223 X-Spam-Level: X-Spam-Status: No, score=-9.223 tagged_above=-999 required=5 tests=[AWL=1.376, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Utf99BKq82od for ; Fri, 24 Feb 2012 07:16:32 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 936E021F87BA for ; Fri, 24 Feb 2012 07:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2695; q=dns/txt; s=iport; t=1330096579; x=1331306179; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BFc7xxhbjuanrQMLbireTtBJJh2tNrZQxa5KFZHr9g4=; b=KnZT+vy7UEbJA7DY6t0UBB3+40GCZRvCMuWBUYsTmCOrnVTV8BywR1iV 8F6lk+N2nomvfikDpbplTswy1jnWgUjHBed2HBeeuuVm0qYLemw3ziUTa sE/CleGEMFEBLnNePSVQh9x3FgJ1Kecof9chsG9phG0F5GsAZFJSmYMgJ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEqpR0+tJV2a/2dsb2JhbABCsxiBB4FzAQEBAwESAR0KPwUHBAIBCBEEAQEBCgYXAQYBICUJCAEBBAESCBqHXwWgTgGXAYkOg3UIFRc+GggChgAMgk1jBIhPmASHdg X-IronPort-AV: E=Sophos;i="4.73,476,1325462400"; d="scan'208";a="61569216" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 24 Feb 2012 15:16:19 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1OFGJ6g003218; Fri, 24 Feb 2012 15:16:19 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Feb 2012 09:16:19 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Feb 2012 09:16:17 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0778DED7@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt Thread-Index: Aczy6Ctk7SHysHGzSQGMEGyKz6CfDQAHfqyQ References: <20120215011928.4651.7195.idtracker@ietfa.amsl.com><20120215104232kawashimam@mail.jp.nec.com> From: "Rajiv Asati (rajiva)" To: "Lorenzo Colitti" , "Cameron Byrne" X-OriginalArrivalTime: 24 Feb 2012 15:16:19.0086 (UTC) FILETIME=[4260C2E0:01CCF307] Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 15:16:33 -0000 > From the perspective of a mobile phone... if it implements tethering, it > already has a NAT44, so requiring NAT44 doesn't introduce additional > complexity. On the other hand, introducing a requirement for proxy NDP > does add complexity (and I'm not even sure if that behaviour is fully > specified). +1. > connectivity due to the fact that it does double NAT. However, in mobile > networks tethered devices are already double NATed. And if you're > positioning 464xlat as a legacy IPv4 compatibility method for smartphones > where most applications already support IPv6, then that slight extra > degradation isn't a big concern. =20 +1. With Tethering (e.g. mobile router is in play), we are back to MAP translation variant for legacy IPv4 connectivity, making it useful/beneficial to both wireline and mobile networks.=20 464xlat is a good option for supporting legacy ipv4 only on mobile networks, when the handsets are not supporting/doing tethering, IMO. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Lorenzo Colitti > Sent: Friday, February 24, 2012 6:33 AM > To: Cameron Byrne > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt >=20 > On Fri, Feb 24, 2012 at 20:01, Cameron Byrne wrote: >=20 >=20 > Remi and Washam have brought up similar concerns regarding NDP. > Our thinking was that the /96 allows the CPE to remain stateless. >=20 > Today's CPE are basically never stateless. Your home router is a NAT44 box, > your phone is a NAT44 box, even your enterprise router might be a NAT box > or firewall. >=20 > From the perspective of a mobile phone... if it implements tethering, it > already has a NAT44, so requiring NAT44 doesn't introduce additional > complexity. On the other hand, introducing a requirement for proxy NDP > does add complexity (and I'm not even sure if that behaviour is fully > specified). >=20 > It's true that an additional NAT44 does slightly degrade the quality of IPv6 > connectivity due to the fact that it does double NAT. However, in mobile > networks tethered devices are already double NATed. And if you're > positioning 464xlat as a legacy IPv4 compatibility method for smartphones > where most applications already support IPv6, then that slight extra > degradation isn't a big concern. After all, if the application developer wants > to, he can always use the native IPv6 path with no NATs in it. >=20 > If you still have the test setup running, can you test with a /128 and see if > anything else breaks compared to having a /96? From despres.remi@laposte.net Fri Feb 24 08:21:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553E521F8815 for ; Fri, 24 Feb 2012 08:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYKVsfuq1qlp for ; Fri, 24 Feb 2012 08:21:39 -0800 (PST) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id D2F1221F87ED for ; Fri, 24 Feb 2012 08:21:38 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id dsMa1i00937Y3f403sMa7Q; Fri, 24 Feb 2012 17:21:36 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--394023486 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 24 Feb 2012 17:21:34 +0100 Message-Id: <57744AC3-B42A-4CE9-8732-1B7451D4962B@laposte.net> References: <20120215011928.4651.7195.idtracker@ietfa.amsl.com> <20120215104232kawashimam@mail.jp.nec.com> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:21:40 -0000 --Apple-Mail-2--394023486 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-02-24 =E0 11:30, Lorenzo Colitti a =E9crit : > On Wed, Feb 15, 2012 at 10:42, Masanobu Kawashima = wrote: > We have published draft-ietf-v6ops-464xlat-00 as WG draft. > We welcome all your comments. >=20 > I like this, because it makes it relatively easy to provide legacy = IPv4 connectivity on a device that has IPv6-only connectivity. >=20 > It's a particularly good fit for 3GPP devices like mobile phones = because it's relatively simple, can be implemented entirely in = userspace, and requires no provisioning that isn't already provided by = 3GPP (a /64 and a DNS server). And it's just a combination of existing = standards. >=20 > By comparison, I think solutions like 4rd require a more complex = device implementation, need the kernel to pick ports in a way that will = be understood by the translator, and require provisioning as to what = mapping algorithm and port ranges to use. I can see why you would use = something like 4rd in a wireline CPE, but on something like a = smartphone, which is already behind an IPv4 NAT today and most = applications already support IPv6, the IPv4 connectivity is only really = used for a few apps anyway. >=20 > I have one question, though: why does the CLAT require a /96? > Wouldn't it be simpler if it uses just one /128 and performed NAT44 = for clients behind it? +1 for this approach. Besides being simpler per se, if there is a LAN, it facilitates = commonality with 4rd, a subject I am working on right now; RD >=20 > That way, if the CLAT have one /64 like in the 3GPP case, you don't = have to worry about DAD and NDP proxying. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-2--394023486 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Wed, Feb 15, 2012 at 10:42, = Masanobu Kawashima <kawashimam@vx.jp.nec.com><= /span> wrote:
We have published draft-ietf-v6ops-464xlat-00 as WG draft.
We welcome all your comments.

I like = this, because it makes it relatively easy to provide legacy IPv4 = connectivity on a device that has IPv6-only = connectivity.

It's a particularly good fit for 3GPP devices like mobile phones because = it's relatively simple, can be implemented entirely in userspace, and = requires no provisioning that isn't already provided by 3GPP (a /64 and = a DNS server). And it's just a combination of existing standards.

By comparison, I think solutions like 4rd require a = more complex device implementation, need the kernel to pick ports in a = way that will be understood by the translator, and require provisioning = as to what mapping algorithm and port ranges to use. I can see why you = would use something like 4rd in a wireline CPE, but on something = like a smartphone, which is already behind an IPv4 NAT today and = most applications already support IPv6, the IPv4 connectivity is only = really used for a few apps anyway.

I have one question, though: why does the CLAT = require a /96?


Wouldn't it be simpler if = it uses just one /128 and performed NAT44 for clients behind = it?

+1 for this = approach.

Besides being simpler per se, if = there is a LAN, it facilitates commonality with 4rd, a subject I am = working on right = now;

RD



That way, = if the CLAT have one /64 like in the 3GPP case, you don't have to worry = about DAD and NDP proxying.
_______________________________________________
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail-2--394023486-- From fgont@si6networks.com Fri Feb 24 08:37:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1471A21F87F7 for ; Fri, 24 Feb 2012 08:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.488 X-Spam-Level: X-Spam-Status: No, score=0.488 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lX2DfFEu7n6P for ; Fri, 24 Feb 2012 08:37:55 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id A941721F87F1 for ; Fri, 24 Feb 2012 08:37:47 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.104]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S0y9I-0003nk-Uc; Fri, 24 Feb 2012 17:37:37 +0100 Message-ID: <4F4712D2.4050202@si6networks.com> Date: Fri, 24 Feb 2012 01:32:18 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Ray Hunter References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F4286A0.6040203@globis.net> In-Reply-To: <4F4286A0.6040203@globis.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:37:56 -0000 Hi, Ray, Thanks so much for your feedback! -- Please find my comments inline... On 02/20/2012 02:45 PM, Ray Hunter wrote: > One thing I do not find satisfactory is one of the MUST drop rules: > >> 3. If the layer-2 device is unable to identify whether the packet is >> an ICMPv6 Router Advertisement message or not (i.e., the packet >> is a fragment, and the necessary information is missing), the >> IPv6 Source Address of the packet is a link-local address or the >> unspecified address (::), and the Hop Limit is 255, silently drop >> the packet. > I understand the logic of the rule. But to me this suggests that the RA > Guard filtering mechanism may well exceed its raison d'etre of layer 2 > filtering of unauthorized RA messages. Filtering RA messages at layer-2 has a number of challenges: 1) RFC4861 allows fragmentation of ND packets. Even if we eventually change this (as proposed in draft-gont-6man-nd-extension-headers), RA-Guard must still be able to deal with the deployed base (i.e., it could never assume that such packets will be dropped) 2) IPv6 first-fragments that do not include the entire header chain are currently legitimate (please see draft-gont-6man-oversized-header-chain). Therefore, an attacker could always conceal the payload by including lots of extension headers, and fragmenting the packets. So the rule above should be read as: "Pathological fragments that do not include the entire IPv6 header chain are still legitimate (specs-wise)... we could rather ban them in RA-Guard... but let's be more conservative, and just filter the ones that could hurt what we are meaning to protect" The above rule will only filter first-fragments that fail to contain the entire IPv6 header chain (i.e., the upper-layer protocol cannot be determined). In order to avoid false positives, we also check the Hop Limit and the Source Address. Note, however, that my take is that such packets would likely be filtered by any deployed IPv6 firewalls, so legitimate traffic shouldn't rely on them. > I get the feeling therefore that > the detection/definition of what is an unauthorized RA message may > currently be underspecified. Or else the RA message itself is currently > specified in such a way that the RA Guard filtering approach is not > viable, as it may be circumvented by other yet-to-be-discovered cloaking > mechanisms. There are two different problems here, which kind of overlap: 1) Support of fragmentation in ND traffic: this should be forbidden (I'd argue that it should be forbidden even if SEND is deployed). Supporting fragmentation makes it much harder to produce feature parity with IPv4: ND traffic monitoring is virtually impossible. 2) First-fragments that do not contain the entire IPv6 header chain bein legitimate: As far as RA-Guard is concerned, if the entire header chain is present in the first-fragment, then we can "cleanly" filter the packets. If the header chain is split into multiple fragments, then we must rely on the heuristics above. > This rule we may also be in danger of heralding in a "drop all source > hop-limit 255 unless" layer-2 filter to cover a > multitude of evils for various protocols and messages. > > What other legitimate traffic would/could this rule potentially break? As noted above, I really doubt that any protocol that relies on "oversized header chains" (draft-gont-6man-oversized-header-chain) as IPv6 firewalls get widely deployed -- the only way to firewall such traffic would be to reassemble-filter-fragment... and that's undesirable in many cases. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From bs7652@att.com Fri Feb 24 09:00:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F2D21F8802 for ; Fri, 24 Feb 2012 09:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kygs7gHEPOyo for ; Fri, 24 Feb 2012 09:00:53 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD7A21F8812 for ; Fri, 24 Feb 2012 09:00:53 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1330102852!65189805!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11134 invoked from network); 24 Feb 2012 17:00:52 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Feb 2012 17:00:52 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1OGxIGt006825; Fri, 24 Feb 2012 11:59:19 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1OGxGqC006724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2012 11:59:16 -0500 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint04.pst.cso.att.com (RSA Interceptor); Fri, 24 Feb 2012 12:00:27 -0500 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.249]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 12:00:27 -0500 From: "STARK, BARBARA H" To: Teemu Savolainen , "v6ops@ietf.org" Thread-Topic: [v6ops] PD-exclude was approved by the IESG -> should be included into 6204bis Thread-Index: AQHM7VAtWpQV+h/2P02U0L/tglKVnJZMTkEQ Date: Fri, 24 Feb 2012 17:00:27 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611043C0B@GAALPA1MSGUSR9N.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {A1013820-7B7B-4E3A-8BAA-0D3A55EB71EF} x-cr-hashedpuzzle: AFPl EUmx F2ES F67Z GOrl HDZe MBKi MSgZ Mgq4 MyB5 NZwh OwQ8 RoCx TqkM UBX7 XaN9; 2; dABzAGEAdgBvAC4AcwB0AGQAcwBAAGcAbQBhAGkAbAAuAGMAbwBtADsAdgA2AG8AcABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {A1013820-7B7B-4E3A-8BAA-0D3A55EB71EF}; YgBzADcANgA1ADIAQABhAHQAdAAuAGMAbwBtAA==; Fri, 24 Feb 2012 17:00:21 GMT; UgBFADoAIABbAHYANgBvAHAAcwBdACAAUABEAC0AZQB4AGMAbAB1AGQAZQAgAHcAYQBzACAAYQBwAHAAcgBvAHYAZQBkACAAYgB5ACAAdABoAGUAIABJAEUAUwBHACAALQA+ACAAcwBoAG8AdQBsAGQAIABiAGUAIABpAG4AYwBsAHUAZABlAGQACQBpAG4AdABvACAANgAyADAANABiAGkAcwA= x-originating-ip: [135.70.114.248] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E611043C0BGAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [v6ops] PD-exclude was approved by the IESG -> should be included into 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 17:00:56 -0000 --_000_2D09D61DDFA73D4C884805CC7865E611043C0BGAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a question as to whether this needs to be a MUST/SHALL or can it be = a SHOULD. In my mind, the answer to this depends on how operators who intend to use P= D-exclude will treat CE routers that do not support PD-exclude. Will they refuse to offer IA_PD (so the non-PD-exclude-supporting CE router= is useless for attachment to that access network), or will they offer IA_P= D and either also offer IA_NA (from a different prefix) or let the CE route= r operate in "unnumbered mode"? If there are numerous operators who intend to use PD-exclude and won't supp= ort non-PD-exclude CE routers, then I agree it's a MUST/SHALL. If these net= works will also provide support for non-PD-exclude CE routers, then I think= SHOULD would be reasonable. Barbara From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of T= eemu Savolainen Sent: Friday, February 17, 2012 3:43 AM To: v6ops@ietf.org Subject: [v6ops] PD-exclude was approved by the IESG -> should be included = into 6204bis Hi v6ops, You may have already noticed that draft-ietf-dhc-pd-exclude-04 was yesterda= y approved by the IESG. I would like to add to the draft-ietf-v6ops-6204bis section 4.2 a new requi= rement (to W-4, or maybe to the WPD-x series) that says support for pd-excl= ude is a SHALL for IPv6 CE router. Best regards, Teemu FYI: --- State changed to Approved-announcement to be sent from IESG Evaluation. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dhc-pd-exclude/ --_000_2D09D61DDFA73D4C884805CC7865E611043C0BGAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a question as to w= hether this needs to be a MUST/SHALL or can it be a SHOULD.

In my mind, the answer to= this depends on how operators who intend to use PD-exclude will treat CE r= outers that do not support PD-exclude.

Will they refuse to offer= IA_PD (so the non-PD-exclude-supporting CE router is useless for attachmen= t to that access network), or will they offer IA_PD and either also offer IA_NA (from a different prefix) or let the CE router ope= rate in “unnumbered mode”?

If there are numerous ope= rators who intend to use PD-exclude and won’t support non-PD-exclude = CE routers, then I agree it’s a MUST/SHALL. If these networks will also provide support for non-PD-exclude CE routers, then I think SHOU= LD would be reasonable.

Barbara=

 <= /p>

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Teemu Savolainen
Sent: Friday, February 17, 2012 3:43 AM
To: v6ops@ietf.org
Subject: [v6ops] PD-exclude was approved by the IESG -> should be= included into 6204bis

 

Hi v6ops,

You may have already noticed that draft-ietf-dhc-pd-exclude-04 was yesterda= y approved by the IESG.

I would like to add to the draft-ietf-v6ops-6204bis section 4.2 a new requi= rement (to W-4, or maybe to the WPD-x series) that says support for pd-excl= ude is a SHALL for IPv6 CE router.

Best regards,

Teemu


FYI: ---

State changed to Approved-announcement to be sent= from IESG Evaluation.

ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dhc-pd-exclude/

 

--_000_2D09D61DDFA73D4C884805CC7865E611043C0BGAALPA1MSGUSR9NIT_-- From v6ops@globis.net Fri Feb 24 09:20:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7098621F85DB for ; Fri, 24 Feb 2012 09:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuQRJ4PgPBqz for ; Fri, 24 Feb 2012 09:20:56 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id CEFB921F854E for ; Fri, 24 Feb 2012 09:20:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9D4788700F5; Fri, 24 Feb 2012 18:20:54 +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 xdXOKN+UEv56; Fri, 24 Feb 2012 18:20:38 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 92EFE8700B2; Fri, 24 Feb 2012 18:20:38 +0100 (CET) Message-ID: <4F47C6E6.9040609@globis.net> Date: Fri, 24 Feb 2012 18:20:38 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Fernando Gont References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F4286A0.6040203@globis.net> <4F4712D2.4050202@si6networks.com> In-Reply-To: <4F4712D2.4050202@si6networks.com> Content-Type: multipart/alternative; boundary="------------040409070606090407030403" Cc: draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 17:20:58 -0000 This is a multi-part message in MIME format. --------------040409070606090407030403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Understood. Thanks. I also see perhaps a third way less-draconian way to help address the generic problem of being unable to track fragmented headers at L2 (due to cloaking). The problem is as you state: "Therefore, it is impossible for a device processing only the second fragment to locate the ICMPv6 header contained in that fragment, since it is unknown how many bytes should be "skipped" to get to the next header following the Destination Options Header." What if this uncertainty could be removed, and the amount to be skipped in subsequent frames was always zero, at least until the ICMPv6 RA or other ND message was encountered and identified? Since fragmentation in IPv6 is host-based, it seems to me that the source host should always have a complete picture of the PMTU and the full contents of the message to be fragmented (unlike IPv4 fragmentation by intermediate routers, which cannot take into account message content in the decision of where to fragment). ND is also very likely to be running on a single contiguous link where the MTU is well defined and known directly at the interface on the source node. So rather than banning fragments altogether for certain traffic, or insisting that the complete header chain resides in the first frame, why not specify that fragmentation should always occur at a convenient point so that the header chain can always be followed at L2 filters, even for individual frames in a fragmented packet, and thus ensure layer 2 filtering or firewall mechanisms cannot be bypassed by "cloaking" via oversized headers? Wouldn't that be as straight forward as saying individual option headers shouldn't be fragmented across multiple frames when transmitting RA, ND or other critical messages that are likely to be filtered at L2? A similar check could be made by receiving hosts during reassembling and processing ND messages to ensure that the end node knew that these frames could have been filtered by RA-Guard or other ND-Guard mechanism if necessary (if it was present). That seems like a much less onerous restriction than the two previously proposed of either banning fragmentation altogether or limiting the total option header length to one frame. regards, RayH Fernando Gont wrote: > Hi, Ray, > > Thanks so much for your feedback! -- Please find my comments inline... > > On 02/20/2012 02:45 PM, Ray Hunter wrote: > >> One thing I do not find satisfactory is one of the MUST drop rules: >> >> >>> 3. If the layer-2 device is unable to identify whether the packet is >>> an ICMPv6 Router Advertisement message or not (i.e., the packet >>> is a fragment, and the necessary information is missing), the >>> IPv6 Source Address of the packet is a link-local address or the >>> unspecified address (::), and the Hop Limit is 255, silently drop >>> the packet. >>> >> I understand the logic of the rule. But to me this suggests that the RA >> Guard filtering mechanism may well exceed its raison d'etre of layer 2 >> filtering of unauthorized RA messages. >> > > Filtering RA messages at layer-2 has a number of challenges: > > 1) RFC4861 allows fragmentation of ND packets. Even if we eventually > change this (as proposed in draft-gont-6man-nd-extension-headers), > RA-Guard must still be able to deal with the deployed base (i.e., it > could never assume that such packets will be dropped) > > 2) IPv6 first-fragments that do not include the entire header chain are > currently legitimate (please see > draft-gont-6man-oversized-header-chain). Therefore, an attacker could > always conceal the payload by including lots of extension headers, and > fragmenting the packets. > > So the rule above should be read as: > "Pathological fragments that do not include the entire IPv6 header chain > are still legitimate (specs-wise)... we could rather ban them in > RA-Guard... but let's be more conservative, and just filter the ones > that could hurt what we are meaning to protect" > > The above rule will only filter first-fragments that fail to contain the > entire IPv6 header chain (i.e., the upper-layer protocol cannot be > determined). In order to avoid false positives, we also check the Hop > Limit and the Source Address. > > Note, however, that my take is that such packets would likely be > filtered by any deployed IPv6 firewalls, so legitimate traffic shouldn't > rely on them. > > > >> I get the feeling therefore that >> the detection/definition of what is an unauthorized RA message may >> currently be underspecified. Or else the RA message itself is currently >> specified in such a way that the RA Guard filtering approach is not >> viable, as it may be circumvented by other yet-to-be-discovered cloaking >> mechanisms. >> > > There are two different problems here, which kind of overlap: > 1) Support of fragmentation in ND traffic: this should be forbidden (I'd > argue that it should be forbidden even if SEND is deployed). Supporting > fragmentation makes it much harder to produce feature parity with IPv4: > ND traffic monitoring is virtually impossible. > > 2) First-fragments that do not contain the entire IPv6 header chain bein > legitimate: As far as RA-Guard is concerned, if the entire header chain > is present in the first-fragment, then we can "cleanly" filter the > packets. If the header chain is split into multiple fragments, then we > must rely on the heuristics above. > > > > >> This rule we may also be in danger of heralding in a "drop all source >> hop-limit 255 unless" layer-2 filter to cover a >> multitude of evils for various protocols and messages. >> >> What other legitimate traffic would/could this rule potentially break? >> > > As noted above, I really doubt that any protocol that relies on > "oversized header chains" (draft-gont-6man-oversized-header-chain) as > IPv6 firewalls get widely deployed -- the only way to firewall such > traffic would be to reassemble-filter-fragment... and that's undesirable > in many cases. > > Thanks, > --------------040409070606090407030403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Understood. Thanks.

I also see perhaps a third way less-draconian way to help address the generic problem of being unable to track fragmented headers at L2 (due to cloaking).

The problem is as you state: "Therefore, it is impossible for a device processing only the second fragment to locate the ICMPv6 header contained in that fragment, since it is unknown how many bytes should be "skipped" to get to the next header following the Destination Options Header."

What if this uncertainty could be removed, and the amount to be skipped in subsequent frames was always zero, at least until the ICMPv6 RA or other ND message was encountered and identified?

Since fragmentation in IPv6 is host-based, it seems to me that the source host should always have a complete picture of the PMTU and the full contents of the message to be fragmented (unlike IPv4 fragmentation by intermediate routers, which cannot take into account message content in the decision of where to fragment). ND is also very likely to be running on a single contiguous link where the MTU is well defined and known directly at the interface on the source node.

So rather than banning fragments altogether for certain traffic, or insisting that the complete header chain resides in the first frame, why not specify that fragmentation should always occur at a convenient point so that the header chain can always be followed at L2 filters, even for individual frames in a fragmented packet, and thus ensure layer 2 filtering or firewall mechanisms cannot be bypassed by "cloaking" via oversized headers?

Wouldn't that be as straight forward as saying individual option headers shouldn't be fragmented across multiple frames when transmitting RA, ND or other critical messages that are likely to be filtered at L2? A similar check could be made by receiving hosts during reassembling and processing ND messages to ensure that the end node knew that these frames could have been filtered by RA-Guard or other ND-Guard mechanism if necessary (if it was present).

That seems like a much less onerous restriction than the two previously proposed of either banning fragmentation altogether or limiting the total option header length to one frame.

regards,
RayH

Fernando Gont wrote: 
Hi, Ray,

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

On 02/20/2012 02:45 PM, Ray Hunter wrote:
  
One thing I do not find satisfactory is one of the MUST drop rules:

    
3.  If the layer-2 device is unable to identify whether the packet is
       an ICMPv6 Router Advertisement message or not (i.e., the packet
       is a fragment, and the necessary information is missing), the
       IPv6 Source Address of the packet is a link-local address or the
       unspecified address (::), and the Hop Limit is 255, silently drop
       the packet.
      
I understand the logic of the rule. But to me this suggests that the RA
Guard filtering mechanism may well exceed its raison d'etre of layer 2
filtering of unauthorized RA messages. 
    

Filtering RA messages at layer-2 has a number of challenges:

1) RFC4861 allows fragmentation of ND packets. Even if we eventually
change this (as proposed in draft-gont-6man-nd-extension-headers),
RA-Guard must still be able to deal with the deployed base (i.e., it
could never assume that such packets will be dropped)

2) IPv6 first-fragments that do not include the entire header chain are
currently legitimate (please see
draft-gont-6man-oversized-header-chain). Therefore, an attacker could
always conceal the payload by including lots of extension headers, and
fragmenting the packets.

So the rule above should be read as:
"Pathological fragments that do not include the entire IPv6 header chain
are still legitimate (specs-wise)... we could rather ban them in
RA-Guard... but let's be more conservative, and just filter the ones
that could hurt what we are meaning to protect"

The above rule will only filter first-fragments that fail to contain the
entire IPv6 header chain (i.e., the upper-layer protocol cannot be
determined). In order to avoid false positives, we also check the Hop
Limit and the Source Address.

Note, however, that my take is that such packets would likely be
filtered by any deployed IPv6 firewalls, so legitimate traffic shouldn't
rely on them.


  
I get the feeling therefore that
the detection/definition of what is an unauthorized RA message may
currently be underspecified. Or else the RA message itself is currently
specified in such a way that the RA Guard filtering approach is not
viable, as it may be circumvented by other yet-to-be-discovered cloaking
mechanisms.
    

There are two different problems here, which kind of overlap:
1) Support of fragmentation in ND traffic: this should be forbidden (I'd
argue that it should be forbidden even if SEND is deployed). Supporting
fragmentation makes it much harder to produce feature parity with IPv4:
ND traffic monitoring is virtually impossible.

2) First-fragments that do not contain the entire IPv6 header chain bein
legitimate: As far as RA-Guard is concerned, if the entire header chain
is present in the first-fragment, then we can "cleanly" filter the
packets. If the header chain is split into multiple fragments, then we
must rely on the heuristics above.



  
This rule we may also be in danger of heralding in a "drop all source
<link-local-address> hop-limit 255 unless" layer-2 filter to cover a
multitude of evils for various protocols and messages.

What other legitimate traffic would/could this rule potentially break?
    

As noted above, I really doubt that any protocol that relies on
"oversized header chains" (draft-gont-6man-oversized-header-chain) as
IPv6 firewalls get widely deployed -- the only way to firewall such
traffic would be to reassemble-filter-fragment... and that's undesirable
in many cases.

Thanks,

--------------040409070606090407030403-- From bs7652@att.com Fri Feb 24 09:36:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1912C21F8871 for ; Fri, 24 Feb 2012 09:36:11 -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.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2W6gnbCFAYH for ; Fri, 24 Feb 2012 09:36:10 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5705B21F885E for ; Fri, 24 Feb 2012 09:36:10 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1330104969!65978169!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2652 invoked from network); 24 Feb 2012 17:36:09 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Feb 2012 17:36:09 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1OHYacv024966; Fri, 24 Feb 2012 12:34:36 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1OHYUYl024767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2012 12:34:31 -0500 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (gaalpa1msghub9a.itservices.sbc.com [130.8.36.87]) by sflint04.pst.cso.att.com (RSA Interceptor); Fri, 24 Feb 2012 12:36:00 -0500 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.249]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 12:36:00 -0500 From: "STARK, BARBARA H" To: Mark Andrews , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: AQHM8nLyxzzuwPVYQ0aM/GWBoA4FXZZMJ2pA Date: Fri, 24 Feb 2012 17:35:59 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E611043C70@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> <20120223213440.B441E1DC3938@drugs.dv.isc.org> In-Reply-To: <20120223213440.B441E1DC3938@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.114.248] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-6204bis@tools.ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 17:36:11 -0000 > We do need a mechanism so that CPE connected to a ISP can be made > aware that the upstream interface is *not* part of site. A DHCP / > RA option, announced by the ISP, would do this nicely perhaps with > a AS number or other unique identifier so that multiple upstream > from the same ISP can be identified. I think this (the DHCPv6 option, not RA) is an interesting suggestion to ex= plore. But instead of indicating what scope the upstream interface is *not*= a part of, I think it might be better to indicate the lowest level multica= st scope it *is* a part of. It would be reasonable to expect ISPs to indica= te "global scope".=20 But a CE router could be configured or defaulted to send a lower (site or o= rganization) scope from its own DHCPv6 server.=20 Given that multiple specs (e.g., REC-2 of RFC 6092) tell CE routers not to = send org scope or lower out the WAN interface, by default, such a DHCPv6 op= tion used by CE routers on their LAN interfaces might provide a useful way = to help cascaded routers understand that they are not at the LAN boundary, = and make it easier to create a working multicast environment in a multi-rou= ter home network. I guess this would need to be something for dhcwg and homenet to consider, = though.=20 Barbara From ichiroumakino@gmail.com Fri Feb 24 09:46:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C44221F867A for ; Fri, 24 Feb 2012 09:46:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8mYyWlBtxNj for ; Fri, 24 Feb 2012 09:46:33 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8828021F885E for ; Fri, 24 Feb 2012 09:46:32 -0800 (PST) Received: by lahl5 with SMTP id l5so3624926lah.31 for ; Fri, 24 Feb 2012 09:46:31 -0800 (PST) Received-SPF: pass (google.com: domain of ichiroumakino@gmail.com designates 10.152.110.6 as permitted sender) client-ip=10.152.110.6; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ichiroumakino@gmail.com designates 10.152.110.6 as permitted sender) smtp.mail=ichiroumakino@gmail.com; dkim=pass header.i=ichiroumakino@gmail.com Received: from mr.google.com ([10.152.110.6]) by 10.152.110.6 with SMTP id hw6mr2716684lab.8.1330105591619 (num_hops = 1); Fri, 24 Feb 2012 09:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=E7JLlm2h69I27RXBYokjl7+p4cIG7eRCPFNglu0TekM=; b=CSopdIGGPBF+zu/Z9X4Tn4QVkXmd7Pn2tdCXb7/K7Y/amPAHRjJe5OC8DqcQW6LHMe 5FxxYRLtlkJY07CbmDvB1AleH5Ky5IhP5SH1Ub+5A9+5dlfD4stC121NOFENWqTyIGFp 6x4PfYW/UbzEnyuYfD8I0Gm1xOdCRGSwFxMPE= Received: by 10.152.110.6 with SMTP id hw6mr2230513lab.8.1330105591551; Fri, 24 Feb 2012 09:46:31 -0800 (PST) Received: from gomlefisk.lan ([84.48.218.141]) by mx.google.com with ESMTPS id tt8sm6416099lbb.16.2012.02.24.09.46.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Feb 2012 09:46:30 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611043C70@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Fri, 24 Feb 2012 18:46:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6017CD47-0538-4732-ADCC-88B756B56343@employees.org> References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com> <20120223213440.B441E1DC3938@drugs.dv.isc.org> <2D09D61DDFA73D4C884805CC7865E611043C70@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1257) Cc: "draft-ietf-v6ops-6204bis@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 17:46:33 -0000 >> We do need a mechanism so that CPE connected to a ISP can be made >> aware that the upstream interface is *not* part of site. A DHCP / >> RA option, announced by the ISP, would do this nicely perhaps with >> a AS number or other unique identifier so that multiple upstream >> from the same ISP can be identified. >=20 > I think this (the DHCPv6 option, not RA) is an interesting suggestion = to explore. But instead of indicating what scope the upstream interface = is *not* a part of, I think it might be better to indicate the lowest = level multicast scope it *is* a part of. It would be reasonable to = expect ISPs to indicate "global scope".=20 >=20 > But a CE router could be configured or defaulted to send a lower (site = or organization) scope from its own DHCPv6 server.=20 >=20 > Given that multiple specs (e.g., REC-2 of RFC 6092) tell CE routers = not to send org scope or lower out the WAN interface, by default, such a = DHCPv6 option used by CE routers on their LAN interfaces might provide a = useful way to help cascaded routers understand that they are not at the = LAN boundary, and make it easier to create a working multicast = environment in a multi-router home network. >=20 > I guess this would need to be something for dhcwg and homenet to = consider, though.=20 border discovery is being worked on in homenet. cheers, Ole= From brian.e.carpenter@gmail.com Fri Feb 24 11:49:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE84321F85FB for ; Fri, 24 Feb 2012 11:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.509 X-Spam-Level: X-Spam-Status: No, score=-103.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OuNQl+ppPNA for ; Fri, 24 Feb 2012 11:49:26 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id EEA3121F854D for ; Fri, 24 Feb 2012 11:49:25 -0800 (PST) Received: by eekc41 with SMTP id c41so1103396eek.31 for ; Fri, 24 Feb 2012 11:49:25 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.194.136 as permitted sender) client-ip=10.14.194.136; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.194.136 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.14.194.136]) by 10.14.194.136 with SMTP id m8mr2219752een.97.1330112965194 (num_hops = 1); Fri, 24 Feb 2012 11:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BgUXzrh6gcCO29yX6l/ujDFQAslnW5tSzGZb0Uedbv8=; b=RZzm4SRHxdLcxU/CAMnxXnejJBS3OsAE8Scu8+gJxGYD9MrgujRlBdgefjNUcCEHo5 QN0w65SYBs8PVNVSCF/goh7i19unsA49LTmocIR1RC46L9QGD7ghqGJIaK1T4DYYK21D 8ZHOFb297ImNAyfUUwygp2SGQXreqHB60oU/0= Received: by 10.14.194.136 with SMTP id m8mr1668069een.97.1330112965097; Fri, 24 Feb 2012 11:49:25 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id w60sm21704518eeb.4.2012.02.24.11.49.20 (version=SSLv3 cipher=OTHER); Fri, 24 Feb 2012 11:49:24 -0800 (PST) Message-ID: <4F47E9B2.6070508@gmail.com> Date: Sat, 25 Feb 2012 08:49:06 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Rajiv Asati (rajiva)" References: <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net><18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com><93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net><4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com><867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com><3D40B569-062C-43DE-A059-69976FFFF7CB@nominum.com> <901586CA8F92D543BFFFD6E1122F5A3602733EFD0C97@HE101453.emea1.cds.t-internal.com> <067E6CE33034954AAC05C9EC85E2577C0778DE49@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0778DE49@XMB-RCD-111.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 19:49:26 -0000 On 2012-02-25 02:36, Rajiv Asati (rajiva) wrote: > Hi Christian , > >> described behaviour when I looked closly at it. During normal operation we >> had no major impact by using ULAs at home. Local network communication (I >> have localy delivered web and mail), if it uses IPv6, utilizes ULA. If the GUA > > What's causing them to prefer ULA for local communication when GUA is available? Longest match, since a ULA *is* a GUA. Brian From brian.e.carpenter@gmail.com Fri Feb 24 13:17:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6E021F8771 for ; Fri, 24 Feb 2012 13:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kR75arrAAYW for ; Fri, 24 Feb 2012 13:17:43 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 00A5221F876E for ; Fri, 24 Feb 2012 13:17:42 -0800 (PST) Received: by eekc41 with SMTP id c41so1133120eek.31 for ; Fri, 24 Feb 2012 13:17:42 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.124.211 as permitted sender) client-ip=10.14.124.211; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.124.211 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.14.124.211]) by 10.14.124.211 with SMTP id x59mr2447190eeh.51.1330118262291 (num_hops = 1); Fri, 24 Feb 2012 13:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wSf+n/aNIISHTESK/yolabV5mMCPBtuhMvUvH9GzH5Q=; b=QkAgxY45P7CJBGP40ukouNDrFGXb+DFDvOjwAIH+WjLTsgegsgXiPKTAKW/FWI97m5 a+BT4hT59qW5+h3YVbuJmGP9ygvNi2O/hRpedl/daCQZAmd56Ejeq4r7nDOoTnz/5wa+ ZglKWxp66dZH17evT0lhNwa0L37ulwmCzjiaA= Received: by 10.14.124.211 with SMTP id x59mr1825153eeh.51.1330118262130; Fri, 24 Feb 2012 13:17:42 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id r5sm10215605eef.6.2012.02.24.13.17.40 (version=SSLv3 cipher=OTHER); Fri, 24 Feb 2012 13:17:41 -0800 (PST) Message-ID: <4F47FE6E.7050905@gmail.com> Date: Sat, 25 Feb 2012 10:17:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> In-Reply-To: <4F32D59E.7080306@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 21:17:44 -0000 It seems from the lack of discussion that nobody in v6ops cares about server load balancers. I find this strange, since when I talk to enterprise operations folk, they always flag load balancers as one of the main holdups with supporting IPv6. The author's won't drop this draft, but unless the WG shows some sign of interest, we will take it elsewhere. Regards Brian On 2012-02-09 09:05, Brian E Carpenter wrote: > Every serious content provider runs load balancers. > > Missing IPv6 support in load balancers has been a delaying factor > for IPv6 deployment. > > This draft discusses the only aspect of IPv6 that seems to be > significantly different from IPv4: the flow label may enhance load > balancer efficiency. > > The authors suggest that the topic belongs in v6ops because it > potentially affects all large server operators, but calls for no > protocol changes. We'd like to know who agrees or disagrees. > > Regards > Brian Carpenter > > On 2012-01-30 11:33, Brian E Carpenter wrote: >> Hi, >> >> I'm not seeing more comments on this. The authors would like advice: >> >> Should we ask for v6ops to adopt this? >> Should we ask another WG to adopt it? >> Should we propose it as an individual submission? >> Should we forget about it? >> >> Regards >> Brian Carpenter >> >> On 2012-01-18 10:14, Brian E Carpenter wrote: >>> This is a significant update since the version discussed in Taipei, >>> with an additional author who is a practitioner in the field, >>> and incorporating comments from implementors. >>> >>> Of course we would like more feedback. For the moment I suggest >>> discussion on the v6ops list, although that may not be the >>> final home for this draft. >>> >>> Please keep Willy on CC since I'm not sure he's on this list. >>> >>> Brian Carpenter >>> >>> -------- Original Message -------- >>> Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt >>> Date: Tue, 17 Jan 2012 12:40:05 -0800 >>> From: internet-drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> Title : Using the IPv6 Flow Label for Server Load Balancing >>> Author(s) : Brian Carpenter >>> Sheng Jiang >>> Willy Tarreau >>> Filename : draft-carpenter-v6ops-label-balance-01.txt >>> Pages : 12 >>> Date : 2012-01-17 >>> >>> This document describes how the IPv6 flow label can be used in >>> support of layer 3/4 load distribution and balancing for large server >>> farms. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>> >>> _______________________________________________ >>> 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 jhw@apple.com Fri Feb 24 13:45:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F22E21F8716 for ; Fri, 24 Feb 2012 13:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.234 X-Spam-Level: X-Spam-Status: No, score=-110.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOuWZzqXRnKM for ; Fri, 24 Feb 2012 13:45:26 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3013721F86E2 for ; Fri, 24 Feb 2012 13:45:25 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0LZX00EA332FPCW1@mail-out.apple.com> for v6ops@ietf.org; Fri, 24 Feb 2012 13:44:52 -0800 (PST) X-AuditID: 11807137-b7c3dae000000e05-7f-4f4804d48aef Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 43.FA.03589.4D4084F4; Fri, 24 Feb 2012 13:44:52 -0800 (PST) From: james woodyatt In-reply-to: <4F47FE6E.7050905@gmail.com> Date: Fri, 24 Feb 2012 13:44:52 -0800 Message-id: References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1426) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42IRPMjroHuFxcPf4ONNQ4vTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY03TM9aCRraKjq13mRsY77N0MXJySAiYSEye9oYNwhaTuHBv PZDNxSEkMJtJYt76A4wgCWYBLYkb/14ygdi8AnoSTZcPg9nCAhkSJ88sAqthE1CR+Hb5Llic U0BTYuXcC2BDWQRUJS59n8MGMUdbYtnC18wQc2wklt9/CtTLAbSsXuL5mRKQsAjQmCln7kPd IytxaMZKxgmMfLOQXDELyRWzkExdwMi8ilGwKDUnsdLQTC+xoCAnVS85P3cTIyiQGgrNdzBu /yt3iFGAg1GJhzdym7u/EGtiWXFl7iFGCQ5mJRFew49AId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4rxf81z9hQTSE0tSs1NTC1KLYLJMHJxSDYyiB1p2tUi+PnlshfvnElmTbVM3ue0IqDkt/fXm dX/ZWxMPp3IXGYbNaBE//XjahUda/ySfrJly1WOt/vWGDPusY7xiXQ6Jx6+K3g2TLrqnfszg osC6v83LtJw1rGIMV77d1OsSvdi1ceZKN9cfu/cq1Xf9fHgqc7Ljvffnj1XFs1qHLa1aUpaq xFKckWioxVxUnAgAlhcBViACAAA= Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 21:45:27 -0000 On Feb 24, 2012, at 13:17 , Brian E Carpenter wrote: > > The author's won't drop this draft, but unless the WG shows some sign of interest, we will take it elsewhere. I'm boggled too. Anyway, I read the draft between compiles. Some comments... -- Page 3, in the list of techniques for redirecting traffic to target servers, this would be a good place to mention NPTv6 as an alternative to NAPT66, if not *instead* of NAPT66. -- Three-way FTP is worth mentioning in section 3. I have no opinion about where this draft belongs, and will defer to those with more experience in relevant operational environments. -- james woodyatt member of technical staff, core os networking From fgont@si6networks.com Fri Feb 24 17:28:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1942911E8074 for ; Fri, 24 Feb 2012 17:28:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-RcqFcXh+sE for ; Fri, 24 Feb 2012 17:28:23 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 39D9E11E8072 for ; Fri, 24 Feb 2012 17:28:23 -0800 (PST) Received: from [190.48.234.9] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S16Qm-0000xs-Rz; Sat, 25 Feb 2012 02:28:16 +0100 Message-ID: <4F48390F.10900@si6networks.com> Date: Fri, 24 Feb 2012 22:27:43 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Ray Hunter References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F4286A0.6040203@globis.net> <4F4712D2.4050202@si6networks.com> <4F47C6E6.9040609@globis.net> In-Reply-To: <4F47C6E6.9040609@globis.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 01:28:24 -0000 Hi, Ray, On 02/24/2012 02:20 PM, Ray Hunter wrote: > The problem is as you state: "Therefore, it is impossible for a device > processing only the second fragment to locate the ICMPv6 header > contained in that fragment, since it is unknown how many bytes should be > "skipped" to get to the next header following the Destination Options > Header." > > What if this uncertainty could be removed, and the amount to be skipped > in subsequent frames was always zero, at least until the ICMPv6 RA or > other ND message was encountered and identified? Not sure what this would mean... forbidding the use of IPv6 Extension Headers with ND packets, or something else? (if that's what you're proposing, please see: draft-gont-6man-nd-extension-headers). In any case, RA-Guard should be able to mitigate RA-based attacks, with *current* implementations. So while that effort is worth pursuing, it would not be an alternative for the current RA-Guard implementation advice. > So rather than banning fragments altogether for certain traffic, or > insisting that the complete header chain resides in the first frame, why > not specify that fragmentation should always occur at a convenient point > so that the header chain can always be followed at L2 filters, even for > individual frames in a fragmented packet, and thus ensure layer 2 > filtering or firewall mechanisms cannot be bypassed by "cloaking" via > oversized headers? Not sure what you mean by "convenient point". That aside, banning fragmentation for ND traffic is a good thing, since it enables ND-monitoring similar to that performed by arpwatch in the IPv4 world (i.e., feature-parity). > Wouldn't that be as straight forward as saying individual option headers > shouldn't be fragmented across multiple frames when transmitting RA, ND > or other critical messages that are likely to be filtered at L2? If you still allow fragmentation, it becomes virtually impossible to monitor ND traffic -- no matter *how* you fragment. > That seems like a much less onerous restriction than the two previously > proposed of either banning fragmentation altogether or limiting the > total option header length to one frame. What's the difference between requiring the entire IPv6 header chain to be prsent in the first fragment, and what you're proposing? 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 Fri Feb 24 18:40:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0A721E8041; Fri, 24 Feb 2012 18:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onMy9MmVB3Au; Fri, 24 Feb 2012 18:40:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666A121E8033; Fri, 24 Feb 2012 18:40:17 -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 X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120225024017.28511.17798.idtracker@ietfa.amsl.com> Date: Fri, 24 Feb 2012 18:40:17 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ivi-icmp-address-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 02:40:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Stateless Source Address Mapping for ICMPv6 Packets Author(s) : Xing Li Congxiao Bao Dan Wing Ramji Vaithianathan Geoff Huston Filename : draft-ietf-v6ops-ivi-icmp-address-01.txt Pages : 8 Date : 2012-02-24 A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source that should be passed across the translator as an ICMP packet directed to the the IPv4-translatable destination. This document discusses the considerations and presents a stateless address mapping algorithm for source address translation in ICMPv6 headers for such cases. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ivi-icmp-address-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ivi-icmp-address-01.txt From xing@cernet.edu.cn Fri Feb 24 18:47:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918D521E803D for ; Fri, 24 Feb 2012 18:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVrEWfQd3RGQ for ; Fri, 24 Feb 2012 18:47:27 -0800 (PST) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 530E121E803A for ; Fri, 24 Feb 2012 18:47:19 -0800 (PST) Received: from [127.0.0.1] (unknown [59.66.24.109]) by centos (Coremail) with SMTP id AQAAf3A7ywkTS0hPkzYNAA--.56610S2; Sat, 25 Feb 2012 10:44:35 +0800 (CST) Message-ID: <4F484BB1.1020005@cernet.edu.cn> Date: Sat, 25 Feb 2012 10:47:13 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20120225024017.28511.17798.idtracker@ietfa.amsl.com> In-Reply-To: <20120225024017.28511.17798.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3A7ywkTS0hPkzYNAA--.56610S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tF43uFyfWF1xZF1DGw4kZwb_yoW8AF4rpa yDG3y3Ka18Jw18G397Xr10vw4kZF95C3yUCF43KwnFkas8JF1Iqr1jkry3ArWDtF95Gw18 Jr4Duw15WanavrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUSCb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28EF7xvwVC0I7IYx2 IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwA2z4x0Y4vEx4A2 jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1le2I262IYc4 CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0Ex4A2jsIE14v26r1j 6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY4 87MxkIecxEwVAFwVW8JwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I 3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxkGc2Ij64vIr41lIx AIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvE x4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07j0oGQUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ivi-icmp-address-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 02:47:28 -0000 Hi, All, According to the comments received from the mailing-list and in the Taipei meeting, we have updated draft-ietf-v6ops-ivi-icmp-address. The major changes are: (1) Add RFC5837 requirements for identify the source IPv6 address in ICMP. (2) Only propose hop count mapping algorithm. (3) Add filtering and rate-limiting recommendations. Regards, xing 于 2012/2/25 10:40, internet-drafts@ietf.org 写é“: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Stateless Source Address Mapping for ICMPv6 Packets > Author(s) : Xing Li > Congxiao Bao > Dan Wing > Ramji Vaithianathan > Geoff Huston > Filename : draft-ietf-v6ops-ivi-icmp-address-01.txt > Pages : 8 > Date : 2012-02-24 > > A stateless IPv4/IPv6 translator may receive ICMPv6 packets > containing non IPv4-translatable addresses as the source that should > be passed across the translator as an ICMP packet directed to the the > IPv4-translatable destination. This document discusses the > considerations and presents a stateless address mapping algorithm for > source address translation in ICMPv6 headers for such cases. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ivi-icmp-address-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ivi-icmp-address-01.txt > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From v6ops@globis.net Sat Feb 25 01:00:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25AD21F85F1 for ; Sat, 25 Feb 2012 01:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLniFj-oD6WM for ; Sat, 25 Feb 2012 01:00:46 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C02521F8573 for ; Sat, 25 Feb 2012 01:00:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 045A487007D; Sat, 25 Feb 2012 10:00:45 +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 ZomcFjaXrOjC; Sat, 25 Feb 2012 10:00:34 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 90D8B87002E; Sat, 25 Feb 2012 10:00:34 +0100 (CET) Message-ID: <4F48A332.7040204@globis.net> Date: Sat, 25 Feb 2012 10:00:34 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Fernando Gont References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F4286A0.6040203@globis.net> <4F4712D2.4050202@si6networks.com> <4F47C6E6.9040609@globis.net> <4F48390F.10900@si6networks.com> In-Reply-To: <4F48390F.10900@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 09:00:47 -0000 If the base requirement for RA Guard is that is has to protect all *current* end node implementations then you are absolutely right, and there's little option but to drop all un-parseable fragments as a default rule. However, it should be noted in the ID what adverse effects this default drop rule could have on filtering legitimate traffic via false positives (however obscure we think the need for that traffic might be), because this filter would potentially be much broader than just RA, and people deploying RA Guard need to be properly informed of the potential negative consequences in advance. Thanks RayH Fernando Gont wrote: > Hi, Ray, > > > > In any case, RA-Guard should be able to mitigate RA-based attacks, with > *current* implementations. So while that effort is worth pursuing, it > would not be an alternative for the current RA-Guard implementation advice. > From joelja@bogus.com Sat Feb 25 01:34:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8454521F85A0 for ; Sat, 25 Feb 2012 01:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.303 X-Spam-Level: X-Spam-Status: No, score=-102.303 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gfd3ZFD4u2od for ; Sat, 25 Feb 2012 01:34:44 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EDD2B21F859B for ; Sat, 25 Feb 2012 01:34:43 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q1P9Yftn008103 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 25 Feb 2012 09:34:42 GMT (envelope-from joelja@bogus.com) Message-ID: <4F48AB30.7060109@bogus.com> Date: Sat, 25 Feb 2012 01:34:40 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> In-Reply-To: <4F47FE6E.7050905@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 25 Feb 2012 09:34:42 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 09:34:44 -0000 On 2/24/12 13:17 , Brian E Carpenter wrote: > It seems from the lack of discussion that nobody in v6ops cares > about server load balancers. I find this strange, since when > I talk to enterprise operations folk, they always flag load > balancers as one of the main holdups with supporting IPv6. I doubt that very much... Every load balancer platform that I have access too today has some level ipv6 support. f5 a10 netscalar, along with ha-proxy and nginx are all in the field providing production level ipv6 traffic delivery. I would think given the topic that the involvement of the flow label is implicated the in lack of excitement. > The author's won't drop this draft, but unless the WG shows > some sign of interest, we will take it elsewhere. > > Regards > Brian > > On 2012-02-09 09:05, Brian E Carpenter wrote: >> Every serious content provider runs load balancers. >> >> Missing IPv6 support in load balancers has been a delaying factor >> for IPv6 deployment. >> >> This draft discusses the only aspect of IPv6 that seems to be >> significantly different from IPv4: the flow label may enhance load >> balancer efficiency. >> >> The authors suggest that the topic belongs in v6ops because it >> potentially affects all large server operators, but calls for no >> protocol changes. We'd like to know who agrees or disagrees. >> >> Regards >> Brian Carpenter >> >> On 2012-01-30 11:33, Brian E Carpenter wrote: >>> Hi, >>> >>> I'm not seeing more comments on this. The authors would like advice: >>> >>> Should we ask for v6ops to adopt this? >>> Should we ask another WG to adopt it? >>> Should we propose it as an individual submission? >>> Should we forget about it? >>> >>> Regards >>> Brian Carpenter >>> >>> On 2012-01-18 10:14, Brian E Carpenter wrote: >>>> This is a significant update since the version discussed in Taipei, >>>> with an additional author who is a practitioner in the field, >>>> and incorporating comments from implementors. >>>> >>>> Of course we would like more feedback. For the moment I suggest >>>> discussion on the v6ops list, although that may not be the >>>> final home for this draft. >>>> >>>> Please keep Willy on CC since I'm not sure he's on this list. >>>> >>>> Brian Carpenter >>>> >>>> -------- Original Message -------- >>>> Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt >>>> Date: Tue, 17 Jan 2012 12:40:05 -0800 >>>> From: internet-drafts@ietf.org >>>> Reply-To: internet-drafts@ietf.org >>>> To: i-d-announce@ietf.org >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> >>>> Title : Using the IPv6 Flow Label for Server Load Balancing >>>> Author(s) : Brian Carpenter >>>> Sheng Jiang >>>> Willy Tarreau >>>> Filename : draft-carpenter-v6ops-label-balance-01.txt >>>> Pages : 12 >>>> Date : 2012-01-17 >>>> >>>> This document describes how the IPv6 flow label can be used in >>>> support of layer 3/4 load distribution and balancing for large server >>>> farms. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> This Internet-Draft can be retrieved at: >>>> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fgont@si6networks.com Sat Feb 25 08:34:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B7121F850C for ; Sat, 25 Feb 2012 08:34:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vWX-JgNI2uL for ; Sat, 25 Feb 2012 08:34:39 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7957121F851A for ; Sat, 25 Feb 2012 08:34:39 -0800 (PST) Received: from [190.48.211.141] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S1KZq-0000OV-7l; Sat, 25 Feb 2012 17:34:30 +0100 Message-ID: <4F490D68.4030107@si6networks.com> Date: Sat, 25 Feb 2012 13:33:44 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Ray Hunter References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F4286A0.6040203@globis.net> <4F4712D2.4050202@si6networks.com> <4F47C6E6.9040609@globis.net> <4F48390F.10900@si6networks.com> <4F48A332.7040204@globis.net> In-Reply-To: <4F48A332.7040204@globis.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 16:34:40 -0000 Hi, Ray, On 02/25/2012 06:00 AM, Ray Hunter wrote: > If the base requirement for RA Guard is that is has to protect all > *current* end node implementations then you are absolutely right, and > there's little option but to drop all un-parseable fragments as a > default rule. Agreed. > However, it should be noted in the ID what adverse effects > this default drop rule could have on filtering legitimate traffic via > false positives (however obscure we think the need for that traffic > might be), How about adding something like this below the filtering rules: "The aforementioned filtering rules require an RA-Guard implementation to inspect, in the case of fragments that do not contain the entire IPv6 header chain, the Source Address and the Hop Limit of the packet. This is meant to reduce false positives that could arise if some legitimate packets failed to include the entire IPv6 header chain. In any case, as noted in [draft-gont-6man-oversized-header-chain], such packets are nevertheless unlikely to survive in real networks, since (while currently legitimate from a specifications standpoint) the are non-sensical and are virtually impossible to police with state-less filters (hence likely to be blocked by such filters)." > because this filter would potentially be much broader than > just RA, Not sure what you mean... > and people deploying RA Guard need to be properly informed of > the potential negative consequences in advance. Agreed. Please let me know if the above would work, or whether I should tweak the text a bit. 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 brian.e.carpenter@gmail.com Sat Feb 25 10:29:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDFF21F84E2 for ; Sat, 25 Feb 2012 10:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHftqGe71+s7 for ; Sat, 25 Feb 2012 10:29:34 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id ACAA221F848F for ; Sat, 25 Feb 2012 10:29:33 -0800 (PST) Received: by eaal12 with SMTP id l12so1446920eaa.31 for ; Sat, 25 Feb 2012 10:29:32 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.28.142 as permitted sender) client-ip=10.14.28.142; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.28.142 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.14.28.142]) by 10.14.28.142 with SMTP id g14mr4234113eea.86.1330194572859 (num_hops = 1); Sat, 25 Feb 2012 10:29:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=r123ryj+ukgPFQRabYlAZch+1BPge3AYeZt+FIjh6XQ=; b=JxuvtuIwdsu2iFn5hztrkwG8M8GEYUvTzIW+deujxVPTYZeVC+GCCCNdLPUb+kjbZa ylculU/r9a9ZjsY/Ji2oR7gQYUkZ/foJtON58afGZ0vJ7KohtD9oYGOuhWKo4YqCNDKV CNZn8vf+Nu45+OfF0V+4Q9UE6pEE8OWoKRyDg= Received: by 10.14.28.142 with SMTP id g14mr3168171eea.86.1330194572682; Sat, 25 Feb 2012 10:29:32 -0800 (PST) Received: from [10.1.1.3] ([121.98.251.219]) by mx.google.com with ESMTPS id a58sm34544203eeb.8.2012.02.25.10.29.29 (version=SSLv3 cipher=OTHER); Sat, 25 Feb 2012 10:29:32 -0800 (PST) Message-ID: <4F492882.4020800@gmail.com> Date: Sun, 26 Feb 2012 07:29:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel jaeggli References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> In-Reply-To: <4F48AB30.7060109@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 18:29:35 -0000 "some level [of] ipv6 support" I can assure you that this is only just filtering out to the more remote ends of the Internet, but I agree that it's happening. However, this draft looks a little beyond current practice. Regards Brian On 2012-02-25 22:34, Joel jaeggli wrote: > On 2/24/12 13:17 , Brian E Carpenter wrote: >> It seems from the lack of discussion that nobody in v6ops cares >> about server load balancers. I find this strange, since when >> I talk to enterprise operations folk, they always flag load >> balancers as one of the main holdups with supporting IPv6. > > I doubt that very much... > > Every load balancer platform that I have access too today has some level > ipv6 support. f5 a10 netscalar, along with ha-proxy and nginx are all in > the field providing production level ipv6 traffic delivery. > > I would think given the topic that the involvement of the flow label is > implicated the in lack of excitement. > >> The author's won't drop this draft, but unless the WG shows >> some sign of interest, we will take it elsewhere. >> >> Regards >> Brian >> >> On 2012-02-09 09:05, Brian E Carpenter wrote: >>> Every serious content provider runs load balancers. >>> >>> Missing IPv6 support in load balancers has been a delaying factor >>> for IPv6 deployment. >>> >>> This draft discusses the only aspect of IPv6 that seems to be >>> significantly different from IPv4: the flow label may enhance load >>> balancer efficiency. >>> >>> The authors suggest that the topic belongs in v6ops because it >>> potentially affects all large server operators, but calls for no >>> protocol changes. We'd like to know who agrees or disagrees. >>> >>> Regards >>> Brian Carpenter >>> >>> On 2012-01-30 11:33, Brian E Carpenter wrote: >>>> Hi, >>>> >>>> I'm not seeing more comments on this. The authors would like advice: >>>> >>>> Should we ask for v6ops to adopt this? >>>> Should we ask another WG to adopt it? >>>> Should we propose it as an individual submission? >>>> Should we forget about it? >>>> >>>> Regards >>>> Brian Carpenter >>>> >>>> On 2012-01-18 10:14, Brian E Carpenter wrote: >>>>> This is a significant update since the version discussed in Taipei, >>>>> with an additional author who is a practitioner in the field, >>>>> and incorporating comments from implementors. >>>>> >>>>> Of course we would like more feedback. For the moment I suggest >>>>> discussion on the v6ops list, although that may not be the >>>>> final home for this draft. >>>>> >>>>> Please keep Willy on CC since I'm not sure he's on this list. >>>>> >>>>> Brian Carpenter >>>>> >>>>> -------- Original Message -------- >>>>> Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt >>>>> Date: Tue, 17 Jan 2012 12:40:05 -0800 >>>>> From: internet-drafts@ietf.org >>>>> Reply-To: internet-drafts@ietf.org >>>>> To: i-d-announce@ietf.org >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>> >>>>> Title : Using the IPv6 Flow Label for Server Load Balancing >>>>> Author(s) : Brian Carpenter >>>>> Sheng Jiang >>>>> Willy Tarreau >>>>> Filename : draft-carpenter-v6ops-label-balance-01.txt >>>>> Pages : 12 >>>>> Date : 2012-01-17 >>>>> >>>>> This document describes how the IPv6 flow label can be used in >>>>> support of layer 3/4 load distribution and balancing for large server >>>>> farms. >>>>> >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> This Internet-Draft can be retrieved at: >>>>> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > From joelja@bogus.com Sat Feb 25 11:15:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9262A21F8518 for ; Sat, 25 Feb 2012 11:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.887 X-Spam-Level: X-Spam-Status: No, score=-101.887 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QX7VuotDJGaw for ; Sat, 25 Feb 2012 11:15:16 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B2F4D21F84F5 for ; Sat, 25 Feb 2012 11:15:16 -0800 (PST) Received: from Joels-MacBook-Pro.local (183.sub-166-250-33.myvzw.com [166.250.33.183]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q1PJFEXs017905 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 25 Feb 2012 19:15:14 GMT (envelope-from joelja@bogus.com) Message-ID: <4F49333B.8090306@bogus.com> Date: Sat, 25 Feb 2012 11:15:07 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> <4F492882.4020800@gmail.com> In-Reply-To: <4F492882.4020800@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 25 Feb 2012 19:15:15 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 19:15:17 -0000 On 2/25/12 10:29 , Brian E Carpenter wrote: > "some level [of] ipv6 support" I'm going to be provocative since I've had my third cup of coffee this morning. An f5 which is a complex appliance has a rather different feature set that nginx which is a http/pop/imap alg that runs on an off-the-shelf linux box. I'm missing features on the f5 like layer3 ecmp routes with ipv6 bgp sessions, that's kinda far down in the weeds feature parity-wise compared to, "can I use it for l4 proxy or l7 session termination, can I hash connections across LBs" which it does fine. The question with rehabilitating the flow label for use with load balancers is imho orthagional to the question of feature parity with ipv4 load balancers. 3697 behavior I imagine still dominates, which implies that if I myself am rewriting the flow label for my own purposes that I'm doing so on the basis of other criterion (for example the 5 tuple, class of service, origin interface, evil bit etc) which means I could just as well make the lb decision on that basis as well. My reading of 6346 is that I'm now more or less free to do what I want with the flow label, and I have access to hardware forwarding platforms that can rewrite anything in the first 256 bytes of a packet at line rate, so hey, like with DSCP bits in ipv4 if I'm going to the use them for my own purpose the first thing I'll do is rewrite every externally set value on ingress because I can't trust them. What could I do with 20 bits that the routers can ignore and that doesn't require a new header? The flow label is big enough bit field to do this in spades: http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf in fact it more bits than I've ever had to hack about with in an ip header, so hey go crazy. joel > I can assure you that this is only just filtering out to > the more remote ends of the Internet, but I agree that it's > happening. However, this draft looks a little beyond current > practice. > > Regards > Brian > > On 2012-02-25 22:34, Joel jaeggli wrote: >> On 2/24/12 13:17 , Brian E Carpenter wrote: >>> It seems from the lack of discussion that nobody in v6ops cares >>> about server load balancers. I find this strange, since when >>> I talk to enterprise operations folk, they always flag load >>> balancers as one of the main holdups with supporting IPv6. >> >> I doubt that very much... >> >> Every load balancer platform that I have access too today has some level >> ipv6 support. f5 a10 netscalar, along with ha-proxy and nginx are all in >> the field providing production level ipv6 traffic delivery. >> >> I would think given the topic that the involvement of the flow label is >> implicated the in lack of excitement. >> >>> The author's won't drop this draft, but unless the WG shows >>> some sign of interest, we will take it elsewhere. >>> >>> Regards >>> Brian >>> >>> On 2012-02-09 09:05, Brian E Carpenter wrote: >>>> Every serious content provider runs load balancers. >>>> >>>> Missing IPv6 support in load balancers has been a delaying factor >>>> for IPv6 deployment. >>>> >>>> This draft discusses the only aspect of IPv6 that seems to be >>>> significantly different from IPv4: the flow label may enhance load >>>> balancer efficiency. >>>> >>>> The authors suggest that the topic belongs in v6ops because it >>>> potentially affects all large server operators, but calls for no >>>> protocol changes. We'd like to know who agrees or disagrees. >>>> >>>> Regards >>>> Brian Carpenter >>>> >>>> On 2012-01-30 11:33, Brian E Carpenter wrote: >>>>> Hi, >>>>> >>>>> I'm not seeing more comments on this. The authors would like advice: >>>>> >>>>> Should we ask for v6ops to adopt this? >>>>> Should we ask another WG to adopt it? >>>>> Should we propose it as an individual submission? >>>>> Should we forget about it? >>>>> >>>>> Regards >>>>> Brian Carpenter >>>>> >>>>> On 2012-01-18 10:14, Brian E Carpenter wrote: >>>>>> This is a significant update since the version discussed in Taipei, >>>>>> with an additional author who is a practitioner in the field, >>>>>> and incorporating comments from implementors. >>>>>> >>>>>> Of course we would like more feedback. For the moment I suggest >>>>>> discussion on the v6ops list, although that may not be the >>>>>> final home for this draft. >>>>>> >>>>>> Please keep Willy on CC since I'm not sure he's on this list. >>>>>> >>>>>> Brian Carpenter >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt >>>>>> Date: Tue, 17 Jan 2012 12:40:05 -0800 >>>>>> From: internet-drafts@ietf.org >>>>>> Reply-To: internet-drafts@ietf.org >>>>>> To: i-d-announce@ietf.org >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>> >>>>>> Title : Using the IPv6 Flow Label for Server Load Balancing >>>>>> Author(s) : Brian Carpenter >>>>>> Sheng Jiang >>>>>> Willy Tarreau >>>>>> Filename : draft-carpenter-v6ops-label-balance-01.txt >>>>>> Pages : 12 >>>>>> Date : 2012-01-17 >>>>>> >>>>>> This document describes how the IPv6 flow label can be used in >>>>>> support of layer 3/4 load distribution and balancing for large server >>>>>> farms. >>>>>> >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> This Internet-Draft can be retrieved at: >>>>>> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>>> >>>>>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> > From victor.kuarsingh@gmail.com Sat Feb 25 18:47:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EAB21F8552 for ; Sat, 25 Feb 2012 18:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWy8C7nBQwqb for ; Sat, 25 Feb 2012 18:47:38 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 049AF21F854B for ; Sat, 25 Feb 2012 18:47:37 -0800 (PST) Received: by iagf6 with SMTP id f6so5841214iag.31 for ; Sat, 25 Feb 2012 18:47:37 -0800 (PST) Received-SPF: pass (google.com: domain of victor.kuarsingh@gmail.com designates 10.43.117.135 as permitted sender) client-ip=10.43.117.135; Authentication-Results: mr.google.com; spf=pass (google.com: domain of victor.kuarsingh@gmail.com designates 10.43.117.135 as permitted sender) smtp.mail=victor.kuarsingh@gmail.com; dkim=pass header.i=victor.kuarsingh@gmail.com Received: from mr.google.com ([10.43.117.135]) by 10.43.117.135 with SMTP id fm7mr5821334icc.29.1330224457737 (num_hops = 1); Sat, 25 Feb 2012 18:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=QETtDDTa+1agaRMy0KF9FpLr6vIi9JBng9daNRSufkY=; b=lfvlZqadJL18BTt+zod9vraG51eFPlcJ0gN4TTp3ngCk9t+mLBM/vmyTmMPgcgv0fS VF9qwqUNB5nvnOwldJ44yrDcWOa6OffJsHkbiaJSc+xm2pyMEQcOn+xuzCFROnAp+wCZ DDZtTnyeqs14wQRHXpkgf+TXbLThayawmY1lc= Received: by 10.43.117.135 with SMTP id fm7mr4795567icc.29.1330224457695; Sat, 25 Feb 2012 18:47:37 -0800 (PST) Received: from [192.168.100.89] ([67.224.83.162]) by mx.google.com with ESMTPS id vr4sm6417862igb.1.2012.02.25.18.47.36 (version=SSLv3 cipher=OTHER); Sat, 25 Feb 2012 18:47:37 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sat, 25 Feb 2012 21:47:36 -0500 From: Victor Kuarsingh To: Message-ID: Thread-Topic: Updated Feedback on Wireline Incremental IPv6 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3413051258_24665563" Subject: [v6ops] Updated Feedback on Wireline Incremental IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2012 02:47:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3413051258_24665563 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable V6ops team, A new version of "draft-ietf-v6ops-wireline-incremental-ipv6-01" has been posted including feedback from the group. This version has some textual improvements and has made the following changes. 1. We have removed some language which focused on the IPv4 connectivity phenomenon (we did not remove all, but some). The focus of this document i= s about IPv6 introduction and evolution. This is also based on other discussions such as the Intarea meeting in Taipei (ref - http://www.ietf.org/proceedings/82/intarea.html) 2. The third phase is no longer called tunnelled IPv4, but IPv6-only. This phase would include tunnelled mode IPv4 if required (I.e. DS-LITE) I would like WG feedback if the refined focus (which is based on comments on/off list) is in line with how the WG thinks this document should proceed= . As well, I would also like feedback on the inclusion/exclusion of the following technologies in phase 3. 1. NAT64. Although this mode of operation will be difficult in the foreseeable future (on it's own) in a Wireline network due to the massive amounts of iPv4 equipment in the environment, it may be of consideration to some wireline providers. 2. Also, should we include discussion on 464 xlate (draft-ietf-v6ops-464xlat-00) framework/architecture. Although the documen= t is focused on "commercially available" technology, it appears that the technology for the 464 xlate is available (CLAT via some beta code and NAT6= 4 is out there) I would like to build in comments in the next rev =AD02. In that rev, there will also be additional considerations discussion/information based on some additional input which is coming now. Regards, Victor K --B_3413051258_24665563 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
V6ops team,

A new version of "draft-ietf-v6ops-wireline-incremental-ipv6-01" ha= s been posted including feedback from the group.  This version has some= textual improvements and has made the following changes.

  1. We have removed some language which focused on the IPv4 connectivi= ty phenomenon (we did not remove all, but some).  The focus of this doc= ument is about IPv6 introduction and evolution.  This is also based on = other discussions such as the Intarea meeting in Taipei (ref - http://w= ww.ietf.org/proceedings/82/intarea.html)
  2. The third phase is no longe= r called tunnelled IPv4, but IPv6-only.  This phase would include tunne= lled mode IPv4 if required (I.e. DS-LITE)
I would like WG feed= back if the refined focus (which is based on comments on/off list) is in lin= e with how the WG thinks this document should proceed.  As well, I woul= d also like feedback on the inclusion/exclusion of the following technologie= s in phase 3.

  1. NAT64.  Although this mode of= operation will be difficult in the foreseeable future (on it's own) in a Wi= reline network due to the massive amounts of iPv4 equipment in the environme= nt, it may be of consideration to some wireline providers.
  2. Also, sho= uld we include discussion on 464 xlate (draft-ietf-v6ops-464xlat-00) framewo= rk/architecture.  Although the document is focused on "commercially ava= ilable" technology, it appears that the technology for the 464 xlate is avai= lable (CLAT via some beta code and NAT64 is out there)
I would= like to build in comments in the next rev –02.  In that rev, the= re will also be additional considerations discussion/information based on so= me additional input which is coming now.

Regards,

Victor K
--B_3413051258_24665563-- From v6ops@globis.net Sun Feb 26 02:48:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8E921F857D for ; Sun, 26 Feb 2012 02:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZAwmL9BLgNN for ; Sun, 26 Feb 2012 02:48:53 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3181021F8534 for ; Sun, 26 Feb 2012 02:48:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id AEA5A87007D; Sun, 26 Feb 2012 11:48:48 +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 XzswZLRYhJGC; Sun, 26 Feb 2012 11:48:42 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id B0A3987002E; Sun, 26 Feb 2012 11:48:42 +0100 (CET) Message-ID: <4F4A0E0A.6000806@globis.net> Date: Sun, 26 Feb 2012 11:48:42 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Fernando Gont References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F4286A0.6040203@globis.net> <4F4712D2.4050202@si6networks.com> <4F47C6E6.9040609@globis.net> <4F48390F.10900@si6networks.com> <4F48A332.7040204@globis.net> <4F490D68.4030107@si6networks.com> In-Reply-To: <4F490D68.4030107@si6networks.com> Content-Type: multipart/alternative; boundary="------------030902020008050209050408" Cc: draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2012 10:48:55 -0000 This is a multi-part message in MIME format. --------------030902020008050209050408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Humbly suggest making the text a bit more neutral, and leaving the debate about oversized headers for another day. Also the reason that a packet cannot be positively identified as RA or not might be the presence of headers split over fragments, but it could also be something else (that we haven't thought of yet). Suggested text: In order to protect current end-node IPv6 implementations, Rule 3 has been defined as a default rule to drop packets that cannot be positively identified as RA packets or not (perhaps due to the fact that it contains fragments that do not contain the entire IPv6 header chain). This introduces a chance that RA-Guard filtering could result in false-positive blocking of some legitimate non-RA packets that could not be positively identified as being non-RA. In order to reduce the likelihood of false positives, Rule 3 also requires that an RA-Guard implementation check before dropping an unidentifiable packet that it has an IPv6 Source Address that is a link-local address or the unspecified address (::), and the Hop Limit is 255 i.e. it is a packet that should not be forwarded by a router. In any case, as noted in [draft-gont-6man-oversized-header-chain], fragmented packets with oversized headers are anyway unlikely to survive in real networks. Whilst currently legitimate from a specifications standpoint, they are virtually impossible to police with state-less filters and firewalls, and are hence likely to be blocked by such filters and firewalls. Also two dumb questions as checks: What about packets including encryption? RFC4861 Section 3.3 and 11.2 still specifies that IPSec may be used to protect ND (and thus RA) Presume encrypted traffic offers no threat as there's protection at a higher layer via the security association. But is there any clarification text required in your draft to explicitly cover this? i.e. all encrypted traffic should be passed by RA-Guard, even though it cannot be positively identified as RA or not? Is there any need to further clarify how RA-Guard interacts with SeND? I don't think so, but thought I'd ask. regards, RayH Fernando Gont wrote: > Hi, Ray, > > On 02/25/2012 06:00 AM, Ray Hunter wrote: > >> If the base requirement for RA Guard is that is has to protect all >> *current* end node implementations then you are absolutely right, and >> there's little option but to drop all un-parseable fragments as a >> default rule. >> > > Agreed. > > > >> However, it should be noted in the ID what adverse effects >> this default drop rule could have on filtering legitimate traffic via >> false positives (however obscure we think the need for that traffic >> might be), >> > > How about adding something like this below the filtering rules: > > "The aforementioned filtering rules require an RA-Guard implementation > to inspect, in the case of fragments that do not contain the entire IPv6 > header chain, the Source Address and the Hop Limit of the packet. This > is meant to reduce false positives that could arise if some legitimate > packets failed to include the entire IPv6 header chain. In any case, as > noted in [draft-gont-6man-oversized-header-chain], such packets are > nevertheless unlikely to survive in real networks, since (while > currently legitimate from a specifications standpoint) the are > non-sensical and are virtually impossible to police with state-less > filters (hence likely to be blocked by such filters)." > > > >> because this filter would potentially be much broader than >> just RA, >> > > Not sure what you mean... > > > >> and people deploying RA Guard need to be properly informed of >> the potential negative consequences in advance. >> > > Agreed. Please let me know if the above would work, or whether I should > tweak the text a bit. > > Thanks so much! > > Best regards, > --------------030902020008050209050408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Humbly suggest making the text a bit more neutral, and leaving the debate about oversized headers for another day. Also the reason that a packet cannot be positively identified as RA or not might be the presence of headers split over fragments, but it could also be something else (that we haven't thought of yet).

Suggested text:

In order to protect current end-node IPv6 implementations, Rule 3 has been defined as a default rule to drop packets that cannot be positively identified as RA packets or not (perhaps due to the fact that it contains fragments that do not contain the entire IPv6
header chain). This introduces a chance that RA-Guard filtering could result in false-positive blocking of some legitimate non-RA packets that could not be positively identified as being non-RA. In order to reduce the likelihood of false positives, Rule 3 also requires that an RA-Guard implementation check before dropping an unidentifiable packet that it has an IPv6 Source Address that is a link-local address or the unspecified address (::), and the Hop Limit is 255 i.e. it is a packet that should not be forwarded by a router.

In any case, as noted in [draft-gont-6man-oversized-header-chain], fragmented packets with oversized headers are anyway unlikely to survive in real networks. Whilst currently legitimate from a specifications standpoint, they are virtually impossible to police with state-less filters and firewalls, and are hence likely to be blocked by such filters and firewalls.



Also two dumb questions as checks:

What about packets including encryption?

RFC4861 Section 3.3 and 11.2 still specifies that IPSec may be used to protect ND (and thus RA)
Presume encrypted traffic offers no threat as there's protection at a higher layer via the security association.
But is there any clarification text required in your draft to explicitly cover this?
i.e. all encrypted traffic should be passed by RA-Guard, even though it cannot be positively identified as RA or not?

Is there any need to further clarify how RA-Guard interacts with SeND?
I don't think so, but thought I'd ask.

regards,
RayH

Fernando Gont wrote: 
Hi, Ray,

On 02/25/2012 06:00 AM, Ray Hunter wrote:
  
If the base requirement for RA Guard is that is has to protect all
*current* end node implementations then you are absolutely right, and
there's little option but to drop all un-parseable fragments as a
default rule. 
    

Agreed.


  
However, it should be noted in the ID what adverse effects
this default drop rule could have on filtering legitimate traffic via
false positives (however obscure we think the need for that traffic
might be),
    

How about adding something like this below the filtering rules:

"The aforementioned filtering rules require an RA-Guard implementation
to inspect, in the case of fragments that do not contain the entire IPv6
header chain, the Source Address and the Hop Limit of the packet. This
is meant to reduce false positives that could arise if some legitimate
packets failed to include the entire IPv6 header chain. In any case, as
noted in [draft-gont-6man-oversized-header-chain], such packets are
nevertheless unlikely to survive in real networks, since (while
currently legitimate from a specifications standpoint) the are
non-sensical and are virtually impossible to police with state-less
filters (hence likely to be blocked by such filters)."


  
because this filter would potentially be much broader than
just RA, 
    

Not sure what you mean...


  
and people deploying RA Guard need to be properly informed of
the potential negative consequences in advance.
    

Agreed. Please let me know if the above would work, or whether I should
tweak the text a bit.

Thanks so much!

Best regards,

--------------030902020008050209050408-- From lorenzo@google.com Sun Feb 26 22:31:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0EA21F84DD for ; Sun, 26 Feb 2012 22:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.743 X-Spam-Level: X-Spam-Status: No, score=-102.743 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzGM0AULdQLk for ; Sun, 26 Feb 2012 22:31:34 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADC9C21F84DA for ; Sun, 26 Feb 2012 22:31:34 -0800 (PST) Received: by obbeh20 with SMTP id eh20so1109819obb.31 for ; Sun, 26 Feb 2012 22:31:34 -0800 (PST) Received-SPF: pass (google.com: domain of lorenzo@google.com designates 10.60.12.231 as permitted sender) client-ip=10.60.12.231; Authentication-Results: mr.google.com; spf=pass (google.com: domain of lorenzo@google.com designates 10.60.12.231 as permitted sender) smtp.mail=lorenzo@google.com; dkim=pass header.i=lorenzo@google.com Received: from mr.google.com ([10.60.12.231]) by 10.60.12.231 with SMTP id b7mr4504937oec.38.1330324294407 (num_hops = 1); Sun, 26 Feb 2012 22:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=o3np31UWq2GQ1mhaW/9DIJyaq/Zi6PT0YhO77Lcdmtk=; b=QofLfIwUmlyrzTRgZlRmJfGMcPK8IbxrKi7ukGB1WJ4B40QNn3wgoUjCWpGisOM1gc JXFTVVqCUgBEAFG14qy8BundSZih6GgiBVecB13g21ppbJ1hn93q9XYfkn6wbHUYeE/R uHKVpVFi/XGFTP3vUgSZAV5e9AnGv2VuMDlXE= Received: by 10.60.12.231 with SMTP id b7mr4030426oec.38.1330324294359; Sun, 26 Feb 2012 22:31:34 -0800 (PST) Received: by 10.60.12.231 with SMTP id b7mr4030416oec.38.1330324294245; Sun, 26 Feb 2012 22:31:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.5.67 with HTTP; Sun, 26 Feb 2012 22:31:14 -0800 (PST) In-Reply-To: References: <20120215011928.4651.7195.idtracker@ietfa.amsl.com> <20120215104232kawashimam@mail.jp.nec.com> From: Lorenzo Colitti Date: Mon, 27 Feb 2012 15:31:14 +0900 Message-ID: To: Cameron Byrne Content-Type: multipart/alternative; boundary=e89a8f83a47bfe9db704b9ec4255 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmH/vuCIl4BDYDvtFg8EisRnUcmQOpfpvzU0iPSTK+8PkED3GL3X60n4XCVjLpKOUeAHl5wSoPYrcC0+o4v4aa2lnRU2Kt2rLsvFmpWolpQ4kMib9BbOMU/sIql5VlO/WyHXRAt Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 06:31:35 -0000 --e89a8f83a47bfe9db704b9ec4255 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 24, 2012 at 21:37, Cameron Byrne wrote: > > It's true that an additional NAT44 does slightly degrade the quality of > IPv6 > > You mean degrade IPv4, right? In all cases IPv6 is end to end, no > compromises, right? > Yes, sorry. > > If you still have the test setup running, can you test with a /128 and > see > > if anything else breaks compared to having a /96? > > Well, for my case of 3GPP, it is only tethering that would be impacted > for scenarios where DNS64 is not effective (ie...IPv4 literals, ...) > on a tethered LAN. So, it is more of a corner case for me, but not a > corner case for others. > Actually, it's not a corner case. Your data says that most Android applications support IPv6, but we know that in many / most cases the tethered device will either run IPv4-only apps (e.g., Skype) or be completely IPv4-only (e.g., if it runs XP). So if you want 464xlat to be used on smartphones that support tethering, then it needs to provide IPv4 to tethered devices. On the plus side, tethering is already provided though an IPv4 NAT and is often behind a carrier operated NAT as well. I'd say that running IPv4-only tethered devices through NAT4464 (where the 6 is stateless) is not much worse than through NAT444. --e89a8f83a47bfe9db704b9ec4255 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 24, 2012 at 21:37, Cameron Byrne <cb.list6@gmail.com= > wrote:
> It's true that an additional NAT44 does slightly= degrade the quality of IPv6

You mean degrade IPv4, right? =A0In all cases IPv6 is end to end, no<= br> compromises, right?

Yes, sorry.
=A0
> If you still have the test setup running, can you te= st with a /128 and see
> if anything else breaks compared to having a /96?

Well, for my case of 3GPP, it is only tethering that would be impacte= d
for scenarios where DNS64 is not effective (ie...IPv4 literals, ...)
on a tethered LAN. =A0So, it is more of a corner case for me, but not a
corner case for others.

Actually, it= 9;s not a corner case. Your data says that most Android applications suppor= t IPv6, but we know that in many / most cases the tethered device will eith= er run IPv4-only apps (e.g., Skype) or be completely IPv4-only (e.g., if it= runs XP).=A0So if you want 464xlat to be used on smartphones that support = tethering, then it needs to provide IPv4 to tethered devices.

On the plus side, tethering is already provided though = an IPv4 NAT and is often behind a carrier operated NAT as well. I'd say= that running IPv4-only tethered devices through NAT4464 (where the 6 is st= ateless) is not much worse than through NAT444.
--e89a8f83a47bfe9db704b9ec4255-- From randy@psg.com Mon Feb 27 01:45:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFDED21F853D for ; Mon, 27 Feb 2012 01:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xn0uPWZdC0Zr for ; Mon, 27 Feb 2012 01:45:17 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C513921F8522 for ; Mon, 27 Feb 2012 01:45:15 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S1x8s-000Hxf-CM; Mon, 27 Feb 2012 09:45:15 +0000 Date: Mon, 27 Feb 2012 15:15:11 +0530 Message-ID: From: Randy Bush To: Joel jaeggli In-Reply-To: <4F48AB30.7060109@bogus.com> References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.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.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 09:45:22 -0000 > Every load balancer platform that I have access too today has some > level ipv6 support. f5 a10 netscalar, along with ha-proxy and nginx > are all in the field providing production level ipv6 traffic delivery. > > I would think given the topic that the involvement of the flow label is > implicated the in lack of excitement. what is a 'flow label'? randy From nick@inex.ie Mon Feb 27 02:10:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A8121F85EE for ; Mon, 27 Feb 2012 02:09:59 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I0Zx1siWy70 for ; Mon, 27 Feb 2012 02:09:56 -0800 (PST) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF5521F85E7 for ; Mon, 27 Feb 2012 02:09:54 -0800 (PST) X-Envelope-To: Received: from cupcake.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q1RAATMv010434 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2012 10:10:30 GMT (envelope-from nick@inex.ie) Message-ID: <4F4B566E.3050901@inex.ie> Date: Mon, 27 Feb 2012 10:09:50 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> In-Reply-To: X-Enigmail-Version: 1.3.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 10:10:00 -0000 On 27/02/2012 09:45, Randy Bush wrote: > what is a 'flow label'? ok, i'll humour you: it's bits 13 to 32 of the standard ipv6 header. But you already know this and we all know you know this, so what point are you making? Nick From randy@psg.com Mon Feb 27 02:43:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C417D21F865E for ; Mon, 27 Feb 2012 02:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZMKWRM7BmGt for ; Mon, 27 Feb 2012 02:43:16 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 527DB21F865D for ; Mon, 27 Feb 2012 02:43:16 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S1y2z-000I3f-Tt; Mon, 27 Feb 2012 10:43:14 +0000 Date: Mon, 27 Feb 2012 16:13:11 +0530 Message-ID: From: Randy Bush To: Nick Hilliard In-Reply-To: <4F4B566E.3050901@inex.ie> References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> <4F4B566E.3050901@inex.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 10:43:16 -0000 >> what is a 'flow label'? > ok, i'll humour you: it's bits 13 to 32 of the standard ipv6 header. > But you already know this and we all know you know this, so what point are > you making? that we have spend over a decade wasting time trying to find a noble use for those bits. perhaps we should find operationally useful work. randy From nick@inex.ie Mon Feb 27 03:22:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DB021F86A8 for ; Mon, 27 Feb 2012 03:22:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmXiOZvgTMdK for ; Mon, 27 Feb 2012 03:22:10 -0800 (PST) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1808D21F86A5 for ; Mon, 27 Feb 2012 03:22:09 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q1RBMhKG011519 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 27 Feb 2012 11:22:43 GMT (envelope-from nick@inex.ie) Message-ID: <4F4B675C.4040909@inex.ie> Date: Mon, 27 Feb 2012 11:22:04 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Randy Bush References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> <4F4B566E.3050901@inex.ie> In-Reply-To: X-Enigmail-Version: 1.3.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 11:22:11 -0000 On 27/02/2012 10:43, Randy Bush wrote: > that we have spend over a decade wasting time trying to find a noble use > for those bits. perhaps we should find operationally useful work. flow labels are used as a hashing token for lags and ecmp load balanced links - this has been the case for a long time. And no, I'm not going to get into protracted arguments about the necessity of load balancing N*10G ipv6 links - the point is that the field is used by various kit out there today. And who knows, maybe on June 6th this year, this might start becoming important. Nick From jason_livingood@cable.comcast.com Mon Feb 27 07:06:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E897C21F8711 for ; Mon, 27 Feb 2012 07:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.663 X-Spam-Level: X-Spam-Status: No, score=-102.663 tagged_above=-999 required=5 tests=[AWL=-1.433, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkGaBiQJR9rt for ; Mon, 27 Feb 2012 07:06:05 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 545F021F86FD for ; Mon, 27 Feb 2012 07:06:05 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.7343225; Mon, 27 Feb 2012 07:52:54 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%17]) with mapi id 14.01.0355.002; Mon, 27 Feb 2012 10:04:09 -0500 From: "Livingood, Jason" To: Marc Lampo , 'Ronald Bonica' , "joelja@bogus.com" , 'Mark Andrews' Thread-Topic: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC Thread-Index: AQHM8NGMkD00gtDZEUSP/1IDM55exZZHw6MAgADeEzCAAdSqgIAGah0A Date: Mon, 27 Feb 2012 15:04:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: multipart/alternative; boundary="_000_CB71054F51C58jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Last Call: (Considerations for Transitioning Content to IPv6) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 15:06:06 -0000 --_000_CB71054F51C58jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Marc and Mark worked together to make one final tweak since I was not corre= ctly capturing what they were each trying to communicate. This minor tweak = will appear in a =9611 in just a few minutes. Thanks Jason --_000_CB71054F51C58jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Marc and Mark worked together to make one final tweak since I was not = correctly capturing what they were each trying to communicate. This minor t= weak will appear in a =9611 in just a few minutes.

Thanks
Jason
--_000_CB71054F51C58jasonlivingoodcablecomcastcom_-- From internet-drafts@ietf.org Mon Feb 27 07:11:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EC221F86C9; Mon, 27 Feb 2012 07:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA5f2lyYBbao; Mon, 27 Feb 2012 07:11:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A061421F86D3; Mon, 27 Feb 2012 07:10:57 -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 X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120227151057.2569.56769.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2012 07:10:57 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 15:11: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 Operations Working Group of the = IETF. Title : Considerations for Transitioning Content to IPv6 Author(s) : Jason Livingood Filename : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11.txt Pages : 31 Date : 2012-02-27 This document describes considerations for the transition of end user content on the Internet to IPv6. While this is tailored to address end user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-i= mplications-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-im= plications-11.txt From gert@space.net Mon Feb 27 07:11:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BCF21F86C9 for ; Mon, 27 Feb 2012 07:11: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxfEL4qG72oY for ; Mon, 27 Feb 2012 07:11:20 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 48C9C21F8787 for ; Mon, 27 Feb 2012 07:11:19 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 55ACCF8A62 for ; Mon, 27 Feb 2012 16:11:05 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 1C6C7F8A5A for ; Mon, 27 Feb 2012 16:11:05 +0100 (CET) Received: (qmail 62725 invoked by uid 1007); 27 Feb 2012 16:11:05 +0100 Date: Mon, 27 Feb 2012 16:11:05 +0100 From: Gert Doering To: Nick Hilliard Message-ID: <20120227151105.GO84425@Space.Net> References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> <4F4B566E.3050901@inex.ie> <4F4B675C.4040909@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F4B675C.4040909@inex.ie> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 15:11:21 -0000 Hi, On Mon, Feb 27, 2012 at 11:22:04AM +0000, Nick Hilliard wrote: > On 27/02/2012 10:43, Randy Bush wrote: > > that we have spend over a decade wasting time trying to find a noble use > > for those bits. perhaps we should find operationally useful work. > > flow labels are used as a hashing token for lags and ecmp load balanced > links Is anybody setting these to anything but "0"? (This is a serious question, and I don't know the answer - but if it's used as a balancing hash, there needs to be some diversity in the values to make it useful) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From bzeeb-lists@lists.zabbadoz.net Mon Feb 27 07:54:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386A421F85BE for ; Mon, 27 Feb 2012 07:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5Xf+5Y5wuZh for ; Mon, 27 Feb 2012 07:54:42 -0800 (PST) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id 7C37221F85CD for ; Mon, 27 Feb 2012 07:54:42 -0800 (PST) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 8960925D3A00; Mon, 27 Feb 2012 15:54:39 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A1E21BDC42D; Mon, 27 Feb 2012 15:54:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id gYQN6+YfMnUi; Mon, 27 Feb 2012 15:54:37 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 4C715BDC42B; Mon, 27 Feb 2012 15:54:37 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120227151105.GO84425@Space.Net> Date: Mon, 27 Feb 2012 15:54:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <72DBDB2C-91CF-4794-B1A0-E3454B8C1F26@lists.zabbadoz.net> References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> <4F4B566E.3050901@inex.ie> <4F4B675C.4040909@inex.ie> <20120227151105.GO84425@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 15:54:43 -0000 On 27. Feb 2012, at 15:11 , Gert Doering wrote: > Hi, >=20 > On Mon, Feb 27, 2012 at 11:22:04AM +0000, Nick Hilliard wrote: >> On 27/02/2012 10:43, Randy Bush wrote: >>> that we have spend over a decade wasting time trying to find a noble = use >>> for those bits. perhaps we should find operationally useful work. >>=20 >> flow labels are used as a hashing token for lags and ecmp load = balanced >> links=20 >=20 > Is anybody setting these to anything but "0"? >=20 > (This is a serious question, and I don't know the answer - but if it's > used as a balancing hash, there needs to be some diversity in the = values > to make it useful) Yes, you may remember the old CSCsd13298 problem? I'd also like to = point you at the old surveys from Orla McGann and David Malone. I think part of the load balancer issues is that the latest documents do = not make it fully suitable for "hosts" anymore where an e-to-end = (edge-to-host or better end-to-end) flow label would be essential (controllable by the = host ideally) or uniquely by an entire management domain, which already = breaks with a customer host (I'll ignore Fernando's immediate concerns there;-) I hope that some RSS people could speak up here, given the toeplitz etc = problems. Talking to NIC vendors (with clue) might also be a good idea. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From nick@inex.ie Mon Feb 27 08:17:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642E721F879D for ; Mon, 27 Feb 2012 08:17: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGpowi5trtER for ; Mon, 27 Feb 2012 08:17:17 -0800 (PST) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC9221F874A for ; Mon, 27 Feb 2012 08:17:11 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q1RGHlWW015907 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 27 Feb 2012 16:17:47 GMT (envelope-from nick@inex.ie) Message-ID: <4F4BAC84.9030603@inex.ie> Date: Mon, 27 Feb 2012 16:17:08 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Gert Doering References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> <4F4B566E.3050901@inex.ie> <4F4B675C.4040909@inex.ie> <20120227151105.GO84425@Space.Net> In-Reply-To: <20120227151105.GO84425@Space.Net> X-Enigmail-Version: 1.3.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 16:17:17 -0000 On 27/02/2012 15:11, Gert Doering wrote: > Is anybody setting these to anything but "0"? > > (This is a serious question, and I don't know the answer - but if it's > used as a balancing hash, there needs to be some diversity in the values > to make it useful) in theory it ought to be enabled on freebsd and consequently mac os/x, depending on whether net.inet6.ip6.auto_flowlabel is set to 1 (the default). However, wireshark shows inconsistent results compatible with the Orla/David's paper of 2005. Linux still has no code to set it. Windows doesn't appear to set it either. Disappointing. Nick From nick@inex.ie Mon Feb 27 08:21:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D78421F86C5 for ; Mon, 27 Feb 2012 08:21:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj-HogfzLDlH for ; Mon, 27 Feb 2012 08:21:14 -0800 (PST) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id A433D21F86BB for ; Mon, 27 Feb 2012 08:21:13 -0800 (PST) X-Envelope-To: Received: from cupcake.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q1RGLowK015986 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 27 Feb 2012 16:21:51 GMT (envelope-from nick@inex.ie) Message-ID: <4F4BAD78.1050005@inex.ie> Date: Mon, 27 Feb 2012 16:21:12 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> <4F4B566E.3050901@inex.ie> <4F4B675C.4040909@inex.ie> <20120227151105.GO84425@Space.Net> <4F4BAC84.9030603@inex.ie> In-Reply-To: <4F4BAC84.9030603@inex.ie> X-Enigmail-Version: 1.3.5 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 16:21:17 -0000 On 27/02/2012 16:17, Nick Hilliard wrote: > in theory it ought to be enabled on freebsd and consequently mac os/x, > depending on whether net.inet6.ip6.auto_flowlabel is set to 1 (the > default). However, wireshark shows inconsistent results compatible with > the Orla/David's paper of 2005. Linux still has no code to set it. > Windows doesn't appear to set it either. Disappointing. should add: this is on the basis of 5-10 minutes of poking around. One wouldn't want to call it useful data or meaningful investigation. Nick From iesg-secretary@ietf.org Mon Feb 27 09:23:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CECF21F87B2; Mon, 27 Feb 2012 09:23:09 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AlUmT9cVM-g; Mon, 27 Feb 2012 09:23:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E19D21F87B9; Mon, 27 Feb 2012 09:23:07 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120227172307.10420.40865.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2012 09:23:07 -0800 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'Considerations for Transitioning Content to IPv6' to Informational RFC (draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 17:23:09 -0000 The IESG has approved the following document: - 'Considerations for Transitioning Content to IPv6' (draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11.txt) as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ronald Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/ Technical Summary The objective of this document is to describe what the whitelisting of DNS AAAA resource records is, hereafter referred to as DNS whitelisting, as well as the implications of this emerging practice and what alternatives may exist. The audience for this document is the Internet community generally, including the IETF and IPv6 implementers. Working Group Summary During the WGLC, Doug Barton captured the major criticism of the document thusly: However I return to my main premise which is: 1. 99.9% of the organizations who have chose this solution already understand these issues, and 2. The 0.1% who don't, don't care. While I think that's a valid concern I'm not sure that it results in a lack of utility for the information present. Consensus squarely favors publication and we feel that the document will be informative and useful in it's present form. Document Quality There are implementers of V6 AAAA whitelisting who have weighed in with their plans and comments on the content of the document. significant effort has gone into obtaining community involvement given the concerns that the document raises. The acknowledgments include several deep reviews of the document. Personel Joel Jaegli is document shepherd From Ray.Hunter@globis.net Mon Feb 27 09:29:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CBC21F84D5 for ; Mon, 27 Feb 2012 09:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgLF3Fp7iz6C for ; Mon, 27 Feb 2012 09:29:47 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9212C21F84D4 for ; Mon, 27 Feb 2012 09:29:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1FBEF8700B9; Mon, 27 Feb 2012 18:29:45 +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 ClIMNmkXNmZy; Mon, 27 Feb 2012 18:29:34 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 8B383870089; Mon, 27 Feb 2012 18:29:34 +0100 (CET) Message-ID: <4F4BBD7E.4000404@globis.net> Date: Mon, 27 Feb 2012 18:29:34 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Brian E Carpenter References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> <4F492882.4020800@gmail.com> In-Reply-To: <4F492882.4020800@gmail.com> Content-Type: multipart/mixed; boundary="------------040303000301070501090503" Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 17:29:48 -0000 This is a multi-part message in MIME format. --------------040303000301070501090503 Content-Type: multipart/alternative; boundary="------------030509070904030509060609" --------------030509070904030509060609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Off Topic: I work with enterprises and care about load balancers and high availability systems. To be honest though, my cares are much much more low-level than a new IETF draft. e.g. lack of any IPv6 support at all in some brand new devices that are still shipping, IPv6 support in existing IPv4-based mechanisms (e.g. WCCP & WCCPv2 although I believe this is now fixed since 2H2011), any impact on security when introducing IPv6 in load balancers, how to deploy IPv6 across 18 different services in 18 months whilst keeping all of the services running 7x24 with minimal downtime. On Topic: I have read this draft. As usual with work from the authors, it is well written and easy to understand for operational type people. A form of load balancing that I have not yet seen addressed is for on the fly processing more akin to multipath routing, such as WAN compression or protocol optimization e.g. for CIFS, where the cost of processing an individual packet may be much greater than switching it. In this case, an in-line device (the interceptor/ director) may intercept packets and switch based on L3/L4 info to either i) forward the original traffic flow to other in-line devices for further processing (e.g. caching/ protocol acceleration/ WAN compression) before the traffic is forwarded over a tunnel to a remote partner device for decompression, or ii) farm out service requests to an array of specialist compression/cache/protocol acceleration engines which then return data to the director for forwarding. Ensuring that content is appropriately balanced between a number of compression/cache/protocol acceleration devices can potentially balance the load on each device, increase the overall system availability, and also increase the efficiency of individual cache hits for requests. Another form of load balancing that hasn't been mentioned is Layer 7 load balancing. A layer 7 switch may examine traffic on the fly and switch the requests to an appropriate server based on the actual content of the request (perhaps utilizing NAT44 to ensure proper routing of the return traffic). This may allow separate provisioning of servers for servicing HTTP requests for fixed content such as static images, compared to servers used for handling transactional requests, whilst all content is located from a browser perspective via a single base URL and IP address. Of course there's no official equivalent of NAT44 in IPv6 to perform this return routing. As far as I can see, the IPv6 flow label may not be an effective method of caching layer 7 load balancing decisions, because a single persistent HTTP session defined in RFC 2616 (aka HTTP keep-alive) may transport requests for many different forms of content via pipelining. Also the cost of Layer 7 processing for IPv6 for load balancing could be very different than in IPv4. See e.g. draft-gont-6man-oversized-header-chain regards, RayH Brian E Carpenter wrote: > "some level [of] ipv6 support" > > I can assure you that this is only just filtering out to > the more remote ends of the Internet, but I agree that it's > happening. However, this draft looks a little beyond current > practice. > > Regards > Brian > > On 2012-02-25 22:34, Joel jaeggli wrote: > >> On 2/24/12 13:17 , Brian E Carpenter wrote: >> >>> It seems from the lack of discussion that nobody in v6ops cares >>> about server load balancers. I find this strange, since when >>> I talk to enterprise operations folk, they always flag load >>> balancers as one of the main holdups with supporting IPv6. >>> >> I doubt that very much... >> >> Every load balancer platform that I have access too today has some level >> ipv6 support. f5 a10 netscalar, along with ha-proxy and nginx are all in >> the field providing production level ipv6 traffic delivery. >> >> I would think given the topic that the involvement of the flow label is >> implicated the in lack of excitement. >> >> >>> The author's won't drop this draft, but unless the WG shows >>> some sign of interest, we will take it elsewhere. >>> >>> Regards >>> Brian >>> >>> On 2012-02-09 09:05, Brian E Carpenter wrote: >>> >>>> Every serious content provider runs load balancers. >>>> >>>> Missing IPv6 support in load balancers has been a delaying factor >>>> for IPv6 deployment. >>>> >>>> This draft discusses the only aspect of IPv6 that seems to be >>>> significantly different from IPv4: the flow label may enhance load >>>> balancer efficiency. >>>> >>>> The authors suggest that the topic belongs in v6ops because it >>>> potentially affects all large server operators, but calls for no >>>> protocol changes. We'd like to know who agrees or disagrees. >>>> >>>> Regards >>>> Brian Carpenter >>>> >>>> On 2012-01-30 11:33, Brian E Carpenter wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm not seeing more comments on this. The authors would like advice: >>>>> >>>>> Should we ask for v6ops to adopt this? >>>>> Should we ask another WG to adopt it? >>>>> Should we propose it as an individual submission? >>>>> Should we forget about it? >>>>> >>>>> Regards >>>>> Brian Carpenter >>>>> >>>>> On 2012-01-18 10:14, Brian E Carpenter wrote: >>>>> >>>>>> This is a significant update since the version discussed in Taipei, >>>>>> with an additional author who is a practitioner in the field, >>>>>> and incorporating comments from implementors. >>>>>> >>>>>> Of course we would like more feedback. For the moment I suggest >>>>>> discussion on the v6ops list, although that may not be the >>>>>> final home for this draft. >>>>>> >>>>>> Please keep Willy on CC since I'm not sure he's on this list. >>>>>> >>>>>> Brian Carpenter >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt >>>>>> Date: Tue, 17 Jan 2012 12:40:05 -0800 >>>>>> From: internet-drafts@ietf.org >>>>>> Reply-To: internet-drafts@ietf.org >>>>>> To: i-d-announce@ietf.org >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>> >>>>>> Title : Using the IPv6 Flow Label for Server Load Balancing >>>>>> Author(s) : Brian Carpenter >>>>>> Sheng Jiang >>>>>> Willy Tarreau >>>>>> Filename : draft-carpenter-v6ops-label-balance-01.txt >>>>>> Pages : 12 >>>>>> Date : 2012-01-17 >>>>>> >>>>>> This document describes how the IPv6 flow label can be used in >>>>>> support of layer 3/4 load distribution and balancing for large server >>>>>> farms. >>>>>> >>>>>> >>>>>> A URL for this Internet-Draft is: >>>>>> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> This Internet-Draft can be retrieved at: >>>>>> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>>> >>>>>> >>>>>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> > > -- Ray Hunter Ray.Hunter@globis.net Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL, Registered at the KvK, Eindhoven, under number BV 17098279 mobile: +31 620 363864 --------------030509070904030509060609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Off Topic:
I work with enterprises and care about load balancers and high availability systems.

To be honest though, my cares are much much more low-level than a new IETF draft. e.g. lack of any IPv6 support at all in some brand new devices that are still shipping, IPv6 support in existing IPv4-based mechanisms (e.g. WCCP & WCCPv2 although I believe this is now fixed since 2H2011), any impact on security when introducing IPv6 in load balancers, how to deploy IPv6 across 18 different services in 18 months whilst keeping all of the services running 7x24 with minimal downtime.

On Topic:
I have read this draft. As usual with work from the authors, it is well written and easy to understand for operational type people.

A form of load balancing that I have not yet seen addressed is for on the fly processing more akin to multipath routing, such as WAN compression or protocol optimization e.g. for CIFS, where the cost of processing an individual packet may be much greater than switching it.

In this case, an in-line device (the interceptor/ director) may intercept packets and switch based on L3/L4 info to either
i) forward the original traffic flow to other in-line devices for further processing (e.g. caching/ protocol acceleration/ WAN compression) before the traffic is forwarded over a tunnel to a remote partner device for decompression,
or
ii) farm out service requests to an array of specialist compression/cache/protocol acceleration engines which then return data to the director for forwarding.

Ensuring that content is appropriately balanced between a number of compression/cache/protocol acceleration devices can potentially balance the load on each device, increase the overall system availability, and also increase the efficiency of individual cache hits for requests.



Another form of load balancing that hasn't been mentioned is Layer 7 load balancing.

A layer 7 switch may examine traffic on the fly and switch the requests to an appropriate server based on the actual content of the request (perhaps utilizing NAT44 to ensure proper routing of the return traffic). This may allow separate provisioning of servers for servicing HTTP requests for fixed content such as static images, compared to servers used for handling transactional requests, whilst all content is located from a browser perspective via a single base URL and IP address. Of course there's no official equivalent of NAT44 in IPv6 to perform this return routing.

As far as I can see, the IPv6 flow label may not be an effective method of caching layer 7 load balancing decisions, because a single persistent HTTP session defined in RFC 2616 (aka HTTP keep-alive) may transport requests for many different forms of content via pipelining.

Also the cost of Layer 7 processing for IPv6 for load balancing could be very different than in IPv4. See e.g. draft-gont-6man-oversized-header-chain

regards,
RayH

Brian E Carpenter wrote: 
"some level [of] ipv6 support"

I can assure you that this is only just filtering out to
the more remote ends of the Internet, but I agree that it's
happening. However, this draft looks a little beyond current
practice.

Regards
   Brian

On 2012-02-25 22:34, Joel jaeggli wrote:
  
On 2/24/12 13:17 , Brian E Carpenter wrote:
    
It seems from the lack of discussion that nobody in v6ops cares
about server load balancers. I find this strange, since when
I talk to enterprise operations folk, they always flag load
balancers as one of the main holdups with supporting IPv6.
      
I doubt that very much...

Every load balancer platform that I have access too today has some level
ipv6 support. f5 a10 netscalar, along with ha-proxy and nginx are all in
the field providing production level ipv6 traffic delivery.

I would think given the topic that the involvement of the flow label is
implicated the in lack of excitement.

    
The author's won't drop this draft, but unless the WG shows
some sign of interest, we will take it elsewhere.

Regards
   Brian

On 2012-02-09 09:05, Brian E Carpenter wrote:
      
Every serious content provider runs load balancers.

Missing IPv6 support in load balancers has been a delaying factor
for IPv6 deployment.

This draft discusses the only aspect of IPv6 that seems to be
significantly different from IPv4: the flow label may enhance load
balancer efficiency.

The authors suggest that the topic belongs in v6ops because it
potentially affects all large server operators, but calls for no
protocol changes. We'd like to know who agrees or disagrees.

Regards
   Brian Carpenter

On 2012-01-30 11:33, Brian E Carpenter wrote:
        
Hi,

I'm not seeing more comments on this. The authors would like advice:

Should we ask for v6ops to adopt this?
Should we ask another WG to adopt it?
Should we propose it as an individual submission?
Should we forget about it?

Regards
   Brian Carpenter

On 2012-01-18 10:14, Brian E Carpenter wrote:
          
This is a significant update since the version discussed in Taipei,
with an additional author who is a practitioner in the field,
and incorporating comments from implementors.

Of course we would like more feedback. For the moment I suggest
discussion on the v6ops list, although that may not be the
final home for this draft.

Please keep Willy on CC since I'm not sure he's on this list.

    Brian Carpenter

-------- Original Message --------
Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt
Date: Tue, 17 Jan 2012 12:40:05 -0800
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Using the IPv6 Flow Label for Server Load Balancing
	Author(s)       : Brian Carpenter
                          Sheng Jiang
                          Willy Tarreau
	Filename        : draft-carpenter-v6ops-label-balance-01.txt
	Pages           : 12
	Date            : 2012-01-17

   This document describes how the IPv6 flow label can be used in
   support of layer 3/4 load distribution and balancing for large server
   farms.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt

_______________________________________________
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


            
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--
Ray Hunter
Ray.Hunter@globis.net
Globis Consulting BV, Fazantlaan 23, 5613CB Eindhoven NL,
Registered at the KvK, Eindhoven, under number BV 17098279
mobile: +31 620 363864

--------------030509070904030509060609-- --------------040303000301070501090503 Content-Type: text/x-vcard; charset=utf-8; name="Ray_Hunter.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Ray_Hunter.vcf" begin:vcard fn:Ray Hunter n:Hunter;Ray org:Globis Consulting BV adr:;;Fazantlaan23;Eindhoven;;5613CB;The Netherlands email;internet:Ray.Hunter@globis.net tel;cell:+31 620 363864 x-mozilla-html:FALSE url:http://www.globis.net version:2.1 end:vcard --------------040303000301070501090503-- From cb.list6@gmail.com Mon Feb 27 09:36:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B450821F871B for ; Mon, 27 Feb 2012 09:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4MUbR08ZmJE for ; Mon, 27 Feb 2012 09:36:29 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 377A621F8717 for ; Mon, 27 Feb 2012 09:36:29 -0800 (PST) Received: by pbcwz17 with SMTP id wz17so1000742pbc.31 for ; Mon, 27 Feb 2012 09:36:29 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.227.164 as permitted sender) client-ip=10.68.227.164; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.227.164 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.227.164]) by 10.68.227.164 with SMTP id sb4mr43536381pbc.134.1330364189061 (num_hops = 1); Mon, 27 Feb 2012 09:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=5r2YEEIHd+ENhvujFMp47wm8C5b127A4KmrtLwIkacQ=; b=wYybBN3YOw9DivX3owkiaJLGVliUfX/OCmKYdKu8CevuuQzOhdLhfPs+P+BFlOBpOo 427QE+ajSHDcrifJ4duYTz5datDnTDszrNigipALQlLc67/uNI4x50pciDEyRJQ8EmdN ocfLpEja8muiel0nufVD0BP3getM0WdxmWyUQ= MIME-Version: 1.0 Received: by 10.68.227.164 with SMTP id sb4mr36928289pbc.134.1330364188940; Mon, 27 Feb 2012 09:36:28 -0800 (PST) Received: by 10.142.99.12 with HTTP; Mon, 27 Feb 2012 09:36:28 -0800 (PST) Date: Mon, 27 Feb 2012 09:36:28 -0800 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 17:36:29 -0000 V6ops, We received some feedback that draft-ietf-v6ops-464xlat-00 has normative language which is not correct for an informational draft. When pressed on where the normative language was, we were told that the issue was use of RFC 2119 key words. In reviewing RFC 2119, I could not find any limitation on how the keywords are used In reviewing RFC 4677, it seems the RFC 2119 drives clarity and therefore should be used to "tell it like it is" Further review of published Informational work, i see that RFC 6092 is informational and uses RFC 2119 key words My preference is to keep the key words in 464XLAT for clarity of the document. Does the WG have an issue with this or statement on how this violates for complies with norms? Thanks, Cameron From jhw@apple.com Mon Feb 27 10:52:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006DF21F87E4 for ; Mon, 27 Feb 2012 10:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.262 X-Spam-Level: X-Spam-Status: No, score=-110.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykTo-KhPOZIO for ; Mon, 27 Feb 2012 10:52:45 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 86D9421F87DF for ; Mon, 27 Feb 2012 10:52:45 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M0200A3FEZCQCM1@mail-out.apple.com> for v6ops@ietf.org; Mon, 27 Feb 2012 10:52:24 -0800 (PST) X-AuditID: 11807136-b7c09ae00000516a-3a-4f4bd0e80547 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id DE.5A.20842.8E0DB4F4; Mon, 27 Feb 2012 10:52:24 -0800 (PST) From: james woodyatt In-reply-to: Date: Mon, 27 Feb 2012 10:52:24 -0800 Message-id: <4D30BB2F-1180-482C-A4EA-5E8665BFB3E0@apple.com> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1426) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUieJDXQffFBW9/g3urOSxWffnIZHH62F5m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj9tV57AX3OSumPb/I3sB4i72LkZNDQsBE or3xFxOELSZx4d56ti5GLg4hgdlMEm1H17KCJJgFtCRu/HsJVsQroCfRdPkwmC0s4CbR/7wB zGYTUJH4dvkumM0pECjxceE1ZhCbRUBV4v6ZE+wQcxQk2t61M0LY2hLLFr5mhphpI/H9+U42 EFtIIEBi/4JdYPUiAmoSU+Y8YYY4Tlbi0IyVjBMY+WchOWkWkpNmIRm7gJF5FaNgUWpOYqWh qV5iQUFOql5yfu4mRlDYNRSa7WDc8VfuEKMAB6MSD2/hLG9/IdbEsuLK3EOMEhzMSiK8+tlA Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxf8lz9hQTSE0tSs1NTC1KLYLJMHJxSDYw5eUzNm1ol 469/79rlMmGpOY+rve3GG0YSUyXKNu+KvV9+59DUeYd3xh29t11GW9w9T2/3TQavkE2BpVOy /DstJq1rirF5/mON2tam/DOhkWUHL1W9clkhYx3Eam/6r16NWT7h+MtWZuP0FovWxJjVhw99 8J2+LX/ih5a7O0/uP5q/d9a0N0xKLMUZiYZazEXFiQAk+3cXNwIAAA== Cc: IPv6 Ops WG Subject: Re: [v6ops] Normative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 18:52:46 -0000 On Feb 27, 2012, at 09:36 , Cameron Byrne wrote: > > Further review of published Informational work, i see that RFC 6092 is > informational and uses RFC 2119 key words > > My preference is to keep the key words in 464XLAT for clarity of the document. RFC 6092 used normative language not to improve clarity, but because it was expressly intended to inform the development of normative texts by other standards development organizations. When someone pointed out that RFC 2119 keywords don't belong in Informational category documents, and consensus could neither be established to set RFC 6092 on the Standards Track nor to remove the RFC 2119 keywords, the following disclaimer was inserted in Section 1.2, Use of Normative Keywords: NOTE WELL: This document is not a standard, and conformance with it is not required in order to claim conformance with IETF standards for IPv6. It uses the normative keywords defined in the previous section only for precision. Are there plans to use I-D.ietf-v6ops-464xlat to inform the development of external standards? -- james woodyatt member of technical staff, core os networking From cb.list6@gmail.com Mon Feb 27 11:12:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C964A21F87B8 for ; Mon, 27 Feb 2012 11:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=1.180, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFtgL9-T7sV5 for ; Mon, 27 Feb 2012 11:12:49 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52BE621F87B7 for ; Mon, 27 Feb 2012 11:12:49 -0800 (PST) Received: by dakl33 with SMTP id l33so1150009dak.31 for ; Mon, 27 Feb 2012 11:12:49 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.129.130 as permitted sender) client-ip=10.68.129.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.129.130 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.68.129.130]) by 10.68.129.130 with SMTP id nw2mr40084005pbb.8.1330369969164 (num_hops = 1); Mon, 27 Feb 2012 11:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QikwKJUZLzDmCuikbR65kapJrQkFkWb6WQ9f3N1ts+o=; b=Burzj0DBA+PlRAhsNLTnF3DZbYnDUP2Z2CgUr3nGwRVveQTgGWByIKOu54HEVMNQ4g 00hcSwV06urdXkndThnOsBrJ0gIVtoROLiwEEQ/JfpZZIieQgVBLVwcv8VhzvKlceJKn PGVfoUc+yiuqfz/4o1VOPdupupRYHgfi7PEio= MIME-Version: 1.0 Received: by 10.68.129.130 with SMTP id nw2mr33797019pbb.8.1330369969098; Mon, 27 Feb 2012 11:12:49 -0800 (PST) Received: by 10.142.99.12 with HTTP; Mon, 27 Feb 2012 11:12:49 -0800 (PST) In-Reply-To: <4D30BB2F-1180-482C-A4EA-5E8665BFB3E0@apple.com> References: <4D30BB2F-1180-482C-A4EA-5E8665BFB3E0@apple.com> Date: Mon, 27 Feb 2012 11:12:49 -0800 Message-ID: From: Cameron Byrne To: james woodyatt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Normative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 19:12:49 -0000 On Mon, Feb 27, 2012 at 10:52 AM, james woodyatt wrote: > On Feb 27, 2012, at 09:36 , Cameron Byrne wrote: >> >> Further review of published Informational work, i see that RFC 6092 is >> informational and uses RFC 2119 key words >> >> My preference is to keep the key words in 464XLAT for clarity of the doc= ument. > > RFC 6092 used normative language not to improve clarity, but because it w= as expressly intended to inform the development of normative texts by other= standards development organizations. > > When someone pointed out that RFC 2119 keywords don't belong in Informati= onal category documents, and consensus could neither be established to set = RFC 6092 on the Standards Track nor to remove the RFC 2119 keywords, the fo= llowing disclaimer was inserted in Section 1.2, Use of Normative Keywords: > > =A0 =A0 =A0NOTE WELL: This document is not a standard, and conformance wi= th > =A0 =A0 =A0it is not required in order to claim conformance with IETF > =A0 =A0 =A0standards for IPv6. =A0It uses the normative keywords defined = in the > =A0 =A0 =A0previous section only for precision. > > Are there plans to use I-D.ietf-v6ops-464xlat to inform the development o= f external standards? > > No. The expectation is that the document will informal implementors (hardware, software, network ...) of how the technologies may work together within a specific architecture to achieve an outcome. For this reason, i would like to keep the precision of the key words ... but i am not married to the key words. It is just the reference to RFC 2119 and case of the letters that would have to be changed? Thanks, Cameron > -- > james woodyatt > member of technical staff, core os networking > > > From sarikaya2012@gmail.com Mon Feb 27 11:15:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B63221F87D6 for ; Mon, 27 Feb 2012 11:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZtu72yzkrRk for ; Mon, 27 Feb 2012 11:15:55 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF0821F87D4 for ; Mon, 27 Feb 2012 11:15:55 -0800 (PST) Received: by yhpp34 with SMTP id p34so628361yhp.31 for ; Mon, 27 Feb 2012 11:15:55 -0800 (PST) Received-SPF: pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.37.132 as permitted sender) client-ip=10.236.37.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sarikaya2012@gmail.com designates 10.236.37.132 as permitted sender) smtp.mail=sarikaya2012@gmail.com; dkim=pass header.i=sarikaya2012@gmail.com Received: from mr.google.com ([10.236.37.132]) by 10.236.37.132 with SMTP id y4mr23776562yha.10.1330370155016 (num_hops = 1); Mon, 27 Feb 2012 11:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=qUC4dK+oqLS/mDrr2ErWUnVbCLKM30540m/vSQQWlH4=; b=REi3skmzYEqudOJhPMtmdqJ0rS+PtmEEFUPSBDrGxvla8BtzyB21SpQDzIvY0ZN62z JU2vBrsjVyP7njmoj3U94yN1yRDsr7qEqsIE5aXzhzhoVWTVIC3c4PL4TcZGL2y+jIWg E2RWoS0znB3dcvZbpgZhkgbqYyee44yedLff4= MIME-Version: 1.0 Received: by 10.236.37.132 with SMTP id y4mr17804164yha.10.1330370154943; Mon, 27 Feb 2012 11:15:54 -0800 (PST) Received: by 10.236.9.73 with HTTP; Mon, 27 Feb 2012 11:15:54 -0800 (PST) In-Reply-To: References: <4D30BB2F-1180-482C-A4EA-5E8665BFB3E0@apple.com> Date: Mon, 27 Feb 2012 13:15:54 -0600 Message-ID: From: Behcet Sarikaya To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Normative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 19:15:56 -0000 Cameron, check RFC 6459 and use the same. On Mon, Feb 27, 2012 at 1:12 PM, Cameron Byrne wrote: > On Mon, Feb 27, 2012 at 10:52 AM, james woodyatt wrote: >> On Feb 27, 2012, at 09:36 , Cameron Byrne wrote: >>> >>> Further review of published Informational work, i see that RFC 6092 is >>> informational and uses RFC 2119 key words >>> >>> My preference is to keep the key words in 464XLAT for clarity of the do= cument. >> >> RFC 6092 used normative language not to improve clarity, but because it = was expressly intended to inform the development of normative texts by othe= r standards development organizations. >> >> When someone pointed out that RFC 2119 keywords don't belong in Informat= ional category documents, and consensus could neither be established to set= RFC 6092 on the Standards Track nor to remove the RFC 2119 keywords, the f= ollowing disclaimer was inserted in Section 1.2, Use of Normative Keywords: >> >> =A0 =A0 =A0NOTE WELL: This document is not a standard, and conformance w= ith >> =A0 =A0 =A0it is not required in order to claim conformance with IETF >> =A0 =A0 =A0standards for IPv6. =A0It uses the normative keywords defined= in the >> =A0 =A0 =A0previous section only for precision. >> >> Are there plans to use I-D.ietf-v6ops-464xlat to inform the development = of external standards? >> >> > > No. =A0The expectation is that the document will informal implementors > (hardware, software, network ...) of how the technologies may work > together within a specific architecture to achieve an outcome. =A0For > this reason, i would like to keep the precision of the key words ... > but i am not married to the key words. > > It is just the reference to RFC 2119 and case of the letters that > would have to be changed? > > Thanks, > > Cameron > > >> -- >> james woodyatt >> member of technical staff, core os networking >> >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Mon Feb 27 12:32:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491C521F84CE for ; Mon, 27 Feb 2012 12:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.428 X-Spam-Level: X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT4Nf76BFBsC for ; Mon, 27 Feb 2012 12:32:57 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CECB521F849D for ; Mon, 27 Feb 2012 12:32:57 -0800 (PST) Received: by iagf6 with SMTP id f6so8215840iag.31 for ; Mon, 27 Feb 2012 12:32:57 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.42.159.135 as permitted sender) client-ip=10.42.159.135; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.42.159.135 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.42.159.135]) by 10.42.159.135 with SMTP id l7mr16205953icx.33.1330374777591 (num_hops = 1); Mon, 27 Feb 2012 12:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2D1fyYFQxFq3dtF5YsZCFbkId6qWH2fBgseDWhpizns=; b=xSkHxzuN3CKInKpF5GYtf50ChvBAyERPMbzEWrZJUViIWaShPbDyxGnnhCOeOV5qF3 m0kxzQbRUhQRpaf9BEGRNyPBaZ60wOl9GJ3hGHb5beZ67J0ic+jYyo4UQTXP6HYGKLJ5 CHkG8W2vmoec6ItLvgqa80azCi6Vwfy9ra9UI= Received: by 10.42.159.135 with SMTP id l7mr13069687icx.33.1330374777553; Mon, 27 Feb 2012 12:32:57 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id bi6sm11332823igc.3.2012.02.27.12.32.54 (version=SSLv3 cipher=OTHER); Mon, 27 Feb 2012 12:32:56 -0800 (PST) Message-ID: <4F4BE874.2010201@gmail.com> Date: Tue, 28 Feb 2012 09:32:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 20:32:59 -0000 On 2012-02-27 22:45, Randy Bush wrote: >> Every load balancer platform that I have access too today has some >> level ipv6 support. f5 a10 netscalar, along with ha-proxy and nginx >> are all in the field providing production level ipv6 traffic delivery. >> >> I would think given the topic that the involvement of the flow label is >> implicated the in lack of excitement. > > what is a 'flow label'? Today, it's usually 00000000000000000000 That's what we want to change, by documenting use cases (as RFC6438 does). Brian From brian.e.carpenter@gmail.com Mon Feb 27 12:40:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6602D21F85DA for ; Mon, 27 Feb 2012 12:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.131 X-Spam-Level: X-Spam-Status: No, score=-103.131 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3G7qt+iUAXU for ; Mon, 27 Feb 2012 12:40:13 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF1C21F85D3 for ; Mon, 27 Feb 2012 12:40:13 -0800 (PST) Received: by obbeh20 with SMTP id eh20so2108976obb.31 for ; Mon, 27 Feb 2012 12:40:13 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.182.15.70 as permitted sender) client-ip=10.182.15.70; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.182.15.70 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.182.15.70]) by 10.182.15.70 with SMTP id v6mr6285349obc.13.1330375213083 (num_hops = 1); Mon, 27 Feb 2012 12:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SWmKJffXW+B1henOn7XyO1ONZ+Ms/jM7rlp5XEp1O/Y=; b=qF7S91kO3sArhJE8DjMYEMBnWvyhgH19dvBOxWFVbiUgSCaHLMWlLiDAB9P4fikRS8 WvQZnhPi77QH3wUXBut768L7vK0lKLP0LWi+UiYIgHhob8Hcw9RViATPEYlp4TAQbGVa WQS7RsncUAHLbtsLmSuiNRjqDMQlYsYUqbUu4= Received: by 10.182.15.70 with SMTP id v6mr5238185obc.13.1330375212987; Mon, 27 Feb 2012 12:40:12 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id u5sm14242823obk.16.2012.02.27.12.40.10 (version=SSLv3 cipher=OTHER); Mon, 27 Feb 2012 12:40:12 -0800 (PST) Message-ID: <4F4BEA27.1050903@gmail.com> Date: Tue, 28 Feb 2012 09:40:07 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> <4F492882.4020800@gmail.com> <4F4BBD7E.4000404@globis.net> In-Reply-To: <4F4BBD7E.4000404@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 20:40:14 -0000 > Another form of load balancing that hasn't been mentioned is Layer 7 load balancing. Actually Ray, it *is* mentioned in the draft, but it's a little beside the point, because the flow label is a layer 3 construct. However, if layer 7 deep packet inspection has been used to assign a particular flow to a particular server, a layer 3 flow label has value for identifying future packets of the same flow. (I'm not going to respond to the other messages that are a rehash of the 2 year debate in 6man that led to RFC6437. Been there, reached rough consensus on that.) Regards Brian On 2012-02-28 06:29, Ray Hunter wrote: > Off Topic: > I work with enterprises and care about load balancers and high > availability systems. > > To be honest though, my cares are much much more low-level than a new > IETF draft. e.g. lack of any IPv6 support at all in some brand new > devices that are still shipping, IPv6 support in existing IPv4-based > mechanisms (e.g. WCCP & WCCPv2 although I believe this is now fixed > since 2H2011), any impact on security when introducing IPv6 in load > balancers, how to deploy IPv6 across 18 different services in 18 months > whilst keeping all of the services running 7x24 with minimal downtime. > > On Topic: > I have read this draft. As usual with work from the authors, it is well > written and easy to understand for operational type people. > > A form of load balancing that I have not yet seen addressed is for on > the fly processing more akin to multipath routing, such as WAN > compression or protocol optimization e.g. for CIFS, where the cost of > processing an individual packet may be much greater than switching it. > > In this case, an in-line device (the interceptor/ director) may > intercept packets and switch based on L3/L4 info to either > i) forward the original traffic flow to other in-line devices for > further processing (e.g. caching/ protocol acceleration/ WAN > compression) before the traffic is forwarded over a tunnel to a remote > partner device for decompression, > or > ii) farm out service requests to an array of specialist > compression/cache/protocol acceleration engines which then return data > to the director for forwarding. > > Ensuring that content is appropriately balanced between a number of > compression/cache/protocol acceleration devices can potentially balance > the load on each device, increase the overall system availability, and > also increase the efficiency of individual cache hits for requests. > > > > Another form of load balancing that hasn't been mentioned is Layer 7 > load balancing. > > A layer 7 switch may examine traffic on the fly and switch the requests > to an appropriate server based on the actual content of the request > (perhaps utilizing NAT44 to ensure proper routing of the return > traffic). This may allow separate provisioning of servers for servicing > HTTP requests for fixed content such as static images, compared to > servers used for handling transactional requests, whilst all content is > located from a browser perspective via a single base URL and IP address. > Of course there's no official equivalent of NAT44 in IPv6 to perform > this return routing. > > As far as I can see, the IPv6 flow label may not be an effective method > of caching layer 7 load balancing decisions, because a single persistent > HTTP session defined in RFC 2616 (aka HTTP keep-alive) may transport > requests for many different forms of content via pipelining. > > Also the cost of Layer 7 processing for IPv6 for load balancing could be > very different than in IPv4. See e.g. > draft-gont-6man-oversized-header-chain > > regards, > RayH > > Brian E Carpenter wrote: >> "some level [of] ipv6 support" >> >> I can assure you that this is only just filtering out to >> the more remote ends of the Internet, but I agree that it's >> happening. However, this draft looks a little beyond current >> practice. >> >> Regards >> Brian >> >> On 2012-02-25 22:34, Joel jaeggli wrote: >> >>> On 2/24/12 13:17 , Brian E Carpenter wrote: >>> >>>> It seems from the lack of discussion that nobody in v6ops cares >>>> about server load balancers. I find this strange, since when >>>> I talk to enterprise operations folk, they always flag load >>>> balancers as one of the main holdups with supporting IPv6. >>>> >>> I doubt that very much... >>> >>> Every load balancer platform that I have access too today has some level >>> ipv6 support. f5 a10 netscalar, along with ha-proxy and nginx are all in >>> the field providing production level ipv6 traffic delivery. >>> >>> I would think given the topic that the involvement of the flow label is >>> implicated the in lack of excitement. >>> >>> >>>> The author's won't drop this draft, but unless the WG shows >>>> some sign of interest, we will take it elsewhere. >>>> >>>> Regards >>>> Brian >>>> >>>> On 2012-02-09 09:05, Brian E Carpenter wrote: >>>> >>>>> Every serious content provider runs load balancers. >>>>> >>>>> Missing IPv6 support in load balancers has been a delaying factor >>>>> for IPv6 deployment. >>>>> >>>>> This draft discusses the only aspect of IPv6 that seems to be >>>>> significantly different from IPv4: the flow label may enhance load >>>>> balancer efficiency. >>>>> >>>>> The authors suggest that the topic belongs in v6ops because it >>>>> potentially affects all large server operators, but calls for no >>>>> protocol changes. We'd like to know who agrees or disagrees. >>>>> >>>>> Regards >>>>> Brian Carpenter >>>>> >>>>> On 2012-01-30 11:33, Brian E Carpenter wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm not seeing more comments on this. The authors would like advice: >>>>>> >>>>>> Should we ask for v6ops to adopt this? >>>>>> Should we ask another WG to adopt it? >>>>>> Should we propose it as an individual submission? >>>>>> Should we forget about it? >>>>>> >>>>>> Regards >>>>>> Brian Carpenter >>>>>> >>>>>> On 2012-01-18 10:14, Brian E Carpenter wrote: >>>>>> >>>>>>> This is a significant update since the version discussed in Taipei, >>>>>>> with an additional author who is a practitioner in the field, >>>>>>> and incorporating comments from implementors. >>>>>>> >>>>>>> Of course we would like more feedback. For the moment I suggest >>>>>>> discussion on the v6ops list, although that may not be the >>>>>>> final home for this draft. >>>>>>> >>>>>>> Please keep Willy on CC since I'm not sure he's on this list. >>>>>>> >>>>>>> Brian Carpenter >>>>>>> >>>>>>> -------- Original Message -------- >>>>>>> Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt >>>>>>> Date: Tue, 17 Jan 2012 12:40:05 -0800 >>>>>>> From: internet-drafts@ietf.org >>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>> To: i-d-announce@ietf.org >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line >>>>>>> Internet-Drafts directories. >>>>>>> >>>>>>> Title : Using the IPv6 Flow Label for Server Load >>>>>>> Balancing >>>>>>> Author(s) : Brian Carpenter >>>>>>> Sheng Jiang >>>>>>> Willy Tarreau >>>>>>> Filename : draft-carpenter-v6ops-label-balance-01.txt >>>>>>> Pages : 12 >>>>>>> Date : 2012-01-17 >>>>>>> >>>>>>> This document describes how the IPv6 flow label can be used in >>>>>>> support of layer 3/4 load distribution and balancing for >>>>>>> large server >>>>>>> farms. >>>>>>> >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>>>>> >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> This Internet-Draft can be retrieved at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> >>> >> >> > From tjc@ecs.soton.ac.uk Mon Feb 27 15:57:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E26921E8033 for ; Mon, 27 Feb 2012 15:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiLe368ZACg8 for ; Mon, 27 Feb 2012 15:57:46 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 70BC621E8029 for ; Mon, 27 Feb 2012 15:57:46 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q1RNvgRR022826 for ; Mon, 27 Feb 2012 23:57:42 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q1RNvgRR022826 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1330387062; bh=KJjgyYEjVT8/cxtkDgV4L0J6Zmo=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=KyvTeNTf2tXpvBlfz8nHh9I0NDaRce0vcfY+1kHhfFSY8v9/HiOkzbSTPr0xqsl+w MkXp74Te4eN2g7Y8fx4xz8kO4FpDqPgymloeEg/hPZXKBtc2IhnOmF26bBzC0BksY/ r4+5m6EsPxA8o/wSofXrtaDntOGk/qmDjPN7b7B8= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id o1QNvg0543763266EC ret-id none; Mon, 27 Feb 2012 23:57:42 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q1RNuNRZ012254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 27 Feb 2012 23:56:24 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Tim Chown In-Reply-To: <20120227235134.24874.64108.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2012 23:56:23 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20120227235134.24874.64108.idtracker@ietfa.amsl.com> <29061E17-4C3E-4865-A64D-3D4B80DDB079@ecs.soton.ac.uk> To: IPv6 Operations X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o1QNvg054376326600; tid=o1QNvg0543763266EC; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q1RNvgRR022826 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] I-D Action: draft-chkpvc-enterprise-incremental-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 23:57:47 -0000 Hi, In Taipei it was pointed out that the previous enterprise guidance texts = were now rather dated, so I asked if any other authors would be interested in = working together to build a more up-to-date enterprise IPv6 deployment text. This is the initial result of pulling some sections together, but is = very much an initial strawman with further work required. All feedback is welcome. Tim On 27 Feb 2012, at 23:51, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Enterprise Incremental IPv6 > Author(s) : Lee Howard > Tim Chown > Kiran K. Chittimaneni > Yanick Pouffary > Eric Vyncke > Victor Kuarsingh > Filename : = draft-chkpvc-enterprise-incremental-ipv6-00.txt > Pages : 26 > Date : 2012-02-27 >=20 > Enterprise network administrators worldwide are in various stages of > preparing for or deploying IPv6 into their networks. The > administrators face different challenges than operators of Internet > access providers, and have reasons for different priorities. The > overall problem for many administrators will be to offer Internet- > facing services over IPv6, while continuing to support IPv4, and > while introducing IPv6 access within the enterprise IT network. The > overall transition will take most networks from an IPv4-only > environment to a dual stack network environment and potentially an > IPv6-only operating mode. This document helps provide a framework > for enterprise network architects or administrators who may be faced > with many of these challenges as they consider their IPv6 support > strategies. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-chkpvc-enterprise-incremental-ip= v6-00.txt From jouni.nospam@gmail.com Tue Feb 28 00:49:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4122521F8523 for ; Tue, 28 Feb 2012 00:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-Kq8lhUo-GK for ; Tue, 28 Feb 2012 00:49:44 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25E7321F850F for ; Tue, 28 Feb 2012 00:49:43 -0800 (PST) Received: by wicr5 with SMTP id r5so1577988wic.31 for ; Tue, 28 Feb 2012 00:49:43 -0800 (PST) Received-SPF: pass (google.com: domain of jouni.nospam@gmail.com designates 10.180.84.36 as permitted sender) client-ip=10.180.84.36; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jouni.nospam@gmail.com designates 10.180.84.36 as permitted sender) smtp.mail=jouni.nospam@gmail.com; dkim=pass header.i=jouni.nospam@gmail.com Received: from mr.google.com ([10.180.84.36]) by 10.180.84.36 with SMTP id v4mr4523483wiy.0.1330418983329 (num_hops = 1); Tue, 28 Feb 2012 00:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hknHZfn7oTW9LMm7ivtLpFUK+aV8n8W/ScPyIA4S+sk=; b=kPs2SeUbq8JSDQkP3y4RnxtFJOxEzvgfKlulJVThOyXWMy9BHCAvop/nC4W2qaBUeh 6SyJgRP7xmK6tctHSXUtXhJHdSVYUUys6yBwIh0jV4a4FBoqDO4o9D4/cIbuoVcQhtQK p0dlZeLRGvB1g0MjCPDJPqN7ajatCG1vJvtWE= Received: by 10.180.84.36 with SMTP id v4mr3522059wiy.0.1330418983278; Tue, 28 Feb 2012 00:49:43 -0800 (PST) Received: from [10.255.132.9] ([192.100.123.77]) by mx.google.com with ESMTPS id hb10sm67816570wib.10.2012.02.28.00.49.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Feb 2012 00:49:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: jouni korhonen In-Reply-To: <2D09D61DDFA73D4C884805CC7865E611043C0B@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Tue, 28 Feb 2012 10:49:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E611043C0B@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] PD-exclude was approved by the IESG -> should be included into 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 08:49:45 -0000 Barbara, On Feb 24, 2012, at 7:00 PM, STARK, BARBARA H wrote: > I have a question as to whether this needs to be a MUST/SHALL or can = it be a SHOULD. > In my mind, the answer to this depends on how operators who intend to = use PD-exclude will treat CE routers that do not support PD-exclude. > Will they refuse to offer IA_PD (so the non-PD-exclude-supporting CE = router is useless for attachment to that access network), or will they = offer IA_PD and either also offer IA_NA (from a different prefix) or let = the CE router operate in =93unnumbered mode=94? I cannot speak on behalf of others but from 3GPP networks point of view, unnumbered mode and/or using IA_NA are not options since the system architecture does not support either of those. If the CE router does not support pd-exclude and still, against 3GPP specifications, attempts prefix delegation the outcome is undefined. The 3GPP specs say today "The UE shall include OPTION_PD_EXCLUDE option code in an OPTION_ORO option.." etc. 3GPP specs also mandate pd-exclude for a delegating router (GGSN/PGW) "Prefix exclusion procedures shall follow draft-ietf-.." However, the delegating router could always neglect OPTION_PD_EXCLUDE since draft-ietf-dhc-pd-exclude gives you that possibility. Still, the delegating router shall guarantee the delegated prefix and the cellular "WAN link" prefix aggregation requirement (this is kind of hard requirement). How it is then done is vendor specific. > If there are numerous operators who intend to use PD-exclude and won=92t= support non-PD-exclude CE routers, then I agree it=92s a MUST/SHALL. If = these networks will also provide support for non-PD-exclude CE routers, = then I think SHOULD would be reasonable. For a CE router that is never going to use e.g. 3GPP WAN link, having to implement pd-exclude is unnecessary. In that sense I could agree on SHOULD. If the CE router has a chance for e.g. 3GPP WAN link, then it is MUST. Which language choice is more safe? - Jouni > Barbara > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Teemu Savolainen > Sent: Friday, February 17, 2012 3:43 AM > To: v6ops@ietf.org > Subject: [v6ops] PD-exclude was approved by the IESG -> should be = included into 6204bis > =20 > Hi v6ops, >=20 > You may have already noticed that draft-ietf-dhc-pd-exclude-04 was = yesterday approved by the IESG. >=20 > I would like to add to the draft-ietf-v6ops-6204bis section 4.2 a new = requirement (to W-4, or maybe to the WPD-x series) that says support for = pd-exclude is a SHALL for IPv6 CE router.=20 >=20 > Best regards, >=20 > Teemu >=20 >=20 > FYI: --- > State changed to Approved-announcement to be sent from IESG = Evaluation. >=20 > ID Tracker URL: = http://datatracker.ietf.org/doc/draft-ietf-dhc-pd-exclude/ >=20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From akapoor@cisco.com Tue Feb 28 02:52:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B8921F8606 for ; Tue, 28 Feb 2012 02:52:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRJ8m05+eEgN for ; Tue, 28 Feb 2012 02:52:13 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 01C6721F85FF for ; Tue, 28 Feb 2012 02:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=akapoor@cisco.com; l=1830; q=dns/txt; s=iport; t=1330426333; x=1331635933; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version:content-transfer-encoding; bh=q1E9yLDnhiTwm/bUv/GeDbS0+wyNcmJ/4A7hxtFIm+M=; b=jaKeuUL26seyIsNfzFPNebPEEgmU4RoB+mvKJRJIsc6znX1/Awp+uS+o RNshqEWEsfU7cempzLQug0oCvVTtEbkW0rmzPgqCiArpz+Xj6BI9xeAyI qyuFx6vDOrygQWMEL/JWPnkDUbrTEt7nY7TKt/v0wHxQ4vf/mOVfGGZOt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAJywTE9Io8UY/2dsb2JhbABDhTmvR4FzAQEBAwESARAEUhALEggCBRMOAgIPAQQ1FAsqh18FoHABjGWKTIEvi2cQAggCCgEGBAcCBgcLCgEDAQEDAgYDAoRACEUDGwMBC4JYgRYEiE2McpJ4gUwI X-IronPort-AV: E=Sophos;i="4.73,495,1325462400"; d="scan'208";a="6558975" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 28 Feb 2012 10:52:11 +0000 Received: from fatcat.cisco.com ([64.103.156.87]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1SAqAbB001125; Tue, 28 Feb 2012 10:52:11 GMT From: Anupam Kapoor To: jouni korhonen References: <2D09D61DDFA73D4C884805CC7865E611043C0B@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Tue, 28 Feb 2012 16:20:09 +0530 In-Reply-To: (jouni korhonen's message of "Tue, 28 Feb 2012 10:49:38 +0200") Message-ID: <87sjhv44gu.fsf@fatcat.cisco.com> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] PD-exclude was approved by the IESG -> should be included into 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 10:52:15 -0000 korhonen> Barbara, korhonen> On Feb 24, 2012, at 7:00 PM, STARK, BARBARA H wrote: >> I have a question as to whether this needs to be a MUST/SHALL or can it= be a SHOULD. >> In my mind, the answer to this depends on how operators who intend to >> use PD-exclude will treat CE routers that do not support PD-exclude. >> Will they refuse to offer IA_PD (so the non-PD-exclude-supporting CE >> router is useless for attachment to that access network), or will they >> offer IA_PD and either also offer IA_NA (from a different prefix) or >> let the CE router operate in =E2=80=9Cunnumbered mode=E2=80=9D? korhonen> I cannot speak on behalf of others but from 3GPP networks point korhonen> of view, unnumbered mode and/or using IA_NA are not options since korhonen> the system architecture does not support either of those. ,---- | korhonen> If the CE router does not support pd-exclude and still, against | korhonen> 3GPP specifications, attempts prefix delegation the outcome is | korhonen> undefined. The 3GPP specs say today "The UE shall include | korhonen> OPTION_PD_EXCLUDE option code in an OPTION_ORO option.." etc. `---- here are the relevant lines from sec:5.3.1.2.6 of 23.401 (ver:10.6.0) =20=20=20=20=20=20 ,---- | If the UE had indicated that it supports prefix exclusion and the | prefix to be delegated to the UE includes the /64 prefix that was | allocated to the PDN Connection, the PDN GW shall=20=20 | utilise the prefix exclusion feature as specified for DHCPv6 Prefix | Delegation in draft-ietf-dhc-pd-exclude-00 [70]=20 `---- from which it seems (to me at least) that ue *may* support prefix-exclusion i.e. it is not mandatory for the ue to send 'PD-EXCLUDE' if supports prefix-delegation. kind regards anupam From jouni.nospam@gmail.com Tue Feb 28 03:45:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64CE21F8615 for ; Tue, 28 Feb 2012 03:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNncA8pkBscp for ; Tue, 28 Feb 2012 03:45:53 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id BD14421F860D for ; Tue, 28 Feb 2012 03:45:52 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so2123922wgb.1 for ; Tue, 28 Feb 2012 03:45:51 -0800 (PST) Received-SPF: pass (google.com: domain of jouni.nospam@gmail.com designates 10.180.24.7 as permitted sender) client-ip=10.180.24.7; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jouni.nospam@gmail.com designates 10.180.24.7 as permitted sender) smtp.mail=jouni.nospam@gmail.com; dkim=pass header.i=jouni.nospam@gmail.com Received: from mr.google.com ([10.180.24.7]) by 10.180.24.7 with SMTP id q7mr37679682wif.14.1330429551992 (num_hops = 1); Tue, 28 Feb 2012 03:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=1/0dgvpxLw5qSaLTxHkAf4VUVvW+2l52W7Nc8xSCpY8=; b=czXCjPgFPCl9NByvtWIFHSOr6tleblrlVWOWphqwASD+mLz+1f4IJZtJoWzVrmRZzl 9Jpo9Nhj8K9S4uM1Eh3Kmd/s3IDAorMOh2VfSvWNJGctE17mlGVk8JcVi8m4XtVWIcfc Hcw0IleFh4BkgZmZLBbP79U65IQYry/QquA2Y= Received: by 10.180.24.7 with SMTP id q7mr29894615wif.14.1330429551952; Tue, 28 Feb 2012 03:45:51 -0800 (PST) Received: from [10.255.132.9] ([192.100.123.77]) by mx.google.com with ESMTPS id bg3sm28249997wib.10.2012.02.28.03.45.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Feb 2012 03:45:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <87sjhv44gu.fsf@fatcat.cisco.com> Date: Tue, 28 Feb 2012 13:45:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0116E712-C8CB-48DE-A53A-E33E9F799592@gmail.com> References: <2D09D61DDFA73D4C884805CC7865E611043C0B@GAALPA1MSGUSR9N.ITServices.sbc.com> <87sjhv44gu.fsf@fatcat.cisco.com> To: Anupam Kapoor X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] PD-exclude was approved by the IESG -> should be included into 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 11:45:53 -0000 > ,---- > | korhonen> If the CE router does not support pd-exclude and still, = against > | korhonen> 3GPP specifications, attempts prefix delegation the = outcome is > | korhonen> undefined. The 3GPP specs say today "The UE shall include > | korhonen> OPTION_PD_EXCLUDE option code in an OPTION_ORO option.." = etc. > `---- > here are the relevant lines from sec:5.3.1.2.6 of 23.401 (ver:10.6.0) >=20 > ,---- > | If the UE had indicated that it supports prefix exclusion and = the > | prefix to be delegated to the UE includes the /64 prefix that = was > | allocated to the PDN Connection, the PDN GW shall =20 > | utilise the prefix exclusion feature as specified for DHCPv6 = Prefix > | Delegation in draft-ietf-dhc-pd-exclude-00 [70]=20 > `---- > from which it seems (to me at least) that ue *may* support > prefix-exclusion i.e. it is not mandatory for the ue to send > 'PD-EXCLUDE' if supports prefix-delegation. Hmm.. you could actually be right with that interpretation :) That would then mean SHOULD is appropriate.=20 - Jouni >=20 > kind regards > anupam From brian.e.carpenter@gmail.com Tue Feb 28 15:18:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D24921E8045 for ; Tue, 28 Feb 2012 15:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.138 X-Spam-Level: X-Spam-Status: No, score=-103.138 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxXFa0GxQkeN for ; Tue, 28 Feb 2012 15:18:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB59721E804F for ; Tue, 28 Feb 2012 15:18:33 -0800 (PST) Received: by iagf6 with SMTP id f6so10201792iag.31 for ; Tue, 28 Feb 2012 15:18:33 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.104.166 as permitted sender) client-ip=10.50.104.166; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.104.166 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.50.104.166]) by 10.50.104.166 with SMTP id gf6mr4828886igb.35.1330471113636 (num_hops = 1); Tue, 28 Feb 2012 15:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UXPEr8rD0a+chpc4XFklZe7ZednUuwj++BHY+Rq+eE4=; b=I9AbAHNQBZzt0MhAOLbdklD8mcbhwWEm+5Xqj7QXirgXjC8qgVuccCe3BbqftCRG79 JQdCS8zxDyWcK3zaJtnImvYVrR127nscVW35cRzPxxsMDFcOLXT+WtnDISfJd2NNKeZl gtnDR/Si0Y+wYjI8wgCzNqkV0fpfRe60cUbVA= Received: by 10.50.104.166 with SMTP id gf6mr3996365igb.35.1330471113551; Tue, 28 Feb 2012 15:18:33 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id j4sm13820583igq.5.2012.02.28.15.18.30 (version=SSLv3 cipher=OTHER); Tue, 28 Feb 2012 15:18:32 -0800 (PST) Message-ID: <4F4D60C5.9050901@gmail.com> Date: Wed, 29 Feb 2012 12:18:29 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel jaeggli References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> <4F492882.4020800@gmail.com> <4F49333B.8090306@bogus.com> In-Reply-To: <4F49333B.8090306@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 23:18:39 -0000 Joel, On 2012-02-26 08:15, Joel jaeggli wrote: > On 2/25/12 10:29 , Brian E Carpenter wrote: >> "some level [of] ipv6 support" > > I'm going to be provocative since I've had my third cup of coffee this > morning. You could try camomile. > > An f5 which is a complex appliance has a rather different feature set > that nginx which is a http/pop/imap alg that runs on an off-the-shelf > linux box. > > I'm missing features on the f5 like layer3 ecmp routes with ipv6 bgp > sessions, that's kinda far down in the weeds feature parity-wise > compared to, "can I use it for l4 proxy or l7 session termination, can I > hash connections across LBs" which it does fine. > > The question with rehabilitating the flow label for use with load > balancers is imho orthagional to the question of feature parity with > ipv4 load balancers. True. The point is to use the flow label to make LBs work better. What I've learnt from Willy Tarreau is that biggest problem for load balancers is when the client's address/port for a given session changes, but the LB still has to identify each packet of the flow at line speed to guarantee session persistence. > 3697 behavior I imagine still dominates, which implies that if I myself > am rewriting the flow label for my own purposes that I'm doing so on the > basis of other criterion (for example the 5 tuple, class of service, > origin interface, evil bit etc) which means I could just as well make > the lb decision on that basis as well. The behaviour that dominates is default (flow label =0) and that won't change unless host stack maintainers see a good reason to change it. > My reading of 6346 is that I'm now more or less free to do what I want > with the flow label, Not quite, there are clear recommendations for default actions, but we have dropped the idea that it's genuinely immutable, and that does allow for innovative use. But the real benefit will come when sources set it. and I have access to hardware forwarding platforms > that can rewrite anything in the first 256 bytes of a packet at line > rate, so hey, like with DSCP bits in ipv4 if I'm going to the use them > for my own purpose the first thing I'll do is rewrite every externally > set value on ingress because I can't trust them. You don't particularly need to trust them, since they aren't used for e2e signalling. But yes, if you are worried about attacks on the flow label itself, the border device could rewrite them. However, that *will* defeat the kind of advanced usage Willy is thinking of to support persistence. What could I do with 20 > bits that the routers can ignore and that doesn't require a new header? > The flow label is big enough bit field to do this in spades: > > http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf Well, the way they use the DSCP is unconventional, but fundamentally harmless as far as I can see. And yes, in the domain between a LB and the target server, I can't see any real harm in twiddling the flow label bits too. It's actually orthogonal to what we talk about in the subject draft, which happens before the packet leaves the load balancer. Brian > in fact it more bits than I've ever had to hack about with in an ip > header, so hey go crazy. > > joel >> I can assure you that this is only just filtering out to >> the more remote ends of the Internet, but I agree that it's >> happening. However, this draft looks a little beyond current >> practice. >> >> Regards >> Brian >> >> On 2012-02-25 22:34, Joel jaeggli wrote: >>> On 2/24/12 13:17 , Brian E Carpenter wrote: >>>> It seems from the lack of discussion that nobody in v6ops cares >>>> about server load balancers. I find this strange, since when >>>> I talk to enterprise operations folk, they always flag load >>>> balancers as one of the main holdups with supporting IPv6. >>> I doubt that very much... >>> >>> Every load balancer platform that I have access too today has some level >>> ipv6 support. f5 a10 netscalar, along with ha-proxy and nginx are all in >>> the field providing production level ipv6 traffic delivery. >>> >>> I would think given the topic that the involvement of the flow label is >>> implicated the in lack of excitement. >>> >>>> The author's won't drop this draft, but unless the WG shows >>>> some sign of interest, we will take it elsewhere. >>>> >>>> Regards >>>> Brian >>>> >>>> On 2012-02-09 09:05, Brian E Carpenter wrote: >>>>> Every serious content provider runs load balancers. >>>>> >>>>> Missing IPv6 support in load balancers has been a delaying factor >>>>> for IPv6 deployment. >>>>> >>>>> This draft discusses the only aspect of IPv6 that seems to be >>>>> significantly different from IPv4: the flow label may enhance load >>>>> balancer efficiency. >>>>> >>>>> The authors suggest that the topic belongs in v6ops because it >>>>> potentially affects all large server operators, but calls for no >>>>> protocol changes. We'd like to know who agrees or disagrees. >>>>> >>>>> Regards >>>>> Brian Carpenter >>>>> >>>>> On 2012-01-30 11:33, Brian E Carpenter wrote: >>>>>> Hi, >>>>>> >>>>>> I'm not seeing more comments on this. The authors would like advice: >>>>>> >>>>>> Should we ask for v6ops to adopt this? >>>>>> Should we ask another WG to adopt it? >>>>>> Should we propose it as an individual submission? >>>>>> Should we forget about it? >>>>>> >>>>>> Regards >>>>>> Brian Carpenter >>>>>> >>>>>> On 2012-01-18 10:14, Brian E Carpenter wrote: >>>>>>> This is a significant update since the version discussed in Taipei, >>>>>>> with an additional author who is a practitioner in the field, >>>>>>> and incorporating comments from implementors. >>>>>>> >>>>>>> Of course we would like more feedback. For the moment I suggest >>>>>>> discussion on the v6ops list, although that may not be the >>>>>>> final home for this draft. >>>>>>> >>>>>>> Please keep Willy on CC since I'm not sure he's on this list. >>>>>>> >>>>>>> Brian Carpenter >>>>>>> >>>>>>> -------- Original Message -------- >>>>>>> Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt >>>>>>> Date: Tue, 17 Jan 2012 12:40:05 -0800 >>>>>>> From: internet-drafts@ietf.org >>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>> To: i-d-announce@ietf.org >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>>> >>>>>>> Title : Using the IPv6 Flow Label for Server Load Balancing >>>>>>> Author(s) : Brian Carpenter >>>>>>> Sheng Jiang >>>>>>> Willy Tarreau >>>>>>> Filename : draft-carpenter-v6ops-label-balance-01.txt >>>>>>> Pages : 12 >>>>>>> Date : 2012-01-17 >>>>>>> >>>>>>> This document describes how the IPv6 flow label can be used in >>>>>>> support of layer 3/4 load distribution and balancing for large server >>>>>>> farms. >>>>>>> >>>>>>> >>>>>>> A URL for this Internet-Draft is: >>>>>>> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> This Internet-Draft can be retrieved at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>> >>>>>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> > > From joelja@bogus.com Tue Feb 28 15:37:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CEA21E8046 for ; Tue, 28 Feb 2012 15:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.192 X-Spam-Level: X-Spam-Status: No, score=-102.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XYiE+-GKi7g for ; Tue, 28 Feb 2012 15:37:26 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 04C3421E8045 for ; Tue, 28 Feb 2012 15:37:25 -0800 (PST) Received: from Joels-MacBook-Pro.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q1SNbMoN002081 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 28 Feb 2012 23:37:23 GMT (envelope-from joelja@bogus.com) Message-ID: <4F4D652C.9060508@bogus.com> Date: Tue, 28 Feb 2012 15:37:16 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> <4F492882.4020800@gmail.com> <4F49333B.8090306@bogus.com> <4F4D60C5.9050901@gmail.com> In-Reply-To: <4F4D60C5.9050901@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 28 Feb 2012 23:37:23 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 23:37:32 -0000 On 2/28/12 15:18 , Brian E Carpenter wrote: > Joel, > > On 2012-02-26 08:15, Joel jaeggli wrote: >> On 2/25/12 10:29 , Brian E Carpenter wrote: >>> "some level [of] ipv6 support" >> >> I'm going to be provocative since I've had my third cup of coffee this >> morning. > > You could try camomile. > >> >> An f5 which is a complex appliance has a rather different feature set >> that nginx which is a http/pop/imap alg that runs on an off-the-shelf >> linux box. >> >> I'm missing features on the f5 like layer3 ecmp routes with ipv6 bgp >> sessions, that's kinda far down in the weeds feature parity-wise >> compared to, "can I use it for l4 proxy or l7 session termination, can I >> hash connections across LBs" which it does fine. >> >> The question with rehabilitating the flow label for use with load >> balancers is imho orthagional to the question of feature parity with >> ipv4 load balancers. > > True. The point is to use the flow label to make LBs work better. What > I've learnt from Willy Tarreau is that biggest problem for load balancers > is when the client's address/port for a given session changes, but the > LB still has to identify each packet of the flow at line speed to guarantee > session persistence. To be clear though if the source ip/port changes that's a new flow... e.g. in the expected case of unicast tcp we need another handshake to restablish a session with a new source port. It may be not be a new session from the vantage point of the application layer which may well maintain persistence across connections (which cookies, http, magic, or otherwise are particularly suitable for). So I'm not sure I grok that's a case where you'd expect the flow label to remain constant when I have to establish a new connection. >> 3697 behavior I imagine still dominates, which implies that if I myself >> am rewriting the flow label for my own purposes that I'm doing so on the >> basis of other criterion (for example the 5 tuple, class of service, >> origin interface, evil bit etc) which means I could just as well make >> the lb decision on that basis as well. > > The behaviour that dominates is default (flow label =0) and that won't change > unless host stack maintainers see a good reason to change it. > >> My reading of 6346 is that I'm now more or less free to do what I want >> with the flow label, > > Not quite, there are clear recommendations for default actions, but we have > dropped the idea that it's genuinely immutable, and that does allow for > innovative use. But the real benefit will come when sources set it. > > and I have access to hardware forwarding platforms >> that can rewrite anything in the first 256 bytes of a packet at line >> rate, so hey, like with DSCP bits in ipv4 if I'm going to the use them >> for my own purpose the first thing I'll do is rewrite every externally >> set value on ingress because I can't trust them. > > You don't particularly need to trust them, since they aren't used > for e2e signalling. But yes, if you are worried about attacks on > the flow label itself, the border device could rewrite them. However, > that *will* defeat the kind of advanced usage Willy is thinking of > to support persistence. > > What could I do with 20 >> bits that the routers can ignore and that doesn't require a new header? >> The flow label is big enough bit field to do this in spades: >> >> http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf > > Well, the way they use the DSCP is unconventional, but fundamentally > harmless as far as I can see. And yes, in the domain between a LB > and the target server, I can't see any real harm in twiddling the > flow label bits too. It's actually orthogonal to what we talk about > in the subject draft, which happens before the packet leaves the > load balancer. > > Brian > >> in fact it more bits than I've ever had to hack about with in an ip >> header, so hey go crazy. >> >> joel >>> I can assure you that this is only just filtering out to >>> the more remote ends of the Internet, but I agree that it's >>> happening. However, this draft looks a little beyond current >>> practice. >>> >>> Regards >>> Brian >>> >>> On 2012-02-25 22:34, Joel jaeggli wrote: >>>> On 2/24/12 13:17 , Brian E Carpenter wrote: >>>>> It seems from the lack of discussion that nobody in v6ops cares >>>>> about server load balancers. I find this strange, since when >>>>> I talk to enterprise operations folk, they always flag load >>>>> balancers as one of the main holdups with supporting IPv6. >>>> I doubt that very much... >>>> >>>> Every load balancer platform that I have access too today has some level >>>> ipv6 support. f5 a10 netscalar, along with ha-proxy and nginx are all in >>>> the field providing production level ipv6 traffic delivery. >>>> >>>> I would think given the topic that the involvement of the flow label is >>>> implicated the in lack of excitement. >>>> >>>>> The author's won't drop this draft, but unless the WG shows >>>>> some sign of interest, we will take it elsewhere. >>>>> >>>>> Regards >>>>> Brian >>>>> >>>>> On 2012-02-09 09:05, Brian E Carpenter wrote: >>>>>> Every serious content provider runs load balancers. >>>>>> >>>>>> Missing IPv6 support in load balancers has been a delaying factor >>>>>> for IPv6 deployment. >>>>>> >>>>>> This draft discusses the only aspect of IPv6 that seems to be >>>>>> significantly different from IPv4: the flow label may enhance load >>>>>> balancer efficiency. >>>>>> >>>>>> The authors suggest that the topic belongs in v6ops because it >>>>>> potentially affects all large server operators, but calls for no >>>>>> protocol changes. We'd like to know who agrees or disagrees. >>>>>> >>>>>> Regards >>>>>> Brian Carpenter >>>>>> >>>>>> On 2012-01-30 11:33, Brian E Carpenter wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm not seeing more comments on this. The authors would like advice: >>>>>>> >>>>>>> Should we ask for v6ops to adopt this? >>>>>>> Should we ask another WG to adopt it? >>>>>>> Should we propose it as an individual submission? >>>>>>> Should we forget about it? >>>>>>> >>>>>>> Regards >>>>>>> Brian Carpenter >>>>>>> >>>>>>> On 2012-01-18 10:14, Brian E Carpenter wrote: >>>>>>>> This is a significant update since the version discussed in Taipei, >>>>>>>> with an additional author who is a practitioner in the field, >>>>>>>> and incorporating comments from implementors. >>>>>>>> >>>>>>>> Of course we would like more feedback. For the moment I suggest >>>>>>>> discussion on the v6ops list, although that may not be the >>>>>>>> final home for this draft. >>>>>>>> >>>>>>>> Please keep Willy on CC since I'm not sure he's on this list. >>>>>>>> >>>>>>>> Brian Carpenter >>>>>>>> >>>>>>>> -------- Original Message -------- >>>>>>>> Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt >>>>>>>> Date: Tue, 17 Jan 2012 12:40:05 -0800 >>>>>>>> From: internet-drafts@ietf.org >>>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>>> To: i-d-announce@ietf.org >>>>>>>> >>>>>>>> >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>>>> >>>>>>>> Title : Using the IPv6 Flow Label for Server Load Balancing >>>>>>>> Author(s) : Brian Carpenter >>>>>>>> Sheng Jiang >>>>>>>> Willy Tarreau >>>>>>>> Filename : draft-carpenter-v6ops-label-balance-01.txt >>>>>>>> Pages : 12 >>>>>>>> Date : 2012-01-17 >>>>>>>> >>>>>>>> This document describes how the IPv6 flow label can be used in >>>>>>>> support of layer 3/4 load distribution and balancing for large server >>>>>>>> farms. >>>>>>>> >>>>>>>> >>>>>>>> A URL for this Internet-Draft is: >>>>>>>> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>>>>>> >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>> >>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>> >> >> > From hesham@elevatemobile.com Tue Feb 28 15:55:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD62721E806C for ; Tue, 28 Feb 2012 15:55:00 -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, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sMBHU+wfxxJ for ; Tue, 28 Feb 2012 15:54:54 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9680021E8061 for ; Tue, 28 Feb 2012 15:54:51 -0800 (PST) Received: from [120.144.187.119] (helo=[10.0.0.59]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1S2Wrl-0000Zg-5F; Wed, 29 Feb 2012 10:53:58 +1100 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 29 Feb 2012 10:53:47 +1100 From: Hesham Soliman To: Joel jaeggli , Brian E Carpenter Message-ID: Thread-Topic: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] In-Reply-To: <4F4D652C.9060508@bogus.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 23:55:01 -0000 >>> >>> >>> >>> An f5 which is a complex appliance has a rather different feature set >>> that nginx which is a http/pop/imap alg that runs on an off-the-shelf >>> linux box. >>> >>> I'm missing features on the f5 like layer3 ecmp routes with ipv6 bgp >>> sessions, that's kinda far down in the weeds feature parity-wise >>> compared to, "can I use it for l4 proxy or l7 session termination, can >>>I >>> hash connections across LBs" which it does fine. >>> >>> The question with rehabilitating the flow label for use with load >>> balancers is imho orthagional to the question of feature parity with >>> ipv4 load balancers. >> >> True. The point is to use the flow label to make LBs work better. What >> I've learnt from Willy Tarreau is that biggest problem for load >>balancers >> is when the client's address/port for a given session changes, but the >> LB still has to identify each packet of the flow at line speed to >>guarantee >> session persistence. > >To be clear though if the source ip/port changes that's a new flow... >e.g. in the expected case of unicast tcp we need another handshake to >restablish a session with a new source port. > >It may be not be a new session from the vantage point of the application >layer which may well maintain persistence across connections (which >cookies, http, magic, or otherwise are particularly suitable for). > >So I'm not sure I grok that's a case where you'd expect the flow label >to remain constant when I have to establish a new connection. => Agreed. Can't see how a flow label can help here. It's not globally unique! Hesham > >>> 3697 behavior I imagine still dominates, which implies that if I myself >>> am rewriting the flow label for my own purposes that I'm doing so on >>>the >>> basis of other criterion (for example the 5 tuple, class of service, >>> origin interface, evil bit etc) which means I could just as well make >>> the lb decision on that basis as well. >> >> The behaviour that dominates is default (flow label =0) and that won't >>change >> unless host stack maintainers see a good reason to change it. >> >>> My reading of 6346 is that I'm now more or less free to do what I want >>> with the flow label, >> >> Not quite, there are clear recommendations for default actions, but we >>have >> dropped the idea that it's genuinely immutable, and that does allow for >> innovative use. But the real benefit will come when sources set it. >> >> and I have access to hardware forwarding platforms >>> that can rewrite anything in the first 256 bytes of a packet at line >>> rate, so hey, like with DSCP bits in ipv4 if I'm going to the use them >>> for my own purpose the first thing I'll do is rewrite every externally >>> set value on ingress because I can't trust them. >> >> You don't particularly need to trust them, since they aren't used >> for e2e signalling. But yes, if you are worried about attacks on >> the flow label itself, the border device could rewrite them. However, >> that *will* defeat the kind of advanced usage Willy is thinking of >> to support persistence. >> >> What could I do with 20 >>> bits that the routers can ignore and that doesn't require a new header? >>> The flow label is big enough bit field to do this in spades: >>> >>> >>>http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk4 >>>5.nanog51-Schaumann.pdf >> >> Well, the way they use the DSCP is unconventional, but fundamentally >> harmless as far as I can see. And yes, in the domain between a LB >> and the target server, I can't see any real harm in twiddling the >> flow label bits too. It's actually orthogonal to what we talk about >> in the subject draft, which happens before the packet leaves the >> load balancer. >> >> Brian >> >>> in fact it more bits than I've ever had to hack about with in an ip >>> header, so hey go crazy. >>> >>> joel >>>> I can assure you that this is only just filtering out to >>>> the more remote ends of the Internet, but I agree that it's >>>> happening. However, this draft looks a little beyond current >>>> practice. >>>> >>>> Regards >>>> Brian >>>> >>>> On 2012-02-25 22:34, Joel jaeggli wrote: >>>>> On 2/24/12 13:17 , Brian E Carpenter wrote: >>>>>> It seems from the lack of discussion that nobody in v6ops cares >>>>>> about server load balancers. I find this strange, since when >>>>>> I talk to enterprise operations folk, they always flag load >>>>>> balancers as one of the main holdups with supporting IPv6. >>>>> I doubt that very much... >>>>> >>>>> Every load balancer platform that I have access too today has some >>>>>level >>>>> ipv6 support. f5 a10 netscalar, along with ha-proxy and nginx are >>>>>all in >>>>> the field providing production level ipv6 traffic delivery. >>>>> >>>>> I would think given the topic that the involvement of the flow label >>>>>is >>>>> implicated the in lack of excitement. >>>>> >>>>>> The author's won't drop this draft, but unless the WG shows >>>>>> some sign of interest, we will take it elsewhere. >>>>>> >>>>>> Regards >>>>>> Brian >>>>>> >>>>>> On 2012-02-09 09:05, Brian E Carpenter wrote: >>>>>>> Every serious content provider runs load balancers. >>>>>>> >>>>>>> Missing IPv6 support in load balancers has been a delaying factor >>>>>>> for IPv6 deployment. >>>>>>> >>>>>>> This draft discusses the only aspect of IPv6 that seems to be >>>>>>> significantly different from IPv4: the flow label may enhance load >>>>>>> balancer efficiency. >>>>>>> >>>>>>> The authors suggest that the topic belongs in v6ops because it >>>>>>> potentially affects all large server operators, but calls for no >>>>>>> protocol changes. We'd like to know who agrees or disagrees. >>>>>>> >>>>>>> Regards >>>>>>> Brian Carpenter >>>>>>> >>>>>>> On 2012-01-30 11:33, Brian E Carpenter wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm not seeing more comments on this. The authors would like >>>>>>>>advice: >>>>>>>> >>>>>>>> Should we ask for v6ops to adopt this? >>>>>>>> Should we ask another WG to adopt it? >>>>>>>> Should we propose it as an individual submission? >>>>>>>> Should we forget about it? >>>>>>>> >>>>>>>> Regards >>>>>>>> Brian Carpenter >>>>>>>> >>>>>>>> On 2012-01-18 10:14, Brian E Carpenter wrote: >>>>>>>>> This is a significant update since the version discussed in >>>>>>>>>Taipei, >>>>>>>>> with an additional author who is a practitioner in the field, >>>>>>>>> and incorporating comments from implementors. >>>>>>>>> >>>>>>>>> Of course we would like more feedback. For the moment I suggest >>>>>>>>> discussion on the v6ops list, although that may not be the >>>>>>>>> final home for this draft. >>>>>>>>> >>>>>>>>> Please keep Willy on CC since I'm not sure he's on this list. >>>>>>>>> >>>>>>>>> Brian Carpenter >>>>>>>>> >>>>>>>>> -------- Original Message -------- >>>>>>>>> Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt >>>>>>>>> Date: Tue, 17 Jan 2012 12:40:05 -0800 >>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>> >>>>>>>>> >>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>Internet-Drafts directories. >>>>>>>>> >>>>>>>>> Title : Using the IPv6 Flow Label for Server Load >>>>>>>>>Balancing >>>>>>>>> Author(s) : Brian Carpenter >>>>>>>>> Sheng Jiang >>>>>>>>> Willy Tarreau >>>>>>>>> Filename : draft-carpenter-v6ops-label-balance-01.txt >>>>>>>>> Pages : 12 >>>>>>>>> Date : 2012-01-17 >>>>>>>>> >>>>>>>>> This document describes how the IPv6 flow label can be used in >>>>>>>>> support of layer 3/4 load distribution and balancing for >>>>>>>>>large server >>>>>>>>> farms. >>>>>>>>> >>>>>>>>> >>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>> >>>>>>>>>http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-ba >>>>>>>>>lance-01.txt >>>>>>>>> >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>> >>>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>>> >>>>>>>>>ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-bal >>>>>>>>>ance-01.txt >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>> _______________________________________________ >>>>>> v6ops mailing list >>>>>> v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>> >>>>> >>> >>> >> > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Tue Feb 28 16:20:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673E921F85EC for ; Tue, 28 Feb 2012 16:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.135 X-Spam-Level: X-Spam-Status: No, score=-103.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prQSZy1s+xxj for ; Tue, 28 Feb 2012 16:20:17 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 311AC21F8566 for ; Tue, 28 Feb 2012 16:20:17 -0800 (PST) Received: by obbeh20 with SMTP id eh20so3977283obb.31 for ; Tue, 28 Feb 2012 16:20:16 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.36.194 as permitted sender) client-ip=10.50.36.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.50.36.194 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.50.36.194]) by 10.50.36.194 with SMTP id s2mr4887017igj.59.1330474816820 (num_hops = 1); Tue, 28 Feb 2012 16:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PHhvFGZkCxVvFd4AkxuPmALf50+vTgtZ5A54zyip+74=; b=TXztPZg0dHc7+Vos3v+JlCqoKYGsHSWLQzTomlmCqkEB5tUsIL9E8oNT9W4+It278q KrOFqjYzUsi6wJOBWRBgaAWxpWDZS9/fb+2pnekTOBzF8ZmIf/KbE/c9F0p9uA5wN3/g m+UQvQUe6gaXp5awvwoHwjTuIfarPYK9LZbM4= Received: by 10.50.36.194 with SMTP id s2mr4064700igj.59.1330474816736; Tue, 28 Feb 2012 16:20:16 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id ub10sm13921493igb.7.2012.02.28.16.20.13 (version=SSLv3 cipher=OTHER); Tue, 28 Feb 2012 16:20:15 -0800 (PST) Message-ID: <4F4D6F46.5010708@gmail.com> Date: Wed, 29 Feb 2012 13:20:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 00:20:25 -0000 On 2012-02-29 12:53, Hesham Soliman wrote: >>>> >>>> >>>> An f5 which is a complex appliance has a rather different feature set >>>> that nginx which is a http/pop/imap alg that runs on an off-the-shelf >>>> linux box. >>>> >>>> I'm missing features on the f5 like layer3 ecmp routes with ipv6 bgp >>>> sessions, that's kinda far down in the weeds feature parity-wise >>>> compared to, "can I use it for l4 proxy or l7 session termination, can >>>> I >>>> hash connections across LBs" which it does fine. >>>> >>>> The question with rehabilitating the flow label for use with load >>>> balancers is imho orthagional to the question of feature parity with >>>> ipv4 load balancers. >>> True. The point is to use the flow label to make LBs work better. What >>> I've learnt from Willy Tarreau is that biggest problem for load >>> balancers >>> is when the client's address/port for a given session changes, but the >>> LB still has to identify each packet of the flow at line speed to >>> guarantee >>> session persistence. >> To be clear though if the source ip/port changes that's a new flow... >> e.g. in the expected case of unicast tcp we need another handshake to >> restablish a session with a new source port. >> >> It may be not be a new session from the vantage point of the application >> layer which may well maintain persistence across connections (which >> cookies, http, magic, or otherwise are particularly suitable for). >> >> So I'm not sure I grok that's a case where you'd expect the flow label >> to remain constant when I have to establish a new connection. If you want to use the flow label instead of much less palatable techniques to identify the transaction, using the same flow label is indicated. But that's getting beyond v6ops scope, I fear. > > => Agreed. Can't see how a flow label can help here. It's not globally > unique! Strangely, it doesn't need to be. It doesn't matter if the load balancer happens to send two different flows to the same target server, because they happen to have the same flow label. (Which is only a 1 per million probability, since we have 20 bits.) What matters is that all the packets of the same transaction go to the same server. Brian > > Hesham > >>>> 3697 behavior I imagine still dominates, which implies that if I myself >>>> am rewriting the flow label for my own purposes that I'm doing so on >>>> the >>>> basis of other criterion (for example the 5 tuple, class of service, >>>> origin interface, evil bit etc) which means I could just as well make >>>> the lb decision on that basis as well. >>> The behaviour that dominates is default (flow label =0) and that won't >>> change >>> unless host stack maintainers see a good reason to change it. >>> >>>> My reading of 6346 is that I'm now more or less free to do what I want >>>> with the flow label, >>> Not quite, there are clear recommendations for default actions, but we >>> have >>> dropped the idea that it's genuinely immutable, and that does allow for >>> innovative use. But the real benefit will come when sources set it. >>> >>> and I have access to hardware forwarding platforms >>>> that can rewrite anything in the first 256 bytes of a packet at line >>>> rate, so hey, like with DSCP bits in ipv4 if I'm going to the use them >>>> for my own purpose the first thing I'll do is rewrite every externally >>>> set value on ingress because I can't trust them. >>> You don't particularly need to trust them, since they aren't used >>> for e2e signalling. But yes, if you are worried about attacks on >>> the flow label itself, the border device could rewrite them. However, >>> that *will* defeat the kind of advanced usage Willy is thinking of >>> to support persistence. >>> >>> What could I do with 20 >>>> bits that the routers can ignore and that doesn't require a new header? >>>> The flow label is big enough bit field to do this in spades: >>>> >>>> >>>> http://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk4 >>>> 5.nanog51-Schaumann.pdf >>> Well, the way they use the DSCP is unconventional, but fundamentally >>> harmless as far as I can see. And yes, in the domain between a LB >>> and the target server, I can't see any real harm in twiddling the >>> flow label bits too. It's actually orthogonal to what we talk about >>> in the subject draft, which happens before the packet leaves the >>> load balancer. >>> >>> Brian >>> >>>> in fact it more bits than I've ever had to hack about with in an ip >>>> header, so hey go crazy. >>>> >>>> joel >>>>> I can assure you that this is only just filtering out to >>>>> the more remote ends of the Internet, but I agree that it's >>>>> happening. However, this draft looks a little beyond current >>>>> practice. >>>>> >>>>> Regards >>>>> Brian >>>>> >>>>> On 2012-02-25 22:34, Joel jaeggli wrote: >>>>>> On 2/24/12 13:17 , Brian E Carpenter wrote: >>>>>>> It seems from the lack of discussion that nobody in v6ops cares >>>>>>> about server load balancers. I find this strange, since when >>>>>>> I talk to enterprise operations folk, they always flag load >>>>>>> balancers as one of the main holdups with supporting IPv6. >>>>>> I doubt that very much... >>>>>> >>>>>> Every load balancer platform that I have access too today has some >>>>>> level >>>>>> ipv6 support. f5 a10 netscalar, along with ha-proxy and nginx are >>>>>> all in >>>>>> the field providing production level ipv6 traffic delivery. >>>>>> >>>>>> I would think given the topic that the involvement of the flow label >>>>>> is >>>>>> implicated the in lack of excitement. >>>>>> >>>>>>> The author's won't drop this draft, but unless the WG shows >>>>>>> some sign of interest, we will take it elsewhere. >>>>>>> >>>>>>> Regards >>>>>>> Brian >>>>>>> >>>>>>> On 2012-02-09 09:05, Brian E Carpenter wrote: >>>>>>>> Every serious content provider runs load balancers. >>>>>>>> >>>>>>>> Missing IPv6 support in load balancers has been a delaying factor >>>>>>>> for IPv6 deployment. >>>>>>>> >>>>>>>> This draft discusses the only aspect of IPv6 that seems to be >>>>>>>> significantly different from IPv4: the flow label may enhance load >>>>>>>> balancer efficiency. >>>>>>>> >>>>>>>> The authors suggest that the topic belongs in v6ops because it >>>>>>>> potentially affects all large server operators, but calls for no >>>>>>>> protocol changes. We'd like to know who agrees or disagrees. >>>>>>>> >>>>>>>> Regards >>>>>>>> Brian Carpenter >>>>>>>> >>>>>>>> On 2012-01-30 11:33, Brian E Carpenter wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm not seeing more comments on this. The authors would like >>>>>>>>> advice: >>>>>>>>> >>>>>>>>> Should we ask for v6ops to adopt this? >>>>>>>>> Should we ask another WG to adopt it? >>>>>>>>> Should we propose it as an individual submission? >>>>>>>>> Should we forget about it? >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Brian Carpenter >>>>>>>>> >>>>>>>>> On 2012-01-18 10:14, Brian E Carpenter wrote: >>>>>>>>>> This is a significant update since the version discussed in >>>>>>>>>> Taipei, >>>>>>>>>> with an additional author who is a practitioner in the field, >>>>>>>>>> and incorporating comments from implementors. >>>>>>>>>> >>>>>>>>>> Of course we would like more feedback. For the moment I suggest >>>>>>>>>> discussion on the v6ops list, although that may not be the >>>>>>>>>> final home for this draft. >>>>>>>>>> >>>>>>>>>> Please keep Willy on CC since I'm not sure he's on this list. >>>>>>>>>> >>>>>>>>>> Brian Carpenter >>>>>>>>>> >>>>>>>>>> -------- Original Message -------- >>>>>>>>>> Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt >>>>>>>>>> Date: Tue, 17 Jan 2012 12:40:05 -0800 >>>>>>>>>> From: internet-drafts@ietf.org >>>>>>>>>> Reply-To: internet-drafts@ietf.org >>>>>>>>>> To: i-d-announce@ietf.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>> Internet-Drafts directories. >>>>>>>>>> >>>>>>>>>> Title : Using the IPv6 Flow Label for Server Load >>>>>>>>>> Balancing >>>>>>>>>> Author(s) : Brian Carpenter >>>>>>>>>> Sheng Jiang >>>>>>>>>> Willy Tarreau >>>>>>>>>> Filename : draft-carpenter-v6ops-label-balance-01.txt >>>>>>>>>> Pages : 12 >>>>>>>>>> Date : 2012-01-17 >>>>>>>>>> >>>>>>>>>> This document describes how the IPv6 flow label can be used in >>>>>>>>>> support of layer 3/4 load distribution and balancing for >>>>>>>>>> large server >>>>>>>>>> farms. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> A URL for this Internet-Draft is: >>>>>>>>>> >>>>>>>>>> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-ba >>>>>>>>>> lance-01.txt >>>>>>>>>> >>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>> >>>>>>>>>> This Internet-Draft can be retrieved at: >>>>>>>>>> >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-bal >>>>>>>>>> ance-01.txt >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> v6ops mailing list >>>>>>> v6ops@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>> >>>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > From hesham@elevatemobile.com Tue Feb 28 23:16:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0124B21F87FB for ; Tue, 28 Feb 2012 23:16:00 -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, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNiM+krJ1yk1 for ; Tue, 28 Feb 2012 23:15:59 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6440421F87FA for ; Tue, 28 Feb 2012 23:15:58 -0800 (PST) Received: from [60.242.128.199] (helo=[192.168.0.5]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1S2dlN-00058q-UR; Wed, 29 Feb 2012 18:15:53 +1100 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 29 Feb 2012 18:15:29 +1100 From: Hesham Soliman To: Brian E Carpenter Message-ID: Thread-Topic: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] In-Reply-To: <4F4D6F46.5010708@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 07:16:00 -0000 > >If you want to use the flow label instead of much less palatable >techniques to identify the transaction, using the same flow label >is indicated. But that's getting beyond v6ops scope, I fear. > >> >> => Agreed. Can't see how a flow label can help here. It's not globally >> unique! > >Strangely, it doesn't need to be. It doesn't matter if the load balancer >happens to send two different flows to the same target server, because >they happen to have the same flow label. (Which is only a 1 per million >probability, since we have 20 bits.) What matters is that all the >packets of the same transaction go to the same server. => Agreed again. But the point is that the flow label doesn't really buy you anything for that specific scenario because it's a new connection anyway and it can be load-balanced to any server. So, there doesn't seem to be an advantage for that scenario. Cheers, Hesham From w@1wt.eu Tue Feb 28 23:30:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C7121E8077 for ; Tue, 28 Feb 2012 23:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.267 X-Spam-Level: X-Spam-Status: No, score=-5.267 tagged_above=-999 required=5 tests=[AWL=-3.824, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQChA8VH-P2O for ; Tue, 28 Feb 2012 23:30:55 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id CA56621E8075 for ; Tue, 28 Feb 2012 23:30:54 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q1T7UjVe032688; Wed, 29 Feb 2012 08:30:45 +0100 Date: Wed, 29 Feb 2012 08:30:45 +0100 From: Willy Tarreau To: Hesham Soliman Message-ID: <20120229073045.GD32187@1wt.eu> References: <4F4D6F46.5010708@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 07:30:55 -0000 Hi, On Wed, Feb 29, 2012 at 06:15:29PM +1100, Hesham Soliman wrote: > > > >If you want to use the flow label instead of much less palatable > >techniques to identify the transaction, using the same flow label > >is indicated. But that's getting beyond v6ops scope, I fear. > > > >> > >> => Agreed. Can't see how a flow label can help here. It's not globally > >> unique! > > > >Strangely, it doesn't need to be. It doesn't matter if the load balancer > >happens to send two different flows to the same target server, because > >they happen to have the same flow label. (Which is only a 1 per million > >probability, since we have 20 bits.) What matters is that all the > >packets of the same transaction go to the same server. > > => Agreed again. But the point is that the flow label doesn't really buy > you anything for that specific scenario because it's a new connection > anyway and it can be load-balanced to any server. So, there doesn't seem > to be an advantage for that scenario. The advantage of having the flow label is to tell the load balancer what user-level session the connection belongs to so that it can forward the connection to the proper server. That's exactly what is currently done in HTTP with cookies and in SSL with SSL-ID, except that with the flow label we wouldn't have to process layer-7 information. Basically a browser would pick a random 20-bit number when opening a page and would assign this 20-bit random number to all outgoing connections to the same site, whether they're HTTP or HTTPS btw. The LB would then either hash this flow label or load-balance + stick on it, at the admin's option. The general idea is to insert a session identifier in the packets so that all packets related to a same user session can be processed equally and directed to the same place, which is the hardest thing to do right now in load-balancing. Regards, Willy From hesham@elevatemobile.com Wed Feb 29 02:43:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EF821F88EB for ; Wed, 29 Feb 2012 02:43:52 -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, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXFnJwTWJBYC for ; Wed, 29 Feb 2012 02:43:52 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id DDC1021F88E6 for ; Wed, 29 Feb 2012 02:43:51 -0800 (PST) Received: from [60.242.128.199] (helo=[192.168.0.5]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1S2h0C-0005c1-8g; Wed, 29 Feb 2012 21:43:20 +1100 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 29 Feb 2012 21:43:05 +1100 From: Hesham Soliman To: Willy Tarreau Message-ID: Thread-Topic: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] In-Reply-To: <20120229073045.GD32187@1wt.eu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 10:43:52 -0000 -----Original Message----- From: Willy Tarreau Date: Wed, 29 Feb 2012 08:30:45 +0100 To: Hesham Soliman Cc: Brian E Carpenter , IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] >Hi, > >On Wed, Feb 29, 2012 at 06:15:29PM +1100, Hesham Soliman wrote: >> > >> >If you want to use the flow label instead of much less palatable >> >techniques to identify the transaction, using the same flow label >> >is indicated. But that's getting beyond v6ops scope, I fear. >> > >> >> >> >> => Agreed. Can't see how a flow label can help here. It's not >>globally >> >> unique! >> > >> >Strangely, it doesn't need to be. It doesn't matter if the load >>balancer >> >happens to send two different flows to the same target server, because >> >they happen to have the same flow label. (Which is only a 1 per million >> >probability, since we have 20 bits.) What matters is that all the >> >packets of the same transaction go to the same server. >> >> => Agreed again. But the point is that the flow label doesn't really buy >> you anything for that specific scenario because it's a new connection >> anyway and it can be load-balanced to any server. So, there doesn't seem >> to be an advantage for that scenario. > >The advantage of having the flow label is to tell the load balancer what >user-level session the connection belongs to so that it can forward the >connection to the proper server. That's exactly what is currently done >in HTTP with cookies and in SSL with SSL-ID, except that with the flow >label we wouldn't have to process layer-7 information. => But aren't you now comparing a unique id known locally in the load balancer to the flow label? > >Basically a browser would pick a random 20-bit number when opening a >page and would assign this 20-bit random number to all outgoing >connections >to the same site, whether they're HTTP or HTTPS btw. => Is it safe enough to rely on the browser's 20 bit RNG and ignore IP addresses? The discussion was related to the change in IP address and whether the flow label helps in that case. Aside from the fact that this case is rare and probably not worth the optimisation, my contention is that the flow label doesn't help because it's not unique. >The LB would then >either hash this flow label or load-balance + stick on it, at the admin's >option. The general idea is to insert a session identifier in the packets >so that all packets related to a same user session can be processed >equally >and directed to the same place, which is the hardest thing to do right now >in load-balancing. => I don't know if this is a sound idea to be honest. I can understand the use of the flow label instead of port numbers when combined with IP addresses for load balancing. I think that's a fine thing to do. I just don't think using the flow label alone as a session id is such a good idea given the reliance on its uniqueness. It seems to optimise for a rare case and for a small benefit. Hesham > >Regards, >Willy > From w@1wt.eu Wed Feb 29 05:39:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480E021F8790 for ; Wed, 29 Feb 2012 05:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.534 X-Spam-Level: X-Spam-Status: No, score=-5.534 tagged_above=-999 required=5 tests=[AWL=-3.491, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4trZJhbSE2db for ; Wed, 29 Feb 2012 05:38:59 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 30E1E21F878E for ; Wed, 29 Feb 2012 05:38:57 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q1TDcmbH002251; Wed, 29 Feb 2012 14:38:48 +0100 Date: Wed, 29 Feb 2012 14:38:48 +0100 From: Willy Tarreau To: Hesham Soliman Message-ID: <20120229133848.GB2171@1wt.eu> References: <20120229073045.GD32187@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 13:39:00 -0000 On Wed, Feb 29, 2012 at 09:43:05PM +1100, Hesham Soliman wrote: > >The advantage of having the flow label is to tell the load balancer what > >user-level session the connection belongs to so that it can forward the > >connection to the proper server. That's exactly what is currently done > >in HTTP with cookies and in SSL with SSL-ID, except that with the flow > >label we wouldn't have to process layer-7 information. > > => But aren't you now comparing a unique id known locally in the load > balancer to the flow label? The goal would be to use the flow label as a session ID. Not a *unique* ID since it won't be unique due to its small size. Just a random enough ID to ensure a smooth enough distribution. > >Basically a browser would pick a random 20-bit number when opening a > >page and would assign this 20-bit random number to all outgoing > >connections > >to the same site, whether they're HTTP or HTTPS btw. > > > => Is it safe enough to rely on the browser's 20 bit RNG and ignore IP > addresses? I'd say it differently. It's safe to rely on anything but the IP address. One user != one IP address. It's only an approximation which is valid enough where it's only used for optimization, but not where user session stickiness is required. For instance, hashing a source IP address is fine to load-balance an SSL farm, because most of the users will remain on the same SSL endpoint, and the small part of those who will constantly change will just experience a minor degradation which is not a show stopper. But it's totally different when you want to ensure that once you log into a server you need to remain on this one until you click the "logout" button, because this time you cannot accept to drop connections for even 1% of your visitors. That's why LBs mostly rely on cookies and have to ignore IP addresses for this task. With a flow label, we have a lower layer alternative to stickiness cookies. > The discussion was related to the change in IP address and whether the > flow label helps in that case. Yes precisely it does help. If you make it possible for the client to set the flow label on purpose on outgoing connections, and you make the LBs only rely on the flow label, then you're not sensitive to IP address changes anymore. These ones happen at enterprise proxies and in the mobile world where it's very common to lose access after some idle time. > Aside from the fact that this case is rare and probably not worth the > optimisation, my contention is that the flow label doesn't help because > it's not unique. We don't need unicity (and we don't even want it). We need a large enough value so that not everyone goes to the same server. Some L3 load balancers are still hashing on the lower 8 bits of IPv4 addresses right now. It's far from being unique and still it works for most purposes, provided that the number of servers is much less than 256. With 20 bits of randomness, you can have a fair distribution up to 1 million servers, or a bit less if you want to apply smooth weighting. > >The LB would then > >either hash this flow label or load-balance + stick on it, at the admin's > >option. The general idea is to insert a session identifier in the packets > >so that all packets related to a same user session can be processed > >equally > >and directed to the same place, which is the hardest thing to do right now > >in load-balancing. > > => I don't know if this is a sound idea to be honest. I can understand the > use of the flow label instead of port numbers when combined with IP > addresses for load balancing. I think that's a fine thing to do. I just > don't think using the flow label alone as a session id is such a good idea > given the reliance on its uniqueness. It seems to optimise for a rare case > and for a small benefit. It's not the rare case, it's the main case. Look at how load balancing is performed everywhere. IP address is never used when you need to guarantee user stickiness (eg: HTTP, RDP, ...). That's even why LB vendors claim to support a wide variety of protocols. In fact what they have to do is to pick the relevant part in the protocol to find the server associated with the session. For instance, in HTTP you have to parse L7 to find cookies, in HTTPS you first have to decipher SSL then to extract HTTP cookies. In RDP you have to either find the user ID or the server's address which are hashed in RDP cookies, etc... Regards, Willy From marc.lampo@eurid.eu Wed Feb 29 08:17:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE0021F86FD for ; Wed, 29 Feb 2012 08:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.53 X-Spam-Level: X-Spam-Status: No, score=-0.53 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq9ouk1XPbWV for ; Wed, 29 Feb 2012 08:17:05 -0800 (PST) Received: from cuda.eurid.eu (cuda.eurid.eu [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id 70CF221F8677 for ; Wed, 29 Feb 2012 08:17:05 -0800 (PST) X-ASG-Debug-ID: 1330532223-02dadd0667229a00001-b2NLKh Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id qSVjHpozoUw1gzW8; Wed, 29 Feb 2012 17:17:03 +0100 (CET) X-Barracuda-Envelope-From: marc.lampo@eurid.eu X-ASG-Whitelist: Client Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 9912AE4075; Wed, 29 Feb 2012 17:17:03 +0100 (CET) X-Virus-Scanned: amavisd-new at techmail.eurid.eu Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jtYqtSnvnpM; Wed, 29 Feb 2012 17:17:03 +0100 (CET) Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 87C89E4070; Wed, 29 Feb 2012 17:17:03 +0100 (CET) From: "Marc Lampo" To: "'Brian E Carpenter'" References: <4F4D6F46.5010708@gmail.com> In-Reply-To: <4F4D6F46.5010708@gmail.com> Date: Wed, 29 Feb 2012 17:17:03 +0100 (CET) X-ASG-Orig-Subj: RE: [v6ops] So nobody cares about load balancers? [draft-carpenter-v6ops-label-balance-01.txt] Message-ID: <011101ccf6fd$928cc6c0$b7a65440$@lampo@eurid.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18) Thread-Index: Acz2d+y5aHNLUSTHQ42nljIJF+7kxwAgDgGw Content-Language: en-za x-antivirus-status: Clean x-antivirus: avast! X-Originating-IP: [172.20.5.51] X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121] X-Barracuda-Start-Time: 1330532223 X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at eurid.eu Cc: 'IPv6 Operations' Subject: Re: [v6ops] So nobody cares about load balancers? [draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 16:17:06 -0000 Hello, Some considerations, trying to bring constructive feedback for this document : 1) seems to me the document, in its present state, is not using the term "session" in a consistent way. Having dome some programming on specific layers of the OSI model, I interpret "session" as something from layer 5 : the session layer. By situating session on a different layer (than transport), the following should be clear : - one transport "connection" can transport multiple sessions (compare to : during one phone call - transport connection - partners have a "greeting" / "say what they have to say" / and "goodbye" part in the conversation; each of which could be considered a "session" by itself) --> seems to me, flow label can cope with this. - one session can span multiple transport connections The present text uses ftp as an example : one control connection + (each ?) data connection are all one "session" (I'm hesitant about this) Another example, also referred to in the text, are http cookies. The final server uses cookie to decide whether or not "this" data is actually a continuation of a previous session. Potentially client IP and port could change during the session. Nothing forbids that different transport layers are used for one session : though not affected by flow label, but think of DNS where the initial Q over UDP yields TC-bit, and is followed by the same Q over TCP : one session ? --> I'm unsure if flow label can cope with this. For the text : Please review the use of "connection" and "session". I see, in 2, second paragraph : "transport session" !? Still in 2, top of page 7 : "first packet of a new session" --> shouldn't this be : "new connection" Looking at the draft and keeping the 7 layer definition in mind, it seems that what is actually attempted is to put layer 5 info (session "id") into a field of layer 3. I'm unsure if this is possible at all (especially : how to span multiple transport "connections"). Of course, the challenge (speed/number of connections per second) for load balancers is not made any easier if they must take layer 5 Information into account. I acknowledge that this draft tries to help them with that. 2) Security considerations (actually a remark on the same section in RFC 6437, but this draft refers to it. Sorry for being late ...) RFC 6437 states, in 6.1 "Covert channel risk" : "... isolated UDP packets ...". But what are "isolated" UDP packets ? Isn't it overlooked that, since a layer 5 session can span multiple layer 4 packets, one session can easily span multiple UDP packets (think of tftp to name one). I hope this contribution helps fixing ideas and avoid confusion. Kind regards, Marc Lampo From warren@kumari.net Wed Feb 29 10:27:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365E621F8726 for ; Wed, 29 Feb 2012 10:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.17 X-Spam-Level: X-Spam-Status: No, score=-106.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0R-emdX7BjF for ; Wed, 29 Feb 2012 10:27:01 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 73F7421F864C for ; Wed, 29 Feb 2012 10:27:01 -0800 (PST) Received: from dhcp-172-19-119-93.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 99C771B40091; Wed, 29 Feb 2012 13:27:00 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <20120229073045.GD32187@1wt.eu> Date: Wed, 29 Feb 2012 13:26:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F4D6F46.5010708@gmail.com> <20120229073045.GD32187@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 18:27:02 -0000 On Feb 29, 2012, at 2:30 AM, Willy Tarreau wrote: > Hi, >=20 > On Wed, Feb 29, 2012 at 06:15:29PM +1100, Hesham Soliman wrote: >>>=20 >>> If you want to use the flow label instead of much less palatable >>> techniques to identify the transaction, using the same flow label >>> is indicated. But that's getting beyond v6ops scope, I fear. >>>=20 >>>>=20 >>>> =3D> Agreed. Can't see how a flow label can help here. It's not = globally >>>> unique!=20 >>>=20 >>> Strangely, it doesn't need to be. It doesn't matter if the load = balancer >>> happens to send two different flows to the same target server, = because >>> they happen to have the same flow label. (Which is only a 1 per = million >>> probability, since we have 20 bits.) What matters is that all the >>> packets of the same transaction go to the same server. >>=20 >> =3D> Agreed again. But the point is that the flow label doesn't = really buy >> you anything for that specific scenario because it's a new connection >> anyway and it can be load-balanced to any server. So, there doesn't = seem >> to be an advantage for that scenario. >=20 > The advantage of having the flow label is to tell the load balancer = what > user-level session the connection belongs to so that it can forward = the > connection to the proper server. That's exactly what is currently done > in HTTP with cookies and in SSL with SSL-ID, except that with the flow > label we wouldn't have to process layer-7 information. >=20 > Basically a browser would pick a random 20-bit number when opening a > page and would assign this 20-bit random number to all outgoing = connections > to the same site, whether they're HTTP or HTTPS btw. The LB would then > either hash this flow label or load-balance + stick on it, at the = admin's > option. The general idea is to insert a session identifier in the = packets > so that all packets related to a same user session can be processed = equally > and directed to the same place, which is the hardest thing to do right = now > in load-balancing. I think that some of the reluctance to this document / idea is that it = gives too much control to the client app and seems like it could be a = DoS vector (unless I have completely misunderstood the mechanism). By using the flow label to determine which backend to ship traffic to, = the clients can basically choose a server to hit -- this means that a = bunch of zombies could all initiate connections to 192.0.2.1:80 with = flow id 42 and then, every N seconds, increment the flow label. This = would basically allow targeting of backends, dumping the full volume of = attack traffic at a single backend (and then the next backend, and then = the next and so on).=20 While this is currently possible with the current load balancing = algorithms, many of them use H(dest_ip, dest_port, src_ip, src_port, = secret)%N -- the inclusion of src_ip, src_port spreads the hash (and the = secret prevents the attackers from calculating src_ports to generate = matching hashes). By doing H(dest_ip, dest_port, flow_label, secret)%N, = the attacker has control over all hash inputs.... W >=20 > Regards, > Willy >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From Tina.Tsou.Zouting@huawei.com Wed Feb 29 10:32:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F207421F86A7 for ; Wed, 29 Feb 2012 10:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQvk3hkIOwIw for ; Wed, 29 Feb 2012 10:32:16 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 60FB921F869D for ; Wed, 29 Feb 2012 10:32:15 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0600BN13HKJT@szxga04-in.huawei.com> for v6ops@ietf.org; Thu, 01 Mar 2012 02:32:09 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0600IDZ3HKH4@szxga04-in.huawei.com> for v6ops@ietf.org; Thu, 01 Mar 2012 02:32:08 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHD68973; Thu, 01 Mar 2012 02:32:07 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 01 Mar 2012 02:31:37 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.28]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Thu, 01 Mar 2012 02:31:57 +0800 Date: Wed, 29 Feb 2012 18:31:56 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.212.244.166] To: Warren Kumari , Willy Tarreau Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] Thread-index: AQHM9rQ1/C03RyneK02lFwHeu7j7+pZTq+wAgACG/RA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F4D6F46.5010708@gmail.com> <20120229073045.GD32187@1wt.eu> Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 18:32:17 -0000 Tina > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Warren Kumari > Sent: Wednesday, February 29, 2012 10:27 AM > To: Willy Tarreau > Cc: IPv6 Operations > Subject: Re: [v6ops] So nobody cares about load balancers? [ draft- > carpenter-v6ops-label-balance-01.txt] > > > On Feb 29, 2012, at 2:30 AM, Willy Tarreau wrote: > > > Hi, > > > > On Wed, Feb 29, 2012 at 06:15:29PM +1100, Hesham Soliman wrote: > >>> > >>> If you want to use the flow label instead of much less palatable > >>> techniques to identify the transaction, using the same flow label > >>> is indicated. But that's getting beyond v6ops scope, I fear. > >>> > >>>> > >>>> => Agreed. Can't see how a flow label can help here. It's not > globally > >>>> unique! > >>> > >>> Strangely, it doesn't need to be. It doesn't matter if the load > balancer > >>> happens to send two different flows to the same target server, because > >>> they happen to have the same flow label. (Which is only a 1 per > million > >>> probability, since we have 20 bits.) What matters is that all the > >>> packets of the same transaction go to the same server. > >> > >> => Agreed again. But the point is that the flow label doesn't really > buy > >> you anything for that specific scenario because it's a new connection > >> anyway and it can be load-balanced to any server. So, there doesn't > seem > >> to be an advantage for that scenario. > > > > The advantage of having the flow label is to tell the load balancer what > > user-level session the connection belongs to so that it can forward the > > connection to the proper server. That's exactly what is currently done > > in HTTP with cookies and in SSL with SSL-ID, except that with the flow > > label we wouldn't have to process layer-7 information. > > > > Basically a browser would pick a random 20-bit number when opening a > > page and would assign this 20-bit random number to all outgoing > connections > > to the same site, whether they're HTTP or HTTPS btw. The LB would then > > either hash this flow label or load-balance + stick on it, at the > admin's > > option. The general idea is to insert a session identifier in the > packets > > so that all packets related to a same user session can be processed > equally > > and directed to the same place, which is the hardest thing to do right > now > > in load-balancing. > > I think that some of the reluctance to this document / idea is that it > gives too much control to the client app and seems like it could be a DoS > vector (unless I have completely misunderstood the mechanism). > > By using the flow label to determine which backend to ship traffic to, the > clients can basically choose a server to hit -- this means that a bunch of > zombies could all initiate connections to 192.0.2.1:80 with flow id 42 and > then, every N seconds, increment the flow label. This would basically > allow targeting of backends, dumping the full volume of attack traffic at > a single backend (and then the next backend, and then the next and so on). > While this is currently possible with the current load balancing > algorithms, many of them use H(dest_ip, dest_port, src_ip, src_port, > secret)%N -- the inclusion of src_ip, src_port spreads the hash (and the > secret prevents the attackers from calculating src_ports to generate > matching hashes). By doing H(dest_ip, dest_port, flow_label, secret)%N, > the attacker has control over all hash inputs.... But can people always have a better hash algorithm? For example, make the hash tables dynamic; that is, they may have to vary in size substantially as the process goes on. > > W > > > > > Regards, > > Willy > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From warren@kumari.net Wed Feb 29 10:42:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C205E21F86C3 for ; Wed, 29 Feb 2012 10:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.167 X-Spam-Level: X-Spam-Status: No, score=-106.167 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mfo4c+TtxXqK for ; Wed, 29 Feb 2012 10:42:55 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B657521F86C2 for ; Wed, 29 Feb 2012 10:42:55 -0800 (PST) Received: from dhcp-172-19-119-93.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id C94721B40091; Wed, 29 Feb 2012 13:42:54 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Wed, 29 Feb 2012 13:42:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F4D6F46.5010708@gmail.com> <20120229073045.GD32187@1wt.eu> To: Tina TSOU X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , Willy Tarreau Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 18:42:56 -0000 On Feb 29, 2012, at 1:31 PM, Tina TSOU wrote: >=20 >=20 > Tina >=20 >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >> Warren Kumari >> Sent: Wednesday, February 29, 2012 10:27 AM >> To: Willy Tarreau >> Cc: IPv6 Operations >> Subject: Re: [v6ops] So nobody cares about load balancers? [ draft- >> carpenter-v6ops-label-balance-01.txt] >>=20 >>=20 >> On Feb 29, 2012, at 2:30 AM, Willy Tarreau wrote: >>=20 >>> Hi, >>>=20 >>> On Wed, Feb 29, 2012 at 06:15:29PM +1100, Hesham Soliman wrote: >>>>>=20 >>>>> If you want to use the flow label instead of much less palatable >>>>> techniques to identify the transaction, using the same flow label >>>>> is indicated. But that's getting beyond v6ops scope, I fear. >>>>>=20 >>>>>>=20 >>>>>> =3D> Agreed. Can't see how a flow label can help here. It's not >> globally >>>>>> unique! >>>>>=20 >>>>> Strangely, it doesn't need to be. It doesn't matter if the load >> balancer >>>>> happens to send two different flows to the same target server, = because >>>>> they happen to have the same flow label. (Which is only a 1 per >> million >>>>> probability, since we have 20 bits.) What matters is that all the >>>>> packets of the same transaction go to the same server. >>>>=20 >>>> =3D> Agreed again. But the point is that the flow label doesn't = really >> buy >>>> you anything for that specific scenario because it's a new = connection >>>> anyway and it can be load-balanced to any server. So, there doesn't >> seem >>>> to be an advantage for that scenario. >>>=20 >>> The advantage of having the flow label is to tell the load balancer = what >>> user-level session the connection belongs to so that it can forward = the >>> connection to the proper server. That's exactly what is currently = done >>> in HTTP with cookies and in SSL with SSL-ID, except that with the = flow >>> label we wouldn't have to process layer-7 information. >>>=20 >>> Basically a browser would pick a random 20-bit number when opening a >>> page and would assign this 20-bit random number to all outgoing >> connections >>> to the same site, whether they're HTTP or HTTPS btw. The LB would = then >>> either hash this flow label or load-balance + stick on it, at the >> admin's >>> option. The general idea is to insert a session identifier in the >> packets >>> so that all packets related to a same user session can be processed >> equally >>> and directed to the same place, which is the hardest thing to do = right >> now >>> in load-balancing. >>=20 >> I think that some of the reluctance to this document / idea is that = it >> gives too much control to the client app and seems like it could be a = DoS >> vector (unless I have completely misunderstood the mechanism). >>=20 >> By using the flow label to determine which backend to ship traffic = to, the >> clients can basically choose a server to hit -- this means that a = bunch of >> zombies could all initiate connections to 192.0.2.1:80 with flow id = 42 and >> then, every N seconds, increment the flow label. This would basically >> allow targeting of backends, dumping the full volume of attack = traffic at >> a single backend (and then the next backend, and then the next and so = on). >> While this is currently possible with the current load balancing >> algorithms, many of them use H(dest_ip, dest_port, src_ip, src_port, >> secret)%N -- the inclusion of src_ip, src_port spreads the hash (and = the >> secret prevents the attackers from calculating src_ports to generate >> matching hashes). By doing H(dest_ip, dest_port, flow_label, = secret)%N, >> the attacker has control over all hash inputs.... > But can people always have a better hash algorithm? For example, make = the hash tables dynamic; that is, they may have to vary in size = substantially as the process goes on. But if you are only hashing over H(dest_ip, dest_port, flow_label, = secret): dest_ip is a constant. dest_port is a constant. flow_label - provided by the attacker. secret is a constant. This means that the attacker is in control of all of the inputs (other = than secret, which has to stay the same to maintain consistency), so: H(192.0.2.1, 80, 42, "hunter2") will always generate the same value (and = has to, otherwise your LB will not be providing a consistent mapping) You need *something* that the attacker is not in control of... W >>=20 >> W >>=20 >>>=20 >>> Regards, >>> Willy >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From wwwrun@rfc-editor.org Wed Feb 29 11:48:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B5221E8017 for ; Wed, 29 Feb 2012 11:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duSZHXDHeit6 for ; Wed, 29 Feb 2012 11:48:30 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0887921E8013 for ; Wed, 29 Feb 2012 11:48:29 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0980972E042; Wed, 29 Feb 2012 11:42:53 -0800 (PST) To: ietf@energizeurnet.com, elwynd@dial.pipex.com, rbonica@juniper.net, dromasca@avaya.com, fred.baker@cisco.com, joelja@bogus.com From: RFC Errata System Message-Id: <20120229194253.0980972E042@rfc-editor.org> Date: Wed, 29 Feb 2012 11:42:53 -0800 (PST) Cc: david.black@emc.com, v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] [Technical Errata Reported] RFC4966 (3142) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 19:48:30 -0000 The following errata report has been submitted for RFC4966, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4966&eid=3142 -------------------------------------- Type: Technical Reported by: David L. Black Section: 2.1 Original Text ------------- Unless UDP encapsulation is used for IPsec [RFC3498], traffic using IPsec AH (Authentication Header), in transport and tunnel mode, and IPsec ESP (Encapsulating Security Payload), in transport mode, is unable to be carried through NAT-PT without terminating the security associations on the NAT-PT, due to their usage of cryptographic integrity protection. Corrected Text -------------- IPsec traffic using AH (Authentication Header) [RFC4302] in both transport and tunnel modes cannot be carried through NAT-PT without terminating the security associations on the NAT-PT, due to the inclusion of IP header fields in the scope of AH's cryptographic integrity protection [RFC3715]. In addition, IPsec traffic using ESP (Encapsulating Security Payload) [RFC4303] in transport mode generally uses UDP encapsulation [RFC3948] for NAT traversal (including NAT-PT traversal) in order to avoid the problems described in [RFC3715]. Notes ----- This RFC4966 text was copied into draft-ietf-behave-64-analysis-06. Gen-ART review of that draft found that the statement was incorrect for ESP. The correct explanations of the problems (in great detail) can be found in RFC 3715. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4966 (draft-ietf-v6ops-natpt-to-historic-00) -------------------------------------- Title : Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status Publication Date : July 2007 Author(s) : C. Aoun, E. Davies Category : INFORMATIONAL Source : IPv6 Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From brian.e.carpenter@gmail.com Wed Feb 29 12:04:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841B921F880E for ; Wed, 29 Feb 2012 12:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.507 X-Spam-Level: X-Spam-Status: No, score=-103.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOPHitEOp6xB for ; Wed, 29 Feb 2012 12:04:11 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C30DA21F8800 for ; Wed, 29 Feb 2012 12:04:10 -0800 (PST) Received: by eeke51 with SMTP id e51so1840533eek.31 for ; Wed, 29 Feb 2012 12:04:10 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.39.145 as permitted sender) client-ip=10.14.39.145; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.39.145 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.14.39.145]) by 10.14.39.145 with SMTP id d17mr228872eeb.86.1330545850043 (num_hops = 1); Wed, 29 Feb 2012 12:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=p2lQRD8kNnlkbOFFWRXsdPjpuwMVKUwgvxjTI90xyvY=; b=OsQTs9rvPpN1cZqjY/F6jVZGO+EK/Bahs/Dryk1eFdSHkVCjmZor7IFvdRL+Oc7+16 oMCft+kOaV5QxMGOr+FAiNFwcuFEIZQmm9kGffFnI2BzFRRkEX7WVJaj2Es8vog6uMXZ zvVuxqPkzxaDmkbnRXmDUL1NFLTr/YyYURqmQ= Received: by 10.14.39.145 with SMTP id d17mr176023eeb.86.1330545849972; Wed, 29 Feb 2012 12:04:09 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id u11sm79121284eeb.1.2012.02.29.12.04.07 (version=SSLv3 cipher=OTHER); Wed, 29 Feb 2012 12:04:09 -0800 (PST) Message-ID: <4F4E84B0.9030907@gmail.com> Date: Thu, 01 Mar 2012 09:04:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marc Lampo References: <4F4D6F46.5010708@gmail.com> <4f4e4f80.042f0e0a.2fb3.2867SMTPIN_ADDED@mx.google.com> In-Reply-To: <4f4e4f80.042f0e0a.2fb3.2867SMTPIN_ADDED@mx.google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'IPv6 Operations' Subject: Re: [v6ops] So nobody cares about load balancers? [draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 20:04:11 -0000 On 2012-03-01 05:17, Marc Lampo wrote: > 1) seems to me the document, in its present state, is not using > the term "session" in a consistent way. Marc is correct that the terminology needs to be defined and used consistently. As Willy has pointed out, a user session is not the same thing as a transport session, and that is a fundamental issue in load balancing. On 2012-03-01 07:26, Warren Kumari wrote: > I think that some of the reluctance to this document / idea is that it gives too much control to the client app and seems like it could be a DoS vector (unless I have completely misunderstood the mechanism). Absolutely, the attack scenarios need to be considered. Actually this is discussed in RFC 6437 and in the subject draft, but it needs more thought if we pop up from transport-layer labels to session labels. Regards Brian Carpenter From fred@cisco.com Wed Feb 29 12:39:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C324321E807A for ; Wed, 29 Feb 2012 12:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.57 X-Spam-Level: X-Spam-Status: No, score=-108.57 tagged_above=-999 required=5 tests=[AWL=2.029, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGx9-87ki0AV for ; Wed, 29 Feb 2012 12:39:06 -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 CA96721E803B for ; Wed, 29 Feb 2012 12:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2907; q=dns/txt; s=iport; t=1330547945; x=1331757545; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=KvslsZtHzOIuUPeZQtCN6nGpDdVvO+tTHnWupt+kGJg=; b=BbwaqgYxPKn6gxhxtLgjSuuqTx2FsG5iTvsQ5kqgTp+iJScVGiRotG8P xu9FNZIwhtsqnfMdgQjD7FuLpZyAN+7IeofAxxhurRCxG6X2afD84WyM7 j3eOnRWaqZKnHJkFCFTU5xscJU0FPOAS5B9A8jLR/8fZ6JKmWbwLbOL6e 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACWMTk+rRDoI/2dsb2JhbAAqGrNggQeBegEBAQMBEgEnLRIQC0ZXBhMih2IEDCmaFwGfHY0EGgELAwIIAgoBBgsCBgcOBwEKCQKFCkYFDggQgkpjBIhNjHKFX40hXg X-IronPort-AV: E=Sophos;i="4.73,504,1325462400"; d="scan'208";a="33336603" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 29 Feb 2012 20:39:05 +0000 Received: from Freds-Computer.local (tky-vpn-client-231-196.cisco.com [10.70.231.196]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1TKd3gW018840; Wed, 29 Feb 2012 20:39:04 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 01 Mar 2012 05:39:05 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 01 Mar 2012 05:39:05 +0900 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <20120229194253.0980972E042@rfc-editor.org> Date: Thu, 1 Mar 2012 05:38:43 +0900 Message-Id: References: <20120229194253.0980972E042@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG , david.black@emc.com, Dan Romascanu , ietf@energizeurnet.com Subject: Re: [v6ops] [Technical Errata Reported] RFC4966 (3142) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 20:39:08 -0000 I have no objection to the erratum. I do wonder about how useful it is; = we don't plan to update RFC 4966 any time soon. On Mar 1, 2012, at 4:42 AM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC4966, > "Reasons to Move the Network Address Translator - Protocol Translator = (NAT-PT) to Historic Status". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4966&eid=3D3142 >=20 > -------------------------------------- > Type: Technical > Reported by: David L. Black >=20 > Section: 2.1 >=20 > Original Text > ------------- > Unless UDP encapsulation is used for IPsec [RFC3498], traffic using >=20 > IPsec AH (Authentication Header), in transport and tunnel mode, and >=20 > IPsec ESP (Encapsulating Security Payload), in transport mode, is >=20 > unable to be carried through NAT-PT without terminating the security >=20 > associations on the NAT-PT, due to their usage of cryptographic >=20 > integrity protection. >=20 > Corrected Text > -------------- > IPsec traffic using AH (Authentication Header) [RFC4302] in both >=20 > transport and tunnel modes cannot be carried through NAT-PT without >=20 > terminating the security associations on the NAT-PT, due to the >=20 > inclusion of IP header fields in the scope of AH's cryptographic >=20 > integrity protection [RFC3715]. In addition, IPsec traffic using >=20 > ESP (Encapsulating Security Payload) [RFC4303] in transport mode >=20 > generally uses UDP encapsulation [RFC3948] for NAT traversal >=20 > (including NAT-PT traversal) in order to avoid the problems >=20 > described in [RFC3715]. >=20 >=20 >=20 > Notes > ----- > This RFC4966 text was copied into draft-ietf-behave-64-analysis-06. >=20 > Gen-ART review of that draft found that the statement was incorrect >=20 > for ESP. The correct explanations of the problems (in great detail) >=20 > can be found in RFC 3715. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4966 (draft-ietf-v6ops-natpt-to-historic-00) > -------------------------------------- > Title : Reasons to Move the Network Address Translator - = Protocol Translator (NAT-PT) to Historic Status > Publication Date : July 2007 > Author(s) : C. Aoun, E. Davies > Category : INFORMATIONAL > Source : IPv6 Operations > Area : Operations and Management > Stream : IETF > Verifying Party : IESG From w@1wt.eu Wed Feb 29 13:27:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7297921F865E for ; Wed, 29 Feb 2012 13:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.522 X-Spam-Level: X-Spam-Status: No, score=-5.522 tagged_above=-999 required=5 tests=[AWL=-3.479, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X74N+S++FmZC for ; Wed, 29 Feb 2012 13:27:19 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id B51C921F865A for ; Wed, 29 Feb 2012 13:27:12 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q1TLR0nW005125; Wed, 29 Feb 2012 22:27:00 +0100 Date: Wed, 29 Feb 2012 22:27:00 +0100 From: Willy Tarreau To: Warren Kumari Message-ID: <20120229212700.GD3575@1wt.eu> References: <4F4D6F46.5010708@gmail.com> <20120229073045.GD32187@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 21:27:19 -0000 Hi, On Wed, Feb 29, 2012 at 01:42:53PM -0500, Warren Kumari wrote: > But if you are only hashing over H(dest_ip, dest_port, flow_label, secret): > > dest_ip is a constant. > dest_port is a constant. > flow_label - provided by the attacker. > secret is a constant. > > This means that the attacker is in control of all of the inputs (other than secret, which has to stay the same to maintain consistency), so: > H(192.0.2.1, 80, 42, "hunter2") will always generate the same value (and has to, otherwise your LB will not be providing a consistent mapping) > > You need *something* that the attacker is not in control of... This is totally pointless because the goal of "persistence" or "stickiness" in load balancing precisely is to ensure that some form of user controlled data is used to find the proper server. If you want to bring a random server down, that's very easy. Just connect to it first, and feed the cookie to a botnet which will always connect to the same server. This is the expected behaviour. There are counter measures against abuse, some of them involve counting the per-session request rate for instance and blocking. Quite frankly right now this has not been an issue and will probably not be one for a long time to come since the biggest issue still is to find this user-server association. Regards, Willy From warren@kumari.net Wed Feb 29 14:13:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B29821E8097 for ; Wed, 29 Feb 2012 14:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.464 X-Spam-Level: X-Spam-Status: No, score=-106.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH6XPijzNBTl for ; Wed, 29 Feb 2012 14:13:24 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id ECB9721E8095 for ; Wed, 29 Feb 2012 14:13:23 -0800 (PST) Received: from dhcp-172-19-119-93.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 259541B411DE; Wed, 29 Feb 2012 17:13:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <20120229212700.GD3575@1wt.eu> Date: Wed, 29 Feb 2012 17:13:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F4D6F46.5010708@gmail.com> <20120229073045.GD32187@1wt.eu> <20120229212700.GD3575@1wt.eu> To: Willy Tarreau X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 22:13:24 -0000 On Feb 29, 2012, at 4:27 PM, Willy Tarreau wrote: > Hi, >=20 > On Wed, Feb 29, 2012 at 01:42:53PM -0500, Warren Kumari wrote: >> But if you are only hashing over H(dest_ip, dest_port, flow_label, = secret): >>=20 >> dest_ip is a constant. >> dest_port is a constant. >> flow_label - provided by the attacker. >> secret is a constant. >>=20 >> This means that the attacker is in control of all of the inputs = (other than secret, which has to stay the same to maintain consistency), = so: >> H(192.0.2.1, 80, 42, "hunter2") will always generate the same value = (and has to, otherwise your LB will not be providing a consistent = mapping) >>=20 >> You need *something* that the attacker is not in control of... >=20 > This is totally pointless because the goal of "persistence" or = "stickiness" > in load balancing precisely is to ensure that some form of user = controlled > data is used to find the proper server. If you want to bring a random = server > down, that's very easy. Just connect to it first, and feed the cookie = to a > botnet which will always connect to the same server. Um, not really -- this only applies if you use cookies for stickiness = (and are load-balancing something like HTTP that uses cookies!) There are a large number of other load balancing algorithms and a large = number of protocols that don't have anything approaching a cookie... W > This is the expected > behaviour. There are counter measures against abuse, some of them = involve > counting the per-session request rate for instance and blocking. Quite > frankly right now this has not been an issue and will probably not be = one > for a long time to come since the biggest issue still is to find this > user-server association. >=20 > Regards, > Willy >=20 From fred@cisco.com Wed Feb 29 14:51:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379C921F86CB; Wed, 29 Feb 2012 14:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.308 X-Spam-Level: X-Spam-Status: No, score=-108.308 tagged_above=-999 required=5 tests=[AWL=1.691, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG-IXIz8CU5H; Wed, 29 Feb 2012 14:51:24 -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 6C44021F86C9; Wed, 29 Feb 2012 14:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2538; q=dns/txt; s=iport; t=1330555884; x=1331765484; h=subject:mime-version:from:date:cc:reply-to:message-id: references:to:content-transfer-encoding; bh=el5aitpION1TvF95X11OazzFHexpHJRjIllrS0pRPj4=; b=ITjJ5BjHb5SsJMs5o92m4/jkMwSPApknm2Af8oDQG6GMIjhsX//Wu63T tF6DSfCU9PoS49wEcI+qVgOomHHSiXm/YvoftBDS9u9EfZjWXi9enauiu QowZ8ONxe2M3q7HJfvJIP2sN0/w0uYsNV7ymbW6hFMKSGyP2Az+3kgUAh E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALaqTk+rRDoJ/2dsb2JhbABDs3aBB4F6AQEBBAEBAQ8BJzQLEBwBAgECASMLJyIEAggGEwkZh2YMoFwBlzmMegMiDgIIAgoBBgsCBgcOBwEKCQKFCjkBDQcEBhqCSWMEiE2McoVfiVKDTw X-IronPort-AV: E=Sophos;i="4.73,505,1325462400"; d="scan'208";a="33507201" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 29 Feb 2012 22:51:24 +0000 Received: from Freds-Computer.local (tky-vpn-client-231-196.cisco.com [10.70.231.196]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1TMpMS6013795; Wed, 29 Feb 2012 22:51:23 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 01 Mar 2012 07:51:23 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 01 Mar 2012 07:51:23 +0900 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker Date: Thu, 1 Mar 2012 07:51:04 +0900 Message-Id: <12E45ED2-C42F-4F00-9014-5814DC4602F2@cisco.com> References: To: v6ops v6ops WG X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: mboned-chairs@ietf.org Subject: [v6ops] Fwd: Review Request - Fwd: [MBONED] I-D Action: draft-ietf-mboned-64-multicast-address-format-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mboned@ietf.org, mboned-chairs@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 22:51:25 -0000 We have a request for review on a multicast address format, from MBONED. = Please review and comment to mboned and its chairs. http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format "IPv4-Embedded IPv6 Multicast Address Format", Mohamed Boucadair, = Jacni Qin, Yiu Lee, Stig Venaas, Xing Li, Mingwei Xu, 29-Feb-12 On Mar 1, 2012, at 4:13 AM, Greg Shepherd wrote: > The draft draft-ietf-mboned-64-multicast-address-format-01.txt just > fineshed WGLC in MBONED but we'd like reviewers from the v6ops and > 6man WGs before we move this along to reqpub. Can you please send the > request to your lists? >=20 > Thanks, > Greg >=20 > ---------- Forwarded message ---------- > From: > Date: Wed, Feb 29, 2012 at 2:07 AM > Subject: [MBONED] I-D Action: > draft-ietf-mboned-64-multicast-address-format-01.txt > To: i-d-announce@ietf.org > Cc: mboned@ietf.org >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the MBONE Deployment Working > Group of the IETF. >=20 > Title : IPv4-Embedded IPv6 Multicast Address Format > Author(s) : Mohamed Boucadair > Jacni Qin > Yiu L. Lee > Stig Venaas > Xing Li > Mingwei Xu > Filename : = draft-ietf-mboned-64-multicast-address-format-01.txt > Pages : 12 > Date : 2012-02-29 >=20 > This document specifies an extension to the IPv6 multicast = addressing > architecture to be used in the context of IPv4-IPv6 interconnection. > In particular, this document defines an address format for IPv4- > embedded IPv6 multicast addresses. This address format can be used > for IPv4-IPv6 translation or encapsulation schemes. >=20 > This document updates RFC4291. >=20 >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-mboned-64-multicast-address= -format-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-mboned-64-multicast-address-= format-01.txt >=20 > _______________________________________________ > MBONED mailing list > MBONED@ietf.org > https://www.ietf.org/mailman/listinfo/mboned >>=20 From hesham@elevatemobile.com Wed Feb 29 16:54:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1955521E8055 for ; Wed, 29 Feb 2012 16:54:02 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJ4QAIp5NZx0 for ; Wed, 29 Feb 2012 16:54:01 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id D8BF721E801C for ; Wed, 29 Feb 2012 16:54:00 -0800 (PST) Received: from [120.144.187.119] (helo=[10.0.0.67]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1S2uGx-0000Q0-0z; Thu, 01 Mar 2012 11:53:31 +1100 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 01 Mar 2012 11:53:13 +1100 From: Hesham Soliman To: Willy Tarreau Message-ID: Thread-Topic: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] In-Reply-To: <20120229133848.GB2171@1wt.eu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 00:54:02 -0000 > > >> >Basically a browser would pick a random 20-bit number when opening a >> >page and would assign this 20-bit random number to all outgoing >> >connections >> >to the same site, whether they're HTTP or HTTPS btw. >> >> >> => Is it safe enough to rely on the browser's 20 bit RNG and ignore IP >> addresses? > >I'd say it differently. It's safe to rely on anything but the IP address. => No one suggested that you rely on the address alone. >One user != one IP address. It's only an approximation which is valid >enough where it's only used for optimization, but not where user session >stickiness is required. => And the flow label can ensure that stickiness by itself? That's a contradiction of what you're trying to do. If you want proper stickiness then you need unique application identifiers. If you think the user's IP address is not stable enough and you want stronger stickiness then I'd say the flow label is much worse. More below >For instance, hashing a source IP address is fine >to load-balance an SSL farm, because most of the users will remain on the >same SSL endpoint, and the small part of those who will constantly change >will just experience a minor degradation which is not a show stopper. But >it's totally different when you want to ensure that once you log into a >server you need to remain on this one until you click the "logout" button, >because this time you cannot accept to drop connections for even 1% of >your >visitors. That's why LBs mostly rely on cookies and have to ignore IP >addresses for this task. => Ok, but my point is that you can't compare flow labels and cookies because you'll end up with either incorrect load distribution (because the flow label doesn't tell you enough about the connection, or with users being distributed onto different servers, depending on which side your load distribution algorithm favours. What am I missing? If you LB flow label 27 on server 1 blindly then you can very well end up with server 1 being busier than others. If you split flow label 27 between servers 1 and 2 without any other considerations then you'll end up where you don't want to be now. Relying on applications to do the right thing (use a good RNG) for your infrastructure to work seems like a proposition that could lead to unreliable results. > >With a flow label, we have a lower layer alternative to stickiness >cookies. > >> The discussion was related to the change in IP address and whether the >> flow label helps in that case. > >Yes precisely it does help. If you make it possible for the client to set >the flow label on purpose on outgoing connections, and you make the LBs >only rely on the flow label, then you're not sensitive to IP address >changes >anymore. These ones happen at enterprise proxies and in the mobile world >where it's very common to lose access after some idle time. => Yes but they don't use flow labels for that. They use a unique application-specific identifier. flow label != cookie. The cookie is not created by the client. > >> Aside from the fact that this case is rare and probably not worth the >> optimisation, my contention is that the flow label doesn't help because >> it's not unique. > >We don't need unicity (and we don't even want it). We need a large enough >value so that not everyone goes to the same server. => Large enough numbers of clients producing a uniform distribution of flow label values. What happens when the clients don't behave that way? >Some L3 load balancers >are still hashing on the lower 8 bits of IPv4 addresses right now. It's >far from being unique and still it works for most purposes, provided that >the number of servers is much less than 256. With 20 bits of randomness, >you can have a fair distribution up to 1 million servers, or a bit less >if you want to apply smooth weighting. > >> >The LB would then >> >either hash this flow label or load-balance + stick on it, at the >>admin's >> >option. The general idea is to insert a session identifier in the >>packets >> >so that all packets related to a same user session can be processed >> >equally >> >and directed to the same place, which is the hardest thing to do right >>now >> >in load-balancing. >> >> => I don't know if this is a sound idea to be honest. I can understand >>the >> use of the flow label instead of port numbers when combined with IP >> addresses for load balancing. I think that's a fine thing to do. I just >> don't think using the flow label alone as a session id is such a good >>idea >> given the reliance on its uniqueness. It seems to optimise for a rare >>case >> and for a small benefit. > >It's not the rare case, it's the main case. Look at how load balancing is >performed everywhere. IP address is never used when you need to guarantee >user stickiness (eg: HTTP, RDP, ...). => Changing IP address is a rare case, I wasn't saying that identifying users is a rare case, lets not mix things. And yes of course user identification happens but this is done with a *unique* identifier. You keep using *user* stickiness as a reason while ignoring that to achieve *user* stickiness you need a unique identifier. The combination of unreliable number generators and load balancing based on those numbers alone can end up with an undesirable effect. Do you disagree with this statement? >That's even why LB vendors claim to >support a wide variety of protocols. In fact what they have to do is to >pick the relevant part in the protocol to find the server associated with >the session. For instance, in HTTP you have to parse L7 to find cookies, >in HTTPS you first have to decipher SSL then to extract HTTP cookies. In >RDP you have to either find the user ID or the server's address which are >hashed in RDP cookies, etc... => Right, all about finding user-specific credentials that are unique on the server side. You're replacing that with arbitrary numbers generated by the client and claiming that it will have the same effect. In an ideal world where clients behave, I think you have a good point, but if clients don't behave, what will you do? Hesham > >Regards, >Willy > From brian.e.carpenter@gmail.com Wed Feb 29 19:08:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F0721E8081 for ; Wed, 29 Feb 2012 19:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.508 X-Spam-Level: X-Spam-Status: No, score=-103.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWnDLbZTY7yW for ; Wed, 29 Feb 2012 19:08:09 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0C1C21E807E for ; Wed, 29 Feb 2012 19:08:08 -0800 (PST) Received: by eaaq11 with SMTP id q11so28161eaa.31 for ; Wed, 29 Feb 2012 19:08:08 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.213.9.73 as permitted sender) client-ip=10.213.9.73; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.213.9.73 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.213.9.73]) by 10.213.9.73 with SMTP id k9mr1468281ebk.96.1330571288138 (num_hops = 1); Wed, 29 Feb 2012 19:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yFLLKHxZCwNRFZdCsXl2WhpgMO2OZ2F/iP9u3hwvFkk=; b=SKZvwTjYq216GjoWlOJbiZCk5v2dgQMi2mGq6iaGlglg4iFSMJzS/EAcX/J+2Yw+Lf J2pdiClv5m4T4ReGXsgOVThYGJ8cmD9awMiW7IoFs4pnCoEsnqt6xsC3NHlTJtbRRqbZ Q6FDIlgJGBL3OlEabhmLJA9x8zpi4dIiQ2tKM= Received: by 10.213.9.73 with SMTP id k9mr1164313ebk.96.1330571288045; Wed, 29 Feb 2012 19:08:08 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id r5sm1853767eef.6.2012.02.29.19.08.04 (version=SSLv3 cipher=OTHER); Wed, 29 Feb 2012 19:08:07 -0800 (PST) Message-ID: <4F4EE80D.6000106@gmail.com> Date: Thu, 01 Mar 2012 16:07:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hesham Soliman References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Willy Tarreau Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 03:08:10 -0000 Hesham, On 2012-03-01 13:53, Hesham Soliman wrote: >> >>>> Basically a browser would pick a random 20-bit number when opening a >>>> page and would assign this 20-bit random number to all outgoing >>>> connections >>>> to the same site, whether they're HTTP or HTTPS btw. >>> >>> => Is it safe enough to rely on the browser's 20 bit RNG and ignore IP >>> addresses? >> I'd say it differently. It's safe to rely on anything but the IP address. > > => No one suggested that you rely on the address alone. > >> One user != one IP address. It's only an approximation which is valid >> enough where it's only used for optimization, but not where user session >> stickiness is required. > > => And the flow label can ensure that stickiness by itself? That's a > contradiction of what you're trying to do. > If you want proper stickiness then you need unique application > identifiers. If you think the user's IP address is not stable enough and > you want stronger stickiness then I'd say the flow label is much worse. > More below > >> For instance, hashing a source IP address is fine >> to load-balance an SSL farm, because most of the users will remain on the >> same SSL endpoint, and the small part of those who will constantly change >> will just experience a minor degradation which is not a show stopper. But >> it's totally different when you want to ensure that once you log into a >> server you need to remain on this one until you click the "logout" button, >> because this time you cannot accept to drop connections for even 1% of >> your >> visitors. That's why LBs mostly rely on cookies and have to ignore IP >> addresses for this task. > > => Ok, but my point is that you can't compare flow labels and cookies > because you'll end up with either incorrect load distribution (because the > flow label doesn't tell you enough about the connection, or with users > being distributed onto different servers, depending on which side your > load distribution algorithm favours. What am I missing? As the draft explains, you don't use the flow label to take the initial decision about which server gets which new session. That must be done by looking at much more of the first packet, exactly as today. You use the flow label to accelerate treatment of the subsequent packets. Please tell us where in the draft we need to make this more clear. > If you LB flow label 27 on server 1 blindly You don't do that. > then you can very well end up > with server 1 being busier than others. If you split flow label 27 between > servers 1 and 2 without any other considerations then you'll end up where > you don't want to be now. Indeed, so you don't do that either. You do accept the 1 in 2^20 chance that two unrelated sessions have the same flow label; in that case they will need to be redirected to the same server. In any case the LB is going to need a hash table to look up current flow labels, but it certainly contains a monstrous hash table today for other reasons. Server LBs are stateful beasts, unfortunately. (In contrast to ECMP/LAG, which should be stateless.) > Relying on applications to do the right thing (use a good RNG) for your > infrastructure to work seems like a proposition that could lead to > unreliable results. It can only be better than today, where there is zero entropy in the flow label. The draft also discusses the case where the source doesn't set the label. As for choice of RNG, yes, it needs to be reasonable. I have some results on this coming very soon. > >> With a flow label, we have a lower layer alternative to stickiness >> cookies. >> >>> The discussion was related to the change in IP address and whether the >>> flow label helps in that case. >> Yes precisely it does help. If you make it possible for the client to set >> the flow label on purpose on outgoing connections, and you make the LBs >> only rely on the flow label, then you're not sensitive to IP address >> changes >> anymore. These ones happen at enterprise proxies and in the mobile world >> where it's very common to lose access after some idle time. > > => Yes but they don't use flow labels for that. They use a unique > application-specific identifier. > flow label != cookie. The cookie is not created by the client. Correct, and it's a fairly horrible solution, isn't it? It forces you into DPI for every packet in order to recognise the session. That's *exactly* what needs to change. > >>> Aside from the fact that this case is rare and probably not worth the >>> optimisation, my contention is that the flow label doesn't help because >>> it's not unique. >> We don't need unicity (and we don't even want it). We need a large enough >> value so that not everyone goes to the same server. > > => Large enough numbers of clients producing a uniform distribution of > flow label values. What happens when the clients don't behave that way? The worst case is that the LB has to drop back to today's solutions. > >> Some L3 load balancers >> are still hashing on the lower 8 bits of IPv4 addresses right now. It's >> far from being unique and still it works for most purposes, provided that >> the number of servers is much less than 256. With 20 bits of randomness, >> you can have a fair distribution up to 1 million servers, or a bit less >> if you want to apply smooth weighting. >> >>>> The LB would then >>>> either hash this flow label or load-balance + stick on it, at the >>> admin's >>>> option. The general idea is to insert a session identifier in the >>> packets >>>> so that all packets related to a same user session can be processed >>>> equally >>>> and directed to the same place, which is the hardest thing to do right >>> now >>>> in load-balancing. >>> => I don't know if this is a sound idea to be honest. I can understand >>> the >>> use of the flow label instead of port numbers when combined with IP >>> addresses for load balancing. I think that's a fine thing to do. I just >>> don't think using the flow label alone as a session id is such a good >>> idea >>> given the reliance on its uniqueness. It seems to optimise for a rare >>> case >>> and for a small benefit. >> It's not the rare case, it's the main case. Look at how load balancing is >> performed everywhere. IP address is never used when you need to guarantee >> user stickiness (eg: HTTP, RDP, ...). > > => Changing IP address is a rare case, I'll let Willy comment on that, but he tells me that it's a very common case, viewed from a server site. I wasn't saying that identifying > users is a rare case, lets not mix things. And yes of course user > identification happens but this is done with a *unique* identifier. You > keep using *user* stickiness as a reason while ignoring that to achieve > *user* stickiness you need a unique identifier. The combination of > unreliable number generators and load balancing based on those numbers > alone can end up with an undesirable effect. Do you disagree with this > statement? Again: that is not the model we describe in the draft. > > >> That's even why LB vendors claim to >> support a wide variety of protocols. In fact what they have to do is to >> pick the relevant part in the protocol to find the server associated with >> the session. For instance, in HTTP you have to parse L7 to find cookies, >> in HTTPS you first have to decipher SSL then to extract HTTP cookies. In >> RDP you have to either find the user ID or the server's address which are >> hashed in RDP cookies, etc... > > => Right, all about finding user-specific credentials that are unique on > the server side. You're replacing that with arbitrary numbers generated by > the client and claiming that it will have the same effect. In an ideal > world where clients behave, I think you have a good point, but if clients > don't behave, what will you do? The worst case is that the LB has to drop back to today's solutions. Also, there's an incentive for client stacks to do the right thing: improved average application response time. Regards Brian From w@1wt.eu Wed Feb 29 22:40:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12B621F8540 for ; Wed, 29 Feb 2012 22:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[AWL=-3.444, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTeE4suSBJY5 for ; Wed, 29 Feb 2012 22:40:27 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8959221F8555 for ; Wed, 29 Feb 2012 22:40:26 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q216eKbJ007853; Thu, 1 Mar 2012 07:40:20 +0100 Date: Thu, 1 Mar 2012 07:40:20 +0100 From: Willy Tarreau To: Warren Kumari Message-ID: <20120301064020.GA7791@1wt.eu> References: <4F4D6F46.5010708@gmail.com> <20120229073045.GD32187@1wt.eu> <20120229212700.GD3575@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 06:40:28 -0000 On Wed, Feb 29, 2012 at 05:13:21PM -0500, Warren Kumari wrote: > > This is totally pointless because the goal of "persistence" or "stickiness" > > in load balancing precisely is to ensure that some form of user controlled > > data is used to find the proper server. If you want to bring a random server > > down, that's very easy. Just connect to it first, and feed the cookie to a > > botnet which will always connect to the same server. > > Um, not really -- this only applies if you use cookies for stickiness (and > are load-balancing something like HTTP that uses cookies!) Let me clarify. Stickiness is the opposite of load balancing. Load balancing applies an algorithm and stickiness is the principle which consists in finding the information which lets you pick the correct server without applying the load balancing algorithm. In HTTP, cookie-based stickiness precisely does that. Same for the RDP cookies used in TSE or with the SSL-ID in SSL which is assigned by the server and works exactly like a cookie. Some hash-based load balancing algorithms are an alternative to the combination of LB + stickiness. The principle is that if the information is always present including the first time, then it is worth hashing to find the appropriate server. This includes MAC/IP/ports where stickiness is not critical (eg: etherchannel in switches, any stateless TCP-based offloader, etc...), URLs for HTTP when caches are involved, username for POP/IMAP servers, etc... > There are a large number of other load balancing algorithms and a large > number of protocols that don't have anything approaching a cookie... I perfectly agree. What I meant is that there are a huge number of situations where load balancing is applied on purpose to some data fed by the client and this is not a problem at all. Even when hashing is involved on source/dest addresses (think about SYN floods), ports (TCP connections are free to select the source port), URL, username, etc... It would be exactly the same with the flow label : the client is able to choose is as well as it can choose its source ports. What is needed is to define clearly how this should be processed in order to avoid caveats such as a flow label changing in the middle of a TCP connection and packets being sent to a wrong server and being resetted (this would leave the old connection open until the timeout, just like when a client suddenly disconnects from the net). Another point to consider is that it would probably make sense to have the server use the same flow label for the return packets belonging to the same connection. This would allow the label to be used for firewall load balancing which needs to be symmetric. Regards, Willy From w@1wt.eu Wed Feb 29 23:05:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FE721E8036 for ; Wed, 29 Feb 2012 23:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.452 X-Spam-Level: X-Spam-Status: No, score=-5.452 tagged_above=-999 required=5 tests=[AWL=-3.409, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5LxPGn-BAD8 for ; Wed, 29 Feb 2012 23:05:58 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 7A70D21E802F for ; Wed, 29 Feb 2012 23:05:57 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q2175iUM007905; Thu, 1 Mar 2012 08:05:44 +0100 Date: Thu, 1 Mar 2012 08:05:44 +0100 From: Willy Tarreau To: Brian E Carpenter Message-ID: <20120301070544.GB7791@1wt.eu> References: <4F4EE80D.6000106@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F4EE80D.6000106@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 07:05:58 -0000 Hi Brian, On Thu, Mar 01, 2012 at 04:07:57PM +1300, Brian E Carpenter wrote: > > => Ok, but my point is that you can't compare flow labels and cookies > > because you'll end up with either incorrect load distribution (because the > > flow label doesn't tell you enough about the connection, or with users > > being distributed onto different servers, depending on which side your > > load distribution algorithm favours. What am I missing? > > As the draft explains, you don't use the flow label to take the > initial decision about which server gets which new session. That > must be done by looking at much more of the first packet, exactly > as today. You use the flow label to accelerate treatment of the > subsequent packets. Please tell us where in the draft we need > to make this more clear. I have talked about that in this thread. In fact, I'm fairly certain that once everyone will observe that flow labels follow an almost uniform distribution, it will be safe to hash them in low level components such as switches. Many switches are already able to hash MAC or IP addresses right now. In a datacenter full of two-port servers, MAC addresses are very poorly distributed, and nobody complains about the risk to cause an unbalanced distribution on etherchannels. Same for IP addresses where .0 and .255 are almost never seen. But I agree that right now we should focus only on load balancers learning the flow label and not on hashing. > You do accept the 1 in 2^20 chance that two unrelated sessions have the > same flow label; in that case they will need to be redirected to the same > server. In any case the LB is going to need a hash table to look up current > flow labels, but it certainly contains a monstrous hash table today for > other reasons. Server LBs are stateful beasts, unfortunately. Let's talk about "lookup table" instead of "hash table" to avoid confusion here. > (In contrast to ECMP/LAG, which should be stateless.) > > > Relying on applications to do the right thing (use a good RNG) for your > > infrastructure to work seems like a proposition that could lead to > > unreliable results. > > It can only be better than today, where there is zero entropy > in the flow label. The draft also discusses the case where the > source doesn't set the label. > > As for choice of RNG, yes, it needs to be reasonable. I have some > results on this coming very soon. In fact there are many other alternative to RNGs to provide a valid flow label inside a browser (sorry for insisting on browsers but I think that HTTP right now is the most load-balanced protocol). It could be anything such as a hash of the precise time the user clicked the link to the page, it could be whatever you like. It could even be a hash of the MAC address of the device itself which would always tie it to the same server for a given site. That's not really an issue, as we don't need it to be unpredictable nor cryptographically strong, we just need it to be uniformly distributed across all clients. > >> Look at how load balancing is performed everywhere. > >> IP address is never used when you need to guarantee > >> user stickiness (eg: HTTP, RDP, ...). > > > > => Changing IP address is a rare case, > > I'll let Willy comment on that, but he tells me that it's a very common > case, viewed from a server site. Yes I can confirm that and everyone dealing with load balancers is well aware of this fact too which forces you to use something else to stick on if stickiness is critical (eg: your shopping basket). Depending on the sites, you can see between 1 and 5% of visitors using more than one source address in their whole session. Even if it was only 0.01% it would be huge because it would mean that for a site seeing 1 million visitors a day (not a big site), you would have 100 people complaining every day that your site is broken. And here I'm talking about much many ones. I have identified three reasons for changing IP addresses : - use of load-balanced proxy farms (the "AOL effect" as it used to be called among web developers) : the client connects to a farm of caching proxies which perform URL-based stickiness to improve caching. They reach the net with a different source address, so many URLs are fetched from different IP addresses ; This practise now tends to be masked by NAT in enterprises but not much at ISPs. With V6, it should reappear better in enterprises with NAT disabled. - mobility : if you look at the address of a mobile user along a session, you'll see that *many* of them regularly change. They change when the device is moving (I suspect that sites such as Facebook where people connect to in the train observe this effect a lot), and after long idle periods ("long" meaning something like 5-10 seconds with some operators). - load-balanced ADSL links. Since ADSL is of extremely poor stability in some places, we've seen the rise of ADSL link loadbalancing gateways. Customers want to use all of their links since they're paying for them, and this results in traffic being randomly spread over the multiple links depending on their instant load or queue size. Each link has a different address and very often is connect to a different ISP in order to maximize reliability. So a client session again uses multiple addresses. Regards, Willy