From despres.remi@laposte.net Fri Jun 1 00:51: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 2B74C21F8639 for ; Fri, 1 Jun 2012 00:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ZXky9KKoV1Mc for ; Fri, 1 Jun 2012 00:51:20 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2654C21F862B for ; Fri, 1 Jun 2012 00:51:19 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2306.sfr.fr (SMTP Server) with ESMTP id C926370000A5; Fri, 1 Jun 2012 09:51:18 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2306.sfr.fr (SMTP Server) with ESMTP id 74B9870000B8; Fri, 1 Jun 2012 09:51:18 +0200 (CEST) X-SFR-UUID: 20120601075118478.74B9870000B8@msfrf2306.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <0D5AC90B-4DCC-4B22-A0C2-54C1FD5ADCDE@gmail.com> Date: Fri, 1 Jun 2012 09:51:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <66611357-7E62-4C22-98A9-D50ABC983CD1@laposte.net> References: <20120518183342kawashimam@mail.jp.nec.com> <813FF89D-FBAF-4634-BF35-E6021D1777E0@laposte.net> <20120529135003.FB9C.8FE1F57E@jpix.ad.jp> <0D5AC90B-4DCC-4B22-A0C2-54C1FD5ADCDE@gmail.com> To: Masataka Mawatari X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 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, 01 Jun 2012 07:51:21 -0000 Masataka-san, 2012-05-29 21:13, jouni korhonen: ... > I do not think the text needs to explicitly state > that the dedicated prefix model is for wireline service. Same view. > Just saying > it applies for any service that utilizes DHCPv6-PD should suffice. In my understanding: - the Dedicated IPv6 prefix model (BTW still too imprecisely defined = IMHO), can work with any way to advertise the chosen 4X4XLAT prefix. = DHCPv6-PD can be for this a possibility, but still incompletely = specified AFAIK if several prefixes are delegated. - Wireline services that support DHCPv6-PD (which is typical) don't need = to use the Dedicated prefix model to use 464XLAT.=20 Regards, RD =20 >=20 > - Jouni >=20 >>=20 >> This text is completely splitted by service applicability (moblie >> and wireline). This is hard to cause some confusions in audiences >> of 464XLAT document. >>=20 >> We really understood your thoughts, we can save operation and >> deployment cost for IPv4 long-life support by using dedicated IPv6 >> prefix. >>=20 >> This is a antinomy between dedicated IPv6 prefix is required and >> not required. We understood this. So we are thinking that we >> would like to describe the 2 models. >>=20 >>=20 >> Kind Regards, >> Masataka MAWATARI >>=20 >>=20 >> * On Sat, 19 May 2012 09:32:33 +0200 >> * Admin wrote: >>=20 >>> Masanobu-san, >>>=20 >>> Thank you for the explanation below. >>> Formally, you are right: RFC6145 doesn't cover the case where there = is only one IPv4 address on the IPv4 side, and where therefore a fixed = IPv6 address, non IPv4 translated, can be used. >>>=20 >>> OTOH, RFC 6052 says, about Stateless translation "Both = IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses = SHOULD use the same prefix". Using different IPv6 prefixes for = customer-side and Internbet-side IPv4 addresses would introduce an = exception to this rule, with the need to explain. >>>=20 >>> The IANA EUI-64 interface ID remains IMHO worth using, at least when = CLAT nodes contain NAT44s. >>>=20 >>> Regards, >>> RD >>=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 rja.lists@gmail.com Fri Jun 1 05:44: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 4C36811E8536 for ; Fri, 1 Jun 2012 05:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 PYHMKBOCds+b for ; Fri, 1 Jun 2012 05:44:52 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A456F21F8C0D for ; Fri, 1 Jun 2012 05:44:47 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1400929vcq.31 for ; Fri, 01 Jun 2012 05:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rpofXknMoub05rQWoq5VBXYL2pshZLEPa1YJFTTZSnI=; b=mOd2QLxI8PZVehRq+ZsiTx6HL+7HjIAIlSKfYdEJd61Mb9f05wLudvK+MfrO8+YOlz ebsJr1FMxF7q1VcR0DsMHROKc165ZcsWkkhrjURtDWRwvrJ4FQ/X651Rr10C71eBn0Xk 7ywu9QCojDDTFY1U9kiILYWugJuxYhQd3+9p0KLCXKpqRGORiiM2FeEzUnfSmbTAoeb6 hD9HIe47LWYK9+cXrD7iWAfXgmvs/y0v/VqhUwMgsPuHsiVi1g9xRx9nXxM11WaUfF2t AI7XFAmea3Q611JVDhXBny8eI6Ti8x0ZVEf5up573Wtx2dLo4y4zA+KBBLJ5WEMj+AsE uOgA== Received: by 10.52.93.50 with SMTP id cr18mr2318779vdb.41.1338554687030; Fri, 01 Jun 2012 05:44:47 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id n2sm2907507vdj.3.2012.06.01.05.44.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jun 2012 05:44:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: RJ Atkinson In-Reply-To: <4FC81786.10207@gont.com.ar> Date: Fri, 1 Jun 2012 08:44:46 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> <4FC7934B.4010205@si6networks.com> <49E46AEE-9BB2-4A08-8069-29D692B21B6B@gmail.com> <4FC7BE00.10403@si6networks.com> <67981392-14C0-46D6-B8E4-D50BEDF7D5FE@gmail.com> <4FC81786.10207@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1278) Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Jun 2012 12:44:53 -0000 On 31 May 2012, at 21:14 , Fernando Gont wrote: > But it was argued (in 6man) that of parsing the entire IPv6 header > chain at a layer-2 device was easily doable, and hence there was no need > to limit possible extensions of ND (based on ext headers). If the RA Guard built into the Layer-2 device is built using software on an off the shelf CPU/NP, then the device likely can't parse the entire IPv6 header chain at wire speed -- thereby creating a new easily exploited DOS attack vector on the RA Guard device. This seems like a cure worse than the disease -- as the Ethernet switch connecting everything dies. > In any case, if anything, this would be an argument to the extent to > which ra-guard is simple/possible to implement, rather than about > whether we should leave rule #4 in or out. No. It is a reality-check. Absent custom silicon (FPGA/ASIC), it isn't going to be practical to parse deeply into the packet at interesting fractions of wire-speed. So deploying the RA Guard will create a new avoidable DOS attack vector. To prevent that, no matter what the RA Guard spec says, it is extremely likely that many implementations will give up on parsing after N bytes -- and generally it is a byte limit (rather than a header count limit) from an implementation perspective. >> So some (we hope not many) real world RA Guard implementations will >> not be able to figure out whether a particular valid IPv6 packet is >> valid or not, due to implementation-specific limitations of that >> particular RA Guard implementation. > > I would expect that RA-Guard implementation enforce a limit on the > number of ext headers that they process (rather than of "bytes" that are > "jumped over"). That expectation appears to be disjoint from the way this is likely to be implemented, especially on a Layer-2 only device. Ethernet switch implementers are, for performance reasons, under a lot of pressure to avoid a "store and forward" implementation strategy. Instead, to get the switching times down into a range competitive with the marketplace, the switches try to forward frames after looking at the first N bytes (for the smallest N practical, as a larger N typically increases the switch latency). In turn, many customers buy switches with smaller switching latency. So their product optimisation is strongly biased away from being able to perform deep packet inspection -- which is what RA Guard effectively requires. My expectation is that useful RA Guards will be implemented inside firewalls or inside IPv6 routers that have extensive ACL capabilities (extensive L4 ACLs typically require packet parsing and examination well beyond the IPv6 base header, so adding the RA Guard won't be as big a change). > My take is that those packets will not survive the public IPv6 Internet. > Stateless firewalls will block those packets when the > implementation-specific limit is hit. A state-less firewall is much more likely to use a store-and-decide architecture than a Layer-2 switch, precisely because their main purpose is Deep Packet Inspection. Firewalls typically have some implementation-specific DPI limit, but they normally go MUCH deeper into a packet than a Layer-2 device such as an Ethernet switch. Also, a state-less firewall is much more likely to have some form of silicon assistance (e.g. FPGA/ASIC) in parsing into the packets to keep performance up. This also helps firewalls with functions such as allowing some ICMP message types, but disallowing other ICMP message types. Based on these implementation differences, the RA Guard built into a Layer-2 switch is the likely place that otherwise valid packets might be dropped. The firewalls are much more likely to be able to parse the whole received 1st fragment and make an informed decision. >> Since the hosts will be protecting themselves from any RAs trying to >> hide behind Fragment Headers, there is no risk to having Rule 4 >> either disappear or be changed to allow all packets where the >> particular RA Guard implementation can't figure out whether a given >> IPv6 packet is valid or not. > > I fully agree with this when it comes to updated host implementations. > However, if the rules are changed as you indicate, those "legacy" > implementations that still allow the use of fragmentation with ND would > remain vulnerable. The probability is that those host implementations will get updated MUCH MUCH faster than the RA Guard implementations built to this spec could be implemented, shipped, and deployed. The host OS implementers have been known to ship exactly this kind of security fix in maintenance releases, without waiting for a new major release of their OS. Rule 4 ought not to allow an uninformed drop. If the RA Guard parses the whole packet and confirms that the full header chain isn't present in a 1st fragment packet, then dropping that packet is OK. However, if the RA Guard can't decide -- which will only be due to some implementation limitation within that RA Guard -- then the packet should be sent along. One of the differences between the IETF and some other standards bodies is that the IETF tries to remain grounded in implementation realities. In this case, that means we want a specification that is realistic about various products having varying ability to perform DPI at speed to check for rogue RAs. "Do no harm" is a very good principle here that needs to be kept in mind. Dropping valid IPv6 packets is harmful to the network, and needs to be explicitly forbidden. The best way to ensure this is to modify Rule 4. >> At a more architectural level, if the IPv6 specs need to change, then >> I'd like to see those changes proposed and accepted by the 6MAN WG >> (or its successors) -- rather than having an IETF recommended >> operational practice have the result of changing the IPv6 specs >> without bothering to update the actual IPv6 specs. > > I personally believe that the specs should be changed -- for instance, > we're pursuing that effort in 6man with > draft-gont-6man-oversized-header-chain (about which 6man should be > polled soon). I'm glad we at least agree on process. I look forward to seeing the new revision of these I-Ds. Yours, Ran From nick@inex.ie Fri Jun 1 06: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 389E621F8B6F for ; Fri, 1 Jun 2012 06:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2NbrmnezEWp for ; Fri, 1 Jun 2012 06:33:36 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7AF21F8B6D for ; Fri, 1 Jun 2012 06:33:35 -0700 (PDT) X-Envelope-To: Received: from cupcake.local ([IPv6:2001:1bb8:2004:100:f0f2:ab4f:abfc:e662]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q51DXMqS031917 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 1 Jun 2012 14:33:24 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FC8C4AD.3000609@inex.ie> Date: Fri, 01 Jun 2012 14:33:33 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> <4FC7934B.4010205@si6networks.com> <49E46AEE-9BB2-4A08-8069-29D692B21B6B@gmail.com> <4FC7BE00.10403@si6networks.com> <67981392-14C0-46D6-B8E4-D50BEDF7D5FE@gmail.com> <4FC81786.10207@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.4.1 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] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Jun 2012 13:33:37 -0000 On 01/06/2012 13:44, RJ Atkinson wrote: > If the RA Guard built into the Layer-2 device is built using > software on an off the shelf CPU/NP, then the device likely > can't parse the entire IPv6 header chain at wire speed -- > thereby creating a new easily exploited DOS attack vector > on the RA Guard device. This seems like a cure worse than > the disease -- as the Ethernet switch connecting everything dies. not really: this is why we have control plane policing. Nick From fernando.gont.netbook.win@gmail.com Fri Jun 1 18: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 4932811E809C for ; Fri, 1 Jun 2012 18:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVY5TWOWPRoG for ; Fri, 1 Jun 2012 18:32:37 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76AD311E8087 for ; Fri, 1 Jun 2012 18:32:37 -0700 (PDT) Received: by yhq56 with SMTP id 56so2389841yhq.31 for ; Fri, 01 Jun 2012 18:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=316QQYq3Vjqx/oXPaWa1x2pjZaUOzDC7xhKe+tFcjtk=; b=JFB4gKHAzxmFeJKbxpTr0zEwS9CfFo5d/Q8Gr6ZCc59bP2/t8qUOv6bUuMYBgyOln1 E3j98kKPqqVdpaVPr0+zvAZ0z4KuyXQlS5YFwhT86ISnPJJCU+lM7R5+Ehd6AwClJ6JZ iZFSJHailaY++5hhC6c/2YccOvXNTkvRrO1V0m4U1b+XBfsWDWNJ0HVDpPCDQfsdUpyH /0tADIZP6vtq+pSNI1y2l6n08X25CFH9HNckIJ5HNKgnnYntNh5e56zsKeJtwIJESfRY HzzTtY2CnCQVR0cf8RJa6j+Wk5uHBtfOvQoLGfYYyK3YzET2qeldu57eQaiYPzvH5tNJ GSaA== Received: by 10.236.192.169 with SMTP id i29mr18974yhn.100.1338600757021; Fri, 01 Jun 2012 18:32:37 -0700 (PDT) Received: from [192.168.123.103] ([186.134.2.37]) by mx.google.com with ESMTPS id n37sm5114843anq.0.2012.06.01.18.32.34 (version=SSLv3 cipher=OTHER); Fri, 01 Jun 2012 18:32:35 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FC95A82.3000600@gont.com.ar> Date: Fri, 01 Jun 2012 21:12:50 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Joel jaeggli References: <20120601035829.5632.30137.idtracker@ietfa.amsl.com> <4FC83EE3.3080000@bogus.com> In-Reply-To: <4FC83EE3.3080000@bogus.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] FYI v6ops - New Meeting Session Request for IETF 84 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Jun 2012 01:32:38 -0000 Hi, Joel, On 06/01/2012 01:02 AM, Joel jaeggli wrote: > Conflicts to Avoid: > First Priority: 6man behave homenet softwire > Second Priority: 6renum > Third Priority: opsarea opsawg [....] > > If there are notable conflict that we should have listed but don't, that > would be could to know. opsec should probably be included as "first priority", since at least at the Paris IETF a number of v6-operations docuements were presented at opsec (and in some cases, I think they were presented both in v6ops and opsec). Just my 2 cents. Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From mawatari@jpix.ad.jp Sun Jun 3 17:46: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 9220021F87BE for ; Sun, 3 Jun 2012 17:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.36 X-Spam-Level: X-Spam-Status: No, score=0.36 tagged_above=-999 required=5 tests=[AWL=0.450, 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 m2Hn7djy1Vzb for ; Sun, 3 Jun 2012 17:46:56 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 27F2121F8512 for ; Sun, 3 Jun 2012 17:46:55 -0700 (PDT) Received: from [192.168.0.229] (64es-v4pool4.jpix.ad.jp [202.90.12.4]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 32560FC021 for ; Mon, 4 Jun 2012 09:46:54 +0900 (JST) Date: Mon, 04 Jun 2012 09:46:55 +0900 From: MAWATARI Masataka To: v6ops@ietf.org In-Reply-To: <66611357-7E62-4C22-98A9-D50ABC983CD1@laposte.net> References: <0D5AC90B-4DCC-4B22-A0C2-54C1FD5ADCDE@gmail.com> <66611357-7E62-4C22-98A9-D50ABC983CD1@laposte.net> Message-Id: <20120604094655.0005.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] 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, 04 Jun 2012 00:46:56 -0000 Dear Remi-san and all, Thank you very much for your responding. We understood your thoughts. We will revise 464XLAT document by clarifying texts about some sections (overview, architecture, applicability, etc.) based on your helpful comments. We are thinking that no NAT44 model on edge model is one of the uniqueness. Kind Regards, Masataka MAWATARI * On Fri, 1 Jun 2012 09:51:17 +0200 * Remi Despres wrote: > Masataka-san, > > > 2012-05-29 21:13, jouni korhonen: > .. > > I do not think the text needs to explicitly state > > that the dedicated prefix model is for wireline service. > > Same view. > > > > Just saying > > it applies for any service that utilizes DHCPv6-PD should suffice. > > In my understanding: > - the Dedicated IPv6 prefix model (BTW still too imprecisely defined IMHO), can work with any way to advertise the chosen 4X4XLAT prefix. DHCPv6-PD can be for this a possibility, but still incompletely specified AFAIK if several prefixes are delegated. > - Wireline services that support DHCPv6-PD (which is typical) don't need to use the Dedicated prefix model to use 464XLAT. > > Regards, > RD From mawatari@jpix.ad.jp Sun Jun 3 17:50: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 EC3AE21F87C3 for ; Sun, 3 Jun 2012 17:50:51 -0700 (PDT) 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_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 3Pla7farE4SK for ; Sun, 3 Jun 2012 17:50:51 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 77E4E21F87BE for ; Sun, 3 Jun 2012 17:50:51 -0700 (PDT) Received: from [192.168.0.229] (64es-v4pool4.jpix.ad.jp [202.90.12.4]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 0E0F6FC021 for ; Mon, 4 Jun 2012 09:50:51 +0900 (JST) Date: Mon, 04 Jun 2012 09:50:52 +0900 From: MAWATARI Masataka To: v6ops@ietf.org In-Reply-To: <0D5AC90B-4DCC-4B22-A0C2-54C1FD5ADCDE@gmail.com> References: <20120529135003.FB9C.8FE1F57E@jpix.ad.jp> <0D5AC90B-4DCC-4B22-A0C2-54C1FD5ADCDE@gmail.com> Message-Id: <20120604095052.0009.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] 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, 04 Jun 2012 00:50:52 -0000 Dear Jouni-san, Thank you very much for your comments. As we responded earlier, we will revise for the better document. Please wait next. Kind Regards, Masataka MAWATARI * On Tue, 29 May 2012 22:13:29 +0300 * jouni korhonen wrote: > Hi, > > One comment below. > > On May 29, 2012, at 7:50 AM, MAWATARI Masataka wrote: > > > Dear Remi-san and all, > > > > > > We appreciate your every comments about 464XLAT. > > > > We will add that the CLAT on 464XLAT architecture does not comply > > with "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 > > addresses SHOULD use the same prefix." that is described on Section > > 3.3. in RFC 6052. > > > > And about document's category, we do not care about the document's > > category as we have told once. The reason that we changed category > > from Informational to BCP is due to v6ops chairs' suggestion. If > > v6ops chairs say a request to change from BCP to Informational, we > > will defer to that. > > > > In case of keeping present category, although we don't know whether > > you are going to like or not, we would like to propose you. > > > > What do you think about splitting text of "no dedicated IPv6 prefix > > model by using NAT44 with IANA's EUI-64 ID" for mobile service (3G, > > LTE, etc.) that does not utilize DHCPv6-PD yet and "dedicated IPv6 > > prefix model" for wireline service that utilize DHCPv6-PD as a > > convenient function. > > For the latter I do not think the text needs to explicitly state > that the dedicated prefix model is for wireline service. Just saying > it applies for any service that utilizes DHCPv6-PD should suffice. > > - Jouni > > > > > This text is completely splitted by service applicability (moblie > > and wireline). This is hard to cause some confusions in audiences > > of 464XLAT document. > > > > We really understood your thoughts, we can save operation and > > deployment cost for IPv4 long-life support by using dedicated IPv6 > > prefix. > > > > This is a antinomy between dedicated IPv6 prefix is required and > > not required. We understood this. So we are thinking that we > > would like to describe the 2 models. > > > > > > Kind Regards, > > Masataka MAWATARI From Fred.L.Templin@boeing.com Mon Jun 4 14:57: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 1085421F86D6 for ; Mon, 4 Jun 2012 14:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 RfkVv3nlwvbj for ; Mon, 4 Jun 2012 14:57:25 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id A204B21F86D5 for ; Mon, 4 Jun 2012 14:57:25 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q54LvgcF027726 for ; Mon, 4 Jun 2012 14:57:42 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q54Lvejo027220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Jun 2012 14:57:40 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q54LvMtu018151; Mon, 4 Jun 2012 16:57:22 -0500 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q54LvLTX018138 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 4 Jun 2012 16:57:22 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Mon, 4 Jun 2012 14:57:21 -0700 From: "Templin, Fred L" To: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Date: Mon, 4 Jun 2012 14:57:20 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac06HpqGDdQcCmriReGswY42wO8iFAAalwRgAgT2iBA= Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Jun 2012 21:57:26 -0000 FYI, the tunnel MTU discussion seems to have spilled over onto the nanog list, where some of the same issue points are being discussed. Fred From fernando.gont.netbook.win@gmail.com Mon Jun 4 19:51: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 B534021F8647 for ; Mon, 4 Jun 2012 19:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilVZxb8Ln4Wc for ; Mon, 4 Jun 2012 19:51:54 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 645F121F8642 for ; Mon, 4 Jun 2012 19:51:51 -0700 (PDT) Received: by yhq56 with SMTP id 56so3911826yhq.31 for ; Mon, 04 Jun 2012 19:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=Xy+MsaTb+0MOJ21oV7104mCV3LcUJQ1x95LsOYABCvw=; b=K8mAAH3/751OsPBW/LH7lUh0E/tWdQrbeNOUzXC0a2SgNEA8kAv1SkPR2FQ4Rlbxjg V0AUufIJy3Wdh3uRFrjfSgUI3Ghzy+uUhMbK+IXyhyYJkSmUFeMDnu8+AC7lzAu91CiA nyBhi7EuEOwcyis5OJokFNuQYhe7stugWTv8YrW5sR7hPxjIhjBwRn+l8R15ZpjLWxKH SQvsF1mTr3vudGTZvw8y5/rdRtD8xy3oMp3ETmF35iqchIs34/CgeeVH9rweccMJZRqa VVbqee4TbHbF4uFYyrlGX/HluWCPo8F5RUepbvkZEOSMCdo91VybQAh72Z7SHpauFOd3 5PuA== Received: by 10.236.156.69 with SMTP id l45mr9484256yhk.123.1338864710599; Mon, 04 Jun 2012 19:51:50 -0700 (PDT) Received: from [192.168.0.170] (61-128-17-190.fibertel.com.ar. [190.17.128.61]) by mx.google.com with ESMTPS id v61sm998085yhi.17.2012.06.04.19.51.27 (version=SSLv3 cipher=OTHER); Mon, 04 Jun 2012 19:51:49 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FCD622C.2080503@gont.com.ar> Date: Mon, 04 Jun 2012 22:34:36 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: RJ Atkinson References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> <4FC7934B.4010205@si6networks.com> <49E46AEE-9BB2-4A08-8069-29D692B21B6B@gmail.com> <4FC7BE00.10403@si6networks.com> <67981392-14C0-46D6-B8E4-D50BEDF7D5FE@gmail.com> <4FC81786.10207@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Jun 2012 02:51:54 -0000 Hi, Ran, On 06/01/2012 09:44 AM, RJ Atkinson wrote: > On 31 May 2012, at 21:14 , Fernando Gont wrote: >> But it was argued (in 6man) that of parsing the entire IPv6 header >> chain at a layer-2 device was easily doable, and hence there was no need >> to limit possible extensions of ND (based on ext headers). > > If the RA Guard built into the Layer-2 device is built using > software on an off the shelf CPU/NP, then the device likely > can't parse the entire IPv6 header chain at wire speed -- > thereby creating a new easily exploited DOS attack vector > on the RA Guard device. This seems like a cure worse than > the disease -- as the Ethernet switch connecting everything dies. FWIW, this is the discussion I was referring to: . My understanding is that we ended up converging on banning *only* the Fragmentation Header (in draft-gont-6man-nd-extension-headers) based on the outcome of that discussion (i.e., parsing the IPv6 header chain at wire speed being doable). If RA-Guard were to be implemented as you describe, I agree that in *that* case the cure could be worse than the disease. >> In any case, if anything, this would be an argument to the extent to >> which ra-guard is simple/possible to implement, rather than about >> whether we should leave rule #4 in or out. > > No. It is a reality-check. Absent custom silicon (FPGA/ASIC), > it isn't going to be practical to parse deeply into the packet > at interesting fractions of wire-speed. Should I add some text about this in the Security Considerations section? >> My take is that those packets will not survive the public IPv6 Internet. >> Stateless firewalls will block those packets when the >> implementation-specific limit is hit. > > A state-less firewall is much more likely to use a store-and-decide > architecture than a Layer-2 switch, precisely because their main purpose > is Deep Packet Inspection. Agreed. However, my point is that if your packets lack the entire IPv6 header chain, they are likely to be dropped (whether by a stateless translator, a stateless firewall, or anything else), and hence should probably not be relied upon. > Rule 4 ought not to allow an uninformed drop. If the RA Guard parses > the whole packet and confirms that the full header chain isn't present > in a 1st fragment packet, then dropping that packet is OK. > > However, if the RA Guard can't decide -- which will only be due to some > implementation limitation within that RA Guard -- then the packet > should be sent along. Ok, this seems reasonable -- since I've not yet gone through the messages that you've posted on the subject, I will go through them first (since this is probably discussed in more detail in those). Otherwise I will come back to you on this one in a standalone e-mail. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From iljitsch@muada.com Tue Jun 5 22:48: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 9C2DF21F86FF for ; Tue, 5 Jun 2012 22:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.53 X-Spam-Level: X-Spam-Status: No, score=-101.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 LREyexHJj48D for ; Tue, 5 Jun 2012 22:48:28 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id E9A4F21F86FD for ; Tue, 5 Jun 2012 22:48:27 -0700 (PDT) Received: from ip212-238-42-225.hotspotsvankpn.com (ip212-238-42-225.hotspotsvankpn.com [212.238.42.225]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id q565l7dh000362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Jun 2012 07:47:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Iljitsch van Beijnum In-Reply-To: <201202141455.q1EEt1I04887@ftpeng-update.cisco.com> Date: Tue, 5 Jun 2012 21:33:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6568CBCF-150E-45AD-BCEB-428974A8DEF1@muada.com> References: <201202141455.q1EEt1I04887@ftpeng-update.cisco.com> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1278) Cc: draft-chen-v6ops-nat64-experience@tools.ietf.org Subject: Re: [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: Wed, 06 Jun 2012 05:48:28 -0000 On 14 Feb 2012, at 15:55 , wrote: > 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. I had a quick read and I don't get it. What is the point of this draft? It looks to me like some kind of = management summary of NAT64. And although it has "experience" in the title, I didn't find any "we did = A and then B happened" type of discussion in the document. What's with the NAT64-CGN and NAT64-CE terminology? Isn't the latter = just NAT46? Considering the above, I strongly recommend that this document be = abandoned so as to not take up time that could be used for something = productive.= From phdgang@gmail.com Wed Jun 6 03:53: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 6590421F86F4 for ; Wed, 6 Jun 2012 03:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnL9NuJa73ir for ; Wed, 6 Jun 2012 03:53:32 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2583921F869C for ; Wed, 6 Jun 2012 03:53:31 -0700 (PDT) Received: by werb13 with SMTP id b13so4860112wer.31 for ; Wed, 06 Jun 2012 03:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aKscOAWOa2vLRhmudR5Bb6p8eo+eZxM26PtQWOWD/cc=; b=oD1hKUMSoHgtfr+oTKba/MxhK52UwmTz5mmp0IvAt0MIn9EtypUlHXPKyRfcgDn+pd csQUMj5Lc6v2xuxdSYO5izJCBGh76R5JXYioP+LSbyIkTkOHy4XxGsXqPuUBwWRwceFE aBYpspFAhCnmlaSN+qe56TCb9fDW21f4m6jn1rrdzcVUAsBKQP+nW54E7Q/lwLcccobs DYsIt40sgUmFIdyIyORCkK4I9LYgRCLKGfNZ6kK/QaDqZc0x+EcrfUfUeL/j9UMeI7np 2ejSKzhdfjy40CSnUllI3RnNm6H+zp/2UhNRkj1A3t8hrhNs/2X7chld8hhuJ5RKiLWp mlmA== MIME-Version: 1.0 Received: by 10.216.140.33 with SMTP id d33mr4347603wej.113.1338980011055; Wed, 06 Jun 2012 03:53:31 -0700 (PDT) Received: by 10.180.104.136 with HTTP; Wed, 6 Jun 2012 03:53:30 -0700 (PDT) In-Reply-To: <6568CBCF-150E-45AD-BCEB-428974A8DEF1@muada.com> References: <201202141455.q1EEt1I04887@ftpeng-update.cisco.com> <6568CBCF-150E-45AD-BCEB-428974A8DEF1@muada.com> Date: Wed, 6 Jun 2012 18:53:30 +0800 Message-ID: From: GangChen To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , draft-chen-v6ops-nat64-experience@tools.ietf.org Subject: Re: [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: Wed, 06 Jun 2012 10:53:33 -0000 2012/6/6, Iljitsch van Beijnum : > On 14 Feb 2012, at 15:55 , wrote: > >> 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. > > I had a quick read and I don't get it.> > What is the point of this draft? It looks to me like some kind of management > summary of NAT64.> > And although it has "experience" in the title, I didn't find any "we did A > and then B happened" type of discussion in the document. Thanks for your attention. The goal is to generalize the "NAT64 experiences" in a single document. The implicited practices in the experiences are certainly doing the "we did A and then B happened". I can describe them in your language as below. -->NAT64-CGN NAT64 placement: we did centralized deployment on CR with embedded NAT64, then it found the cost is much than distributed on BNG with NAT64-by-side NAT64 HA: we did hot-standby and cold-standby, then hot-standby does not offer much benefit because the most common Internet traffic type is short lived sessions Traceability: we did online (by Radius server), then it found high performance is required on Radius servers (Another recommendation is to add logging amount discussion, we will update that at next version) Quality of Experience: we did testing on ALG, then it found the practices doesn't conform the standard pace. Most ALG is vendor-specific, even doesn't support it at all --->NAT64-CE we did NAT64-CE for enterprise customers, then it found IPv6 space much bigger than IPv4 space we did NAT64-CE for enterprise customers, then it found Anti-DDoS/SYN Flood should be considerated we did load-balance for NAT6-CE, then it found DNS64-based could not work, load balancer is preferable we did NAT64-CE for enterprise customers, then it found MTU on IPv4 network is better to set more than 1260(IPv4 network normally operated by a particular entity) Since it's a generalized experience, we may not strictly formulate the text as "we did A and then B happened" type But we could do that, if the group asks such expressing > What's with the NAT64-CGN and NAT64-CE terminology? Isn't the latter just > NAT46? The terms (CGN/CE) is only to be understood as a topological qualifier. Different scenarios link to RFC6144. One explanation is the third paragraph in introduction. In short NAT64-CE is the IPv6 Internet to Ipv4 network scenario. NAT64-CE has nothing to do with NAT46. NAT64-CE is subsided the location to a customer edge, e.g. Enterprise-GW. Many legacy IPv4 servers would benefit from such placement and become accessible from IPv6. Please see more at section 3.1 > Considering the above, I strongly recommend that this document be abandoned > so as to not take up time that could be used for something productive. I guess that is not a fair decision for a item people in favor of in last meeting. Gang From iljitsch@muada.com Wed Jun 6 04:02: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 DB9C421F8615 for ; Wed, 6 Jun 2012 04:02:55 -0700 (PDT) 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 0PPTGKqOIyrr for ; Wed, 6 Jun 2012 04:02:55 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 2078321F85FB for ; Wed, 6 Jun 2012 04:02:54 -0700 (PDT) Received: from [IPv6:2001:610:159:dead:a1fd:ce4a:c51f:8cd5] ([IPv6:2001:610:159:dead:a1fd:ce4a:c51f:8cd5]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id q56B1g7G002669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Jun 2012 13:01:42 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 6 Jun 2012 13:02:51 +0200 Content-Transfer-Encoding: 7bit Message-Id: <0C379D4E-BA4D-43FC-B984-04EC25D1EA15@muada.com> References: <201202141455.q1EEt1I04887@ftpeng-update.cisco.com> <6568CBCF-150E-45AD-BCEB-428974A8DEF1@muada.com> To: GangChen X-Mailer: Apple Mail (2.1278) Cc: IPv6 Ops WG , draft-chen-v6ops-nat64-experience@tools.ietf.org Subject: Re: [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: Wed, 06 Jun 2012 11:02:56 -0000 On 6 Jun 2012, at 12:53 , GangChen wrote: > The goal is to generalize the "NAT64 experiences" in a single document. Wouldn't that be more like an applicability document? From phdgang@gmail.com Wed Jun 6 04:38: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 D092521F8838 for ; Wed, 6 Jun 2012 04:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpu0kF42oI99 for ; Wed, 6 Jun 2012 04:38:18 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC7F421F883F for ; Wed, 6 Jun 2012 04:38:17 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so4023439wib.13 for ; Wed, 06 Jun 2012 04:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ozc1GAHi7GUqID90eyzdscA92cGqb1EsAsrFl8rGj9I=; b=faZ2vSPWMa84Za2XhN7vvj+zNmNHgqP2h1MKqSLR8CdcfktNUJtDLgvLPabzRf1ODZ ID5UfZoWCdzkNCHj+foG47eA4iOCn+kEJ/iI4+PmLraBeayqD5uonFJHLn+GZZKqfBi1 eqd/oF8fNXHLyKa5YY1FgkrMsPu4p7yWWwsCd+hEyPxkMR4NU8+vZ2W1fPvKL4SCE/mK jF3Xpib5iuBS7khBOiNFCZaQTm/ja5kVrcuLoji38DdKRZYQVRX+7EAl6IBAZivqZxCv AMOckivXfrGBqkxyElgMOEP5b54RJWbA+K1jgGQgaaHS5mV9YsUhUidojGGllvNjV8FI zDNQ== MIME-Version: 1.0 Received: by 10.216.196.91 with SMTP id q69mr16864012wen.185.1338982696994; Wed, 06 Jun 2012 04:38:16 -0700 (PDT) Received: by 10.180.104.136 with HTTP; Wed, 6 Jun 2012 04:38:16 -0700 (PDT) In-Reply-To: <0C379D4E-BA4D-43FC-B984-04EC25D1EA15@muada.com> References: <201202141455.q1EEt1I04887@ftpeng-update.cisco.com> <6568CBCF-150E-45AD-BCEB-428974A8DEF1@muada.com> <0C379D4E-BA4D-43FC-B984-04EC25D1EA15@muada.com> Date: Wed, 6 Jun 2012 19:38:16 +0800 Message-ID: From: GangChen To: Iljitsch van Beijnum Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , draft-chen-v6ops-nat64-experience@tools.ietf.org Subject: Re: [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: Wed, 06 Jun 2012 11:38:18 -0000 2012/6/6, Iljitsch van Beijnum : > On 6 Jun 2012, at 12:53 , GangChen wrote: > >> The goal is to generalize the "NAT64 experiences" in a single document. > > Wouldn't that be more like an applicability document? > http://www.ietf.org/mail-archive/web/v6ops/current/msg11145.html already helped to clarify that. Please take a look Gang From rja.lists@gmail.com Thu Jun 7 08:45: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 65FE911E80B6 for ; Thu, 7 Jun 2012 08:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 OpJC2DnFgsqy for ; Thu, 7 Jun 2012 08:45:17 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A71F21F8670 for ; Thu, 7 Jun 2012 08:45:17 -0700 (PDT) Received: by vcqp1 with SMTP id p1so451131vcq.31 for ; Thu, 07 Jun 2012 08:45:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=NUX7/xW4f5kcE2vwDnauRKdWuvenItqSsbNDCPh9b/M=; b=a0+DRaBJKxBfZHciqqMN3DaCLhWurH9dZ5KaFmfNi0xHjw3Iouci+7rqcby7AY/n2d YVQDhzM0iN4mHzdv00RlMjWvksvtG8imoHgQ2Qo6MYNzMui5NSUG8TvecFBknZcczFe4 D/AtsoVUSceF88iyTEUBLrW5tdsNTJmnBqssdW8fY6wBGjC2cvoYPV6fGCchK4Ak+VUe gaKvato5Wu1gPnnAZ+ChgN/GCe2OatyeiGIjzue1YJg/SfS6IQsQhKlMSyRDSFbjgYUc qBTTVMxEwaP2x7J9j6Cg9qJMckQgmAJV7aBMdRIy8TfsGdXomKC1T9roxHWoXESgx1Jc Jgnw== Received: by 10.220.107.130 with SMTP id b2mr2506939vcp.35.1339083916560; Thu, 07 Jun 2012 08:45:16 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id by3sm5079488vdc.17.2012.06.07.08.45.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jun 2012 08:45:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: RJ Atkinson In-Reply-To: <4FCD622C.2080503@gont.com.ar> Date: Thu, 7 Jun 2012 11:45:12 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> <4FC7934B.4010205@si6networks.com> <49E46AEE-9BB2-4A08-8069-29D692B21B6B@gmail.com> <4FC7BE00.10403@si6networks.com> <67981392-14C0-46D6-B8E4-D50BEDF7D5FE@gmail.com> <4FC81786.10207@gont.com.ar> <4FCD622C.2080503@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1278) Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Jun 2012 15:45:18 -0000 On 04 Jun 2012, at 21:34 , Fernando Gont wrote: > On 06/01/2012 09:44 AM, RJ Atkinson wrote: >> On 31 May 2012, at 21:14 , Fernando Gont wrote: >>> But it was argued (in 6man) that of parsing the entire IPv6 header >>> chain at a layer-2 device was easily doable, and hence there was no need >>> to limit possible extensions of ND (based on ext headers). >> >> If the RA Guard built into the Layer-2 device is built using >> software on an off the shelf CPU/NP, then the device likely >> can't parse the entire IPv6 header chain at wire speed -- >> thereby creating a new easily exploited DOS attack vector >> on the RA Guard device. This seems like a cure worse than >> the disease -- as the Ethernet switch connecting everything dies. > > FWIW, this is the discussion I was referring to: > . > > My understanding is that we ended up converging on banning *only* the > Fragmentation Header (in draft-gont-6man-nd-extension-headers) based on > the outcome of that discussion (i.e., parsing the IPv6 header chain at > wire speed being doable). > > If RA-Guard were to be implemented as you describe, I agree that in > *that* case the cure could be worse than the disease. This issue ought to be mentioned in Security Considerations for the RA Guard, along with advice that implementers add IPv4/IPv6 packet parsing capability to future packet processing hardware. > >>> In any case, if anything, this would be an argument to the extent to >>> which ra-guard is simple/possible to implement, rather than about >>> whether we should leave rule #4 in or out. >> >> No. It is a reality-check. Absent custom silicon (FPGA/ASIC), >> it isn't going to be practical to parse deeply into the packet >> at interesting fractions of wire-speed. > > Should I add some text about this in the Security Considerations section? Yes, please. See my comments just above. >>> My take is that those packets will not survive the public IPv6 Internet. >>> Stateless firewalls will block those packets when the >>> implementation-specific limit is hit. >> >> A state-less firewall is much more likely to use a store-and-decide >> architecture than a Layer-2 switch, precisely because their main purpose >> is Deep Packet Inspection. > > Agreed. However, my point is that if your packets lack the entire IPv6 > header chain, they are likely to be dropped (whether by a stateless > translator, a stateless firewall, or anything else), and hence should > probably not be relied upon. ** I believe most IPv6 NATs will be able to handle many/all IPv6 packets with chained-headers. Where they don't, those devices are violating IPv6 specifications. ** I also believe that most IPv6 firewalls will be able to handle many/all IPv6 packets with chained-headers. Where they don't, those devices are violating IPv6 specifications. ** I strongly disagree that chained-headers already are broken in the deployed IPv6 Internet. Further, IPv6 specifications REQUIRE that IPv6 nodes handle chained-headers properly. The RA Guard is different from those cases above in one VERY important respect. The RA Guard spec (with its current language) is a case of the IETF formally recommending that implementers ignore the IETF's IPv6 specifications -- which is a very inconsistent, very bad, message for the IETF to be sending. This is resolvable, simply by adding normative references to the related 6MAN I-Ds that update the IETF's IPv6 specifications in specific, clearly specified, clearly justified ways. This process also ensures that the IPv6 specification changes being imposed by the (current) RA Guard text actually are agreeable to the 6MAN WG. If those changes are NOT agreeable, which I consider an unlikely outcome, then that is a strong indication that the current RA Guard text ought to be changed so that it fully complies with IETF IPv6 specifications. If some additional change to IETF IPv6 specifications seems warranted (e.g. a per-packet limit on total number of daisy-chained headers present), then that proposed change ought to be written up as an I-D, normatively cited by the RA Guard I-D, and taken to 6MAN WG for their consideration. >> Rule 4 ought not to allow an uninformed drop. If the RA Guard parses >> the whole packet and confirms that the full header chain isn't present >> in a 1st fragment packet, then dropping that packet is OK. >> >> However, if the RA Guard can't decide -- which will only be due to some >> implementation limitation within that RA Guard -- then the packet >> should be sent along. > > Ok, this seems reasonable -- since I've not yet gone through the > messages that you've posted on the subject, I will go through them first > (since this is probably discussed in more detail in those). Otherwise I > will come back to you on this one in a standalone e-mail. OK. One important goal of mine is to avoid granting a broad license that permits a faulty implementation to truthfully claim that it complies with IETF specifications. Along the same lines, I think some more general editing of the overall RA Guard rule set would be sensible -- so that the implementation requirements of the RA Guard are very clearly specified. Thanks for listening. Cheers, Ran From fernando.gont.netbook.win@gmail.com Fri Jun 8 03:04: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 2B9CC21F84C8 for ; Fri, 8 Jun 2012 03:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUBDgdMp8Cra for ; Fri, 8 Jun 2012 03:04:49 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 79A1C21F84A5 for ; Fri, 8 Jun 2012 03:04:48 -0700 (PDT) Received: by yenq13 with SMTP id q13so1282676yen.31 for ; Fri, 08 Jun 2012 03:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=KLdq0gwg7UjbwGmSf+39a27k85CgJpwPkbx9oXrObhE=; b=C8M9T5juC0DL+/z46Ye8THxShaeON+S9Rf98LJAUWdQLdSqvq6ChwLjOIkbsoTYMp6 Pztllqe7G6FSScapSbWJKgBms1vthPPnQkDqo1Dq2dLG041JZrojsduFQEosfk03/6EP aybcre5drxHUc6DWAtM0Mqm/rfDJgH+VamtLzHFPXbbW3QOFF6dtmlE70hBBC85XbiTF 5OSVQ/r5Vf0kpSwDbg59fjw6YxkCCLGDa8MdqcIwu6uiBR6ndU9kK06C8zAbjPZZs41y eTtPSv45+dHFGLH6jJjbafhgI3/ZZz44DymvPixvGHmVgQoD0bjOtIsM9qbifse8X79q 3qqQ== Received: by 10.236.187.2 with SMTP id x2mr6023207yhm.42.1339149887979; Fri, 08 Jun 2012 03:04:47 -0700 (PDT) Received: from ?IPv6:2001:5c0:1000:a::1a5? ([2001:5c0:1000:a::1a5]) by mx.google.com with ESMTPS id d10sm8550623anm.17.2012.06.08.03.04.43 (version=SSLv3 cipher=OTHER); Fri, 08 Jun 2012 03:04:46 -0700 (PDT) Sender: Fernando Gont Message-ID: <4FD1CE39.5000208@gont.com.ar> Date: Fri, 08 Jun 2012 07:04:41 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: RJ Atkinson References: <7BAC243D-7B55-460E-B36C-52CA83F12B78@gmail.com> <4FC6AAD4.4090108@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C44FF13@EMBX01-WF.jnpr.net> <4FC7864D.8000307@si6networks.com> <13205C286662DE4387D9AF3AC30EF456D76C450163@EMBX01-WF.jnpr.net> <4FC7934B.4010205@si6networks.com> <49E46AEE-9BB2-4A08-8069-29D692B21B6B@gmail.com> <4FC7BE00.10403@si6networks.com> <67981392-14C0-46D6-B8E4-D50BEDF7D5FE@gmail.com> <4FC81786.10207@gont.com.ar> <4FCD622C.2080503@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Jun 2012 10:04:50 -0000 On 06/07/2012 12:45 PM, RJ Atkinson wrote: >> FWIW, this is the discussion I was referring to: >> . >> >> My understanding is that we ended up converging on banning *only* the >> Fragmentation Header (in draft-gont-6man-nd-extension-headers) based on >> the outcome of that discussion (i.e., parsing the IPv6 header chain at >> wire speed being doable). >> >> If RA-Guard were to be implemented as you describe, I agree that in >> *that* case the cure could be worse than the disease. > > This issue ought to be mentioned in Security Considerations > for the RA Guard, along with advice that implementers add > IPv4/IPv6 packet parsing capability to future packet processing > hardware. Will do. >>>> My take is that those packets will not survive the public IPv6 Internet. >>>> Stateless firewalls will block those packets when the >>>> implementation-specific limit is hit. >>> >>> A state-less firewall is much more likely to use a store-and-decide >>> architecture than a Layer-2 switch, precisely because their main purpose >>> is Deep Packet Inspection. >> >> Agreed. However, my point is that if your packets lack the entire IPv6 >> header chain, they are likely to be dropped (whether by a stateless >> translator, a stateless firewall, or anything else), and hence should >> probably not be relied upon. > > ** I believe most IPv6 NATs will be able to handle many/all IPv6 > packets with chained-headers. Where they don't, those devices > are violating IPv6 specifications. Stateless translators require that the entire IPv6 header chain is in the first fragment (since e.g. they will need to drop Dest Options headers and extract the TCP info) -- that's why IPv6 header chains that span multiple fragments won't succeed. (Note: not that I'm happy about this, or that I consider this to be the best possible approach...) > ** I also believe that most IPv6 firewalls will be able to handle > many/all IPv6 packets with chained-headers. Where they don't, > those devices are violating IPv6 specifications. If an IPv6 header chain spans multiple fragments, the the only possible options for firewalls are: * stateless firewalls: simply drop such packets * stateless firewalls: reassemble, filter, and refragment Unless we want to (implicitly) ban IPv6 stateless firewalling, we need to require the entire IPv6 header chain to be in the first fragment. (My take is that if we don't formally do this, firewalls will drop such packets anyway... so we better provide advice that such packets are not generated in the first place) > ** I strongly disagree that chained-headers already are broken > in the deployed IPv6 Internet. Further, IPv6 specifications > REQUIRE that IPv6 nodes handle chained-headers properly. The problem is not chained headers per-se, but rather chained headers that span multiple fragments. (please see my comment above wrt stateless translators and firewalls) > The RA Guard is different from those cases above in one VERY > important respect. The RA Guard spec (with its current language) > is a case of the IETF formally recommending that implementers > ignore the IETF's IPv6 specifications -- which is a very inconsistent, > very bad, message for the IETF to be sending. > > This is resolvable, simply by adding normative references to the > related 6MAN I-Ds that update the IETF's IPv6 specifications in > specific, clearly specified, clearly justified ways. As noted off-list, I think this is a very sensible approach. >> Ok, this seems reasonable -- since I've not yet gone through the >> messages that you've posted on the subject, I will go through them first >> (since this is probably discussed in more detail in those). Otherwise I >> will come back to you on this one in a standalone e-mail. > > OK. One important goal of mine is to avoid granting a broad > license that permits a faulty implementation to truthfully claim > that it complies with IETF specifications. I fully agree with this. Essentially, you're arguing that you don't want an RA-guard to drop valid packets (as a result of an implementation constraint), whereas I don't want a device to be able to claim ra-guard compliance while still being trivial to circumvent. I believe that it is possible to have the ra-guard I-D address both of our concerns. -- more about this shortly. > Thanks for listening. Thank *you* for constructive feedback! Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From rja.lists@gmail.com Fri Jun 8 09:37: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 7DA1721F890B for ; Fri, 8 Jun 2012 09:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=-0.236, 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 ZnlZhO8puSTt for ; Fri, 8 Jun 2012 09:37:26 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D476521F8904 for ; Fri, 8 Jun 2012 09:37:25 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1330225vbb.31 for ; Fri, 08 Jun 2012 09:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=TLXIwx9qxX2tbqxF78B8QPC9OCVk2qFDmZDil0wZXww=; b=1Dm+rvdQRwUHKSRl6ElXolWCaEqXpEhMDeE4rFWKibjPlGDVvsatPjpKMZi9iD5hm+ e+9hf4edTmnOlAUphfwtGpygt+5wXCzHgD2jILylNvd8E0LrXoM+zvVCEJ+HKTid0zCV Fix32KuSjHDcnMOyC2Y2Efloxe9KgMv6Iqju/lJ0hHT+ySVwbsz2esmjMC5raOUdvNNE kEIppn2Hk4dwbiNSbNMedeD8n2A+ePalpGambPlRmicLV5Wd63KASM0857rQ9sjWUBna T0HLOWRXXPs4MiN8gWzd3Vnc1lSb1s9b5J2uVIXy8vHCZnKvKZ4t4kc5TntDTsDhUtcc Szrw== Received: by 10.52.21.177 with SMTP id w17mr5879437vde.98.1339173445250; Fri, 08 Jun 2012 09:37:25 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id c17sm10480960vdj.11.2012.06.08.09.37.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 09:37:23 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 8 Jun 2012 12:37:21 -0400 Message-Id: <1808D6C4-0207-4163-B364-7329C6D2572D@gmail.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: Re: [v6ops] Last Call: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Jun 2012 16:37:26 -0000 At this point, my understanding is that Fernando has agreed to make some edits to draft-ietf-v6ops-ra-guard-implementation to resolve the concerns raised on the v6ops list. These edits include at least: -- adding the 2 IPv6 specification update I-Ds as normative references, draft-gont-6man-nd-extension-headers and also draft-gont-6man-oversized-header-chain, so that the IETF avoids recommending that RA Guard implementers violate the IETF IPv6 specifications. -- updating the Security Considerations as discussed on v6ops, and to note the potential that deploying the RA Guard can create a new DoS attack vector (e.g. on the RA Guard itself). -- editing the RA Guard text to improve the crispness/clarity of the implementation requirements & also eliminating the situation where an RA Guard would drop a valid IPv6 packet (example: RA Guard MUST parse the packet's whole IPv6 header chain, thereby eliminating the situation where a correct RA Guard implementation might not know whether a packet is valid or not) For my part, I hope the 6MAN WG will approve the 2 specification updates in the first item listed above, and undertake that soon. (I don't expect the proposed updates will be controversial in 6MAN, but often I am confused.) I'm unclear whether text specific to the SEND situation might be added or not, but it might well be sensible to add some text, since SEND is cryptographically authenticated (so forged RAs would be dropped by recipients as "authentication failed"). Yours, Ran From internet-drafts@ietf.org Sat Jun 9 13:43: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 6150B21F863D; Sat, 9 Jun 2012 13:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8p8I69La0LS; Sat, 9 Jun 2012 13:43:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DBA21F8630; Sat, 9 Jun 2012 13:43:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120609204303.11860.77131.idtracker@ietfa.amsl.com> Date: Sat, 09 Jun 2012 13:43:03 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-discard-prefix-05.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, 09 Jun 2012 20:43:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : A Discard Prefix for IPv6 Author(s) : Nick Hilliard David Freedman Filename : draft-ietf-v6ops-ipv6-discard-prefix-05.txt Pages : 6 Date : 2012-06-09 Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates the IPv6 Special Purpose Address Registry by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-discard-prefix-05= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-discard-prefix-05.= txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-discard-prefix/ From joelja@bogus.com Sun Jun 10 10:38: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 A870521F858E for ; Sun, 10 Jun 2012 10:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.399 X-Spam-Level: X-Spam-Status: No, score=-99.399 tagged_above=-999 required=5 tests=[BAYES_50=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 OUAYVEliql3P for ; Sun, 10 Jun 2012 10:38:25 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4866A21F857F for ; Sun, 10 Jun 2012 10:38:25 -0700 (PDT) Received: from Joels-MacBook-Pro.local (204.sub-166-250-47.myvzw.com [166.250.47.204]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q5AHcMWF065377 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 10 Jun 2012 17:38:23 GMT (envelope-from joelja@bogus.com) Message-ID: <4FD4DB88.7090803@bogus.com> Date: Sun, 10 Jun 2012 10:38:16 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: IPv6 Ops WG , V6ops Chairs 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]); Sun, 10 Jun 2012 17:38:24 +0000 (UTC) Subject: [v6ops] Agenda Items for v6ops WG meetings vancouver. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Jun 2012 17:38:25 -0000 It's time to start considering what needs to be on the agenda for Vancouver. Recall that if you have a document to be published at or near the deadlines that we need to see uptake/interest/discussion on the list to take that discussion to the working-group meeting. Thanks Joel Jaeggli From lee@asgard.org Mon Jun 11 11:36: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 B60EA21F856D for ; Mon, 11 Jun 2012 11:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.957 X-Spam-Level: X-Spam-Status: No, score=0.957 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, 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 Wf0HZDvshx8E for ; Mon, 11 Jun 2012 11:36:38 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id DA0B121F856C for ; Mon, 11 Jun 2012 11:36:37 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q5BIaZvx000988 for ; Mon, 11 Jun 2012 14:36:36 -0400 Authentication-Results: cm-omr4 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.165] ([204.235.115.165:65260] helo=HDC00042402) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id F3/B5-30503-FAA36DF4; Mon, 11 Jun 2012 14:36:31 -0400 From: "Lee Howard" To: "'Victor Kuarsingh'" , "'IPv6 Operations'" Date: Mon, 11 Jun 2012 14:36:31 -0400 Message-ID: <000301cd4801$1f059880$5d10c980$@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1IAPwwo0J5FB5uS12XOZV+JSkuAQ== Content-Language: en-us Subject: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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, 11 Jun 2012 18:36:38 -0000 When discussed in Taipei, it seemed there was real interest in updating guidance for enterprise networks. From lack of list discussion, it now appears there's no interest in the WG. 1. Are people interested? 2. Should we let it die? 3. Should we pursue other avenues of publication? Lee > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Victor > Kuarsingh > Sent: Monday, March 26, 2012 7:42 AM > To: IPv6 Operations > Subject: Re: [v6ops] draft-chkpvc-enterprise-incremental-ipv6-00 > > IPv6 WG, > > I would like to kick off some comments on this draft for other group members to comment. > > I do think (Bias noted) that this material is useful for Enterprises who need to being and/or > move their IPv6 deployments. Many (of those I have worked with thus far) are bogged > down with personnel who are overwhelmed with what it may take to get IPv6 moving on > their networks. > > The draft breaks the challenge down by areas of focus (rolled into > "Phases") which can help put this large challenge into bite size chunks for them. The draft > also provides some valid contextual information around > IPv6 and highlights areas which should be looked at. > > Given the good momentum we now have in the operator space, it would be good to see this > move forward into the Enterprise space. I think such documents can help many of those still > waffling (too many to count) to start acting. > > Regards, > > Victor K > > > On 12-03-22 8:02 AM, "Tim Chown" wrote: > > >Hi, > > > >Due to a typo in the draft name, this draft didn't hit Fred's automated > >WG tools, so the authors would like to raise the draft on the list now > >with a view to securing a slot in Paris to discuss its value and content. > > > >In Taipei there was a comment in the WG session that there is no > >up-to-date v6ops guidance on enterprise networks, while other scenarios > >do have such texts. So at the mic I invited people to join an effort > >to put something together. There is a good breadth of experience > >across the people who stepped forward, and the result is available as > > > >http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.txt > > > >Does the WG think the subject matter of this draft is one we should > >pursue in the WG? If so, is the structure and content appropriate? We > >need some positive feedback and comments in order for Fred to schedule > >us time in Paris. > > > >We have had a couple of people contact us off-list offering to help > >develop the content. But we'd like some feedback from the WG before > >investing more time in doing so. The -00 text is somewhat "rough", but > >we feel it could be polished into something quite useful for the > >community. > > > >Tim > > > >_______________________________________________ > >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 internet-drafts@ietf.org Tue Jun 12 03:26: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 521CF21F8630; Tue, 12 Jun 2012 03:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp4tGGJG1F0U; Tue, 12 Jun 2012 03:26:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39BA21F8613; Tue, 12 Jun 2012 03:26:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120612102649.29664.78206.idtracker@ietfa.amsl.com> Date: Tue, 12 Jun 2012 03:26:49 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-icp-guidance-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, 12 Jun 2012 10:26:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Guidance for Internet Content and Application Servi= ce Providers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-v6ops-icp-guidance-01.txt Pages : 19 Date : 2012-06-12 Abstract: 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 hosting providers, or to any enterprise network preparing for IPv6 users. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-icp-guidance-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Tue Jun 12 07: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 2D2C021F865B; Tue, 12 Jun 2012 07:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.176 X-Spam-Level: X-Spam-Status: No, score=-102.176 tagged_above=-999 required=5 tests=[AWL=-0.177, 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 I1jX+jbmJSBN; Tue, 12 Jun 2012 07:37:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A104C21F8686; Tue, 12 Jun 2012 07:37:55 -0700 (PDT) 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.20 Message-ID: <20120612143755.20254.19733.idtracker@ietfa.amsl.com> Date: Tue, 12 Jun 2012 07:37:55 -0700 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'A Discard Prefix for IPv6' to Informational RFC (draft-ietf-v6ops-ipv6-discard-prefix-05.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, 12 Jun 2012 14:37:56 -0000 The IESG has approved the following document: - 'A Discard Prefix for IPv6' (draft-ietf-v6ops-ipv6-discard-prefix-05.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-discard-prefix/ Technical Summary: Remote triggered black hole filtering describes a method of militating against denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document explains why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. Working Group Summary The document has received extensive review both prior to and during WG LC. As the document allocates ipv6 address space for a special purpose application, review was sought and obtained from IANA during the process of WG last call. Document Quality Field reports from operators suggested multiple solutions for an appropriate address range were already in use at the time of the inception of this document. A defined prefix will facilitate proper designation of the address range and facilitate the creation of default filters. The request has been relatively simple and uncontroversial as a proposal, and therefore advancement of the document towards the publication has so far encountered few obstacles. Personnel Joel Jaeggli v6ops co-chair, is the document shepherd for draft-ietf-v6ops-ipv6-discard-prefix. From Fred.L.Templin@boeing.com Tue Jun 12 15:50: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 84B2421F86C9 for ; Tue, 12 Jun 2012 15:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5Gj4NtVkhuS for ; Tue, 12 Jun 2012 15:50:58 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id E554221F86BE for ; Tue, 12 Jun 2012 15:50:57 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5CMpF5R017311 for ; Tue, 12 Jun 2012 15:51:15 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5CMpEfS017305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jun 2012 15:51:15 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5CMot2b031425; Tue, 12 Jun 2012 15:50:55 -0700 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5CMotru031399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Jun 2012 15:50:55 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Tue, 12 Jun 2012 15:50:55 -0700 From: "Templin, Fred L" To: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Date: Tue, 12 Jun 2012 15:50:54 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac06HpqGDdQcCmriReGswY42wO8iFAAalwRgA5kBbjA= Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jun 2012 22:50:58 -0000 Hi, This document has now been updated to address issues raised on the list and to expand on the roles of inner fragmentation before encapsulation and outer fragmentation after encapsulation. The answer is that inner is needed in certain use cases, outer is needed in certain others and both are needed in still yet others. The latest draft is now available here: https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ Can we talk about this during the v6ops session at the Vancouver meeting? Thanks - Fred fred.l.templin@boeing.com From fgont@si6networks.com Wed Jun 13 07:00: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 7A12E21F85A5 for ; Wed, 13 Jun 2012 07:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54qT9ptonJTn for ; Wed, 13 Jun 2012 07:00:06 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id E010921F85A4 for ; Wed, 13 Jun 2012 07:00:05 -0700 (PDT) Received: from 61-128-17-190.fibertel.com.ar ([190.17.128.61] helo=[192.168.0.203]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Seo75-0008Ur-QM; Wed, 13 Jun 2012 16:00:00 +0200 Message-ID: <4FD898DA.3070505@si6networks.com> Date: Wed, 13 Jun 2012 10:42:50 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: IPv6 Operations X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] Heads up: 6man poll for adoption of RA-Guard/firewalling/monitoring-related I-Ds X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jun 2012 14:00:06 -0000 Folks, Just wanted to send a heads up regarding two 6man wg polls that have just been started for adoption of these documents: * draft-gont-6man-oversized-header-chain-02 (Security and Interoperability Implications of Oversized IPv6 Header Chains) * draft-gont-6man-nd-extension-headers-03 (Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery) draft-gont-6man-oversized-header-chain-02 requires that when packets are fragmented, the first fragment must contain the entire IPv6 header chain. This is important for a number of reasons: it allows for stateless filtering (both at firewalls and at RA-Guard-like devices), prevents stateless translators from breaking, etc. draft-gont-6man-nd-extension-headers-03 forbids the use of fragmentation with Neighbor Discovery. This essentially enables Neighbor Discovery monitoring in IPv6, thus providing feature parity with IPv4 (think about arpwatch and the like) -- not to mention that it obviously mitigates fragmentation-based attacks against Neighbor Discovery and SEND. IMO, these two I-Ds propose small spec updates which could result in concrete operational and security benefits. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From v6ops@globis.net Wed Jun 13 08:28: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 EF0A321F853E for ; Wed, 13 Jun 2012 08:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 aR5zu-zZSAag for ; Wed, 13 Jun 2012 08:28:20 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 123F321F84A7 for ; Wed, 13 Jun 2012 08:28:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 784F187005E; Wed, 13 Jun 2012 17:28:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PQir6rpFeLc; Wed, 13 Jun 2012 17:28:09 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 35ECA870044; Wed, 13 Jun 2012 17:28:09 +0200 (CEST) Message-ID: <4FD8B188.1000403@globis.net> Date: Wed, 13 Jun 2012 17:28:08 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: Lee Howard References: <000301cd4801$1f059880$5d10c980$@asgard.org> In-Reply-To: <000301cd4801$1f059880$5d10c980$@asgard.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'IPv6 Operations' Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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: Wed, 13 Jun 2012 15:28:21 -0000 Regardless of whether this draft is the vehicle or not, one thing that I think is missing is that large enterprises currently almost universally use some sort of centralized gateway or proxy to access the Internet, coupled with "split DNS" (whether the IETF likes that or not). Many enterprises have expressed a desire to become "Internet Centric" whatever that is. They're also moving very rapidly to cloud services for generic applications. However, they'll still need private enterprise networks with SLAs for many other business critical services ad interim, at least until the generic Internet supports an equivalent of Diffserv. Multiple IPv6 addresses per node, with a combination of PI space for the enterprise network and PA space fromlocal providers, is making direct proxy-free nat-free local Internet breakout potentially possible (together with MIF and appropriate address selection). DNSSEC is also potentially attractive to facilitate/ restore a basic end to end trust model. So I think we know where we're starting, and I think we know where we end up, but is there any operational advice available on the steps that would be required to e.g. "unsplit DNS" (and remove proxies) when introducing IPv6? In other words, how do we restore the end to end model without breaking stuff on the way? regards, RayH Lee Howard wrote: > When discussed in Taipei, it seemed there was real interest in updating > guidance for > enterprise networks. From lack of list discussion, it now appears there's > no interest in > the WG. > > 1. Are people interested? > 2. Should we let it die? > 3. Should we pursue other avenues of publication? > > Lee > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Victor >> Kuarsingh >> Sent: Monday, March 26, 2012 7:42 AM >> To: IPv6 Operations >> Subject: Re: [v6ops] draft-chkpvc-enterprise-incremental-ipv6-00 >> >> IPv6 WG, >> >> I would like to kick off some comments on this draft for other group > members to comment. >> I do think (Bias noted) that this material is useful for Enterprises who > need to being and/or >> move their IPv6 deployments. Many (of those I have worked with thus far) > are bogged >> down with personnel who are overwhelmed with what it may take to get IPv6 > moving on >> their networks. >> >> The draft breaks the challenge down by areas of focus (rolled into >> "Phases") which can help put this large challenge into bite size chunks > for them. The draft >> also provides some valid contextual information around >> IPv6 and highlights areas which should be looked at. >> >> Given the good momentum we now have in the operator space, it would be > good to see this >> move forward into the Enterprise space. I think such documents can help > many of those still >> waffling (too many to count) to start acting. >> >> Regards, >> >> Victor K >> >> >> On 12-03-22 8:02 AM, "Tim Chown" wrote: >> >>> Hi, >>> >>> Due to a typo in the draft name, this draft didn't hit Fred's automated >>> WG tools, so the authors would like to raise the draft on the list now >>> with a view to securing a slot in Paris to discuss its value and content. >>> >>> In Taipei there was a comment in the WG session that there is no >>> up-to-date v6ops guidance on enterprise networks, while other scenarios >>> do have such texts. So at the mic I invited people to join an effort >>> to put something together. There is a good breadth of experience >>> across the people who stepped forward, and the result is available as >>> >>> http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.txt >>> >>> Does the WG think the subject matter of this draft is one we should >>> pursue in the WG? If so, is the structure and content appropriate? We >>> need some positive feedback and comments in order for Fred to schedule >>> us time in Paris. >>> >>> We have had a couple of people contact us off-list offering to help >>> develop the content. But we'd like some feedback from the WG before >>> investing more time in doing so. The -00 text is somewhat "rough", but >>> we feel it could be polished into something quite useful for the >>> community. >>> >>> Tim >>> >>> _______________________________________________ >>> 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 Fred.L.Templin@boeing.com Wed Jun 13 09:20: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 D03AB21F8541 for ; Wed, 13 Jun 2012 09:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 CTMA85PbNstv for ; Wed, 13 Jun 2012 09:20:31 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2D31B21F852C for ; Wed, 13 Jun 2012 09:20:31 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5DGKHSs017151 for ; Wed, 13 Jun 2012 11:20:18 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5DGKH5c017144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2012 11:20:17 -0500 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5DGKTvM017102; Wed, 13 Jun 2012 11:20:29 -0500 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5DGKSXZ017062 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 13 Jun 2012 11:20:29 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Wed, 13 Jun 2012 09:20:28 -0700 From: "Templin, Fred L" To: Lee Howard , "'Victor Kuarsingh'" , "'IPv6 Operations'" Date: Wed, 13 Jun 2012 09:20:27 -0700 Thread-Topic: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-00) Thread-Index: Ac1IAPwwo0J5FB5uS12XOZV+JSkuAQBfxtzw Message-ID: References: <000301cd4801$1f059880$5d10c980$@asgard.org> In-Reply-To: <000301cd4801$1f059880$5d10c980$@asgard.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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: Wed, 13 Jun 2012 16:20:32 -0000 Hi Lee, If you do decide to pursue this further, here are two documents that fit this space: https://datatracker.ietf.org/doc/draft-templin-v6ops-isops/ https://datatracker.ietf.org/doc/rfc5214/ Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Lee Howard > Sent: Monday, June 11, 2012 11:37 AM > To: 'Victor Kuarsingh'; 'IPv6 Operations' > Subject: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise- > incremental-ipv6-00) >=20 > When discussed in Taipei, it seemed there was real interest in updating > guidance for > enterprise networks. From lack of list discussion, it now appears there'= s > no interest in > the WG. >=20 > 1. Are people interested? > 2. Should we let it die? > 3. Should we pursue other avenues of publication? >=20 > Lee >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > Victor > > Kuarsingh > > Sent: Monday, March 26, 2012 7:42 AM > > To: IPv6 Operations > > Subject: Re: [v6ops] draft-chkpvc-enterprise-incremental-ipv6-00 > > > > IPv6 WG, > > > > I would like to kick off some comments on this draft for other group > members to comment. > > > > I do think (Bias noted) that this material is useful for Enterprises wh= o > need to being and/or > > move their IPv6 deployments. Many (of those I have worked with thus > far) > are bogged > > down with personnel who are overwhelmed with what it may take to get > IPv6 > moving on > > their networks. > > > > The draft breaks the challenge down by areas of focus (rolled into > > "Phases") which can help put this large challenge into bite size chunks > for them. The draft > > also provides some valid contextual information around > > IPv6 and highlights areas which should be looked at. > > > > Given the good momentum we now have in the operator space, it would be > good to see this > > move forward into the Enterprise space. I think such documents can hel= p > many of those still > > waffling (too many to count) to start acting. > > > > Regards, > > > > Victor K > > > > > > On 12-03-22 8:02 AM, "Tim Chown" wrote: > > > > >Hi, > > > > > >Due to a typo in the draft name, this draft didn't hit Fred's automate= d > > >WG tools, so the authors would like to raise the draft on the list now > > >with a view to securing a slot in Paris to discuss its value and > content. > > > > > >In Taipei there was a comment in the WG session that there is no > > >up-to-date v6ops guidance on enterprise networks, while other scenario= s > > >do have such texts. So at the mic I invited people to join an effort > > >to put something together. There is a good breadth of experience > > >across the people who stepped forward, and the result is available as > > > > > >http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.txt > > > > > >Does the WG think the subject matter of this draft is one we should > > >pursue in the WG? If so, is the structure and content appropriate? W= e > > >need some positive feedback and comments in order for Fred to schedule > > >us time in Paris. > > > > > >We have had a couple of people contact us off-list offering to help > > >develop the content. But we'd like some feedback from the WG before > > >investing more time in doing so. The -00 text is somewhat "rough", bu= t > > >we feel it could be polished into something quite useful for the > > >community. > > > > > >Tim > > > > > >_______________________________________________ > > >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 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From victor.kuarsingh@gmail.com Wed Jun 13 11: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 DC3C711E8089 for ; Wed, 13 Jun 2012 11:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 9h7omYq4xNiu for ; Wed, 13 Jun 2012 11:32:09 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6B5811E807F for ; Wed, 13 Jun 2012 11:32:08 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so671467vbb.31 for ; Wed, 13 Jun 2012 11:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=jdl4IvydH0c+/fozfcWaj2Gf7wnUH2fTLcoFru9bQAo=; b=0nJN63kuVw5rDI4ygxsOHe1HBVFIvRuqEPlr3ncd2u1YfBR52eZ15u3GBUydElLLZZ GAdGVxwlb6liMHGlflECp4MkN5xWD4JJ6p1401QBHmt2eC8KlO0sO0t0AGGY+OXsTgbO o17BcRFOOh2rA52xx0LPqDfAVuOorEUhdaCKtel2BHNl/O1fjlfAiedRO8JURFQs8Oh1 LEGeCZKYVKV42BG685WjklES41HKDfeY7AtIHzbwPw1hjoFbHbY9Tlt9ju30P78nXeJh BAhwJewdFVSG0QLcH202OJuB/lk69PbEzwbr3OBUUfzwN9WdyFi3jufsP4L1effh2FeC DuTA== Received: by 10.220.150.134 with SMTP id y6mr17572662vcv.43.1339612328226; Wed, 13 Jun 2012 11:32:08 -0700 (PDT) Received: from [192.168.1.123] (CPEc0c1c0d0a27e-CM001bd7a9dea0.cpe.net.cable.rogers.com. [173.34.66.20]) by mx.google.com with ESMTPS id c17sm2777747vdj.11.2012.06.13.11.32.04 (version=SSLv3 cipher=OTHER); Wed, 13 Jun 2012 11:32:07 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 13 Jun 2012 14:32:03 -0400 From: Victor Kuarsingh To: Ray Hunter , Lee Howard Message-ID: Thread-Topic: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-00) In-Reply-To: <4FD8B188.1000403@globis.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'IPv6 Operations' Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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: Wed, 13 Jun 2012 18:32:10 -0000 Ray, How would you propose we work this concept in? These are good points overall, but would we expect a document focused IPv6 in the enterprise to also tackle fallout of architectural enhancements possible with IPv6? I would think that such a document/concept would be best managed in a separate document which was focused on that subject. I may have missed your point, but these are my initial thoughts. Regards, Victor K On 12-06-13 11:28 AM, "Ray Hunter" wrote: >Regardless of whether this draft is the vehicle or not, one thing that I >think is missing is that large enterprises currently almost universally >use some sort of centralized gateway or proxy to access the Internet, >coupled with "split DNS" (whether the IETF likes that or not). > >Many enterprises have expressed a desire to become "Internet Centric" >whatever that is. They're also moving very rapidly to cloud services for >generic applications. However, they'll still need private enterprise >networks with SLAs for many other business critical services ad interim, >at least until the generic Internet supports an equivalent of Diffserv. >Multiple IPv6 addresses per node, with a combination of PI space for the >enterprise network and PA space fromlocal providers, is making direct >proxy-free nat-free local Internet breakout potentially possible >(together with MIF and appropriate address selection). DNSSEC is also >potentially attractive to facilitate/ restore a basic end to end trust >model. > >So I think we know where we're starting, and I think we know where we >end up, but is there any operational advice available on the steps that >would be required to e.g. "unsplit DNS" (and remove proxies) when >introducing IPv6? > >In other words, how do we restore the end to end model without breaking >stuff on the way? > >regards, >RayH > >Lee Howard wrote: >> When discussed in Taipei, it seemed there was real interest in updating >> guidance for >> enterprise networks. From lack of list discussion, it now appears >>there's >> no interest in >> the WG. >> >> 1. Are people interested? >> 2. Should we let it die? >> 3. Should we pursue other avenues of publication? >> >> Lee >> >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >>>Of >> Victor >>> Kuarsingh >>> Sent: Monday, March 26, 2012 7:42 AM >>> To: IPv6 Operations >>> Subject: Re: [v6ops] draft-chkpvc-enterprise-incremental-ipv6-00 >>> >>> IPv6 WG, >>> >>> I would like to kick off some comments on this draft for other group >> members to comment. >>> I do think (Bias noted) that this material is useful for Enterprises >>>who >> need to being and/or >>> move their IPv6 deployments. Many (of those I have worked with thus >>>far) >> are bogged >>> down with personnel who are overwhelmed with what it may take to get >>>IPv6 >> moving on >>> their networks. >>> >>> The draft breaks the challenge down by areas of focus (rolled into >>> "Phases") which can help put this large challenge into bite size chunks >> for them. The draft >>> also provides some valid contextual information around >>> IPv6 and highlights areas which should be looked at. >>> >>> Given the good momentum we now have in the operator space, it would be >> good to see this >>> move forward into the Enterprise space. I think such documents can >>>help >> many of those still >>> waffling (too many to count) to start acting. >>> >>> Regards, >>> >>> Victor K >>> >>> >>> On 12-03-22 8:02 AM, "Tim Chown" wrote: >>> >>>> Hi, >>>> >>>> Due to a typo in the draft name, this draft didn't hit Fred's >>>>automated >>>> WG tools, so the authors would like to raise the draft on the list now >>>> with a view to securing a slot in Paris to discuss its value and >>>>content. >>>> >>>> In Taipei there was a comment in the WG session that there is no >>>> up-to-date v6ops guidance on enterprise networks, while other >>>>scenarios >>>> do have such texts. So at the mic I invited people to join an effort >>>> to put something together. There is a good breadth of experience >>>> across the people who stepped forward, and the result is available as >>>> >>>> http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.txt >>>> >>>> Does the WG think the subject matter of this draft is one we should >>>> pursue in the WG? If so, is the structure and content appropriate? >>>>We >>>> need some positive feedback and comments in order for Fred to schedule >>>> us time in Paris. >>>> >>>> We have had a couple of people contact us off-list offering to help >>>> develop the content. But we'd like some feedback from the WG before >>>> investing more time in doing so. The -00 text is somewhat "rough", >>>>but >>>> we feel it could be polished into something quite useful for the >>>> community. >>>> >>>> Tim >>>> >>>> _______________________________________________ >>>> 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 victor.kuarsingh@gmail.com Wed Jun 13 11:44: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 55D8C11E8079 for ; Wed, 13 Jun 2012 11:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 BieP4DOHk6ju for ; Wed, 13 Jun 2012 11:44:02 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7500511E8072 for ; Wed, 13 Jun 2012 11:44:01 -0700 (PDT) Received: by vcqp1 with SMTP id p1so596506vcq.31 for ; Wed, 13 Jun 2012 11:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=Qo4hF3Ng9weE5XshVxC9ojaYCQSMNZu2BaO7EC8Xzu8=; b=fnRRSzLEoltOVN7CC3a5ieTpAGzgnPCirBdIHdNijykMd2TdO4RKYPDcXrj81Tsw6j 6rVFmMvYu9lXb7CIBu+xnLW3kw4HmzicNZclQr2fjhl6uxvICb9JK/KG2DOlbhavGZFO eJwIenpNgj9u5XvFhC2VMDOxcQQN09cAOznSzqeTUn0SfIMVe7WZoAVvLUUnrWK+Ddmk xwNvRDBEkc9+lcwT6J82izey1L43TuowiNXSOxzuHFdtXrWr8TqCNgz2corYkeCFB4iw sM/AxKxmgCpZ2g8Zhb0hjFz0Zw+28GZHQdnP0gWK3KNeZnm4D20rJbpOYzeLNjyVVL55 AV+w== Received: by 10.220.215.136 with SMTP id he8mr17758916vcb.13.1339613040945; Wed, 13 Jun 2012 11:44:00 -0700 (PDT) Received: from [192.168.1.123] (CPEc0c1c0d0a27e-CM001bd7a9dea0.cpe.net.cable.rogers.com. [173.34.66.20]) by mx.google.com with ESMTPS id l4sm2832894vdh.1.2012.06.13.11.43.54 (version=SSLv3 cipher=OTHER); Wed, 13 Jun 2012 11:43:59 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 13 Jun 2012 14:43:47 -0400 From: Victor Kuarsingh To: "Templin, Fred L" , Lee Howard , 'IPv6 Operations' Message-ID: Thread-Topic: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-00) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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: Wed, 13 Jun 2012 18:44:03 -0000 Fred, I would (personally) tend to agree. Given the details from "draft-templin-v6ops-ispos", would a reference to that document fit the bill? Regards, Victor K On 12-06-13 12:20 PM, "Templin, Fred L" wrote: >Hi Lee, > >If you do decide to pursue this further, here are two >documents that fit this space: > >https://datatracker.ietf.org/doc/draft-templin-v6ops-isops/ >https://datatracker.ietf.org/doc/rfc5214/ > >Fred >fred.l.templin@boeing.com > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >>Of >> Lee Howard >> Sent: Monday, June 11, 2012 11:37 AM >> To: 'Victor Kuarsingh'; 'IPv6 Operations' >> Subject: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise- >> incremental-ipv6-00) >> >> When discussed in Taipei, it seemed there was real interest in updating >> guidance for >> enterprise networks. From lack of list discussion, it now appears >>there's >> no interest in >> the WG. >> >> 1. Are people interested? >> 2. Should we let it die? >> 3. Should we pursue other avenues of publication? >> >> Lee >> >> > -----Original Message----- >> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of >> Victor >> > Kuarsingh >> > Sent: Monday, March 26, 2012 7:42 AM >> > To: IPv6 Operations >> > Subject: Re: [v6ops] draft-chkpvc-enterprise-incremental-ipv6-00 >> > >> > IPv6 WG, >> > >> > I would like to kick off some comments on this draft for other group >> members to comment. >> > >> > I do think (Bias noted) that this material is useful for Enterprises >>who >> need to being and/or >> > move their IPv6 deployments. Many (of those I have worked with thus >> far) >> are bogged >> > down with personnel who are overwhelmed with what it may take to get >> IPv6 >> moving on >> > their networks. >> > >> > The draft breaks the challenge down by areas of focus (rolled into >> > "Phases") which can help put this large challenge into bite size >>chunks >> for them. The draft >> > also provides some valid contextual information around >> > IPv6 and highlights areas which should be looked at. >> > >> > Given the good momentum we now have in the operator space, it would be >> good to see this >> > move forward into the Enterprise space. I think such documents can >>help >> many of those still >> > waffling (too many to count) to start acting. >> > >> > Regards, >> > >> > Victor K >> > >> > >> > On 12-03-22 8:02 AM, "Tim Chown" wrote: >> > >> > >Hi, >> > > >> > >Due to a typo in the draft name, this draft didn't hit Fred's >>automated >> > >WG tools, so the authors would like to raise the draft on the list >>now >> > >with a view to securing a slot in Paris to discuss its value and >> content. >> > > >> > >In Taipei there was a comment in the WG session that there is no >> > >up-to-date v6ops guidance on enterprise networks, while other >>scenarios >> > >do have such texts. So at the mic I invited people to join an effort >> > >to put something together. There is a good breadth of experience >> > >across the people who stepped forward, and the result is available as >> > > >> > >>>http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.txt >> > > >> > >Does the WG think the subject matter of this draft is one we should >> > >pursue in the WG? If so, is the structure and content appropriate? >>We >> > >need some positive feedback and comments in order for Fred to >>schedule >> > >us time in Paris. >> > > >> > >We have had a couple of people contact us off-list offering to help >> > >develop the content. But we'd like some feedback from the WG before >> > >investing more time in doing so. The -00 text is somewhat "rough", >>but >> > >we feel it could be polished into something quite useful for the >> > >community. >> > > >> > >Tim >> > > >> > >_______________________________________________ >> > >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 Fred.L.Templin@boeing.com Wed Jun 13 11:46: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 4C9A011E8096 for ; Wed, 13 Jun 2012 11:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 vrkWjA1ZSqWx for ; Wed, 13 Jun 2012 11:46:40 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 92D6911E809F for ; Wed, 13 Jun 2012 11:46:40 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5DIkaB4028154 for ; Wed, 13 Jun 2012 11:46:37 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5DIkZoM028137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2012 11:46:36 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5DIkcXa013188; Wed, 13 Jun 2012 13:46:38 -0500 Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5DIkb8i013162 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 13 Jun 2012 13:46:38 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Wed, 13 Jun 2012 11:46:37 -0700 From: "Templin, Fred L" To: Victor Kuarsingh , Lee Howard , "'IPv6 Operations'" Date: Wed, 13 Jun 2012 11:46:36 -0700 Thread-Topic: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-00) Thread-Index: Ac1JlIV7xKPWBw6lR6iqb8BN2ADWUQAABFUg Message-ID: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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: Wed, 13 Jun 2012 18:46:41 -0000 Hi Victor, > -----Original Message----- > From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com] > Sent: Wednesday, June 13, 2012 11:44 AM > To: Templin, Fred L; Lee Howard; 'IPv6 Operations' > Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise= - > incremental-ipv6-00) >=20 > Fred, >=20 > I would (personally) tend to agree. Given the details from > "draft-templin-v6ops-ispos", would a reference to that document fit the > bill? Assuming the authors decide to pursue this work further, then a reference to "draft-templin-v6ops-isops" would be fine. Thanks - Fred fred.l.templin@boeing.com =20 > Regards, >=20 > Victor K >=20 >=20 >=20 > On 12-06-13 12:20 PM, "Templin, Fred L" wrote= : >=20 > >Hi Lee, > > > >If you do decide to pursue this further, here are two > >documents that fit this space: > > > >https://datatracker.ietf.org/doc/draft-templin-v6ops-isops/ > >https://datatracker.ietf.org/doc/rfc5214/ > > > >Fred > >fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > >>Of > >> Lee Howard > >> Sent: Monday, June 11, 2012 11:37 AM > >> To: 'Victor Kuarsingh'; 'IPv6 Operations' > >> Subject: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise- > >> incremental-ipv6-00) > >> > >> When discussed in Taipei, it seemed there was real interest in updatin= g > >> guidance for > >> enterprise networks. From lack of list discussion, it now appears > >>there's > >> no interest in > >> the WG. > >> > >> 1. Are people interested? > >> 2. Should we let it die? > >> 3. Should we pursue other avenues of publication? > >> > >> Lee > >> > >> > -----Original Message----- > >> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf > >> Of > >> Victor > >> > Kuarsingh > >> > Sent: Monday, March 26, 2012 7:42 AM > >> > To: IPv6 Operations > >> > Subject: Re: [v6ops] draft-chkpvc-enterprise-incremental-ipv6-00 > >> > > >> > IPv6 WG, > >> > > >> > I would like to kick off some comments on this draft for other group > >> members to comment. > >> > > >> > I do think (Bias noted) that this material is useful for Enterprises > >>who > >> need to being and/or > >> > move their IPv6 deployments. Many (of those I have worked with thus > >> far) > >> are bogged > >> > down with personnel who are overwhelmed with what it may take to get > >> IPv6 > >> moving on > >> > their networks. > >> > > >> > The draft breaks the challenge down by areas of focus (rolled into > >> > "Phases") which can help put this large challenge into bite size > >>chunks > >> for them. The draft > >> > also provides some valid contextual information around > >> > IPv6 and highlights areas which should be looked at. > >> > > >> > Given the good momentum we now have in the operator space, it would > be > >> good to see this > >> > move forward into the Enterprise space. I think such documents can > >>help > >> many of those still > >> > waffling (too many to count) to start acting. > >> > > >> > Regards, > >> > > >> > Victor K > >> > > >> > > >> > On 12-03-22 8:02 AM, "Tim Chown" wrote: > >> > > >> > >Hi, > >> > > > >> > >Due to a typo in the draft name, this draft didn't hit Fred's > >>automated > >> > >WG tools, so the authors would like to raise the draft on the list > >>now > >> > >with a view to securing a slot in Paris to discuss its value and > >> content. > >> > > > >> > >In Taipei there was a comment in the WG session that there is no > >> > >up-to-date v6ops guidance on enterprise networks, while other > >>scenarios > >> > >do have such texts. So at the mic I invited people to join an > effort > >> > >to put something together. There is a good breadth of experience > >> > >across the people who stepped forward, and the result is available > as > >> > > > >> > > >>>http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.txt > >> > > > >> > >Does the WG think the subject matter of this draft is one we should > >> > >pursue in the WG? If so, is the structure and content appropriate? > >>We > >> > >need some positive feedback and comments in order for Fred to > >>schedule > >> > >us time in Paris. > >> > > > >> > >We have had a couple of people contact us off-list offering to help > >> > >develop the content. But we'd like some feedback from the WG befor= e > >> > >investing more time in doing so. The -00 text is somewhat "rough", > >>but > >> > >we feel it could be polished into something quite useful for the > >> > >community. > >> > > > >> > >Tim > >> > > > >> > >_______________________________________________ > >> > >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 >=20 From lee@asgard.org Thu Jun 14 08:01: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 0455221F85DB for ; Thu, 14 Jun 2012 08:01:42 -0700 (PDT) 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=1.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 p3Rlge+6Brvd for ; Thu, 14 Jun 2012 08:01:41 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 17D7C21F8575 for ; Thu, 14 Jun 2012 08:01:41 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q5EF1d1q005689 for ; Thu, 14 Jun 2012 11:01:39 -0400 Authentication-Results: cm-omr9 smtp.user=lee@asgard.org; auth=pass (LOGIN) X-Authenticated-UID: lee@asgard.org Received: from [204.235.115.165] ([204.235.115.165:45675] helo=HDC00042402) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id BB/80-05613-3DCF9DF4; Thu, 14 Jun 2012 11:01:39 -0400 From: "Lee Howard" To: "'Ray Hunter'" References: <000301cd4801$1f059880$5d10c980$@asgard.org> <4FD8B188.1000403@globis.net> In-Reply-To: <4FD8B188.1000403@globis.net> Date: Thu, 14 Jun 2012 11:01:38 -0400 Message-ID: <002701cd4a3e$99e19ce0$cda4d6a0$@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHyxyM+GjWm1durjzyQdvxrLipY3QKtCX0xlpmEaVA= Content-Language: en-us Cc: 'IPv6 Operations' Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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: Thu, 14 Jun 2012 15:01:42 -0000 > -----Original Message----- > From: Ray Hunter [mailto:v6ops@globis.net] > Sent: Wednesday, June 13, 2012 11:28 AM > To: Lee Howard > Cc: 'Victor Kuarsingh'; 'IPv6 Operations' > Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental- > ipv6-00) > > Regardless of whether this draft is the vehicle or not, one thing that I think is missing is that > large enterprises currently almost universally use some sort of centralized gateway or proxy > to access the Internet, coupled with "split DNS" (whether the IETF likes that or not). "Split DNS" meaning that different responses are returned depending on whether the query comes from within the enterprise or from outside? For instance, an employee can reach ACCOUNTING.EXAMPLE.COM internally, because the name server returns a net 10 address, but a query from outside receives NXDOMAIN? > Many enterprises have expressed a desire to become "Internet Centric" > whatever that is. They're also moving very rapidly to cloud services for generic applications. > However, they'll still need private enterprise networks with SLAs for many other business > critical services ad interim, at least until the generic Internet supports an equivalent of > Diffserv. > Multiple IPv6 addresses per node, with a combination of PI space for the enterprise network > and PA space fromlocal providers, is making direct proxy-free nat-free local Internet > breakout potentially possible (together with MIF and appropriate address selection). > DNSSEC is also potentially attractive to facilitate/ restore a basic end to end trust model. > > So I think we know where we're starting, and I think we know where we end up, but is there > any operational advice available on the steps that would be required to e.g. "unsplit DNS" > (and remove proxies) when introducing IPv6? What changes? You can still return NXDOMAIN if you don't like the querier. Or you can respond with a AAAA and rely on your security to protect your accounting system. > In other words, how do we restore the end to end model without breaking stuff on the way? I may be misunderstanding you, though, since I'm not sure how the end-to-end principle applies to this DNS setup. Yes, GUA addressing makes it possible to eliminate NAT, but whether enterprises eliminate proxies depends on their policy reasons for implementing them in the first place. What should we say about all this? Lee > > regards, > RayH > > Lee Howard wrote: > > When discussed in Taipei, it seemed there was real interest in > > updating guidance for enterprise networks. From lack of list > > discussion, it now appears there's no interest in the WG. > > > > 1. Are people interested? > > 2. Should we let it die? > > 3. Should we pursue other avenues of publication? > > > > Lee > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > >> Behalf Of > > Victor > >> Kuarsingh > >> Sent: Monday, March 26, 2012 7:42 AM > >> To: IPv6 Operations > >> Subject: Re: [v6ops] draft-chkpvc-enterprise-incremental-ipv6-00 > >> > >> IPv6 WG, > >> > >> I would like to kick off some comments on this draft for other group > > members to comment. > >> I do think (Bias noted) that this material is useful for Enterprises > >> who > > need to being and/or > >> move their IPv6 deployments. Many (of those I have worked with thus > >> far) > > are bogged > >> down with personnel who are overwhelmed with what it may take to get > >> IPv6 > > moving on > >> their networks. > >> > >> The draft breaks the challenge down by areas of focus (rolled into > >> "Phases") which can help put this large challenge into bite size > >> chunks > > for them. The draft > >> also provides some valid contextual information around > >> IPv6 and highlights areas which should be looked at. > >> > >> Given the good momentum we now have in the operator space, it would > >> be > > good to see this > >> move forward into the Enterprise space. I think such documents can > >> help > > many of those still > >> waffling (too many to count) to start acting. > >> > >> Regards, > >> > >> Victor K > >> > >> > >> On 12-03-22 8:02 AM, "Tim Chown" wrote: > >> > >>> Hi, > >>> > >>> Due to a typo in the draft name, this draft didn't hit Fred's > >>> automated WG tools, so the authors would like to raise the draft on > >>> the list now with a view to securing a slot in Paris to discuss its value and content. > >>> > >>> In Taipei there was a comment in the WG session that there is no > >>> up-to-date v6ops guidance on enterprise networks, while other > >>> scenarios do have such texts. So at the mic I invited people to > >>> join an effort to put something together. There is a good breadth > >>> of experience across the people who stepped forward, and the result > >>> is available as > >>> > >>> http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.t > >>> xt > >>> > >>> Does the WG think the subject matter of this draft is one we should > >>> pursue in the WG? If so, is the structure and content appropriate? > >>> We need some positive feedback and comments in order for Fred to > >>> schedule us time in Paris. > >>> > >>> We have had a couple of people contact us off-list offering to help > >>> develop the content. But we'd like some feedback from the WG before > >>> investing more time in doing so. The -00 text is somewhat "rough", > >>> but we feel it could be polished into something quite useful for the > >>> community. > >>> > >>> Tim > >>> > >>> _______________________________________________ > >>> 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 v6ops@globis.net Thu Jun 14 10:06: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 802AF21F871A for ; Thu, 14 Jun 2012 10:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.300, 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 fcFfUVov0-Mb for ; Thu, 14 Jun 2012 10:06:23 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A03621F8717 for ; Thu, 14 Jun 2012 10:06:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id DF97E8700E6; Thu, 14 Jun 2012 19:06:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSqVndEFjF0q; Thu, 14 Jun 2012 19:06:06 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id DCF6D870089; Thu, 14 Jun 2012 19:06:05 +0200 (CEST) Message-ID: <4FDA19FC.1010606@globis.net> Date: Thu, 14 Jun 2012 19:06:04 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: Lee Howard References: <000301cd4801$1f059880$5d10c980$@asgard.org> <4FD8B188.1000403@globis.net> <002701cd4a3e$99e19ce0$cda4d6a0$@asgard.org> In-Reply-To: <002701cd4a3e$99e19ce0$cda4d6a0$@asgard.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'IPv6 Operations' Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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: Thu, 14 Jun 2012 17:06:26 -0000 inline > Lee Howard > 14 June 2012 17:01 >> -----Original Message----- >> From: Ray Hunter [mailto:v6ops@globis.net] >> Sent: Wednesday, June 13, 2012 11:28 AM >> To: Lee Howard >> Cc: 'Victor Kuarsingh'; 'IPv6 Operations' >> Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental- >> ipv6-00) >> >> Regardless of whether this draft is the vehicle or not, one thing that I think is missing is that >> large enterprises currently almost universally use some sort of centralized gateway or proxy >> to access the Internet, coupled with "split DNS" (whether the IETF likes that or not > > "Split DNS" meaning that different responses are returned depending on > whether the query > comes from within the enterprise or from outside? > For instance, an employee can reach ACCOUNTING.EXAMPLE.COM internally, > because the > name server returns a net 10 address, but a query from outside receives > NXDOMAIN? I believe "Split DNS" can mean several things, which is why I placed it in quotes. I don't think Split DNS was ever acknowledged as a standard. But it is widely deployed in enterprises AFAIK. One reason was to mitigate against cache poisoning. Another was to be able to use DNS with RFC1918 addresses before this was supported on common implementations. Another was just so that internal name and address space was completely private in manufacturing environments. Another was for test & development environments. Another was so that dynamically updated names in AD could remain relatively secure from external interference. So the namespace can be split, or the transport, or both. I believe I've seen: 1) internal hidden servers that serve different zones internally as the external servers. These internal hidden masters may be used to source zone transfers to sacrificial external slave servers that serve a subset of the namespace. So ext.example.com may be served externally, but int.example.com may be restricted to the internal servers (simply by not having the secondary zone configured on the external server). The internal servers may or may not be able to resolve Internet names (sometimes via a proxy DNS setup) Here we have a split namespace, and potentially a split transport (depending on how internal hosts resolve external addresses) 2) A single set of DNS servers that serve different answers based on some parameter from the query e.g. a single DNS server using BIND "views" to provide an answer for accounting.example.com based on the source address of the query matching an on-enterprise-net pattern, that is not resolvable for off-enterprise-net addresses. Here we're clearly talking about split namespace, but contiguous transport. 3) Completely separate internal and external servers serving the same logical zone but with different content and sometimes managed completely separately e.g. www.example.com hosted externally at a hosting provider for a corporate website for public consumption, and a separate employee's version of the same website iww.example.com hosted internally by the IT department. The external DNS servers may have an Internet hints file and a be managed by the hosting provider. The internal DNS servers may have a (fake) master root zone and be managed by the IT department. Internal hosts normally will not be able to resolve www.external.com or www.example.com and are pointed to an appropriate web proxy via a proxy pac file. Here we're talking about split namespace and split transport. Sometimes there may even be conflicting or overlapping namespace. 4) Completely fictitious internal A record entries for trusted 3rd party companies where there is a private link between the two companies together with a contractual agreement defining responsibilities e.g. for B2B transactions or for managing outsourced systems, or providing outsourced services to example.com. This is just a horrible kludge. 5) Equivalent of a .local namespace for dev, test & production. So there'd be overlapping address space for hostname-x.dev.company.com hostname-x.test.company.com hostname-x.production.company.com. As software moved from one environment to the next, all that was changed was the DNS default search domain (no machine renumbering needed in order to avoid problems with high availability scripts having to be edited). Some people even used identical setups for all 3 environments (identical names, addresses & domains) to avoid changing anything as solutions were transported between environments (via hard media). 6) Manufacturing environments that were meant to be completely isolated (yes I know) that use private RFC1918 IP space. Don't shoot the messenger. >> Many enterprises have expressed a desire to become "Internet Centric" >> whatever that is. They're also moving very rapidly to cloud services for > generic applications. >> However, they'll still need private enterprise networks with SLAs for many > other business >> critical services ad interim, at least until the generic Internet supports > an equivalent of >> Diffserv. >> Multiple IPv6 addresses per node, with a combination of PI space for the > enterprise network >> and PA space fromlocal providers, is making direct proxy-free nat-free > local Internet >> breakout potentially possible (together with MIF and appropriate address > selection). >> DNSSEC is also potentially attractive to facilitate/ restore a basic end > to end trust model. >> So I think we know where we're starting, and I think we know where we end > up, but is there >> any operational advice available on the steps that would be required to > e.g. "unsplit DNS" >> (and remove proxies) when introducing IPv6? > > What changes? You can still return NXDOMAIN if you don't like the querier. > Or you can > respond with a AAAA and rely on your security to protect your accounting > system. You're assuming that the transport has always been contiguous between internal and external hosts and DNS servers, and that there is a single consistent set of authoritative name servers for a common Worldwide namespace. That is rarely the case AFAIK. >> In other words, how do we restore the end to end model without breaking > stuff on the way? > > I may be misunderstanding you, though, since I'm not sure how the end-to-end > principle > applies to this DNS setup. > Yes, GUA addressing makes it possible to eliminate NAT, but whether > enterprises eliminate > proxies depends on their policy reasons for implementing them in the first > place. > > What should we say about all this? It's relatively easily to define a flexible PI based IPv6 addressing plan so that return routes can be de-aggregated as necessary (based on Internet latency) as the number of direct Internet gateways grows. That might be a useful hint for enterprises as they remove proxies and increase local breakout. But I really don't know at the moment what's the best roadmap for migrating the DNS and the namespace to being "Internet centric", which is why I asked the WG ;) It could get very complex because you can learn or leak IPv4 information (e.g. RFC1918 addresses, private namespace, or conflicting namespace) over an IPv6 transport connection (which will be end-to-end transparent), but which would not be transported over an IPv4 connection (the IPv4 transport either never existed, was DNS forwarded or proxied, or was NATted). Then add caching and mobile end nodes into the mix. I suspect it will be quite easy for enterprises to paint themselves into a corner, if they haven't already. And if they already have, what do they do? regards, RayH From fred@cisco.com Thu Jun 14 18:14: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 9C8C611E808D for ; Thu, 14 Jun 2012 18:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -112.599 X-Spam-Level: X-Spam-Status: No, score=-112.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, 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 gEtGu3jpqVIp for ; Thu, 14 Jun 2012 18:14:39 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2C611E8072 for ; Thu, 14 Jun 2012 18:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=385; q=dns/txt; s=iport; t=1339722879; x=1340932479; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=8pAZcLHStZJKhXLlP7QUoDXDMrmzcUXdH8AVSSq0C54=; b=Xxw2HTPeug23bFEqjZKU6QXYKkgFm7xJ2H8MhDn1jxjRHGuWn7jQ/PPd REFiNTZy7NWGoK1zr5RenNokUl7RLDFo9TlyhYZZsdvr/l1kiYkrHIq0m CIotntsjnhHqnTw6u8e097pvYHV3Pbp+fxh3FeA8ZpFqHazd7qIQo/eMt 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAGSL2k+rRDoH/2dsb2JhbABFtT6BB4IxASc0gUk1h2iYVoEooBSQY2ADiEGMYIVUiEKBZoMA X-IronPort-AV: E=Sophos;i="4.75,774,1330905600"; d="scan'208";a="49018314" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 15 Jun 2012 01:14:39 +0000 Received: from dhcp-171-69-156-29.cisco.com (dhcp-171-69-156-29.cisco.com [171.69.156.29]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5F1EcKO014156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 15 Jun 2012 01:14:38 GMT Received: from [127.0.0.1] by dhcp-171-69-156-29.cisco.com (PGP Universal service); Thu, 14 Jun 2012 18:14:38 -0700 X-PGP-Universal: processed; by dhcp-171-69-156-29.cisco.com on Thu, 14 Jun 2012 18:14:38 -0700 From: Fred Baker Date: Thu, 14 Jun 2012 18:14:20 -0700 Message-Id: <3E4C01D2-AA46-4F4E-835C-C6E29484F497@cisco.com> To: IPv6 Operations 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] -00 draft cut-off X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Jun 2012 01:14:39 -0000 FYI, the -00 draft cut-off for IETF 84 (Vancouver) is 9 July, a few = weeks hence. As always, as new -00 drafts come in, my bot will post an = invitation to discussion on the mailing list. Apart from that, it's up = to the author to generate discussion. That often takes some time. So you want to start thinking about those -00 drafts now, and get them = into the discussion.= From brian.e.carpenter@gmail.com Sun Jun 17 02:29: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 5061421F85F6 for ; Sun, 17 Jun 2012 02:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -89.991 X-Spam-Level: X-Spam-Status: No, score=-89.991 tagged_above=-999 required=5 tests=[AWL=-11.115, BAYES_20=-0.74, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356, URIBL_BLACK=20, 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 MP08JpfqX+uJ for ; Sun, 17 Jun 2012 02:29:07 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20DB421F85CC for ; Sun, 17 Jun 2012 02:29:06 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1420591eaa.31 for ; Sun, 17 Jun 2012 02:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wlXb8/pYXoZ7PS75ZvRK6CSwv21HuKdc/h2spFHzqok=; b=mry1BOmp3oueVOEMz4LBlFeob74eYqkNiIam4UuGRrdP/jdBw188VFPoLd++2VY+BM J6XP8kB1nfNWnPywgRcpV3jCBYTTuYZd4/E9rguBdYJXt5ixofLoctzl6OkE3Yyparbv LE7/J/zwFznFP4jakZdzMmGSdGv/LdEoaQ/F7EEA46MBujy9H/kPvVncqLzDdGsUys8Y wUOUIBnXSQcnTtENjWz+DTGeEAqAnnJinvEs1oO/Du5mGOmg3RW2FKvvhiCLVU9bsLaS 8vjzwkW62OMuilNWLchWEOi7/evoW3rid/w5nKzoV0QffBrSzIWq854rw9kv3rNPClIB Fwxw== Received: by 10.14.97.77 with SMTP id s53mr2569746eef.104.1339925345962; Sun, 17 Jun 2012 02:29:05 -0700 (PDT) Received: from [192.168.1.66] (host-2-102-218-189.as13285.net. [2.102.218.189]) by mx.google.com with ESMTPS id y12sm48977277eem.7.2012.06.17.02.29.04 (version=SSLv3 cipher=OTHER); Sun, 17 Jun 2012 02:29:05 -0700 (PDT) Message-ID: <4FDDA35E.9050701@gmail.com> Date: Sun, 17 Jun 2012 10:29:02 +0100 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: <000301cd4801$1f059880$5d10c980$@asgard.org> <4FD8B188.1000403@globis.net> <002701cd4a3e$99e19ce0$cda4d6a0$@asgard.org> <4FDA19FC.1010606@globis.net> In-Reply-To: <4FDA19FC.1010606@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'IPv6 Operations' Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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, 17 Jun 2012 09:29:09 -0000 Re split DNS, someone pointed me at this interesting draft: http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view Not a popular topic in DNS land, of course. Regards Brian On 2012-06-14 18:06, Ray Hunter wrote: > inline >> Lee Howard >> 14 June 2012 17:01 >>> -----Original Message----- >>> From: Ray Hunter [mailto:v6ops@globis.net] >>> Sent: Wednesday, June 13, 2012 11:28 AM >>> To: Lee Howard >>> Cc: 'Victor Kuarsingh'; 'IPv6 Operations' >>> Subject: Re: [v6ops] Enterprise Guidance on IPv6 >>> (draft-chkpvc-enterprise-incremental- >>> ipv6-00) >>> >>> Regardless of whether this draft is the vehicle or not, one thing >>> that I think is missing is that >>> large enterprises currently almost universally use some sort of >>> centralized gateway or proxy >>> to access the Internet, coupled with "split DNS" (whether the IETF >>> likes that or not >> >> "Split DNS" meaning that different responses are returned depending on >> whether the query >> comes from within the enterprise or from outside? >> For instance, an employee can reach ACCOUNTING.EXAMPLE.COM internally, >> because the >> name server returns a net 10 address, but a query from outside receives >> NXDOMAIN? > I believe "Split DNS" can mean several things, which is why I placed it > in quotes. > > I don't think Split DNS was ever acknowledged as a standard. But it is > widely deployed in enterprises AFAIK. One reason was to mitigate against > cache poisoning. Another was to be able to use DNS with RFC1918 > addresses before this was supported on common implementations. Another > was just so that internal name and address space was completely private > in manufacturing environments. Another was for test & development > environments. Another was so that dynamically updated names in AD could > remain relatively secure from external interference. > > So the namespace can be split, or the transport, or both. > > I believe I've seen: > > 1) internal hidden servers that serve different zones internally as the > external servers. These internal hidden masters may be used to source > zone transfers to sacrificial external slave servers that serve a subset > of the namespace. So ext.example.com may be served externally, but > int.example.com may be restricted to the internal servers (simply by not > having the secondary zone configured on the external server). The > internal servers may or may not be able to resolve Internet names > (sometimes via a proxy DNS setup) Here we have a split namespace, and > potentially a split transport (depending on how internal hosts resolve > external addresses) > > 2) A single set of DNS servers that serve different answers based on > some parameter from the query e.g. a single DNS server using BIND > "views" to provide an answer for accounting.example.com based on the > source address of the query matching an on-enterprise-net pattern, that > is not resolvable for off-enterprise-net addresses. Here we're clearly > talking about split namespace, but contiguous transport. > > 3) Completely separate internal and external servers serving the same > logical zone but with different content and sometimes managed completely > separately e.g. www.example.com hosted externally at a hosting provider > for a corporate website for public consumption, and a separate > employee's version of the same website iww.example.com hosted internally > by the IT department. The external DNS servers may have an Internet > hints file and a be managed by the hosting provider. The internal DNS > servers may have a (fake) master root zone and be managed by the IT > department. Internal hosts normally will not be able to resolve > www.external.com or www.example.com and are pointed to an appropriate > web proxy via a proxy pac file. Here we're talking about split namespace > and split transport. Sometimes there may even be conflicting or > overlapping namespace. > > 4) Completely fictitious internal A record entries for trusted 3rd party > companies where there is a private link between the two companies > together with a contractual agreement defining responsibilities e.g. for > B2B transactions or for managing outsourced systems, or providing > outsourced services to example.com. This is just a horrible kludge. > > 5) Equivalent of a .local namespace for dev, test & production. So > there'd be overlapping address space for hostname-x.dev.company.com > hostname-x.test.company.com hostname-x.production.company.com. As > software moved from one environment to the next, all that was changed > was the DNS default search domain (no machine renumbering needed in > order to avoid problems with high availability scripts having to be > edited). Some people even used identical setups for all 3 environments > (identical names, addresses & domains) to avoid changing anything as > solutions were transported between environments (via hard media). > > 6) Manufacturing environments that were meant to be completely isolated > (yes I know) that use private RFC1918 IP space. > > Don't shoot the messenger. >>> Many enterprises have expressed a desire to become "Internet Centric" >>> whatever that is. They're also moving very rapidly to cloud services for >> generic applications. >>> However, they'll still need private enterprise networks with SLAs for >>> many >> other business >>> critical services ad interim, at least until the generic Internet >>> supports >> an equivalent of >>> Diffserv. >>> Multiple IPv6 addresses per node, with a combination of PI space for the >> enterprise network >>> and PA space fromlocal providers, is making direct proxy-free nat-free >> local Internet >>> breakout potentially possible (together with MIF and appropriate address >> selection). >>> DNSSEC is also potentially attractive to facilitate/ restore a basic end >> to end trust model. >>> So I think we know where we're starting, and I think we know where we >>> end >> up, but is there >>> any operational advice available on the steps that would be required to >> e.g. "unsplit DNS" >>> (and remove proxies) when introducing IPv6? >> >> What changes? You can still return NXDOMAIN if you don't like the >> querier. >> Or you can >> respond with a AAAA and rely on your security to protect your accounting >> system. > You're assuming that the transport has always been contiguous between > internal and external hosts and DNS servers, and that there is a single > consistent set of authoritative name servers for a common Worldwide > namespace. That is rarely the case AFAIK. >>> In other words, how do we restore the end to end model without breaking >> stuff on the way? >> >> I may be misunderstanding you, though, since I'm not sure how the >> end-to-end >> principle >> applies to this DNS setup. >> Yes, GUA addressing makes it possible to eliminate NAT, but whether >> enterprises eliminate >> proxies depends on their policy reasons for implementing them in the >> first >> place. >> >> What should we say about all this? > It's relatively easily to define a flexible PI based IPv6 addressing > plan so that return routes can be de-aggregated as necessary (based on > Internet latency) as the number of direct Internet gateways grows. That > might be a useful hint for enterprises as they remove proxies and > increase local breakout. > > But I really don't know at the moment what's the best roadmap for > migrating the DNS and the namespace to being "Internet centric", which > is why I asked the WG ;) > > It could get very complex because you can learn or leak IPv4 information > (e.g. RFC1918 addresses, private namespace, or conflicting namespace) > over an IPv6 transport connection (which will be end-to-end > transparent), but which would not be transported over an IPv4 connection > (the IPv4 transport either never existed, was DNS forwarded or proxied, > or was NATted). Then add caching and mobile end nodes into the mix. > > I suspect it will be quite easy for enterprises to paint themselves into > a corner, if they haven't already. And if they already have, what do > they do? > > regards, > RayH > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Mon Jun 18 04:07: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 6E86921F8566 for ; Mon, 18 Jun 2012 04:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.821 X-Spam-Level: X-Spam-Status: No, score=-98.821 tagged_above=-999 required=5 tests=[AWL=-11.778, BAYES_50=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_6CONS_WORD=0.356, URIBL_BLACK=20, 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 S+SUk749XgX3 for ; Mon, 18 Jun 2012 04:07:48 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3D721F8562 for ; Mon, 18 Jun 2012 04:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=10038; q=dns/txt; s=iport; t=1340017668; x=1341227268; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ZzPRCl92CKcH2IWaZy8vEhflydlPW8mvLKlBZrrpr6c=; b=CXl1e5IKQoS2JqiAvvUAu6ioNW5YW+9rMLPeiOgcg3dNlmu/zW7qYhnb AdBqJvVbwP62K5Y4Jw65k/XAuu2UHL5tqUzJRNE20k8QhWWbWpXy2CucA 4qtFbiTEqPjunZnW1lXfvr03rw1smyvcHe6zDlwhgDL8QVWJg8gBPDa47 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPoK30+rRDoJ/2dsb2JhbAA/BrVbgQeCGAEBAQMBAQEBDwEnDyULBQcECxEEAQEBJwcnHwkIBgoJGweHZAQMmFWfHIs3JoU1YAOIQoxigRKNBYFmgwA X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="49270334" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 18 Jun 2012 11:07:47 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5IB7k4M013971; Mon, 18 Jun 2012 11:07:46 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <4FDDA35E.9050701@gmail.com> Date: Mon, 18 Jun 2012 04:07:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7E0A8DAA-2EE6-4771-BDB0-F5FD4CD3EA5E@cisco.com> References: <000301cd4801$1f059880$5d10c980$@asgard.org> <4FD8B188.1000403@globis.net> <002701cd4a3e$99e19ce0$cda4d6a0$@asgard.org> <4FDA19FC.1010606@globis.net> <4FDDA35E.9050701@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter , 'IPv6 Operations' Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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, 18 Jun 2012 11:07:52 -0000 On Jun 17, 2012, at 2:29 AM, Brian E Carpenter wrote: > Re split DNS, someone pointed me at this interesting draft: > http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view >=20 > Not a popular topic in DNS land, of course. You're correct that DNS-land hasn't liked it. I think the point being = made here is that, with or without help from namedroppers@, something = akin to what Ray described is an operational reality. It's not unusual = for a company to have an internal and external set of names, the latter = much smaller. Servers that are externally-accessible don't translate = names that the company doesn't authorize for external access, even if = they have global addresses, and even for names that are so advertised, = they might be internally read/write while externally read-only, and in = fact be instantiated as separate servers, the read/write one = periodically over-writing the read-only one. Speaking for myself, I would rather have a frank discussion of a bad = idea that is an operational reality than to play pretend (see my draft = on firewalls, which has the same logic underlying it), because = discussion may improve it or may convince people it is in fact a bad = idea - or may demonstrate that it's a good idea that is unpopular. > Regards > Brian >=20 > On 2012-06-14 18:06, Ray Hunter wrote: >> inline >>> Lee Howard >>> 14 June 2012 17:01 >>>> -----Original Message----- >>>> From: Ray Hunter [mailto:v6ops@globis.net] >>>> Sent: Wednesday, June 13, 2012 11:28 AM >>>> To: Lee Howard >>>> Cc: 'Victor Kuarsingh'; 'IPv6 Operations' >>>> Subject: Re: [v6ops] Enterprise Guidance on IPv6 >>>> (draft-chkpvc-enterprise-incremental- >>>> ipv6-00) >>>>=20 >>>> Regardless of whether this draft is the vehicle or not, one thing >>>> that I think is missing is that >>>> large enterprises currently almost universally use some sort of >>>> centralized gateway or proxy >>>> to access the Internet, coupled with "split DNS" (whether the IETF >>>> likes that or not >>>=20 >>> "Split DNS" meaning that different responses are returned depending = on >>> whether the query >>> comes from within the enterprise or from outside? >>> For instance, an employee can reach ACCOUNTING.EXAMPLE.COM = internally, >>> because the >>> name server returns a net 10 address, but a query from outside = receives >>> NXDOMAIN? >> I believe "Split DNS" can mean several things, which is why I placed = it >> in quotes. >>=20 >> I don't think Split DNS was ever acknowledged as a standard. But it = is >> widely deployed in enterprises AFAIK. One reason was to mitigate = against >> cache poisoning. Another was to be able to use DNS with RFC1918 >> addresses before this was supported on common implementations. = Another >> was just so that internal name and address space was completely = private >> in manufacturing environments. Another was for test & development >> environments. Another was so that dynamically updated names in AD = could >> remain relatively secure from external interference. >>=20 >> So the namespace can be split, or the transport, or both. >>=20 >> I believe I've seen: >>=20 >> 1) internal hidden servers that serve different zones internally as = the >> external servers. These internal hidden masters may be used to source >> zone transfers to sacrificial external slave servers that serve a = subset >> of the namespace. So ext.example.com may be served externally, but >> int.example.com may be restricted to the internal servers (simply by = not >> having the secondary zone configured on the external server). The >> internal servers may or may not be able to resolve Internet names >> (sometimes via a proxy DNS setup) Here we have a split namespace, and >> potentially a split transport (depending on how internal hosts = resolve >> external addresses) >>=20 >> 2) A single set of DNS servers that serve different answers based on >> some parameter from the query e.g. a single DNS server using BIND >> "views" to provide an answer for accounting.example.com based on the >> source address of the query matching an on-enterprise-net pattern, = that >> is not resolvable for off-enterprise-net addresses. Here we're = clearly >> talking about split namespace, but contiguous transport. >>=20 >> 3) Completely separate internal and external servers serving the same >> logical zone but with different content and sometimes managed = completely >> separately e.g. www.example.com hosted externally at a hosting = provider >> for a corporate website for public consumption, and a separate >> employee's version of the same website iww.example.com hosted = internally >> by the IT department. The external DNS servers may have an Internet >> hints file and a be managed by the hosting provider. The internal DNS >> servers may have a (fake) master root zone and be managed by the IT >> department. Internal hosts normally will not be able to resolve >> www.external.com or www.example.com and are pointed to an appropriate >> web proxy via a proxy pac file. Here we're talking about split = namespace >> and split transport. Sometimes there may even be conflicting or >> overlapping namespace. >>=20 >> 4) Completely fictitious internal A record entries for trusted 3rd = party >> companies where there is a private link between the two companies >> together with a contractual agreement defining responsibilities e.g. = for >> B2B transactions or for managing outsourced systems, or providing >> outsourced services to example.com. This is just a horrible kludge. >>=20 >> 5) Equivalent of a .local namespace for dev, test & production. So >> there'd be overlapping address space for hostname-x.dev.company.com >> hostname-x.test.company.com hostname-x.production.company.com. As >> software moved from one environment to the next, all that was changed >> was the DNS default search domain (no machine renumbering needed in >> order to avoid problems with high availability scripts having to be >> edited). Some people even used identical setups for all 3 = environments >> (identical names, addresses & domains) to avoid changing anything as >> solutions were transported between environments (via hard media). >>=20 >> 6) Manufacturing environments that were meant to be completely = isolated >> (yes I know) that use private RFC1918 IP space. >>=20 >> Don't shoot the messenger. >>>> Many enterprises have expressed a desire to become "Internet = Centric" >>>> whatever that is. They're also moving very rapidly to cloud = services for >>> generic applications. >>>> However, they'll still need private enterprise networks with SLAs = for >>>> many >>> other business >>>> critical services ad interim, at least until the generic Internet >>>> supports >>> an equivalent of >>>> Diffserv. >>>> Multiple IPv6 addresses per node, with a combination of PI space = for the >>> enterprise network >>>> and PA space fromlocal providers, is making direct proxy-free = nat-free >>> local Internet >>>> breakout potentially possible (together with MIF and appropriate = address >>> selection). >>>> DNSSEC is also potentially attractive to facilitate/ restore a = basic end >>> to end trust model. >>>> So I think we know where we're starting, and I think we know where = we >>>> end >>> up, but is there >>>> any operational advice available on the steps that would be = required to >>> e.g. "unsplit DNS" >>>> (and remove proxies) when introducing IPv6? >>>=20 >>> What changes? You can still return NXDOMAIN if you don't like the >>> querier. >>> Or you can >>> respond with a AAAA and rely on your security to protect your = accounting >>> system. >> You're assuming that the transport has always been contiguous between >> internal and external hosts and DNS servers, and that there is a = single >> consistent set of authoritative name servers for a common Worldwide >> namespace. That is rarely the case AFAIK. >>>> In other words, how do we restore the end to end model without = breaking >>> stuff on the way? >>>=20 >>> I may be misunderstanding you, though, since I'm not sure how the >>> end-to-end >>> principle >>> applies to this DNS setup. >>> Yes, GUA addressing makes it possible to eliminate NAT, but whether >>> enterprises eliminate >>> proxies depends on their policy reasons for implementing them in the >>> first >>> place. >>>=20 >>> What should we say about all this? >> It's relatively easily to define a flexible PI based IPv6 addressing >> plan so that return routes can be de-aggregated as necessary (based = on >> Internet latency) as the number of direct Internet gateways grows. = That >> might be a useful hint for enterprises as they remove proxies and >> increase local breakout. >>=20 >> But I really don't know at the moment what's the best roadmap for >> migrating the DNS and the namespace to being "Internet centric", = which >> is why I asked the WG ;) >>=20 >> It could get very complex because you can learn or leak IPv4 = information >> (e.g. RFC1918 addresses, private namespace, or conflicting namespace) >> over an IPv6 transport connection (which will be end-to-end >> transparent), but which would not be transported over an IPv4 = connection >> (the IPv4 transport either never existed, was DNS forwarded or = proxied, >> or was NATted). Then add caching and mobile end nodes into the mix. >>=20 >> I suspect it will be quite easy for enterprises to paint themselves = into >> a corner, if they haven't already. And if they already have, what do >> they do? >>=20 >> regards, >> RayH >> _______________________________________________ >> 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 fred@cisco.com Mon Jun 18 04:14: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 0B8FF21F85A0 for ; Mon, 18 Jun 2012 04:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.877 X-Spam-Level: X-Spam-Status: No, score=-105.877 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_50=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_6CONS_WORD=0.356, 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 wm9CJ3fNs0Za for ; Mon, 18 Jun 2012 04:14:16 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3A221F8562 for ; Mon, 18 Jun 2012 04:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4552; q=dns/txt; s=iport; t=1340018056; x=1341227656; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=QKgc2+6IFCfDkISdTI99aumc4MXqcjYAg4PZaORxq5w=; b=SQbxAtuIr3EIAnpcCWN2yP/29eSymVwlNAzQQn3f1Zfiezw7ULJ5Ytyf +xixPZAp573ASsBjBV4tFcO8BxeTo/EA09+r66/mTo+saSUzjAGhEif0o gzqgss7/sr/WY0glcSB4fl7QbeixGTWaROwUfgrsi/OnQf3Oi2m60Fm+o k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL4M30+rRDoG/2dsb2JhbABFtVuBB4IYAQEBAwEBAQEPASc0EAcECxEEAQEBJwcnHwkIBhMJCw6HZAQMmFCfG4V2hUGFW2ADiEKMYoESjQWBZoMA X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="49354206" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 18 Jun 2012 11:14:12 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5IBDjaH013862 for ; Mon, 18 Jun 2012 11:14:12 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <000301cd4801$1f059880$5d10c980$@asgard.org> Date: Mon, 18 Jun 2012 04:14:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <58DBDF90-CE65-467C-A7C4-F6A1C9E69642@cisco.com> References: <000301cd4801$1f059880$5d10c980$@asgard.org> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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, 18 Jun 2012 11:14:17 -0000 Let me put a straight question to the working group. The topic is: http://tools.ietf.org/html/draft-chkpvc-enterprise-incremental-ipv6 "Enterprise Incremental IPv6", Lee Howard, Tim Chown, KK Chittimaneni, Yanick Pouffary, Eric Vyncke, Victor Kuarsingh, 27-Feb-12 Read the v6ops charter (http://datatracker.ietf.org/wg/v6ops/charter/). = Do you feel that this document is within the charter? If so, do you feel = that the document and its recommendations represent useful advice = concerning operational practice in an enterprise (e.g., edge network = that is large enough to provide its own IT services as opposed to = contracting those) IPv6 network? Based on that analysis and viewpoint, would you support its adoption as = a working group draft? I am of course interested in views across the working group. In this = particular case, however, I would find especially interesting the = commentary of enterprise network operators. On Jun 11, 2012, at 11:36 AM, Lee Howard wrote: > When discussed in Taipei, it seemed there was real interest in = updating > guidance for=20 > enterprise networks. =46rom lack of list discussion, it now appears = there's > no interest in=20 > the WG. =20 >=20 > 1. Are people interested? > 2. Should we let it die? > 3. Should we pursue other avenues of publication? >=20 > Lee >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of > Victor >> Kuarsingh >> Sent: Monday, March 26, 2012 7:42 AM >> To: IPv6 Operations >> Subject: Re: [v6ops] draft-chkpvc-enterprise-incremental-ipv6-00 >>=20 >> IPv6 WG, >>=20 >> I would like to kick off some comments on this draft for other group > members to comment. >>=20 >> I do think (Bias noted) that this material is useful for Enterprises = who > need to being and/or >> move their IPv6 deployments. Many (of those I have worked with thus = far) > are bogged >> down with personnel who are overwhelmed with what it may take to get = IPv6 > moving on >> their networks. >>=20 >> The draft breaks the challenge down by areas of focus (rolled into >> "Phases") which can help put this large challenge into bite size = chunks > for them. The draft >> also provides some valid contextual information around >> IPv6 and highlights areas which should be looked at. >>=20 >> Given the good momentum we now have in the operator space, it would = be > good to see this >> move forward into the Enterprise space. I think such documents can = help > many of those still >> waffling (too many to count) to start acting. >>=20 >> Regards, >>=20 >> Victor K >>=20 >>=20 >> On 12-03-22 8:02 AM, "Tim Chown" wrote: >>=20 >>> Hi, >>>=20 >>> Due to a typo in the draft name, this draft didn't hit Fred's = automated >>> WG tools, so the authors would like to raise the draft on the list = now >>> with a view to securing a slot in Paris to discuss its value and = content. >>>=20 >>> In Taipei there was a comment in the WG session that there is no >>> up-to-date v6ops guidance on enterprise networks, while other = scenarios >>> do have such texts. So at the mic I invited people to join an = effort >>> to put something together. There is a good breadth of experience >>> across the people who stepped forward, and the result is available = as >>>=20 >>> = http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.txt >>>=20 >>> Does the WG think the subject matter of this draft is one we should >>> pursue in the WG? If so, is the structure and content appropriate? = We >>> need some positive feedback and comments in order for Fred to = schedule >>> us time in Paris. >>>=20 >>> We have had a couple of people contact us off-list offering to help >>> develop the content. But we'd like some feedback from the WG before >>> investing more time in doing so. The -00 text is somewhat "rough", = but >>> we feel it could be polished into something quite useful for the >>> community. >>>=20 >>> Tim >>>=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 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Mon Jun 18 04:19: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 B7F0221F85C3 for ; Mon, 18 Jun 2012 04:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.588 X-Spam-Level: X-Spam-Status: No, score=-107.588 tagged_above=-999 required=5 tests=[AWL=2.411, 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 QsJ13eOrdf9U for ; Mon, 18 Jun 2012 04:19:43 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 088C421F85BB for ; Mon, 18 Jun 2012 04:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1141; q=dns/txt; s=iport; t=1340018382; x=1341227982; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=49k4cvYHIwB/OIbOAaYPwBhttoCg0sm51f3Gb0oz+xs=; b=SWhgQiaLnb2NedYmn5CXBssIdpj6dziGxf/xubRFb7NMj0+ZIri5ut5T aqCJAqkFAWeIUnms6gAjizbQ1BAyCuaLBX9oKpvqxq+146wKiKYz7lG0M gbyqNq6mRPDo6LFoZl6MFKFVFT7J8uFlC1u4DUQ1DXwNF08WGzKltklqU Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIgN30+rRDoJ/2dsb2JhbABFtVuBB4IYAQEBAwEBAQEPASc0CwULC0YnMAYTIodkBAyYVJ8XBIs3hVtgA4hCjGKOF4FmgwA X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="46242699" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 18 Jun 2012 11:19:42 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5IBJgmJ023331; Mon, 18 Jun 2012 11:19:42 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: Date: Mon, 18 Jun 2012 04:19:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1084) Cc: draft-generic-v6ops-tunmtu@tools.ietf.org Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jun 2012 11:19:43 -0000 On Jun 12, 2012, at 3:50 PM, Templin, Fred L wrote: > Hi, >=20 > This document has now been updated to address issues > raised on the list and to expand on the roles of > inner fragmentation before encapsulation and outer > fragmentation after encapsulation. The answer is > that inner is needed in certain use cases, outer > is needed in certain others and both are needed in > still yet others. >=20 > The latest draft is now available here: >=20 > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ >=20 > Can we talk about this during the v6ops session at > the Vancouver meeting? I have seen comments on-list from Daniel Roesen, Mark Andrews, and = Washam Fan. In each case, they have commented on the draft without = saying whether they think it is a valuable working group output, which I = take quite literally - I don't know their opinion. Working group, is this draft something you would like to discuss? > Thanks - Fred > fred.l.templin@boeing.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Carl.Wuyts@technicolor.com Mon Jun 18 04:55: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 6873921F8575 for ; Mon, 18 Jun 2012 04:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[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 3AGVg30st1qU for ; Mon, 18 Jun 2012 04:55:34 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id 91C6A21F8562 for ; Mon, 18 Jun 2012 04:55:33 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKT98XL+NtwAUz3ARJ8pocmsIKIyvtEgiq@postini.com; Mon, 18 Jun 2012 04:55:34 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 18 Jun 2012 13:51:56 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.120]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Mon, 18 Jun 2012 13:51:58 +0200 From: Wuyts Carl To: Fred Baker , "v6ops@ietf.org WG" Date: Mon, 18 Jun 2012 13:51:56 +0200 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1NREkyfkPRTx8hTrS2vuHhPNMsLwAAxDOg Message-ID: <867F4B6A1672E541A94676D556793ACD149E83662A@MOPESMBX01.eu.thmulti.com> References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jun 2012 11:55:35 -0000 Hi Fred, I thought the target of the v6ops was to avoid these kind of things, and pr= omote proper IPv6 packet handling. After all, it is promoted from the star= t, that IPv6 brings you some extra things, like fixed header size, no more = fragmentation (only at host), a MANDATORY PMTU (while for v4 it was only ad= ded AFTER the protocol was there), .... Now I read in this draft to start = doing some fragmentation with inner/outer, whatever, headers etc ?? First of all, the "all links are 1500" statement is correct for Ethernet-ba= sed networks, but as I'm working for a company dealing with DSL, this is no= t always the case, so don't take it for granted. Moreover, CPE will be hea= vily involved in this (6rd etc). Secondly, if ICMPv6 PTB messages gets filtered out (by some wrongly configu= red firewall or any other device) then it should be fixed where it goes wro= ng, not work-around it. You're replacing a wrong filter with some complex = mechanism of fragmentation. Why is this filter in place ? Third, I see the definition of an "atomic" packet, but that's quite some as= sumption to be made for IPv6 packets. Just for the record. Our CPE can do fragmentation, so that's not an issue,= but we'd like to avoid this becoming normal mode of operation, to avoid lo= ts of potential issues with it. Moreover, what's next ?=20 regs Carl Wuyts -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= red Baker Sent: maandag 18 juni 2012 13:20 To: v6ops@ietf.org WG Cc: draft-generic-v6ops-tunmtu@tools.ietf.org Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu On Jun 12, 2012, at 3:50 PM, Templin, Fred L wrote: > Hi, >=20 > This document has now been updated to address issues raised on the=20 > list and to expand on the roles of inner fragmentation before=20 > encapsulation and outer fragmentation after encapsulation. The answer=20 > is that inner is needed in certain use cases, outer is needed in=20 > certain others and both are needed in still yet others. >=20 > The latest draft is now available here: >=20 > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ >=20 > Can we talk about this during the v6ops session at the Vancouver=20 > meeting? I have seen comments on-list from Daniel Roesen, Mark Andrews, and Washam F= an. In each case, they have commented on the draft without saying whether t= hey think it is a valuable working group output, which I take quite literal= ly - I don't know their opinion. Working group, is this draft something you would like to discuss? > Thanks - Fred > fred.l.templin@boeing.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 From fred@cisco.com Mon Jun 18 05:11: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 BCDA821F848F for ; Mon, 18 Jun 2012 05:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.29 X-Spam-Level: X-Spam-Status: No, score=-108.29 tagged_above=-999 required=5 tests=[AWL=2.309, 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 MVutQsiXzPmW for ; Mon, 18 Jun 2012 05:11:54 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id E92B221F847D for ; Mon, 18 Jun 2012 05:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1109; q=dns/txt; s=iport; t=1340021513; x=1341231113; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ITe/1cH0BdqSCyAdIu/vcLWSJGG27KiIKineTXPHgD8=; b=Dghz9rx6XX1Wct8kviP/WLEa1x9ev9/SzfOIxj/tZY0rPGPqfBsSiIsP WqaWZWnAMSQKmnE2HdryBfKWvMhValbEOxTPcVGLX1XjB6kmyT36L7uB+ /nXWmPmjM9/fu5T2e8cCFLbJ5kMyLjOAGRYt2WXe5wdk4gW0egxbECYlc Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHYa30+rRDoI/2dsb2JhbABFtVuBB4IYAQEBAwESAQUiPwULC0ZXBjWHZASYYp8jizcVhUZgA4hCjGKOF4FmgwCBNw X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="46247058" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 18 Jun 2012 12:11:53 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5ICBrGO015334; Mon, 18 Jun 2012 12:11:53 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <867F4B6A1672E541A94676D556793ACD149E83662A@MOPESMBX01.eu.thmulti.com> Date: Mon, 18 Jun 2012 05:11:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> <867F4B6A1672E541A94676D556793ACD149E83662A@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1084) Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jun 2012 12:11:54 -0000 On Jun 18, 2012, at 4:51 AM, Wuyts Carl wrote: > First of all, the "all links are 1500" statement is correct for = Ethernet-based networks, but as I'm working for a company dealing with = DSL, this is not always the case, so don't take it for granted.=20 Personal opinion... "All links are 1500 bytes" is a silly statement. There are days that I = think that some engineers only look as far as the interfaces on their = laptops to figure out what is interesting. There are some, for example, = that seem to think IEEE 802.15.4 has value; 802.15.4g has a 2047 byte = MTU; 802.15.4 uses 127. Something on the order of 9K bytes is pretty = common in optical networks (e.g. gigabit speed including Ethernet), but = is not a hard limit, and in the Ethernet case isn't in the IEEE = specification and so may or may not be supported. Ask yourself, for = example, how a 1500 byte Ethernet frame is encapsulated in MPLS and = placed on another Ethernet... What might be a useful survey would be for someone to figure out what = interface types are currently in use and what their MTUs are.= From fred@cisco.com Mon Jun 18 05:18: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 75B4121F8604 for ; Mon, 18 Jun 2012 05:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.32 X-Spam-Level: X-Spam-Status: No, score=-108.32 tagged_above=-999 required=5 tests=[AWL=1.679, 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 u9sA1UpWNDPo for ; Mon, 18 Jun 2012 05:18:25 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id CB2E521F8600 for ; Mon, 18 Jun 2012 05:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1373; q=dns/txt; s=iport; t=1340021905; x=1341231505; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lDR8+MRWrHjZW34mTiu6oVZ9w+b4uimVqQIpNBI+2k8=; b=TxPtwRMTzEQnZHzoIGZkkhUBCyKlQdqmyIaCoXEh4UTPXlwiOpyV8Rh8 bqFqI7kzOi433UHCXYLKyqbabeqk4E9c3eMIBL1TmDvxXGlHesjy08rUd u+xJBmICcy+xaY5+cGnyx3TSLFmxuZERfICOpZmNvt68YQeGRZnsl0VU4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAYc30+rRDoH/2dsb2JhbABFtVuBB4IYAQEBAwESASc/BQsLRlcGNYdkBJhonyOLN4VbYAOIQoxijheBZoMA X-IronPort-AV: E=Sophos;i="4.75,791,1330905600"; d="scan'208";a="46787479" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 18 Jun 2012 12:18:25 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5ICIPHa010925; Mon, 18 Jun 2012 12:18:25 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Fred Baker In-Reply-To: <867F4B6A1672E541A94676D556793ACD149E83662A@MOPESMBX01.eu.thmulti.com> Date: Mon, 18 Jun 2012 05:18:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9DCE9355-24EA-4900-8DEF-10528A170FED@cisco.com> References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> <867F4B6A1672E541A94676D556793ACD149E83662A@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1084) Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jun 2012 12:18:26 -0000 On Jun 18, 2012, at 4:51 AM, Wuyts Carl wrote: > I thought the target of the v6ops was to avoid these kind of things, = and promote proper IPv6 packet handling. After all, it is promoted from = the start, that IPv6 brings you some extra things, like fixed header = size, no more fragmentation (only at host), a MANDATORY PMTU (while for = v4 it was only added AFTER the protocol was there), ... On the mandatory PMTU... Yes, it is mandatory to implement. Those operator guys - on alternate = tuesdays I think some of them are either completely clueless or are = actively trying to make things more complex. Example, for the IPv6 Day a = year ago, I ran around looking at an amazing number of web sites. One = that I couldn't read was Juniper's. My IPv6 is a Hurricane Electric = tunnel, which I am quite sure is correctly sending ICMPv6 = packet-too-large messages, as I can read lots of other web pages, but at = that time I suspect that Juniper might have been dropping incoming = ICMPv6 messages. I know at least one large company configured all of its = equipment to never send a packet larger than 1280 bytes, which I would = consider a sad eventual outcome. It would be Really Nice if it were "mandatory to actually make work". Or, alternatively, if end systems would implement RFC 4821 or something = like it so we didn't have to.= From cb.list6@gmail.com Mon Jun 18 07:54: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 1283921F86BB for ; Mon, 18 Jun 2012 07:54:58 -0700 (PDT) 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 QgWRAxdHAKfT for ; Mon, 18 Jun 2012 07:54:58 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10C9721F86B9 for ; Mon, 18 Jun 2012 07:54:58 -0700 (PDT) Received: by dacx6 with SMTP id x6so7101207dac.31 for ; Mon, 18 Jun 2012 07:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IoFOjZCg5zdIOiaRxZNav0Xnsw8hdOdNpTktx+1RKic=; b=C0nERWuLF+gFxyRNfoGc/spl/dTPGKDFXH3QSP4wj6tkYD8egYwEeHEHO06by0uEhS DScykM/vyRuEes35b9mKmKTVki+kVQBNAZTvF4xPe9034jz5fQg4gMhj16xwOm5ARVrA z83njKZJwxRY6qxvCY+PuYzTLwLzhR93H5Kaa0wM7GCMcWE+D6i0czGh8EOGmvmSh28Q Kx8f6dD2+kyHSyyB2cNkXlTuQAywlx+CuQtx+WTUSj1hmDrvmYGWYc7FtXPVbNOYmhAM vFfLTgfK3w7doRenOGmIBsO8sq8BFxeLc0sI3o1lGoVquG4/MalVQtbChgUX8lFyA0fv KFhw== MIME-Version: 1.0 Received: by 10.68.130.169 with SMTP id of9mr23285110pbb.82.1340031297821; Mon, 18 Jun 2012 07:54:57 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Mon, 18 Jun 2012 07:54:57 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Mon, 18 Jun 2012 07:54:57 -0700 (PDT) In-Reply-To: <9DCE9355-24EA-4900-8DEF-10528A170FED@cisco.com> References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> <867F4B6A1672E541A94676D556793ACD149E83662A@MOPESMBX01.eu.thmulti.com> <9DCE9355-24EA-4900-8DEF-10528A170FED@cisco.com> Date: Mon, 18 Jun 2012 07:54:57 -0700 Message-ID: From: Cameron Byrne To: Fred Baker Content-Type: multipart/alternative; boundary=047d7b10cac57e9d1404c2c05977 Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jun 2012 14:54:59 -0000 --047d7b10cac57e9d1404c2c05977 Content-Type: text/plain; charset=ISO-8859-1 On Jun 18, 2012 5:18 AM, "Fred Baker" wrote: > > > On Jun 18, 2012, at 4:51 AM, Wuyts Carl wrote: > > > I thought the target of the v6ops was to avoid these kind of things, and promote proper IPv6 packet handling. After all, it is promoted from the start, that IPv6 brings you some extra things, like fixed header size, no more fragmentation (only at host), a MANDATORY PMTU (while for v4 it was only added AFTER the protocol was there), ... > > On the mandatory PMTU... > > Yes, it is mandatory to implement. Those operator guys - on alternate tuesdays I think some of them are either completely clueless or are actively trying to make things more complex. Example, for the IPv6 Day a year ago, I ran around looking at an amazing number of web sites. One that I couldn't read was Juniper's. My IPv6 is a Hurricane Electric tunnel, which I am quite sure is correctly sending ICMPv6 packet-too-large messages, as I can read lots of other web pages, but at that time I suspect that Juniper might have been dropping incoming ICMPv6 messages. I know at least one large company configured all of its equipment to never send a packet larger than 1280 bytes, which I would consider a sad eventual outcome. > > It would be Really Nice if it were "mandatory to actually make work". > > Or, alternatively, if end systems would implement RFC 4821 or something like it so we didn't have to. > Afaik, failure to do pmtu is fairly quick and obvious breakage. So blocking ptb icmpv6 is not an operational practice, it is an implementation misstep that is resolved relatively quickly in the real world. It is not a systemic problem that needs to be solved by the ietf, it is just part of the ipv6 learning curve. CB _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --047d7b10cac57e9d1404c2c05977 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jun 18, 2012 5:18 AM, "Fred Baker" <fred@cisco.com> wrote:
>
>
> On Jun 18, 2012, at 4:51 AM, Wuyts Carl wrote:
>
> > I thought the target of the v6ops was to avoid these kind of thin= gs, and promote proper IPv6 packet handling. =A0After all, it is promoted f= rom the start, that IPv6 brings you some extra things, like fixed header si= ze, no more fragmentation (only at host), a MANDATORY PMTU (while for v4 it= was only added AFTER the protocol was there), ...
>
> On the mandatory PMTU...
>
> Yes, it is mandatory to implement. Those operator guys - on alternate = tuesdays I think some of them are either completely clueless or are activel= y trying to make things more complex. Example, for the IPv6 Day a year ago,= I ran around looking at an amazing number of web sites. One that I couldn&= #39;t read was Juniper's. My IPv6 is a Hurricane Electric tunnel, which= I am quite sure is correctly sending ICMPv6 packet-too-large messages, as = I can read lots of other web pages, but at that time I suspect that Juniper= might have been dropping incoming ICMPv6 messages. I know at least one lar= ge company configured all of its equipment to never send a packet larger th= an 1280 bytes, which I would consider a sad eventual outcome.
>
> It would be Really Nice if it were "mandatory to actually make wo= rk".
>
> Or, alternatively, if end systems would implement RFC 4821 or somethin= g like it so we didn't have to.
>

Afaik, failure to do pmtu is fairly quick and obvious breakage.

So blocking ptb icmpv6 is not an operational practice, it is an implemen= tation misstep that is resolved relatively quickly in the real world.

It is not a systemic problem that needs to be solved by the ietf, it is = just part of the ipv6 learning curve.

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

--047d7b10cac57e9d1404c2c05977-- From Fred.L.Templin@boeing.com Mon Jun 18 09:05: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 8DFFE21F86DF for ; Mon, 18 Jun 2012 09:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.119, 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 gqmQ4HWPaP4k for ; Mon, 18 Jun 2012 09:05:06 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id C59B821F86F5 for ; Mon, 18 Jun 2012 09:05:06 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5IG5PXN015732 for ; Mon, 18 Jun 2012 09:05:25 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5IG5OGm015716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Jun 2012 09:05:24 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5IG552p017892; Mon, 18 Jun 2012 09:05:05 -0700 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5IG54ha017837 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 18 Jun 2012 09:05:05 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Mon, 18 Jun 2012 09:05:04 -0700 From: "Templin, Fred L" To: Fred Baker , "v6ops@ietf.org WG" Date: Mon, 18 Jun 2012 09:05:03 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1NREi51/egJIBMSZ6Xf9kkgomedgAJqj2w Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jun 2012 16:05:07 -0000 Hi, I touched this draft up for a -04 version to add a new section on "tunnel fragmentation". No other changes were made to the document. I don't expect any further revisions ahead of the IETF, but should any occur I would announce them here. In any case, the document can be tracked in the datatracker at: https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ The text of the new section appears below: Thanks - Fred fred.l.templin@boeing.com --- 6. Tunnel Fragmentation A third and less commonly known method of fragmentation is called "tunnel fragmentation". Tunnel fragmentation occurs following any inner fragmentation but before any outer fragmentation. Tunnel fragmentation requires separate packet Identification and segmentation control bits in a mid-layer of encapsulation that is added between the inner and outer IP headers. As for outer fragmentation, the tunnel egress is responsible for reassembly. Tunnel fragmentation can be particularly useful for tunnels over IPv4, since the mid-layer encapsulation can include an extended Identification field that avoids the identification wrapping issues seen for IPv4 fragmentation [RFC4963]. Furthermore, when tunnel fragmentation is used the tunnel ingress has assurance that the egress can reassemble up to (1500 + HLEN) since both the ingress and egress are required to implement the scheme. An example of tunnel fragmentation appears in SEAL [I-D.templin-intarea-seal]. --- > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Fred Baker > Sent: Monday, June 18, 2012 4:20 AM > To: v6ops@ietf.org WG > Cc: draft-generic-v6ops-tunmtu@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 >=20 > On Jun 12, 2012, at 3:50 PM, Templin, Fred L wrote: >=20 > > Hi, > > > > This document has now been updated to address issues > > raised on the list and to expand on the roles of > > inner fragmentation before encapsulation and outer > > fragmentation after encapsulation. The answer is > > that inner is needed in certain use cases, outer > > is needed in certain others and both are needed in > > still yet others. > > > > The latest draft is now available here: > > > > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ > > > > Can we talk about this during the v6ops session at > > the Vancouver meeting? >=20 > I have seen comments on-list from Daniel Roesen, Mark Andrews, and Washam > Fan. In each case, they have commented on the draft without saying whethe= r > they think it is a valuable working group output, which I take quite > literally - I don't know their opinion. >=20 > Working group, is this draft something you would like to discuss? >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > > _______________________________________________ > > 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 Fred.L.Templin@boeing.com Mon Jun 18 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 332DB21F86F8 for ; Mon, 18 Jun 2012 09:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=0.089, 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 iNpNtTMQM5uv for ; Mon, 18 Jun 2012 09:23:08 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 6A69521F86FA for ; Mon, 18 Jun 2012 09:23:07 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5IGN6eu012077 for ; Mon, 18 Jun 2012 09:23:06 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5IGN5Tv012061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Jun 2012 09:23:06 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5IGN5VK013213; Mon, 18 Jun 2012 09:23:05 -0700 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5IGN4j4013189 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 18 Jun 2012 09:23:05 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Mon, 18 Jun 2012 09:23:04 -0700 From: "Templin, Fred L" To: Wuyts Carl , Fred Baker , "v6ops@ietf.org WG" Date: Mon, 18 Jun 2012 09:23:04 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1NREkyfkPRTx8hTrS2vuHhPNMsLwAAxDOgAAlTOUA= Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> <867F4B6A1672E541A94676D556793ACD149E83662A@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD149E83662A@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jun 2012 16:23:09 -0000 Hi Carl, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Wuyts Carl > Sent: Monday, June 18, 2012 4:52 AM > To: Fred Baker; v6ops@ietf.org WG > Cc: draft-generic-v6ops-tunmtu@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > Hi Fred, >=20 > I thought the target of the v6ops was to avoid these kind of things, and > promote proper IPv6 packet handling. After all, it is promoted from the > start, that IPv6 brings you some extra things, like fixed header size, no > more fragmentation (only at host), a MANDATORY PMTU (while for v4 it was > only added AFTER the protocol was there), .... Now I read in this draft > to start doing some fragmentation with inner/outer, whatever, headers etc > ?? IPv6 fixes fragmentation and reassembly by virtue of the extended Identification field. I think that legislating IPv6 fragmentation out of the network was a well-intentioned mistake that was heavily influenced by earlier works including the 1987 "Fragmentation Considered Harmful". That work was published a long time ago and made valid points, but many of the assumptions and issues it documented no longer apply. =20 > First of all, the "all links are 1500" statement is correct for Ethernet- > based networks, but as I'm working for a company dealing with DSL, this i= s > not always the case, so don't take it for granted. Moreover, CPE will be > heavily involved in this (6rd etc). > Secondly, if ICMPv6 PTB messages gets filtered out (by some wrongly > configured firewall or any other device) then it should be fixed where it > goes wrong, not work-around it. You're replacing a wrong filter with som= e > complex mechanism of fragmentation. Why is this filter in place ? > Third, I see the definition of an "atomic" packet, but that's quite some > assumption to be made for IPv6 packets. We're not trying to say that all links are 1500 - only that 1500 is the minimum path MTU that most hosts expect to see unless they connect directly to a sub-1500 link. What we would like to get to is support for MTU diversity so that whatever link MTUs occur in the path can be naturally accommodated.=20 =20 > Just for the record. Our CPE can do fragmentation, so that's not an > issue, but we'd like to avoid this becoming normal mode of operation, to > avoid lots of potential issues with it. Moreover, what's next ? I don't think anything is next necessarily, other than migration to links with larger MTUs. The choices for the CPE are to either hope that the network delivers the necessary PTB messages or to take matters into its own hands and perform a little bit of fragmentation. Thanks - Fred fred.l.templin@boeing.com > regs > Carl Wuyts >=20 >=20 >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Fred Baker > Sent: maandag 18 juni 2012 13:20 > To: v6ops@ietf.org WG > Cc: draft-generic-v6ops-tunmtu@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 >=20 > On Jun 12, 2012, at 3:50 PM, Templin, Fred L wrote: >=20 > > Hi, > > > > This document has now been updated to address issues raised on the > > list and to expand on the roles of inner fragmentation before > > encapsulation and outer fragmentation after encapsulation. The answer > > is that inner is needed in certain use cases, outer is needed in > > certain others and both are needed in still yet others. > > > > The latest draft is now available here: > > > > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ > > > > Can we talk about this during the v6ops session at the Vancouver > > meeting? >=20 > I have seen comments on-list from Daniel Roesen, Mark Andrews, and Washam > Fan. In each case, they have commented on the draft without saying whethe= r > they think it is a valuable working group output, which I take quite > literally - I don't know their opinion. >=20 > Working group, is this draft something you would like to discuss? >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > > _______________________________________________ > > 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Mon Jun 18 09:29: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 DC5D421F86E5 for ; Mon, 18 Jun 2012 09:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.53 X-Spam-Level: X-Spam-Status: No, score=-108.53 tagged_above=-999 required=5 tests=[AWL=1.470, 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 fY5ueZ-iWBmH for ; Mon, 18 Jun 2012 09:29:06 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC8921F86FA for ; Mon, 18 Jun 2012 09:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2865; q=dns/txt; s=iport; t=1340036946; x=1341246546; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=UX8Sy/6F8kIDr2hP/w3rzbnSVi45sf1DEkjx2sOVrgc=; b=ZKD/j0560lLXAwEb0gAUqoIbHI7aWY8pPn01lGQyiSlPeY5qG7g8P8Qh pMyLqRK6BU/uACq5Eg1FcDNRfRW8naOtnJ7GE4JIJtEXB9vR7AF+PkmKH y3LPeUSkDtMR5Kt/HyE1Wu1tAqB4wvPodC0msvOgnbM8pQ7BeMjAiRSd7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHhW30+rRDoH/2dsb2JhbABFtVuBB4IYAQEBAwESAScNJgwFCwsOCi5XBhMbB4dkBJkAkQKOV4s3hVtgA4hCjGKFVIhDgWaDAA X-IronPort-AV: E=Sophos;i="4.75,793,1330905600"; d="scan'208";a="49380037" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 18 Jun 2012 16:29:06 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5IGT5Z7007817; Mon, 18 Jun 2012 16:29:05 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Mon, 18 Jun 2012 09:29:06 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Mon, 18 Jun 2012 09:29:06 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 18 Jun 2012 09:28:38 -0700 Message-Id: <9AD9DADA-7E71-49B4-B8A2-A7FCE82BD3A9@cisco.com> References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> <867F4B6A1672E541A94676D556793ACD149E83662A@MOPESMBX01.eu.thmulti.com> <9DCE9355-24EA-4900-8DEF-10528A170FED@cisco.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jun 2012 16:29:08 -0000 On Jun 18, 2012, at 7:54 AM, Cameron Byrne wrote: > On Jun 18, 2012 5:18 AM, "Fred Baker" wrote: > On Jun 18, 2012, at 4:51 AM, Wuyts Carl wrote: >>> I thought the target of the v6ops was to avoid these kind of things, = and promote proper IPv6 packet handling. After all, it is promoted from = the start, that IPv6 brings you some extra things, like fixed header = size, no more fragmentation (only at host), a MANDATORY PMTU (while for = v4 it was only added AFTER the protocol was there), ... >>=20 >> On the mandatory PMTU... >>=20 >> Yes, it is mandatory to implement. Those operator guys - on alternate = tuesdays I think some of them are either completely clueless or are = actively trying to make things more complex. Example, for the IPv6 Day a = year ago, I ran around looking at an amazing number of web sites. One = that I couldn't read was Juniper's. My IPv6 is a Hurricane Electric = tunnel, which I am quite sure is correctly sending ICMPv6 = packet-too-large messages, as I can read lots of other web pages, but at = that time I suspect that Juniper might have been dropping incoming = ICMPv6 messages. I know at least one large company configured all of its = equipment to never send a packet larger than 1280 bytes, which I would = consider a sad eventual outcome. >>=20 >> It would be Really Nice if it were "mandatory to actually make work". >>=20 >> Or, alternatively, if end systems would implement RFC 4821 or = something like it so we didn't have to. >=20 >=20 > Afaik, failure to do pmtu is fairly quick and obvious breakage. It is, but it may not be visible to the culprit. The fact that *I* block = ICMPv6 as a swath means that *you* don't get PMTU. *I* don't see any = breakage unless I am looking for it. > So blocking ptb icmpv6 is not an operational practice, it is an = implementation misstep that is resolved relatively quickly in the real = world. >=20 > It is not a systemic problem that needs to be solved by the ietf, it = is just part of the ipv6 learning curve. I agree, but then...=20 PMTU works the same way in IPv4, and in fact was developed for IPv4. = ICMP is commonly blocked in IPv4, sending or receiving, and the practice = is copied to IPv6. That said, I asked Google about "security practice = ICMP" and got back links making recommendations on both sides - "Block = ICMP type <> because it is used in attacks", "block outbound ICMP", and = "permit PMTU messages". I would about bet that as soon as one steps away = from people likely to be on this list, you'll get to people that say = "the right solution is to block anything you can't say why you need - = and *I* don't implement any tunnels..." On the other hand, I can't say I think many of those people actually = read RFCs, so I don't know what providing an RFC does for them.= From washam.fan@gmail.com Mon Jun 18 22:48: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 674A621F86EA for ; Mon, 18 Jun 2012 22:48:19 -0700 (PDT) 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 Cyk-Y78kx5FY for ; Mon, 18 Jun 2012 22:48:18 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42921F84D9 for ; Mon, 18 Jun 2012 22:48:18 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so188850wib.13 for ; Mon, 18 Jun 2012 22:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LSn9O1C63jjvqaNBIkyCsE4K6MSW96zMpqaLwQu+Ibk=; b=ivv9zLn/ADw6DgIYUQJ0wOSoUfkfkrbzynItNfaMx68KKQ3asu2wrFksqdyfyKc1OI WzqEcSvGJg4t0LeQgRX8EN9JoShOYoC2j1HMTYvN7/vOLhCh3trryuSQsi6cYqXtfDr5 Q/vofgbPjXEpoCZzv2ylANU5KDKhFFUfUN6RXV1e6bqnmjqjQW52uioLwj8T7ZCpZ9SQ dpy0qLCzaR/ZUmcpld6m0fMAnDtoCDCHJjNBxJlYJYdLD2fBTBgAM9QB4d9rRqZ/oWBV 8h5AAdTKNd3J+hV2pcPu0S3+ZEhkYhjqc720GRjniLb/ReUpJvjTH3xlx0KDXo16T/OW ykTg== MIME-Version: 1.0 Received: by 10.216.226.136 with SMTP id b8mr9134710weq.152.1340084897586; Mon, 18 Jun 2012 22:48:17 -0700 (PDT) Received: by 10.216.81.138 with HTTP; Mon, 18 Jun 2012 22:48:17 -0700 (PDT) In-Reply-To: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> Date: Tue, 19 Jun 2012 13:48:17 +0800 Message-ID: From: Washam Fan To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jun 2012 05:48:19 -0000 Hi Fred, We've discussed before in this link http://www.ietf.org/mail-archive/web/v6ops/current/msg13206.html I've read the section 4, -04 version. I noticed only clause 1) bullet 1) trigger PTB messages. Should it not better to let clause 1) bullet 2 and clause 2) also trigger PTB messages expecting PMTU works and subsequent arriving packets just fit in the tunnel MTU? Thanks, washam 2012/5/23 Templin, Fred L : > Please review and comment on 'draft-generic-v6ops-tunmtu': > > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ > > This new document takes the radical approach of proposing > IPv6 router fragmentation at the tunnel ingress so that > the tunnel MTU can be jacked up to 1500 bytes. > > The document notes issues that arise when the IPv6 router > performs fragmentation - most notably, the selection of > the Identification value to place in the (router-inserted) > fragmentation header. > > Please review and comment on this thread. Remember that > this approach is proposing something new and different > and should be discussed further on the list. > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >> fred@cisco.com >> Sent: Wednesday, May 23, 2012 5:45 AM >> To: v6ops@ietf.org >> Cc: draft-generic-v6ops-tunmtu@tools.ietf.org >> Subject: [v6ops] new draft: draft-generic-v6ops-tunmtu >> >> >> A new draft has been posted, at http://tools.ietf.org/html/draft-generic- >> v6ops-tunmtu. 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 From washam.fan@gmail.com Mon Jun 18 22:54: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 E0CF521F871A for ; Mon, 18 Jun 2012 22:54:12 -0700 (PDT) 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 x1vfYJC5VCRk for ; Mon, 18 Jun 2012 22:54:12 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C01F221F8718 for ; Mon, 18 Jun 2012 22:54:11 -0700 (PDT) Received: by werb13 with SMTP id b13so4874119wer.31 for ; Mon, 18 Jun 2012 22:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wzpQiljxiDoMlzmhRhL6U2F55NgFa6VNWLyH5QEGf6c=; b=XBxzCxrpn+p+Tn6HcJm2Uuj/L21Yk/gmN32MHqzIAd924IzejP4TKuTrCbQe1d0PMf SobyzRM+EbaehvssaZlnvLFY2ttuIUtyVcqggsaI0TGOLFSfpldCh4tQEJRcYKnqECZN 73KhUmhi+S5jGINYAYxwtOEywrRyT93pS3e8FYyUiB4SrkC0504B2bZZ3VgokAFFqXj2 tvmX80ZclxZ8NwZxRFPpr9dSvQaMp8iEeS/e5HvWlpyjckAPVTljMkDDBi1eCSHQuLwI 0gm9xboPDMcEEFM9XfhSfGmoM63TZHABjgTINF3+nYYHiIKIc8ph5vpYCTvnk9HR9O7C P/7w== MIME-Version: 1.0 Received: by 10.180.78.233 with SMTP id e9mr335177wix.5.1340085250795; Mon, 18 Jun 2012 22:54:10 -0700 (PDT) Received: by 10.216.81.138 with HTTP; Mon, 18 Jun 2012 22:54:10 -0700 (PDT) In-Reply-To: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> <867F4B6A1672E541A94676D556793ACD149E83662A@MOPESMBX01.eu.thmulti.com> Date: Tue, 19 Jun 2012 13:54:10 +0800 Message-ID: From: Washam Fan To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jun 2012 05:54:13 -0000 Hi Fred, 2012/6/19 Templin, Fred L : > Hi Carl, > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf O= f >> Wuyts Carl >> Sent: Monday, June 18, 2012 4:52 AM >> To: Fred Baker; v6ops@ietf.org WG >> Cc: draft-generic-v6ops-tunmtu@tools.ietf.org >> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >> >> Hi Fred, >> >> I thought the target of the v6ops was to avoid these kind of things, and >> promote proper IPv6 packet handling. =A0After all, it is promoted from t= he >> start, that IPv6 brings you some extra things, like fixed header size, n= o >> more fragmentation (only at host), a MANDATORY PMTU (while for v4 it was >> only added AFTER the protocol was there), .... =A0Now I read in this dra= ft >> to start doing some fragmentation with inner/outer, whatever, headers et= c >> ?? > > IPv6 fixes fragmentation and reassembly by virtue of the > extended Identification field. I think that legislating IPv6 > fragmentation out of the network was a well-intentioned mistake > that was heavily influenced by earlier works including the 1987 > "Fragmentation Considered Harmful". That work was published a > long time ago and made valid points, but many of the assumptions > and issues it documented no longer apply. I think this issue is the only concern for me on this draft. the draft explicitly says it *ignore* the requirement that router can't fragment ipv6 packets enroute. If we would've had an agreement that this requirement was a mistake, should we first update rfc2460 and then persuit this draft? Thanks, washam >> First of all, the "all links are 1500" statement is correct for Ethernet= - >> based networks, but as I'm working for a company dealing with DSL, this = is >> not always the case, so don't take it for granted. =A0Moreover, CPE will= be >> heavily involved in this (6rd etc). >> Secondly, if ICMPv6 PTB messages gets filtered out (by some wrongly >> configured firewall or any other device) then it should be fixed where i= t >> goes wrong, not work-around it. =A0You're replacing a wrong filter with = some >> complex mechanism of fragmentation. =A0Why is this filter in place ? >> Third, I see the definition of an "atomic" packet, but that's quite some >> assumption to be made for IPv6 packets. > > We're not trying to say that all links are 1500 - only that > 1500 is the minimum path MTU that most hosts expect to see > unless they connect directly to a sub-1500 link. What we > would like to get to is support for MTU diversity so that > whatever link MTUs occur in the path can be naturally > accommodated. > >> Just for the record. =A0Our CPE can do fragmentation, so that's not an >> issue, but we'd like to avoid this becoming normal mode of operation, to >> avoid lots of potential issues with it. =A0Moreover, what's next ? > > I don't think anything is next necessarily, other than > migration to links with larger MTUs. The choices for the > CPE are to either hope that the network delivers the > necessary PTB messages or to take matters into its own > hands and perform a little bit of fragmentation. > > Thanks - Fred > fred.l.templin@boeing.com > >> regs >> Carl Wuyts >> >> >> >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf O= f >> Fred Baker >> Sent: maandag 18 juni 2012 13:20 >> To: v6ops@ietf.org WG >> Cc: draft-generic-v6ops-tunmtu@tools.ietf.org >> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >> >> >> On Jun 12, 2012, at 3:50 PM, Templin, Fred L wrote: >> >> > Hi, >> > >> > This document has now been updated to address issues raised on the >> > list and to expand on the roles of inner fragmentation before >> > encapsulation and outer fragmentation after encapsulation. The answer >> > is that inner is needed in certain use cases, outer is needed in >> > certain others and both are needed in still yet others. >> > >> > The latest draft is now available here: >> > >> > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ >> > >> > Can we talk about this during the v6ops session at the Vancouver >> > meeting? >> >> I have seen comments on-list from Daniel Roesen, Mark Andrews, and Washa= m >> Fan. In each case, they have commented on the draft without saying wheth= er >> they think it is a valuable working group output, which I take quite >> literally - I don't know their opinion. >> >> Working group, is this draft something you would like to discuss? >> >> > Thanks - Fred >> > fred.l.templin@boeing.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 >> _______________________________________________ >> 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 Fred.L.Templin@boeing.com Tue Jun 19 09:16: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 C1BAF21F85F2 for ; Tue, 19 Jun 2012 09:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.071, 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 7FHh9XVxHLyb for ; Tue, 19 Jun 2012 09:16:02 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id BEC0521F85F0 for ; Tue, 19 Jun 2012 09:16:02 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5JGFv2D029062 for ; Tue, 19 Jun 2012 09:15:57 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5JGFuI0029059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Jun 2012 09:15:57 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5JGG0j5021631; Tue, 19 Jun 2012 09:16:00 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5JGG0Qr021624 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 19 Jun 2012 09:16:00 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 19 Jun 2012 09:16:00 -0700 From: "Templin, Fred L" To: Washam Fan Date: Tue, 19 Jun 2012 09:15:58 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1N3ygEms9c4ytjSByeaLrArtpj0gAU3XGQ Message-ID: References: <201205231245.q4NCj1X27445@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jun 2012 16:16:04 -0000 Hi Washam, Thanks for the continued discussion, and see below: > -----Original Message----- > From: Washam Fan [mailto:washam.fan@gmail.com] > Sent: Monday, June 18, 2012 10:48 PM > To: Templin, Fred L > Cc: fred@cisco.com; v6ops@ietf.org; draft-generic-v6ops- > tunmtu@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > Hi Fred, >=20 > We've discussed before in this link > http://www.ietf.org/mail-archive/web/v6ops/current/msg13206.html > I've read the section 4, -04 version. I noticed only clause 1) bullet > 1) trigger PTB messages. Yes, that is correct. But, the tunnel ingress has no way of assuring that the PTB will be delivered all the way back to the original source. > Should it not better to let clause 1) bullet > 2 and clause 2) also trigger PTB messages expecting PMTU works and > subsequent arriving packets just fit in the tunnel MTU? Clause 1) bullet 2 is about fragmentable packets, and is not a case where a PTB should be returned. The clause ensures that the fragmentable packets get through by fragmenting them to a still smaller size so that they will not encounter a restricting link on the way to the final destination (where they will be reassembled). Clause 2) is the controversial portion of the proposal. The goal is to ensure that 1500 and smaller packets get through to the final destination even if a small amount of fragmentation is necessary and without returning a PTB (which again cannot be assured to be delivered to the original source). In that case, it is the tunnel ingress and not the original source that supplies the Identification value. This is all to meet the expectation of source hosts that 1500 or smaller packets will be delivered to the destination, but there are no such assurances for 1501 or larger packets. For those, the source host should use RFC4821. It might be a good idea for me to add some words to this effect in the next document version. Thanks - Fred fred.l.templin@boeing.com > Thanks, > washam >=20 > 2012/5/23 Templin, Fred L : > > Please review and comment on 'draft-generic-v6ops-tunmtu': > > > > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ > > > > This new document takes the radical approach of proposing > > IPv6 router fragmentation at the tunnel ingress so that > > the tunnel MTU can be jacked up to 1500 bytes. > > > > The document notes issues that arise when the IPv6 router > > performs fragmentation - most notably, the selection of > > the Identification value to place in the (router-inserted) > > fragmentation header. > > > > Please review and comment on this thread. Remember that > > this approach is proposing something new and different > > and should be discussed further on the list. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > >> fred@cisco.com > >> Sent: Wednesday, May 23, 2012 5:45 AM > >> To: v6ops@ietf.org > >> Cc: draft-generic-v6ops-tunmtu@tools.ietf.org > >> Subject: [v6ops] new draft: draft-generic-v6ops-tunmtu > >> > >> > >> A new draft has been posted, at http://tools.ietf.org/html/draft- > generic- > >> v6ops-tunmtu. 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 From Fred.L.Templin@boeing.com Tue Jun 19 09:23: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 43C7211E80AE for ; Tue, 19 Jun 2012 09:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.059, 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 4QIVRIdDl6-e for ; Tue, 19 Jun 2012 09:23:14 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 45D0A21F8541 for ; Tue, 19 Jun 2012 09:23:14 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5JGNDRd028662 for ; Tue, 19 Jun 2012 11:23:13 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5JGNBB7028653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Jun 2012 11:23:12 -0500 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5JGNBC6010651; Tue, 19 Jun 2012 09:23:11 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5JGNAVu010640 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 19 Jun 2012 09:23:11 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 19 Jun 2012 09:23:10 -0700 From: "Templin, Fred L" To: Washam Fan Date: Tue, 19 Jun 2012 09:23:10 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1N3/bibLcAP91cRWCHm6PESuxZ4AAVuD9A Message-ID: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> <78EEAF0D-B3E1-48FB-91A2-7D5E8894D81C@cisco.com> <867F4B6A1672E541A94676D556793ACD149E83662A@MOPESMBX01.eu.thmulti.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-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jun 2012 16:23:16 -0000 Hi Washam, > -----Original Message----- > From: Washam Fan [mailto:washam.fan@gmail.com] > Sent: Monday, June 18, 2012 10:54 PM > To: Templin, Fred L > Cc: Wuyts Carl; Fred Baker; v6ops@ietf.org WG; draft-generic-v6ops- > tunmtu@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > Hi Fred, >=20 > 2012/6/19 Templin, Fred L : > > Hi Carl, > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > >> Wuyts Carl > >> Sent: Monday, June 18, 2012 4:52 AM > >> To: Fred Baker; v6ops@ietf.org WG > >> Cc: draft-generic-v6ops-tunmtu@tools.ietf.org > >> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu > >> > >> Hi Fred, > >> > >> I thought the target of the v6ops was to avoid these kind of things, > and > >> promote proper IPv6 packet handling. =A0After all, it is promoted from > the > >> start, that IPv6 brings you some extra things, like fixed header size, > no > >> more fragmentation (only at host), a MANDATORY PMTU (while for v4 it > was > >> only added AFTER the protocol was there), .... =A0Now I read in this > draft > >> to start doing some fragmentation with inner/outer, whatever, headers > etc > >> ?? > > > > IPv6 fixes fragmentation and reassembly by virtue of the > > extended Identification field. I think that legislating IPv6 > > fragmentation out of the network was a well-intentioned mistake > > that was heavily influenced by earlier works including the 1987 > > "Fragmentation Considered Harmful". That work was published a > > long time ago and made valid points, but many of the assumptions > > and issues it documented no longer apply. >=20 > I think this issue is the only concern for me on this draft. the draft > explicitly says it *ignore* the requirement that router can't fragment > ipv6 packets enroute. If we would've had an agreement that this > requirement was a mistake, should we first update rfc2460 and then > persuit this draft? That is indeed an interesting point. I believe there were at least two factors that led to the omission of network fragmentation in IPv6: 1) that including a 32-bit Identification value and 16-bit fragmentation control field on each packet would add excessive overhead to the already-large IPv6 header 2) that the IPv6 header was already aligned on a nice quad-word boundary, and so adding one more field to the header would necessitate adding at least 8 more bytes, making the header 48bytes instead of 40. I don't know, but I suspect the 40byte IPv6 header is burned into far too much silicon at this point to consider retro-fitting to a 48byte header. But, maybe others have ideas on this. Thanks - Fred fred.l.templin@boeing.com > Thanks, > washam >=20 > >> First of all, the "all links are 1500" statement is correct for > Ethernet- > >> based networks, but as I'm working for a company dealing with DSL, thi= s > is > >> not always the case, so don't take it for granted. =A0Moreover, CPE wi= ll > be > >> heavily involved in this (6rd etc). > >> Secondly, if ICMPv6 PTB messages gets filtered out (by some wrongly > >> configured firewall or any other device) then it should be fixed where > it > >> goes wrong, not work-around it. =A0You're replacing a wrong filter wit= h > some > >> complex mechanism of fragmentation. =A0Why is this filter in place ? > >> Third, I see the definition of an "atomic" packet, but that's quite > some > >> assumption to be made for IPv6 packets. > > > > We're not trying to say that all links are 1500 - only that > > 1500 is the minimum path MTU that most hosts expect to see > > unless they connect directly to a sub-1500 link. What we > > would like to get to is support for MTU diversity so that > > whatever link MTUs occur in the path can be naturally > > accommodated. > > > >> Just for the record. =A0Our CPE can do fragmentation, so that's not an > >> issue, but we'd like to avoid this becoming normal mode of operation, > to > >> avoid lots of potential issues with it. =A0Moreover, what's next ? > > > > I don't think anything is next necessarily, other than > > migration to links with larger MTUs. The choices for the > > CPE are to either hope that the network delivers the > > necessary PTB messages or to take matters into its own > > hands and perform a little bit of fragmentation. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> regs > >> Carl Wuyts > >> > >> > >> > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > >> Fred Baker > >> Sent: maandag 18 juni 2012 13:20 > >> To: v6ops@ietf.org WG > >> Cc: draft-generic-v6ops-tunmtu@tools.ietf.org > >> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu > >> > >> > >> On Jun 12, 2012, at 3:50 PM, Templin, Fred L wrote: > >> > >> > Hi, > >> > > >> > This document has now been updated to address issues raised on the > >> > list and to expand on the roles of inner fragmentation before > >> > encapsulation and outer fragmentation after encapsulation. The answe= r > >> > is that inner is needed in certain use cases, outer is needed in > >> > certain others and both are needed in still yet others. > >> > > >> > The latest draft is now available here: > >> > > >> > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ > >> > > >> > Can we talk about this during the v6ops session at the Vancouver > >> > meeting? > >> > >> I have seen comments on-list from Daniel Roesen, Mark Andrews, and > Washam > >> Fan. In each case, they have commented on the draft without saying > whether > >> they think it is a valuable working group output, which I take quite > >> literally - I don't know their opinion. > >> > >> Working group, is this draft something you would like to discuss? > >> > >> > Thanks - Fred > >> > fred.l.templin@boeing.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 > >> _______________________________________________ > >> 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 gert@space.net Tue Jun 19 11:50: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 E54E821F861A for ; Tue, 19 Jun 2012 11:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNTrXhCrvY2E for ; Tue, 19 Jun 2012 11:50:40 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id E9A8E21F860E for ; Tue, 19 Jun 2012 11:50:38 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 22763F8BDC for ; Tue, 19 Jun 2012 20:50:37 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 01C1CF8BD9 for ; Tue, 19 Jun 2012 20:50:37 +0200 (CEST) Received: (qmail 96132 invoked by uid 1007); 19 Jun 2012 20:50:36 +0200 Date: Tue, 19 Jun 2012 20:50:36 +0200 From: Gert Doering To: "Templin, Fred L" Message-ID: <20120619185036.GB38127@Space.Net> References: <867F4B6A1672E541A94676D556793ACD149E83662A@MOPESMBX01.eu.thmulti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jun 2012 18:50:41 -0000 Hi, On Tue, Jun 19, 2012 at 09:23:10AM -0700, Templin, Fred L wrote: > I don't know, but I suspect the 40byte IPv6 header is > burned into far too much silicon at this point to > consider retro-fitting to a 48byte header. But, maybe > others have ideas on this. Incompatible changes to the packet format are right out - if you do that, what little IPv6 deployment we have achieved so far is all dead. 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 Fred.L.Templin@boeing.com Tue Jun 19 12:26: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 2A28011E814A for ; Tue, 19 Jun 2012 12:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 dOslPMMGPtpY for ; Tue, 19 Jun 2012 12:26:35 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 93C3B11E8144 for ; Tue, 19 Jun 2012 12:26:35 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5JJQU9C003002 for ; Tue, 19 Jun 2012 12:26:31 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5JJQTCM002970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Jun 2012 12:26:29 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5JJQXvQ031754; Tue, 19 Jun 2012 12:26:33 -0700 Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5JJQWVn031739 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 19 Jun 2012 12:26:33 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 19 Jun 2012 12:26:32 -0700 From: "Templin, Fred L" To: Gert Doering Date: Tue, 19 Jun 2012 12:26:30 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1OTHSIvgAbJ0vmSxCYDgDD0GkVlwABH3lw Message-ID: References: <867F4B6A1672E541A94676D556793ACD149E83662A@MOPESMBX01.eu.thmulti.com> <20120619185036.GB38127@Space.Net> In-Reply-To: <20120619185036.GB38127@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jun 2012 19:26:36 -0000 > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Tuesday, June 19, 2012 11:51 AM > To: Templin, Fred L > Cc: Washam Fan; draft-generic-v6ops-tunmtu@tools.ietf.org; v6ops@ietf.org > WG > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > Hi, >=20 > On Tue, Jun 19, 2012 at 09:23:10AM -0700, Templin, Fred L wrote: > > I don't know, but I suspect the 40byte IPv6 header is > > burned into far too much silicon at this point to > > consider retro-fitting to a 48byte header. But, maybe > > others have ideas on this. >=20 > Incompatible changes to the packet format are right out - if you do that, > what little IPv6 deployment we have achieved so far is all dead. I tend to agree, and a quick check shows that in-the-network fragmentation was left out of the design from the very earliest days going back to the SIPP proposal in the 1993/94 timeframe. If anyone has references to earlier works and decision points on this issue I'd be interested to see them. Thanks - Fred > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > 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 washam.fan@gmail.com Tue Jun 19 20:02: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 5306511E8097 for ; Tue, 19 Jun 2012 20:02:38 -0700 (PDT) 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 cAT84w3+gpM8 for ; Tue, 19 Jun 2012 20:02:37 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F353811E808E for ; Tue, 19 Jun 2012 20:02:36 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4801554wgb.13 for ; Tue, 19 Jun 2012 20:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NAgDPXXISX2lMaAcGsK5oK3d0MKBkJEODnkg2QDELzM=; b=GOJBws+wR+gu6IWGVP/jL0MDyBzGUH7M6O1oG0C2Fs8inrj62ZrXrEo7eitkTzCi00 qwNp0cSM2vgQf+X5I3a5bcUvevyaRPAP9ZwIj1QQxoaIJs/ZcOkzBOK+yamun4RLz8hN Gsgkp8+C4tz+XQQtf3TznB3L8vr9eJBBqscG8+ftQBvmmt58i6XGXuyJZ/r/DJB1DmAF c2TxpI59jL7+AyexFBzHAauBVOHtwtLi+KJbtad0lnzq5p7zEJN5TC87D2gVr4HcNRlf iaRs4qRJ9KXqYLovjYwbhw4nzg60H1X0S9rAa9+zxQ+g0DqgoswkFoZvnOuZlxDY11CO tyLA== MIME-Version: 1.0 Received: by 10.216.226.136 with SMTP id b8mr1732032weq.152.1340161355767; Tue, 19 Jun 2012 20:02:35 -0700 (PDT) Received: by 10.216.81.138 with HTTP; Tue, 19 Jun 2012 20:02:35 -0700 (PDT) In-Reply-To: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> Date: Wed, 20 Jun 2012 11:02:35 +0800 Message-ID: From: Washam Fan To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Jun 2012 03:02:38 -0000 Hi Fred, 2012/6/20 Templin, Fred L : > Hi Washam, > > Thanks for the continued discussion, and see below: > >> -----Original Message----- >> From: Washam Fan [mailto:washam.fan@gmail.com] >> Sent: Monday, June 18, 2012 10:48 PM >> To: Templin, Fred L >> Cc: fred@cisco.com; v6ops@ietf.org; draft-generic-v6ops- >> tunmtu@tools.ietf.org >> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >> >> Hi Fred, >> >> We've discussed before in this link >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13206.html >> I've read the section 4, -04 version. I noticed only clause 1) bullet >> 1) trigger PTB messages. > > Yes, that is correct. But, the tunnel ingress has no way > of assuring that the PTB will be delivered all the way > back to the original source. > >> Should it not better to let clause 1) bullet >> 2 and clause 2) also trigger PTB messages expecting PMTU works and >> subsequent arriving packets just fit in the tunnel MTU? > > Clause 1) bullet 2 is about fragmentable packets, and > is not a case where a PTB should be returned. The clause > ensures that the fragmentable packets get through by > fragmenting them to a still smaller size so that they > will not encounter a restricting link on the way to the > final destination (where they will be reassembled). OK. I see. > Clause 2) is the controversial portion of the proposal. > The goal is to ensure that 1500 and smaller packets get > through to the final destination even if a small amount > of fragmentation is necessary and without returning a > PTB (which again cannot be assured to be delivered to > the original source). Right. If a PTB is returned, it is probably blocked or ignored, but it probably also be seen by the original source. In the latter case, the subsequent packages from the original source would fit in 1280 and tunnel ingress no need to fragment afterward. Thanks, washam > In that case, it is the tunnel > ingress and not the original source that supplies the > Identification value. > This is all to meet the expectation of source hosts > that 1500 or smaller packets will be delivered to the > destination, but there are no such assurances for 1501 > or larger packets. For those, the source host should > use RFC4821. It might be a good idea for me to add > some words to this effect in the next document version. > > Thanks - Fred > fred.l.templin@boeing.com > >> Thanks, >> washam >> >> 2012/5/23 Templin, Fred L : >> > Please review and comment on 'draft-generic-v6ops-tunmtu': >> > >> > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ >> > >> > This new document takes the radical approach of proposing >> > IPv6 router fragmentation at the tunnel ingress so that >> > the tunnel MTU can be jacked up to 1500 bytes. >> > >> > The document notes issues that arise when the IPv6 router >> > performs fragmentation - most notably, the selection of >> > the Identification value to place in the (router-inserted) >> > fragmentation header. >> > >> > Please review and comment on this thread. Remember that >> > this approach is proposing something new and different >> > and should be discussed further on the list. >> > >> > Thanks - Fred >> > fred.l.templin@boeing.com >> > >> >> -----Original Message----- >> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of >> >> fred@cisco.com >> >> Sent: Wednesday, May 23, 2012 5:45 AM >> >> To: v6ops@ietf.org >> >> Cc: draft-generic-v6ops-tunmtu@tools.ietf.org >> >> Subject: [v6ops] new draft: draft-generic-v6ops-tunmtu >> >> >> >> >> >> A new draft has been posted, at http://tools.ietf.org/html/draft- >> generic- >> >> v6ops-tunmtu. 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 From Tina.Tsou.Zouting@huawei.com Tue Jun 19 20:16: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 D11A211E80E3 for ; Tue, 19 Jun 2012 20:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 rpEzcJP0H0hn for ; Tue, 19 Jun 2012 20:16:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 116F211E808E for ; Tue, 19 Jun 2012 20:16:27 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHI56439; Tue, 19 Jun 2012 23:16:26 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 19 Jun 2012 20:15:10 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.109]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Tue, 19 Jun 2012 20:15:05 -0700 From: Tina TSOU To: IPv6 Operations Thread-Topic: New Version Notification for draft-lopez-v6ops-dc-ipv6-02.txt Thread-Index: AQHNTo2WH+IwP5C39UO+HhZ+DyESLpcCiDuw Date: Wed, 20 Jun 2012 03:15:05 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.66] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] FW: New Version Notification for draft-lopez-v6ops-dc-ipv6-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, 20 Jun 2012 03:16:27 -0000 Rm9yIHlvdXIgcmVhZGluZyBwbGVhc3VyZSBhbmQgY29tbWVudHMuDQpodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sb3Blei12Nm9wcy1kYy1pcHY2LTAyLnR4dA0KDQpU aW5hDQpAIDIwMDE6ZGI4OjE6ZmZmZjplOGUyOjc4MjI6OWQxMjplMTJlDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwgSnVuZSAxOSwgMjAxMiA3 OjM3IFBNDQpUbzogWmhvdXFpYW4gKENhdGh5KQ0KQ2M6IFRpbmEgVFNPVTsgZGllZ29AdGlkLmVz OyAxODkxODU4ODg5N0AxODkuY24NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtbG9wZXotdjZvcHMtZGMtaXB2Ni0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtbG9wZXotdjZvcHMtZGMtaXB2Ni0wMi50eHQNCmhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgQ2F0aHkgWmhvdSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBv c2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWxvcGV6LXY2b3BzLWRjLWlwdjYNClJldmlzaW9u OgkgMDINClRpdGxlOgkJIEEgUmVmZXJlbmNlIEZyYW1ld29yayBmb3IgREMgTWlncmF0aW9uIHRv IElQdjYNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTA2LTE5DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTMNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbG9wZXotdjZvcHMtZGMtaXB2Ni0wMi50 eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1sb3Blei12Nm9wcy1kYy1pcHY2DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWxvcGV6LXY2b3BzLWRjLWlwdjYtMDINCkRpZmY6ICAgICAgICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1sb3Blei12Nm9wcy1kYy1p cHY2LTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBwcm92 aWRlIGEgcmVmZXJlbmNlIGZyYW1ld29yayBmb3INCiAgIGRhdGFjZW50ZXIgb3BlcmF0b3JzIHBs YW5uaW5nIGZvciBhIG1pZ3JhdGlvbiBvZiB0aGVpcg0KICAgaW5mcmFzdHJ1Y3R1cmVzIHRvIElQ djYuICBJdCBhaW1zIHRvIG9mZmVyIGEgc2NoZW1lIGZvciBldmFsdWF0aW5nDQogICBkaWZmZXJl bnQgcHJvZHVjdHMgYW5kIGFyY2hpdGVjdHVyZXMsIGFuZCB0aGVyZWZvcmUgaXQgaXMgYWxzbw0K ICAgYWRkcmVzc2VkIHRvIG1hbnVmYWN0dXJlcnMgYW5kIHNvbHV0aW9uIHByb3ZpZGVycywgc28g dGhleSBjYW4gdXNlIGl0DQogICB0byBnYXVnZSB0aGVpciBzb2x1dGlvbnMuICBXZSBiZWxpZXZl IHRoaXMgd2lsbCB0cmFuc2xhdGUgaW4gYQ0KICAgc21vb3RoZXIgYW5kIGZhc3RlciB0cmFuc2l0 aW9uIG9mIHRoZXNlIGluZnJhc3R1Y3R1cmVzIGludG8gSVB2Ng0KDQogICBUaGUgZG9jdW1lbnQg Zm9jdXNlcyBvbiB0aGUgREMgaW5mcmFzdHJ1Y3R1cmUgaXRzZWxmLCBpdHMgb3BlcmF0aW9uLA0K ICAgYW5kIHRoZSBhc3BlY3RzIHJlbGF0ZWQgdG8gREMgaW50ZXJjb25uZWN0aW9uIHRocm91Z2gg SVB2Ni4gIEl0IGRvZXMNCiAgIG5vdCBjb25zaWRlciB0aGUgcGFydGljdWxhciBtZWNoYW5pc21z IGZvciBtYWtpbmcgSW50ZXJuZXQgc2VydmljZXMNCiAgIHByb3ZpZGVkIGJ5IGFwcGxpY2F0aW9u cyBob3N0ZWQgaW4gdGhlIERDIGF2YWlsYWJsZSB0aHJvdWdoIElQdjYNCiAgIGJleW9uZCB0aGUg c3BlY2lmaWMgYXNwZWN0cyByZWxhdGVkIHRvIGhvdyB0aGVpciBkZXBsb3ltZW50IG9uIHRoZSBE Qw0KICAgaW5mcmFzdHJ1Y3R1cmUuDQoNCiAgIEFwYXJ0IGZyb20gZmFjaWxpdGF0aW5nIHRoZSBt aWdyYXRpb24gcHJvY2VkdXJlIGl0c2VsZiwgdGhlDQogICBtZWNoYW5pc21zIG91dGxpbmVkIGhl cmUgYXJlIGludGVuZGVkIHRvIG1ha2UgdGhpcyBtaWdyYXRpb24gYXMNCiAgIHRyYW5zcGFyZW50 IGFzIHBvc3NpYmxlIChpZiBub3QgY29tcGxldGVseSB0cmFuc3BhcmVudCkgdG8NCiAgIGFwcGxp Y2F0aW9ucyBhbmQgc2VydmljZXMgcnVubmluZyBvbiB0aGUgREMgaW5mcmFzdHJ1Y3R1cmUsIGFz IHdlbGwNCiAgIGFzIHRvIHRha2UgYWR2YW50YWdlIG9mIElQdjYgZmVhdHVyZXMgdG8gc2ltcGxp ZnkgREMgb3BlcmF0aW9ucywNCiAgIGludGVybmFsbHkgYW5kIGFjcm9zcyB0aGUgSW50ZXJuZXQu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From Fred.L.Templin@boeing.com Wed Jun 20 09: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 7929D21F877C for ; Wed, 20 Jun 2012 09:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.007, 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 6jeD81lV9cP1 for ; Wed, 20 Jun 2012 09:45:00 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id C095C21F8639 for ; Wed, 20 Jun 2012 09:45:00 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5KGixdI008110 for ; Wed, 20 Jun 2012 09:45:00 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5KGiwZI008081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Jun 2012 09:44:59 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5KGiwwG022933; Wed, 20 Jun 2012 09:44:58 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5KGiwAY022929 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 20 Jun 2012 09:44:58 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 20 Jun 2012 09:44:58 -0700 From: "Templin, Fred L" To: Washam Fan Date: Wed, 20 Jun 2012 09:44:49 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1OkSdwVM4a2h8ZS72uoe3/wXaf0QAbaFfA Message-ID: References: <201205231245.q4NCj1X27445@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Jun 2012 16:45:01 -0000 Hi Washam, > -----Original Message----- > From: Washam Fan [mailto:washam.fan@gmail.com] > Sent: Tuesday, June 19, 2012 8:03 PM > To: Templin, Fred L > Cc: fred@cisco.com; v6ops@ietf.org; draft-generic-v6ops- > tunmtu@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > Hi Fred, >=20 > 2012/6/20 Templin, Fred L : > > Hi Washam, > > > > Thanks for the continued discussion, and see below: > > > >> -----Original Message----- > >> From: Washam Fan [mailto:washam.fan@gmail.com] > >> Sent: Monday, June 18, 2012 10:48 PM > >> To: Templin, Fred L > >> Cc: fred@cisco.com; v6ops@ietf.org; draft-generic-v6ops- > >> tunmtu@tools.ietf.org > >> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu > >> > >> Hi Fred, > >> > >> We've discussed before in this link > >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13206.html > >> I've read the section 4, -04 version. I noticed only clause 1) bullet > >> 1) trigger PTB messages. > > > > Yes, that is correct. But, the tunnel ingress has no way > > of assuring that the PTB will be delivered all the way > > back to the original source. > > > >> Should it not better to let clause 1) bullet > >> 2 and clause 2) also trigger PTB messages expecting PMTU works and > >> subsequent arriving packets just fit in the tunnel MTU? > > > > Clause 1) bullet 2 is about fragmentable packets, and > > is not a case where a PTB should be returned. The clause > > ensures that the fragmentable packets get through by > > fragmenting them to a still smaller size so that they > > will not encounter a restricting link on the way to the > > final destination (where they will be reassembled). >=20 > OK. I see. OK. > > Clause 2) is the controversial portion of the proposal. > > The goal is to ensure that 1500 and smaller packets get > > through to the final destination even if a small amount > > of fragmentation is necessary and without returning a > > PTB (which again cannot be assured to be delivered to > > the original source). >=20 > Right. If a PTB is returned, it is probably blocked or ignored, but it > probably also be seen by the original source. In the latter case, the > subsequent packages from the original source would fit in 1280 and > tunnel ingress no need to fragment afterward. OK - so, the tunnel ingress should both send the packet *and* also return a PTB? That's a very interesting idea and sounds OK on the surface. But, the source host upon receiving the PTB is going to reduce its packet sizes to 1280 even if the tunnel is configured over all-9KB links, i.e., the Clause 1 case would never be met. There is also another consideration with clauses 2 and 3. If there will be nested encapsulations on the path between the tunnel ingress and egress then even a 1280 packet may be too big to enter another tunnel ingress on the path. So we should leave extra room for additional encapsulations and change clauses 2 and 3 to: 2) if the packet is between 1025 - 1500: - break the packet into 2 pieces (where each piece is a random length between 500-1000 bytes) and admit each piece into the tunnel. 3) if the packet is 1024 or less: - admit the packet into the tunnel That said, we could use an adaptation of your idea and change clause 2 to: 2) if the packet is between 1025 - 1500: - break the packet into 2 pieces (where each piece is a random length between 500-1000 bytes), admit each piece into the tunnel and return a PTB message with MTU=3D1024. Then, when the source host receives the PTB, it will honor the final paragraph of RFC2460, Section 5 and begin inserting a fragment header in the packets it sends. The tunnel ingress can then use the Id value in the fragment header when performing fragmentation. What do you think? Fred fred.l.templin@boeing.com=20 > Thanks, > washam >=20 > > In that case, it is the tunnel > > ingress and not the original source that supplies the > > Identification value. >=20 >=20 > > This is all to meet the expectation of source hosts > > that 1500 or smaller packets will be delivered to the > > destination, but there are no such assurances for 1501 > > or larger packets. For those, the source host should > > use RFC4821. It might be a good idea for me to add > > some words to this effect in the next document version. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> Thanks, > >> washam > >> > >> 2012/5/23 Templin, Fred L : > >> > Please review and comment on 'draft-generic-v6ops-tunmtu': > >> > > >> > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ > >> > > >> > This new document takes the radical approach of proposing > >> > IPv6 router fragmentation at the tunnel ingress so that > >> > the tunnel MTU can be jacked up to 1500 bytes. > >> > > >> > The document notes issues that arise when the IPv6 router > >> > performs fragmentation - most notably, the selection of > >> > the Identification value to place in the (router-inserted) > >> > fragmentation header. > >> > > >> > Please review and comment on this thread. Remember that > >> > this approach is proposing something new and different > >> > and should be discussed further on the list. > >> > > >> > Thanks - Fred > >> > fred.l.templin@boeing.com > >> > > >> >> -----Original Message----- > >> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf > >> Of > >> >> fred@cisco.com > >> >> Sent: Wednesday, May 23, 2012 5:45 AM > >> >> To: v6ops@ietf.org > >> >> Cc: draft-generic-v6ops-tunmtu@tools.ietf.org > >> >> Subject: [v6ops] new draft: draft-generic-v6ops-tunmtu > >> >> > >> >> > >> >> A new draft has been posted, at http://tools.ietf.org/html/draft- > >> generic- > >> >> v6ops-tunmtu. 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 From touch@isi.edu Wed Jun 20 16:07: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 3603421F8570 for ; Wed, 20 Jun 2012 16:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.456 X-Spam-Level: X-Spam-Status: No, score=-103.456 tagged_above=-999 required=5 tests=[AWL=-0.857, 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 ZYyCWGBAnVGE for ; Wed, 20 Jun 2012 16:07:47 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB1321F8573 for ; Wed, 20 Jun 2012 16:07:47 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q5KN7DuZ009965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jun 2012 16:07:13 -0700 (PDT) Message-ID: <4FE257A1.7070608@isi.edu> Date: Wed, 20 Jun 2012 16:07:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Jun 2012 23:07:48 -0000 > Please review and comment on 'draft-generic-v6ops-tunmtu': > > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ > > This new document takes the radical approach of proposing > IPv6 router fragmentation at the tunnel ingress so that > the tunnel MTU can be jacked up to 1500 bytes. > > The document notes issues that arise when the IPv6 router > performs fragmentation - most notably, the selection of > the Identification value to place in the (router-inserted) > fragmentation header. Hi, all, This draft was recently brought to my attention in a discussion on the main IETF list. This doc's premise is badly flawed: Even assuming the pending draft-ietf-intarea-ipv4-id-update-05, it is impossible to overwrite the DF and ID of inner IPv4 datagrams in a way that makes fragmentation usefully safe. Consider: A. non-atomic datagram fragments that enter the ingress B. non-atomic datagrams that have not yet been fragmented, but that this ingress needs to fragment C. non-atomic datagram fragments that reach the destination but do not use the tunnel at all The IDs that the ingress overwrites CANNOT use IDs that are used by any of (A), (B), or (C). (B) can be avoided by overwriting those IDs too. (A) requires the ingress keep track of the IDs seen and avoid using them for 2MSL. IDs used by (C) aren't seen at all - and thus cannot be avoided. Keep in mind that (C) could also be the result of one of the proposed tunnels from this draft on a different path in the network. So (A) and (B) make this complex, and (C) makes it impossible. I.e., the result of inserting your own IDs into someone else's packets is that you could corrupt reassembly at the destination, and you can't know when that will happen. ---- I have stated before many times that tunnels must clean up the mess they create. The only viable path for a tunnel that receives a DF=1 datagram is to generate fragments in the outer header, and reassemble them at the egress. Joe From washam.fan@gmail.com Wed Jun 20 22:03: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 0CAD921F8620 for ; Wed, 20 Jun 2012 22:03:48 -0700 (PDT) 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 qJBPDWz-mzlj for ; Wed, 20 Jun 2012 22:03:46 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB3E21F858D for ; Wed, 20 Jun 2012 22:03:45 -0700 (PDT) Received: by bkty8 with SMTP id y8so169550bkt.31 for ; Wed, 20 Jun 2012 22:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yxebbvojvG3owpq1cUEajjGoX7jxFVvsbpRSlPg1T+4=; b=dAOtLh9Rs7MMGRxppjYpePpUvDVnbIb6btdixam4GGv84tLUQ9Z5lVko2xbdut3tNs hkIEAn82BjCJA75L0MbOex4xZ+yDBbZDzJvTfP499ev+3h2Ok4LCSIqxVURoOcmdUhF9 RgrZdpiBeqtcH9XnmmJ3zAJ2ysQKMyK803demmJ51rUvGwzm6lI6W0BApvESuJtixfAO JYrQ18Xg0y5iZ50z4QGETo/I/d6GuAxwj3Eg1DhztVaFpitOrnfTWORqTBCpWg1tWvAN fUOVSqdE/7Dz36QtvRu0iu9I3S4s5bBjGe3qapgZDtwNVks3KeaETJabsQKuG07rk9s0 ikmA== MIME-Version: 1.0 Received: by 10.204.150.72 with SMTP id x8mr11662682bkv.33.1340255023619; Wed, 20 Jun 2012 22:03:43 -0700 (PDT) Received: by 10.204.169.193 with HTTP; Wed, 20 Jun 2012 22:03:43 -0700 (PDT) In-Reply-To: References: <201205231245.q4NCj1X27445@ftpeng-update.cisco.com> Date: Thu, 21 Jun 2012 13:03:43 +0800 Message-ID: From: Washam Fan To: "Templin, Fred L" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-generic-v6ops-tunmtu@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Jun 2012 05:03:48 -0000 Hi Fred, I think it might be better to discuss this issue by introducing tunnel MTU. See inline for details. >> > Clause 2) is the controversial portion of the proposal. >> > The goal is to ensure that 1500 and smaller packets get >> > through to the final destination even if a small amount >> > of fragmentation is necessary and without returning a >> > PTB (which again cannot be assured to be delivered to >> > the original source). >> >> Right. If a PTB is returned, it is probably blocked or ignored, but it >> probably also be seen by the original source. In the latter case, the >> subsequent packages from the original source would fit in 1280 and >> tunnel ingress no need to fragment afterward. > > OK - so, the tunnel ingress should both send the packet > *and* also return a PTB? That's a very interesting idea > and sounds OK on the surface. But, the source host upon > receiving the PTB is going to reduce its packet sizes > to 1280 even if the tunnel is configured over all-9KB > links, i.e., the Clause 1 case would never be met. Why not we return a PTB >=3D tunnel MTU instead of 1280? if the tunnel is over all 9kB links, all tunnelled packets would be fit in the tunnel without fragmentation, because now the tunnel MTU is 9kB minus the encapsulation header (which is very smaller compared to 9kB) In a case where ipv6 packets transmitted over ipv4 network, the tunnel MTU would be 1480 =3D 1500 - 20 (the lengh of ipv4 header without options). Then 1. any packets whose length exceeds 1500, drop the packets and return PTB>= =3D1480 2. any packets whose length is between 1480 and 1500, fragment the packets and return PTB>=3D1480 3. any packets whose length is under 1480, transmit without fragments > There is also another consideration with clauses 2 and 3. > If there will be nested encapsulations on the path between > the tunnel ingress and egress then even a 1280 packet may > be too big to enter another tunnel ingress on the path. So > we should leave extra room for additional encapsulations > and change clauses 2 and 3 to: if netsted encapsulations case is considered, the tunnel MTU would be 1500 - 20 - additional costs > =A0 =A0 2) if the packet is between 1025 - 1500: > =A0 =A0 =A0 =A0- break the packet into 2 pieces (where each piece > =A0 =A0 =A0 =A0 =A0is a random length between 500-1000 bytes) and > =A0 =A0 =A0 =A0 =A0admit each piece into the tunnel. > > =A0 =A0 3) if the packet is 1024 or less: > =A0 =A0 =A0 =A0- admit the packet into the tunnel In the above case, 1025 would be tunnel MTU (which is under 1280) > That said, we could use an adaptation of your idea and > change clause 2 to: > > =A0 =A0 2) if the packet is between 1025 - 1500: > =A0 =A0 =A0 =A0- break the packet into 2 pieces (where each piece > =A0 =A0 =A0 =A0 =A0is a random length between 500-1000 bytes), admit > =A0 =A0 =A0 =A0 =A0each piece into the tunnel and return a PTB > =A0 =A0 =A0 =A0 =A0message with MTU=3D1024. > > Then, when the source host receives the PTB, it will > honor the final paragraph of RFC2460, Section 5 and > begin inserting a fragment header in the packets it > sends. The tunnel ingress can then use the Id value > in the fragment header when performing fragmentation. Yes. if the tunnel MTU is under 1280, the above statement would be valid. > What do you think? What do you think ? Thanks, washam > fred.l.templin@boeing.com > > >> Thanks, >> washam >> >> > In that case, it is the tunnel >> > ingress and not the original source that supplies the >> > Identification value. >> >> >> > This is all to meet the expectation of source hosts >> > that 1500 or smaller packets will be delivered to the >> > destination, but there are no such assurances for 1501 >> > or larger packets. For those, the source host should >> > use RFC4821. It might be a good idea for me to add >> > some words to this effect in the next document version. >> > >> > Thanks - Fred >> > fred.l.templin@boeing.com >> > >> >> Thanks, >> >> washam >> >> >> >> 2012/5/23 Templin, Fred L : >> >> > Please review and comment on 'draft-generic-v6ops-tunmtu': >> >> > >> >> > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ >> >> > >> >> > This new document takes the radical approach of proposing >> >> > IPv6 router fragmentation at the tunnel ingress so that >> >> > the tunnel MTU can be jacked up to 1500 bytes. >> >> > >> >> > The document notes issues that arise when the IPv6 router >> >> > performs fragmentation - most notably, the selection of >> >> > the Identification value to place in the (router-inserted) >> >> > fragmentation header. >> >> > >> >> > Please review and comment on this thread. Remember that >> >> > this approach is proposing something new and different >> >> > and should be discussed further on the list. >> >> > >> >> > Thanks - Fred >> >> > fred.l.templin@boeing.com >> >> > >> >> >> -----Original Message----- >> >> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On >> Behalf >> >> Of >> >> >> fred@cisco.com >> >> >> Sent: Wednesday, May 23, 2012 5:45 AM >> >> >> To: v6ops@ietf.org >> >> >> Cc: draft-generic-v6ops-tunmtu@tools.ietf.org >> >> >> Subject: [v6ops] new draft: draft-generic-v6ops-tunmtu >> >> >> >> >> >> >> >> >> A new draft has been posted, at http://tools.ietf.org/html/draft- >> >> generic- >> >> >> v6ops-tunmtu. 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 From washam.fan@gmail.com Wed Jun 20 22:42: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 4FAD921F852A for ; Wed, 20 Jun 2012 22:42:59 -0700 (PDT) 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 UnVQFIgXXM-j for ; Wed, 20 Jun 2012 22:42:57 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4FD11E8083 for ; Wed, 20 Jun 2012 22:42:56 -0700 (PDT) Received: by bkty8 with SMTP id y8so188581bkt.31 for ; Wed, 20 Jun 2012 22:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/6hHzjSyC9WY2/O7qP/KeUGVyG4D7F2O5GuFmH0eNpU=; b=my/NYiWrkyNbbrC33W+Iei+Bbqt2OPIL/jJgyCiTTfrhWRGZKGnyre2EnruCmxmgIO vuf8r5dqGr/BahX4ZWY4Z0wCc9aTRPJ5H7abIo+/IxZDegqypoNxxrexiOy/CzOrO6Nm S0IJyVWmxnFPvN1Ols8zOH/LJzo+nJP6TPI5S83T+pBZa8oNQWOzNpObzVwr+ZnMp87f AwpYxEyO2twjxpCjXZd6oGYyZwwCnLce2vOaHjw7fTdHIDdplyr0oqvlbm8dfNJacQok kKNxp5RM6RI6khFAcRuMsz/EaMV2+aZXAZ0aeFIs/wC3uV9QuxJ/61ioBaXDo2Knqp3c 8AzA== MIME-Version: 1.0 Received: by 10.205.127.140 with SMTP id ha12mr11057013bkc.105.1340257370988; Wed, 20 Jun 2012 22:42:50 -0700 (PDT) Received: by 10.204.169.193 with HTTP; Wed, 20 Jun 2012 22:42:50 -0700 (PDT) In-Reply-To: <4FE257A1.7070608@isi.edu> References: <4FE257A1.7070608@isi.edu> Date: Thu, 21 Jun 2012 13:42:50 +0800 Message-ID: From: Washam Fan To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Jun 2012 05:42:59 -0000 Hi Joe, 2012/6/21 Joe Touch : >> Please review and comment on 'draft-generic-v6ops-tunmtu': >> >> https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ >> >> This new document takes the radical approach of proposing >> IPv6 router fragmentation at the tunnel ingress so that >> the tunnel MTU can be jacked up to 1500 bytes. >> >> The document notes issues that arise when the IPv6 router >> performs fragmentation - most notably, the selection of >> the Identification value to place in the (router-inserted) >> fragmentation header. > > > Hi, all, > > This draft was recently brought to my attention in a discussion on the ma= in > IETF list. This doc's premise is badly flawed: > > Even assuming the pending draft-ietf-intarea-ipv4-id-update-05, it is > impossible to overwrite the DF and ID of inner IPv4 datagrams in a way th= at > makes fragmentation usefully safe. Consider: > > =A0 =A0 =A0 =A0A. non-atomic datagram fragments that enter the ingress > > =A0 =A0 =A0 =A0B. non-atomic datagrams that have not yet been fragmented, > =A0 =A0 =A0 =A0but that this ingress needs to fragment > > =A0 =A0 =A0 =A0C. non-atomic datagram fragments that reach the destinatio= n > =A0 =A0 =A0 =A0but do not use the tunnel at all > > The IDs that the ingress overwrites CANNOT use IDs that are used by any o= f > (A), (B), or (C). (B) can be avoided by overwriting those IDs too. (A) > requires the ingress keep track of the IDs seen and avoid using them for > 2MSL. IDs used by (C) aren't seen at all - and thus cannot be avoided. > > Keep in mind that (C) could also be the result of one of the proposed > tunnels from this draft on a different path in the network. > > So (A) and (B) make this complex, and (C) makes it impossible. I.e., the > result of inserting your own IDs into someone else's packets is that you > could corrupt reassembly at the destination, and you can't know when that > will happen. > the last 2nd para, section 4 admits the exist of the collision, do you think the randomness assignment can not suffiently address this issue? > > I have stated before many times that tunnels must clean up the mess they > create. The only viable path for a tunnel that receives a DF=3D1 datagram= is > to generate fragments in the outer header, and reassemble them at the > egress. > Right. This way eliminate the fragment ID collision concern. But this draft is to avoid reassemble at egress. Thanks, washam > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Thu Jun 21 02:01: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 F352121F8459 for ; Thu, 21 Jun 2012 02:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.382 X-Spam-Level: X-Spam-Status: No, score=-100.382 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356, 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 FBMjr7KbuixA for ; Thu, 21 Jun 2012 02:01:47 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9440E21F8450 for ; Thu, 21 Jun 2012 02:01:46 -0700 (PDT) Received: by eaaq13 with SMTP id q13so114232eaa.31 for ; Thu, 21 Jun 2012 02:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UXmT8d68c6ESMW0NBluCPY/JGGp26P2flYgsYtJffdE=; b=lZjwFxlMn7SbhXdKzazEKVMLcZ/ffzDxTYerQ5b9YCN2t45f7astfYO8/5IF+hz+f6 68i1ME1ydqYcqQHxshwpz/Ob0rhW1gW6qpSwdp4ueqRBHCgiLcdkq0S2KWwl0Od2hCAo DCg0chGrVP57FpXS5h0Tw+saC+fAMIerf/qot5FxB0EjvVfiCxaNZ//spWlCjJ/+qrBF sXTvmPHjFkuStDub00eHC/2+3JtNCWClvCt3mgT5pIctIpKcdfK9kzOG1z9tiRwESAqP lp0ukLAUdMZpxKxLT4wRdQJaoj3wGpzkfIXEHvSJn/MDG8aDyCGaVhY8jvjX15wteNGn qfxg== Received: by 10.14.47.139 with SMTP id t11mr5913557eeb.155.1340269305252; Thu, 21 Jun 2012 02:01:45 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-59.as13285.net. [2.102.216.59]) by mx.google.com with ESMTPS id c51sm100550493eei.12.2012.06.21.02.01.43 (version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 02:01:44 -0700 (PDT) Message-ID: <4FE2E2F2.8000107@gmail.com> Date: Thu, 21 Jun 2012 10:01:38 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <000301cd4801$1f059880$5d10c980$@asgard.org> <58DBDF90-CE65-467C-A7C4-F6A1C9E69642@cisco.com> In-Reply-To: <58DBDF90-CE65-467C-A7C4-F6A1C9E69642@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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: Thu, 21 Jun 2012 09:01:48 -0000 On 2012-06-18 12:14, Fred Baker wrote: > Let me put a straight question to the working group. The > topic is: > > http://tools.ietf.org/html/draft-chkpvc-enterprise-incremental-ipv6 > "Enterprise Incremental IPv6", Lee Howard, Tim Chown, KK > Chittimaneni, Yanick Pouffary, Eric Vyncke, Victor Kuarsingh, > 27-Feb-12 > > Read the v6ops charter > (http://datatracker.ietf.org/wg/v6ops/charter/). Do you feel > that this document is within the charter? Yes, under goal 1 (operational issues). > If so, do you feel > that the document and its recommendations represent useful > advice concerning operational practice in an enterprise > (e.g., edge network that is large enough to provide its own > IT services as opposed to contracting those) IPv6 network? The aims of the document are admirable and the range of topics seems about right. However, I'd have expected to see separate sections on major topics like DNS, DHCPv6, choice of routing protocol (it's a bit facile to say "if using OSPF, use OSPF"), address management tools, ops and management tools, firewalls, load balancers, etc. I would also expect discussion of the approach to transition tools. This is really a book-length topic. That's one reason why we bit off a smaller problem for draft-ietf-v6ops-icp-guidance-01.txt. > Based on that analysis and viewpoint, would you support its > adoption as a working group draft? My concern is whether the document is too ambitious. If it is to be detailed enough to be useful, maybe it needs to be split into a number of separate documents. Brian > > I am of course interested in views across the working group. > In this particular case, however, I would find especially > interesting the commentary of enterprise network operators. > > On Jun 11, 2012, at 11:36 AM, Lee Howard wrote: > >> When discussed in Taipei, it seemed there was real interest >> in updating guidance for enterprise networks. From lack of >> list discussion, it now appears there's no interest in the >> WG. >> >> 1. Are people interested? 2. Should we let it die? 3. >> Should we pursue other avenues of publication? >> >> Lee >> >>> -----Original Message----- From: v6ops-bounces@ietf.org >>> [mailto:v6ops-bounces@ietf.org] On Behalf Of >> Victor >>> Kuarsingh Sent: Monday, March 26, 2012 7:42 AM To: IPv6 >>> Operations Subject: Re: [v6ops] >>> draft-chkpvc-enterprise-incremental-ipv6-00 >>> >>> IPv6 WG, >>> >>> I would like to kick off some comments on this draft for >>> other group >> members to comment. >>> I do think (Bias noted) that this material is useful for >>> Enterprises who >> need to being and/or >>> move their IPv6 deployments. Many (of those I have >>> worked with thus far) >> are bogged >>> down with personnel who are overwhelmed with what it may >>> take to get IPv6 >> moving on >>> their networks. >>> >>> The draft breaks the challenge down by areas of focus >>> (rolled into "Phases") which can help put this large >>> challenge into bite size chunks >> for them. The draft >>> also provides some valid contextual information around >>> IPv6 and highlights areas which should be looked at. >>> >>> Given the good momentum we now have in the operator >>> space, it would be >> good to see this >>> move forward into the Enterprise space. I think such >>> documents can help >> many of those still >>> waffling (too many to count) to start acting. >>> >>> Regards, >>> >>> Victor K >>> >>> >>> On 12-03-22 8:02 AM, "Tim Chown" >>> wrote: >>> >>>> Hi, >>>> >>>> Due to a typo in the draft name, this draft didn't hit >>>> Fred's automated WG tools, so the authors would like to >>>> raise the draft on the list now with a view to securing >>>> a slot in Paris to discuss its value and content. >>>> >>>> In Taipei there was a comment in the WG session that >>>> there is no up-to-date v6ops guidance on enterprise >>>> networks, while other scenarios do have such texts. So >>>> at the mic I invited people to join an effort to put >>>> something together. There is a good breadth of >>>> experience across the people who stepped forward, and >>>> the result is available as >>>> >>>> http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.txt >>>> >>>> >>>> Does the WG think the subject matter of this draft is >>>> one we should pursue in the WG? If so, is the >>>> structure and content appropriate? We need some >>>> positive feedback and comments in order for Fred to >>>> schedule us time in Paris. >>>> >>>> We have had a couple of people contact us off-list >>>> offering to help develop the content. But we'd like >>>> some feedback from the WG before investing more time in >>>> doing so. The -00 text is somewhat "rough", but we >>>> feel it could be polished into something quite useful >>>> for the community. >>>> >>>> Tim >>>> >>>> _______________________________________________ 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 touch@isi.edu Thu Jun 21 08:05: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 C1DC021F8700 for ; Thu, 21 Jun 2012 08:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=0.700, 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 RQ780fvryaTO for ; Thu, 21 Jun 2012 08:05:10 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id BED8421F86F7 for ; Thu, 21 Jun 2012 08:05:10 -0700 (PDT) Received: from [192.168.1.95] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5LF3nMw011300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Jun 2012 08:04:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Joe Touch In-Reply-To: Date: Thu, 21 Jun 2012 08:04:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9A5D41C8-A94C-46EE-9638-25FEFBD66CC3@isi.edu> References: <4FE257A1.7070608@isi.edu> To: Washam Fan X-Mailer: Apple Mail (2.1278) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Jun 2012 15:05:11 -0000 Hi, Washam, On Jun 20, 2012, at 10:42 PM, Washam Fan wrote: > Hi Joe, >=20 > 2012/6/21 Joe Touch : >>> Please review and comment on 'draft-generic-v6ops-tunmtu': >>>=20 >>> https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ >>>=20 >>> This new document takes the radical approach of proposing >>> IPv6 router fragmentation at the tunnel ingress so that >>> the tunnel MTU can be jacked up to 1500 bytes. >>>=20 >>> The document notes issues that arise when the IPv6 router >>> performs fragmentation - most notably, the selection of >>> the Identification value to place in the (router-inserted) >>> fragmentation header. >>=20 >>=20 >> Hi, all, >>=20 >> This draft was recently brought to my attention in a discussion on = the main >> IETF list. This doc's premise is badly flawed: >>=20 >> Even assuming the pending draft-ietf-intarea-ipv4-id-update-05, it is >> impossible to overwrite the DF and ID of inner IPv4 datagrams in a = way that >> makes fragmentation usefully safe. Consider: >>=20 >> A. non-atomic datagram fragments that enter the ingress >>=20 >> B. non-atomic datagrams that have not yet been fragmented, >> but that this ingress needs to fragment >>=20 >> C. non-atomic datagram fragments that reach the destination >> but do not use the tunnel at all >>=20 >> The IDs that the ingress overwrites CANNOT use IDs that are used by = any of >> (A), (B), or (C). (B) can be avoided by overwriting those IDs too. = (A) >> requires the ingress keep track of the IDs seen and avoid using them = for >> 2MSL. IDs used by (C) aren't seen at all - and thus cannot be = avoided. >>=20 >> Keep in mind that (C) could also be the result of one of the proposed >> tunnels from this draft on a different path in the network. >>=20 >> So (A) and (B) make this complex, and (C) makes it impossible. I.e., = the >> result of inserting your own IDs into someone else's packets is that = you >> could corrupt reassembly at the destination, and you can't know when = that >> will happen. >>=20 >=20 > the last 2nd para, section 4 admits the exist of the collision, do you > think the randomness assignment can not suffiently address this issue? It might for IPv6, but the ID space for IPv4 is far too small to avoid = such collisions. The draft says: Specifically, the tunnel ingress must ensure that there will be no IP fragments alive in the system with duplicate Identification values. Since [RFC2460] specifies that the maximum time a node may retain an incomplete fragmented packet is 60 seconds, this means that the tunnel ingress must not allow the Identification values to be repeated within this timeframe. The tunnel ingress can therefore calculate a maximum data rate for admission of fragmented packets into the tunnel. The tunnel ingress cannot know the fragments that are alive in the = system that don't use the ingress. FWIW, there are other problems: - admitting fragments with IDs that are recently used (within 60 = seconds) at a rate of 11 Mbps, regardless of how random IDs are generated, the = IDs *must* repeat, which means that *all* incoming fragments must be = discarded. - the 60 second rule for the receiver is used in this paper as if there = were one such timer per ID forever. consider that fragments could arrive = at the receiver separated by up to 2MSL (let's assume the MSL is = reasonable); if three such segments arrive spaced at t=3D0seconds and = t=3D119seconds, then the receiver is susceptible to collisions for 179 = seconds. Overall, the ingress cannot rewrite IDs faster than a rate of 4Mbps ONLY = IF it is the *ONLY* generator of IDs on the path - i.e., only if the = source never generates non-atomic packets AND there are no other tunnels = doing what this draft proposes. The probability of collision is proportional to the rate of nonatomic = packets of all entities that rewrite IDs on a path. That cannot be = known. It is unsafe and should not be suggested. >> I have stated before many times that tunnels must clean up the mess = they >> create. The only viable path for a tunnel that receives a DF=3D1 = datagram is >> to generate fragments in the outer header, and reassemble them at the >> egress. >>=20 >=20 > Right. This way eliminate the fragment ID collision concern. But this > draft is to avoid reassemble at egress. That's a common goal, but always creates problems when it ignores the DF = bit. That bit can be set because of a negotiation between the source and = destination using higher level information (e.g., HTTP request context), = sometimes to take into account limitations on reassembly limitations at = the receiver (where reassembly may be supported but might consume memory = or CPU resources, such as for cellphones). See section 8 of = http://tools.ietf.org/html/draft-ietf-intarea-tunnels-00 (granted, I'm = overdue to update that...) Joe >=20 > Thanks, > washam >=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Thu Jun 21 10:00: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 4B76D21F8726 for ; Thu, 21 Jun 2012 10:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.006, 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 IgI2HT9uwCR9 for ; Thu, 21 Jun 2012 10:00:08 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id B80C221F8723 for ; Thu, 21 Jun 2012 10:00:08 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5LH07TK001925 for ; Thu, 21 Jun 2012 10:00:08 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5LH063Q001909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jun 2012 10:00:07 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5LH06S3018768; Thu, 21 Jun 2012 10:00:06 -0700 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5LH064T018716 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 21 Jun 2012 10:00:06 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Thu, 21 Jun 2012 10:00:06 -0700 From: "Templin, Fred L" To: Joe Touch , "v6ops@ietf.org" Date: Thu, 21 Jun 2012 10:00:05 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1POYd/dmi9LCDjQjuwUwynTZBGaQAkulYA Message-ID: References: <4FE257A1.7070608@isi.edu> In-Reply-To: <4FE257A1.7070608@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Jun 2012 17:00:09 -0000 Hi Joe, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Joe Touch > Sent: Wednesday, June 20, 2012 4:07 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > > Please review and comment on 'draft-generic-v6ops-tunmtu': > > > > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ > > > > This new document takes the radical approach of proposing > > IPv6 router fragmentation at the tunnel ingress so that > > the tunnel MTU can be jacked up to 1500 bytes. > > > > The document notes issues that arise when the IPv6 router > > performs fragmentation - most notably, the selection of > > the Identification value to place in the (router-inserted) > > fragmentation header. >=20 > Hi, all, >=20 > This draft was recently brought to my attention in a discussion on the > main IETF list. This doc's premise is badly flawed: >=20 > Even assuming the pending draft-ietf-intarea-ipv4-id-update-05, it is > impossible to overwrite the DF and ID of inner IPv4 datagrams in a way > that makes fragmentation usefully safe. Consider: >=20 > A. non-atomic datagram fragments that enter the ingress >=20 > B. non-atomic datagrams that have not yet been fragmented, > but that this ingress needs to fragment >=20 > C. non-atomic datagram fragments that reach the destination > but do not use the tunnel at all >=20 > The IDs that the ingress overwrites CANNOT use IDs that are used by any > of (A), (B), or (C). (B) can be avoided by overwriting those IDs too. > (A) requires the ingress keep track of the IDs seen and avoid using them > for 2MSL. IDs used by (C) aren't seen at all - and thus cannot be avoided= . >=20 > Keep in mind that (C) could also be the result of one of the proposed > tunnels from this draft on a different path in the network. >=20 > So (A) and (B) make this complex, and (C) makes it impossible. I.e., the > result of inserting your own IDs into someone else's packets is that you > could corrupt reassembly at the destination, and you can't know when > that will happen. I can see the point about IPv4. In that case, perhaps the document should recommend against inner fragmentation and jump straight to section 5 on Outer Fragmentation. This would be consistent with RFC6333. > I have stated before many times that tunnels must clean up the mess they > create. The only viable path for a tunnel that receives a DF=3D1 datagram > is to generate fragments in the outer header, and reassemble them at the > egress. With IPv6, I believe it should be OK for the router to perform inner fragmentation if the packet already has a fragment header - in other words, treat the packet as non-atomic the same as for IPv4 with DF=3D0. If the packet does not already have a fragment header then insert one, have the tunnel ingress supply an Identification value (random? sequential?), and also send a PTB message back to the original source telling it to begin inserting fragment headers. The draft doesn't currently say this, but will fix that in the next version. Fred fred.l.templin@boeing.com > Joe > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From touch@isi.edu Thu Jun 21 16: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 6B62111E8096 for ; Thu, 21 Jun 2012 16:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=-0.750, 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 EEHJXLPop8tp for ; Thu, 21 Jun 2012 16:00:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id DDFC011E80A6 for ; Thu, 21 Jun 2012 16:00:27 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q5LMxtc6021391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jun 2012 15:59:55 -0700 (PDT) Message-ID: <4FE3A76B.9060400@isi.edu> Date: Thu, 21 Jun 2012 15:59:55 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <4FE257A1.7070608@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Jun 2012 23:00:28 -0000 Hi, Fred, On 6/21/2012 10:00 AM, Templin, Fred L wrote: ... >> So (A) and (B) make this complex, and (C) makes it impossible. I.e., the >> result of inserting your own IDs into someone else's packets is that you >> could corrupt reassembly at the destination, and you can't know when >> that will happen. > > I can see the point about IPv4. In that case, perhaps the > document should recommend against inner fragmentation and > jump straight to section 5 on Outer Fragmentation. This > would be consistent with RFC6333. That's what I would suggest. >> I have stated before many times that tunnels must clean up the mess they >> create. The only viable path for a tunnel that receives a DF=1 datagram >> is to generate fragments in the outer header, and reassemble them at the >> egress. > > With IPv6, I believe it should be OK for the router to > perform inner fragmentation if the packet already has > a fragment header - in other words, treat the packet as > non-atomic the same as for IPv4 with DF=0. I disagree. IPv6 establishes that the source - and only the source - determines fragment boundaries. There are various reasons to retain control over that. I haven't seen a general recommendation to relax that constraint. Absent such a general update to RFC 2460, I think that this doc should stay within existing requirements or be very clear about relaxing them in general. There's simply no reason to treat this tunnel case as distinct. > If the packet > does not already have a fragment header then insert one, > have the tunnel ingress supply an Identification value > (random? sequential?), and also send a PTB message back > to the original source telling it to begin inserting > fragment headers. The draft doesn't currently say this, > but will fix that in the next version. Inserting the header has the same problem as ignoring DF=1. It defeats all path MTU mechanisms downstream of the decsion. Yes, the ID space is larger and potential for collisions is lower, but I don't like the idea of a tunnel making this gamble - there are consequences to the endpoints, but none to the tunnel. Sending a PTB is fine for both IPv4 and IPv6. Fragmenting the outer is fine in both cases, and clean. Anything else requires a general revision to RFC791/RFC1122, RFC2460, and probably both PMTU docs. I don't see the reason for *this* tunnel mechanism as a justification for any of that. Joe From Fred.L.Templin@boeing.com Fri Jun 22 09:23: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 DDEFC21F875D for ; Fri, 22 Jun 2012 09:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 8zUOWniKGI9K for ; Fri, 22 Jun 2012 09:23:39 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 97D7D21F875B for ; Fri, 22 Jun 2012 09:23:39 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5MGNuiK010625 for ; Fri, 22 Jun 2012 09:23:56 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5MGNsAT010602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Jun 2012 09:23:55 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5MGNZVM022504; Fri, 22 Jun 2012 11:23:35 -0500 Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5MGNO94021763 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 22 Jun 2012 11:23:34 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 22 Jun 2012 09:23:33 -0700 From: "Templin, Fred L" To: Joe Touch Date: Fri, 22 Jun 2012 09:23:32 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1QAaXKtgitoj7zRimRj19yZk4h1wAi3P+w Message-ID: References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> In-Reply-To: <4FE3A76B.9060400@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jun 2012 16:23:41 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Thursday, June 21, 2012 4:00 PM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > Hi, Fred, >=20 > On 6/21/2012 10:00 AM, Templin, Fred L wrote: > ... > >> So (A) and (B) make this complex, and (C) makes it impossible. I.e., > the > >> result of inserting your own IDs into someone else's packets is that > you > >> could corrupt reassembly at the destination, and you can't know when > >> that will happen. > > > > I can see the point about IPv4. In that case, perhaps the > > document should recommend against inner fragmentation and > > jump straight to section 5 on Outer Fragmentation. This > > would be consistent with RFC6333. >=20 > That's what I would suggest. I spun the draft again to take out inner fragmentation for IPv4 as the inner payload. For IPv4-over-IPv4 tunnels, however, even outer fragmentation at high data rates is dangerous and cannot be recommended without rate limiting. Does this match your understanding? For IPv4-over-IPv6 tunnels, outer fragmentation is feasible since host-based fragmentation is fixed in IPv6. However, existing tunnel protocols have not specified the minimum MRU that the tunnel egress must configure, so the ingress has no way of knowing whether the egress can reassemble a 1500 byte inner packet plus the size of the encapsulation headers. That means that the ingress would have to set a (1500-HLEN) MTU at the maximum, and can lead to PMTUD problems when the ingress needs to drop a packet that is larger than this MTU but no larger than 1500. =20 > >> I have stated before many times that tunnels must clean up the mess > they > >> create. The only viable path for a tunnel that receives a DF=3D1 datag= ram > >> is to generate fragments in the outer header, and reassemble them at > the > >> egress. > > > > With IPv6, I believe it should be OK for the router to > > perform inner fragmentation if the packet already has > > a fragment header - in other words, treat the packet as > > non-atomic the same as for IPv4 with DF=3D0. >=20 > I disagree. IPv6 establishes that the source - and only the source - > determines fragment boundaries. There are various reasons to retain > control over that. > > I haven't seen a general recommendation to relax that constraint. Absent > such a general update to RFC 2460, I think that this doc should stay > within existing requirements or be very clear about relaxing them in > general. There's simply no reason to treat this tunnel case as distinct. I think we should relax the RFC2460 requirement that routers not (re)fragment IPv6 packets that already include a fragment header. Otherwise, we can run into problems when there are multiple tunnel nestings between the original source and final destination, i.e., even if the source takes care in setting conservative fragment boundaries. To relax this would take an update to RFC2460, Section 4.5 to drop the following statement: "(Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path -- see section 5.)" > > If the packet > > does not already have a fragment header then insert one, > > have the tunnel ingress supply an Identification value > > (random? sequential?), and also send a PTB message back > > to the original source telling it to begin inserting > > fragment headers. The draft doesn't currently say this, > > but will fix that in the next version. >=20 > Inserting the header has the same problem as ignoring DF=3D1. It defeats > all path MTU mechanisms downstream of the decsion. Yes, the ID space is > larger and potential for collisions is lower, but I don't like the idea > of a tunnel making this gamble - there are consequences to the > endpoints, but none to the tunnel. If the tunnel sets a conservative rate limit for admitting inner packets for which it has added a fragmentation header, the incidence of collisions will be minimized, and the source is given incentive to begin including fragment headers in the packets it sends. Namely, inner packets that already include a fragment header do not need to be rate limited. > Sending a PTB is fine for both IPv4 and IPv6. Fragmenting the outer is > fine in both cases, and clean. Outer fragmentation for tunnels over IPv4 is subject to a too-slow rate limit. Outer fragmentation for tunnels over IPv6 do not have this limitation, but there is no assurance that the tunnel egress can reassemble a 1500 byte inner packet. A third alternative called "tunnel fragmentation" is available if the tunneling protocol inserts a mid-layer encapsulation with a suitably long Identification field. That is what SEAL does, but it requires both the ingress and egress to be aware of SEAL. > Anything else requires a general revision > to RFC791/RFC1122, RFC2460, and probably both PMTU docs. I don't see the > reason for *this* tunnel mechanism as a justification for any of that. No changes to RFC791, RFC1122 and the PMTU docs. The only update would be to RFC2460 to re-allow router fragmentation and to encourage hosts to include fragment headers with the packets they send. It should be clear by now that I believe the abolishment of router fragmentation in IPv6 was a mistake that seems to be interfering with tunnels. It would be very nice to find a way to fix this by only having to visit the tunnel ingress (and not both the ingress and egress), and inner fragmentation is the only way to do that unless we are willing to pull in SEAL. Thanks - Fred =20 > Joe From touch@isi.edu Fri Jun 22 10:06: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 0F9D121F8746 for ; Fri, 22 Jun 2012 10:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 bS0p6Wmwaens for ; Fri, 22 Jun 2012 10:06:19 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9323621F8723 for ; Fri, 22 Jun 2012 10:06:17 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q5MH5Hg1007804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jun 2012 10:05:18 -0700 (PDT) Message-ID: <4FE4A5CD.6000405@isi.edu> Date: Fri, 22 Jun 2012 10:05:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jun 2012 17:06:26 -0000 Hi Fred, On 6/22/2012 9:23 AM, Templin, Fred L wrote: > Hi Joe, ... > I spun the draft again to take out inner fragmentation for > IPv4 as the inner payload. For IPv4-over-IPv4 tunnels, however, > even outer fragmentation at high data rates is dangerous and > cannot be recommended without rate limiting. Does this match > your understanding? Yes. > For IPv4-over-IPv6 tunnels, outer fragmentation is feasible > since host-based fragmentation is fixed in IPv6. However, > existing tunnel protocols have not specified the minimum MRU > that the tunnel egress must configure, so the ingress has no > way of knowing whether the egress can reassemble a 1500 byte > inner packet plus the size of the encapsulation headers. Agreed. IPv4 reassembly is assumed up to 576 bytes, but not above that. > That > means that the ingress would have to set a (1500-HLEN) MTU > at the maximum, and can lead to PMTUD problems when the > ingress needs to drop a packet that is larger than this > MTU but no larger than 1500. Strictly, it has to set to the min of the MTU of IPv4 and IPv6 - which is 576 as per above. However, if you're not willing to make this bet on behalf of the egress - which you can specify herein - why are you expecting that the ultimate endpoint has the capability to reassemble 1500-byte IPv4 packets either? >>>> I have stated before many times that tunnels must clean up the mess >> they >>>> create. The only viable path for a tunnel that receives a DF=1 datagram >>>> is to generate fragments in the outer header, and reassemble them at >> the >>>> egress. >>> >>> With IPv6, I believe it should be OK for the router to >>> perform inner fragmentation if the packet already has >>> a fragment header - in other words, treat the packet as >>> non-atomic the same as for IPv4 with DF=0. >> >> I disagree. IPv6 establishes that the source - and only the source - >> determines fragment boundaries. There are various reasons to retain >> control over that. >> >> I haven't seen a general recommendation to relax that constraint. Absent >> such a general update to RFC 2460, I think that this doc should stay >> within existing requirements or be very clear about relaxing them in >> general. There's simply no reason to treat this tunnel case as distinct. > > I think we should relax the RFC2460 requirement that routers > not (re)fragment IPv6 packets that already include a fragment > header. That should not happen as a side issue of this doc. That should be a standalone proposal. There was a lot of debate around this as I recall; I'll be surprised if it passes, FWIW. > Otherwise, we can run into problems when there are > multiple tunnel nestings between the original source and > final destination, i.e., even if the source takes care in > setting conservative fragment boundaries. Multiple nestings always cause problems, but I don't think it's useful to sacrifice robustness for efficiency. Multiple nestings always work if the tunnels frag/reassemble - it's inefficient, but robust. All other solutions are not, AFAICT. > To relax this > would take an update to RFC2460, Section 4.5 to drop the > following statement: > > "(Note: unlike IPv4, fragmentation in IPv6 is performed > only by source nodes, not by routers along a packet's > delivery path -- see section 5.)" Agreed - that's the standalone proposal I refer to above. >> > If the packet >>> does not already have a fragment header then insert one, >>> have the tunnel ingress supply an Identification value >>> (random? sequential?), and also send a PTB message back >>> to the original source telling it to begin inserting >>> fragment headers. The draft doesn't currently say this, >>> but will fix that in the next version. >> >> Inserting the header has the same problem as ignoring DF=1. It defeats >> all path MTU mechanisms downstream of the decsion. Yes, the ID space is >> larger and potential for collisions is lower, but I don't like the idea >> of a tunnel making this gamble - there are consequences to the >> endpoints, but none to the tunnel. > > If the tunnel sets a conservative rate limit for admitting > inner packets for which it has added a fragmentation header, > the incidence of collisions will be minimized, Collision probability is determined by the combination of what you do and what other sources do - since you can't know the latter, you can't know the total. > and the source > is given incentive to begin including fragment headers in the > packets it sends. The source has no idea what you're doing in this downstream tunnel. You can try to send an ICMP upstream, but those are often blocked. So you should not assume the source will adjust its behavior. > Namely, inner packets that already include > a fragment header do not need to be rate limited. Agreed. >> Sending a PTB is fine for both IPv4 and IPv6. Fragmenting the outer is >> fine in both cases, and clean. > > Outer fragmentation for tunnels over IPv4 is subject to a > too-slow rate limit. Outer fragmentation for tunnels over > IPv6 do not have this limitation, but there is no assurance > that the tunnel egress can reassemble a 1500 byte inner > packet. Yes. But there's similarly no assurance that the destination can either, as noted above. If you have to make this assumption, make it inside your system. > A third alternative called "tunnel fragmentation" is > available if the tunneling protocol inserts a mid-layer > encapsulation with a suitably long Identification field. > That is what SEAL does, but it requires both the ingress > and egress to be aware of SEAL. Yup. And that's the best solution for IPv4. >> Anything else requires a general revision >> to RFC791/RFC1122, RFC2460, and probably both PMTU docs. I don't see the >> reason for *this* tunnel mechanism as a justification for any of that. > > No changes to RFC791, RFC1122 and the PMTU docs. The only > update would be to RFC2460 to re-allow router fragmentation > and to encourage hosts to include fragment headers with > the packets they send. See above; as a separate proposal. > It should be clear by now that I believe the abolishment > of router fragmentation in IPv6 was a mistake that seems > to be interfering with tunnels. I think this is the wrong conclusion. IMO, tunnels always are implemented in pairs - ingress and egress - and the entire system needs to be defined and implemented. My conclusion is that doing tricks at the ingress to avoid work at the egress is inappropriate, because it *always* pushes that work to the final destination. IMO, the ingress shouldn't place any bets that the egress can't pay out. > It would be very nice to > find a way to fix this by only having to visit the tunnel > ingress (and not both the ingress and egress), and inner > fragmentation is the only way to do that unless we are > willing to pull in SEAL. I don't see that as a bad thing. Joe From touch@isi.edu Fri Jun 22 10:17: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 83A4911E8087 for ; Fri, 22 Jun 2012 10:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 Zcv9L1G7Ilnk for ; Fri, 22 Jun 2012 10:17:24 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id F192411E80AE for ; Fri, 22 Jun 2012 10:17:23 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q5MHH6hU009727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jun 2012 10:17:06 -0700 (PDT) Message-ID: <4FE4A892.1040809@isi.edu> Date: Fri, 22 Jun 2012 10:17:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> <4FE4A5CD.6000405@isi.edu> In-Reply-To: <4FE4A5CD.6000405@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jun 2012 17:17:24 -0000 One PS - IMO, fragmenting something that says "don't fragment" is a bad idea. IPv4 does this with DF=1, we agree. IMO, IPv6 does this by omitting the frag header. Mucking with either one destroys PMTU determination. If you want to update IPv6 to allow downstream fragmentation, you are still doing something dangerous when you add a frag header when it wasn't there. Regardless of the potential for frag ID collisions (which is admittedly low for IPv6), you're still expecting a) that the destination can reassemble the components instead of the egress b) that there's no interference with PMTU algs I would suggest that - at best - you might want to see how changing IPv6 to allow downstream fragmentation is received, but that inserting a new frag header where one doesn't exist should still be avoided. Joe From fred@cisco.com Fri Jun 22 14:43: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 3955411E809F for ; Fri, 22 Jun 2012 14:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reAfO9CTZJ6r for ; Fri, 22 Jun 2012 14:43:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF3011E80A3 for ; Fri, 22 Jun 2012 14:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2206; q=dns/txt; s=iport; t=1340401404; x=1341611004; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1YZ8mMQmZQMuSuCh88hy9/k3uLZYjekG/FZNiU/96+k=; b=gY9bprOHqR6OodcHYPM5XyJiuZRrdJpi/mzxJJSv+hDF7HU2nJkBdgoq IsxKWvC4DpKPKC39xmMVIFEhmBYmQkgMJ5Ilqo5v04c47KVKNwfm5TlZO wUvYUtqhGAJdOnWakNgFi+2NKFVpg2IVb1kr67FoAk/Vi250yxjHwKFv/ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOHl5E+tJXG+/2dsb2JhbABFtWiBB4IZAQEEEgEnTwIBCDYQMiUCBAE0h2maLZ9zkFBgA5UsjhuBZoJf X-IronPort-AV: E=Sophos;i="4.77,460,1336348800"; d="scan'208";a="95091210" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 22 Jun 2012 21:43:24 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5MLhOS2010883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Jun 2012 21:43:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.234]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 16:43:23 -0500 From: "Fred Baker (fred)" To: Fred Templin , "v6ops@ietf.org WG" Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: AQHNUMAMI2lkh8Q9EkiB3bN18+NwHA== Date: Fri, 22 Jun 2012 21:43:22 +0000 Message-ID: References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18990.001 x-tm-as-result: No--43.117700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jun 2012 21:43:25 -0000 Coming back to this as a meta-issue. v6ops is about operational considerations and procedures, but not protocols= ; disputing RFC 2460, aka redesigning IPv6, seems like a protocol issue. The reason to not do inner fragmentation, if memory serves, has to do with = the behavior of fragmentation in the network and its effect on communicatio= ns. For example, suppose you and I are in 9K clean networks (so the TCP MSS= starts out as 9K), my link to the public network has an MTU of 1500, and s= omewhere en route to you there is another link with an MTU of 1400. When I = send a 9K packet, it will become six 1500 byte packets with a small caboose= that picks up the size of five IP headers (IPv4 or IPv6), and what you wil= l receive is six 1400 byte packets interspersed with six 100+IP byte packet= s, followed by the original caboose. What if the fragmenting router's queue= , at the time of fragmentation, was one packet short of the needed capacity= ? Maybe the retransmission follows a different path and is fragmented diffe= rently, resulting in funny overlaps whose handling isn't very well specifie= d. There's nothing *incorrect* about a stream of 13 packets of various size= s being reassembled, but integrating retransmissions gets messy. IIRC, they= just wanted to clean that up. Which brings me to the following consideration. If we're talking about having one tunnel endpoint put a message into a tunn= el datagram and then fragment it, and have the other tunnel endpoint reasse= mble the original and forward it, we are talking about an operational proce= dure that requires support in a router, but which I can correlate with sect= ion 5 of RFC 2460. One thing I would invite is discussion of operational experience with RFC 4= 821. Wouldn't it be nice if the endpoint actually chose an MSS based on wha= t actually worked (shades of Happy Eyeballs), rather than depending on erro= r messages that network operators routinely filter out? If we're talking about changing the recommendation of RFC 2460 regarding wh= o does fragmentation, that sounds like an IPv6 protocol change, and I'd lik= e to refer that to 6MAN. Does that make sense?= From Fred.L.Templin@boeing.com Fri Jun 22 15:28: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 7E5A111E809F for ; Fri, 22 Jun 2012 15:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 Zae82cvY6Wcm for ; Fri, 22 Jun 2012 15:28:01 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 835DE11E809B for ; Fri, 22 Jun 2012 15:28:01 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5MMSKjd002450 for ; Fri, 22 Jun 2012 15:28:20 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5MMSJSr002438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Jun 2012 15:28:20 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5MMS0km026020; Fri, 22 Jun 2012 17:28:00 -0500 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5MMRxla026001 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 22 Jun 2012 17:27:59 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Fri, 22 Jun 2012 15:27:59 -0700 From: "Templin, Fred L" To: Joe Touch Date: Fri, 22 Jun 2012 15:27:58 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1QmVYiddK4gu4dTIuGd6/xoD35QwAKwWFA Message-ID: References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> <4FE4A5CD.6000405@isi.edu> In-Reply-To: <4FE4A5CD.6000405@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jun 2012 22:28:02 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, June 22, 2012 10:05 AM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > Hi Fred, >=20 > On 6/22/2012 9:23 AM, Templin, Fred L wrote: > > Hi Joe, > ... > > I spun the draft again to take out inner fragmentation for > > IPv4 as the inner payload. For IPv4-over-IPv4 tunnels, however, > > even outer fragmentation at high data rates is dangerous and > > cannot be recommended without rate limiting. Does this match > > your understanding? >=20 > Yes. OK. > > For IPv4-over-IPv6 tunnels, outer fragmentation is feasible > > since host-based fragmentation is fixed in IPv6. However, > > existing tunnel protocols have not specified the minimum MRU > > that the tunnel egress must configure, so the ingress has no > > way of knowing whether the egress can reassemble a 1500 byte > > inner packet plus the size of the encapsulation headers. >=20 > Agreed. IPv4 reassembly is assumed up to 576 bytes, but not above that. OK, so IPv4 routers are only required to reassemble up to 576 bytes and are not required to reassemble any more - is that right? So, tunnel protocols that specified router reassembly without specifying a tunnel egress router's maximum reassembly unit (MRU) are only guaranteed 576? > > That > > means that the ingress would have to set a (1500-HLEN) MTU > > at the maximum, and can lead to PMTUD problems when the > > ingress needs to drop a packet that is larger than this > > MTU but no larger than 1500. >=20 > Strictly, it has to set to the min of the MTU of IPv4 and IPv6 - which > is 576 as per above. Well, minMRU for IPv6 is 1500 while minMRU for IPv4 is only 576. So, an IPv6 tunnel egress should be able to reassemble inner packets up to (1500-40) bytes while an IPv4 tunnel egress only needs to reassemble inner packets up to (576-20) bytes in length - right? > However, if you're not willing to make this bet on behalf of the egress > - which you can specify herein - why are you expecting that the ultimate > endpoint has the capability to reassemble 1500-byte IPv4 packets either? Hosts are expected to reassemble as much as their connected network interfaces, which is 1500 in the vast majority of cases. Unless by "ultimate endpoint" you mean that that could be another tunnel egress router instead of a host - in which case we are back to 576, right? > >>>> I have stated before many times that tunnels must clean up the mess > >> they > >>>> create. The only viable path for a tunnel that receives a DF=3D1 > datagram > >>>> is to generate fragments in the outer header, and reassemble them at > >> the > >>>> egress. > >>> > >>> With IPv6, I believe it should be OK for the router to > >>> perform inner fragmentation if the packet already has > >>> a fragment header - in other words, treat the packet as > >>> non-atomic the same as for IPv4 with DF=3D0. > >> > >> I disagree. IPv6 establishes that the source - and only the source - > >> determines fragment boundaries. There are various reasons to retain > >> control over that. > >> > >> I haven't seen a general recommendation to relax that constraint. > Absent > >> such a general update to RFC 2460, I think that this doc should stay > >> within existing requirements or be very clear about relaxing them in > >> general. There's simply no reason to treat this tunnel case as > distinct. > > > > I think we should relax the RFC2460 requirement that routers > > not (re)fragment IPv6 packets that already include a fragment > > header. >=20 > That should not happen as a side issue of this doc. That should be a > standalone proposal. Maybe we can peel this out of this document and go standalone - maybe in a different wg? > There was a lot of debate around this as I recall; I'll be surprised if > it passes, FWIW. We will see... > > Otherwise, we can run into problems when there are > > multiple tunnel nestings between the original source and > > final destination, i.e., even if the source takes care in > > setting conservative fragment boundaries. >=20 > Multiple nestings always cause problems, but I don't think it's useful > to sacrifice robustness for efficiency. Multiple nestings always work if > the tunnels frag/reassemble - it's inefficient, but robust. All other > solutions are not, AFAICT. Certainly having the tunnels drop packets and return PTBs is a brittle solution. > > To relax this > > would take an update to RFC2460, Section 4.5 to drop the > > following statement: > > > > "(Note: unlike IPv4, fragmentation in IPv6 is performed > > only by source nodes, not by routers along a packet's > > delivery path -- see section 5.)" >=20 > Agreed - that's the standalone proposal I refer to above. OK. > >> > If the packet > >>> does not already have a fragment header then insert one, > >>> have the tunnel ingress supply an Identification value > >>> (random? sequential?), and also send a PTB message back > >>> to the original source telling it to begin inserting > >>> fragment headers. The draft doesn't currently say this, > >>> but will fix that in the next version. > >> > >> Inserting the header has the same problem as ignoring DF=3D1. It defea= ts > >> all path MTU mechanisms downstream of the decsion. Yes, the ID space i= s > >> larger and potential for collisions is lower, but I don't like the ide= a > >> of a tunnel making this gamble - there are consequences to the > >> endpoints, but none to the tunnel. > > > > If the tunnel sets a conservative rate limit for admitting > > inner packets for which it has added a fragmentation header, > > the incidence of collisions will be minimized, >=20 > Collision probability is determined by the combination of what you do > and what other sources do - since you can't know the latter, you can't > know the total. OK, I'll have to admit the point. The tunnel ingress can only control what it does and not what other network elements might do.=20 > > and the source > > is given incentive to begin including fragment headers in the > > packets it sends. >=20 > The source has no idea what you're doing in this downstream tunnel. You > can try to send an ICMP upstream, but those are often blocked. So you > should not assume the source will adjust its behavior. OK - but we can still > > Namely, inner packets that already include > > a fragment header do not need to be rate limited. >=20 > Agreed. OK. =20 > >> Sending a PTB is fine for both IPv4 and IPv6. Fragmenting the outer is > >> fine in both cases, and clean. > > > > Outer fragmentation for tunnels over IPv4 is subject to a > > too-slow rate limit. Outer fragmentation for tunnels over > > IPv6 do not have this limitation, but there is no assurance > > that the tunnel egress can reassemble a 1500 byte inner > > packet. >=20 > Yes. But there's similarly no assurance that the destination can either, > as noted above. If you have to make this assumption, make it inside your > system. OK, but there needs to be some requirements set for tunnel egress MRUs so that a 1500 inner packet can be reassembled >=20 > > A third alternative called "tunnel fragmentation" is > > available if the tunneling protocol inserts a mid-layer > > encapsulation with a suitably long Identification field. > > That is what SEAL does, but it requires both the ingress > > and egress to be aware of SEAL. >=20 > Yup. And that's the best solution for IPv4. Good. This is the place where we can set the requirement for the tunnel egress MRU. > >> Anything else requires a general revision > >> to RFC791/RFC1122, RFC2460, and probably both PMTU docs. I don't see > the > >> reason for *this* tunnel mechanism as a justification for any of that. > > > > No changes to RFC791, RFC1122 and the PMTU docs. The only > > update would be to RFC2460 to re-allow router fragmentation > > and to encourage hosts to include fragment headers with > > the packets they send. >=20 > See above; as a separate proposal. OK. > > It should be clear by now that I believe the abolishment > > of router fragmentation in IPv6 was a mistake that seems > > to be interfering with tunnels. >=20 > I think this is the wrong conclusion. IMO, tunnels always are > implemented in pairs - ingress and egress - and the entire system needs > to be defined and implemented. >=20 > My conclusion is that doing tricks at the ingress to avoid work at the > egress is inappropriate, because it *always* pushes that work to the > final destination. IMO, the ingress shouldn't place any bets that the > egress can't pay out. OK. =20 > > It would be very nice to > > find a way to fix this by only having to visit the tunnel > > ingress (and not both the ingress and egress), and inner > > fragmentation is the only way to do that unless we are > > willing to pull in SEAL. >=20 > I don't see that as a bad thing. Pulling in SEAL, you mean? If so, I agree and I'll make sure that SEAL is ready to go. Thanks - Fred > Joe From Fred.L.Templin@boeing.com Fri Jun 22 15:35: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 BB63921F851B for ; Fri, 22 Jun 2012 15:35:33 -0700 (PDT) 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.045, 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 FEeROrxYaqFs for ; Fri, 22 Jun 2012 15:35:33 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 4173F21F851A for ; Fri, 22 Jun 2012 15:35:33 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5MMZqWO012893 for ; Fri, 22 Jun 2012 15:35:52 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5MMZq5N012887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 22 Jun 2012 15:35:52 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5MMZW5F029424; Fri, 22 Jun 2012 15:35:32 -0700 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5MMZWGc029412 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 22 Jun 2012 15:35:32 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Fri, 22 Jun 2012 15:35:31 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" , "v6ops@ietf.org WG" Date: Fri, 22 Jun 2012 15:35:30 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: AQHNUMAMI2lkh8Q9EkiB3bN18+NwHJcG60mw Message-ID: References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jun 2012 22:35:33 -0000 Hi Fred, > -----Original Message----- > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Friday, June 22, 2012 2:43 PM > To: Templin, Fred L; v6ops@ietf.org WG > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > Coming back to this as a meta-issue. >=20 > v6ops is about operational considerations and procedures, but not > protocols; disputing RFC 2460, aka redesigning IPv6, seems like a protoco= l > issue. OK - we can take this up outside of v6ops if necessary. > The reason to not do inner fragmentation, if memory serves, has to do wit= h > the behavior of fragmentation in the network and its effect on > communications. For example, suppose you and I are in 9K clean networks > (so the TCP MSS starts out as 9K), my link to the public network has an > MTU of 1500, and somewhere en route to you there is another link with an > MTU of 1400. When I send a 9K packet, it will become six 1500 byte packet= s > with a small caboose that picks up the size of five IP headers (IPv4 or > IPv6), and what you will receive is six 1400 byte packets interspersed > with six 100+IP byte packets, followed by the original caboose. What if > the fragmenting router's queue, at the time of fragmentation, was one > packet short of the needed capacity? Maybe the retransmission follows a > different path and is fragmented differently, resulting in funny overlaps > whose handling isn't very well specified. There's nothing *incorrect* > about a stream of 13 packets of various sizes being reassembled, but > integrating retransmissions gets messy. IIRC, they just wanted to clean > that up. I think you could probably extend this to even worse cases if you said that the 1400 link was followed by a 1380 link, which was followed by a 1350 link, etc. The caboose-trimming would become pathological very quickly. So, why not require that fragmenting routers make all fragments to be roughly the same size (instead of roughly MTU-sized) so they will fit through smaller links further down the line? > Which brings me to the following consideration. >=20 > If we're talking about having one tunnel endpoint put a message into a > tunnel datagram and then fragment it, and have the other tunnel endpoint > reassemble the original and forward it, we are talking about an > operational procedure that requires support in a router, but which I can > correlate with section 5 of RFC 2460. Right. > One thing I would invite is discussion of operational experience with RFC > 4821. Wouldn't it be nice if the endpoint actually chose an MSS based on > what actually worked (shades of Happy Eyeballs), rather than depending on > error messages that network operators routinely filter out? ICMP-based PTB feedback is nice to have if you can get it. But, you can't always count on getting the PTBs, hence the need for RFC4821. =20 > If we're talking about changing the recommendation of RFC 2460 regarding > who does fragmentation, that sounds like an IPv6 protocol change, and I'd > like to refer that to 6MAN. >=20 > Does that make sense? Sure. If we decide to make a recommendation for RFC2460 we can take that up in 6MAN. But, that would be a separate proposal. Thanks - Fred From touch@isi.edu Fri Jun 22 16:24: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 256A421F843C for ; Fri, 22 Jun 2012 16:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.144 X-Spam-Level: X-Spam-Status: No, score=-103.144 tagged_above=-999 required=5 tests=[AWL=-0.545, 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 cWIrflmJTdtz for ; Fri, 22 Jun 2012 16:24:09 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 8611D21F843A for ; Fri, 22 Jun 2012 16:24:09 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q5MNNpnc018195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Jun 2012 16:23:51 -0700 (PDT) Message-ID: <4FE4FE87.5020605@isi.edu> Date: Fri, 22 Jun 2012 16:23:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> <4FE4A5CD.6000405@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jun 2012 23:24:10 -0000 Hi, Fred, On 6/22/2012 3:27 PM, Templin, Fred L wrote: > Hi Joe, ... >> Agreed. IPv4 reassembly is assumed up to 576 bytes, but not above that. > > OK, so IPv4 routers are only required to reassemble up to > 576 bytes and are not required to reassemble any more - is > that right? Correct - that's as per RFCs 791 and 1122. Search for 576 and you'll see the relevant text. > So, tunnel protocols that specified router > reassembly without specifying a tunnel egress router's > maximum reassembly unit (MRU) are only guaranteed 576? Correct. >>> That >>> means that the ingress would have to set a (1500-HLEN) MTU >>> at the maximum, and can lead to PMTUD problems when the >>> ingress needs to drop a packet that is larger than this >>> MTU but no larger than 1500. >> >> Strictly, it has to set to the min of the MTU of IPv4 and IPv6 - which >> is 576 as per above. > > Well, minMRU for IPv6 is 1500 while minMRU for IPv4 is > only 576. So, an IPv6 tunnel egress should be able to > reassemble inner packets up to (1500-40) bytes while > an IPv4 tunnel egress only needs to reassemble inner > packets up to (576-20) bytes in length - right? An tunnel egress needs to be able to reassemble IPv6 inner packets that sum up to 1500 bytes, or IPv4 inner packets that sum up to 576 bytes. In both cases that includes the IP headers and their options. Note that this means the egress needs to reassemble (outer) IP packets that are larger than the minimum in both cases (476 or 1500 + the outer + any other signatures or shim layers). >> However, if you're not willing to make this bet on behalf of the egress >> - which you can specify herein - why are you expecting that the ultimate >> endpoint has the capability to reassemble 1500-byte IPv4 packets either? > > Hosts are expected to reassemble as much as their > connected network interfaces, which is 1500 in the > vast majority of cases. That's probably statistically correct, but the only requirement is 476 for IPv4 interfaces. > Unless by "ultimate endpoint" > you mean that that could be another tunnel egress > router instead of a host - in which case we are > back to 576, right? I meant the destination of the packet that arrives at the ingress, i.e., the "final destination". As per above, though, tunnel egresses always need to have higher reassembly bounds than "final destination" hosts on the network. Jumping ahead ... >> Multiple nestings always cause problems, but I don't think it's useful >> to sacrifice robustness for efficiency. Multiple nestings always work if >> the tunnels frag/reassemble - it's inefficient, but robust. All other >> solutions are not, AFAICT. > > Certainly having the tunnels drop packets and return > PTBs is a brittle solution. Agreed, but that need not happen if frag/reassembly is supported. In that case PTB is advisory, not critical to successful transmission. Jumping again ... >> The source has no idea what you're doing in this downstream tunnel. You >> can try to send an ICMP upstream, but those are often blocked. So you >> should not assume the source will adjust its behavior. > > OK - but we can still This seems incomplete. Yes, you can still send the ICMPs and hope they get through, but you probably want to assume they won't. Jumping one last time ... >>> It would be very nice to >>> find a way to fix this by only having to visit the tunnel >>> ingress (and not both the ingress and egress), and inner >>> fragmentation is the only way to do that unless we are >>> willing to pull in SEAL. >> >> I don't see that as a bad thing. > > Pulling in SEAL, you mean? If so, I agree and I'll make sure > that SEAL is ready to go. Yes. Joe From fred@cisco.com Fri Jun 22 17:32: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 D544721F84B4 for ; Fri, 22 Jun 2012 17:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qQWtzsfpdjI for ; Fri, 22 Jun 2012 17:32:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id ED53921F8497 for ; Fri, 22 Jun 2012 17:32:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2762; q=dns/txt; s=iport; t=1340411527; x=1341621127; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N4LhOoYb63eNoCVMf6qX5VytxtPO/FLVqbCRVhjBOUA=; b=D4z5rBkeS3oBO3emwQ7FNC2GtbTQj3P50VHMas/Q7oAYEVLxzUjaKed0 4+QBYQU6UDq9ThoMNqRR9wt+++HdbxPiBZf3lXtz6ar76k5/eO3xFKQbb wxrJD73QNsCLK0FvonS4eqS8/AdQe/7NPkYah9OPDBUcJT8eoNWlvmepx 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADoO5U+tJXG//2dsb2JhbABFtWeBB4IYAQEBAwESASc/EAIBCDYQMiUCBA4nh2QFmi6fYYsuhSJgA5UsjhuBZoJf X-IronPort-AV: E=Sophos;i="4.77,460,1336348800"; d="scan'208";a="95142466" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 23 Jun 2012 00:32:06 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5N0W6h5019049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Jun 2012 00:32:06 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.234]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 19:32:06 -0500 From: "Fred Baker (fred)" To: "Templin, Fred L" Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: AQHNUMAMI2lkh8Q9EkiB3bN18+NwHA== Date: Sat, 23 Jun 2012 00:32:05 +0000 Message-ID: <9B27D3CA-DDF1-4D48-9988-EB218EC2159A@cisco.com> References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18990.001 x-tm-as-result: No--40.092100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <1B3B839B023C0B4098562251613B7598@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Jun 2012 00:32:08 -0000 On Jun 22, 2012, at 3:35 PM, Templin, Fred L wrote: >> The reason to not do inner fragmentation, if memory serves, has to do wi= th >> the behavior of fragmentation in the network and its effect on >> communications. For example, suppose you and I are in 9K clean networks >> (so the TCP MSS starts out as 9K), my link to the public network has an >> MTU of 1500, and somewhere en route to you there is another link with an >> MTU of 1400. When I send a 9K packet, it will become six 1500 byte packe= ts >> with a small caboose that picks up the size of five IP headers (IPv4 or >> IPv6), and what you will receive is six 1400 byte packets interspersed >> with six 100+IP byte packets, followed by the original caboose. What if >> the fragmenting router's queue, at the time of fragmentation, was one >> packet short of the needed capacity? Maybe the retransmission follows a >> different path and is fragmented differently, resulting in funny overlap= s >> whose handling isn't very well specified. There's nothing *incorrect* >> about a stream of 13 packets of various sizes being reassembled, but >> integrating retransmissions gets messy. IIRC, they just wanted to clean >> that up. >=20 > I think you could probably extend this to even worse cases > if you said that the 1400 link was followed by a 1380 link, > which was followed by a 1350 link, etc. The caboose-trimming > would become pathological very quickly. So, why not require > that fragmenting routers make all fragments to be roughly > the same size (instead of roughly MTU-sized) so they will > fit through smaller links further down the line? OOO M M GGG O O MM MM G G O O M M M M G O O M M M G GG O O M M G G O O M M G G OOO M M GGG If you want to go there, there are some 20-year-old discussions I need for = you to look at. Options proposed include at least - someone (a router, a host) fragmenting traffic should make all chunks t= he same size - the first N-1 chunks should be approximately MTU-sized and the last a c= aboose - the last N-1 chunks should be approximately MTU-sized and the first a c= aboose There have been passionate discussions, each approach having proponents wit= h believed-by-them-to-be-good arguments for their position. And I'm pretty = sure there were other positions. The one thing I'll take serious exception to is a proposal that a router re= assemble packets and then re-fragment some other way in the normal course o= f doing business. Excellent fodder for an IRTF draft. Go for it, with my blessing. I, persona= lly, won't be there to keep track of the angels and pinheads... From fred@cisco.com Fri Jun 22 23:32: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 1262121F8539 for ; Fri, 22 Jun 2012 23:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.599 X-Spam-Level: X-Spam-Status: No, score=-111.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 UYuSR+pMz1eF for ; Fri, 22 Jun 2012 23:32:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDB721F8534 for ; Fri, 22 Jun 2012 23:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=937; q=dns/txt; s=iport; t=1340433144; x=1341642744; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TpkVVK9RJr/53O5jA3QHRopgToh8hUZmC6STPagKKBM=; b=b02qtPWwEsOAUa4fp0kr48AaqSomS1evGgFTDMkBzr1ZD/191qUNlH7d efhOrjU0wTdSLtQ2/ZTtHVoTMi+ZSfoYwqYnNkX1Sw5dleej5kX9HLVyC YKxrvFEisFphTdVhm/q/nYJQI8jrZTTu97EZ8NmkOnEi9czcqKBrcCpPE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKVi5U+tJXHB/2dsb2JhbABEDrVZgQeCGAEBAQMBEgEnPwULAgEINhAyJQIEDieHZAWaDp9bizCFImADlSyOG4FmgiY5 X-IronPort-AV: E=Sophos;i="4.77,462,1336348800"; d="scan'208";a="95207699" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 23 Jun 2012 06:32:23 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q5N6WN8Y028478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Jun 2012 06:32:23 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.234]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Sat, 23 Jun 2012 01:32:22 -0500 From: "Fred Baker (fred)" To: Joe Touch Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: AQHNUQnyI2lkh8Q9EkiB3bN18+NwHA== Date: Sat, 23 Jun 2012 06:32:22 +0000 Message-ID: <78A786F2-A62B-457A-B185-7A92E91E044E@cisco.com> References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> <4FE4A5CD.6000405@isi.edu> In-Reply-To: <4FE4A5CD.6000405@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18990.004 x-tm-as-result: No--27.651000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <4E1671B9C20545458D2B61945003E0A6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Jun 2012 06:32:26 -0000 On Jun 22, 2012, at 10:05 AM, Joe Touch wrote: > Agreed. IPv4 reassembly is assumed up to 576 bytes, but not above that. That may be the letter of the law. Practically speaking, both IPv4 and IPv6= routers have to be able to deal with the messages that hosts exchange with= them, and there is no obvious limitation on that. I think it's fair to ass= ume that if there is an MTU somewhere in the network of a given amount, som= e host will take the opportunity to send a message that size, and be very c= onfused if whatever it's talking with (at the IP layer, it doesn't know whe= ther the peer is a router or a host) can't reassemble a message that it sen= t and (however it happened) got fragmented. For today's interfaces, I would say that boils down to a *market* requireme= nt (not a legal value, just something that affects, oh, purchase orders, am= ong other things) to reassemble a 9K packet.= From joelja@bogus.com Sat Jun 23 10:40: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 BDB6A21F851B for ; Sat, 23 Jun 2012 10:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 qFT0Xm2XEoTO for ; Sat, 23 Jun 2012 10:40:11 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF4E21F8518 for ; Sat, 23 Jun 2012 10:40:11 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q5NHeABX015915 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 23 Jun 2012 17:40:10 GMT (envelope-from joelja@bogus.com) Message-ID: <4FE5FF7B.3040401@bogus.com> Date: Sat, 23 Jun 2012 10:40:11 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120619 Thunderbird/14.0 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 23 Jun 2012 17:40:10 +0000 (UTC) Subject: [v6ops] Remaining milestones prior to IETF 84 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Jun 2012 17:40:11 -0000 Just a quick reminder. The following calender milestones are upcoming: *2012-07-02 (Monday):*Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PT (UTC -7).* We'll know when our meetings fall after: 2012-07-06 (Friday):*Final agenda to be published.* 00 draft must be in by this time. Consideration for the v6ops agenda is contingent on mailing list discussion. 2012-07-09 (Monday):*Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (UTC -7), upload usingIETF ID Submission Tool . Updated Drafts must be submitted by the 16th. *2012-07-16 (Monday):*Internet Draft final submission cut-off by 17:00 PT (UTC -7), upload usingIETF ID Submission Tool .* 2012-07-18 (Wednesday):*Draft Working Group agendas due by 17:00 PT (UTC -7), upload usingIETF Meeting Materials Management Tool . *2012-07-29 - 2012-08-03: 84th IETF Meeting in Vancouver, BC, Canada.* The ietf 84 milestones are conveniently available in ICS format from: http://www.ietf.org/meeting/84/IETF-84-important-dates.ics thanks joel From internet-drafts@ietf.org Sun Jun 24 17: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 412CB21F867E; Sun, 24 Jun 2012 17:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 oVzuKGbbNds5; Sun, 24 Jun 2012 17:29:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8FA21F8629; Sun, 24 Jun 2012 17:29:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21 Message-ID: <20120625002907.24191.87700.idtracker@ietfa.amsl.com> Date: Sun, 24 Jun 2012 17:29:07 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Mon, 25 Jun 2012 00:29: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 : 464XLAT: Combination of Stateful and Stateless Translati= on Author(s) : Masataka Mawatari Masanobu Kawashima Cameron Byrne Filename : draft-ietf-v6ops-464xlat-04.txt Pages : 18 Date : 2012-06-24 Abstract: This document describes an architecture (464XLAT) for providing limited 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 limited IPv4 access service to IPv6-only edge networks without encapsulation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kawashimam@vx.jp.nec.com Sun Jun 24 17:34: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 3B1A821F85F0 for ; Sun, 24 Jun 2012 17:34:10 -0700 (PDT) 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=[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 FbjeCnwyqKuR for ; Sun, 24 Jun 2012 17:34:06 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id 3125221F8566 for ; Sun, 24 Jun 2012 17:34:06 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q5P0Y5ar023285 for ; Mon, 25 Jun 2012 09:34:05 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q5P0Y5F18504 for v6ops@ietf.org; Mon, 25 Jun 2012 09:34:05 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id q5P0Y4iS026379 for ; Mon, 25 Jun 2012 09:34:04 +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-19223; Mon, 25 Jun 2012 09:33:20 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Mon, 25 Jun 2012 09:33:20 +0900 To: v6ops@ietf.org In-reply-to: <20120625002907.24191.87700.idtracker@ietfa.amsl.com> Message-Id: <20120625093320kawashimam@mail.jp.nec.com> References: <20120625002907.24191.87700.idtracker@ietfa.amsl.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Mon, 25 Jun 2012 09:33:19 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Mon, 25 Jun 2012 00:34:10 -0000 Hi all, We have published draft-ietf-v6ops-464xlat-04. Can we move forward to WGLC? Changes are: - adding in the "Terminology" of CLAT that the CLAT does not comply with "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix." that is described on Section 3.3 in RFC 6052. - splitting text of "using NAT44 and stateless XLATE on CLAT" and "using only stateless XLATE on CLAT" in the section of "IPv4/IPv6 Address Translation Chart" and "IPv6 Prefix Handling" instead of deleting the section of "Relationship between CLAT and NAT44" - adding the combination with BIH [RFC6535] in the section of "Introduction" and "Deployment Considerations". - adding explanations about the diagram in the section of "Network Architecture". - adding the section of "Appendix A. Examples of IPv4/IPv6 Address Translation". - deleting marketing and commercial phrases (JPIX trial service). All comments are welcome. 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-04.txt > Pages : 18 > Date : 2012-06-24 > >Abstract: > This document describes an architecture (464XLAT) for providing > limited 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 limited IPv4 > access service to IPv6-only edge networks without encapsulation. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-04 > >A diff from previous version is available at: >http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-04 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >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 Sun Jun 24 19:05: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 4A98A21F8630 for ; Sun, 24 Jun 2012 19:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=-0.550, 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 JQQr4OnQbaft for ; Sun, 24 Jun 2012 19:05:16 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E8A8721F85DD for ; Sun, 24 Jun 2012 19:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2142; q=dns/txt; s=iport; t=1340589916; x=1341799516; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ukZu5z49CR4lZCthW7BYlS1pWGM//58TB+2/ZbznE40=; b=AIxeSrb9FTXS+cDT4m+Cyw3bAkJa/F2PDYiY5bNglIJ9uyPMDuL4/0DW ATVF9sb0vQomu2gLp6rkur8bsgFfaBGWysOLzjSj23bmkV8EjysPvs+3Z HYOSuQ1vk5J/HtXVuoVxCS10ZzCerwDHib2FrM9NxwNGRgP0nAuN+pVCH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAALH50+tJV2b/2dsb2JhbABEtgCBB4IfDgQBJysUEgE+QicEDhkOh2mYe58EkFVgA5UujhuBZoJf X-IronPort-AV: E=Sophos;i="4.77,468,1336348800"; d="scan'208";a="95518208" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jun 2012 02:04:54 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5P24sAF021145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Jun 2012 02:04:54 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.234]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Sun, 24 Jun 2012 21:04:54 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: Prep for v6ops IETF 84 agenda Thread-Index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXQ== Date: Mon, 25 Jun 2012 02:04:53 +0000 Message-ID: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.231.59] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18994.001 x-tm-as-result: No--38.652700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <98679CE35EFA7D4BB2BAC51E5FD09A6F@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ron Bonica Subject: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jun 2012 02:05:20 -0000 I sat down this morning to assess our agenda. Interested in working group c= omment. # no update Jan 11 16:48 draft-yang-v6ops-fast6-pppoe-02.txt Feb 21 18:10 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt Feb 23 07:29 draft-carpenter-v6ops-icp-guidance-03.txt Feb 25 11:37 draft-ietf-v6ops-ivi-icmp-address-01.txt Feb 28 08:49 draft-chkpvc-enterprise-incremental-ipv6-00.txt Mar 5 17:46 draft-ma-v6ops-terminal-test-00.txt Mar 7 07:33 draft-carpenter-v6ops-label-balance-02.txt Mar 12 06:21 draft-vanrein-v6ops-6bed4-01.txt Mar 12 17:52 draft-chen-v6ops-nat64-experience-01.txt Mar 12 21:34 draft-liu-v6ops-ula-usage-analysis-02.txt Mar 13 04:59 draft-sunq-v6ops-contents-transition-03.txt Mar 30 03:27 draft-donley-v6ops-ce-router-design-00.txt Mar 31 11:33 draft-yang-v6ops-fast6-00.txt #no expressed interest Jun 20 11:33 draft-lopez-v6ops-dc-ipv6-02.txt Apr 27 12:07 draft-jiang-v6ops-v4v6mc-proxy-01.txt #out of charter Jun 24 07:59 draft-generic-v6ops-tunmtu-07.txt May 10 11:44 draft-templin-v6ops-isops-17.txt #in IESG queue May 30 11:10 draft-ietf-v6ops-wireline-incremental-ipv6-04.txt May 17 11:02 draft-ietf-v6ops-6204bis-09.txt #WGLC in v6ops or move to sunset4; awaiting AD direction May 8 10:14 draft-ietf-v6ops-464xlat-03.txt #potential for agenda Apr 30 13:58 draft-gundavelli-v6ops-community-wifi-svcs-04.txt May 16 02:12 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt May 22 21:30 draft-ietf-v6ops-ra-guard-implementation-04.txt #for agenda, perhaps ready for last call Jun 12 19:26 draft-ietf-v6ops-icp-guidance-01.txt For draft-ietf-v6ops-ivi-icmp-address, the last discussion was in April, an= d we were to expect an update. If that happens, I expect to bring that to t= he agenda.=20 Lee asked about draft-chkpvc-enterprise-incremental-ipv6 on the list, but I= see no update and I wasn't clear on the list commentary, whether the opera= tors want to discuss.=20 There is still, of course, time for folks to post -00 drafts (until 9 July)= ; if there is list discussion of those drafts, we will include them in the = agenda.= From despres.remi@laposte.net Mon Jun 25 00:34: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 0B09921F8508 for ; Mon, 25 Jun 2012 00:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[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 wrxv7TRhixdZ for ; Mon, 25 Jun 2012 00:34:24 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id E507921F850B for ; Mon, 25 Jun 2012 00:34:22 -0700 (PDT) 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 4E61294017D; Mon, 25 Jun 2012 09:34:14 +0200 (CEST) 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: <20120625093320kawashimam@mail.jp.nec.com> Date: Mon, 25 Jun 2012 09:34:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <79510968-0EE0-473F-A0B1-DD4B35092523@laposte.net> References: <20120625002907.24191.87700.idtracker@ietfa.amsl.com> <20120625093320kawashimam@mail.jp.nec.com> To: Masanobu Kawashima X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Mon, 25 Jun 2012 07:34:29 -0000 Hi, Masanobu-san, I have to confirm, no surprise, that I object to its BCP status because: - it proposes more than just a combination of existing RFCs - it has close relationship with subjects discussed in Softwires such as = MAP and 4rd, without serious examination of this relationship. OTOH, I also confirm that I would be pleased to support it if its status = is changed back to Informational (its original status) because: - It deals with a subject not covered by existing RFCs - It is based on ideas that have been, at least in part, tested in the = field. - Issues raised in the WG (other than the RFC status) have been dealt = with. Kind regards, RD Le 2012-06-25 =E0 02:33, Masanobu Kawashima a =E9crit : >=20 > Hi all, >=20 > We have published draft-ietf-v6ops-464xlat-04. > Can we move forward to WGLC? >=20 > Changes are: >=20 > - adding in the "Terminology" of CLAT that the CLAT does not > comply with "Both IPv4-translatable IPv6 addresses and > IPv4-converted IPv6 addresses SHOULD use the same prefix." > that is described on Section 3.3 in RFC 6052. >=20 > - splitting text of "using NAT44 and stateless XLATE on CLAT" > and "using only stateless XLATE on CLAT" in the section of > "IPv4/IPv6 Address Translation Chart" and "IPv6 Prefix > Handling" instead of deleting the section of "Relationship > between CLAT and NAT44" >=20 > - adding the combination with BIH [RFC6535] in the section of > "Introduction" and "Deployment Considerations". >=20 > - adding explanations about the diagram in the section of > "Network Architecture". >=20 > - adding the section of "Appendix A. Examples of IPv4/IPv6 > Address Translation". >=20 > - deleting marketing and commercial phrases (JPIX trial service). >=20 > All comments are welcome. >=20 > Regards, > Masanobu >=20 >=20 >>=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 : 464XLAT: Combination of Stateful and Stateless = Translation >> Author(s) : Masataka Mawatari >> Masanobu Kawashima >> Cameron Byrne >> Filename : draft-ietf-v6ops-464xlat-04.txt >> Pages : 18 >> Date : 2012-06-24 >>=20 >> Abstract: >> This document describes an architecture (464XLAT) for providing >> limited 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 limited IPv4 >> access service to IPv6-only edge networks without encapsulation. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-04 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-04 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC AccessTechnica, Ltd. =20 > Product Development Department =20 > Masanobu Kawashima =20 > kawashimam@vx.jp.nec.com =20 > http://www.necat.co.jp/ =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From diego@tid.es Mon Jun 25 00:58: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 79B9521F8513 for ; Mon, 25 Jun 2012 00:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_50=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 sMvwR+hP8OVp for ; Mon, 25 Jun 2012 00:58:54 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id A579421F8480 for ; Mon, 25 Jun 2012 00:58:53 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M6500G5RY636E@tid.hi.inet> for v6ops@ietf.org; Mon, 25 Jun 2012 09:58:51 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 5E.C5.26499.B3A18EF4; Mon, 25 Jun 2012 09:58:51 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M6500CETY634C@tid.hi.inet> for v6ops@ietf.org; Mon, 25 Jun 2012 09:58:51 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Mon, 25 Jun 2012 09:58:51 +0200 Date: Mon, 25 Jun 2012 07:58:50 +0000 From: "Diego R. Lopez" X-Originating-IP: [10.95.64.115] To: "v6ops@ietf.org" Message-id: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> Content-id: <7D163DEB6F4EDB4195AC7995A8ADA97B@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: Draft on DC migration to IPv6 Thread-index: AQHNUqhbgWRF7Aew1UKq7qhHvsQ1MQ== X-AuditID: 0a5f4068-b7f206d000006783-ac-4fe81a3bb33a X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42Lhivcz1LWWeuFvcGmyosXpY3uZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8aR3LUtBj1DFrnP7mBsYLwh2MXJySAiYSOz9dpsNwhaTuHBv PZDNxSEksJ1R4sHeW+wQzk9GiR1r/rNCOEsZJe7vvcIK0sIioCqx5folZhCbDch+1PybHcQW FlCT+LPyGTvEWAWJP+ces4DYIkA1p59eBqvnFbCU2LxjMxOIzSxgJvFjZwcTRFxQ4sfke0D1 HEBxdYkpU3IhSsQlmltvskDYihLTFjUwgtiMQFd/P7WGCWK8tsSte1+YIWw9iXs3W6FOEJBY suc8M4QtKvHy8T/WCYyis5BsnoVk8yyEzbOQbJ6FZPMCRtZVjGLFSUWZ6RkluYmZOekGhnoZ mXqZeaklmxjB0eKQsYNx+U6VQ4wCHIxKPLz+05/7C7EmlhVX5h5ilORgUhLlNRJ94S/El5Sf UpmRWJwRX1Sak1p8iFGCg1lJhJeDESjHm5JYWZValA+TkuHgUJLgtZcESgkWpaanVqRl5gBT AkyaiYMTpJ0HqD2YF6S9uCAxtzgzHSJ/ilFSSpxXDqRZACSRUZoH1/uKURzoSGHeaJAsDzB5 wXW9AhrIBDSw9cAzkIEliQgpqQbG+aw/eQ658mdF27bU8nNPrwmfZ5HedDD9mefuv+cZMusM z+W4fW/t3Xo1N/G8qH2a5g6G8xJp3KIrVrzzSronKqV9RsHmjXu1lei2pTaRTuuKNB49vq+/ bY1XuPNXM7WzxlmHsoT3C4Su3xmcLO3RsXzD52TGCczdGpzvBGucn9dWCcXZzVJiKc5INNRi LipOBADyufm/GwMAAA== Subject: [v6ops] Draft on DC migration to 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: Mon, 25 Jun 2012 07:58:58 -0000 SGksDQoNCkkndmUgcmVjZW50bHkgYmVlbiBhdCBhIHdvcmtzaG9wICh0aGUgQ2FycmllciBDbG91 ZCBTdW1taXQpIGluIHdoaWNoIG1vc3Qgb2YNCnRoZSBwcmVzZW50YXRpb25zIGFuZCBwcm9wb3Nh bHMgc3RpbGwgb25seSBjb25zaWRlciB2NC1iYXNlZCBzb2x1dGlvbnMsIHdpdGgNCnY2IGJlaW5n IGEgbWF0dGVyIG9mIGJvcmRlciB0cmFuc2xhdGlvbiBpZiBhdCBhbGwsIG9yIHZpZXcgdjYgYXMg YSBsb25nLXRlcm0NCmlzc3VlLCBub3QgY29uc2lkZXJpbmcgZWl0aGVyIHRoZSBwcm9ibGVtcyBv ciB0aGUgbmV3IHNvbHV0aW9ucyBpdCBjYW4gYnJpbmcgdG8NCmRhdGFjZW50ZXIgYXJjaGl0ZWN0 dXJlIGFzcGVjdHMuDQoNCldlIGhhdmUgcmVjZW50bHkgdXBkYXRlZCBhIGRyYWZ0IChkcmFmdC1s b3Blei12Nm9wcy1kYy1pcHY2LTAyKSwgcHJlY2lzZWx5IG9yaWVudGVkDQppbiB0aGF0IGRpcmVj dGlvbi4gUXVvdGluZyB0aGUgYWJzdHJhY3QsIHRoZSBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byAi cHJvdmlkZSBhDQpyZWZlcmVuY2UgZnJhbWV3b3JrIGZvciBkYXRhY2VudGVyIG9wZXJhdG9ycyBw bGFubmluZyBmb3IgYSBtaWdyYXRpb24gb2YgdGhlaXINCmluZnJhc3RydWN0dXJlcyB0byBJUHY2 LiBJdCBhaW1zIHRvIG9mZmVyIGEgc2NoZW1lIGZvciBldmFsdWF0aW5nIGRpZmZlcmVudCBwcm9k dWN0cw0KYW5kIGFyY2hpdGVjdHVyZXMsIGFuZCB0aGVyZWZvcmUgaXQgaXMgYWxzbyBhZGRyZXNz ZWQgdG8gbWFudWZhY3R1cmVycyBhbmQgc29sdXRpb24NCnByb3ZpZGVycywgc28gdGhleSBjYW4g dXNlIGl0IHRvIGdhdWdlIHRoZWlyIHNvbHV0aW9ucyIuDQoNCkEgbWVzc2FnZSBmcm9tIHRoZSBj aGFpciBub3RlcyB0aGF0IHRoaXMgZHJhZnQgaXMgYW1vbmcgdGhvc2Ugd2l0aCAibm8NCmV4cHJl c3NlZCBpbnRlcmVzdCIuIEFuZCBzaW5jZSBJIHRoaW5rIGRhdGFjZW50ZXIgaXNzdWVzIHNob3Vs ZCBiZSB1bmRlciB0aGUNCmdyb3VwIGNvbnNpZGVyYXRpb24sIEknZCBsaWtlIGFzayB5b3UgdG8g aGF2ZSBhIChzZWNvbmQ/KSBsb29rIGF0IGl0Lg0KDQpCZSBnb29kZSwNCg0KLS0NCiJFc3RhIHZl eiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpU ZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFp bDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgy IDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmln ZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0 cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmlj byBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVu ZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2Vp dmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Lg0KaHR0cDovL3d3 dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== From brian.e.carpenter@gmail.com Mon Jun 25 01:06: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 3ACB221F852B for ; Mon, 25 Jun 2012 01:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.616 X-Spam-Level: X-Spam-Status: No, score=-100.616 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, 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 jIYiffGwjelZ for ; Mon, 25 Jun 2012 01:06:06 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 877AD21F852A for ; Mon, 25 Jun 2012 01:06:06 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1182821eaa.31 for ; Mon, 25 Jun 2012 01:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ss9HoaTLT3sJFvF8QiOXLDCmifWnk1eJTuCEg4gNzEc=; b=Mh/0FMkYWJLbwUNeRtf07Eudf2ARV2N0rLiuDIrJAWbCvaGJzL0YhhcIan+Mz+at7B 9Iz+nylrOnqlvaTFkmF78SFHAK3gkej3IspN9xyGmZuSmYZeGyDWzacMne55uXTgkF7S V/+1/wXC5iI2EL5C3aONM8VD8Np/pjjvQYgjvM/0Te1H0yU+EWlBKqXzTq4lZxnKcIOF qiirCsZLaMFoKn1b828am06/M3JI26wCxdu152awEBSmpgofk9prgfzJ4nDJvZx1TysV r6Gg684oi4Wk7z4y4PU1Ix5i6mLhmLc9ZjuXcWT1bVaQ97XuCYXvlIn4T6msq8floBM8 YTpA== Received: by 10.14.119.3 with SMTP id m3mr2092462eeh.204.1340611565504; Mon, 25 Jun 2012 01:06:05 -0700 (PDT) Received: from [192.168.1.66] (host-2-102-219-12.as13285.net. [2.102.219.12]) by mx.google.com with ESMTPS id y54sm136085191eef.10.2012.06.25.01.06.03 (version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 01:06:04 -0700 (PDT) Message-ID: <4FE81BE4.6010309@gmail.com> Date: Mon, 25 Jun 2012 09:05:56 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Fred Baker (fred)" References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> In-Reply-To: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jun 2012 08:06:07 -0000 > Feb 23 07:29 draft-carpenter-v6ops-icp-guidance-03.txt We would like to ask for a WGLC, as discussion has died down. > Mar 7 07:33 draft-carpenter-v6ops-label-balance-02.txt This is replaced by draft-carpenter-flow-label-balancing-01 and draft-tarreau-extend-flow-label-balancing-00.txt. We are not planning to discuss these in v6ops for now. The first one doesn't suggest any protocol changes, so we could bring it back to v6ops if asked to so so. Regards Brian Carpenter From brian.e.carpenter@gmail.com Mon Jun 25 05:49: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 EFD2721F8597 for ; Mon, 25 Jun 2012 05:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.638 X-Spam-Level: X-Spam-Status: No, score=-100.638 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, 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 7hH3kcFrjvG9 for ; Mon, 25 Jun 2012 05:49:46 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB5ED21F8596 for ; Mon, 25 Jun 2012 05:49:45 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1306237eaa.31 for ; Mon, 25 Jun 2012 05:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R4B54uhrAiLbAGxrCQWckyxtc0wSn0Ik1JhnjBtASoM=; b=qXeHD3Bfcqb83znW/6Q1uSv3wDfptck/KtyiJDMjiUNoco/D8fWJi9TSxK7Qvxk8xk xREmFLE6YHx2+m8WiCgIPOBdTbkRuE3TQl5tZGtk/uB10Bt6tlguUEwOEK97+KsStI+R IwQO3o9+ONXY2FRAsOzma73rd1IdOzErRW8Is+wIQ5WMQDD295/JhlZcweY5HXaUoJ8J JMwGR5nf9zkee8fywMo3JnrjQ/tZswDSh6u1AiPemCXaWBNib7AIhe/tuqEaXw4Yog2t bqrUpxXay1hLNPvwuOa0+fRnIIBbvGryqRNfmXkPLOLXMjPMVvpn5P0BQOj/2vuUfrji TNJQ== Received: by 10.14.99.78 with SMTP id w54mr2074723eef.135.1340628584896; Mon, 25 Jun 2012 05:49:44 -0700 (PDT) Received: from [192.168.1.67] (host-2-102-219-12.as13285.net. [2.102.219.12]) by mx.google.com with ESMTPS id q53sm138518533eef.8.2012.06.25.05.49.43 (version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 05:49:43 -0700 (PDT) Message-ID: <4FE85E64.1010400@gmail.com> Date: Mon, 25 Jun 2012 13:49:40 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Diego R. Lopez" References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> In-Reply-To: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on DC migration to 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: Mon, 25 Jun 2012 12:49:50 -0000 Diego, I think the real problem is persuading the people who manage data centres that there is an economic and business incentive to support native IPv6 (as opposed to support native IPv6 customers, which they probably understand). In some cases the arguments are technical perhaps (for example, if the load balancers use direct server return, making the servers dual stack will be the only reasonable approach). But in general just showing people how to design the technical solution is not enough for them to adopt it. So while I understand the idea of your draft, it doesn't solve the problem of motivation. Also I think it's unlikely that all DCs fit the single framework you describe - surely there is a wider range of scenarios? That's why the IETF in general does better when documenting individual components and solutions than when tackling frameworks. Also there should be a clarification of how this draft relates to draft-chkpvc-enterprise-incremental-ipv6. Please refer to draft-carpenter-flow-label-balancing instead of draft-carpenter-v6ops-label-balance. Regards Brian Carpenter On 2012-06-25 08:58, Diego R. Lopez wrote: > Hi, >=20 > I've recently been at a workshop (the Carrier Cloud Summit) in which mo= st of > the presentations and proposals still only consider v4-based solutions,= with > v6 being a matter of border translation if at all, or view v6 as a long= -term > issue, not considering either the problems or the new solutions it can = bring to > datacenter architecture aspects. >=20 > We have recently updated a draft (draft-lopez-v6ops-dc-ipv6-02), precis= ely oriented > in that direction. Quoting the abstract, the document is intended to "p= rovide a > reference framework for datacenter operators planning for a migration o= f their > infrastructures to IPv6. It aims to offer a scheme for evaluating diffe= rent products > and architectures, and therefore it is also addressed to manufacturers = and solution > providers, so they can use it to gauge their solutions". >=20 > A message from the chair notes that this draft is among those with "no > expressed interest". And since I think datacenter issues should be unde= r the > group consideration, I'd like ask you to have a (second?) look at it. >=20 > Be goode, >=20 > -- > "Esta vez no fallaremos, Doctor Infierno" >=20 > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ >=20 > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- >=20 >=20 > ________________________________ >=20 > Este mensaje se dirige exclusivamente a su destinatario. Puede consulta= r nuestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo electr=C3= =B3nico en el enlace situado m=C3=A1s abajo. > This message is intended exclusively for its addressee. We only send an= d receive email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jared@puck.nether.net Mon Jun 25 06:28: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 F113F21F85CF for ; Mon, 25 Jun 2012 06:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZhquGunPLWb for ; Mon, 25 Jun 2012 06:28:43 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7B44521F856D for ; Mon, 25 Jun 2012 06:28:43 -0700 (PDT) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q5PDSZBS026186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Jun 2012 09:28:40 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> Date: Mon, 25 Jun 2012 09:28:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> To: "Diego R. Lopez" X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 25 Jun 2012 09:28:41 -0400 (EDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on DC migration to 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: Mon, 25 Jun 2012 13:28:44 -0000 On Jun 25, 2012, at 3:58 AM, Diego R. Lopez wrote: > A message from the chair notes that this draft is among those with "no > expressed interest". And since I think datacenter issues should be = under the > group consideration, I'd like ask you to have a (second?) look at it. A datacenter is usually just a managed customer CPE environment. I'm = not sure how this differs from any other service delivery for IP, without regard = to version number. Now my observation: Generally the "data centers" have had a different class of equipment in = there that did not include IPv6 roadmap as part of their original RFP. The biggest problem has been customer expectations, that one can't = touch/move the service to IPv6 capable equipment, or that the risk of upgrading the hardware is = too high (or expensive). These are business drivers that I've seen trump a = technology decision. - Jared= From joelja@bogus.com Mon Jun 25 08: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 2EE8121F8517 for ; Mon, 25 Jun 2012 08:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOpUKZIPbCiz for ; Mon, 25 Jun 2012 08:25:43 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9500121F84D6 for ; Mon, 25 Jun 2012 08:25:43 -0700 (PDT) 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 q5PFPg21028749 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 25 Jun 2012 15:25:43 GMT (envelope-from joelja@bogus.com) Message-ID: <4FE882F1.7080803@bogus.com> Date: Mon, 25 Jun 2012 08:25:37 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: IPv6 Ops WG 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, 25 Jun 2012 15:25:43 +0000 (UTC) Subject: [v6ops] address reservation for discard prefix recorded... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jun 2012 15:25:44 -0000 http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml#note8 http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-discard-prefix-05 From Fred.L.Templin@boeing.com Mon Jun 25 09:21: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 41F7121F8549 for ; Mon, 25 Jun 2012 09:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 YFW7IVSuIqq4 for ; Mon, 25 Jun 2012 09:21:29 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id B3E5421F8539 for ; Mon, 25 Jun 2012 09:20:57 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5PGKsP2008600 for ; Mon, 25 Jun 2012 11:20:54 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5PGKr6S008586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2012 11:20:54 -0500 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5PGKrUq008234; Mon, 25 Jun 2012 09:20:53 -0700 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5PGKqVU008160 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 25 Jun 2012 09:20:53 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Mon, 25 Jun 2012 09:20:52 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" Date: Mon, 25 Jun 2012 09:20:50 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: AQHNUMAMI2lkh8Q9EkiB3bN18+NwHJcLN42g Message-ID: References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> <9B27D3CA-DDF1-4D48-9988-EB218EC2159A@cisco.com> In-Reply-To: <9B27D3CA-DDF1-4D48-9988-EB218EC2159A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jun 2012 16:21:52 -0000 Hi Fred, > -----Original Message----- > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Friday, June 22, 2012 5:32 PM > To: Templin, Fred L > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 >=20 > On Jun 22, 2012, at 3:35 PM, Templin, Fred L wrote: >=20 > >> The reason to not do inner fragmentation, if memory serves, has to do > with > >> the behavior of fragmentation in the network and its effect on > >> communications. For example, suppose you and I are in 9K clean network= s > >> (so the TCP MSS starts out as 9K), my link to the public network has a= n > >> MTU of 1500, and somewhere en route to you there is another link with > an > >> MTU of 1400. When I send a 9K packet, it will become six 1500 byte > packets > >> with a small caboose that picks up the size of five IP headers (IPv4 o= r > >> IPv6), and what you will receive is six 1400 byte packets interspersed > >> with six 100+IP byte packets, followed by the original caboose. What i= f > >> the fragmenting router's queue, at the time of fragmentation, was one > >> packet short of the needed capacity? Maybe the retransmission follows = a > >> different path and is fragmented differently, resulting in funny > overlaps > >> whose handling isn't very well specified. There's nothing *incorrect* > >> about a stream of 13 packets of various sizes being reassembled, but > >> integrating retransmissions gets messy. IIRC, they just wanted to clea= n > >> that up. > > > > I think you could probably extend this to even worse cases > > if you said that the 1400 link was followed by a 1380 link, > > which was followed by a 1350 link, etc. The caboose-trimming > > would become pathological very quickly. So, why not require > > that fragmenting routers make all fragments to be roughly > > the same size (instead of roughly MTU-sized) so they will > > fit through smaller links further down the line? >=20 >=20 > OOO M M GGG > O O MM MM G G > O O M M M M G > O O M M M G GG > O O M M G G > O O M M G G > OOO M M GGG >=20 >=20 > If you want to go there, there are some 20-year-old discussions I need fo= r > you to look at. Options proposed include at least > - someone (a router, a host) fragmenting traffic should make all chunks > the same size > - the first N-1 chunks should be approximately MTU-sized and the last a > caboose > - the last N-1 chunks should be approximately MTU-sized and the first a > caboose I guess you are talking about p.45 of RFC1812? I've looked at that many times and have always wondered about the option to lead with a caboose as the first fragment. As a receiver, I'd like to be able to look at the first fragment as a way of measuring the path MTU, but I don't get that option when the first fragment is tiny.=20 > There have been passionate discussions, each approach having proponents > with believed-by-them-to-be-good arguments for their position. And I'm > pretty sure there were other positions. >=20 > The one thing I'll take serious exception to is a proposal that a router > reassemble packets and then re-fragment some other way in the normal > course of doing business. Per RFC1812, I agree for packets that are just passing through the router, but the router has to reassemble packets that are explicitly addressed to itself. RFC1122 also says that the router only needs to reassemble 576 at minimum so that is all that the tunnel near end can assume if the tunnel far end is (or might be) a router. > Excellent fodder for an IRTF draft. Go for it, with my blessing. I, > personally, won't be there to keep track of the angels and pinheads... I guess you didn't like the departure into fragmentation technique discussions. We don't have to go there, so we can back off from that line of discussion if you find it offensive. Thanks - Fred fred.l.templin@boeing.com From touch@isi.edu Mon Jun 25 09:54: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 79C4121F852D for ; Mon, 25 Jun 2012 09:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 YGpxtM7LE0L3 for ; Mon, 25 Jun 2012 09:54:58 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id DBF4921F854D for ; Mon, 25 Jun 2012 09:54:58 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q5PGs69V011440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jun 2012 09:54:06 -0700 (PDT) Message-ID: <4FE897AE.5040606@isi.edu> Date: Mon, 25 Jun 2012 09:54:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> <9B27D3CA-DDF1-4D48-9988-EB218EC2159A@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jun 2012 16:54:59 -0000 On 6/25/2012 9:20 AM, Templin, Fred L wrote: > Hi Fred, > >> -----Original Message----- >> From: Fred Baker (fred) [mailto:fred@cisco.com] ... >> If you want to go there, there are some 20-year-old discussions I need for >> you to look at. Options proposed include at least >> - someone (a router, a host) fragmenting traffic should make all chunks >> the same size >> - the first N-1 chunks should be approximately MTU-sized and the last a >> caboose >> - the last N-1 chunks should be approximately MTU-sized and the first a >> caboose > > I guess you are talking about p.45 of RFC1812? I've looked > at that many times and have always wondered about the option > to lead with a caboose as the first fragment. As a receiver, > I'd like to be able to look at the first fragment as a way > of measuring the path MTU, but I don't get that option when > the first fragment is tiny. Since there is no requirement that the first fragment be "as large as possible", it is inappropriate to infer anything from its size anyway. >> There have been passionate discussions, each approach having proponents >> with believed-by-them-to-be-good arguments for their position. And I'm >> pretty sure there were other positions. >> >> The one thing I'll take serious exception to is a proposal that a router >> reassemble packets and then re-fragment some other way in the normal >> course of doing business. > > Per RFC1812, I agree for packets that are just passing > through the router, but the router has to reassemble packets > that are explicitly addressed to itself. I don't think there's any disagreement there. There are two kinds of packets "router boxes" process: forwarded packets (when the box acts like a router) packets originating/terminating at the router (when the box acts like a host) Note that tunnel ingress/egress processing falls into the latter category for the outer packet, and the former for the inner packet. > RFC1122 also says > that the router only needs to reassemble 576 at minimum > so that is all that the tunnel near end can assume if the > tunnel far end is (or might be) a router. RFC1122 applies only to hosts (and routers when they act as a host, e.g., as a source or destination of packets). And yes, 576 is the largest reassembled MTU for IPv4 (the largest MTU, e.g., that you can assume for fragments, is 64). Joe From Tina.Tsou.Zouting@huawei.com Mon Jun 25 10:41: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 3AAE021F853F for ; Mon, 25 Jun 2012 10:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.121 X-Spam-Level: X-Spam-Status: No, score=-6.121 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 7vU3KZc1COtQ for ; Mon, 25 Jun 2012 10:41:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B028821F8546 for ; Mon, 25 Jun 2012 10:41:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHM13318; Mon, 25 Jun 2012 13:41:50 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 25 Jun 2012 10:40:04 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.109]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Mon, 25 Jun 2012 10:40:01 -0700 From: Tina TSOU To: Brian E Carpenter , Fred Baker Thread-Topic: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-00) Thread-Index: AQHNT4yOq6T3bI5P5EKyzlUVoj4Gh5cLUz9A Date: Mon, 25 Jun 2012 17:40:01 +0000 Message-ID: References: <000301cd4801$1f059880$5d10c980$@asgard.org> <58DBDF90-CE65-467C-A7C4-F6A1C9E69642@cisco.com> <4FE2E2F2.8000107@gmail.com> In-Reply-To: <4FE2E2F2.8000107@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Operations Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise-incremental-ipv6-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, 25 Jun 2012 17:41:52 -0000 In the assumptions, it is mentioned to provide native IP wherever possible.= If the native IP is IPv6, it contradicts the sentence "want to minimize le= vel of disruption". If native IPv6 is to be provided in the enterprise netw= ork, the devices have to be upgraded to support IPv6. Only devices which ha= s are already support IPv6 would not have to be upgraded, what about the re= st of the devices? Should their software be upgraded or should NAT64/transi= tion be used at first and then slowly the entire network migrated to native= IPv6. In the phased approach, the two statements for implementation of IPv6 in th= e internal network does not provide strong reasons for deploying IPv6 inter= nally. The statements about deployment of IPv6 in the internal enterprise s= hould indicate the increasing need of the number of IP address internally i= n a company. As IPv6 is enabled by default in all operating systems, deploy= ing IPv6 internally would not be a very difficult task. The priority always= goes to external network first and simultaneously should be implemented in= the internal networks. Else if it is not simultaneously done, again transi= tion technologies need to be configured in the edge routers for communicati= on between the external and internal networks. In analyzing the network infrastructure stage, more than just IPv6 capable,= the device should be checked for support of the applications required by t= he enterprise. There are routers that do not support MPLS VPN over IPv6, bu= t are ipv6 capable. Thus, only being IPv6 capable is not enough, unless it = is ensured its firmware supports the required applications over IPv6. Address plan: Specifying change in A DNS records to quad A records is also = important. So that when DNS query is made, appropriate DNS reply is ensured= .=20 Tools and assessment: Not only the monitoring tools should be checked for I= Pv6 enable, the devices running these tools should also be checked for memo= ry. IPv6 applications will need more memory to store 128 bit addresses. The= processing logic might also demand more processor memory. "will likely time time "-----Page 13, second last para ( some correction) While using PI for advertising routes, the routes when advertised to two up= stream providers should have route filters to distribute traffic in the two= paths according to business requirements.=20 Provider may introduce challenges since traffic utilizing a given PA assign block would be expected to flow tears the assigning provider for entry to the Internet. (Excepted to flow tears)? Didn't get the meanin= g of the line. In the planning stage of deployment of IPv6, as far as possible native IPv6= should be employed. Transition technologies should be used only in impossi= ble cases. Transition technologies poses security threat and complexity, an= d thus does not serve the true purpose of IPv6 deployment in the network.=20 Tina @ 2001:db8:1:ffff:e8e2:7822:9d12:e12e > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Thursday, June 21, 2012 2:02 AM > To: Fred Baker > Cc: IPv6 Operations > Subject: Re: [v6ops] Enterprise Guidance on IPv6 (draft-chkpvc-enterprise= - > incremental-ipv6-00) >=20 > On 2012-06-18 12:14, Fred Baker wrote: > > Let me put a straight question to the working group. The > > topic is: > > > > http://tools.ietf.org/html/draft-chkpvc-enterprise-incremental-ipv6 > > "Enterprise Incremental IPv6", Lee Howard, Tim Chown, KK > > Chittimaneni, Yanick Pouffary, Eric Vyncke, Victor Kuarsingh, > > 27-Feb-12 > > > > Read the v6ops charter > > (http://datatracker.ietf.org/wg/v6ops/charter/). Do you feel > > that this document is within the charter? >=20 > Yes, under goal 1 (operational issues). >=20 > > If so, do you feel > > that the document and its recommendations represent useful > > advice concerning operational practice in an enterprise > > (e.g., edge network that is large enough to provide its own > > IT services as opposed to contracting those) IPv6 network? >=20 > The aims of the document are admirable and the range of topics > seems about right. However, I'd have expected to see separate > sections on major topics like DNS, DHCPv6, choice of routing > protocol (it's a bit facile to say "if using OSPF, use OSPF"), > address management tools, ops and management tools, firewalls, > load balancers, etc. I would also expect discussion of the > approach to transition tools. >=20 > This is really a book-length topic. That's one reason why we bit > off a smaller problem for draft-ietf-v6ops-icp-guidance-01.txt. >=20 > > Based on that analysis and viewpoint, would you support its > > adoption as a working group draft? >=20 > My concern is whether the document is too ambitious. If it is to > be detailed enough to be useful, maybe it needs to be split into > a number of separate documents. >=20 > Brian >=20 > > > > I am of course interested in views across the working group. > > In this particular case, however, I would find especially > > interesting the commentary of enterprise network operators. > > > > On Jun 11, 2012, at 11:36 AM, Lee Howard wrote: > > > >> When discussed in Taipei, it seemed there was real interest > >> in updating guidance for enterprise networks. From lack of > >> list discussion, it now appears there's no interest in the > >> WG. > >> > >> 1. Are people interested? 2. Should we let it die? 3. > >> Should we pursue other avenues of publication? > >> > >> Lee > >> > >>> -----Original Message----- From: v6ops-bounces@ietf.org > >>> [mailto:v6ops-bounces@ietf.org] On Behalf Of > >> Victor > >>> Kuarsingh Sent: Monday, March 26, 2012 7:42 AM To: IPv6 > >>> Operations Subject: Re: [v6ops] > >>> draft-chkpvc-enterprise-incremental-ipv6-00 > >>> > >>> IPv6 WG, > >>> > >>> I would like to kick off some comments on this draft for > >>> other group > >> members to comment. > >>> I do think (Bias noted) that this material is useful for > >>> Enterprises who > >> need to being and/or > >>> move their IPv6 deployments. Many (of those I have > >>> worked with thus far) > >> are bogged > >>> down with personnel who are overwhelmed with what it may > >>> take to get IPv6 > >> moving on > >>> their networks. > >>> > >>> The draft breaks the challenge down by areas of focus > >>> (rolled into "Phases") which can help put this large > >>> challenge into bite size chunks > >> for them. The draft > >>> also provides some valid contextual information around > >>> IPv6 and highlights areas which should be looked at. > >>> > >>> Given the good momentum we now have in the operator > >>> space, it would be > >> good to see this > >>> move forward into the Enterprise space. I think such > >>> documents can help > >> many of those still > >>> waffling (too many to count) to start acting. > >>> > >>> Regards, > >>> > >>> Victor K > >>> > >>> > >>> On 12-03-22 8:02 AM, "Tim Chown" > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> Due to a typo in the draft name, this draft didn't hit > >>>> Fred's automated WG tools, so the authors would like to > >>>> raise the draft on the list now with a view to securing > >>>> a slot in Paris to discuss its value and content. > >>>> > >>>> In Taipei there was a comment in the WG session that > >>>> there is no up-to-date v6ops guidance on enterprise > >>>> networks, while other scenarios do have such texts. So > >>>> at the mic I invited people to join an effort to put > >>>> something together. There is a good breadth of > >>>> experience across the people who stepped forward, and > >>>> the result is available as > >>>> > >>>> http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6- > 00.txt > >>>> > >>>> > >>>> Does the WG think the subject matter of this draft is > >>>> one we should pursue in the WG? If so, is the > >>>> structure and content appropriate? We need some > >>>> positive feedback and comments in order for Fred to > >>>> schedule us time in Paris. > >>>> > >>>> We have had a couple of people contact us off-list > >>>> offering to help develop the content. But we'd like > >>>> some feedback from the WG before investing more time in > >>>> doing so. The -00 text is somewhat "rough", but we > >>>> feel it could be polished into something quite useful > >>>> for the community. > >>>> > >>>> Tim > >>>> > >>>> _______________________________________________ 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 > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Mon Jun 25 11:18: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 CD2AC11E807F for ; Mon, 25 Jun 2012 11:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 iiqIY0Cm+BNY for ; Mon, 25 Jun 2012 11:18:20 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBE121F8467 for ; Mon, 25 Jun 2012 11:18:20 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5PIIJou015239 for ; Mon, 25 Jun 2012 11:18:19 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5PIIIOJ015205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2012 11:18:19 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5PIII7k004175; Mon, 25 Jun 2012 13:18:18 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5PIIH6u004106 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 25 Jun 2012 13:18:17 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Mon, 25 Jun 2012 11:18:17 -0700 From: "Templin, Fred L" To: Joe Touch Date: Mon, 25 Jun 2012 11:18:16 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1S809vxh2EQrDRS/+zcnl2MQ+2FAACVG2g Message-ID: References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> <9B27D3CA-DDF1-4D48-9988-EB218EC2159A@cisco.com> <4FE897AE.5040606@isi.edu> In-Reply-To: <4FE897AE.5040606@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jun 2012 18:18:21 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Monday, June 25, 2012 9:54 AM > To: Templin, Fred L > Cc: Fred Baker (fred); v6ops@ietf.org WG > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 >=20 >=20 > On 6/25/2012 9:20 AM, Templin, Fred L wrote: > > Hi Fred, > > > >> -----Original Message----- > >> From: Fred Baker (fred) [mailto:fred@cisco.com] > ... > >> If you want to go there, there are some 20-year-old discussions I need > for > >> you to look at. Options proposed include at least > >> - someone (a router, a host) fragmenting traffic should make all > chunks > >> the same size > >> - the first N-1 chunks should be approximately MTU-sized and the > last a > >> caboose > >> - the last N-1 chunks should be approximately MTU-sized and the > first a > >> caboose > > > > I guess you are talking about p.45 of RFC1812? I've looked > > at that many times and have always wondered about the option > > to lead with a caboose as the first fragment. As a receiver, > > I'd like to be able to look at the first fragment as a way > > of measuring the path MTU, but I don't get that option when > > the first fragment is tiny. >=20 > Since there is no requirement that the first fragment be "as large as > possible", it is inappropriate to infer anything from its size anyway. Maybe or maybe not. If the first fragment is significantly larger than the minimum link MTU isn't it fair to say that it is likely to approximate the largest unfragmented packet that can traverse the tunnel? The only risk then is in under-estimating the tunnel MTU (and not over-estimating). An historical anecdote - Fred B. may know more about this. In the mid-1980's companies such as Digital Equipment Corporation produced 1st generation Ethernet gear that could not always keep up with wire-speed. I know of at least one of these 1st generation NICs that would reset itself if it dropped a packet, which happened quite frequently if the card received a burst of fragments from a large fragmented datagram. Was this the genesis of the RFC1918 text that says: "Work with slow machines leads us to believe that if it is necessary to fragment messages, sending the small IP fragment first maximizes the chance of a host with a slow interface of receiving all the fragments." ?? =20 > >> There have been passionate discussions, each approach having proponent= s > >> with believed-by-them-to-be-good arguments for their position. And I'm > >> pretty sure there were other positions. > >> > >> The one thing I'll take serious exception to is a proposal that a > router > >> reassemble packets and then re-fragment some other way in the normal > >> course of doing business. > > > > Per RFC1812, I agree for packets that are just passing > > through the router, but the router has to reassemble packets > > that are explicitly addressed to itself. >=20 > I don't think there's any disagreement there. There are two kinds of > packets "router boxes" process: > forwarded packets (when the box acts like a router) > packets originating/terminating at the router (when the box acts > like a host) >=20 > Note that tunnel ingress/egress processing falls into the latter > category for the outer packet, and the former for the inner packet. Right. And, the philosophy I'm suggesting is that the router kick the can down the road as far as possible toward the inner packet destination as long as it is done within the specified limits for inner fragmentation and reassembly. When that can't be done, then the router at the other end of the tunnel has to do the reassembly. > > RFC1122 also says > > that the router only needs to reassemble 576 at minimum > > so that is all that the tunnel near end can assume if the > > tunnel far end is (or might be) a router. >=20 > RFC1122 applies only to hosts (and routers when they act as a host, Right; router acting as host is the case of interest. > e.g., as a source or destination of packets). And yes, 576 is the > largest reassembled MTU for IPv4 (the largest MTU, e.g., that you can > assume for fragments, is 64). Did you mean 68? Thanks - Fred fred.l.templin@boeing.com =20 > Joe From touch@isi.edu Mon Jun 25 11:30: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 A2CFA21F848A for ; Mon, 25 Jun 2012 11:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.061 X-Spam-Level: X-Spam-Status: No, score=-103.061 tagged_above=-999 required=5 tests=[AWL=-0.462, 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 71GZSSCXeijp for ; Mon, 25 Jun 2012 11:30:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 05D6821F8471 for ; Mon, 25 Jun 2012 11:30:02 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q5PITNaV029104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jun 2012 11:29:23 -0700 (PDT) Message-ID: <4FE8AE03.4080603@isi.edu> Date: Mon, 25 Jun 2012 11:29:23 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> <9B27D3CA-DDF1-4D48-9988-EB218EC2159A@cisco.com> <4FE897AE.5040606@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jun 2012 18:30:02 -0000 Hi Fred, On 6/25/2012 11:18 AM, Templin, Fred L wrote: > Hi Joe, ... >> Since there is no requirement that the first fragment be "as large as >> possible", it is inappropriate to infer anything from its size anyway. > > Maybe or maybe not. If the first fragment is significantly > larger than the minimum link MTU isn't it fair to say that > it is likely to approximate the largest unfragmented packet > that can traverse the tunnel? No; there are no requirements on how packets are fragmented, so making any assumptions based on any subset of fragments is not being "liberal in what you accept". > The only risk then is in > under-estimating the tunnel MTU (and not over-estimating). Technically that's true - any fragment you see must have gotten through, so you can assume that the E2E path supports at least that size fragment (for the given endpoints; for a tunnel that's the ingress/egress if we're talking about outer fragmentation). However, I'm not sure that "at least this big" helps all that much for any given fragment. You'd need to see a stream over time to draw any reasonable conclusions. > An historical anecdote - Fred B. may know more about this. > In the mid-1980's companies such as Digital Equipment > Corporation produced 1st generation Ethernet gear that > could not always keep up with wire-speed. I know of at > least one of these 1st generation NICs that would reset > itself if it dropped a packet, which happened quite > frequently if the card received a burst of fragments > from a large fragmented datagram. Was this the genesis > of the RFC1918 text that says: I think you mean RFC 1812 ;-) That RFC includes a discussion of various rationales for how to fragment, and basically recommends only that routers don't unnecessarily create more fragments than necessary. > "Work with slow machines leads us to believe that if it is > necessary to fragment messages, sending the small IP fragment > first maximizes the chance of a host with a slow interface of > receiving all the fragments." > > ?? I would expect the excerpt above refers to systems where the need to create a new entry for a new fragment interferes with receive processing, so a small first fragment helps in that case. It does assume that there's no persistent reordering, and assumes a somewhat broken receiver anyway though, IMO. >>>> There have been passionate discussions, each approach having proponents >>>> with believed-by-them-to-be-good arguments for their position. And I'm >>>> pretty sure there were other positions. >>>> >>>> The one thing I'll take serious exception to is a proposal that a >> router >>>> reassemble packets and then re-fragment some other way in the normal >>>> course of doing business. >>> >>> Per RFC1812, I agree for packets that are just passing >>> through the router, but the router has to reassemble packets >>> that are explicitly addressed to itself. >> >> I don't think there's any disagreement there. There are two kinds of >> packets "router boxes" process: >> forwarded packets (when the box acts like a router) >> packets originating/terminating at the router (when the box acts >> like a host) >> >> Note that tunnel ingress/egress processing falls into the latter >> category for the outer packet, and the former for the inner packet. > > Right. And, the philosophy I'm suggesting is that the > router kick the can down the road as far as possible > toward the inner packet destination as long as it is > done within the specified limits for inner fragmentation > and reassembly. When that can't be done, then the router > at the other end of the tunnel has to do the reassembly. Routers shouldn't kick problems down the road towards the destination. They should fragment inner packets ONLY when they need to, and that necessity doesn't exist for tunnels. ... >> e.g., as a source or destination of packets). And yes, 576 is the >> largest reassembled MTU for IPv4 (the largest MTU, e.g., that you can >> assume for fragments, is 64). > > Did you mean 68? Yeah - typed too quick. 68. Joe From Fred.L.Templin@boeing.com Mon Jun 25 11:39: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 A48FF11E8125 for ; Mon, 25 Jun 2012 11:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 PLmG+plQcZXl for ; Mon, 25 Jun 2012 11:39:55 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 22A6511E8120 for ; Mon, 25 Jun 2012 11:39:55 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5PIds43011388 for ; Mon, 25 Jun 2012 11:39:54 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5PIdrN7011376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2012 11:39:54 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5PIdrW9015897; Mon, 25 Jun 2012 13:39:53 -0500 Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5PIdrve015877 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 25 Jun 2012 13:39:53 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Mon, 25 Jun 2012 11:39:52 -0700 From: "Templin, Fred L" To: Joe Touch Date: Mon, 25 Jun 2012 11:39:51 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1TAIfZBMIuP28BQYSSwOXmZL5wMQAARpIg Message-ID: References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> <9B27D3CA-DDF1-4D48-9988-EB218EC2159A@cisco.com> <4FE897AE.5040606@isi.edu> <4FE8AE03.4080603@isi.edu> In-Reply-To: <4FE8AE03.4080603@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jun 2012 18:39:55 -0000 > >Was this the genesis > > of the RFC1918 text that says: >=20 > I think you mean RFC 1812 ;-) That's about the 10th time I've mis-typed that today... no associations btw the two documents intended! :^} Fred From Fred.L.Templin@boeing.com Mon Jun 25 13: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 D3D5D21F8585 for ; Mon, 25 Jun 2012 13:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 7iquZChYx+NY for ; Mon, 25 Jun 2012 13:25:23 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCDD21F8582 for ; Mon, 25 Jun 2012 13:25:23 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5PKPMRV026283 for ; Mon, 25 Jun 2012 13:25:22 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5PKPL4r026271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jun 2012 13:25:21 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5PKPLZQ004669; Mon, 25 Jun 2012 15:25:21 -0500 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5PKPKYf004626 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 25 Jun 2012 15:25:21 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 25 Jun 2012 13:25:20 -0700 From: "Templin, Fred L" To: Joe Touch Date: Mon, 25 Jun 2012 13:25:19 -0700 Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: Ac1TAIfZBMIuP28BQYSSwOXmZL5wMQAC2InA Message-ID: References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> <9B27D3CA-DDF1-4D48-9988-EB218EC2159A@cisco.com> <4FE897AE.5040606@isi.edu> <4FE8AE03.4080603@isi.edu> In-Reply-To: <4FE8AE03.4080603@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jun 2012 20:25:23 -0000 Hi again Joe, > > "Work with slow machines leads us to believe that if it is > > necessary to fragment messages, sending the small IP fragment > > first maximizes the chance of a host with a slow interface of > > receiving all the fragments." > > > > ?? > =20 > I would expect the excerpt above refers to systems where the need to > create a new entry for a new fragment interferes with receive > processing, so a small first fragment helps in that case. It does assume > that there's no persistent reordering, and assumes a somewhat broken > receiver anyway though, IMO. Actually, I have some real-world experience behind this. In 1986, I was asked to look into a problem where a DEC VAXStation with a DELQA NIC was performing very poorly as an NFS file server. We found that the DELQA actually reset itself if it ran out of receive ring buffers, which is exactly what was happening when enough fragmented IPv4/UDP/NFS packets arrived in bursts. There was literally nothing to be done for it - the hardware was deemed broken, and the VAXStation/DELQA configuration was disqualified as an NFS server platform. Right around the same time, a DEC colleague was off writing "Fragmentation Considered Harmful", which (IMO) is where the whole fragmentation/reassembly/MTU debate went sideways. I was never consulted on that writing, but my input would have been that the protocol shouldn't be changed to accommodate broken hardware. We are still living with the "harmful" stigma today, but we need to get beyond that if we're going to accommodate tunnels. Fred fred.l.templin@boeing.com From touch@isi.edu Mon Jun 25 13:39: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 D51EE11E8093 for ; Mon, 25 Jun 2012 13:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.028 X-Spam-Level: X-Spam-Status: No, score=-105.028 tagged_above=-999 required=5 tests=[AWL=1.571, 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 f6-+qCg59qIa for ; Mon, 25 Jun 2012 13:39:27 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id CA1F311E808E for ; Mon, 25 Jun 2012 13:39:27 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5PKd6jc012015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jun 2012 13:39:06 -0700 (PDT) Message-ID: <4FE8CC6A.6040708@isi.edu> Date: Mon, 25 Jun 2012 13:39:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> <9B27D3CA-DDF1-4D48-9988-EB218EC2159A@cisco.com> <4FE897AE.5040606@isi.edu> <4FE8AE03.4080603@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jun 2012 20:39:29 -0000 Hi, Fred, On 6/25/2012 1:25 PM, Templin, Fred L wrote: > Hi again Joe, > >>> "Work with slow machines leads us to believe that if it is >>> necessary to fragment messages, sending the small IP fragment >>> first maximizes the chance of a host with a slow interface of >>> receiving all the fragments." >>> >>> ?? >> >> I would expect the excerpt above refers to systems where the need to >> create a new entry for a new fragment interferes with receive >> processing, so a small first fragment helps in that case. It does assume >> that there's no persistent reordering, and assumes a somewhat broken >> receiver anyway though, IMO. > > Actually, I have some real-world experience behind this. > In 1986, I was asked to look into a problem where a DEC > VAXStation with a DELQA NIC was performing very poorly as > an NFS file server. We found that the DELQA actually reset > itself if it ran out of receive ring buffers, which is > exactly what was happening when enough fragmented > IPv4/UDP/NFS packets arrived in bursts. There was literally > nothing to be done for it - the hardware was deemed broken, > and the VAXStation/DELQA configuration was disqualified > as an NFS server platform. Sure, it's not surprising... > Right around the same time, a DEC colleague was off writing > "Fragmentation Considered Harmful", which (IMO) is where the > whole fragmentation/reassembly/MTU debate went sideways. I > was never consulted on that writing, but my input would have > been that the protocol shouldn't be changed to accommodate > broken hardware. We are still living with the "harmful" > stigma today, but we need to get beyond that if we're > going to accommodate tunnels. Yup - you note too it seems like not being able to setup the fragment reception at line rate is an implementation failure, not necessarily something we should modify protocols to address. Joe From fred@cisco.com Mon Jun 25 14:24: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 5000611E80B8 for ; Mon, 25 Jun 2012 14:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAN274NzKGwQ for ; Mon, 25 Jun 2012 14:24:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 616ED11E80A1 for ; Mon, 25 Jun 2012 14:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1166; q=dns/txt; s=iport; t=1340659440; x=1341869040; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OzA7X3qP44ZM3moCqwiXjIJPx0ErnROX7m6iTgC17Vs=; b=b37bf4buymfKPDpiTIrVQOwl/pS3rJBQ6lZDSGDiuwB+88gDCOoWXBhH tZhXj8YmtpdXu5+DrcSn6SwJ2D6au8bS4ffDRDnjcdRk6pKjgHiZwEQ8c KP7i+cfUdJw3E1uPIyD10/kyDnNK3EOjiy6uS6x3Jj/myhH29E0iIHk4r 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAI3W6E+tJV2Y/2dsb2JhbABEtjSBB4IYAQEBAwESASc/BQsCAQg2EDIlAgQOJ4dkBZhkoAqLM4UkYAOVLo4bgWaCXw X-IronPort-AV: E=Sophos;i="4.77,474,1336348800"; d="scan'208";a="95804486" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 25 Jun 2012 21:24:00 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5PLNxAC002046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Jun 2012 21:24:00 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.234]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Mon, 25 Jun 2012 16:23:59 -0500 From: "Fred Baker (fred)" To: "Templin, Fred L" Thread-Topic: [v6ops] new draft: draft-generic-v6ops-tunmtu Thread-Index: AQHNUMAMI2lkh8Q9EkiB3bN18+NwHA== Date: Mon, 25 Jun 2012 21:23:59 +0000 Message-ID: <69B920DE-2D00-49DC-9BD7-A3B4639F26A5@cisco.com> References: <4FE257A1.7070608@isi.edu> <4FE3A76B.9060400@isi.edu> <9B27D3CA-DDF1-4D48-9988-EB218EC2159A@cisco.com> <4FE897AE.5040606@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.231.251] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18994.004 x-tm-as-result: No--30.474200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <318519952506D948BFA402DDE785E30E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jun 2012 21:24:01 -0000 On Jun 26, 2012, at 3:18 AM, Templin, Fred L wrote: > An historical anecdote - Fred B. may know more about this. > In the mid-1980's companies such as Digital Equipment > Corporation produced 1st generation Ethernet gear that > could not always keep up with wire-speed. I know of at > least one of these 1st generation NICs that would reset > itself if it dropped a packet, which happened quite > frequently if the card received a burst of fragments > from a large fragmented datagram. Was this the genesis > of the RFC1918 text that says: >=20 > "Work with slow machines leads us to believe that if it is > necessary to fragment messages, sending the small IP fragment > first maximizes the chance of a host with a slow interface of > receiving all the fragments." >=20 > ?? It may have been. I was the editor, a long time after the fact of that text= being written. I can tell you that there were a list of NIC issues in the = 1980's; Novell could only receive packets if there was a certain gap betwee= n them, Cisco AGS with a SEEQ chip had a gap requirement, and so on. In 201= 2, I wouldn't read a lot into those comments.= From diego@tid.es Tue Jun 26 00:26: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 2D1F921F857F for ; Tue, 26 Jun 2012 00:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=2.300, 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 QHeWiJY556zh for ; Tue, 26 Jun 2012 00:26:45 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABDF21F855A for ; Tue, 26 Jun 2012 00:26:45 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M6700M02RCAOJ@tid.hi.inet> for v6ops@ietf.org; Tue, 26 Jun 2012 09:26:44 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 7E.BF.02752.33469EF4; Tue, 26 Jun 2012 09:26:44 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M6700M13RCJOJ@tid.hi.inet> for v6ops@ietf.org; Tue, 26 Jun 2012 09:26:43 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Tue, 26 Jun 2012 09:26:43 +0200 Date: Tue, 26 Jun 2012 07:26:42 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: Jared Mauch Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [v6ops] Draft on DC migration to IPv6 Thread-index: AQHNUqhbgWRF7Aew1UKq7qhHvsQ1MZcK5f4AgAEQmQA= X-AuditID: 0a5f4e69-b7f6d6d000000ac0-0c-4fe96433750c X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsXCFe9nqGuS8tLf4P87RovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEro23ZFtaCVWIVHZ+XMjYwPhDtYuTkkBAwkfja+JgRwhaTuHBv PVsXIxeHkMB2RonHN6+zQjg/GSXmdK+CyixllPh56jkbSAuLgKrE9W/HWEBsNiD7UfNv9i5G Dg5hASOJ75O8QMKcAs4SHyY3sUBsUJD4c+4xmC0ioC5xZFEH2GZmoNZ5606BxXkFLCXmLXnB CjKGWcBM4k6rGkRYUOLH5HssEGF1iSlTciE6xSWaW2+yQNiKEtMWNYBNZAT65fupNUwg5SIC xhJH9glCmFYSK3vrIG4RkFiy5zwzhC0q8fLxP1YQW0igSOLGrQ2MExglZiGcMAvJCbMQTpiF 5IRZSE5YwMi6ilGsOKkoMz2jJDcxMyfdwEgvI1MvMy+1ZBMjJNYydzAu36lyiFGAg1GJh9ej /oW/EGtiWXFl7iFGSQ4mJVFei+SX/kJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeJP8gHK8KYmV ValF+TApGQ4OJQlee5A2waLU9NSKtMwcYEKBSTNxcIK08wC1+4HU8BYXJOYWZ6ZD5E8xSkqJ 82qCJARAEhmleXC9rxjFgY4U5g0CyfIAUx9c1yuggUxAAzk2vQAZWJKIkJJqYHQz3NbUmN90 pkWe09w8yGDu6xnWRwvkLr/Z8COla/qyqczvC8LqpebIp7yee7c7JT5bS08/ZHNduOivh97J t62t/k78efvW9kqN34IM7anhX0ysn/zLm2DMKuzQu+Fa2sKu1K2T/iv9l3gXuGOd2IX3hUnb G/4pWX6ac63N/OI5dYvli7LLK5RYijMSDbWYi4oTASjuuy86AwAA References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on DC migration to 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: Tue, 26 Jun 2012 07:26:47 -0000 SGkgSmFyZWQsDQoNCk9uIDI1IEp1biAyMDEyLCBhdCAxNToyOCAsIEphcmVkIE1hdWNoIHdyb3Rl Og0KPiBPbiBKdW4gMjUsIDIwMTIsIGF0IDM6NTggQU0sIERpZWdvIFIuIExvcGV6IHdyb3RlOg0K Pg0KPj4gQSBtZXNzYWdlIGZyb20gdGhlIGNoYWlyIG5vdGVzIHRoYXQgdGhpcyBkcmFmdCBpcyBh bW9uZyB0aG9zZSB3aXRoICJubw0KPj4gZXhwcmVzc2VkIGludGVyZXN0Ii4gQW5kIHNpbmNlIEkg dGhpbmsgZGF0YWNlbnRlciBpc3N1ZXMgc2hvdWxkIGJlIHVuZGVyIHRoZQ0KPj4gZ3JvdXAgY29u c2lkZXJhdGlvbiwgSSdkIGxpa2UgYXNrIHlvdSB0byBoYXZlIGEgKHNlY29uZD8pIGxvb2sgYXQg aXQuDQo+DQo+IEEgZGF0YWNlbnRlciBpcyB1c3VhbGx5IGp1c3QgYSBtYW5hZ2VkIGN1c3RvbWVy IENQRSBlbnZpcm9ubWVudC4gIEknbSBub3Qgc3VyZQ0KPiBob3cgdGhpcyBkaWZmZXJzIGZyb20g YW55IG90aGVyIHNlcnZpY2UgZGVsaXZlcnkgZm9yIElQLCB3aXRob3V0IHJlZ2FyZCB0byB2ZXJz aW9uDQo+IG51bWJlci4NCg0KQXMgc2FpZCBpbiBteSBwcmV2aW91cyByZXBseSB0byBCcmlhbiwg dGhpcyBkcmFmdCBmb2N1c2VzIG9uIHRoZSBhc3BlY3RzIHJlbGF0ZWQNCnRvIGEgZGF0YWNlbnRl ciBhbmQgY29uc2lkZXJlZCBmcm9tIHRoZSBkYXRhY2VudGVyIG9wZXJhdG9yIHZpZXcsIGRpc2N1 c3NpbmcNCmFzcGVjdHMgcmVsYXRlZCB0byBkYXRhY2VudGVyIG5ldHdvcmsgc3RydWN0dXJlIGFu ZCBtdWx0aS10ZW5hbmN5LCB3aGljaCBtYWtlDQp0aGVtIGRpZmZlcmVudCB0byBhIHNpbXBsZSBt YW5hZ2VkIGN1c3RvbWVyIENQRS4NCg0KPiBOb3cgbXkgb2JzZXJ2YXRpb246DQo+IEdlbmVyYWxs eSB0aGUgImRhdGEgY2VudGVycyIgaGF2ZSBoYWQgYSBkaWZmZXJlbnQgY2xhc3Mgb2YgZXF1aXBt ZW50IGluIHRoZXJlIHRoYXQNCj4gZGlkIG5vdCBpbmNsdWRlIElQdjYgcm9hZG1hcCBhcyBwYXJ0 IG9mIHRoZWlyIG9yaWdpbmFsIFJGUC4NCj4NCj4gVGhlIGJpZ2dlc3QgcHJvYmxlbSBoYXMgYmVl biBjdXN0b21lciBleHBlY3RhdGlvbnMsIHRoYXQgb25lIGNhbid0IHRvdWNoL21vdmUgdGhlIHNl cnZpY2UNCj4gdG8gSVB2NiBjYXBhYmxlIGVxdWlwbWVudCwgb3IgdGhhdCB0aGUgcmlzayBvZiB1 cGdyYWRpbmcgdGhlIGhhcmR3YXJlIGlzIHRvbyBoaWdoIChvcg0KPiBleHBlbnNpdmUpLiAgVGhl c2UgYXJlIGJ1c2luZXNzIGRyaXZlcnMgdGhhdCBJJ3ZlIHNlZW4gdHJ1bXAgYSB0ZWNobm9sb2d5 IGRlY2lzaW9uLg0KDQoNCldlIHRoaW5rIGEgZnJhbWV3b3JrIGxpa2UgdGhlIG9uZSBwcm9wb3Nl ZCBpbiB0aGlzIGRyYWZ0IHdvdWxkIGJlIG9mIGhlbHAgdG8NCm1ha2UgSVB2NiByZXF1aXJlbWVu dHMgcGFydCBvZiBkYXRhY2VudGVyIG9wZXJhdG9yIFJGUHMsIGFuZCBkZWZpbmUgdGhlaXINCnNl cnZpY2UgbGV2ZWxzIHRvIGN1c3RvbWVycy4NCg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXog bm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVs ZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6 IGRpZWdvQHRpZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAw NTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2Ug ZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJh IHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28g ZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRl ZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZl IGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdC4NCmh0dHA6Ly93d3cu dGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From diego@tid.es Tue Jun 26 00:26: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 4517521F855A for ; Tue, 26 Jun 2012 00:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_05=-1.11, 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 80YWsS+RJr+h for ; Tue, 26 Jun 2012 00:26:45 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99A4021F8555 for ; Tue, 26 Jun 2012 00:26:44 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M6700F3GRCAIB@tid.hi.inet> for v6ops@ietf.org; Tue, 26 Jun 2012 09:26:43 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 45.F8.26499.23469EF4; Tue, 26 Jun 2012 09:26:42 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M6700F4RRCIIB@tid.hi.inet> for v6ops@ietf.org; Tue, 26 Jun 2012 09:26:42 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Tue, 26 Jun 2012 09:26:42 +0200 Date: Tue, 26 Jun 2012 07:26:41 +0000 From: "Diego R. Lopez" In-reply-to: <4FE85E64.1010400@gmail.com> X-Originating-IP: [10.95.64.115] To: Brian E Carpenter Message-id: <8B588653-D42B-43DA-90C9-8DC9C39C5E67@tid.es> Content-id: <3DB831E42F1D1C489D69871BAD506708@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [v6ops] Draft on DC migration to IPv6 Thread-index: AQHNUqhbgWRF7Aew1UKq7qhHvsQ1MZcK2yAAgAEbdoA= X-AuditID: 0a5f4068-b7f206d000006783-7e-4fe96432efe2 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsXCFe/ApWuU8tLfYPUkc4vTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY+WhNewFRxQq2i6tYW9gvCHfxcjJISFgIvH/wwJGCFtM4sK9 9WxdjFwcQgIbGSWO31jACuH8ZJT49GILE4SzlFFievsxdpAWFgFViQOPL7KA2GxA9qPm30Bx Dg5hASOJ75O8QMKcApoS716th9qgIPHn3GOwchEBY4nGrtOsIDYzUOu8dafA4rwClhK7266y Q8TNJB5sesQEEReU+DH5HgvIeGYBdYkpU3IhSsQlmltvskDYihLTFjWArWIEeub7qTVMIOUg q47sE4TYaiXRcbWBBeIaAYkle84zQ9iiEi8f/wO7RkggQmL7xFlsExglZiE5YhaSI2YhHDEL yRGzkByxgJF1FaNYcVJRZnpGSW5iZk66gaFeRqZeZl5qySZGSMRl7GBcvlPlEKMAB6MSD69H /Qt/IdbEsuLK3EOMkhxMSqK8Fskv/YX4kvJTKjMSizPii0pzUosPMUpwMCuJ8Cb5AeV4UxIr q1KL8mFSMhwcShK89iBtgkWp6akVaZk5wLQCk2bi4ARp5wFq9wOp4S0uSMwtzkyHyJ9ilJQS 59UESQiAJDJK8+B6XzGKAx0pzBsEkuUBJkC4rldAA5mABnJsegEysCQRISXVwCiTIlyjdLHm mti0DbKxXqdPPon7O6X52UU3d5YNrx4s+bdLyG/9kkyzx7IfC57q/76mEr9Wj0mrf/XSbcwi GY4svXc3BegpeyxayvktT/T4RWGDdYyfX28+0Ki95q5HSZjPhaDDs5P3eixZKBB3aKrynntx W38rFzfVasfZdf+uMuMKn/vm9C8lluKMREMt5qLiRACr3h5RPQMAAA== References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FE85E64.1010400@gmail.com> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on DC migration to 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: Tue, 26 Jun 2012 07:26:47 -0000 SGkgQnJpYW4sDQoNCk9uIDI1IEp1biAyMDEyLCBhdCAxNDo0OSAsIEJyaWFuIEUgQ2FycGVudGVy IHdyb3RlOg0KPiBJIHRoaW5rIHRoZSByZWFsIHByb2JsZW0gaXMgcGVyc3VhZGluZyB0aGUgcGVv cGxlIHdobyBtYW5hZ2UNCj4gZGF0YSBjZW50cmVzIHRoYXQgdGhlcmUgaXMgYW4gZWNvbm9taWMg YW5kIGJ1c2luZXNzIGluY2VudGl2ZQ0KPiB0byBzdXBwb3J0IG5hdGl2ZSBJUHY2IChhcyBvcHBv c2VkIHRvIHN1cHBvcnQgbmF0aXZlIElQdjYNCj4gY3VzdG9tZXJzLCB3aGljaCB0aGV5IHByb2Jh Ymx5IHVuZGVyc3RhbmQpLiBJbiBzb21lIGNhc2VzIHRoZQ0KPiBhcmd1bWVudHMgYXJlIHRlY2hu aWNhbCBwZXJoYXBzIChmb3IgZXhhbXBsZSwgaWYgdGhlIGxvYWQNCj4gYmFsYW5jZXJzIHVzZSBk aXJlY3Qgc2VydmVyIHJldHVybiwgbWFraW5nIHRoZSBzZXJ2ZXJzIGR1YWwNCj4gc3RhY2sgd2ls bCBiZSB0aGUgb25seSByZWFzb25hYmxlIGFwcHJvYWNoKS4gQnV0IGluIGdlbmVyYWwNCj4ganVz dCBzaG93aW5nIHBlb3BsZSBob3cgdG8gZGVzaWduIHRoZSB0ZWNobmljYWwgc29sdXRpb24gaXMN Cj4gbm90IGVub3VnaCBmb3IgdGhlbSB0byBhZG9wdCBpdC4NCg0KSW5kZWVkLiBCdXQgb3VyIHBv aW50IHRoZXJlIGlzIHRoYXQgcHJvdmlkaW5nIHBlb3BsZSB3aXRoIGEgbWVjaGFuaXNtDQp0byBn YXVnZSB0aGVpciByZXF1aXJlbWVudHMgYW5kIHRoZSBwcm9wb3NhbHMgdGhleSBnZXQgdG8gc2F0 aXNmeSB0aGVtDQpjYW4gZWFzZSBhZG9wdGlvbi4NCg0KPiBTbyB3aGlsZSBJIHVuZGVyc3RhbmQg dGhlIGlkZWEgb2YgeW91ciBkcmFmdCwgaXQgZG9lc24ndCBzb2x2ZQ0KPiB0aGUgcHJvYmxlbSBv ZiBtb3RpdmF0aW9uLg0KDQpNb3RpdmF0aW9uIGNhbiBvbmx5IGNvbWUgZnJvbSBhIGNsZWFyIGJ1 c2luZXNzIGNhc2UsIGFuZCBldmVuIGVudW1lcmF0aW5nDQpwb3RlbnRpYWwgdGVjaG5pY2FsIGJl bmVmaXRzIChzdWNoIGFzIHNpbXBsaWZpZWQgbG9hZCBiYWxhbmNpbmcsIG9yIGJldHRlcg0Kb3Zl cmxheSBtYW5hZ2VtZW50KSB3b3VsZCBub3QgcHJvdmlkZSBhIGRlZmluaXRpdmUgbW90aXZhdGlv bi4gQnV0DQphIGJldHRlciB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjaG9pY2VzIHNob3VsZCBwcm92 aWRlIGFkZGl0aW9uYWwgc3VwcG9ydA0KZm9yIHBhcnRpY3VsYXIgbW90aXZhdGlvbnMuDQoNCj4g QWxzbyBJIHRoaW5rIGl0J3MgdW5saWtlbHkgdGhhdCBhbGwNCj4gRENzIGZpdCB0aGUgc2luZ2xl IGZyYW1ld29yayB5b3UgZGVzY3JpYmUgLSBzdXJlbHkgdGhlcmUgaXMNCj4gYSB3aWRlciByYW5n ZSBvZiBzY2VuYXJpb3M/IFRoYXQncyB3aHkgdGhlIElFVEYgaW4gZ2VuZXJhbA0KPiBkb2VzIGJl dHRlciB3aGVuIGRvY3VtZW50aW5nIGluZGl2aWR1YWwgY29tcG9uZW50cyBhbmQgc29sdXRpb25z DQo+IHRoYW4gd2hlbiB0YWNrbGluZyBmcmFtZXdvcmtzLg0KDQpXZSdsbCBwcm9iYWJseSBuZWVk IHRvIHJlZmluZSBzb21lIG9mIHRoZSBtYXR1cml0eSBsZXZlbHMNCihlc3BlY2lhbGx5LCBsZXZl bCAyKSBhcyBleHBlcmllbmNlIHdpdGggbWlncmF0aW9ucyBncm93cywNCmJ1dCBJIGJlbGlldmUg dGhlIGdlbmVyYWwgZnJhbWV3b3JrIHdpbGwgc3RheSBhcHBsaWNhYmxlLCBhcyBsb25nIGFzDQp0 aGVyZSBpcyBub3QgYSByZWFsbHkgZGlzcnVwdGl2ZSBzb2x1dGlvbiwgb2YgY291cnNlLg0KDQo+ IEFsc28gdGhlcmUgc2hvdWxkIGJlIGEgY2xhcmlmaWNhdGlvbiBvZiBob3cgdGhpcyBkcmFmdCBy ZWxhdGVzDQo+IHRvIGRyYWZ0LWNoa3B2Yy1lbnRlcnByaXNlLWluY3JlbWVudGFsLWlwdjYuDQoN CkVzc2VudGlhbGx5LCBkcmFmdC1jaGtwdmMtZW50ZXJwcmlzZS1pbmNyZW1lbnRhbC1pcHY2IHRy aWVzIHRvIGNvdmVyIGFsbA0KdGhlIG5ldHdvcmtpbmcgYXNwZWN0cyBpbiBhbiBlbnRlcnByaXNl LCBwcm92aWRpbmcgZ2VuZXJhbCBndWlkYW5jZXMgZm9yDQpkaWZmZXJlbnQgbWlncmF0aW9uIHN0 cmF0ZWdpZXMuIFRoaXMgZHJhZnQgZm9jdXNlcyBvbiB0aGUgYXNwZWN0cyByZWxhdGVkDQp0byBh IGRhdGFjZW50ZXIgYW5kIGNvbnNpZGVyZWQgZnJvbSB0aGUgZGF0YWNlbnRlciBvcGVyYXRvciB2 aWV3LCBkaXNjdXNzaW5nDQphc3BlY3RzIHJlbGF0ZWQgdG8gZGF0YWNlbnRlciBuZXR3b3JrIHN0 cnVjdHVyZSBhbmQgbXVsdGktdGVuYW5jeSwgb2Z0ZW4NCihpZiBub3QgYWx3YXlzKSBoaWRkZW4g dG8gdGhlIGN1c3RvbWVyIChlbnRlcnByaXNlKSB2aWV3Lg0KDQo+IFBsZWFzZSByZWZlciB0byBk cmFmdC1jYXJwZW50ZXItZmxvdy1sYWJlbC1iYWxhbmNpbmcgaW5zdGVhZA0KPiBvZiBkcmFmdC1j YXJwZW50ZXItdjZvcHMtbGFiZWwtYmFsYW5jZS4NCg0KV2lsbCBkby4gVGhhbmtzIGZvciB0aGUg Y29ycmVjdGlvbi4NCg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywg RG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0 dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRpZC5lcw0K VGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUg YSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBl bnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNp dHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBm b3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBi YXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdC4NCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lO QVMvZGlzY2xhaW1lci5hc3B4DQo= From ietfc@btconnect.com Tue Jun 26 04:04: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 0998A21F85FB for ; Tue, 26 Jun 2012 04:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.974 X-Spam-Level: X-Spam-Status: No, score=-4.974 tagged_above=-999 required=5 tests=[AWL=1.025, 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 1wnTr6sYhAJf for ; Tue, 26 Jun 2012 04:04:44 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5E50521F85F0 for ; Tue, 26 Jun 2012 04:04:44 -0700 (PDT) Received: from mail42-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 11:03:03 +0000 Received: from mail42-tx2 (localhost [127.0.0.1]) by mail42-tx2-R.bigfish.com (Postfix) with ESMTP id 3D9D34E049E; Tue, 26 Jun 2012 11:03:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT010.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zcb8kz9371I542M1432I1418Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail42-tx2 (localhost.localdomain [127.0.0.1]) by mail42-tx2 (MessageSwitch) id 1340708581376439_7075; Tue, 26 Jun 2012 11:03:01 +0000 (UTC) Received: from TX2EHSMHS009.bigfish.com (unknown [10.9.14.248]) by mail42-tx2.bigfish.com (Postfix) with ESMTP id 4DBE3200F6; Tue, 26 Jun 2012 11:03:01 +0000 (UTC) Received: from DB3PRD0702HT010.eurprd07.prod.outlook.com (157.55.224.141) by TX2EHSMHS009.bigfish.com (10.9.99.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 11:02:59 +0000 Received: from AMSPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.5) by pod51017.outlook.com (10.3.4.178) with Microsoft SMTP Server (TLS) id 14.15.86.1; Tue, 26 Jun 2012 11:04:06 +0000 Message-ID: <017901cd538a$e9af8980$4001a8c0@gateway.2wire.net> From: t.petch To: "Fred Baker (fred)" , References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> Date: Tue, 26 Jun 2012 12:00:28 +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-Originating-IP: [157.56.248.5] X-OriginatorOrg: btconnect.com Cc: Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Jun 2012 11:04:45 -0000 I am confused about the legend for draft-ietf-v6ops-464xlat-03.txt There was a lively discussion in May which left a number of issues unclear for me, and I see that, today, a new version has arrived, so I think that further discussion should ensue, preferrably on the list. Tom Petch ----- Original Message ----- From: "Fred Baker (fred)" To: Cc: "Ron Bonica" Sent: Monday, June 25, 2012 3:04 AM Subject: [v6ops] Prep for v6ops IETF 84 agenda > I sat down this morning to assess our agenda. Interested in working group comment. > > # no update > Jan 11 16:48 draft-yang-v6ops-fast6-pppoe-02.txt > Feb 21 18:10 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt > Feb 23 07:29 draft-carpenter-v6ops-icp-guidance-03.txt > Feb 25 11:37 draft-ietf-v6ops-ivi-icmp-address-01.txt > Feb 28 08:49 draft-chkpvc-enterprise-incremental-ipv6-00.txt > Mar 5 17:46 draft-ma-v6ops-terminal-test-00.txt > Mar 7 07:33 draft-carpenter-v6ops-label-balance-02.txt > Mar 12 06:21 draft-vanrein-v6ops-6bed4-01.txt > Mar 12 17:52 draft-chen-v6ops-nat64-experience-01.txt > Mar 12 21:34 draft-liu-v6ops-ula-usage-analysis-02.txt > Mar 13 04:59 draft-sunq-v6ops-contents-transition-03.txt > Mar 30 03:27 draft-donley-v6ops-ce-router-design-00.txt > Mar 31 11:33 draft-yang-v6ops-fast6-00.txt > > #no expressed interest > Jun 20 11:33 draft-lopez-v6ops-dc-ipv6-02.txt > Apr 27 12:07 draft-jiang-v6ops-v4v6mc-proxy-01.txt > > #out of charter > Jun 24 07:59 draft-generic-v6ops-tunmtu-07.txt > May 10 11:44 draft-templin-v6ops-isops-17.txt > > #in IESG queue > May 30 11:10 draft-ietf-v6ops-wireline-incremental-ipv6-04.txt > May 17 11:02 draft-ietf-v6ops-6204bis-09.txt > > > #WGLC in v6ops or move to sunset4; awaiting AD direction > May 8 10:14 draft-ietf-v6ops-464xlat-03.txt > > #potential for agenda > Apr 30 13:58 draft-gundavelli-v6ops-community-wifi-svcs-04.txt > May 16 02:12 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt > May 22 21:30 draft-ietf-v6ops-ra-guard-implementation-04.txt > > #for agenda, perhaps ready for last call > Jun 12 19:26 draft-ietf-v6ops-icp-guidance-01.txt > > > > For draft-ietf-v6ops-ivi-icmp-address, the last discussion was in April, and we were to expect an update. If that happens, I expect to bring that to the agenda. > > Lee asked about draft-chkpvc-enterprise-incremental-ipv6 on the list, but I see no update and I wasn't clear on the list commentary, whether the operators want to discuss. > > There is still, of course, time for folks to post -00 drafts (until 9 July); if there is list discussion of those drafts, we will include them in the agenda. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Tue Jun 26 06:54: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 F274F21F8639 for ; Tue, 26 Jun 2012 06:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=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 Z0Bstug5CMfQ for ; Tue, 26 Jun 2012 06:54:35 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 566CE21F8615 for ; Tue, 26 Jun 2012 06:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=395; q=dns/txt; s=iport; t=1340718875; x=1341928475; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ENT04t5he6/zG9ovn4GCYoAn4QrQNVgI17D1kDbRrao=; b=P7h+uB9INbxINowUxL8wUJmwTKbkgBD1ohQvUye5WOr8pnMdffQFtFFu 2nEM6myYy3aP4KyOwqawT+wP/qRoibRL6H5lOUNh8sZGBr09Pq15wJnTg Npx3aFs6S3g3sRAQG7sIIinJjInZ8joMlCA4lIF/qo3RrqAd7K+qVS0du 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKG+6U+tJXG+/2dsb2JhbABFtjKBB4IYAQEBAwESASc/BQsCAQg2EDIlAgQOJ4dkBZhjoEOLN4YEA5Uyjh2BZoJf X-IronPort-AV: E=Sophos;i="4.77,477,1336348800"; d="scan'208";a="96091243" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 26 Jun 2012 13:54:31 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5QDsVQM007438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Jun 2012 13:54:31 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.234]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Tue, 26 Jun 2012 08:54:31 -0500 From: "Fred Baker (fred)" To: "t.petch" Thread-Topic: [v6ops] Prep for v6ops IETF 84 agenda Thread-Index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXQ== Date: Tue, 26 Jun 2012 13:54:30 +0000 Message-ID: References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> <017901cd538a$e9af8980$4001a8c0@gateway.2wire.net> In-Reply-To: <017901cd538a$e9af8980$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.79.230] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18996.004 x-tm-as-result: No--28.185400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <1CC86BE12EF22742983F00121ED523E8@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Jun 2012 13:54:36 -0000 On Jun 26, 2012, at 7:00 PM, t.petch wrote: > There was a lively discussion in May which left a number of issues > unclear for me, and I see that, today, a new version has arrived, so I > think that further discussion should ensue, preferrably on the list. Happy to have list discussion, and if my AD tells me it's a v6ops item, at = IETF 84. That discussion may happen in sunset4.= From kawashimam@vx.jp.nec.com Tue Jun 26 07:53: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 689F821F8615 for ; Tue, 26 Jun 2012 07:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 eni8txyXNqP5 for ; Tue, 26 Jun 2012 07:53:57 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id 9213721F85FB for ; Tue, 26 Jun 2012 07:53:57 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.192]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q5QEruoF021756; Tue, 26 Jun 2012 23:53:56 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q5QEruL11352; Tue, 26 Jun 2012 23:53:56 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id q5QErttv001765; Tue, 26 Jun 2012 23:53:55 +0900 (JST) Received: from yonosuke.jp.nec.com ([10.26.220.15] [10.26.220.15]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-68965; Tue, 26 Jun 2012 23:53:29 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Tue, 26 Jun 2012 23:53:29 +0900 To: despres.remi@laposte.net In-reply-to: <79510968-0EE0-473F-A0B1-DD4B35092523@laposte.net> Message-Id: <20120626235329kawashimam@mail.jp.nec.com> References: <79510968-0EE0-473F-A0B1-DD4B35092523@laposte.net> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Tue, 26 Jun 2012 23:53:28 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 26 Jun 2012 14:53:58 -0000 Hi Remi, I'm sorry for late reply. 464XLAT authors don't stick to the document category. If the chairs request changing the category, we will follow their opinion as we did before. Regards, Masanobu >Hi, Masanobu-san, > >I have to confirm, no surprise, that I object to its BCP status because: >- it proposes more than just a combination of existing RFCs >- it has close relationship with subjects discussed in Softwires such as MAP and 4rd, without serious examination of this relationship. > >OTOH, I also confirm that I would be pleased to support it if its status is changed back to Informational (its original status) because: >- It deals with a subject not covered by existing RFCs >- It is based on ideas that have been, at least in part, tested in the field. >- Issues raised in the WG (other than the RFC status) have been dealt with. > >Kind regards, >RD > > >Le 2012-06-25 02:33, Masanobu Kawashima a rit : > >> >> Hi all, >> >> We have published draft-ietf-v6ops-464xlat-04. >> Can we move forward to WGLC? >> >> Changes are: >> >> - adding in the "Terminology" of CLAT that the CLAT does not >> comply with "Both IPv4-translatable IPv6 addresses and >> IPv4-converted IPv6 addresses SHOULD use the same prefix." >> that is described on Section 3.3 in RFC 6052. >> >> - splitting text of "using NAT44 and stateless XLATE on CLAT" >> and "using only stateless XLATE on CLAT" in the section of >> "IPv4/IPv6 Address Translation Chart" and "IPv6 Prefix >> Handling" instead of deleting the section of "Relationship >> between CLAT and NAT44" >> >> - adding the combination with BIH [RFC6535] in the section of >> "Introduction" and "Deployment Considerations". >> >> - adding explanations about the diagram in the section of >> "Network Architecture". >> >> - adding the section of "Appendix A. Examples of IPv4/IPv6 >> Address Translation". >> >> - deleting marketing and commercial phrases (JPIX trial service). >> >> All comments are welcome. >> >> 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-04.txt >>> Pages : 18 >>> Date : 2012-06-24 >>> >>> Abstract: >>> This document describes an architecture (464XLAT) for providing >>> limited 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 limited IPv4 >>> access service to IPv6-only edge networks without encapsulation. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-04 >>> >>> A diff from previous version is available at: >>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-04 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 kawashimam@vx.jp.nec.com Tue Jun 26 07:57: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 84BF421F85F2 for ; Tue, 26 Jun 2012 07:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.36 X-Spam-Level: X-Spam-Status: No, score=0.36 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 i0ogAMKxFnMJ for ; Tue, 26 Jun 2012 07:57:28 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id C6B6321F85CD for ; Tue, 26 Jun 2012 07:57:27 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q5QEuGof007662; Tue, 26 Jun 2012 23:56:16 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q5QEuG818181; Tue, 26 Jun 2012 23:56:16 +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 q5QEuFoj008777; Tue, 26 Jun 2012 23:56:15 +0900 (JST) Received: from kameyata.jp.nec.com ([10.26.220.29] [10.26.220.29]) by mail01b.kamome.nec.co.jp with ESMTP id BT-MMP-68130; Tue, 26 Jun 2012 23:55:50 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-64238; Tue, 26 Jun 2012 23:55:50 +0900 To: "t.petch" In-reply-to: <017901cd538a$e9af8980$4001a8c0@gateway.2wire.net> Message-Id: <20120626235550kawashimam@mail.jp.nec.com> References: <017901cd538a$e9af8980$4001a8c0@gateway.2wire.net> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Tue, 26 Jun 2012 23:55:49 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Jun 2012 14:57:28 -0000 Hi Tom, Thank you for your comment. We took your opinion into consideration. I think that we did everything we could. Could you please comment us your unclear points or suggestion? If we should revise the document, we will revise it immediately. Regards, Masanobu >I am confused about the legend for >draft-ietf-v6ops-464xlat-03.txt > >There was a lively discussion in May which left a number of issues >unclear for me, and I see that, today, a new version has arrived, so I >think that further discussion should ensue, preferrably on the list. > >Tom Petch > >----- Original Message ----- >From: "Fred Baker (fred)" >To: >Cc: "Ron Bonica" >Sent: Monday, June 25, 2012 3:04 AM >Subject: [v6ops] Prep for v6ops IETF 84 agenda > > >> I sat down this morning to assess our agenda. Interested in working >group comment. >> >> # no update >> Jan 11 16:48 draft-yang-v6ops-fast6-pppoe-02.txt >> Feb 21 18:10 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt >> Feb 23 07:29 draft-carpenter-v6ops-icp-guidance-03.txt >> Feb 25 11:37 draft-ietf-v6ops-ivi-icmp-address-01.txt >> Feb 28 08:49 draft-chkpvc-enterprise-incremental-ipv6-00.txt >> Mar 5 17:46 draft-ma-v6ops-terminal-test-00.txt >> Mar 7 07:33 draft-carpenter-v6ops-label-balance-02.txt >> Mar 12 06:21 draft-vanrein-v6ops-6bed4-01.txt >> Mar 12 17:52 draft-chen-v6ops-nat64-experience-01.txt >> Mar 12 21:34 draft-liu-v6ops-ula-usage-analysis-02.txt >> Mar 13 04:59 draft-sunq-v6ops-contents-transition-03.txt >> Mar 30 03:27 draft-donley-v6ops-ce-router-design-00.txt >> Mar 31 11:33 draft-yang-v6ops-fast6-00.txt >> >> #no expressed interest >> Jun 20 11:33 draft-lopez-v6ops-dc-ipv6-02.txt >> Apr 27 12:07 draft-jiang-v6ops-v4v6mc-proxy-01.txt >> >> #out of charter >> Jun 24 07:59 draft-generic-v6ops-tunmtu-07.txt >> May 10 11:44 draft-templin-v6ops-isops-17.txt >> >> #in IESG queue >> May 30 11:10 draft-ietf-v6ops-wireline-incremental-ipv6-04.txt >> May 17 11:02 draft-ietf-v6ops-6204bis-09.txt >> >> >> #WGLC in v6ops or move to sunset4; awaiting AD direction >> May 8 10:14 draft-ietf-v6ops-464xlat-03.txt >> >> #potential for agenda >> Apr 30 13:58 draft-gundavelli-v6ops-community-wifi-svcs-04.txt >> May 16 02:12 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt >> May 22 21:30 draft-ietf-v6ops-ra-guard-implementation-04.txt >> >> #for agenda, perhaps ready for last call >> Jun 12 19:26 draft-ietf-v6ops-icp-guidance-01.txt >> >> >> >> For draft-ietf-v6ops-ivi-icmp-address, the last discussion was in >April, and we were to expect an update. If that happens, I expect to >bring that to the agenda. >> >> Lee asked about draft-chkpvc-enterprise-incremental-ipv6 on the list, >but I see no update and I wasn't clear on the list commentary, whether >the operators want to discuss. >> >> There is still, of course, time for folks to post -00 drafts (until 9 >July); if there is list discussion of those drafts, we will include them >in the agenda. >> _______________________________________________ >> 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 ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From ietfc@btconnect.com Tue Jun 26 08:33: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 AC06221F8568 for ; Tue, 26 Jun 2012 08:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=-0.560, 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 zJAd7OPbJY55 for ; Tue, 26 Jun 2012 08:33:33 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE3721F855E for ; Tue, 26 Jun 2012 08:33:32 -0700 (PDT) Received: from mail3-am1-R.bigfish.com (10.3.201.226) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 15:31:50 +0000 Received: from mail3-am1 (localhost [127.0.0.1]) by mail3-am1-R.bigfish.com (Postfix) with ESMTP id C5CF3401F8; Tue, 26 Jun 2012 15:31:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT012.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zcb8kz9371I542M1432I1418Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail3-am1 (localhost.localdomain [127.0.0.1]) by mail3-am1 (MessageSwitch) id 1340724708147344_14854; Tue, 26 Jun 2012 15:31:48 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.238]) by mail3-am1.bigfish.com (Postfix) with ESMTP id 219AA20045; Tue, 26 Jun 2012 15:31:48 +0000 (UTC) Received: from DB3PRD0702HT012.eurprd07.prod.outlook.com (157.55.224.141) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 15:31:47 +0000 Received: from DB3PRD0610HT003.eurprd06.prod.outlook.com (157.56.252.53) by pod51017.outlook.com (10.3.5.132) with Microsoft SMTP Server (TLS) id 14.15.86.1; Tue, 26 Jun 2012 15:33:23 +0000 Message-ID: <00b401cd53b0$88115840$4001a8c0@gateway.2wire.net> From: t.petch To: Masanobu Kawashima References: <017901cd538a$e9af8980$4001a8c0@gateway.2wire.net> <20120626235550kawashimam@mail.jp.nec.com> Date: Tue, 26 Jun 2012 16:28:40 +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-Originating-IP: [157.56.252.53] X-OriginatorOrg: btconnect.com Cc: v6ops@ietf.org Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Jun 2012 15:33:33 -0000 ----- Original Message ----- From: "Masanobu Kawashima" To: "t.petch" Cc: ; "Fred Baker (fred)" ; "Ron Bonica" Sent: Tuesday, June 26, 2012 3:55 PM > > Hi Tom, > > Thank you for your comment. > > We took your opinion into consideration. > I think that we did everything we could. > Could you please comment us your unclear points or suggestion? > If we should revise the document, we will revise it immediately. Ah, I haven't read -04 yet:-( There was a quite a lot of comment on -03 so I was expecting a -04 and confirmation or otherwise, on the list, that the comments had been addressed. Then I saw Fred's note about -03, which I still don't understand but I realise I have no idea what sunset4 is, which may be part of the part of the problem but thought that WGLC was premature until a new version appeared so I drafted a note in response to Fred. As I was about to hit send, I saw -04 had appeared but still thought WGLC premature and sent the note anyway. So I will read -04 and hope that everyone else who had comments will do likewise, after which, I hope that the chairs will initiate WGLC. Tom Petch > Regards, > Masanobu > > > >I am confused about the legend for > >draft-ietf-v6ops-464xlat-03.txt > > > >There was a lively discussion in May which left a number of issues > >unclear for me, and I see that, today, a new version has arrived, so I > >think that further discussion should ensue, preferrably on the list. > > > >Tom Petch > > > >----- Original Message ----- > >From: "Fred Baker (fred)" > >To: > >Cc: "Ron Bonica" > >Sent: Monday, June 25, 2012 3:04 AM > >Subject: [v6ops] Prep for v6ops IETF 84 agenda > > > > > >> I sat down this morning to assess our agenda. Interested in working > >group comment. > >> > >> # no update > >> Jan 11 16:48 draft-yang-v6ops-fast6-pppoe-02.txt > >> Feb 21 18:10 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt > >> Feb 23 07:29 draft-carpenter-v6ops-icp-guidance-03.txt > >> Feb 25 11:37 draft-ietf-v6ops-ivi-icmp-address-01.txt > >> Feb 28 08:49 draft-chkpvc-enterprise-incremental-ipv6-00.txt > >> Mar 5 17:46 draft-ma-v6ops-terminal-test-00.txt > >> Mar 7 07:33 draft-carpenter-v6ops-label-balance-02.txt > >> Mar 12 06:21 draft-vanrein-v6ops-6bed4-01.txt > >> Mar 12 17:52 draft-chen-v6ops-nat64-experience-01.txt > >> Mar 12 21:34 draft-liu-v6ops-ula-usage-analysis-02.txt > >> Mar 13 04:59 draft-sunq-v6ops-contents-transition-03.txt > >> Mar 30 03:27 draft-donley-v6ops-ce-router-design-00.txt > >> Mar 31 11:33 draft-yang-v6ops-fast6-00.txt > >> > >> #no expressed interest > >> Jun 20 11:33 draft-lopez-v6ops-dc-ipv6-02.txt > >> Apr 27 12:07 draft-jiang-v6ops-v4v6mc-proxy-01.txt > >> > >> #out of charter > >> Jun 24 07:59 draft-generic-v6ops-tunmtu-07.txt > >> May 10 11:44 draft-templin-v6ops-isops-17.txt > >> > >> #in IESG queue > >> May 30 11:10 draft-ietf-v6ops-wireline-incremental-ipv6-04.txt > >> May 17 11:02 draft-ietf-v6ops-6204bis-09.txt > >> > >> > >> #WGLC in v6ops or move to sunset4; awaiting AD direction > >> May 8 10:14 draft-ietf-v6ops-464xlat-03.txt > >> > >> #potential for agenda > >> Apr 30 13:58 draft-gundavelli-v6ops-community-wifi-svcs-04.txt > >> May 16 02:12 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt > >> May 22 21:30 draft-ietf-v6ops-ra-guard-implementation-04.txt > >> > >> #for agenda, perhaps ready for last call > >> Jun 12 19:26 draft-ietf-v6ops-icp-guidance-01.txt > >> > >> > >> > >> For draft-ietf-v6ops-ivi-icmp-address, the last discussion was in > >April, and we were to expect an update. If that happens, I expect to > >bring that to the agenda. > >> > >> Lee asked about draft-chkpvc-enterprise-incremental-ipv6 on the list, > >but I see no update and I wasn't clear on the list commentary, whether > >the operators want to discuss. > >> > >> There is still, of course, time for folks to post -00 drafts (until 9 > >July); if there is list discussion of those drafts, we will include them > >in the agenda. > >> _______________________________________________ > >> 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 > > ======================================== > NEC AccessTechnica, Ltd. > Product Development Department > Masanobu Kawashima > kawashimam@vx.jp.nec.com > http://www.necat.co.jp/ > ======================================== > > From arturo.servin@gmail.com Tue Jun 26 12:25: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 1962011E80CB for ; Tue, 26 Jun 2012 12:25:29 -0700 (PDT) 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 AVkjhKr05Y36 for ; Tue, 26 Jun 2012 12:25:28 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26AB711E809F for ; Tue, 26 Jun 2012 12:25:28 -0700 (PDT) Received: by yenq13 with SMTP id q13so297284yen.31 for ; Tue, 26 Jun 2012 12:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=yJN1n+vuT8nPmEwBZIoY7juJX6AReYpohInnfoWTfCU=; b=zMx0XatCqG6OPLMSKZxfeu5hyE9NO5x9zRlANA/+da3J5TGCU0+VEPr2mbC8tsJuQK Fl8txA57uLMI/uGWjYBlF82EPpEhpiIuroBMYAyDLMzbnMV8vQ0Q6DN8WBObgjyl1bZD J4H0cCwk9HFTOrXGjnOGGFGcAnZ9hLV5PyZizYxvD39ACmlBsQiA4I/aR0nc1y5F5wUu IInC/9vrUgQPOnD6s/iEZ8n6jYmJ97RatfVEDneSVFJ6jazVSjQjUXkhDFRKB6CkToXr OD8m1+WcDeyzvXbC+qg5GVRMkD/YTU+FzIEfIqCnBUqtbzfuCPH2KwKt59cRLPtsj1jZ GtwQ== Received: by 10.236.200.199 with SMTP id z47mr19265744yhn.82.1340738727733; Tue, 26 Jun 2012 12:25:27 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([200.7.85.172]) by mx.google.com with ESMTPS id w61sm142146623yhi.5.2012.06.26.12.25.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 12:25:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Arturo Servin In-Reply-To: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> Date: Tue, 26 Jun 2012 16:25:21 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7EC83C63-AE66-4FD1-8EFE-2C2CF41F5106@gmail.com> References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> To: Diego R. Lopez X-Mailer: Apple Mail (2.1278) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on DC migration to 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: Tue, 26 Jun 2012 19:25:29 -0000 Diego, Some questions and comments. The maturity level 1 is a bit odd to me. Do you mean that it is = common to DC to translate all the traffic from v4 to v6 in the border? I = am misunderstanding something? Shouldn't be a dual stack network (with servers and services in = v4) a maturity level 0.5 or 1.5? I think also that there are some common scenarios not explored = here, for example some native dual stack servers and services combined = with single stack services (web server in DS + database server in v4 = only). The maturity level 3 I think that you need to add that a single = stack network is much simple to manage than a dual stack one. IMHO that = will be the killer app for an IPv6 only DC. Also, take a look at draft-ietf-v6ops-icp-guidance, there is = some content that it is already there.=20 Regards, as =09 =09 On 25 Jun 2012, at 04:58, Diego R. Lopez wrote: > Hi, >=20 > I've recently been at a workshop (the Carrier Cloud Summit) in which = most of > the presentations and proposals still only consider v4-based = solutions, with > v6 being a matter of border translation if at all, or view v6 as a = long-term > issue, not considering either the problems or the new solutions it can = bring to > datacenter architecture aspects. >=20 > We have recently updated a draft (draft-lopez-v6ops-dc-ipv6-02), = precisely oriented > in that direction. Quoting the abstract, the document is intended to = "provide a > reference framework for datacenter operators planning for a migration = of their > infrastructures to IPv6. It aims to offer a scheme for evaluating = different products > and architectures, and therefore it is also addressed to manufacturers = and solution > providers, so they can use it to gauge their solutions". >=20 > A message from the chair notes that this draft is among those with "no > expressed interest". And since I think datacenter issues should be = under the > group consideration, I'd like ask you to have a (second?) look at it. >=20 > Be goode, >=20 > -- > "Esta vez no fallaremos, Doctor Infierno" >=20 > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ >=20 > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- >=20 >=20 > ________________________________ >=20 > Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico en el enlace situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send = and receive email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From jouni.nospam@gmail.com Tue Jun 26 15:23: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 9623F11E80D0 for ; Tue, 26 Jun 2012 15:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+T0SQLpckg8 for ; Tue, 26 Jun 2012 15:23:54 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8123C11E80CA for ; Tue, 26 Jun 2012 15:23:54 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so711524lbb.31 for ; Tue, 26 Jun 2012 15:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=yZkkaDKx6S01GVE0uc4vJgP8K8hjJ2pXI5fiWd/TFT4=; b=xgsHno57OxQTXG7CKHsGQCg+cWyBSWrJl8hiFn3+qVwxuGnpS9n9/wR4O/RXxxd3e1 ++cx8Cyr0u90xx/liFn9oU/WpJj7Q4g0dcsEgYsQ4H2Phs9pf9xL60qOuuzKopKIn9cD EmzOw2CwYX20zWwTdLF+PvNpFJsJpTJGeNFTl0lpTrZY9MxJiwFFYXPSNWlZx62ILQEw UqFv+7eCgkNyWo24ggBKb3vCL4zK3vhf5NKEl/k9DTn2aWGXdhOytyKNNHvi4HwZ9Rr2 05lhBui+kDkfrFmfWt4WrUcONN77q5P0EuPll/iLZrX3Ock8DXlungimt/h3YIrStApg Fs9g== Received: by 10.112.43.37 with SMTP id t5mr8632462lbl.89.1340749433219; Tue, 26 Jun 2012 15:23:53 -0700 (PDT) Received: from [62.237.209.67] ([62.237.209.67]) by mx.google.com with ESMTPS id hz16sm79699743lab.6.2012.06.26.15.23.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 15:23:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <20120625093320kawashimam@mail.jp.nec.com> Date: Wed, 27 Jun 2012 01:23:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4F0E3E03-49EF-4723-B1F8-613961A23729@gmail.com> References: <20120625002907.24191.87700.idtracker@ietfa.amsl.com> <20120625093320kawashimam@mail.jp.nec.com> To: Masanobu Kawashima X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 26 Jun 2012 22:23:55 -0000 Hi, Just to point out that this revision did not address the editorial comments I had that fixed e.g. some inconsistencies with references, see http://www.ietf.org/mail-archive/web/v6ops/current/msg13057.html - Jouni On Jun 25, 2012, at 3:33 AM, Masanobu Kawashima wrote: >=20 > Hi all, >=20 > We have published draft-ietf-v6ops-464xlat-04. > Can we move forward to WGLC? >=20 > Changes are: >=20 > - adding in the "Terminology" of CLAT that the CLAT does not > comply with "Both IPv4-translatable IPv6 addresses and > IPv4-converted IPv6 addresses SHOULD use the same prefix." > that is described on Section 3.3 in RFC 6052. >=20 > - splitting text of "using NAT44 and stateless XLATE on CLAT" > and "using only stateless XLATE on CLAT" in the section of > "IPv4/IPv6 Address Translation Chart" and "IPv6 Prefix > Handling" instead of deleting the section of "Relationship > between CLAT and NAT44" >=20 > - adding the combination with BIH [RFC6535] in the section of > "Introduction" and "Deployment Considerations". >=20 > - adding explanations about the diagram in the section of > "Network Architecture". >=20 > - adding the section of "Appendix A. Examples of IPv4/IPv6 > Address Translation". >=20 > - deleting marketing and commercial phrases (JPIX trial service). >=20 > All comments are welcome. >=20 > Regards, > Masanobu >=20 >=20 >>=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 : 464XLAT: Combination of Stateful and Stateless = Translation >> Author(s) : Masataka Mawatari >> Masanobu Kawashima >> Cameron Byrne >> Filename : draft-ietf-v6ops-464xlat-04.txt >> Pages : 18 >> Date : 2012-06-24 >>=20 >> Abstract: >> This document describes an architecture (464XLAT) for providing >> limited 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 limited IPv4 >> access service to IPv6-only edge networks without encapsulation. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-04 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-04 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC AccessTechnica, Ltd. =20 > Product Development Department =20 > Masanobu Kawashima =20 > kawashimam@vx.jp.nec.com =20 > http://www.necat.co.jp/ =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Tue Jun 26 16: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 7A29011E80B5 for ; Tue, 26 Jun 2012 16:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.139 X-Spam-Level: X-Spam-Status: No, score=-110.139 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=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 DeJnyB4tcuKP for ; Tue, 26 Jun 2012 16:18:47 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 607A611E809F for ; Tue, 26 Jun 2012 16:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=6202; q=dns/txt; s=iport; t=1340752727; x=1341962327; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e9q71qX9U4hJnYKXm+4CeIxEPGSMw+546LD1UpIf7Pc=; b=XbcVQNCkbGQipVNNr1MJR9fSC2qScM8Qs8i7kNrcEt8ZWcsyCjp9b7r3 Docay3E487cV4/wMWU7DBBS7yrXN1D5y98y9CRjd1Ix7r0eEbhhi1IlpG FEBCkWl2rh+B9TNkaplR2fV5s0NS5mJ/eMwNAmS3g8AYj+kQfdH2jCbGF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJFC6k+tJXG9/2dsb2JhbABFtjiBB4IYAQEBAwEBAQELBAEnKwkLBQcEAgEIEQQBAR8QJwsdCAIEDgUUDodkBQuZF6BAizeFKmADlTKBEo0LgWaCXw X-IronPort-AV: E=Sophos;i="4.77,480,1336348800"; d="scan'208";a="96249293" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jun 2012 23:18:46 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5QNIknb002261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Jun 2012 23:18:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.234]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Tue, 26 Jun 2012 18:18:46 -0500 From: "Fred Baker (fred)" To: "t.petch" Thread-Topic: [v6ops] Prep for v6ops IETF 84 agenda Thread-Index: AQHNU/IIWFu7FKUfJEyvobkjy/vWXQ== Date: Tue, 26 Jun 2012 23:18:45 +0000 Message-ID: References: <017901cd538a$e9af8980$4001a8c0@gateway.2wire.net> <20120626235550kawashimam@mail.jp.nec.com> <00b401cd53b0$88115840$4001a8c0@gateway.2wire.net> In-Reply-To: <00b401cd53b0$88115840$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.166.59] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18996.004 x-tm-as-result: No--57.853400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <2B43157669FE7F4384081EBA9AD0ADAC@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Jun 2012 23:18:48 -0000 On Jun 26, 2012, at 11:28 PM, t.petch wrote: > ----- Original Message ----- > From: "Masanobu Kawashima" > To: "t.petch" > Cc: ; "Fred Baker (fred)" ; "Ron Bonica" > > Sent: Tuesday, June 26, 2012 3:55 PM >>=20 >> Hi Tom, >>=20 >> Thank you for your comment. >>=20 >> We took your opinion into consideration. >> I think that we did everything we could. >> Could you please comment us your unclear points or suggestion? >> If we should revise the document, we will revise it immediately. >=20 > Ah, I haven't read -04 yet:-( >=20 > There was a quite a lot of comment on -03 so I was expecting a -04 and > confirmation or otherwise, on the list, that the comments had been > addressed. Then I saw Fred's note about -03, which came out a few minutes before I got the announcement of -04 :-) > which I still don't > understand but I realise I have no idea what sunset4 is, which may be > part of the part of the problem but thought that WGLC was premature > until a new version appeared so I drafted a note in response to Fred. http://datatracker.ietf.org/wg/sunset4/charter/ isn't all that helpful; the= IESG isn't done with the charter. But in essence, it is a working group fo= r documents that address issues in IPv4 during the IPv6 turn-up. As origina= lly written, it sounded like they couldn't mention IPv6 at all, which is si= lly. Current discussion among the chairs and the relevant ADs stops it shor= t of being a "transition mechanism working group", but permits discussion o= f transition mechanisms. At this point, the discussion has come down to cas= es: does document X fit? does document Y? How do we adjust the proposed cha= rter so that the point, yea or nay, is clear? Wes and Marc can probably comment more thoroughly, but that's where the dis= cussion stands as I understand it. > As I was about to hit send, I saw -04 had appeared but still thought > WGLC premature and sent the note anyway. >=20 > So I will read -04 and hope that everyone else who had comments will do > likewise, after which, I hope that the chairs will initiate WGLC. >=20 > Tom Petch >=20 >> Regards, >> Masanobu >>=20 >>=20 >>> I am confused about the legend for >>> draft-ietf-v6ops-464xlat-03.txt >>>=20 >>> There was a lively discussion in May which left a number of issues >>> unclear for me, and I see that, today, a new version has arrived, so > I >>> think that further discussion should ensue, preferrably on the list. >>>=20 >>> Tom Petch >>>=20 >>> ----- Original Message ----- >>> From: "Fred Baker (fred)" >>> To: >>> Cc: "Ron Bonica" >>> Sent: Monday, June 25, 2012 3:04 AM >>> Subject: [v6ops] Prep for v6ops IETF 84 agenda >>>=20 >>>=20 >>>> I sat down this morning to assess our agenda. Interested in working >>> group comment. >>>>=20 >>>> # no update >>>> Jan 11 16:48 draft-yang-v6ops-fast6-pppoe-02.txt >>>> Feb 21 18:10 > draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt >>>> Feb 23 07:29 draft-carpenter-v6ops-icp-guidance-03.txt >>>> Feb 25 11:37 draft-ietf-v6ops-ivi-icmp-address-01.txt >>>> Feb 28 08:49 draft-chkpvc-enterprise-incremental-ipv6-00.txt >>>> Mar 5 17:46 draft-ma-v6ops-terminal-test-00.txt >>>> Mar 7 07:33 draft-carpenter-v6ops-label-balance-02.txt >>>> Mar 12 06:21 draft-vanrein-v6ops-6bed4-01.txt >>>> Mar 12 17:52 draft-chen-v6ops-nat64-experience-01.txt >>>> Mar 12 21:34 draft-liu-v6ops-ula-usage-analysis-02.txt >>>> Mar 13 04:59 draft-sunq-v6ops-contents-transition-03.txt >>>> Mar 30 03:27 draft-donley-v6ops-ce-router-design-00.txt >>>> Mar 31 11:33 draft-yang-v6ops-fast6-00.txt >>>>=20 >>>> #no expressed interest >>>> Jun 20 11:33 draft-lopez-v6ops-dc-ipv6-02.txt >>>> Apr 27 12:07 draft-jiang-v6ops-v4v6mc-proxy-01.txt >>>>=20 >>>> #out of charter >>>> Jun 24 07:59 draft-generic-v6ops-tunmtu-07.txt >>>> May 10 11:44 draft-templin-v6ops-isops-17.txt >>>>=20 >>>> #in IESG queue >>>> May 30 11:10 draft-ietf-v6ops-wireline-incremental-ipv6-04.txt >>>> May 17 11:02 draft-ietf-v6ops-6204bis-09.txt >>>>=20 >>>>=20 >>>> #WGLC in v6ops or move to sunset4; awaiting AD direction >>>> May 8 10:14 draft-ietf-v6ops-464xlat-03.txt >>>>=20 >>>> #potential for agenda >>>> Apr 30 13:58 draft-gundavelli-v6ops-community-wifi-svcs-04.txt >>>> May 16 02:12 > draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt >>>> May 22 21:30 draft-ietf-v6ops-ra-guard-implementation-04.txt >>>>=20 >>>> #for agenda, perhaps ready for last call >>>> Jun 12 19:26 draft-ietf-v6ops-icp-guidance-01.txt >>>>=20 >>>>=20 >>>>=20 >>>> For draft-ietf-v6ops-ivi-icmp-address, the last discussion was in >>> April, and we were to expect an update. If that happens, I expect to >>> bring that to the agenda. >>>>=20 >>>> Lee asked about draft-chkpvc-enterprise-incremental-ipv6 on the > list, >>> but I see no update and I wasn't clear on the list commentary, > whether >>> the operators want to discuss. >>>>=20 >>>> There is still, of course, time for folks to post -00 drafts (until > 9 >>> July); if there is list discussion of those drafts, we will include > them >>> in the agenda. >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> NEC AccessTechnica, Ltd. >> Product Development Department >> Masanobu Kawashima >> kawashimam@vx.jp.nec.com >> http://www.necat.co.jp/ >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Tue Jun 26 16:21: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 22E9E11E80DF for ; Tue, 26 Jun 2012 16:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 iwiTjFcPuOi8 for ; Tue, 26 Jun 2012 16:21:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D8F8511E809F for ; Tue, 26 Jun 2012 16:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3864; q=dns/txt; s=iport; t=1340752901; x=1341962501; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=kAJFFgg+gUFftUP657TSsPmVC4rgcCBwdwts/FJn408=; b=mSH0NxOrXN3M/EvjFObajTpLP+Fk4hOJgMl61DPSjJzFUxHaEgRVXzGS /iDuYneX94KaQGrfdO+xdglFI1ADvTTjYXs1hzgUZcX+qyuL5tUtf+yWl 9/5+aq65t05ZkJ7u8dhD4zYS/rbiYnqfacf45dcHNIrh1m5jKtv44o+EF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEpD6k+tJV2d/2dsb2JhbABFtjiBB4IYAQEBAwEBAQEPASctBxALAgEZAwECDhEQIQYLGwIIAgQTCQsHB4dbAwYFC5kYlmUNiU6KVGMahRBgA5UyiwODGoFmgl+BXw X-IronPort-AV: E=Sophos;i="4.77,480,1336348800"; d="scan'208";a="96279243" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 26 Jun 2012 23:21:40 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q5QNLefe008063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Jun 2012 23:21:40 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.234]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Tue, 26 Jun 2012 18:21:40 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: WG Action: sunset4 (sunset4) Thread-Index: AQHNU/Jw5VwWz/AU4U+JCe+wpQLyog== Date: Tue, 26 Jun 2012 23:21:39 +0000 Message-ID: <546BCBFF-6751-4976-AD59-CE3A6DD23292@cisco.com> References: <20120501163318.8925.56287.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.166.59] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18996.004 x-tm-as-result: No--42.189400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Fwd: WG Action: sunset4 (sunset4) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Jun 2012 23:21:42 -0000 The sunset4 charter as I last saw it. > From: IESG Secretary > Date: May 2, 2012 12:33:18 AM GMT+08:00 > To: IETF Announcement List > Cc: sunset4@ietf.org > Subject: WG Action: sunset4 (sunset4) >=20 > A new IETF working group has been formed in the Internet Area. For addit= ional information, please contact the Area Directors or the WG Chairs. >=20 > sunset4 (sunset4) > -------------------- > Current Status: Active >=20 > Chairs (proposed): > Marc Blanchet > Wes George >=20 > INT Area Director: > Ralph Droms >=20 > Area Advisors: > OPS: Fred Baker > TSV: Martin Stiemerling > RTG: Stewart Bryant >=20 > Mailing Lists: > Address: sunset4@ietf.org > List Subscription: https://www.ietf.org/mailman/listinfo/sunset4 > Email Archive: http://www.ietf.org/mail-archive/web/sunset4/ >=20 > Description of Working Group: >=20 > The IETF is committed to the deployment of IPv6 to ensure the > evolution of the Internet. However, the IPv4-only components of the > Internet must continue to operate as much as possible during the > transition from IPv4 to IPv6. >=20 > The Working Group will standardize technologies that facilitate the > graceful sunsetting of the IPv4 Internet in the context of the > exhaustion of IPv4 address space while IPv6 is deployed. These > technologies will likely be less optimal than equivalent technologies > for IPv6-only and dual-stack networks. The Working Group works only > on IPv4 protocols to facilitate IPv4 sunsetting. >=20 > The Working Group may work on fixing security bugs in existing > IPv4-specific protocols but is not chartered to add new security > functionality to those protocols. >=20 > The working group will provide a single venue for the consideration of > IPv4 sunsetting, while ensuring that any such technologies do not > impede the deployment of IPv6 and do not duplicate functions and > capabilities already available in existing technologies. Therefore, > along the lines of draft-george-ipv6-support, before the working > group adopts any technology, it must: >=20 > 1) describe the problem to be solved and show that there is widespread > demand for a solution > 2) demonstrate that the problem can not be solved with existing > technologies > 3) provide a description of the proposed solution along with the > impact on current IPv4-only use and its ability to promote the > deployment of IPv6=20 >=20 > These steps will likely be described in the form of a use case and > requirements document. >=20 > Only after the above mentioned steps have been completed and the > results accepted by the community will the IETF consider adding new > work items to the Working Group charter. This new work may include > protocol specifications. >=20 > The work spans over multiple IETF areas including as Internet, > Operations, Transport and Routing. Therefore, cross-area coordination > and support is essential and required. Any work on IPv4 to IPv6 > transition methods is out of scope. >=20 > The initial work items are: >=20 > * Review current Carrier-Grade NAT (CGN) documents and related issues, > including requirements for standardization, and determine if CGN is > a suitable sunsetting technology to become a work item: > draft-ietf-behave-lsn-requirements > draft-ietf-behave-nat-mib > CGN port allocation methods > * Gap analysis of IPv4 features to facilitate IPv4 sunsetting >=20 > Milestones >=20 > 2012-09 Complete review of CGN and, if necessary, propose CGN work > items > 2013-06 Send gap analysis on IPv4 sunsetting to IESG >=20 >=20 From mawatari@jpix.ad.jp Wed Jun 27 01:48: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 EB3BE21F8647 for ; Wed, 27 Jun 2012 01:48:33 -0700 (PDT) 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=[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 LoIsBp8qXrIc for ; Wed, 27 Jun 2012 01:48:33 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6C19121F8646 for ; Wed, 27 Jun 2012 01:48:32 -0700 (PDT) Received: from [192.168.0.229] (64es-v4pool4.jpix.ad.jp [202.90.12.4]) by mx20.jpix.ad.jp (Postfix) with ESMTP id B08C6FC021 for ; Wed, 27 Jun 2012 17:48:31 +0900 (JST) Date: Wed, 27 Jun 2012 17:48:29 +0900 From: MAWATARI Masataka To: v6ops@ietf.org In-Reply-To: <4F0E3E03-49EF-4723-B1F8-613961A23729@gmail.com> References: <20120625093320kawashimam@mail.jp.nec.com> <4F0E3E03-49EF-4723-B1F8-613961A23729@gmail.com> Message-Id: <20120627174828.F66D.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] I-D Action: draft-ietf-v6ops-464xlat-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: Wed, 27 Jun 2012 08:48:34 -0000 Dear Jouni-san, Sorry for missing your helpful comments and thank you very much for reminder. We will add your comments into next version. Kind Regards, Masataka MAWATARI * On Wed, 27 Jun 2012 01:23:45 +0300 * jouni korhonen wrote: > Hi, > > Just to point out that this revision did not address the > editorial comments I had that fixed e.g. some inconsistencies > with references, see > http://www.ietf.org/mail-archive/web/v6ops/current/msg13057.html > > - Jouni > > > On Jun 25, 2012, at 3:33 AM, Masanobu Kawashima wrote: > > > > > Hi all, > > > > We have published draft-ietf-v6ops-464xlat-04. > > Can we move forward to WGLC? > > > > Changes are: > > > > - adding in the "Terminology" of CLAT that the CLAT does not > > comply with "Both IPv4-translatable IPv6 addresses and > > IPv4-converted IPv6 addresses SHOULD use the same prefix." > > that is described on Section 3.3 in RFC 6052. > > > > - splitting text of "using NAT44 and stateless XLATE on CLAT" > > and "using only stateless XLATE on CLAT" in the section of > > "IPv4/IPv6 Address Translation Chart" and "IPv6 Prefix > > Handling" instead of deleting the section of "Relationship > > between CLAT and NAT44" > > > > - adding the combination with BIH [RFC6535] in the section of > > "Introduction" and "Deployment Considerations". > > > > - adding explanations about the diagram in the section of > > "Network Architecture". > > > > - adding the section of "Appendix A. Examples of IPv4/IPv6 > > Address Translation". > > > > - deleting marketing and commercial phrases (JPIX trial service). > > > > All comments are welcome. > > > > Regards, > > Masanobu From fgont@si6networks.com Wed Jun 27 05: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 23B7021F86C6 for ; Wed, 27 Jun 2012 05:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_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 G08Xt7e9BJZe for ; Wed, 27 Jun 2012 05:21:34 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 13B8521F8698 for ; Wed, 27 Jun 2012 05:21:34 -0700 (PDT) Received: from ldijon-156-65-32-229.w80-15.abo.wanadoo.fr ([80.15.111.229] helo=[192.168.1.14]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SjrFN-0001Go-GZ; Wed, 27 Jun 2012 14:21:25 +0200 Message-ID: <4FEAEE3B.5040804@si6networks.com> Date: Wed, 27 Jun 2012 13:27:55 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: IPv6 Operations References: <20120615013626.31172.89725.idtracker@ietfa.amsl.com> In-Reply-To: <20120615013626.31172.89725.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] New I-D on SLAAC DNS configuration problems (Fwd: New Version Notification for draft-gont-6man-slaac-dns-config-issues-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, 27 Jun 2012 12:21:35 -0000 Folks, We have published a new Internet-Draft entitled "Current issues with DNS Configuration Options for SLAAC". This draft if meant to address the SLAAC DNS configuration issues raised by Pavel on the 6man mailing-list, and also discusses other potential issues. The I-D is available at: The I-D is aimed at 6man, but since it discusses an operational problem, I've decided to send this heads-up to v6ops. Any comments will be highly appreciated. Thanks! Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-6man-slaac-dns-config-issues-00.txt Date: Thu, 14 Jun 2012 18:36:26 -0700 From: internet-drafts@ietf.org To: fgont@si6networks.com CC: pavlix@pavlix.net A new version of I-D, draft-gont-6man-slaac-dns-config-issues-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-6man-slaac-dns-config-issues Revision: 00 Title: Current issues with DNS Configuration Options for SLAAC Creation date: 2012-06-15 WG ID: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-gont-6man-slaac-dns-config-issues-00.txt Status: http://datatracker.ietf.org/doc/draft-gont-6man-slaac-dns-config-issues Htmlized: http://tools.ietf.org/html/draft-gont-6man-slaac-dns-config-issues-00 Abstract: RFC 6106 specifies two Neighbor Discovery options that can be included in Router Advertisement messages to convey information about DNS recursive servers and DNS Search Lists. Small lifetime values for the aforementioned options have been found to cause interoperability problems in those network scenarios in which these options are used to convey DNS-related information. This document analyzes the aforementioned problem, and formally updates RFC 6106 such that these issues are mitigated. The IETF Secretariat From iesg-secretary@ietf.org Wed Jun 27 10:49: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 6BC1C11E810E; Wed, 27 Jun 2012 10:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 RhiOvoGeAHz6; Wed, 27 Jun 2012 10:49:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B784211E8073; Wed, 27 Jun 2012 10:49:57 -0700 (PDT) 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.21 Message-ID: <20120627174957.18647.15377.idtracker@ietfa.amsl.com> Date: Wed, 27 Jun 2012 10:49:57 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Basic Requirements for IPv6 Customer Edge Routers) 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, 27 Jun 2012 17:49:58 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Basic Requirements for IPv6 Customer Edge Routers' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-07-11. 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 specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite are covered in the document. The document obsoletes RFC 6204, if approved. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6204bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6204bis/ballot/ No IPR declarations have been submitted directly on this I-D. From randy@psg.com Wed Jun 27 13:53: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 461FE21F86B5; Wed, 27 Jun 2012 13:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 UzORTusXpG+l; Wed, 27 Jun 2012 13:53:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C096321F86B1; Wed, 27 Jun 2012 13:53:40 -0700 (PDT) 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 1SjzF5-00074c-Ly; Wed, 27 Jun 2012 20:53:40 +0000 Date: Wed, 27 Jun 2012 10:53:38 -1000 Message-ID: From: Randy Bush To: The IESG In-Reply-To: <20120627174957.18647.15377.idtracker@ietfa.amsl.com> References: <20120627174957.18647.15377.idtracker@ietfa.amsl.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: IETF v6ops list , IETF Disgust Subject: Re: [v6ops] Last Call: (Basic Requirements for IPv6 Customer Edge Routers) 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, 27 Jun 2012 20:53:41 -0000 > - 'Basic Requirements for IPv6 Customer Edge Routers' > as Informational RFC this document persists in confusing routing and forwarding. there are no routing protocols, a la 1812, here. there is confused text such as 4.1. General Requirements The IPv6 CE router is responsible for implementing IPv6 routing; that is, the IPv6 CE router must look up the IPv6 destination address in its routing table to decide to which interface it should send the packet. which i thought was forwarding, not routing. RA/RD doeth not a router make. randy From marka@isc.org Wed Jun 27 17:31: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 03E1F11E8134; Wed, 27 Jun 2012 17:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.233, 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 O66l0iSB4-To; Wed, 27 Jun 2012 17:31:13 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 544AD11E8133; Wed, 27 Jun 2012 17:31:10 -0700 (PDT) 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 71B2A5F99B2; Thu, 28 Jun 2012 00:30:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7471:6721:a784:9471]) (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 78635216C33; Thu, 28 Jun 2012 00:30:53 +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 49AF52208913; Thu, 28 Jun 2012 10:30:51 +1000 (EST) To: Randy Bush From: Mark Andrews References: <20120627174957.18647.15377.idtracker@ietfa.amsl.com> In-reply-to: Your message of "Wed, 27 Jun 2012 10:53:38 -1000." Date: Thu, 28 Jun 2012 10:30:51 +1000 Message-Id: <20120628003051.49AF52208913@drugs.dv.isc.org> Cc: IETF v6ops list , The IESG , IETF Disgust Subject: Re: [v6ops] Last Call: (Basic Requirements for IPv6 Customer Edge Routers) 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, 28 Jun 2012 00:31:14 -0000 In message , Randy Bush writes: > > - 'Basic Requirements for IPv6 Customer Edge Routers' > > as Informational RFC > > this document persists in confusing routing and forwarding. > > there are no routing protocols, a la 1812, here. there is confused text > such as > > 4.1. General Requirements > > The IPv6 CE router is responsible for implementing IPv6 routing; that > is, the IPv6 CE router must look up the IPv6 destination address in > its routing table to decide to which interface it should send the > packet. > > which i thought was forwarding, not routing. It's static routing. And if there is down stream PD there will be next hop routers as well as interfaces in the table. > RA/RD doeth not a router make. > > randy > _______________________________________________ > 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 diego@tid.es Thu Jun 28 00:19:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7C211E81E4 for ; Thu, 28 Jun 2012 00:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.263 X-Spam-Level: X-Spam-Status: No, score=-5.263 tagged_above=-999 required=5 tests=[AWL=1.336, 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 VQTL0mLQXHxe for ; Thu, 28 Jun 2012 00:19:12 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3DF11E81C5 for ; Thu, 28 Jun 2012 00:19:11 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M6B00B26GBWE7@tid.hi.inet> for v6ops@ietf.org; Thu, 28 Jun 2012 09:19:08 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id B4.9F.26499.C650CEF4; Thu, 28 Jun 2012 09:19:08 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M6B00B22GBWE7@tid.hi.inet> for v6ops@ietf.org; Thu, 28 Jun 2012 09:19:08 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Thu, 28 Jun 2012 09:19:08 +0200 Date: Thu, 28 Jun 2012 07:19:07 +0000 From: "Diego R. Lopez" In-reply-to: <7EC83C63-AE66-4FD1-8EFE-2C2CF41F5106@gmail.com> X-Originating-IP: [10.95.64.115] To: Arturo Servin Message-id: Content-id: <147CD873D4F59D4383379F3551C21ACD@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [v6ops] Draft on DC migration to IPv6 Thread-index: AQHNUqhbgWRF7Aew1UKq7qhHvsQ1MZcM3AKAgAJZwwA= X-AuditID: 0a5f4068-b7f206d000006783-45-4fec056c9ec0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsXCFe/ApZvD+sbf4NBWXYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48usP6wFq0Ur5s27zt7A+FSgi5GTQ0LAROL766eMELaYxIV7 69m6GLk4hAQ2MkqsnXqKHcL5yShxb+oaVghnKaPEwxl/mbsYOThYBFQlFl6zAulmAzIfNf9m BwkLCxhJfJ/kBRLmFLCV2NG/kRVigYLEn3OPWUBKRAS0JXaeUQMJMwN1zlt3igXE5hWwlHj4 +gkbRNxMoqfhBBtEXFDix+R7LBBxHYne79+YIWxxiebWm1BxbYkn7y6ArWIE+uX7qTVMEKuM JY7sEwQJiwhYSaxq38AGcY2AxJI955khbFGJl4//sYKUCwnkSDx+JD2BUWIWkiNmITliFpIj ZiE5YhaSIxYwsq5iFCtOKspMzyjJTczMSTcw1MvI1MvMSy3ZxAiJt4wdjMt3qhxiFOBgVOLh 1fJ67S/EmlhWXJl7iFGSg0lJlLeW5Y2/EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe73FA5bwp iZVVqUX5MCkZDg4lCd6dIG2CRanpqRVpmTnApAKTZuLgBGnnAWqfAlLDW1yQmFucmQ6RP8Uo KSUOsVMAJJFRmgfX+4pRHOhIYd7pIFkeYPqD63oFNJAJaKBTAMg9xSWJCCmpBsZOtQ+ZUze+ Wiey+Ezeh7lpa3+tkqrymvJm85Itb/156xQWtj5MLrsvKXPjsbHTp/biVcWfWBnEvV+cFz65 8821rTK31BUNq/qrq7Mv88dv8Krn2BHf6rfriOvxAzKW31ZbGwr+2L9SN+/m8iVrjmw6mXHq mFS4vor7x2Vc507wBMkzHVxzYBWLEktxRqKhFnNRcSIAGxyeLzwDAAA= References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <7EC83C63-AE66-4FD1-8EFE-2C2CF41F5106@gmail.com> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on DC migration to 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: Thu, 28 Jun 2012 07:19:13 -0000 Hi Arturo, On 26 Jun 2012, at 21:25 , Arturo Servin wrote: > The maturity level 1 is a bit odd to me. Do you mean that it is com= mon to DC to translate all the traffic from v4 to v6 in the border? I am mi= sunderstanding something? The maturity level 1 corresponds to a datacenter in which all traffic it is= v4-based, and translation from and to the v6 Internet is provided at the border. Our = take is that this is the most common case nowadays. > Shouldn't be a dual stack network (with servers and services in v4)= a maturity level 0.5 or 1.5? If you have dual stack inside the datacenter fabric, you are at maturity le= vel 2. > I think also that there are some common scenarios not explored here= , for example some native dual stack servers and services combined with sin= gle stack services (web server in DS + database server in v4 only). As said in the introduction, the document concentrates in how is v6 applied= in the datacenter infrastructure, and the implications and features that this application has. A scenario like the one you describe would only be possibl= e in maturity level 2. It is true that we have not considered the different possibilities with res= pect to server and services that maturity levels have. We will update the draft including these considerations. Thanks for noting it. > The maturity level 3 I think that you need to add that a single sta= ck network is much simple to manage than a dual stack one. IMHO that will b= e the killer app for an IPv6 only DC. Agreed, provided that the v6 traffic grows up to a certain level and/or ven= dor solutions cover your needs for the supporting datacenter fabric to be relia= ble to the operator. Note that the argument of a simple stack network being easier= to manage is equally applicable to level 1. I think this is worth to be mentio= ned in the text as well. > Also, take a look at draft-ietf-v6ops-icp-guidance, there is some c= ontent that it is already there. Will do. Thanls for the pointer. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From arturo.servin@gmail.com Thu Jun 28 05: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 5FFA121F8568 for ; Thu, 28 Jun 2012 05:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PDAELqkym90 for ; Thu, 28 Jun 2012 05:58:19 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 787AA21F8567 for ; Thu, 28 Jun 2012 05:58:16 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1998345ghb.31 for ; Thu, 28 Jun 2012 05:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=1U6wXaobxH04AWGyuHuwDg6VsgFWk9qDqJSmL0Cru8U=; b=zz2E7yd0Ip2nWLOi2Zo+X+e9pVht+mTSq6PHHER9BZ0auvo9k5m2vOvA4le+oE8zu3 LuGNwwPN9UpCXFjVbta0S+1po5aTP2HWkkY7mN7UOj1lPTnlUle/iRWp81KmfTJNlGIx yzDH4uYXF6Z3m0H24yJhnRrk2hcVcg1y4nvU6MgPwZGtifCUbTafM4Co6lH25A4uUu8O tT0Iqw8gNRfWmFpOwclW+BmVyeMZ0i5ltHT5w6J6B7V+nSMCaJU68rqtpxmJgLTp87vg mihyaLwvebNT2gLuo6h95Ju2rwAaa9bla3T2LjFo8b9XaBGTREtulxdqwBrzHvyM1JBH EPxA== Received: by 10.236.181.199 with SMTP id l47mr2991110yhm.85.1340888296126; Thu, 28 Jun 2012 05:58:16 -0700 (PDT) Received: from ?IPv6:2001:13c7:7001:5128:3499:a706:2ecc:7f46? ([2001:13c7:7001:5128:3499:a706:2ecc:7f46]) by mx.google.com with ESMTPS id h15sm482369ank.1.2012.06.28.05.58.13 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jun 2012 05:58:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Arturo Servin In-Reply-To: Date: Thu, 28 Jun 2012 09:58:11 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <7EC83C63-AE66-4FD1-8EFE-2C2CF41F5106@gmail.com> To: Diego R. Lopez X-Mailer: Apple Mail (2.1278) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on DC migration to 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: Thu, 28 Jun 2012 12:58:20 -0000 Diego, Thanks for the reply. Just a new comment. On 28 Jun 2012, at 04:19, Diego R. Lopez wrote: > Hi Arturo, >=20 > On 26 Jun 2012, at 21:25 , Arturo Servin wrote: >> The maturity level 1 is a bit odd to me. Do you mean that it is = common to DC to translate all the traffic from v4 to v6 in the border? I = am misunderstanding something? >=20 > The maturity level 1 corresponds to a datacenter in which all traffic = it is v4-based, > and translation from and to the v6 Internet is provided at the border. = Our take is > that this is the most common case nowadays. Do you have some examples? Personally I haven't seen any (but I = have seen just a few DC with v6, so I am not expert. I am just curious = about the basis of your claim). I have seen load balancers in front of webservers, but that I = think is different. For now the most common that I have seen are load balancers in = DS and webservers in v4; and dual stack DCs where some services (i.e = web, dns and sometimes email ) are in v6 and some others (legacy = applications, video streaming, etc.) are in v4. Regards, as= From despres.remi@laposte.net Thu Jun 28 07:22: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 DE10121F85AA for ; Thu, 28 Jun 2012 07:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.531 X-Spam-Level: X-Spam-Status: No, score=-1.531 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 p6s3bXYI4wz2 for ; Thu, 28 Jun 2012 07:22:21 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id A209F21F8539 for ; Thu, 28 Jun 2012 07:22:21 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id ECF5C7000054; Thu, 28 Jun 2012 16:22:19 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 2569570000A7; Thu, 28 Jun 2012 16:22:18 +0200 (CEST) X-SFR-UUID: 20120628142219153.2569570000A7@msfrf2117.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: <20120626235329kawashimam@mail.jp.nec.com> Date: Thu, 28 Jun 2012 16:22:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <79510968-0EE0-473F-A0B1-DD4B35092523@laposte.net> <20120626235329kawashimam@mail.jp.nec.com> To: Masanobu Kawashima X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Thu, 28 Jun 2012 14:22:23 -0000 Le 2012-06-26 =E0 16:53, Masanobu Kawashima a =E9crit : >=20 > Hi Remi, >=20 > I'm sorry for late reply. >=20 > 464XLAT authors don't stick to the document category. OK, thanks. > If the chairs request changing the category, we will follow > their opinion as we did before. The question is then, are the chairs opposed to the draft being = published as experimental? Hope they will be open, so that we finish this thread. Regards, RD >=20 > Regards, > Masanobu >=20 >=20 >> Hi, Masanobu-san, >>=20 >> I have to confirm, no surprise, that I object to its BCP status = because: >> - it proposes more than just a combination of existing RFCs >> - it has close relationship with subjects discussed in Softwires such = as MAP and 4rd, without serious examination of this relationship. >>=20 >> OTOH, I also confirm that I would be pleased to support it if its = status is changed back to Informational (its original status) because: >> - It deals with a subject not covered by existing RFCs >> - It is based on ideas that have been, at least in part, tested in = the field. >> - Issues raised in the WG (other than the RFC status) have been dealt = with. >>=20 >> Kind regards, >> RD >>=20 >>=20 >> Le 2012-06-25 02:33, Masanobu Kawashima a rit : >>=20 >>>=20 >>> Hi all, >>>=20 >>> We have published draft-ietf-v6ops-464xlat-04. >>> Can we move forward to WGLC? >>>=20 >>> Changes are: >>>=20 >>> - adding in the "Terminology" of CLAT that the CLAT does not >>> comply with "Both IPv4-translatable IPv6 addresses and >>> IPv4-converted IPv6 addresses SHOULD use the same prefix." >>> that is described on Section 3.3 in RFC 6052. >>>=20 >>> - splitting text of "using NAT44 and stateless XLATE on CLAT" >>> and "using only stateless XLATE on CLAT" in the section of >>> "IPv4/IPv6 Address Translation Chart" and "IPv6 Prefix >>> Handling" instead of deleting the section of "Relationship >>> between CLAT and NAT44" >>>=20 >>> - adding the combination with BIH [RFC6535] in the section of >>> "Introduction" and "Deployment Considerations". >>>=20 >>> - adding explanations about the diagram in the section of >>> "Network Architecture". >>>=20 >>> - adding the section of "Appendix A. Examples of IPv4/IPv6 >>> Address Translation". >>>=20 >>> - deleting marketing and commercial phrases (JPIX trial service). >>>=20 >>> All comments are welcome. >>>=20 >>> Regards, >>> Masanobu >>>=20 >>>=20 >>>>=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 : 464XLAT: Combination of Stateful and Stateless = Translation >>>> Author(s) : Masataka Mawatari >>>> Masanobu Kawashima >>>> Cameron Byrne >>>> Filename : draft-ietf-v6ops-464xlat-04.txt >>>> Pages : 18 >>>> Date : 2012-06-24 >>>>=20 >>>> Abstract: >>>> This document describes an architecture (464XLAT) for providing >>>> limited 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 limited IPv4 >>>> access service to IPv6-only edge networks without encapsulation. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat >>>>=20 >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-04 >>>>=20 >>>> A diff from previous version is available at: >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-04 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC AccessTechnica, Ltd. =20 > Product Development Department =20 > Masanobu Kawashima =20 > kawashimam@vx.jp.nec.com =20 > http://www.necat.co.jp/ =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 From Fred.L.Templin@boeing.com Thu Jun 28 09:34: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 190D221F858F for ; Thu, 28 Jun 2012 09:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=-0.103, 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 OlhEqwWAapBe for ; Thu, 28 Jun 2012 09:34:28 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) by ietfa.amsl.com (Postfix) with ESMTP id 4D00921F854E for ; Thu, 28 Jun 2012 09:34:28 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5SGYSqV027630 for ; Thu, 28 Jun 2012 09:34:29 -0700 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.16.37]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5SGYRnS027613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 28 Jun 2012 09:34:28 -0700 Received: from blv-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5SGYQ5X001030; Thu, 28 Jun 2012 09:34:26 -0700 Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5SGYQCT001021 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 28 Jun 2012 09:34:26 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Thu, 28 Jun 2012 09:34:26 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" , "v6ops@ietf.org WG" Date: Thu, 28 Jun 2012 09:34:25 -0700 Thread-Topic: Prep for v6ops IETF 84 agenda Thread-Index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXZcP8g9Q Message-ID: References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> In-Reply-To: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Jun 2012 16:34:32 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Fred Baker (fred) > Sent: Sunday, June 24, 2012 7:05 PM > To: v6ops@ietf.org WG > Cc: Ron Bonica > Subject: [v6ops] Prep for v6ops IETF 84 agenda >=20 > I sat down this morning to assess our agenda. Interested in working group > comment. OK Fred; I'll bite. Why are you listing 'draft-generic-v6ops-tunmtu' as "#out of charter"? Thanks - Fred fred.l.templin@boeing.com > # no update > Jan 11 16:48 draft-yang-v6ops-fast6-pppoe-02.txt > Feb 21 18:10 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt > Feb 23 07:29 draft-carpenter-v6ops-icp-guidance-03.txt > Feb 25 11:37 draft-ietf-v6ops-ivi-icmp-address-01.txt > Feb 28 08:49 draft-chkpvc-enterprise-incremental-ipv6-00.txt > Mar 5 17:46 draft-ma-v6ops-terminal-test-00.txt > Mar 7 07:33 draft-carpenter-v6ops-label-balance-02.txt > Mar 12 06:21 draft-vanrein-v6ops-6bed4-01.txt > Mar 12 17:52 draft-chen-v6ops-nat64-experience-01.txt > Mar 12 21:34 draft-liu-v6ops-ula-usage-analysis-02.txt > Mar 13 04:59 draft-sunq-v6ops-contents-transition-03.txt > Mar 30 03:27 draft-donley-v6ops-ce-router-design-00.txt > Mar 31 11:33 draft-yang-v6ops-fast6-00.txt >=20 > #no expressed interest > Jun 20 11:33 draft-lopez-v6ops-dc-ipv6-02.txt > Apr 27 12:07 draft-jiang-v6ops-v4v6mc-proxy-01.txt >=20 > #out of charter > Jun 24 07:59 draft-generic-v6ops-tunmtu-07.txt > May 10 11:44 draft-templin-v6ops-isops-17.txt >=20 > #in IESG queue > May 30 11:10 draft-ietf-v6ops-wireline-incremental-ipv6-04.txt > May 17 11:02 draft-ietf-v6ops-6204bis-09.txt >=20 >=20 > #WGLC in v6ops or move to sunset4; awaiting AD direction > May 8 10:14 draft-ietf-v6ops-464xlat-03.txt >=20 > #potential for agenda > Apr 30 13:58 draft-gundavelli-v6ops-community-wifi-svcs-04.txt > May 16 02:12 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt > May 22 21:30 draft-ietf-v6ops-ra-guard-implementation-04.txt >=20 > #for agenda, perhaps ready for last call > Jun 12 19:26 draft-ietf-v6ops-icp-guidance-01.txt >=20 >=20 >=20 > For draft-ietf-v6ops-ivi-icmp-address, the last discussion was in April, > and we were to expect an update. If that happens, I expect to bring that > to the agenda. >=20 > Lee asked about draft-chkpvc-enterprise-incremental-ipv6 on the list, but > I see no update and I wasn't clear on the list commentary, whether the > operators want to discuss. >=20 > There is still, of course, time for folks to post -00 drafts (until 9 > July); if there is list discussion of those drafts, we will include them > in the agenda. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Thu Jun 28 09:37: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 C726521F8516 for ; Thu, 28 Jun 2012 09:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 xBJ43xDfGUSb for ; Thu, 28 Jun 2012 09:37:58 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB1A21F850D for ; Thu, 28 Jun 2012 09:37:57 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2308.sfr.fr (SMTP Server) with ESMTP id 2D9A870000A3; Thu, 28 Jun 2012 18:37:57 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2308.sfr.fr (SMTP Server) with ESMTP id BF12570000F6; Thu, 28 Jun 2012 18:37:56 +0200 (CEST) X-SFR-UUID: 20120628163756782.BF12570000F6@msfrf2308.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: <00b401cd53b0$88115840$4001a8c0@gateway.2wire.net> Date: Thu, 28 Jun 2012 18:37:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <152970C3-BBA5-4399-B913-4D86907C6742@laposte.net> References: <017901cd538a$e9af8980$4001a8c0@gateway.2wire.net> <20120626235550kawashimam@mail.jp.nec.com> <00b401cd53b0$88115840$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Jun 2012 16:37:58 -0000 Hi, Tom, 2012-06-26 =E0 17:28, t.petch: ... > So I will read -04 and hope that everyone else who had comments will = do > likewise, after which, I hope that the chairs will initiate WGLC. FYI, after previous comments I had made on previous versions, I = commented -04 in = /www.ietf.org/mail-archive/web/v6ops/current/msg13314.html, to say: << I have to confirm, no surprise, that I object to its BCP status = because: - it proposes more than just a combination of existing RFCs - it has close relationship with subjects discussed in Softwires such as = MAP and 4rd, without serious examination of this relationship. OTOH, I also confirm that I would be pleased to support it if its status = is changed back to Informational (its original status) because: - It deals with a subject not covered by existing RFCs - It is based on ideas that have been, at least in part, tested in the = field. - Issues raised in the WG (other than the RFC status) have been dealt = with. >> Regards, RD From joelja@bogus.com Thu Jun 28 15:57: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 8083A21F84E7 for ; Thu, 28 Jun 2012 15:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 IGrcApQMtCi0 for ; Thu, 28 Jun 2012 15:57:54 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF9D21F84D3 for ; Thu, 28 Jun 2012 15:57:54 -0700 (PDT) Received: from 23515sphillips.corp.zynga.com (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 q5SMvr0r056157 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 28 Jun 2012 22:57:53 GMT (envelope-from joelja@bogus.com) Message-ID: <4FECE16E.5080007@bogus.com> Date: Thu, 28 Jun 2012 15:57:50 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120619 Thunderbird/14.0 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 28 Jun 2012 22:57:53 +0000 (UTC) Subject: [v6ops] fyi sessions scheduled. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Jun 2012 22:57:54 -0000 if you see conflicts with these times that are really undesirable, please let me know. --- Dear Joel Jaeggli, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. v6ops Session 1 (2:30:00) Thursday, Morning Session I 0900-1130 Room Name: Regency C --------------------------------------------- v6ops Session 2 (2:00:00) Friday, Morning Session I 0900-1100 Room Name: Regency C --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Area Name: Session Requester: Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2 Hours Number of Attendees: 300 Conflicts to Avoid: First Priority: 6man behave homenet softwire Second Priority: 6renum Third Priority: opsarea opsawg Special Requests: --------------------------------------------------------- From fred@cisco.com Thu Jun 28 16:21: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 2ADDD11E80D7 for ; Thu, 28 Jun 2012 16:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.274 X-Spam-Level: X-Spam-Status: No, score=-110.274 tagged_above=-999 required=5 tests=[AWL=-0.275, 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 VueXTRU0DM82 for ; Thu, 28 Jun 2012 16:21:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9D94911E80D3 for ; Thu, 28 Jun 2012 16:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3382; q=dns/txt; s=iport; t=1340925664; x=1342135264; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zpQgXkQEUaY3JpBhs9pMRIgIdLhuf8A5TWrnrzwXStU=; b=VyTaMGbDi/TWws0VzNTAP6xhwvyBwOnHhtGdXBtWt4mu6WQXUcTAwR21 U4ha0V5ydoO0S1zi2ZWGGVnVEFLb91vvfFoxJWBomZX6Yxil2QjWMnGAm +3LJhO23Ti8/48UFsiQmreYHzUmje8vXVnmknTx5he4p1aV2RkfUZ9k03 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALbm7E+tJV2a/2dsb2JhbABFtkSBB4IYAQEBAwEBAQEPASc0CwUHBAIBCBEDAQEBHwkHJwsUCQgCBA4FIodkBQuYJqBbBIs3hSpgA5Uyjh2BZoJf X-IronPort-AV: E=Sophos;i="4.77,494,1336348800"; d="scan'208";a="97051828" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jun 2012 23:21:04 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5SNL41b010854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Jun 2012 23:21:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.234]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Thu, 28 Jun 2012 18:21:03 -0500 From: "Fred Baker (fred)" To: "Templin, Fred L" Thread-Topic: Prep for v6ops IETF 84 agenda Thread-Index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXQ== Date: Thu, 28 Jun 2012 23:21:02 +0000 Message-ID: References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.168.105] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19002.004 x-tm-as-result: No--70.370500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <950004C7AB24A644A87782E747594E45@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Jun 2012 23:21:06 -0000 On Jun 29, 2012, at 12:34 AM, Templin, Fred L wrote: >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf O= f >> Fred Baker (fred) >> Sent: Sunday, June 24, 2012 7:05 PM >> To: v6ops@ietf.org WG >> Cc: Ron Bonica >> Subject: [v6ops] Prep for v6ops IETF 84 agenda >>=20 >> I sat down this morning to assess our agenda. Interested in working grou= p >> comment. >=20 > OK Fred; I'll bite. Why are you listing 'draft-generic-v6ops-tunmtu' > as "#out of charter"? Because changes to section 4.5 of RFC 2460 ("a source node may divide the p= acket...") is a change to RFC 2460, and should be discussed by the folks ma= intaining RFC 2460.=20 Begin forwarded message: > From: "Fred Baker (fred)" > Date: June 23, 2012 5:43:22 AM GMT+08:00 > To: Fred Templin , "v6ops@ietf.org WG" > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >=20 > Coming back to this as a meta-issue. >=20 > v6ops is about operational considerations and procedures, but not protoco= ls; disputing RFC 2460, aka redesigning IPv6, seems like a protocol issue. >=20 > The reason to not do inner fragmentation, if memory serves, has to do wit= h the behavior of fragmentation in the network and its effect on communicat= ions. For example, suppose you and I are in 9K clean networks (so the TCP M= SS starts out as 9K), my link to the public network has an MTU of 1500, and= somewhere en route to you there is another link with an MTU of 1400. When = I send a 9K packet, it will become six 1500 byte packets with a small caboo= se that picks up the size of five IP headers (IPv4 or IPv6), and what you w= ill receive is six 1400 byte packets interspersed with six 100+IP byte pack= ets, followed by the original caboose. What if the fragmenting router's que= ue, at the time of fragmentation, was one packet short of the needed capaci= ty? Maybe the retransmission follows a different path and is fragmented dif= ferently, resulting in funny overlaps whose handling isn't very well specif= ied. There's nothing *incorrect* about a stream of 13 packets of various si= zes being reassem > bled, but integrating retransmissions gets messy. IIRC, they just wanted = to clean that up. >=20 > Which brings me to the following consideration. >=20 > If we're talking about having one tunnel endpoint put a message into a tu= nnel datagram and then fragment it, and have the other tunnel endpoint reas= semble the original and forward it, we are talking about an operational pro= cedure that requires support in a router, but which I can correlate with se= ction 5 of RFC 2460. >=20 > One thing I would invite is discussion of operational experience with RFC= 4821. Wouldn't it be nice if the endpoint actually chose an MSS based on w= hat actually worked (shades of Happy Eyeballs), rather than depending on er= ror messages that network operators routinely filter out? >=20 > If we're talking about changing the recommendation of RFC 2460 regarding = who does fragmentation, that sounds like an IPv6 protocol change, and I'd l= ike to refer that to 6MAN. >=20 > Does that make sense? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Fri Jun 29 09:14: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 29AEE21F879B for ; Fri, 29 Jun 2012 09:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=-0.097, 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 oZFmJNcj85o8 for ; Fri, 29 Jun 2012 09:14:30 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 981D121F869D for ; Fri, 29 Jun 2012 09:14:17 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5TGEF5r002744 for ; Fri, 29 Jun 2012 11:14:16 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5TGEEiA002487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Jun 2012 11:14:15 -0500 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5TGEEKg030389; Fri, 29 Jun 2012 11:14:14 -0500 Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5TGEE4D030365 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 29 Jun 2012 11:14:14 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Fri, 29 Jun 2012 09:14:13 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" Date: Fri, 29 Jun 2012 09:14:12 -0700 Thread-Topic: Prep for v6ops IETF 84 agenda Thread-Index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXZcRfShA Message-ID: References: <8D73E1D6-A968-4397-A843-FE073197B7F1@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org WG" , Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 Jun 2012 16:14:32 -0000 Hi Fred, > -----Original Message----- > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Thursday, June 28, 2012 4:21 PM > To: Templin, Fred L > Cc: v6ops@ietf.org WG; Ron Bonica > Subject: Re: Prep for v6ops IETF 84 agenda >=20 >=20 > On Jun 29, 2012, at 12:34 AM, Templin, Fred L wrote: >=20 > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > >> Fred Baker (fred) > >> Sent: Sunday, June 24, 2012 7:05 PM > >> To: v6ops@ietf.org WG > >> Cc: Ron Bonica > >> Subject: [v6ops] Prep for v6ops IETF 84 agenda > >> > >> I sat down this morning to assess our agenda. Interested in working > group > >> comment. > > > > OK Fred; I'll bite. Why are you listing 'draft-generic-v6ops-tunmtu' > > as "#out of charter"? >=20 > Because changes to section 4.5 of RFC 2460 ("a source node may divide the > packet...") is a change to RFC 2460, and should be discussed by the folks > maintaining RFC 2460. OK, I think I get your meaning now. You are concerned that the draft in its current form seems to call for an update to RFC2460 - right? I'd like to propose a second alternative. Rather than taking this over to 6man, my draft could be revised to become a problem statement only rather than a functional specification. Then, the fact that "(only) a source node may divide the packet" becomes a problem to be addressed in a different document - and not something to be defied by this document. Would you be willing to consider a new draft version that stays within the problem statement narrative? Thanks - Fred fred.l.templin@boeing.com =20 > Begin forwarded message: >=20 > > From: "Fred Baker (fred)" > > Date: June 23, 2012 5:43:22 AM GMT+08:00 > > To: Fred Templin , "v6ops@ietf.org WG" > > > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu > > > > Coming back to this as a meta-issue. > > > > v6ops is about operational considerations and procedures, but not > protocols; disputing RFC 2460, aka redesigning IPv6, seems like a protoco= l > issue. > > > > The reason to not do inner fragmentation, if memory serves, has to do > with the behavior of fragmentation in the network and its effect on > communications. For example, suppose you and I are in 9K clean networks > (so the TCP MSS starts out as 9K), my link to the public network has an > MTU of 1500, and somewhere en route to you there is another link with an > MTU of 1400. When I send a 9K packet, it will become six 1500 byte packet= s > with a small caboose that picks up the size of five IP headers (IPv4 or > IPv6), and what you will receive is six 1400 byte packets interspersed > with six 100+IP byte packets, followed by the original caboose. What if > the fragmenting router's queue, at the time of fragmentation, was one > packet short of the needed capacity? Maybe the retransmission follows a > different path and is fragmented differently, resulting in funny overlaps > whose handling isn't very well specified. There's nothing *incorrect* > about a stream of 13 packets of various sizes being reassem > > bled, but integrating retransmissions gets messy. IIRC, they just wante= d > to clean that up. > > > > Which brings me to the following consideration. > > > > If we're talking about having one tunnel endpoint put a message into a > tunnel datagram and then fragment it, and have the other tunnel endpoint > reassemble the original and forward it, we are talking about an > operational procedure that requires support in a router, but which I can > correlate with section 5 of RFC 2460. > > > > One thing I would invite is discussion of operational experience with > RFC 4821. Wouldn't it be nice if the endpoint actually chose an MSS based > on what actually worked (shades of Happy Eyeballs), rather than depending > on error messages that network operators routinely filter out? > > > > If we're talking about changing the recommendation of RFC 2460 regardin= g > who does fragmentation, that sounds like an IPv6 protocol change, and I'd > like to refer that to 6MAN. > > > > Does that make sense? > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From ietfc@btconnect.com Fri Jun 29 11: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 2DF0221F883C for ; Fri, 29 Jun 2012 11:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=-0.764, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=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 eOdEIw267VvL for ; Fri, 29 Jun 2012 11:09:41 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0877621F881C for ; Fri, 29 Jun 2012 11:09:41 -0700 (PDT) Received: from mail109-db3-R.bigfish.com (10.3.81.232) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 29 Jun 2012 18:07:50 +0000 Received: from mail109-db3 (localhost [127.0.0.1]) by mail109-db3-R.bigfish.com (Postfix) with ESMTP id 4F86760432; Fri, 29 Jun 2012 18:07:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT011.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zz98dI9371I1be0I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail109-db3 (localhost.localdomain [127.0.0.1]) by mail109-db3 (MessageSwitch) id 1340993268158930_12120; Fri, 29 Jun 2012 18:07:48 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.239]) by mail109-db3.bigfish.com (Postfix) with ESMTP id 250DC320048; Fri, 29 Jun 2012 18:07:48 +0000 (UTC) Received: from DB3PRD0702HT011.eurprd07.prod.outlook.com (157.55.224.141) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 29 Jun 2012 18:07:47 +0000 Received: from AMSPRD0410HT003.eurprd04.prod.outlook.com (157.56.248.37) by pod51017.outlook.com (10.3.48.170) with Microsoft SMTP Server (TLS) id 14.15.86.1; Fri, 29 Jun 2012 18:09:36 +0000 Message-ID: <01b101cd5621$d70745e0$4001a8c0@gateway.2wire.net> From: t.petch To: MAWATARI Masataka References: <20120519112826.C685.8FE1F57E@jpix.ad.jp> <010a01cd39cb$1adc4540$4001a8c0@gateway.2wire.net> <20120529135457.FBA0.8FE1F57E@jpix.ad.jp> Date: Fri, 29 Jun 2012 19:05:47 +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-Originating-IP: [157.56.248.37] X-OriginatorOrg: btconnect.com Cc: v6ops@ietf.org Subject: Re: [v6ops] 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, 29 Jun 2012 18:09:42 -0000 I find -04 a definite improvement in clarity. Should it go further? unsure, I will wait to see what others say (eg about s.1 paragraph 2 with the references to client-server and peer-to-peer - I would prefer explicit reference to the addresses involved rather than the indirect reference via the nature of the application).. Tom Petch ----- Original Message ----- From: "MAWATARI Masataka" To: Cc: Sent: Tuesday, May 29, 2012 5:54 AM > Dear Tom-san, > > > Thank you for your comments. > > I understood your thoughts. > I will polish again the diagram on Section 5 and the overview by > adding the explanations. > > The IPv6 host on the diagram on Section 5.1 shows that a IPv6 host > can reach the other IPv6 hosts on the Internet via no translation. > This means that the CPE can not only have the function of CLAT but > also the function of IPv6 native router for IPv6 native traffic. > > And the 464XLAT architecture provides limited IPv4 service as you > understand. This is true due to hub-and-spoke model using stateful > translation. > > > Kind Regards, > Masataka MAWATARI > > > * On Thu, 24 May 2012 17:34:22 +0100 > * t.petch wrote: > > > I would like to see this published, regardless of status, but to think > > that it needs more work before it is ready for WGLC. It is just too > > hard to follow. When I supported its adoption by v6ops, I was expecting > > that it would be hammered into shape but that has not happened. > > > > It contains the detail but lacks the overview - framework, architecture > > or what, I do not mind, but it is that level of description that it > > lacks. Rather, the first four sections read like marketing, this is a > > great idea, you must buy it; err, no, tell me what it is, not the how or > > why, and I will decide whether or not to buy it. > > > > The description only starts at section 5 with a diagram, but this is a > > diagram that is worth minus one thousand words - if this is 464, then > > why is the first line a v6 address - that makes it 664! And something > > you do not explain. > > > > The terminology too seems ill-chosen. For example, clauses such as > > " limited to application > > that function in a client server model and is not fit for IPv4 peer- > > to-peer communication or inbound IPv4 connections." > > does not impart understanding. Of course there is an inbound IPv4 > > connection, your diagrams all show that. What I reverse-engineer from > > the I-D, is that the destination IP address used to establish the > > connection MUST be a global IPv4 address. Which is a much more specific > > limitation. > > > > So let's have an overview in section one and then see if the rest of it > > still makes sense. > > > > > > Tom Petch > > From philip_matthews@magma.ca Fri Jun 29 11:15: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 1BB8521F884E for ; Fri, 29 Jun 2012 11:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rgGpWYDzSoW0 for ; Fri, 29 Jun 2012 11:15:02 -0700 (PDT) Received: from mail-09.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 668DE21F8845 for ; Fri, 29 Jun 2012 11:15:02 -0700 (PDT) Received: from [74.198.165.39] (helo=[172.20.10.2]) by mail-09.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Skfie-0001Wv-12 for v6ops@ietf.org; Fri, 29 Jun 2012 14:15:02 -0400 From: Philip Matthews Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-5--238238311 Date: Fri, 29 Jun 2012 14:14:58 -0400 In-Reply-To: To: v6ops References: <20120629134643.1308.69156.idtracker@ietfa.amsl.com> Message-Id: <6BCCA339-F0B1-4CAC-A1FA-B2B3DF887D66@magma.ca> X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.39] Subject: [v6ops] New draft: draft-matthews-v6ops-design-guidelines-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, 29 Jun 2012 18:15:04 -0000 --Apple-Mail-5--238238311 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (Looks like my first attempt didn't make it for some reason, so I am = resending. My apologies if you receive two copies.) I have submitted a draft entitled "Design Guidelines for IPv6 Networks". = The intent is to present some of the common design choices that come up = when designing IPv6 networks, and document the pros and cons of the = various possible solutions. These are questions like "Should I do eBGP = peering with globals or link-locals?" that come up from time-to-time on = mailing lists or *NOG presentations. The goal is to document them in one = place, give fairly thorough discussion, and present a best-practice (if = we can come to some agreement).=20 The document is looking at both IPv6-only networks and mixed IPv4/IPv6 = networks. That is, a number of questions have to do with how IPv4 and = IPv6 should or should not be mixed in a network. The current version is very much a work-in-progress, with content in = some areas, but TBDs in other areas. Currently, I have put in content = around point-to-point links, static routing, and eBGP routing.=20 I have gotten some interesting feedback on a preliminary version from a = couple of people, but want to see what others say before doing more work = on the document. I would be interested in hearing comment on both the general idea of the = document, as well as comments on the current discussion areas and new = discussion areas. - Philip Begin forwarded message: > From: internet-drafts@ietf.org > Date: June 29, 2012 9:46:43 EDT > To: philip_matthews@magma.ca > Subject: New Version Notification for = draft-matthews-v6ops-design-guidelines-00.txt >=20 >=20 > A new version of I-D, draft-matthews-v6ops-design-guidelines-00.txt > has been successfully submitted by Philip Matthews and posted to the > IETF repository. >=20 > Filename: draft-matthews-v6ops-design-guidelines > Revision: 00 > Title: Design Guidelines for IPv6 Networks > Creation date: 2012-06-29 > WG ID: Individual Submission > Number of pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-matthews-v6ops-design-guidelines= -00.txt > Status: = http://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines > Htmlized: = http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-00 >=20 >=20 > Abstract: > This document presents advice on the design choices that arise when > designing IPv6 networks (both dual-stack and IPv6-only). The > intended audience is someone designing an IPv6 network who is > knowledgeable about best current practices around IPv4 network > design, and wishes to learn the corresponding practices for IPv6. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 --Apple-Mail-5--238238311 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I = have submitted a draft entitled "Design Guidelines for IPv6 Networks". = The intent is to present some of the common design choices that come up = when designing IPv6 networks, and document the pros and cons of the = various possible solutions. These are questions like "Should I do eBGP = peering with globals or link-locals?" that come up from time-to-time on = mailing lists or *NOG presentations. The goal is to document them in one = place, give fairly thorough discussion, and present a best-practice (if = we can come to some agreement). 

The document is = looking at both IPv6-only networks and mixed IPv4/IPv6 networks. =  That is, a number of questions have to do with how IPv4 and IPv6 = should or should not be mixed in a network.

The = current version is very much a work-in-progress, with content in some = areas, but TBDs in other areas.  Currently, I have put in content = around point-to-point links, static routing, and eBGP = routing. 

I have gotten some interesting = feedback on a preliminary version from a couple of people, but want to = see what others say before doing more work on the = document.

I would be interested in hearing = comment on both the general idea of the document, as well as comments on = the current discussion areas and new discussion = areas.

- Philip

Begin = forwarded message:

Date: June 29, 2012 9:46:43 EDT
Subject: New Version Notification for = draft-matthews-v6ops-design-guidelines-00.txt


A new version of I-D, = draft-matthews-v6ops-design-guidelines-00.txt
has been successfully = submitted by Philip Matthews and posted to the
IETF = repository.

Filename: = draft-matthews-v6ops-design-guidelines
Revision: = 00
Title: = = Design Guidelines for IPv6 Networks
Creation date: = 2012-06-29
WG ID: Individual Submission
Number = of pages: 10
URL: =             http://www.ietf.org/internet-drafts/draft-matthews-v6ops-= design-guidelines-00.txt
Status: =          http://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelin= es
Htmlized:        http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-00


Abstract:
  This document presents advice on = the design choices that arise when
  designing IPv6 = networks (both dual-stack and IPv6-only).  The
=   intended audience is someone designing an IPv6 network who = is
  knowledgeable about best current practices around = IPv4 network
  design, and wishes to learn the = corresponding practices for IPv6.




The IETF = Secretariat


= --Apple-Mail-5--238238311-- From touch@isi.edu Fri Jun 29 12:43: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 6450321F8661 for ; Fri, 29 Jun 2012 12:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.077 X-Spam-Level: X-Spam-Status: No, score=-105.077 tagged_above=-999 required=5 tests=[AWL=0.922, 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 0qNuEH+zS-Od for ; Fri, 29 Jun 2012 12:43:21 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5080221F8657 for ; Fri, 29 Jun 2012 12:43:21 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5TJghCl029240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jun 2012 12:42:43 -0700 (PDT) Message-ID: <4FEE0533.1060203@isi.edu> Date: Fri, 29 Jun 2012 12:42:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Templin, Fred L" References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "v6ops@ietf.org WG" , Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 Jun 2012 19:43:22 -0000 On 6/29/2012 9:14 AM, Templin, Fred L wrote: > Hi Fred, ... >>> OK Fred; I'll bite. Why are you listing 'draft-generic-v6ops-tunmtu' >>> as "#out of charter"? >> >> Because changes to section 4.5 of RFC 2460 ("a source node may divide the >> packet...") is a change to RFC 2460, and should be discussed by the folks >> maintaining RFC 2460. > > OK, I think I get your meaning now. You are concerned > that the draft in its current form seems to call for > an update to RFC2460 - right? > > I'd like to propose a second alternative. Rather than > taking this over to 6man, my draft could be revised to > become a problem statement only rather than a functional > specification. Then, the fact that "(only) a source node > may divide the packet" becomes a problem to be addressed > in a different document - and not something to be defied > by this document. I was expecting a differrent approach: a) revise this doc to focus on ops issues that don't require any standards changes b) propose the problem of IPv6 downstream refragmentation in a separate doc in a different WG Even a problem statement for (b) would need to be handled in a non-ops WG, AFAICT. Joe From Fred.L.Templin@boeing.com Fri Jun 29 13:10: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 CABF121F88D5 for ; Fri, 29 Jun 2012 13:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=-0.092, 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 xAqe9qoZia0B for ; Fri, 29 Jun 2012 13:10:57 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id 536E121F85A0 for ; Fri, 29 Jun 2012 13:10:57 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q5TKAuXt018016 for ; Fri, 29 Jun 2012 13:10:56 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q5TKAsJ0018001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Jun 2012 13:10:55 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q5TKAsnd011757; Fri, 29 Jun 2012 15:10:54 -0500 Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q5TKAsVY011733 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 29 Jun 2012 15:10:54 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Fri, 29 Jun 2012 13:10:53 -0700 From: "Templin, Fred L" To: Joe Touch Date: Fri, 29 Jun 2012 13:10:52 -0700 Thread-Topic: [v6ops] Prep for v6ops IETF 84 agenda Thread-Index: Ac1WL5ycrhwC71jqR/+m8XEHfMnATgAA3mGw Message-ID: References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> <4FEE0533.1060203@isi.edu> In-Reply-To: <4FEE0533.1060203@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org WG" , Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 Jun 2012 20:10:57 -0000 Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, June 29, 2012 12:43 PM > To: Templin, Fred L > Cc: Fred Baker (fred); v6ops@ietf.org WG; Ron Bonica > Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda >=20 >=20 >=20 > On 6/29/2012 9:14 AM, Templin, Fred L wrote: > > Hi Fred, > ... > >>> OK Fred; I'll bite. Why are you listing 'draft-generic-v6ops-tunmtu' > >>> as "#out of charter"? > >> > >> Because changes to section 4.5 of RFC 2460 ("a source node may divide > the > >> packet...") is a change to RFC 2460, and should be discussed by the > folks > >> maintaining RFC 2460. > > > > OK, I think I get your meaning now. You are concerned > > that the draft in its current form seems to call for > > an update to RFC2460 - right? > > > > I'd like to propose a second alternative. Rather than > > taking this over to 6man, my draft could be revised to > > become a problem statement only rather than a functional > > specification. Then, the fact that "(only) a source node > > may divide the packet" becomes a problem to be addressed > > in a different document - and not something to be defied > > by this document. >=20 > I was expecting a differrent approach: >=20 > a) revise this doc to focus on ops issues that > don't require any standards changes >=20 > b) propose the problem of IPv6 downstream refragmentation > in a separate doc in a different WG That sounds like a reasonable approach that can be accommodated within the draft cutoff date timeframe. > Even a problem statement for (b) would need to be handled in a non-ops > WG, AFAICT. OK - Thanks. Fred =20 > Joe From randy@psg.com Fri Jun 29 17:39: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 D2F6A11E8097 for ; Fri, 29 Jun 2012 17:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 jsNEzv6LWylG for ; Fri, 29 Jun 2012 17:39:02 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 58EC711E808D for ; Fri, 29 Jun 2012 17:39:02 -0700 (PDT) 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 1SkliH-000FX6-1G; Sat, 30 Jun 2012 00:39:01 +0000 Date: Fri, 29 Jun 2012 14:38:59 -1000 Message-ID: From: Randy Bush To: Philip Matthews In-Reply-To: <6BCCA339-F0B1-4CAC-A1FA-B2B3DF887D66@magma.ca> References: <20120629134643.1308.69156.idtracker@ietfa.amsl.com> <6BCCA339-F0B1-4CAC-A1FA-B2B3DF887D66@magma.ca> 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: IETF v6ops list Subject: Re: [v6ops] New draft: draft-matthews-v6ops-design-guidelines-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: Sat, 30 Jun 2012 00:39:02 -0000 >> A new version of I-D, draft-matthews-v6ops-design-guidelines-00.txt >> has been successfully submitted by Philip Matthews and posted to the >> IETF repository. >> >> Filename: draft-matthews-v6ops-design-guidelines >> Revision: 00 >> Title: Design Guidelines for IPv6 Networks >> Creation date: 2012-06-29 >> WG ID: Individual Submission >> Number of pages: 10 >> URL: http://www.ietf.org/internet-drafts/draft-matthews-v6ops-design-guidelines-00.txt >> Status: http://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines >> Htmlized: http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-00 i read this document prepared to laugh and/or puke. i was pleasantly surprised. this is generally quite good advice without getting religious, and a darned good start. congrats! randy From Tina.Tsou.Zouting@huawei.com Fri Jun 29 18:21: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 3589411E8088 for ; Fri, 29 Jun 2012 18:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.352 X-Spam-Level: X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[AWL=0.647, 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 4o8YPiNMpMcH for ; Fri, 29 Jun 2012 18:20:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C6C5211E808D for ; Fri, 29 Jun 2012 18:20:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHI04285; Fri, 29 Jun 2012 21:20:58 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 29 Jun 2012 18:20:17 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.109]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Fri, 29 Jun 2012 18:20:10 -0700 From: Tina TSOU To: Randy Bush , Philip Matthews Thread-Topic: [v6ops] New draft: draft-matthews-v6ops-design-guidelines-00.txt Thread-Index: AQHNViMoDPf3v3AqFUm8niNhTvrbXpcSeoyA//+U3SA= Date: Sat, 30 Jun 2012 01:20:09 +0000 Message-ID: References: <20120629134643.1308.69156.idtracker@ietfa.amsl.com> <6BCCA339-F0B1-4CAC-A1FA-B2B3DF887D66@magma.ca> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.114] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IETF v6ops list Subject: Re: [v6ops] New draft: draft-matthews-v6ops-design-guidelines-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: Sat, 30 Jun 2012 01:21:00 -0000 8. OSPF (TBD) I used basic OSPFv3 functionalities in IPv6 at my enterprise. Nothing speci= al was found. Tina @ 2001:db8:1:ffff:e8e2:7822:9d12:e12e > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Randy Bush > Sent: Friday, June 29, 2012 5:39 PM > To: Philip Matthews > Cc: IETF v6ops list > Subject: Re: [v6ops] New draft: draft-matthews-v6ops-design-guidelines- > 00.txt >=20 > >> A new version of I-D, draft-matthews-v6ops-design-guidelines-00.txt > >> has been successfully submitted by Philip Matthews and posted to the > >> IETF repository. > >> > >> Filename: draft-matthews-v6ops-design-guidelines > >> Revision: 00 > >> Title: Design Guidelines for IPv6 Networks > >> Creation date: 2012-06-29 > >> WG ID: Individual Submission > >> Number of pages: 10 > >> URL: http://www.ietf.org/internet-drafts/draft-matthews- > v6ops-design-guidelines-00.txt > >> Status: http://datatracker.ietf.org/doc/draft-matthews-v6ops- > design-guidelines > >> Htmlized: http://tools.ietf.org/html/draft-matthews-v6ops- > design-guidelines-00 >=20 > i read this document prepared to laugh and/or puke. i was pleasantly > surprised. this is generally quite good advice without getting > religious, and a darned good start. congrats! >=20 > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Sat Jun 30 05:45: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 B93BB21F8622 for ; Sat, 30 Jun 2012 05:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.099 X-Spam-Level: X-Spam-Status: No, score=-111.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 i1Q-pRrwQ2ug for ; Sat, 30 Jun 2012 05:45:08 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2A42F21F861E for ; Sat, 30 Jun 2012 05:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=140; q=dns/txt; s=iport; t=1341060301; x=1342269901; h=date:from:message-id:to:subject:cc; bh=aZ3ME0irb9uzQjZEdiOJr7be30UE6Se0jucsaywQBZM=; b=BiZi2hTHVacNlHIm4JNiyESHXQKYzQiUCHfDlInpNnWQO2k8zcVo0Tuz NH5gbkNSzC9td1e2tBZFcd1QFmg4Vd8VKx0u/qBPVeD1TfvxUAr8ADUej HLNRzYEBFYwWHTNNQxKQQvydloUEesnJ5SxwPhvWwQdITOxPyKVIPELtW A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIHANbz7k+rRDoJ/2dsb2JhbABFpgsBkEqBB4IxAWY8LYEKh2gMm0CfdI45gxwDiEqNfI0LgWaCfw X-IronPort-AV: E=Sophos;i="4.77,501,1336348800"; d="scan'208";a="50576157" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 30 Jun 2012 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5UCj1Kw023995; Sat, 30 Jun 2012 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q5UCj1c07569; Sat, 30 Jun 2012 05:45:01 -0700 (PDT) Date: Sat, 30 Jun 2012 05:45:01 -0700 (PDT) From: Message-Id: <201206301245.q5UCj1c07569@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-matthews-v6ops-design-guidelines@tools.ietf.org Subject: [v6ops] new draft: draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jun 2012 12:45:10 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines. Please take a look at it and comment. From fred@cisco.com Sat Jun 30 05:45: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 AE8E921F8582 for ; Sat, 30 Jun 2012 05:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.599 X-Spam-Level: X-Spam-Status: No, score=-111.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 hqEua7RERh1l for ; Sat, 30 Jun 2012 05:45:08 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 24F4D21F8472 for ; Sat, 30 Jun 2012 05:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=130; q=dns/txt; s=iport; t=1341060301; x=1342269901; h=date:from:message-id:to:subject:cc; bh=Nw1bPO+w2dfhGT4/BtW7bFQXD1h0LZb+TnkfsYT4+j8=; b=AsoIIbNsDKETxGMoFuiM3xopCBdTfe+Ez8cEd2QsCvZpN0WvTPDSuRSW s/NHWaEe6zcCfYId5DF9NCKldRIdc4Ps5YqPG29/mQ+Rs2dVCBIhd+AW6 5mLnAPV5RNojP5RM3zKFcteUxJBamBcHhmEa4mV3fD/7VLbCT5HSRfuUj 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIHAEP07k+rRDoJ/2dsb2JhbABFpgsBkEqBB4IxAWY8LYEKh2gMmz+fdI45gxwDiEqNfI0LgWaCfw X-IronPort-AV: E=Sophos;i="4.77,501,1336348800"; d="scan'208";a="47544216" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 30 Jun 2012 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5UCj1kn023996; Sat, 30 Jun 2012 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q5UCj1q07575; Sat, 30 Jun 2012 05:45:01 -0700 (PDT) Date: Sat, 30 Jun 2012 05:45:01 -0700 (PDT) From: Message-Id: <201206301245.q5UCj1q07575@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-zhang-v6ops-ipv6oa-iwf@tools.ietf.org Subject: [v6ops] new draft: draft-zhang-v6ops-ipv6oa-iwf X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jun 2012 12:45:10 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-zhang-v6ops-ipv6oa-iwf. Please take a look at it and comment.