From townsley@cisco.com Mon Mar 1 00:46:55 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762A03A8B19 for ; Mon, 1 Mar 2010 00:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1TXCS00OyL2 for ; Mon, 1 Mar 2010 00:46:54 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3D2B93A7930 for ; Mon, 1 Mar 2010 00:46:54 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANINi0urR7H+/2dsb2JhbACbEnOiH5c+hHsEjkI X-IronPort-AV: E=Sophos;i="4.49,559,1262563200"; d="scan'208";a="243144479" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 01 Mar 2010 08:46:54 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o218ksho001336 for ; Mon, 1 Mar 2010 08:46:54 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o218kqY08465 for ; Mon, 1 Mar 2010 00:46:53 -0800 (PST) Message-ID: <4B8B7EFB.20006@cisco.com> Date: Mon, 01 Mar 2010 09:46:51 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <428863.89468.qm@web45507.mail.sp1.yahoo.com> In-Reply-To: <428863.89468.qm@web45507.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 08:46:55 -0000 On 3/1/10 8:44 AM, Gabi Nakibly wrote: > Hi all, > I would like to comment on the loop avoidance issue addressed in the > Security Considerations section. > First, I agree that the the best mitigation measure here for loops via > external relays is to simply drop at the border of the 6rd domain > packets sent from or destined to a 6rd BR. > Second, regarding loops via internal relays the draft mentions that: > To avoid forwarding loops via other internal relays, the BR should > employ outgoing and incoming IPv4 packets filters, filtering out all > known relay addresses for internal 6rd BRs, ISATAP routers or 6to4 > relays, including the well known anycast address space for 6to4. > Does the SP necessarily knows of every ISATAP router or 6to4 > relay deployed in the 6rd domain? Deployed by the SP. > After all, a customer can deploy an ISATAP router or even a 6to4 relay > for that matter without the knowledge of the SP, while using > a configured tunnel (by a tunnel broker) for its IPv6 connectivity. As presented in Hiroshima, I don't think an attack between a subscriber's own equipment and the BR is a top concern. The amount of traffic a single subscriber can generate with a loop is no more than the subscriber could generate by downloading and uploading a lot of v6 content at the same time from outside the 6rd domain. Further, with a tunnel loop, the download path would be rate-limited by the upload path, which is generally quite asymmetric (e.g., today a bit-torrent user within a decent swarm off-net could generate more traffic on the BR than a loop). Point is, there a are a lot of ways a user can fill his own pipe, and a loop between relays is probably way down low on the list of interesting things to do. > I suggest to keep the filtering of internal 6rd BRs. But to avoid > loops via internal ISATAP routers or 6to4 relays, I would suggest > employing the destination/source address check described in Section > 3.1 in http://tools.ietf.org/html/draft-nakibly-v6ops-tunnel-loops-01 > we have recently submitted. It is not a perfect solution, and indeed > it should be updated in case other types of automatic tunnels come up, > but it does the job for ISATAP and 6to4 loops without demanding > a knowledge of every internal ISATAP router or 6to4 relay. If you are referring to this kind of check: For example, if tunnel router A (ISATAP router or 6to4 relay) forwards a packet into a tunnel interface with an IPv6 source address that matches the 6to4 prefix 2002:IPa::/48, the router discards the packet if IPa is one of its own IPv4 addresses. In a second example, if tunnel router B (ISATAP router or 6to4 relay) receives an IPv6 packet on a tunnel interface with an IPv6 destination address that matches the ISATAP address suffix ::0200:5EFE:IPb, the router discards the packet if IPb is one of its own IPv4 addresses. My concern here is that checking all possible local IPv4 addresses at a particular location in the IPv6 address for every packet switched through the BR would result in very significant overhead for a hardware-optimized implementation operating at high speed. I have no objection to someone doing this kind of check in their implementation, but their customers had better be willing to pay for it ;-) Currently, we have this paper referenced: [RoutingLoop] Nakibly and Arov, "Routing Loop Attacks using IPv6 Tunnels", August 2009,. Should we refer to your Internet Draft instead? > Other than this I fully support this draft for advancement. Thanks, - Mark > Gabi > > > ------------------------------------------------------------------------ > *From:* "Durand, Alain" > *To:* softwires ; DHC WG > *Cc:* Ole Troan > *Sent:* Mon, February 22, 2010 11:43:00 PM > *Subject:* [Softwires] SOFTWIRE working group last call on 6rd > > All - > > We'd like to announce the softwire WG LC on the 6rd technology. I've > copied both SOFTWIRE and DHC mailing lists and solicit comments from > both groups of experts. The draft is here: > > _http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-07.txt > _ > Please reply with comments to this thread by 2010.03.08 at 1700 PST > > Thanks > > - Alain > _______________________________________________ > Softwires mailing list > _Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires_ > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From townsley@cisco.com Mon Mar 1 01:08:31 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5403A8B22 for ; Mon, 1 Mar 2010 01:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyCKQ34b6-72 for ; Mon, 1 Mar 2010 01:08:31 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 04D9C3A7D14 for ; Mon, 1 Mar 2010 01:08:31 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHMTi0urR7Hu/2dsb2JhbACbEXOiHIppCIxLgmMIghAE X-IronPort-AV: E=Sophos;i="4.49,559,1262563200"; d="scan'208";a="489843419" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 01 Mar 2010 09:08:26 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2198Q4T021152 for ; Mon, 1 Mar 2010 09:08:26 GMT Received: from ams-townsley-8715.cisco.com (ams-townsley-8715.cisco.com [10.55.233.230]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2198OY11035 for ; Mon, 1 Mar 2010 01:08:24 -0800 (PST) Message-ID: <4B8B8406.4000402@cisco.com> Date: Mon, 01 Mar 2010 10:08:22 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 09:08:31 -0000 Hi Martin, great news on the interoperability. Thanks for sharing this. A good IPv4 ECMP load-balancing algorithm will take into account the source and destination IPv4 address pair and try to keep associated flows along the same path if possible. However, the fewer the IP addresses, the more difficult this becomes, and at some point the algorithm could favor balancing the load vs. keeping the detectable flows together. If your test was with a small number of RGs, perhaps this is what you were running into. In a typical deployment with a fairly large number of subscribers, each with their own source IPv4 address together with the relatively large link speeds on the routers performing ECMP vs. the subscriber's upstream bandwidth, I don't think you will see the same behavior you did in the lab. This is really good input for an operational document on 6rd though. Thanks, - Mark On 2/25/10 9:05 AM, Martin.Gysi@swisscom.com wrote: > > Hi, > > We have succesfully shown interoperability between the 6RD CEs of two > different manufacturers (integrated into VDSL routers) and the 6RD > border relays of yet another two manufacturers. All implementations > run smoothly, and we have not discovered any issues with the 6RD > technology. 6RD fits very well into a service provider enironment, > allowing for a cost efficient IPv6 deployment at a large scale. I > stronlgy support this draf'ts advancement to standards track. > > We are running a setup with redundant border relays. At first, we had > some issues with packet reordering when both relays had the same IGP > metric, and load balancing was performed on a per packet basis. This > adversely affected the TCP througphut of Windows XP. Other OS did not > suffer from this. We have now changed from load balancing to an > active/standby configuration. > > Best regards, > > Martin Gysi, Swisscom > > *From:* softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] > *On Behalf Of *Durand, Alain > *Sent:* Monday, February 22, 2010 10:43 PM > *To:* softwires; DHC WG > *Cc:* Ole Troan > *Subject:* [Softwires] SOFTWIRE working group last call on 6rd > > All - > > We'd like to announce the softwire WG LC on the 6rd technology. I've > copied both SOFTWIRE and DHC mailing lists and solicit comments from > both groups of experts. The draft is here: > > _http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-07.txt > _ > Please reply with comments to this thread by 2010.03.08 at 1700 PST > > Thanks > > - Alain > _______________________________________________ > Softwires mailing list > _Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires_ > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From Fred.L.Templin@boeing.com Mon Mar 1 13:49:45 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8985A28C197 for ; Mon, 1 Mar 2010 13:49:45 -0800 (PST) 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_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chU3blqKqsnp for ; Mon, 1 Mar 2010 13:49:44 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id D7B4A3A8AFE for ; Mon, 1 Mar 2010 13:49:42 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o21LnZmA026894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Mar 2010 15:49:36 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o21LnZnQ011603; Mon, 1 Mar 2010 13:49:35 -0800 (PST) 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 o21LnZHe011576 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 1 Mar 2010 13:49:35 -0800 (PST) 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, 1 Mar 2010 13:49:35 -0800 From: "Templin, Fred L" To: Ole Troan Date: Mon, 1 Mar 2010 13:49:29 -0800 Thread-Topic: SOFTWIRE working group last call on 6rd Thread-Index: Acq2e5wl4Tj10szeRZuzcU1yw2h3zgDDFIrg 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 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 21:49:45 -0000 Ole, Just getting back to e-mail after a three-day weekend: > -----Original Message----- > From: Ole Troan [mailto:ot@cisco.com] > Sent: Thursday, February 25, 2010 4:36 PM > To: Templin, Fred L > Cc: Martin.Gysi@swisscom.com; alain_durand@cable.comcast.com; softwires@i= etf.org > Subject: Re: SOFTWIRE working group last call on 6rd >=20 > Fred, >=20 > > Regarding the load balancing issue, if the CE routers are exposed to > > the list of unicast addresses of BRs they can use Equal Cost > > MultiPath (ECMP) to direct the load balancing if any load balancing > > is desired. This would allow multiple active BRs (as opposed to > > active/standy) and still give a nice distribution of traffic without > > packet reordering issues. >=20 > if you do per-packet load balancing you could get re-ordering in any plac= e in the network, assuming > multiple paths. regardless of what the CE does. > it would of course be beneficial if intermediate routers manage to do flo= w based load sharing also > for tunneled packets. I'm sorry I wasn't more specific, but what I intended to say was per-flow; not per-packet. It says this explicitly in Section 6.3.2 of draft-templin-intarea-vet. There is also the possibility for in-the-network ECMP if the tunneling mechanism were to use UDP encaps. as discussed in Section 4.2 of that document. > in any case one could adjust the IGP metrics for the anycast routes to av= oid any load balancing > between them from a single CE. You mean so that one BR always appears more favorable than all of the others? That may allow for fault tolerance but would seem to erase the opportunity for per-flow load balancing when there are multiple BRs that should really be seen as equivalent. Fred fred.l.templin@boeing.com=20 > cheers, > Ole >=20 > > > > Fred > > fred.l.templin@boeing.com > > > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On= Behalf Of > Martin.Gysi@swisscom.com > > Sent: Thursday, February 25, 2010 12:05 AM > > To: alain_durand@cable.comcast.com; softwires@ietf.org > > Cc: ot@cisco.com > > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > > > > Hi, > > > > We have succesfully shown interoperability between the 6RD CEs of two d= ifferent manufacturers > (integrated into VDSL routers) and the 6RD border relays of yet another t= wo manufacturers. All > implementations run smoothly, and we have not discovered any issues with = the 6RD technology. 6RD fits > very well into a service provider enironment, allowing for a cost efficie= nt IPv6 deployment at a > large scale. I stronlgy support this draf'ts advancement to standards tra= ck. > > > > We are running a setup with redundant border relays. At first, we had s= ome issues with packet > reordering when both relays had the same IGP metric, and load balancing w= as performed on a per packet > basis. This adversely affected the TCP througphut of Windows XP. Other OS= did not suffer from this. > We have now changed from load balancing to an active/standby configuratio= n. > > > > Best regards, > > Martin Gysi, Swisscom > > > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On= Behalf Of Durand, Alain > > Sent: Monday, February 22, 2010 10:43 PM > > To: softwires; DHC WG > > Cc: Ole Troan > > Subject: [Softwires] SOFTWIRE working group last call on 6rd > > > > All - > > > > We'd like to announce the softwire WG LC on the 6rd technology. I've co= pied both SOFTWIRE and DHC > mailing lists and solicit comments from both groups of experts. The draft= is here: > > > > http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-07.txt > > > > Please reply with comments to this thread by 2010.03.08 at 1700 PST > > > > Thanks > > > > - Alain > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires From Fred.L.Templin@boeing.com Mon Mar 1 14:05:07 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE9128C5D5 for ; Mon, 1 Mar 2010 14:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80IVgL86sWPB for ; Mon, 1 Mar 2010 14:05:06 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 1E32C28C17D for ; Mon, 1 Mar 2010 14:05:06 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o21M54ba005911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Mar 2010 16:05:05 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o21M52YU014277; Mon, 1 Mar 2010 14:05:03 -0800 (PST) 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 o21M50fu013852 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 1 Mar 2010 14:05:00 -0800 (PST) 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, 1 Mar 2010 14:04:59 -0800 From: "Templin, Fred L" To: Ole Troan Date: Mon, 1 Mar 2010 14:04:59 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: Acq2fLLKSnB5ReDxQTOsbIAxLSvQtgDDHopw Message-ID: References: <20100223203618.G A13301@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <12670 05876.2679.231.camel@lnxos-dev> <4B86D8F3.9000108@gmail.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: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 22:05:08 -0000 Ole, > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan > Sent: Thursday, February 25, 2010 4:44 PM > To: Templin, Fred L > Cc: Brian E Carpenter; softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > Fred, >=20 > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: Thursday, February 25, 2010 12:09 PM > >> To: Templin, Fred L > >> Cc: acassen@freebox.fr; softwires@ietf.org > >> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > >> > >> Hi Fred, > >> > >> On 2010-02-26 06:25, Templin, Fred L wrote: > >>> > >>>> -----Original Message----- > >>>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]= On Behalf Of Alexandre > Cassen > >>>> Sent: Wednesday, February 24, 2010 2:05 AM > >>>> To: softwires@ietf.org > >>>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > >>>> > >>>> Hi, > >>>> > >>>> On Mon, 22 Feb 2010 16:43:00 -0500, Durand, Alain wrote: > >>>>> We'd like to announce the softwire WG LC on the 6rd technology. I'v= e > >>>>> copied both SOFTWIRE and DHC mailing lists and solicit comments fro= m > >>>>> both groups of experts. The draft is here: > >>>>> > >>>>> http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-07= .txt > >>>>> > >>>>> Please reply with comments to this thread by 2010.03.08 at 1700 PST > >>>> This document truly depict what we are running into production in ou= r > >>>> backbone here. I strongly support it! > >>>> > >>>> I read some post on the ML regarding fragmentation and MTU related. > >>>> IMHO, section 9.1 is enough explicit, anyone playing around with > >>>> encapsulation will face at one point MTU issues and fragmentation, i= t is > >>>> really common. Any operational networking guy will/have to keep in m= ind > >>>> this MTU stuff while designing/setting up its encapsulation > >>>> architecture. What is important here, 6rd is operating inside a spec= ific > >>>> routing domain so that if there is MTU/fragmentation issues then it = is > >>>> networking domain designer job/responsibility to fix it ! if network= ing > >>>> design has been made into a crappy way then it will transitively ope= rate > >>>> into a crappy way too. IMHO, it should certainly not be the focus of= an > >>>> operational protocol draft, like 6rd, to provide a networking course= . > >>>> > >>>> In our production env, MTU is set to 1480 at CPE side. > >>> > >>> Here's another thing to consider wrt the 1480. Once the > >>> CPE statically sets a 1480, it will be next to impossible > >>> to get it to set something larger in the future. > >> > >> So what? 6RD is definitely a transition technique running over > >> legacy IPv4. I think we have running code experience that > >> defaulting the MTU to 1480 will work in most normal circumstances, > >> whereas reliance on PMTUD is known to be problematic. > > > > To be clear, I am not asking for reliance on PMTUD. I am > > instead asking for reliance on something better than that > > (SEAL) so that no artificial limits like 1480 are needed. > > > >> If 1480 > >> becomes an issue, it will become part of the motivation to upgrade > >> to native IPv6. > > > > This kind of argument strikes me as a business-oriented > > rather than technical viewpoint on the problem space. We > > now have technologies by which we can deploy tunneled > > service that is as good as or perhaps even better than > > native (and yes, I include 6rd as part of the solution). > > So, why not have a once-and-done deployment now as opposed > > to putting up a temporary service which we know will need > > replacement in the near future? So that network equipment > > vendors can sell more products and services? >=20 > I do agree that MTU handling is a general problem, and not even just for = tunnels. > I thought we agreed while discussing earlier versions of this draft, We had not reached an agreement by my reckoning; I was expecting follow-up from you, and perhaps you were expecting follow-up from me and the ball got dropped. > not to encumber the 6rd > specification with the general solutions to these MTU problems. "Encumber" is IMHO not the correct word; the more accurate word would be "improve". The SEAL spec is going to give flexibility whereby the tunnel egress can reassemble as much or as little as it wants, with no reassembly at all as the limiting case. The spec will say that the egress SHOULD reassemble IPv6 packets up to 1500 bytes and MAY reassemble more. But, that would not prevent a tunnel egress from performing no reassembly at all and simply report packet too bigs back to the ingress as necessary. Either way, unlike with classical path MTU discovery the ingress gets path MTU feedback that it can reliably relay back to the source. Fred fred.l.templin@boeing.com =20 =20 > 6rd references RFC4213 for most of the tunnel mechanics. could we move th= at debate to rfc4213bis or > something? >=20 > cheers, > Ole From Fred.L.Templin@boeing.com Mon Mar 1 17:09:20 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B01C28C6B0 for ; Mon, 1 Mar 2010 17:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HSU2-K3sKy4 for ; Mon, 1 Mar 2010 17:09:19 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id A84A528C6AB for ; Mon, 1 Mar 2010 17:09:18 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2219DI3013023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Mar 2010 19:09:14 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2219DvL021434; Mon, 1 Mar 2010 17:09:13 -0800 (PST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2219DBk021431 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 1 Mar 2010 17:09:13 -0800 (PST) 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; Mon, 1 Mar 2010 17:09:12 -0800 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Ole Troan Date: Mon, 1 Mar 2010 17:09:13 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: Acq2seSDpfDm1RVeSSiiduic19gGzQC2c+0w Message-ID: References: <20100223203618.G A13301@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <126700 5876.2679.231.camel@lnxos-dev><4B86D8F3.9000108@gmail.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 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 01:09:20 -0000 Remi, > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of R=E9mi Despr=E9s > Sent: Thursday, February 25, 2010 11:04 PM > To: Ole Troan > Cc: softwires@ietf.org; Templin, Fred L > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > Hi Fred, >=20 > Although the SEAL approach has IMHO some merit of its own for some genera= lized tunneling scenarios, > using it in 6rd would defeat the objective of simplicity for "rapid depl= oyment" of IPv6. There is an opportunity at hand to get tunneling done right the first time and then have a long-term quality IPv6 service. 6rd is a large piece to the puzzle, but there are other pieces that would make for a more complete solution. IMHO, we can have it both ways of doing it fast *and* doing it right on the first iteration. Fred fred.l.templin@boeing.com > The draft should therefore proceed as is on this subject. >=20 > RD >=20 > > Fred, > > > >>> -----Original Message----- > >>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >>> Sent: Thursday, February 25, 2010 12:09 PM > >>> To: Templin, Fred L > >>> Cc: acassen@freebox.fr; softwires@ietf.org > >>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > >>> > >>> Hi Fred, > >>> > >>> On 2010-02-26 06:25, Templin, Fred L wrote: > >>>> > >>>>> -----Original Message----- > >>>>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org= ] On Behalf Of Alexandre > Cassen > >>>>> Sent: Wednesday, February 24, 2010 2:05 AM > >>>>> To: softwires@ietf.org > >>>>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > >>>>> > >>>>> Hi, > >>>>> > >>>>> On Mon, 22 Feb 2010 16:43:00 -0500, Durand, Alain wrote: > >>>>>> We'd like to announce the softwire WG LC on the 6rd technology. I'= ve > >>>>>> copied both SOFTWIRE and DHC mailing lists and solicit comments fr= om > >>>>>> both groups of experts. The draft is here: > >>>>>> > >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-0= 7.txt > >>>>>> > >>>>>> Please reply with comments to this thread by 2010.03.08 at 1700 PS= T > >>>>> This document truly depict what we are running into production in o= ur > >>>>> backbone here. I strongly support it! > >>>>> > >>>>> I read some post on the ML regarding fragmentation and MTU related. > >>>>> IMHO, section 9.1 is enough explicit, anyone playing around with > >>>>> encapsulation will face at one point MTU issues and fragmentation, = it is > >>>>> really common. Any operational networking guy will/have to keep in = mind > >>>>> this MTU stuff while designing/setting up its encapsulation > >>>>> architecture. What is important here, 6rd is operating inside a spe= cific > >>>>> routing domain so that if there is MTU/fragmentation issues then it= is > >>>>> networking domain designer job/responsibility to fix it ! if networ= king > >>>>> design has been made into a crappy way then it will transitively op= erate > >>>>> into a crappy way too. IMHO, it should certainly not be the focus o= f an > >>>>> operational protocol draft, like 6rd, to provide a networking cours= e. > >>>>> > >>>>> In our production env, MTU is set to 1480 at CPE side. > >>>> > >>>> Here's another thing to consider wrt the 1480. Once the > >>>> CPE statically sets a 1480, it will be next to impossible > >>>> to get it to set something larger in the future. > >>> > >>> So what? 6RD is definitely a transition technique running over > >>> legacy IPv4. I think we have running code experience that > >>> defaulting the MTU to 1480 will work in most normal circumstances, > >>> whereas reliance on PMTUD is known to be problematic. > >> > >> To be clear, I am not asking for reliance on PMTUD. I am > >> instead asking for reliance on something better than that > >> (SEAL) so that no artificial limits like 1480 are needed. >=20 > See above. >=20 > >> > >>> If 1480 > >>> becomes an issue, it will become part of the motivation to upgrade > >>> to native IPv6. > >> > >> This kind of argument strikes me as a business-oriented > >> rather than technical viewpoint on the problem space. We > >> now have technologies by which we can deploy tunneled > >> service that is as good as or perhaps even better than > >> native (and yes, I include 6rd as part of the solution). > >> So, why not have a once-and-done deployment now as opposed > >> to putting up a temporary service which we know will need > >> replacement in the near future? So that network equipment > >> vendors can sell more products and services? > > > > I do agree that MTU handling is a general problem, and not even just fo= r tunnels. > > I thought we agreed while discussing earlier versions of this draft, no= t to encumber the 6rd > specification with the general solutions to these MTU problems. >=20 > This is IMHO the right approach. >=20 > > 6rd references RFC4213 for most of the tunnel mechanics. could we move = that debate to rfc4213bis or > something? > > > > cheers, > > Ole > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From guoseu@huawei.com Mon Mar 1 17:29:26 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98BC228C6A0; Mon, 1 Mar 2010 17:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ap1qfCdNKc9u; Mon, 1 Mar 2010 17:29:24 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2FAA428C679; Mon, 1 Mar 2010 17:29:24 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYM00F93S4Y8L@szxga04-in.huawei.com>; Tue, 02 Mar 2010 09:29:22 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYM0002JS4YWX@szxga04-in.huawei.com>; Tue, 02 Mar 2010 09:29:22 +0800 (CST) Received: from g57775 ([10.111.12.162]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYM00A26S4X7C@szxml06-in.huawei.com>; Tue, 02 Mar 2010 09:29:22 +0800 (CST) Date: Tue, 02 Mar 2010 09:29:21 +0800 From: Dayong Guo To: softwires@ietf.org Message-id: <000c01cab9a7$c972c760$a20c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acq5QD0+LOmWb4b2TjuuQ0wQFFCZGwAZWSRw Cc: 'DHC WG' Subject: [Softwires] FW: New Version Notification for draft-guo-softwire-6rd-ipv6-config-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 01:29:27 -0000 =20 Dayong Guo Huawei Technologies Co., Ltd. =20 Email=A3=BAguoseu@huawei.com http://www.huawei.com Hi, all A new draft about IPv6 auto-configuration in 6rd scenario was submitted. Any comments are welcome. Xiaohu Xu & Dayong Guo -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Monday, March 01, 2010 9:02 PM To: xuxh@huawei.com Cc: guoseu@huawei.com Subject: New Version Notification for = draft-guo-softwire-6rd-ipv6-config-00 A new version of I-D, draft-guo-softwire-6rd-ipv6-config-00.txt has been successfuly submitted by Xiaohu Xu and posted to the IETF repository. Filename: draft-guo-softwire-6rd-ipv6-config Revision: 00 Title: IPv6 Host Configuration in 6rd Deployment Creation_date: 2010-03-01 WG ID: Independent Submission Number_of_pages: 7 Abstract: This document proposes two new DHCPv4 options which allow IPv6 hosts to obtain configuration information (e.g., DNS servers). The DHCPv6 Server Option in DHCPv4 provides the IPv6 address of DHCPv6 server to the 6rd = CPE. In result the 6rd CPE can relay DHCPv6 requests to DHCPv6 servers. As an alternative, the IPv6 DNS Server Option is used = in the scenario where hosts only need the information of IPv6 DNS servers. =20 The IETF Secretariat. From Washam.Fan@huaweisymantec.com Mon Mar 1 17:57:44 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6560E28C5FB; Mon, 1 Mar 2010 17:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pyvyv5mUl0C8; Mon, 1 Mar 2010 17:57:43 -0800 (PST) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 5358E3A8C09; Mon, 1 Mar 2010 17:57:43 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=iso-2022-jp Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KYM00MHZTFXCC00@hstga01-in.huaweisymantec.com>; Tue, 02 Mar 2010 09:57:33 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KYM00BESTFXQK10@hstml01-in.huaweisymantec.com>; Tue, 02 Mar 2010 09:57:33 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 02 Mar 2010 09:57:33 +0800 From: WashamFan To: Dayong Guo Message-id: Date: Tue, 02 Mar 2010 09:57:33 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <000c01cab9a7$c972c760$a20c6f0a@china.huawei.com> References: <000c01cab9a7$c972c760$a20c6f0a@china.huawei.com> Cc: softwires@ietf.org, 'DHC WG' Subject: Re: [Softwires] FW: New Version Notification for draft-guo-softwire-6rd-ipv6-config-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 01:57:44 -0000 Hi, Do you assume the SP would provide DHCPv6 server and DNSv6 server for the hosts behind 6rd CEs? Since the SP network is IPv4-only, IMO, DHCPv6 server and DNSv6 server would be deployed in 6rd CE LAN side. In that case, DHCPv4 options defined in this draft would be not justified. I thought the hosts residing on the 6rd CE LAN side are dual stack hosts. If there is any IPv6-only host, a DNS proxy might be deployed (in the 6rd CE). Any comments? washam ----- Original Message ----- From: Dayong Guo Date: Tuesday, March 2, 2010 9:29 am Subject: [Softwires] FW: New Version Notification for draft-guo-softwire-6rd-ipv6-config-00 To: softwires@ietf.org Cc: 'DHC WG' > > > > Dayong Guo > > Huawei Technologies Co., Ltd. > Email$B!'(Bguoseu@huawei.com > http://www.huawei.com > > Hi, all > A new draft about IPv6 auto-configuration in 6rd scenario was > submitted. Any comments are welcome. > > Xiaohu Xu & Dayong Guo > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Monday, March 01, 2010 9:02 PM > To: xuxh@huawei.com > Cc: guoseu@huawei.com > Subject: New Version Notification for draft-guo-softwire-6rd-ipv6-config-00 > > > A new version of I-D, draft-guo-softwire-6rd-ipv6-config-00.txt has been > successfuly submitted by Xiaohu Xu and posted to the IETF repository. > > Filename: draft-guo-softwire-6rd-ipv6-config > Revision: 00 > Title: IPv6 Host Configuration in 6rd Deployment > Creation_date: 2010-03-01 > WG ID: Independent Submission > Number_of_pages: 7 > > Abstract: > This document proposes two new DHCPv4 options which allow IPv6 hosts > to > obtain configuration information (e.g., DNS servers). The DHCPv6 Server > Option in DHCPv4 provides the IPv6 address of DHCPv6 server to the > 6rd CPE. > In result the 6rd CPE can relay DHCPv6 requests to > DHCPv6 servers. As an alternative, the IPv6 DNS Server Option is > used in > the scenario where hosts only need the information of IPv6 DNS servers. > > > > > The IETF Secretariat. > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From xuxh@huawei.com Mon Mar 1 18:14:07 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E9F28C65D; Mon, 1 Mar 2010 18:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.891 X-Spam-Level: ** X-Spam-Status: No, score=2.891 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUYZM9W0DDkt; Mon, 1 Mar 2010 18:14:06 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 7C71328C679; Mon, 1 Mar 2010 18:13:59 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYM00DJNU70JF@szxga03-in.huawei.com>; Tue, 02 Mar 2010 10:13:48 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYM003MCU70SR@szxga03-in.huawei.com>; Tue, 02 Mar 2010 10:13:48 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.13.9]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYM009KCU6V86@szxml04-in.huawei.com>; Tue, 02 Mar 2010 10:13:48 +0800 (CST) Date: Tue, 02 Mar 2010 10:13:43 +0800 From: Xu Xiaohu In-reply-to: To: 'WashamFan' , 'Dayong Guo' Message-id: <00cf01cab9ad$fe8af200$090d6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acq5q8WlkQ3ehGdAQC+3hi7KCrPELgAAI0/Q Cc: softwires@ietf.org, 'DHC WG' Subject: Re: [Softwires] FW: New Version Notification for draft-guo-softwire-6rd-ipv6-config-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 02:14:07 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org] =B4=FA =B1=ED > WashamFan > =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA3=D4=C22=C8=D5 9:58 > =CA=D5=BC=FE=C8=CB: Dayong Guo > =B3=AD=CB=CD: softwires@ietf.org; 'DHC WG' > =D6=F7=CC=E2: Re: [Softwires] FW: New Version Notification for > draft-guo-softwire-6rd-ipv6-config-00 >=20 > Hi, >=20 > Do you assume the SP would provide DHCPv6 server and DNSv6 > server for the hosts behind 6rd CEs? Not accurate. Taken the DHCPv6 option usage as an example, the SP = provides the DHCPv6 server to the 6rd CPE which would act as a DHCPv6 relay = agent, the IPv6 hosts behind the 6rd CPE in turn obtain the configuration information (e.g., DNS, NTP etc) from the DHCPv6 server. > Since the SP network is IPv4-only, IMO, DHCPv6 server and > DNSv6 server would be deployed in 6rd CE LAN side. In that > case, DHCPv4 options defined in this draft would be not > justified. If a given DHCPv6 server is deployed in a customer site, its IPv6 = address should be a 6rd IPv6 address. In this case, the DHCP relay agent will = relay the information-request message to the 6rd CPE of that site, rather than = to the 6rd border relay. > I thought the hosts residing on the 6rd CE LAN side are dual stack > hosts. If there is any IPv6-only host, a DNS proxy might be > deployed (in the 6rd CE). Yes, if DNS is the only configuration information which the hosts need, = the DNS proxy mechanism can be used. However, if the hosts need other configuration information besides DNS, they should use the stateless = DHCPv6. Xiaohu > Any comments? >=20 > washam >=20 > ----- Original Message ----- > From: Dayong Guo > Date: Tuesday, March 2, 2010 9:29 am > Subject: [Softwires] FW: New Version Notification for > draft-guo-softwire-6rd-ipv6-config-00 > To: softwires@ietf.org > Cc: 'DHC WG' >=20 >=20 > > > > > > > > Dayong Guo > > > > Huawei Technologies Co., Ltd. > > Email=A3=BAguoseu@huawei.com > > http://www.huawei.com > > > > Hi, all > > A new draft about IPv6 auto-configuration in 6rd scenario was > > submitted. Any comments are welcome. > > > > Xiaohu Xu & Dayong Guo > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Monday, March 01, 2010 9:02 PM > > To: xuxh@huawei.com > > Cc: guoseu@huawei.com > > Subject: New Version Notification for > draft-guo-softwire-6rd-ipv6-config-00 > > > > > > A new version of I-D, draft-guo-softwire-6rd-ipv6-config-00.txt has been > > successfuly submitted by Xiaohu Xu and posted to the IETF = repository. > > > > Filename: draft-guo-softwire-6rd-ipv6-config > > Revision: 00 > > Title: IPv6 Host Configuration in 6rd Deployment > > Creation_date: 2010-03-01 > > WG ID: Independent Submission > > Number_of_pages: 7 > > > > Abstract: > > This document proposes two new DHCPv4 options which allow IPv6 = hosts > > to > > obtain configuration information (e.g., DNS servers). The DHCPv6 Server > > Option in DHCPv4 provides the IPv6 address of DHCPv6 server to the > > 6rd CPE. > > In result the 6rd CPE can relay DHCPv6 requests to > > DHCPv6 servers. As an alternative, the IPv6 DNS Server Option is > > used in > > the scenario where hosts only need the information of IPv6 DNS servers. > > > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From xuxh@huawei.com Mon Mar 1 18:41:13 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBC2428C5EC; Mon, 1 Mar 2010 18:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.541 X-Spam-Level: * X-Spam-Status: No, score=1.541 tagged_above=-999 required=5 tests=[AWL=1.351, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWYcEZr6jZPS; Mon, 1 Mar 2010 18:41:12 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2655528C231; Mon, 1 Mar 2010 18:41:12 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYM00MYGVFUHI@szxga04-in.huawei.com>; Tue, 02 Mar 2010 10:40:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYM002MWVFU6V@szxga04-in.huawei.com>; Tue, 02 Mar 2010 10:40:42 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.13.9]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYM00EA6VFU32@szxml06-in.huawei.com>; Tue, 02 Mar 2010 10:40:42 +0800 (CST) Date: Tue, 02 Mar 2010 10:40:41 +0800 From: Xu Xiaohu In-reply-to: To: 'WashamFan' , 'Dayong Guo' Message-id: <00d601cab9b1$c08e6d70$090d6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acq5q8WlkQ3ehGdAQC+3hi7KCrPELgAAI0/QAAEBSUA= Cc: softwires@ietf.org, 'DHC WG' Subject: Re: [Softwires] FW: New Version Notification for draft-guo-softwire-6rd-ipv6-config-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 02:41:14 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Xu Xiaohu [mailto:xuxh@huawei.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA3=D4=C22=C8=D5 10:14 > =CA=D5=BC=FE=C8=CB: 'WashamFan'; 'Dayong Guo' > =B3=AD=CB=CD: 'softwires@ietf.org'; 'DHC WG' > =D6=F7=CC=E2: re: [Softwires] FW: New Version Notification for > draft-guo-softwire-6rd-ipv6-config-00 >=20 >=20 >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: softwires-bounces@ietf.org = [mailto:softwires-bounces@ietf.org] =B4=FA > =B1=ED > > WashamFan > > =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA3=D4=C22=C8=D5 9:58 > > =CA=D5=BC=FE=C8=CB: Dayong Guo > > =B3=AD=CB=CD: softwires@ietf.org; 'DHC WG' > > =D6=F7=CC=E2: Re: [Softwires] FW: New Version Notification for > > draft-guo-softwire-6rd-ipv6-config-00 > > > > Hi, > > > > Do you assume the SP would provide DHCPv6 server and DNSv6 > > server for the hosts behind 6rd CEs? >=20 > Not accurate. Taken the DHCPv6 option usage as an example, the SP = provides the > DHCPv6 server to the 6rd CPE which would act as a DHCPv6 relay agent, = the IPv6 > hosts behind the 6rd CPE in turn obtain the configuration information (e.g., > DNS, NTP etc) from the DHCPv6 server. >=20 > > Since the SP network is IPv4-only, IMO, DHCPv6 server and > > DNSv6 server would be deployed in 6rd CE LAN side. In that > > case, DHCPv4 options defined in this draft would be not > > justified. >=20 > If a given DHCPv6 server is deployed in a customer site, its IPv6 = address should > be a 6rd IPv6 address. In this case, the DHCP relay agent will relay = the > information-request message to the 6rd CPE of that site, rather than = to the > 6rd border relay. The "customer" site mentioned above is a 6rd site which is actually = deployed by the SP and is used for holding IPv6 servers (e.g., DHCPv6 servers, = NTP servers and DNS servers etc).=20 For the small-sized sites, do you believe they should deploy their own DHCPv6 servers? Xiaohu > > I thought the hosts residing on the 6rd CE LAN side are dual stack > > hosts. If there is any IPv6-only host, a DNS proxy might be > > deployed (in the 6rd CE). >=20 > Yes, if DNS is the only configuration information which the hosts = need, the > DNS proxy mechanism can be used. However, if the hosts need other configuration > information besides DNS, they should use the stateless DHCPv6. >=20 > Xiaohu >=20 > > Any comments? > > > > washam > > > > ----- Original Message ----- > > From: Dayong Guo > > Date: Tuesday, March 2, 2010 9:29 am > > Subject: [Softwires] FW: New Version Notification for > > draft-guo-softwire-6rd-ipv6-config-00 > > To: softwires@ietf.org > > Cc: 'DHC WG' > > > > > > > > > > > > > > > > Dayong Guo > > > > > > Huawei Technologies Co., Ltd. > > > Email=A3=BAguoseu@huawei.com > > > http://www.huawei.com > > > > > > Hi, all > > > A new draft about IPv6 auto-configuration in 6rd scenario = was > > > submitted. Any comments are welcome. > > > > > > Xiaohu Xu & Dayong Guo > > > > > > -----Original Message----- > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > > Sent: Monday, March 01, 2010 9:02 PM > > > To: xuxh@huawei.com > > > Cc: guoseu@huawei.com > > > Subject: New Version Notification for > > draft-guo-softwire-6rd-ipv6-config-00 > > > > > > > > > A new version of I-D, draft-guo-softwire-6rd-ipv6-config-00.txt = has been > > > successfuly submitted by Xiaohu Xu and posted to the IETF = repository. > > > > > > Filename: draft-guo-softwire-6rd-ipv6-config > > > Revision: 00 > > > Title: IPv6 Host Configuration in 6rd Deployment > > > Creation_date: 2010-03-01 > > > WG ID: Independent Submission > > > Number_of_pages: 7 > > > > > > Abstract: > > > This document proposes two new DHCPv4 options which allow IPv6 = hosts > > > to > > > obtain configuration information (e.g., DNS servers). The DHCPv6 Server > > > Option in DHCPv4 provides the IPv6 address of DHCPv6 server to = the > > > 6rd CPE. > > > In result the 6rd CPE can relay DHCPv6 requests to > > > DHCPv6 servers. As an alternative, the IPv6 DNS Server Option is > > > used in > > > the scenario where hosts only need the information of IPv6 DNS servers. > > > > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > _______________________________________________ > > > Softwires mailing list > > > Softwires@ietf.org > > > https://www.ietf.org/mailman/listinfo/softwires > > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires From Washam.Fan@huaweisymantec.com Mon Mar 1 19:00:53 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 865853A8B0D; Mon, 1 Mar 2010 19:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFyFJRMKeYDf; Mon, 1 Mar 2010 19:00:52 -0800 (PST) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 3BE5E3A8A2F; Mon, 1 Mar 2010 19:00:13 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KYM002HWWC3XW50@hstga02-in.huaweisymantec.com>; Tue, 02 Mar 2010 11:00:03 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KYM00BTFWC3RG10@hstml01-in.huaweisymantec.com>; Tue, 02 Mar 2010 11:00:03 +0800 (CST) Received: from [10.27.154.141] by hstml01-in.huaweisymantec.com (mshttpd); Tue, 02 Mar 2010 11:00:03 +0800 From: WashamFan To: Xu Xiaohu Message-id: Date: Tue, 02 Mar 2010 11:00:03 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <00d601cab9b1$c08e6d70$090d6f0a@china.huawei.com> References: <00d601cab9b1$c08e6d70$090d6f0a@china.huawei.com> Cc: softwires@ietf.org, 'DHC WG' Subject: Re: [Softwires] FW: New Version Notification for draft-guo-softwire-6rd-ipv6-config-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 03:00:53 -0000 Hi, > > > Since the SP network is IPv4-only, IMO, DHCPv6 server and > > > DNSv6 server would be deployed in 6rd CE LAN side. In that > > > case, DHCPv4 options defined in this draft would be not > > > justified. > > > > If a given DHCPv6 server is deployed in a customer site, its IPv6 address > should > > be a 6rd IPv6 address. In this case, the DHCP relay agent will > relay the > > information-request message to the 6rd CPE of that site, rather > than to > the > > 6rd border relay. > > The "customer" site mentioned above is a 6rd site which is actually deployed > by the SP and is used for holding IPv6 servers (e.g., DHCPv6 servers, > NTP > servers and DNS servers etc). > > For the small-sized sites, do you believe they should deploy their own > DHCPv6 servers? My concern is, if DHCPv6 is deployed within 6rd CE LANs, extensions to DHCPv4 defined in the draft would not apply. If DHCPv6 server deployed in 6rd CE WAN, that is where your draft fits in, I guess. But how come DHCPv6 server is deployed in 6rd CE WAN which is IPv4-only SP network? Thanks, washam From guoseu@huawei.com Mon Mar 1 19:08:48 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98163A88B7; Mon, 1 Mar 2010 19:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.153 X-Spam-Level: X-Spam-Status: No, score=-0.153 tagged_above=-999 required=5 tests=[AWL=-2.447, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjMEmP0mM52a; Mon, 1 Mar 2010 19:08:47 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 878423A8A06; Mon, 1 Mar 2010 19:08:47 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYM00KJPWQ9IH@szxga03-in.huawei.com>; Tue, 02 Mar 2010 11:08:33 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYM00FP6WQ9AB@szxga03-in.huawei.com>; Tue, 02 Mar 2010 11:08:33 +0800 (CST) Received: from g57775 ([10.111.12.162]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYM00435WQ8EI@szxml06-in.huawei.com>; Tue, 02 Mar 2010 11:08:33 +0800 (CST) Date: Tue, 02 Mar 2010 11:08:33 +0800 From: Dayong Guo In-reply-to: <00cf01cab9ad$fe8af200$090d6f0a@china.huawei.com> To: 'Xu Xiaohu' , 'WashamFan' Message-id: <000d01cab9b5$a4ddf830$a20c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acq5q8WlkQ3ehGdAQC+3hi7KCrPELgAAI0/QAAFgFbA= Cc: softwires@ietf.org, 'DHC WG' Subject: Re: [Softwires] FW: New Version Notification for draft-guo-softwire-6rd-ipv6-config-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 03:08:48 -0000 Hi, washam Thanks for your comments. There some supplement to xiaohu's reply: 6rd scenario is more suitable to provide IPv6 access for home = network or small office, not for large business units. The formers generally = need configuration infomation from SP. Dayong Guo Huawei Technologies Co., Ltd. =20 Email=A3=BAguoseu@huawei.com http://www.huawei.com =20 > -----Original Message----- > From: Xu Xiaohu [mailto:xuxh@huawei.com]=20 > Sent: Tuesday, March 02, 2010 10:14 AM > To: 'WashamFan'; 'Dayong Guo' > Cc: softwires@ietf.org; 'DHC WG' > Subject: re: [Softwires] FW: New Version Notification for=20 > draft-guo-softwire-6rd-ipv6-config-00 >=20 >=20 >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: softwires-bounces@ietf.org=20 > [mailto:softwires-bounces@ietf.org] =B4=FA > =B1=ED > > WashamFan > > =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA3=D4=C22=C8=D5 9:58 > > =CA=D5=BC=FE=C8=CB: Dayong Guo > > =B3=AD=CB=CD: softwires@ietf.org; 'DHC WG' > > =D6=F7=CC=E2: Re: [Softwires] FW: New Version Notification for=20 > > draft-guo-softwire-6rd-ipv6-config-00 > >=20 > > Hi, > >=20 > > Do you assume the SP would provide DHCPv6 server and DNSv6=20 > server for=20 > > the hosts behind 6rd CEs? >=20 > Not accurate. Taken the DHCPv6 option usage as an example,=20 > the SP provides the DHCPv6 server to the 6rd CPE which would=20 > act as a DHCPv6 relay agent, the IPv6 hosts behind the 6rd=20 > CPE in turn obtain the configuration information (e.g., DNS,=20 > NTP etc) from the DHCPv6 server. >=20 > > Since the SP network is IPv4-only, IMO, DHCPv6 server and > > DNSv6 server would be deployed in 6rd CE LAN side. In that case,=20 > > DHCPv4 options defined in this draft would be not justified. >=20 > If a given DHCPv6 server is deployed in a customer site, its=20 > IPv6 address should be a 6rd IPv6 address. In this case, the=20 > DHCP relay agent will relay the information-request message=20 > to the 6rd CPE of that site, rather than to the 6rd border relay. >=20 > > I thought the hosts residing on the 6rd CE LAN side are dual stack=20 > > hosts. If there is any IPv6-only host, a DNS proxy might be=20 > deployed=20 > > (in the 6rd CE). >=20 > Yes, if DNS is the only configuration information which the=20 > hosts need, the DNS proxy mechanism can be used. However, if=20 > the hosts need other configuration information besides DNS,=20 > they should use the stateless DHCPv6. >=20 > Xiaohu >=20 > > Any comments? > >=20 > > washam > >=20 From xuxh@huawei.com Mon Mar 1 19:10:42 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD823A8A2F; Mon, 1 Mar 2010 19:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.091 X-Spam-Level: * X-Spam-Status: No, score=1.091 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9Y4-UaTCe7v; Mon, 1 Mar 2010 19:10:41 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 099283A8A06; Mon, 1 Mar 2010 19:10:28 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYM00D9GWTDQG@szxga04-in.huawei.com>; Tue, 02 Mar 2010 11:10:25 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYM002GPWTD6V@szxga04-in.huawei.com>; Tue, 02 Mar 2010 11:10:25 +0800 (CST) Received: from HUAWEIE75F8F11 ([10.111.13.9]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYM004S3WTDEI@szxml06-in.huawei.com>; Tue, 02 Mar 2010 11:10:25 +0800 (CST) Date: Tue, 02 Mar 2010 11:10:25 +0800 From: Xu Xiaohu In-reply-to: To: 'WashamFan' Message-id: <00d701cab9b5$e75d48f0$090d6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acq5tIWXwwOg0DRWQMm3fB9Oh5B/9wAAGBgA Cc: softwires@ietf.org, 'DHC WG' Subject: Re: [Softwires] FW: New Version Notification for draft-guo-softwire-6rd-ipv6-config-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 03:10:42 -0000 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: WashamFan [mailto:Washam.Fan@huaweisymantec.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2010=C4=EA3=D4=C22=C8=D5 11:00 > =CA=D5=BC=FE=C8=CB: Xu Xiaohu > =B3=AD=CB=CD: 'Dayong Guo'; softwires@ietf.org; 'DHC WG' > =D6=F7=CC=E2: Re: [Softwires] FW: New Version Notification for > draft-guo-softwire-6rd-ipv6-config-00 >=20 > Hi, >=20 > > > > Since the SP network is IPv4-only, IMO, DHCPv6 server and > > > > DNSv6 server would be deployed in 6rd CE LAN side. In that > > > > case, DHCPv4 options defined in this draft would be not > > > > justified. > > > > > > If a given DHCPv6 server is deployed in a customer site, its IPv6 address > > should > > > be a 6rd IPv6 address. In this case, the DHCP relay agent will > > relay the > > > information-request message to the 6rd CPE of that site, rather > > than to > > the > > > 6rd border relay. > > > > The "customer" site mentioned above is a 6rd site which is actually deployed > > by the SP and is used for holding IPv6 servers (e.g., DHCPv6 = servers, > > NTP > > servers and DNS servers etc). > > > > For the small-sized sites, do you believe they should deploy their = own > > DHCPv6 servers? >=20 > My concern is, if DHCPv6 is deployed within 6rd CE LANs, extensions > to DHCPv4 defined in the draft would not apply. If DHCPv6 server > deployed in 6rd CE WAN, that is where your draft fits in, I guess. >=20 > But how come DHCPv6 server is deployed in 6rd CE WAN which > is IPv4-only SP network? The IPv6 servers (e.g., DHCPv6 servers) could be deployed in a 6rd = =A1=B1 customer=A1=B1 site which is actually owned by the SP. Xiaohu From remi.despres@free.fr Mon Mar 1 23:55:20 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E89F3A871B for ; Mon, 1 Mar 2010 23:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-Iz25AWJf6h for ; Mon, 1 Mar 2010 23:55:20 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 6077228C140 for ; Mon, 1 Mar 2010 23:55:01 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 16686E080A1; Tue, 2 Mar 2010 08:54:57 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 40E72E080B8; Tue, 2 Mar 2010 08:54:54 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 2 Mar 2010 08:54:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <700287C3-4EAA-4027-8CCC-17201B628CDB@free.fr> References: <20100223203618.G A13301@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <126700 5876.2679.231.camel@lnxos-dev><4B86D8F3.9000108@gmail.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 07:55:20 -0000 Le 2 mars 2010 =E0 02:09, Templin, Fred L a =E9crit : > Remi, >=20 >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf Of R=E9mi Despr=E9s >> Sent: Thursday, February 25, 2010 11:04 PM >> To: Ole Troan >> Cc: softwires@ietf.org; Templin, Fred L >> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >>=20 >> Hi Fred, >>=20 >> Although the SEAL approach has IMHO some merit of its own for some = generalized tunneling scenarios, >> using it in 6rd would defeat the objective of simplicity for "rapid = deployment" of IPv6. >=20 > There is an opportunity at hand to get tunneling done right > the first time and then have a long-term quality IPv6 service. > 6rd is a large piece to the puzzle, but there are other pieces > that would make for a more complete solution. IMHO, we can > have it both ways of doing it fast *and* doing it right on > the first iteration. Different view here. As far as 6rd is concerned, doing it right is IMO keeping it as is. Regards, RD= From brian.e.carpenter@gmail.com Tue Mar 2 01:00:10 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FEDB28C11B for ; Tue, 2 Mar 2010 01:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbpomT-kGH0h for ; Tue, 2 Mar 2010 01:00:09 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 0B61F3A8913 for ; Tue, 2 Mar 2010 00:59:50 -0800 (PST) Received: by gwb10 with SMTP id 10so5575gwb.31 for ; Tue, 02 Mar 2010 00:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Sexo35NiNRH9/pQhQuN9G4e8Lw1P6ANauUEdaX3FmP0=; b=BkPJNb6/2jPgzEJiZ1PWq48+MzUgoq2XFVKpck/HpXqgf91m8S+cxdpW8GRqPhDVWw 6MCfnPLuidCFo9jH7rp7yKjo6yAZuyBADYGge5RJGtIAc6GmPFaHkIPsqhVrLb2NhNcS OY5N+PZT2lIrVdDm27VEIrGx8kdrvOw6NVMlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=M1s6LyT8sZK2/IHNJS9+eCRRTA7d3Il1iwGMvDYADYP3Lgbh9Ld9ebybqvZxP0PLbY c7SSJlir+jynOI2AIdMFEFVVb/oFTB+QSzpTGYfdBTgmIHFt9UyF1Ww2TInep2KDX7nq 0zEnDiNXdwUleb6ZbDZaaz/+GwcJPXm+65ni4= Received: by 10.100.245.29 with SMTP id s29mr135927anh.146.1267520387661; Tue, 02 Mar 2010 00:59:47 -0800 (PST) Received: from ?169.223.34.224? ([169.223.34.224]) by mx.google.com with ESMTPS id 4sm1562859ywd.13.2010.03.02.00.59.44 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Mar 2010 00:59:46 -0800 (PST) Message-ID: <4B8CD37A.5090203@gmail.com> Date: Tue, 02 Mar 2010 21:59:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <20100223203618.G A13301@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <126700 5876.2679.231.camel@lnxos-dev><4B86D8F3.9000108@gmail.com> <700287C3-4EAA-4027-8CCC-17201B628CDB@free.fr> In-Reply-To: <700287C3-4EAA-4027-8CCC-17201B628CDB@free.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" , "Templin, Fred L" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 09:00:10 -0000 > As far as 6rd is concerned, doing it right is IMO keeping it as is. Yes, given that we have just been told at APRICOT that the vast majority of Google and YouTube's IPv6 traffic comes from one particular ISP in France. It's a real success story, with a clamped MTU. Brian From remi.despres@free.fr Tue Mar 2 01:11:19 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227FE3A8AFB for ; Tue, 2 Mar 2010 01:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMRJD5fAvOin for ; Tue, 2 Mar 2010 01:11:18 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id E1CB83A8A7A for ; Tue, 2 Mar 2010 01:11:16 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id CB73FE0815A for ; Tue, 2 Mar 2010 10:11:14 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id E3A29E081D8 for ; Tue, 2 Mar 2010 10:11:11 +0100 (CET) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Mar 2010 10:11:11 +0100 Message-Id: To: softwires@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Softwires] New draft on SAM X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 09:11:19 -0000 Hi all, A new draft on SAM is now available at = tools.ietf.org/id/draft-despres-softwire-sam-00. Title: Stateless Address Mapping (SAM) for Softwire-Lite Solutions Abstract: Stateless Address Mapping (SAM) is a generic mechanism which permits, in = a number of new scenarios, to easily establish tunnels for packets of = some address family to traverse domains where this family is not = directly routed (softwires). It generalizes address mapping principles = of already deployed technologies such as 6to4, ISATAP, and 6rd, where = encapsulations of IP over IP are used for point-to-multipoint tunnels = (mesh softwires). Identified use cases of SAM include native IPv6 across IPv4 NATs, IPv6 = multihoming with provider-aggregatable prefixes, public IPv4 across = IPv6-only domains and, to mitigate consequences of the IPv4 address = shortage, extended IPv4 prefixes for statically shared IPv4 public = addresses.=20 Comments most welcome. Regards, RD= From gnakibly@yahoo.com Tue Mar 2 06:37:14 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045B53A8A93 for ; Tue, 2 Mar 2010 06:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t64uyUD3E3K3 for ; Tue, 2 Mar 2010 06:37:12 -0800 (PST) Received: from n67.bullet.mail.sp1.yahoo.com (n67.bullet.mail.sp1.yahoo.com [98.136.44.47]) by core3.amsl.com (Postfix) with SMTP id 8DD7C3A8A90 for ; Tue, 2 Mar 2010 06:37:12 -0800 (PST) Received: from [69.147.84.144] by n67.bullet.mail.sp1.yahoo.com with NNFMP; 02 Mar 2010 14:37:13 -0000 Received: from [98.136.44.161] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 02 Mar 2010 14:37:13 -0000 Received: from [127.0.0.1] by omp602.mail.sp1.yahoo.com with NNFMP; 02 Mar 2010 14:37:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 883888.66779.bm@omp602.mail.sp1.yahoo.com Received: (qmail 10240 invoked by uid 60001); 2 Mar 2010 14:37:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1267540633; bh=hp++7M391TdOTRI3XAM2BzGQ2qsANeYMYDYdpIM6+FM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=e2pX98jI7DmH4Z30d/EomEdwkXYrykyS4pWtMOvq26i2F3PtO7EnxIpCfoemjzdhHIwcxQwisqgAbGz5R91jqaLjR4bTyOIcrW1aOrk1AzQExrB9bgxQlDgx/sPEh1PnfYmUIMqClfj/BKDe82sqKlnIzikxzUjB42Oy0xZclKE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=u4qxl6RNcRu4p5FFb8zYSJiGpoJaHt1itiA88H6nJmd++Sk5L5OUkC74FSYD5TAKYIWnVgcLYM3CyKbdLd23U75pnoCpKdIgK1ibxobwAeWiDJANJSmAo0JVhHL+ZI6hGmrb+KI7TFVUbRKj4pZKc1TJ7///vDXC4RrcCcvkBwQ=; Message-ID: <779468.9747.qm@web45504.mail.sp1.yahoo.com> X-YMail-OSG: 1KQVO5AVM1nLuXcQ5061WSdI9P_n2BLL1AkzCeNM_DH05A4mntCeL3M0NlXosdy6I4rRnP8AzYgvHttY2MIPXr_GrkhjSI3vWqrzQoCs9XlbGxpSsYJptt6X9ldn.gZp77T0bEcI1SUcLYNGbXG_R0n8kMQG2es3c3E2MKfn3w1rY4d1jev.NfEboFRu4zpT4OB4hPAEKYiiM1GxbJ7qm0RleUJQ5Ygc_0FsDrvt7Krvcjp8OtGruX2nDFnfodBO88SLnhmnVSJ1WTKMDPj9xHLochK.glwFuFs- Received: from [93.173.241.253] by web45504.mail.sp1.yahoo.com via HTTP; Tue, 02 Mar 2010 06:37:13 PST X-Mailer: YahooMailRC/300.3 YahooMailWebService/0.8.100.260964 References: <428863.89468.qm@web45507.mail.sp1.yahoo.com> <4B8B7EFB.20006@cisco.com> Date: Tue, 2 Mar 2010 06:37:13 -0800 (PST) From: Gabi Nakibly To: Mark Townsley , softwires@ietf.org In-Reply-To: <4B8B7EFB.20006@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 14:37:14 -0000 Mark,=0A=0A>As presented in Hiroshima, I don't think an attack between a su= bscriber's own equipment and the BR is a top concern. The amount of traffic= a single =0A>subscriber can generate with a loop is no more than the subsc= riber could generate by downloading and uploading a lot of v6 content at th= e same time from =0A>outside the 6rd domain. Further, with a tunnel loop, t= he download path would be rate-limited by the upload path, which is general= ly quite asymmetric (e.g., =0A>today a bit-torrent user within a decent swa= rm off-net could generate more traffic on the BR than a loop). Point is, th= ere a are a lot of ways a user can fill =0A>his own pipe, and a loop betwee= n relays is probably way down low on the list of interesting things to do.= =0A=0AI=A0definitely see your point=A0here: due to=A0the clients' limited u= pload bandwidth=A0a routing loop via internal relay may cause only small da= mage to the BR. If this is the case, why should the draft=A0address the int= ernal loop case at all?=A0Guiding the SP to track all its internal relays m= ay incur too much administrative overhead for such a small threat. On the o= ther hand,=A0one should note that the internal=A0routing loop=A0will probab= ly=A0clog up=A0 the upstream of the client and completely DoS it. So this= =A0may be a=A0big threat for the client itself.=0A=0A>My concern here is th= at checking all possible local IPv4 addresses at a particular location in t= he IPv6 address for every packet switched through the BR =0A>would result i= n very significant overhead for a hardware-optimized implementation operati= ng at high speed. I have no objection to someone doing this kind =0A>of che= ck in their implementation, but their customers had better be willing to pa= y for it ;-)=0A=0AIf you still decide to address the internal loop case,=A0= it=A0should be noted that actually only one address=A0must be checked for e= ach packet:=0A- Source address check: the loop will succeed only if the IPv= 4 source address corresponds to the IPv6 source address, so before forwardi= ng a packet into=A0the tunnel interface the BR must make sure that the IPv6= source address does not correspond to the IPv4=A0address that is intended = to be=A0the packet's IPv4 source address, only. The other IPv4 addresses of= the BR are irrelevant here.=0A- Destination address check: as I gather fro= m Section 7.1.1 in the draft,=A0currently only a single 6rdBRIPv4Address=A0= is supported=A0by a=A0CE for each BR. If this means that a BR advertises in= the SP's IGP only one IPv4 address, then=A0the BR=A0is reachable to the cl= ients=A0only via this single address. Only this address should be verified = in the destination address check. The loop will not work with any other IPv= 4 addresses, even if they belong to the BR.=0A=0A>Should we refer to your I= nternet Draft instead?=0A=0AI think you should refer to this draft only if = you intend to reference one of the mitigation measures we propose there. If= you only refer the attacks themselves the current reference is better. =0A= In any case, I think that our draft=A0will be revised to refer to the 6rd c= ase, as well. =0A=0AGabi=0A________________________________=0AFrom: Mark To= wnsley =0ATo: softwires@ietf.org=0ASent: Mon, March 1, = 2010 10:46:51 AM=0ASubject: Re: [Softwires] SOFTWIRE working group last cal= l on 6rd=0A=0AOn 3/1/10 8:44 AM, Gabi Nakibly wrote:=0A> Hi all,=0A> I woul= d like to comment on the loop avoidance issue addressed in the Security Con= siderations section.=0A> First, I agree that the the best mitigation measur= e here for loops via external relays is to simply drop at the border of the= 6rd domain packets sent from or destined to a 6rd BR.=0A> Second, regardin= g loops via internal relays the draft mentions that:=0A>=A0 =A0 To avoid fo= rwarding loops via other internal relays, the BR should=0A>=A0 =A0 employ o= utgoing and incoming IPv4 packets filters, filtering out all=0A>=A0 =A0 kno= wn relay addresses for internal 6rd BRs, ISATAP routers or 6to4=0A>=A0 =A0 = relays, including the well known anycast address space for 6to4.=0A> Does t= he SP necessarily knows of every ISATAP router or 6to4 relay deployed in th= e 6rd domain?=0ADeployed by the SP.=0A> After all, a customer can deploy an= ISATAP router or even a 6to4 relay for that matter without the knowledge o= f the SP, while using a configured tunnel (by a tunnel broker) for its IPv6= connectivity.=0AAs presented in Hiroshima, I don't think an attack between= a subscriber's own equipment and the BR is a top concern. The amount of tr= affic a single subscriber can generate with a loop is no more than the subs= criber could generate by downloading and uploading a lot of v6 content at t= he same time from outside the 6rd domain. Further, with a tunnel loop, the = download path would be rate-limited by the upload path, which is generally = quite asymmetric (e.g., today a bit-torrent user within a decent swarm off-= net could generate more traffic on the BR than a loop). Point is, there a a= re a lot of ways a user can fill his own pipe, and a loop between relays is= probably way down low on the list of interesting things to do.=0A=0A=0A=0A= =0A> I suggest to keep the filtering of internal 6rd BRs. But to avoid loop= s via internal ISATAP routers or 6to4 relays, I would suggest employing the= destination/source address check described in Section 3.1 in http://tools.= ietf.org/html/draft-nakibly-v6ops-tunnel-loops-01 we have recently submitte= d. It is not a perfect solution, and indeed it should be updated in case ot= her types of automatic tunnels come up, but it does the job for ISATAP and = 6to4 loops without demanding a knowledge of every internal ISATAP router or= 6to4 relay.=0AIf you are referring to this kind of check:=0A=0A=A0 For exa= mple, if tunnel router A (ISATAP router or 6to4 relay)=0A=A0 forwards a pac= ket into a tunnel interface with an IPv6 source address=0A=A0 that matches = the 6to4 prefix 2002:IPa::/48, the router discards the=0A=A0 packet if IPa = is one of its own IPv4 addresses.=A0 In a second example,=0A=A0 if tunnel r= outer B (ISATAP router or 6to4 relay) receives an IPv6=0A=A0 packet on a tu= nnel interface with an IPv6 destination address that=0A=A0 matches the ISAT= AP address suffix ::0200:5EFE:IPb, the router=0A=A0 discards the packet if = IPb is one of its own IPv4 addresses.=0A=0AMy concern here is that checking= all possible local IPv4 addresses at a particular location in the IPv6 add= ress for every packet switched through the BR would result in very signific= ant overhead for a hardware-optimized implementation operating at high spee= d. I have no objection to someone doing this kind of check in their impleme= ntation, but their customers had better be willing to pay for it ;-)=0A=0AC= urrently, we have this paper referenced:=0A=0A=A0 [RoutingLoop]=0A=A0 =A0 = =A0 =A0 =A0 =A0 =A0 Nakibly and Arov, "Routing Loop Attacks using IPv6=0A= =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tunnels", August 2009,.=0A= =0AShould we refer to your Internet Draft instead?=0A=0A> Other than this I= fully support this draft for advancement.=0AThanks,=0A=0A- Mark=0A=0A> Gab= i=0A> =0A> =0A> -----------------------------------------------------------= -------------=0A> *From:* "Durand, Alain" = =0A> *To:* softwires ; DHC WG =0A> *Cc:= * Ole Troan =0A> *Sent:* Mon, February 22, 2010 11:43:00 PM= =0A> *Subject:* [Softwires] SOFTWIRE working group last call on 6rd=0A> =0A= > All -=0A> =0A> We'd like to announce the softwire WG LC on the 6rd techno= logy. I've copied both SOFTWIRE and DHC mailing lists and solicit comments = from both groups of experts. The draft is here:=0A> =0A> _http://www.ietf.o= rg/internet-drafts/draft-ietf-softwire-ipv6-6rd-07.txt=0A> _=0A> Please rep= ly with comments to this thread by 2010.03.08 at 1700 PST=0A> =0A> Thanks= =0A> =0A> - Alain=0A> _______________________________________________=0A> S= oftwires mailing list=0A> _Softwires@ietf.org=0A> https://www.ietf.org/mail= man/listinfo/softwires_=0A> =0A> =0A> _____________________________________= __________=0A> Softwires mailing list=0A> Softwires@ietf.org=0A> https://ww= w.ietf.org/mailman/listinfo/softwires=0A>=A0 =A0 =0A=0A____________________= ___________________________=0ASoftwires mailing list=0ASoftwires@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/softwires=0A=0A=0A=0A From Fred.L.Templin@boeing.com Tue Mar 2 08:51:58 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5098428C1CD for ; Tue, 2 Mar 2010 08:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mytm-bHhZQCt for ; Tue, 2 Mar 2010 08:51:57 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 0CB2628C0D8 for ; Tue, 2 Mar 2010 08:51:56 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o22Gptap020802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 Mar 2010 10:51:55 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o22Gps92005264; Tue, 2 Mar 2010 08:51:54 -0800 (PST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o22Gpso4005255 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 2 Mar 2010 08:51:54 -0800 (PST) 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; Tue, 2 Mar 2010 08:51:54 -0800 From: "Templin, Fred L" To: Brian E Carpenter , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Tue, 2 Mar 2010 08:51:52 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: Acq55vEVk6BJuURVRSG4TxfLvj++cQAOisyg Message-ID: References: <20100223203618.G A13301@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <12670 0 5876.2679.231.camel@lnxos-dev><4B86D8F3.9000108@gmail.com> <700287C3-4EAA-4027-8CCC-17201B628CDB@free.fr> <4B8CD37A.5090203@gmail.com> In-Reply-To: <4B8CD37A.5090203@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 16:51:58 -0000 Brian, > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Brian E Carpenter > Sent: Tuesday, March 02, 2010 1:00 AM > To: R=E9mi Despr=E9s > Cc: softwires@ietf.org; Templin, Fred L > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > > As far as 6rd is concerned, doing it right is IMO keeping it as is. >=20 > Yes, given that we have just been told at APRICOT that the vast majority > of Google and YouTube's IPv6 traffic comes from one particular ISP in > France. It's a real success story, with a clamped MTU. You are right that the MTU clamping seems to be the approach being advocated under 6rd, but I disagree that that is the best we can (or should) do. During the NGTRANS days, the ISATAP team was strongly required to include a "Domain of Applicability" statement, and I think the same should be required of 6rd. I see a number of aspects of 6rd that IMHO would limit its applicability, including: - IPv6 prefix tied to IPv4 address (renumbering implications) - potential black holes when ICMPs can't be translated - provider-aggregated addressing only (no provider-independent) - not compatible with multihoming via a single, stable IPv6 prefix - not compatible with traffic engineering (i.e., CE can't select specific BRs) - interactions with load balancing; ECMP within provider network - MTU clamping exposes degenerate MTUs to the customer network and doesn't allow for automatic discovery of larger MTUs - requires operators to exercise tight controls on link MTUs - requires operators to exercise tight controls on ICMP generation and ICMP filtering So, while I see the 6rd stateless prefix delegation as a highly desirable contribution, I think the implications of these limitations should somehow be captured in an applicability statement the same as was required for the NGTRANS mechanisms. Thanks - Fred fred.l.templin@boeing.com =20 > Brian > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From brian.e.carpenter@gmail.com Tue Mar 2 16:23:35 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E709728C1B2 for ; Tue, 2 Mar 2010 16:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txPk16uMPzDR for ; Tue, 2 Mar 2010 16:23:35 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id A9C6F28C130 for ; Tue, 2 Mar 2010 16:23:34 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id d26so187608eyd.51 for ; Tue, 02 Mar 2010 16:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=N+H7XG0BqOWpVeQlRbYvBsmC6Ke1s3f45cSfTtspJ2E=; b=Sas0bCouQAOrLl8CnOmtt33xXDTl+KStAsdSG0xt1MxzyaX47/DaipoF1uoGpzlA1j 7DfS6aGFeOT30fCFfs/KY9aQrPKwRMTW5rKRxYoiOZA6MGzTVeQeV6li2Z1xW/okmVnW oWQVgbq2gtCB11TNPX9BY0CkJKY1GDQKx2Gs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=phFn6inGkZ0NIZzLY38ODr00cttXVTZ9uIAo20gCikDsOAjgPCoRyv3D/tt2HEz9xh liUR4AK9wncFDXpFNtyUadgWkdSNlXnwfmIALirULIAU8U6uwgke2D/HOM8/DURdzkdT S7FXyngo6GWP25GagoNUslcdvI69atMnlF40s= Received: by 10.213.65.138 with SMTP id j10mr1613676ebi.23.1267575800967; Tue, 02 Mar 2010 16:23:20 -0800 (PST) Received: from ?10.71.0.54? ([202.133.104.182]) by mx.google.com with ESMTPS id 15sm3396859ewy.4.2010.03.02.16.23.16 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Mar 2010 16:23:19 -0800 (PST) Message-ID: <4B8DABEE.3030407@gmail.com> Date: Wed, 03 Mar 2010 13:23:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" References: <20100223203618.G A13301@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <12670 0 5876.2679.231.camel@lnxos-dev><4B86D8F3.9000108@gmail.com> <700287C3-4EAA-4027-8CCC-17201B628CDB@free.fr> <4B8CD37A.5090203@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 00:23:36 -0000 Fred, I agree that distinguishing between pragmatic operational practices (such as clamping the MTU) and generic solutions is correct, but as far as the current last call goes, I think that leaving the generic solution FFS is also correct. I don't think the text in section 9.1 really needs changing. It doesn't exclude future mechanisms, it simply recommends what to do if there is no MTU discovery or management in place. Regards Brian On 2010-03-03 05:51, Templin, Fred L wrote: > Brian, >=20 >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] O= n Behalf Of Brian E Carpenter >> Sent: Tuesday, March 02, 2010 1:00 AM >> To: R=C3=A9mi Despr=C3=A9s >> Cc: softwires@ietf.org; Templin, Fred L >> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >> >>> As far as 6rd is concerned, doing it right is IMO keeping it as is. >> Yes, given that we have just been told at APRICOT that the vast majori= ty >> of Google and YouTube's IPv6 traffic comes from one particular ISP in >> France. It's a real success story, with a clamped MTU. >=20 > You are right that the MTU clamping seems to be the approach > being advocated under 6rd, but I disagree that that is the > best we can (or should) do. >=20 > During the NGTRANS days, the ISATAP team was strongly required > to include a "Domain of Applicability" statement, and I think > the same should be required of 6rd. I see a number of aspects > of 6rd that IMHO would limit its applicability, including: >=20 > - IPv6 prefix tied to IPv4 address (renumbering implications) > - potential black holes when ICMPs can't be translated > - provider-aggregated addressing only (no provider-independent) > - not compatible with multihoming via a single, stable IPv6 prefix > - not compatible with traffic engineering (i.e., CE can't select > specific BRs) > - interactions with load balancing; ECMP within provider network > - MTU clamping exposes degenerate MTUs to the customer network > and doesn't allow for automatic discovery of larger MTUs > - requires operators to exercise tight controls on link MTUs > - requires operators to exercise tight controls on ICMP > generation and ICMP filtering >=20 > So, while I see the 6rd stateless prefix delegation as a > highly desirable contribution, I think the implications > of these limitations should somehow be captured in an > applicability statement the same as was required for the > NGTRANS mechanisms. >=20 > Thanks - Fred > fred.l.templin@boeing.com > =20 >> Brian >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 From root@core3.amsl.com Tue Mar 2 18:00:02 2010 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4723B28C287; Tue, 2 Mar 2010 18:00:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100303020002.4723B28C287@core3.amsl.com> Date: Tue, 2 Mar 2010 18:00:02 -0800 (PST) Cc: softwires@ietf.org Subject: [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 02:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Options for Dual- Stack Lite Author(s) : D. Hankins, T. Mrugalski Filename : draft-ietf-softwire-ds-lite-tunnel-option-02.txt Pages : 8 Date : 2010-03-02 This document specifies two DHCPv6 options which are meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand element, B4) to discover its Address Family Transition Router (AFTR) address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-softwire-ds-lite-tunnel-option-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-02175332.I-D@ietf.org> --NextPart-- From David_Hankins@isc.org Tue Mar 2 18:07:08 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BDB228C0DB for ; Tue, 2 Mar 2010 18:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCsbuxGIQ3Go for ; Tue, 2 Mar 2010 18:07:07 -0800 (PST) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id 5750328C1DB for ; Tue, 2 Mar 2010 18:07:07 -0800 (PST) Received: from david.isc.org (c-67-188-70-48.hsd1.ca.comcast.net [67.188.70.48] (may be forged)) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id o23273Yf014298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Mar 2010 18:07:03 -0800 Received: by david.isc.org (Postfix, from userid 10200) id 2768C16CDB6; Tue, 2 Mar 2010 18:07:08 -0800 (PST) Date: Tue, 2 Mar 2010 18:07:08 -0800 From: "David W. Hankins" To: softwires@ietf.org Message-ID: <20100303020707.GB5782@isc.org> References: <20100303015332.868833A855B@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20100303015332.868833A855B@core3.amsl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Softwires] New Version Notification for draft-ietf-softwire-ds-lite-tunnel-option-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 02:07:08 -0000 On Tue, Mar 02, 2010 at 05:53:32PM -0800, IETF I-D Submission Tool wrote: > Filename: draft-ietf-softwire-ds-lite-tunnel-option > Revision: 02 =46rom -01 there are a few minor grammar and spelling nits, the ASCII art is slightly reformed to be more visually in line with RFC 3315 convention, and I've omitted a useless "hierarchy" section that had all of one sentence in it other than its subsections. So, just editorial stuff from what Tomasz already did in -01. Outside of that, I did want to address one more thing from Paul; On Mon, Feb 08, 2010 at 10:44:08PM +0000, Paul Selkirk wrote: > This could be interpreted as a recommendation to use the FQDN option > instead of the Address option. Perhaps something like: > For the sake of simplicity, this option conveys a single IPv6 > address. If you want to convey multiple IPv6 addresses, you should > instead use the Dual-Stack Lite Name option, where the DNS name > could resolve to multiple addresses. I've updated this bit a little differently; This option conveys a single IPv6 address, as the Dual-Stack Lite specification [I-D.softwire-ds-lite-03] defines only one Softwire connection between a B4 and any AFTR. Multiple connections or endpoints are undefined. For more information, see Section 7.2 "High Availability" of [I-D.softwire-ds-lite-03].=20 I hope this is reasonable. Mainly I'm trying to avoid a language that seems permissible of multiple addresses in either form. This particular paragraph has had a rough time adjusting from initial discussion formats to the present day. :) Quick link to the draft; https://datatracker.ietf.org/doc/draft-ietf-softwire-ds-lite-tunnel-option/ --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins From Fred.L.Templin@boeing.com Wed Mar 3 09:57:00 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8175D28C238 for ; Wed, 3 Mar 2010 09:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arMSg6KB11Hb for ; Wed, 3 Mar 2010 09:56:59 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id EB14C3A8AA0 for ; Wed, 3 Mar 2010 09:56:58 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o23HuvJd013265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Mar 2010 09:56:57 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o23Huu4C023769; Wed, 3 Mar 2010 09:56:56 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o23Huutw023761 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 3 Mar 2010 09:56:56 -0800 (PST) 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; Wed, 3 Mar 2010 09:56:56 -0800 From: "Templin, Fred L" To: Brian E Carpenter Date: Wed, 3 Mar 2010 09:56:55 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: Acq6Z8J/070FYQbwSWiB9eNj+5It0AAiTPOw Message-ID: References: <20100223203618.G A13301@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <1267 0 0 5876.2679.231.camel@lnxos-dev><4B86D8F3.9000108@gmail.com> <700287C3-4EAA-4027-8CCC-17201B628CDB@free.fr> <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> In-Reply-To: <4B8DABEE.3030407@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 17:57:00 -0000 Hi Brian, > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Tuesday, March 02, 2010 4:23 PM > To: Templin, Fred L > Cc: R=E9mi Despr=E9s; softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > Fred, >=20 > I agree that distinguishing between pragmatic operational practices > (such as clamping the MTU) and generic solutions is correct, but > as far as the current last call goes, I think that leaving the generic > solution FFS is also correct. Still, I think an applicability statement with disclosure of some of the limitations I cited would be appropriate. It's not that I think that aspects of 6rd would not fit into a generic solution (I do!) - it is rather that the current manifestation of 6rd is not in itself a generic solution. =20 > I don't think the text in section 9.1 really needs changing. It > doesn't exclude future mechanisms, it simply recommends what to do > if there is no MTU discovery or management in place. Focusing solely on the section 9.1 text for now: + MTU and fragmentation issues for IPv6 in IPv4 tunneling are discussed + in detail in section 3.2 of RFC4213 [RFC4213]. 6rd's scope is limited + to a service provider network. IPv4 Path MTU discovery MAY be used + to adjust the MTU of the tunnel as described in section 3.2.2 of + RFC4213 [RFC4213] or the 6rd Tunnel MTU may be explicitly configured. RFC4213 cites limitations of the IPv4 Path MTU discovery method, which I assume is why the explicit configuration option is listed and examined more closely in the following: =20 + If the MTU is well-managed such that the IPv4 MTU on the CE WAN side + interface is set so that no fragmentation occurs within the boundary + of the SP, then the 6rd Tunnel MTU should be set to the known IPv4 + MTU minus the size of the encapsulating IPv4 header (20 bytes). For + example, if the IPv4 MTU is known to be 1500 bytes, the 6rd Tunnel + MTU may be set to 1480 bytes. =20 But with SEAL, there is no need for a clamped MTU limit and the tunnel MTU can be set to infinity. + Absent of more specific information + the 6rd Tunnel MTU SHOULD default to 1280 bytes. Setting SEAL aside and considering only the existing Section 9.1 text, no discussion of v6/v4 tunnel MTU is complete without also examining the setting of the DF bit in the IPv4 header. In particular, when the 6rd BR uses an anycast address as the IPv4 source address, it truly cannot allow fragmentation on the outer packet since that could easily result in fragment misassociation within a CE's reassembly buffer. For example, if BRs A and B both use the same IPv4 source address X and destination address Y, then happen to also choose the same IP_ID, any fragments from A would be indistinguishable from B's fragments, and CE Y could be left with a dangerous reassembly misassociation that evades upper layer integrity checks. So, the document should say that BRs that use an anycast source address MUST set DF=3D1. Yes, this means that BR use of an anycast source address would be incompatible with IPv4 networks that mis-manage their MTUs and/or include links with MTUs smaller than 1280. This is not a show-stopper at all, but simply another bullet for inclusion in an applicability statement. =20 + A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined + automatically or configured directly, on the LAN side by setting the + MTU option in Router Advertisements [RFC4861] messages to the 6rd + Tunnel MTU. Here, hosts connected to the LAN that receive the RA MTU option will be stuck with a degenerate MTU (1480) even for communications that do not leave the LAN. This means that even if the LAN supports a 9KB MTU any hosts that receive the MTU option will only ever be able to talk to each other using 1480. The other issue is that the customer's network may have an arbitrarily-complex topology of additional links and routers. So, unless the 1480 is somehow propagated deeply into the customer network, hosts connected to those links will not observe the MTU clamping and continue to use 1500+ packets. Fred fred.l.templin@boeing.com =20 > Regards > Brian >=20 > On 2010-03-03 05:51, Templin, Fred L wrote: > > Brian, > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] O= n Behalf Of Brian E > Carpenter > >> Sent: Tuesday, March 02, 2010 1:00 AM > >> To: R=E9mi Despr=E9s > >> Cc: softwires@ietf.org; Templin, Fred L > >> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > >> > >>> As far as 6rd is concerned, doing it right is IMO keeping it as is. > >> Yes, given that we have just been told at APRICOT that the vast majori= ty > >> of Google and YouTube's IPv6 traffic comes from one particular ISP in > >> France. It's a real success story, with a clamped MTU. > > > > You are right that the MTU clamping seems to be the approach > > being advocated under 6rd, but I disagree that that is the > > best we can (or should) do. > > > > During the NGTRANS days, the ISATAP team was strongly required > > to include a "Domain of Applicability" statement, and I think > > the same should be required of 6rd. I see a number of aspects > > of 6rd that IMHO would limit its applicability, including: > > > > - IPv6 prefix tied to IPv4 address (renumbering implications) > > - potential black holes when ICMPs can't be translated > > - provider-aggregated addressing only (no provider-independent) > > - not compatible with multihoming via a single, stable IPv6 prefix > > - not compatible with traffic engineering (i.e., CE can't select > > specific BRs) > > - interactions with load balancing; ECMP within provider network > > - MTU clamping exposes degenerate MTUs to the customer network > > and doesn't allow for automatic discovery of larger MTUs > > - requires operators to exercise tight controls on link MTUs > > - requires operators to exercise tight controls on ICMP > > generation and ICMP filtering > > > > So, while I see the 6rd stateless prefix delegation as a > > highly desirable contribution, I think the implications > > of these limitations should somehow be captured in an > > applicability statement the same as was required for the > > NGTRANS mechanisms. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> Brian > >> _______________________________________________ > >> Softwires mailing list > >> Softwires@ietf.org > >> https://www.ietf.org/mailman/listinfo/softwires > > From Washam.Fan@huaweisymantec.com Wed Mar 3 18:13:25 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BDE228C4E2 for ; Wed, 3 Mar 2010 18:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH8gC-x+0mCg for ; Wed, 3 Mar 2010 18:13:24 -0800 (PST) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 054D428C4C6 for ; Wed, 3 Mar 2010 18:13:24 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KYQ00HHLJI06O20@hstga01-in.huaweisymantec.com> for softwires@ietf.org; Thu, 04 Mar 2010 10:13:13 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KYQ00GWKJI04010@hstml02-in.huaweisymantec.com> for softwires@ietf.org; Thu, 04 Mar 2010 10:13:12 +0800 (CST) Received: from [10.27.153.131] by hstml02-in.huaweisymantec.com (mshttpd); Thu, 04 Mar 2010 10:13:12 +0800 From: WashamFan To: "Templin, Fred L" Message-id: Date: Thu, 04 Mar 2010 10:13:12 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: References: <"20100223203618.G A13301"@isc.org> <13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com> <"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com> <"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org> <700287C3-4EAA-4027-8CCC-17201B628CDB@free.fr> <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 02:13:25 -0000 Hi, > Setting SEAL aside and considering only the existing > Section 9.1 text, no discussion of v6/v4 tunnel MTU is > complete without also examining the setting of the DF bit > in the IPv4 header. In particular, when the 6rd BR uses > an anycast address as the IPv4 source address, it truly > cannot allow fragmentation on the outer packet since that > could easily result in fragment misassociation within a > CE's reassembly buffer. > > For example, if BRs A and B both use the same IPv4 source > address X and destination address Y, then happen to also > choose the same IP_ID, any fragments from A would be > indistinguishable from B's fragments, and CE Y could be > left with a dangerous reassembly misassociation that > evades upper layer integrity checks. So, the document > should say that BRs that use an anycast source address > MUST set DF=1. Or we fix this problem by some measures. How about allocating different IP_ID range for each BR? Although it might entail modification on BRs. > Yes, this means that BR use of an anycast source address > would be incompatible with IPv4 networks that mis-manage > their MTUs and/or include links with MTUs smaller than 1280. > This is not a show-stopper at all, but simply another bullet > for inclusion in an applicability statement. > > + A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined > + automatically or configured directly, on the LAN side by setting > the > + MTU option in Router Advertisements [RFC4861] messages to the 6rd > + Tunnel MTU. > > Here, hosts connected to the LAN that receive the RA MTU > option will be stuck with a degenerate MTU (1480) even for > communications that do not leave the LAN. This means that > even if the LAN supports a 9KB MTU any hosts that receive > the MTU option will only ever be able to talk to each other > using 1480. The other issue is that the customer's network > may have an arbitrarily-complex topology of additional links > and routers. So, unless the 1480 is somehow propagated deeply > into the customer network, hosts connected to those links > will not observe the MTU clamping and continue to use > 1500+ packets. Why advertise WAN side MTU to LAN side? Doesn't routers advertise LAN MTU via RA? PMTU would work out the optimal MTU for end-to-end communication. washam From brian.e.carpenter@gmail.com Wed Mar 3 18:23:21 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B9228C4E7 for ; Wed, 3 Mar 2010 18:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-g5D+MW-ewg for ; Wed, 3 Mar 2010 18:23:19 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 2766128C4C2 for ; Wed, 3 Mar 2010 18:23:18 -0800 (PST) Received: by wwb18 with SMTP id 18so710972wwb.31 for ; Wed, 03 Mar 2010 18:23:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Hk2cgMXUYHBXZ6FZO4TxtOmVk0R954Md6034ORLum3k=; b=TrW3z+3YEakJB665PUxS7qxufyvmlre4DfEuceezPf5w2v1K0v5Gw5x4mezfoCibzu jq9b9hp5cRKXCa54HPMv7vDcPt6uiCzse8amvurwdYWBBXsito3OOvxOPqIM9/FyLdXP DRPK8rs3DJfPGWMdMbwQ67T+VpTwwhRcxd6bw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=PbvoDsclychL/8/HpOZjRe7htxcTQtdSO9GrT+1zdLF3CHN+BMkZb1BmEH/dWJW85E /s7luhABNUNyoPKFDuIR7QXcPvhVBHmkegFRd0tW59pQV1wfz5ywnZD6F7TuA65JEfvx Y3CJzHkoTMgRKjcQy9oe55MY4m/Yzzjv6nIcY= Received: by 10.216.89.202 with SMTP id c52mr1320818wef.84.1267669395786; Wed, 03 Mar 2010 18:23:15 -0800 (PST) Received: from [169.223.34.224] (224.34.dhcp.conference.apricot.net [169.223.34.224]) by mx.google.com with ESMTPS id g11sm251896gve.8.2010.03.03.18.23.08 (version=SSLv3 cipher=RC4-MD5); Wed, 03 Mar 2010 18:23:14 -0800 (PST) Message-ID: <4B8F1984.3040905@gmail.com> Date: Thu, 04 Mar 2010 15:23:00 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: WashamFan References: <"20100223203618.G A13301"@isc.org> <13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com> <"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com> <"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org> <700287C3-4EAA-4027-8CCC-17201B628CDB@free.fr> <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" , "Templin, Fred L" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 02:23:21 -0000 On 2010-03-04 15:13, WashamFan wrote: > Why advertise WAN side MTU to LAN side? Doesn't routers > advertise LAN MTU via RA? PMTU would work out the optimal > MTU for end-to-end communication. Because PMTUD is not reliable. Brian From remi.despres@free.fr Thu Mar 4 05:25:55 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A068C3A880F for ; Thu, 4 Mar 2010 05:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWWYHdVpm2aA for ; Thu, 4 Mar 2010 05:25:55 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id B2E6928C0CE for ; Thu, 4 Mar 2010 05:25:53 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id BE299E0819A; Thu, 4 Mar 2010 14:25:50 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0DD90E08058; Thu, 4 Mar 2010 14:25:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4B8F1984.3040905@gmail.com> Date: Thu, 4 Mar 2010 14:25:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <220E3820-C870-4AA9-AC75-9D6139CA37CA@free.fr> References: <"20100223203618.G A13301"@isc.org> <13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com> <"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com> <"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org> <700287C3-4EAA-4027-8CCC-17201B628CDB@free.fr> <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> <4B8F1984.3040905@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1077) Cc: "softwires@ietf.org" , "Templin, Fred L" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 13:25:55 -0000 Le 4 mars 2010 =E0 03:23, Brian E Carpenter a =E9crit : > On 2010-03-04 15:13, WashamFan wrote: >=20 >> Why advertise WAN side MTU to LAN side? Doesn't routers >> advertise LAN MTU via RA? PMTU would work out the optimal >> MTU for end-to-end communication. >=20 > Because PMTUD is not reliable. The dilemma seems to be: - either one relies on ICMPv6 packet-too-big error messages being = properly forwarded and processed, - or, for IPv6 to work, hosts have to be clamped to 1280. This is IMHO a good reason to insist, again and again, that ICMPv6 PTB = messages MUST be always forwarded in intermediated nodes, and always = processed in their destination hosts for PMTUD to become reliable. RD From Fred.L.Templin@boeing.com Thu Mar 4 08:39:07 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 641F13A8587 for ; Thu, 4 Mar 2010 08:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV0PVa8iIz7S for ; Thu, 4 Mar 2010 08:39:06 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 5B2D03A8CDE for ; Thu, 4 Mar 2010 08:39:06 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o24Gcwip005523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Mar 2010 10:38:59 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o24GcvLi020942; Thu, 4 Mar 2010 08:38:57 -0800 (PST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o24Gcv6l020938 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 4 Mar 2010 08:38:57 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Thu, 4 Mar 2010 08:38:57 -0800 From: "Templin, Fred L" To: WashamFan Date: Thu, 4 Mar 2010 08:38:55 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: Acq7QEGOQOcng9HlQtq8ppMooPqpOgAdLNjQ Message-ID: References: <"20100223203618. G A13301"@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.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: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:39:07 -0000 Hi Washam, > -----Original Message----- > From: WashamFan [mailto:Washam.Fan@huaweisymantec.com] > Sent: Wednesday, March 03, 2010 6:13 PM > To: Templin, Fred L > Cc: Brian E Carpenter; softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > Hi, >=20 > > Setting SEAL aside and considering only the existing > > Section 9.1 text, no discussion of v6/v4 tunnel MTU is > > complete without also examining the setting of the DF bit > > in the IPv4 header. In particular, when the 6rd BR uses > > an anycast address as the IPv4 source address, it truly > > cannot allow fragmentation on the outer packet since that > > could easily result in fragment misassociation within a > > CE's reassembly buffer. > > > > For example, if BRs A and B both use the same IPv4 source > > address X and destination address Y, then happen to also > > choose the same IP_ID, any fragments from A would be > > indistinguishable from B's fragments, and CE Y could be > > left with a dangerous reassembly misassociation that > > evades upper layer integrity checks. So, the document > > should say that BRs that use an anycast source address > > MUST set DF=3D1. >=20 > Or we fix this problem by some measures. How about allocating > different IP_ID range for each BR? Although it might entail > modification on BRs. Reducing the IP_ID range on each BR would increase the incidence of reassembly errors at high data rates [RFC4963]. So, I'm not sure new patch-type mechanisms like this would be all that helpful without taking the full step of going to something like SEAL. AFAICT, that just means that, under the current 6rd mechanisms, SP networks that want to have their BR's use an anycast source address had better ensure that the tunnels won't ever fragment. 6rd BRs that use anycast can help by setting DF=3D1.=20 > > Yes, this means that BR use of an anycast source address > > would be incompatible with IPv4 networks that mis-manage > > their MTUs and/or include links with MTUs smaller than 1280. > > This is not a show-stopper at all, but simply another bullet > > for inclusion in an applicability statement. > > > > + A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined > > + automatically or configured directly, on the LAN side by setting > > the > > + MTU option in Router Advertisements [RFC4861] messages to the 6rd > > + Tunnel MTU. > > > > Here, hosts connected to the LAN that receive the RA MTU > > option will be stuck with a degenerate MTU (1480) even for > > communications that do not leave the LAN. This means that > > even if the LAN supports a 9KB MTU any hosts that receive > > the MTU option will only ever be able to talk to each other > > using 1480. The other issue is that the customer's network > > may have an arbitrarily-complex topology of additional links > > and routers. So, unless the 1480 is somehow propagated deeply > > into the customer network, hosts connected to those links > > will not observe the MTU clamping and continue to use > > 1500+ packets. >=20 > Why advertise WAN side MTU to LAN side? Doesn't routers > advertise LAN MTU via RA? PMTU would work out the optimal > MTU for end-to-end communication. PMTUD within end sites *has* to work in order for there to be any measure of robustness. Customer end systems and middleboxes that filter ICMPs are only hurting themselves and need to change their ways. That said, I believe the reason for asking the CE to advertise 1480 internally to the customer site is to minimize the incidence of invoking PMTUD. Otherwise, customer end systems would be constantly sending 1500 packets initially which would be thrown away by the CE until PMTUD kicks in. As I mentioned however, the issue with advertising the 1480 is that it would cause an MTU reduction even for communications that never leave the end site. Customers with 9K links might not like that. Thanks - Fred fred.l.templin@boeing.com=20 =20 > washam From Fred.L.Templin@boeing.com Thu Mar 4 08:45:48 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F023A8D56 for ; Thu, 4 Mar 2010 08:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uclo7kIVxpv6 for ; Thu, 4 Mar 2010 08:45:48 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 0C2663A8B56 for ; Thu, 4 Mar 2010 08:45:48 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o24Gjh9B003018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Mar 2010 08:45:44 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o24GjhTN010737; Thu, 4 Mar 2010 10:45:43 -0600 (CST) 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 o24GjghH010712 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 4 Mar 2010 10:45:43 -0600 (CST) 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; Thu, 4 Mar 2010 08:45:42 -0800 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Brian E Carpenter Date: Thu, 4 Mar 2010 08:45:41 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: Acq7njuTHLA62AtZTZK7wtrpy+9o4gAGwOCA Message-ID: References: <"20100223203618.GA13301"@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@emp loyees.org> <"1267 0 05876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr><4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com><4B8F1984.3040905@gmail.com> <220E3820-C870-4AA9-AC75-9D6139CA37CA@free.fr> In-Reply-To: <220E3820-C870-4AA9-AC75-9D6139CA37CA@free.fr> 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 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:45:48 -0000 Remi, > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of R=E9mi Despr=E9s > Sent: Thursday, March 04, 2010 5:26 AM > To: Brian E Carpenter > Cc: softwires@ietf.org; Templin, Fred L > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 >=20 > Le 4 mars 2010 =E0 03:23, Brian E Carpenter a =E9crit : >=20 > > On 2010-03-04 15:13, WashamFan wrote: > > > >> Why advertise WAN side MTU to LAN side? Doesn't routers > >> advertise LAN MTU via RA? PMTU would work out the optimal > >> MTU for end-to-end communication. > > > > Because PMTUD is not reliable. >=20 > The dilemma seems to be: > - either one relies on ICMPv6 packet-too-big error messages being properl= y forwarded and processed, > - or, for IPv6 to work, hosts have to be clamped to 1280. >=20 > This is IMHO a good reason to insist, again and again, that ICMPv6 PTB me= ssages MUST be always > forwarded in intermediated nodes, and always processed in their destinati= on hosts for PMTUD to become > reliable. I agree that customer end systems and middleboxes within the customer network *must* be made capable of honoring PMTUD; otherwise, there is no hope. The difficulty lies in reliance on PMTUD for detecting MTU restrictions that occur *outside* of the site. That is where Brian is correct in pointing out that PMTUD is unreliable. That said, it would be very useful to reduce the incidence of invoking PMTUD within the end site if possible without the side effect of clamping MTUs that don't need to be clamped. That is an area in which SEAL can help. Thanks - Fred fred.l.templin@boeing.com > RD >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Fred.L.Templin@boeing.com Thu Mar 4 08:51:38 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF9E3A8D63 for ; Thu, 4 Mar 2010 08:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf8zNtekItkh for ; Thu, 4 Mar 2010 08:51:35 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 67D833A8A71 for ; Thu, 4 Mar 2010 08:51:35 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o24GpaTM013441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Mar 2010 10:51:36 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o24GpZ1I022337; Thu, 4 Mar 2010 10:51:35 -0600 (CST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o24GpYeB022275 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 4 Mar 2010 10:51:35 -0600 (CST) 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; Thu, 4 Mar 2010 08:51:35 -0800 From: "Templin, Fred L" To: "Durand, Alain" , softwires Date: Thu, 4 Mar 2010 08:51:33 -0800 Thread-Topic: Call for agenda items Thread-Index: AcqqeG1MNlazVRfw/U6XHmU8DGMeiwRQhoWQ 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: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A64951152D06XCHNW01Vnwnos_" MIME-Version: 1.0 Subject: Re: [Softwires] Call for agenda items X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:51:38 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A64951152D06XCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alain and David, I would like to request a 30min slot to brief the RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320] trilogy. I would also introduce IRON [draft-templin-iron], which is the bond that binds the constituent parts together. Thanks - Fred fred.l.templin@boeing.com ________________________________ From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Durand, Alain Sent: Wednesday, February 10, 2010 9:43 AM To: softwires Subject: [Softwires] Call for agenda items Please send me and David a note if you plan to present something at the upc= oming IETF softwires wg meeting. - Alain. --_000_E1829B60731D1740BB7A0626B4FAF0A64951152D06XCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Call for agenda items

Alain and David,

 

I would like to request a 30min slot t= o brief the RANGER [RFC5720],

VET [RFC5558] and SEAL [RFC5320] trilo= gy. I would also introduce

IRON [draft-templin-iron], which is th= e bond that binds the constituent

parts together.

 

Thanks – Fred

fred.l.templin@boeing.com

 

From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Durand, Alain
Sent: Wednesday, February 10= , 2010 9:43 AM
To: softwires
Subject: [Softwires] Call fo= r agenda items

 

Please send me and David a note if you plan to present something at the upcoming IETF softwires wg meeting.

  - Alain.

--_000_E1829B60731D1740BB7A0626B4FAF0A64951152D06XCHNW01Vnwnos_-- From Fred.L.Templin@boeing.com Thu Mar 4 09:19:28 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FA9B3A8D9C for ; Thu, 4 Mar 2010 09:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OQ+snzkMLEg for ; Thu, 4 Mar 2010 09:19:26 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 8B08B3A8D9B for ; Thu, 4 Mar 2010 09:19:26 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o24HIb3a023753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Mar 2010 09:18:38 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o24HIbPn007143; Thu, 4 Mar 2010 09:18:37 -0800 (PST) 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 o24HIb5o007135 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 4 Mar 2010 09:18:37 -0800 (PST) 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, 4 Mar 2010 09:18:37 -0800 From: "Templin, Fred L" To: Gabi Nakibly , Mark Townsley , "softwires@ietf.org" Date: Thu, 4 Mar 2010 09:18:35 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: Acq6Fd4iDHQdFGXZSGqegl4pwaLibgBp3xAA Message-ID: References: <428863.89468.qm@ web45507.mail.sp1.yahoo.com><4B8B7EFB.20006@cisco.com> <779468.9747.qm@web45504.mail.sp1.yahoo.com> In-Reply-To: <779468.9747.qm@web45504.mail.sp1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 17:19:28 -0000 Apologies for coming late to this thread. One thing I wanted to point out is that the ISATAP issues identified by 'draft-nakibly-v6ops-tunnel-loops-01' pertain to the ISATAP on-link prefix model. The vulnerability lies in an ISATAP router's mistaken assumption that a correspondent is an ISATAP host when in fact it is another router that could incorrectly reflect the packet. So, in order to have a fine-grained rather than coarse-grained mitigation, the router that implements the mitigation may need to perform an IPv6 prefix check as well as the embedded IPv4 address check. (We believe this is only true for embedded IPv4 addresses taken from RFC1918 private space, however.) Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Gabi Nakibly > Sent: Tuesday, March 02, 2010 6:37 AM > To: Mark Townsley; softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > Mark, >=20 > >As presented in Hiroshima, I don't think an attack between a subscriber'= s own equipment and the BR > is a top concern. The amount of traffic a single > >subscriber can generate with a loop is no more than the subscriber could= generate by downloading and > uploading a lot of v6 content at the same time from > >outside the 6rd domain. Further, with a tunnel loop, the download path w= ould be rate-limited by the > upload path, which is generally quite asymmetric (e.g., > >today a bit-torrent user within a decent swarm off-net could generate mo= re traffic on the BR than a > loop). Point is, there a are a lot of ways a user can fill > >his own pipe, and a loop between relays is probably way down low on the = list of interesting things > to do. >=20 > I=A0definitely see your point=A0here: due to=A0the clients' limited uploa= d bandwidth=A0a routing loop via > internal relay may cause only small damage to the BR. If this is the case= , why should the > draft=A0address the internal loop case at all?=A0Guiding the SP to track = all its internal relays may > incur too much administrative overhead for such a small threat. On the ot= her hand,=A0one should note > that the internal=A0routing loop=A0will probably=A0clog up=A0 the upstrea= m of the client and completely DoS > it. So this=A0may be a=A0big threat for the client itself. >=20 > >My concern here is that checking all possible local IPv4 addresses at a = particular location in the > IPv6 address for every packet switched through the BR > >would result in very significant overhead for a hardware-optimized imple= mentation operating at high > speed. I have no objection to someone doing this kind > >of check in their implementation, but their customers had better be will= ing to pay for it ;-) >=20 > If you still decide to address the internal loop case,=A0it=A0should be n= oted that actually only one > address=A0must be checked for each packet: > - Source address check: the loop will succeed only if the IPv4 source add= ress corresponds to the IPv6 > source address, so before forwarding a packet into=A0the tunnel interface= the BR must make sure that > the IPv6 source address does not correspond to the IPv4=A0address that is= intended to be=A0the packet's > IPv4 source address, only. The other IPv4 addresses of the BR are irrelev= ant here. > - Destination address check: as I gather from Section 7.1.1 in the draft,= =A0currently only a single > 6rdBRIPv4Address=A0is supported=A0by a=A0CE for each BR. If this means th= at a BR advertises in the SP's IGP > only one IPv4 address, then=A0the BR=A0is reachable to the clients=A0only= via this single address. Only > this address should be verified in the destination address check. The loo= p will not work with any > other IPv4 addresses, even if they belong to the BR. >=20 > >Should we refer to your Internet Draft instead? >=20 > I think you should refer to this draft only if you intend to reference on= e of the mitigation measures > we propose there. If you only refer the attacks themselves the current re= ference is better. > In any case, I think that our draft=A0will be revised to refer to the 6rd= case, as well. >=20 > Gabi > ________________________________ > From: Mark Townsley > To: softwires@ietf.org > Sent: Mon, March 1, 2010 10:46:51 AM > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > On 3/1/10 8:44 AM, Gabi Nakibly wrote: > > Hi all, > > I would like to comment on the loop avoidance issue addressed in the Se= curity Considerations > section. > > First, I agree that the the best mitigation measure here for loops via = external relays is to simply > drop at the border of the 6rd domain packets sent from or destined to a 6= rd BR. > > Second, regarding loops via internal relays the draft mentions that: > >=A0 =A0 To avoid forwarding loops via other internal relays, the BR shou= ld > >=A0 =A0 employ outgoing and incoming IPv4 packets filters, filtering out= all > >=A0 =A0 known relay addresses for internal 6rd BRs, ISATAP routers or 6t= o4 > >=A0 =A0 relays, including the well known anycast address space for 6to4. > > Does the SP necessarily knows of every ISATAP router or 6to4 relay depl= oyed in the 6rd domain? > Deployed by the SP. > > After all, a customer can deploy an ISATAP router or even a 6to4 relay = for that matter without the > knowledge of the SP, while using a configured tunnel (by a tunnel broker)= for its IPv6 connectivity. > As presented in Hiroshima, I don't think an attack between a subscriber's= own equipment and the BR is > a top concern. The amount of traffic a single subscriber can generate wit= h a loop is no more than the > subscriber could generate by downloading and uploading a lot of v6 conten= t at the same time from > outside the 6rd domain. Further, with a tunnel loop, the download path wo= uld be rate-limited by the > upload path, which is generally quite asymmetric (e.g., today a bit-torre= nt user within a decent > swarm off-net could generate more traffic on the BR than a loop). Point i= s, there a are a lot of ways > a user can fill his own pipe, and a loop between relays is probably way d= own low on the list of > interesting things to do. >=20 >=20 >=20 >=20 > > I suggest to keep the filtering of internal 6rd BRs. But to avoid loops= via internal ISATAP routers > or 6to4 relays, I would suggest employing the destination/source address = check described in Section > 3.1 in http://tools.ietf.org/html/draft-nakibly-v6ops-tunnel-loops-01 we = have recently submitted. It > is not a perfect solution, and indeed it should be updated in case other = types of automatic tunnels > come up, but it does the job for ISATAP and 6to4 loops without demanding = a knowledge of every > internal ISATAP router or 6to4 relay. > If you are referring to this kind of check: >=20 > =A0 For example, if tunnel router A (ISATAP router or 6to4 relay) > =A0 forwards a packet into a tunnel interface with an IPv6 source address > =A0 that matches the 6to4 prefix 2002:IPa::/48, the router discards the > =A0 packet if IPa is one of its own IPv4 addresses.=A0 In a second exampl= e, > =A0 if tunnel router B (ISATAP router or 6to4 relay) receives an IPv6 > =A0 packet on a tunnel interface with an IPv6 destination address that > =A0 matches the ISATAP address suffix ::0200:5EFE:IPb, the router > =A0 discards the packet if IPb is one of its own IPv4 addresses. >=20 > My concern here is that checking all possible local IPv4 addresses at a p= articular location in the > IPv6 address for every packet switched through the BR would result in ver= y significant overhead for a > hardware-optimized implementation operating at high speed. I have no obje= ction to someone doing this > kind of check in their implementation, but their customers had better be = willing to pay for it ;-) >=20 > Currently, we have this paper referenced: >=20 > =A0 [RoutingLoop] > =A0 =A0 =A0 =A0 =A0 =A0 =A0 Nakibly and Arov, "Routing Loop Attacks using= IPv6 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tunnels", August 2009, =A0 =A0 =A0 =A0 =A0 =A0 =A0 woot09/tech/full_papers/nakibly.pdf>. >=20 > Should we refer to your Internet Draft instead? >=20 > > Other than this I fully support this draft for advancement. > Thanks, >=20 > - Mark >=20 > > Gabi > > > > > > -----------------------------------------------------------------------= - > > *From:* "Durand, Alain" > > *To:* softwires ; DHC WG > > *Cc:* Ole Troan > > *Sent:* Mon, February 22, 2010 11:43:00 PM > > *Subject:* [Softwires] SOFTWIRE working group last call on 6rd > > > > All - > > > > We'd like to announce the softwire WG LC on the 6rd technology. I've co= pied both SOFTWIRE and DHC > mailing lists and solicit comments from both groups of experts. The draft= is here: > > > > _http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-07.tx= t > > _ > > Please reply with comments to this thread by 2010.03.08 at 1700 PST > > > > Thanks > > > > - Alain > > _______________________________________________ > > Softwires mailing list > > _Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires_ > > > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ichiroumakino@gmail.com Thu Mar 4 12:15:53 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990783A8BD2 for ; Thu, 4 Mar 2010 12:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cU-nBrQoRdO7 for ; Thu, 4 Mar 2010 12:15:52 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 7EA733A8E36 for ; Thu, 4 Mar 2010 12:15:52 -0800 (PST) Received: by ewy7 with SMTP id 7so1988960ewy.29 for ; Thu, 04 Mar 2010 12:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=gvU57jPwfhTcMse1METSuWB2bU5OCUZmvqYPSEq4fqg=; b=Jch+EM4Kui+KdbUZ9lgtf9/8XYim2VquoKItHb4ERP4grd0Ab3zmrdHg7/dbpLF6iM MBf/Sv6UxQP9oI9vUm6J36y/pSm6sgxyIfMw1kRY1rqLGFZzj51rT7h6N1UiryExUjit MrSke110T7V9bdslDteK1ghR2Di5NwZ+PyRRw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=XlRYwPftO6UTu63OLHKCoJg2JaC1Xhj20P20fa6UtRM75jdemuHnJcYvHLnjHrpmx2 E0AfNkY013JJs8bJClABVyKVnyE6wXMoOvv28OgoN9X6d785cOuxl769z/Vyy9bdlvco Vw/c+o9YFAWck1U/kM2wyE/ttFBjjGX1NSr1k= Received: by 10.213.100.201 with SMTP id z9mr941262ebn.65.1267733753173; Thu, 04 Mar 2010 12:15:53 -0800 (PST) Received: from ams-otroan-87110.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id 28sm2090988eyg.6.2010.03.04.12.15.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Mar 2010 12:15:51 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Thu, 4 Mar 2010 21:16:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> References: <"20100223203618. G A13301"@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 20:15:53 -0000 Fred, [...] >> Why advertise WAN side MTU to LAN side? Doesn't routers >> advertise LAN MTU via RA? PMTU would work out the optimal >> MTU for end-to-end communication. >=20 > PMTUD within end sites *has* to work in order for there > to be any measure of robustness. Customer end systems > and middleboxes that filter ICMPs are only hurting > themselves and need to change their ways. >=20 > That said, I believe the reason for asking the CE to > advertise 1480 internally to the customer site is to > minimize the incidence of invoking PMTUD. Otherwise, > customer end systems would be constantly sending 1500 > packets initially which would be thrown away by the > CE until PMTUD kicks in. As I mentioned however, the > issue with advertising the 1480 is that it would cause > an MTU reduction even for communications that never > leave the end site. Customers with 9K links might > not like that. I can remove the sentence recommending advertising the tunnel MTU on the = LAN-side interface. or change it from a SHOULD to a MAY. as you say this = is just to minimize the incidence of invoking PMTUD. it should be rare that path MTU discovery doesn't work on the first hop. cheers, Ole= From Fred.L.Templin@boeing.com Thu Mar 4 13:03:23 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 164543A8E66 for ; Thu, 4 Mar 2010 13:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wC6BuJ00ET3 for ; Thu, 4 Mar 2010 13:03:22 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 0E22C3A8E6D for ; Thu, 4 Mar 2010 13:03:21 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o24L3AKT017838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 Mar 2010 15:03:11 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o24L3Afb028119; Thu, 4 Mar 2010 13:03:10 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o24L3AUV028112 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 4 Mar 2010 13:03:10 -0800 (PST) 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, 4 Mar 2010 13:03:10 -0800 From: "Templin, Fred L" To: Ole Troan Date: Thu, 4 Mar 2010 13:03:09 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: Acq713/oEOB9X9jCTMGU3RbpfQcQCwAAGpzA Message-ID: References: <"20100223203618. G A13301"@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> In-Reply-To: <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.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 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 21:03:23 -0000 Hi Ole, > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan > Sent: Thursday, March 04, 2010 12:16 PM > To: Templin, Fred L > Cc: WashamFan; softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > Fred, >=20 > [...] >=20 > >> Why advertise WAN side MTU to LAN side? Doesn't routers > >> advertise LAN MTU via RA? PMTU would work out the optimal > >> MTU for end-to-end communication. > > > > PMTUD within end sites *has* to work in order for there > > to be any measure of robustness. Customer end systems > > and middleboxes that filter ICMPs are only hurting > > themselves and need to change their ways. > > > > That said, I believe the reason for asking the CE to > > advertise 1480 internally to the customer site is to > > minimize the incidence of invoking PMTUD. Otherwise, > > customer end systems would be constantly sending 1500 > > packets initially which would be thrown away by the > > CE until PMTUD kicks in. As I mentioned however, the > > issue with advertising the 1480 is that it would cause > > an MTU reduction even for communications that never > > leave the end site. Customers with 9K links might > > not like that. >=20 > I can remove the sentence recommending advertising the tunnel MTU on the = LAN-side interface. or > change it from a SHOULD to a MAY. as you say this is just to minimize the= incidence of invoking > PMTUD. Removing the sentence might be best. The MAY would be OK, but then you might need to also say something like: "(Note that advertising the tunnel MTU on the LAN-side interface would cause all hosts attached to the link to use a reduced MTU even for link-local communications.)" =20 =20 > it should be rare that path MTU discovery doesn't work on the first hop. If by first hop you mean exiting the customer network and entering the tunnel interface, then I agree. However, over-reliance on PMTUD has negative implications also, including degraded efficiency. Worst case is for short transactions (e.g., http over VPN) where up to 2x as many packets as necessary would be used. Also, setting a conservative fixed MTU on the tunnel interface would make it very difficult to go back and set a larger value later. This, I think, is a key question for how we want to see the IPv6 service deployed: if we want to go out with a robust MTU service in the first iteration, then we have the tools at hand to do so. Otherwise, we wait for the SP network to turn up IPv6 on all of their routers. Turning to SEAL again for the moment, SEAL is about more than just PMTUD. SEAL provides a way for tunnel endpoints to prevent source address spoofing even if the SP network itself has insufficient mitigations. That might possibly be even better than what we can do with native IPv6. Fred fred.l.templin@boeing.com > cheers, > Ole From remi.despres@free.fr Fri Mar 5 06:33:50 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1066628C103 for ; Fri, 5 Mar 2010 06:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+YfK-XMN+xY for ; Fri, 5 Mar 2010 06:33:49 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 035143A8155 for ; Fri, 5 Mar 2010 06:33:47 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 411D4E08137; Fri, 5 Mar 2010 15:33:44 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id E516EE080E6; Fri, 5 Mar 2010 15:33:41 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 5 Mar 2010 15:33:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> References: <"20100223203618. G A13301"@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> To: "Templin, Fred L" , Ole Troan , Brian E Carpenter X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 14:33:50 -0000 Fred, Ole, Brian, Le 4 mars 2010 =E0 22:03, Templin, Fred L a =E9crit : >> -----Original Message----- >> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole = Troan >>=20 >> ...I can remove the sentence recommending advertising the tunnel MTU = on the LAN-side interface. or >> change it from a SHOULD to a MAY. as you say this is just to minimize = the incidence of invoking >> PMTUD. >=20 > Removing the sentence might be best. The MAY would be OK, > but then you might need to also say something like: "(Note > that advertising the tunnel MTU on the LAN-side interface > would cause all hosts attached to the link to use a reduced > MTU even for link-local communications.)" Fred, Ole, Brian, Until PMTUD is made reliable in IPv6 (btw an important objective), all = IPv6-enabled hosts should have their MTU set to 1280 to avoid IPv6 = blackholes. This could in principle apply only to IPv6 packets that leave customer = sites, but as long as hosts have only one MTU parameter, it has to apply = to all packets. Since typical hosts have longer default MTUs than 1280, advertising = MTU=3D1280 on links that offer paths to the global Internet appears to = be the only available tool at hand. =20 The proposal is then to replace: "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined = automatically or configured directly, on the LAN side by setting the MTU = option in Router Advertisements [RFC4861] messages to the 6rd Tunnel = MTU." by: "As long as the path MTU discovery has not been made reliable, a 6rd CE = SHOULD advertise on the LAN side, in the MTU option of Router = Advertisements [RFC4861], an MTU of 1280 octets . This is to prevent = that longer packets that could have traversed the local 6rd domain may = be discarded, because of their size, further in the Internet because of = their size. Note that this may cause all hosts attached to the link to = use a reduced MTU even for link-local communications, IPv6 and IPv4." Regards, RD From ford@isoc.org Fri Mar 5 08:05:10 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F47428C17B for ; Fri, 5 Mar 2010 08:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RALqAKPeV7Fa for ; Fri, 5 Mar 2010 08:05:08 -0800 (PST) Received: from smtp161.iad.emailsrvr.com (smtp161.iad.emailsrvr.com [207.97.245.161]) by core3.amsl.com (Postfix) with ESMTP id 9F75D28C16C for ; Fri, 5 Mar 2010 08:05:07 -0800 (PST) Received: from relay16.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay16.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id C011B1B4220 for ; Fri, 5 Mar 2010 11:05:09 -0500 (EST) Received: by relay16.relay.iad.mlsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id 534221B41EB for ; Fri, 5 Mar 2010 11:05:09 -0500 (EST) Message-ID: <4B912BB4.3090700@isoc.org> Date: Fri, 05 Mar 2010 16:05:08 +0000 From: Matthew Ford User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: softwires@ietf.org References: <"20100223203618. G A13301"@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> In-Reply-To: <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 16:05:10 -0000 Hi Rémi, On 05/03/2010 14:33, Rémi Després wrote: > Until PMTUD is made reliable in IPv6 (btw an important objective), all IPv6-enabled hosts should have their MTU set to 1280 to avoid IPv6 blackholes. > This could in principle apply only to IPv6 packets that leave customer sites, but as long as hosts have only one MTU parameter, it has to apply to all packets. > Since typical hosts have longer default MTUs than 1280, advertising MTU=1280 on links that offer paths to the global Internet appears to be the only available tool at hand. > > The proposal is then to replace: > "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined automatically or configured directly, on the LAN side by setting the MTU option in Router Advertisements [RFC4861] messages to the 6rd Tunnel MTU." > by: > "As long as the path MTU discovery has not been made reliable, a 6rd CE SHOULD advertise on the LAN side, in the MTU option of Router Advertisements [RFC4861], an MTU of 1280 octets . This is to prevent that longer packets that could have traversed the local 6rd domain may be discarded, because of their size, further in the Internet because of their size. Note that this may cause all hosts attached to the link to use a reduced MTU even for link-local communications, IPv6 and IPv4." I'm not sure I see how adopting this approach makes meeting your 'important objective' any more likely. - Mat From Fred.L.Templin@boeing.com Fri Mar 5 08:52:22 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1367A28C2D3 for ; Fri, 5 Mar 2010 08:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.361 X-Spam-Level: X-Spam-Status: No, score=-6.361 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fogNFK3M63ej for ; Fri, 5 Mar 2010 08:52:21 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 400B528C2D2 for ; Fri, 5 Mar 2010 08:52:21 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o25GqClQ017216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 Mar 2010 08:52:12 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o25GqBWB018655; Fri, 5 Mar 2010 08:52:12 -0800 (PST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o25GqB2j018647 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 5 Mar 2010 08:52:11 -0800 (PST) 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, 5 Mar 2010 08:52:11 -0800 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Ole Troan , Brian E Carpenter Date: Fri, 5 Mar 2010 08:52:10 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: Acq8cOC+6on7n3smRA+ojn8iN0BkNgAEv2Vw Message-ID: References: <"20100223203618. G A13301"@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> In-Reply-To: <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> 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 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 16:52:22 -0000 Remi, > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Friday, March 05, 2010 6:34 AM > To: Templin, Fred L; Ole Troan; Brian E Carpenter > Cc: softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > Fred, Ole, Brian, >=20 > Le 4 mars 2010 =E0 22:03, Templin, Fred L a =E9crit : >=20 > >> -----Original Message----- > >> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troa= n > >> > >> ...I can remove the sentence recommending advertising the tunnel MTU o= n the LAN-side interface. or > >> change it from a SHOULD to a MAY. as you say this is just to minimize = the incidence of invoking > >> PMTUD. > > > > Removing the sentence might be best. The MAY would be OK, > > but then you might need to also say something like: "(Note > > that advertising the tunnel MTU on the LAN-side interface > > would cause all hosts attached to the link to use a reduced > > MTU even for link-local communications.)" >=20 > Fred, Ole, Brian, >=20 > Until PMTUD is made reliable in IPv6 (btw an important objective), all IP= v6-enabled hosts should have > their MTU set to 1280 to avoid IPv6 blackholes. > This could in principle apply only to IPv6 packets that leave customer si= tes, but as long as hosts > have only one MTU parameter, it has to apply to all packets. > Since typical hosts have longer default MTUs than 1280, advertising MTU= =3D1280 on links that offer > paths to the global Internet appears to be the only available tool at han= d. >=20 > The proposal is then to replace: > "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined automat= ically or configured > directly, on the LAN side by setting the MTU option in Router Advertiseme= nts [RFC4861] messages to > the 6rd Tunnel MTU." > by: > "As long as the path MTU discovery has not been made reliable, a 6rd CE S= HOULD advertise on the LAN > side, in the MTU option of Router Advertisements [RFC4861], an MTU of 12= 80 octets . This is to > prevent that longer packets that could have traversed the local 6rd domai= n may be discarded, because > of their size, further in the Internet because of their size. Note that t= his may cause all hosts > attached to the link to use a reduced MTU even for link-local communicati= ons, IPv6 and IPv4." The 1280 would be disappointing; I'm sure we can do better. Thanks - Fred fred.l.templin@boeing.com > Regards, > RD From brian.e.carpenter@gmail.com Fri Mar 5 12:38:16 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BDA28C352 for ; Fri, 5 Mar 2010 12:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZhGyJsWNpqI for ; Fri, 5 Mar 2010 12:38:14 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id D80B828C347 for ; Fri, 5 Mar 2010 12:38:13 -0800 (PST) Received: by fxm5 with SMTP id 5so4560890fxm.29 for ; Fri, 05 Mar 2010 12:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fQvBanPPgFzhHIkeNlNEeNYMdIrET1uCTzx9qeQ6sA0=; b=VpiAm+F+4FLDJo+PyQS9Gx0vk2LLmkitv6i7hg5kT5rp7UmZBqlkYlaBiEsZ4+ZDZZ /K+P3m6uo6qkoOIPBXTYAO44hwKicg0DtcUFr71rh4gksK2EnEuhBcDJJyskH67pPdmq H1QesTrMKW+0QogEUDrBAWXFrdMzOise8EDDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=ovOImOo3H8PgLbrCAupsTy9bS2gBOoDXxxzGYFxbfm3fgF/4VJE3IfruuTXiC3pNBW cbbFzLGfRPUyRem6bjT0/qqNChqvQFw3AHmfwn06wABvseUYNIw2diyYjPUNbABVbHEU iQMuKOEXnUfIsSoVwmFrwLf8xV9ux5Z30EJKI= Received: by 10.223.15.89 with SMTP id j25mr1516354faa.97.1267821492941; Fri, 05 Mar 2010 12:38:12 -0800 (PST) Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id 19sm3336494fkr.46.2010.03.05.12.38.08 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Mar 2010 12:38:11 -0800 (PST) Message-ID: <4B916BA7.3080400@gmail.com> Date: Sat, 06 Mar 2010 09:37:59 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" References: <"20100223203618. G A13301"@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 20:38:16 -0000 On 2010-03-06 05:52, Templin, Fred L wrote: > Remi, >=20 >> -----Original Message----- >> From: R=C3=A9mi Despr=C3=A9s [mailto:remi.despres@free.fr] >> Sent: Friday, March 05, 2010 6:34 AM >> To: Templin, Fred L; Ole Troan; Brian E Carpenter >> Cc: softwires@ietf.org >> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >> >> Fred, Ole, Brian, >> >> Le 4 mars 2010 =C3=A0 22:03, Templin, Fred L a =C3=A9crit : >> >>>> -----Original Message----- >>>> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Tr= oan >>>> >>>> ...I can remove the sentence recommending advertising the tunnel MTU= on the LAN-side interface. or >>>> change it from a SHOULD to a MAY. as you say this is just to minimiz= e the incidence of invoking >>>> PMTUD. >>> Removing the sentence might be best. The MAY would be OK, >>> but then you might need to also say something like: "(Note >>> that advertising the tunnel MTU on the LAN-side interface >>> would cause all hosts attached to the link to use a reduced >>> MTU even for link-local communications.)" >> Fred, Ole, Brian, >> >> Until PMTUD is made reliable in IPv6 (btw an important objective), all= IPv6-enabled hosts should have >> their MTU set to 1280 to avoid IPv6 blackholes. >> This could in principle apply only to IPv6 packets that leave customer= sites, but as long as hosts >> have only one MTU parameter, it has to apply to all packets. >> Since typical hosts have longer default MTUs than 1280, advertising MT= U=3D1280 on links that offer >> paths to the global Internet appears to be the only available tool at = hand. >> >> The proposal is then to replace: >> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined auto= matically or configured >> directly, on the LAN side by setting the MTU option in Router Advertis= ements [RFC4861] messages to >> the 6rd Tunnel MTU." >> by: >> "As long as the path MTU discovery has not been made reliable, a 6rd C= E SHOULD advertise on the LAN >> side, in the MTU option of Router Advertisements [RFC4861], an MTU of= 1280 octets . This is to >> prevent that longer packets that could have traversed the local 6rd do= main may be discarded, because >> of their size, further in the Internet because of their size. Note tha= t this may cause all hosts >> attached to the link to use a reduced MTU even for link-local communic= ations, IPv6 and IPv4." >=20 > The 1280 would be disappointing; I'm sure we can do better. As has been said before, in theory there is no difference between theory and practice, but in practice, there is. Right now today a number of ISPs are planning to deploy 6RD, and we have already seen clear evidence from 6to4 deployment that setting the MTU to 1280 is a necessary evil at the moment. So I think this advice should be in the specification, as a SHOULD. Otherwise we'd be misleading those ISPs. I don't like this any more than you do, from a long term perspective. Brian From Fred.L.Templin@boeing.com Fri Mar 5 15:33:44 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72D7A28C426 for ; Fri, 5 Mar 2010 15:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT2zNHpdtEmH for ; Fri, 5 Mar 2010 15:33:43 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id D6F3F28C423 for ; Fri, 5 Mar 2010 15:33:41 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o25NXTIX023719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 Mar 2010 17:33:29 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o25NXTfO013920; Fri, 5 Mar 2010 17:33:29 -0600 (CST) 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 o25NXSc9013909 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 5 Mar 2010 17:33:28 -0600 (CST) 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; Fri, 5 Mar 2010 15:33:27 -0800 From: "Templin, Fred L" To: Brian E Carpenter Date: Fri, 5 Mar 2010 15:33:27 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: Acq8o9ealMZKOiadQaeJDN4xNC70UQAGBltw Message-ID: References: <"20100223203618. G A13301"@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB @f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> In-Reply-To: <4B916BA7.3080400@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 23:33:44 -0000 Hi Brian, > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Friday, March 05, 2010 12:38 PM > To: Templin, Fred L > Cc: R=E9mi Despr=E9s; Ole Troan; softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > On 2010-03-06 05:52, Templin, Fred L wrote: > > Remi, > > > >> -----Original Message----- > >> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > >> Sent: Friday, March 05, 2010 6:34 AM > >> To: Templin, Fred L; Ole Troan; Brian E Carpenter > >> Cc: softwires@ietf.org > >> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > >> > >> Fred, Ole, Brian, > >> > >> Le 4 mars 2010 =E0 22:03, Templin, Fred L a =E9crit : > >> > >>>> -----Original Message----- > >>>> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Tr= oan > >>>> > >>>> ...I can remove the sentence recommending advertising the tunnel MTU= on the LAN-side interface. > or > >>>> change it from a SHOULD to a MAY. as you say this is just to minimiz= e the incidence of invoking > >>>> PMTUD. > >>> Removing the sentence might be best. The MAY would be OK, > >>> but then you might need to also say something like: "(Note > >>> that advertising the tunnel MTU on the LAN-side interface > >>> would cause all hosts attached to the link to use a reduced > >>> MTU even for link-local communications.)" > >> Fred, Ole, Brian, > >> > >> Until PMTUD is made reliable in IPv6 (btw an important objective), all= IPv6-enabled hosts should > have > >> their MTU set to 1280 to avoid IPv6 blackholes. > >> This could in principle apply only to IPv6 packets that leave customer= sites, but as long as hosts > >> have only one MTU parameter, it has to apply to all packets. > >> Since typical hosts have longer default MTUs than 1280, advertising MT= U=3D1280 on links that offer > >> paths to the global Internet appears to be the only available tool at = hand. > >> > >> The proposal is then to replace: > >> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined auto= matically or configured > >> directly, on the LAN side by setting the MTU option in Router Advertis= ements [RFC4861] messages to > >> the 6rd Tunnel MTU." > >> by: > >> "As long as the path MTU discovery has not been made reliable, a 6rd C= E SHOULD advertise on the > LAN > >> side, in the MTU option of Router Advertisements [RFC4861], an MTU of= 1280 octets . This is to > >> prevent that longer packets that could have traversed the local 6rd do= main may be discarded, > because > >> of their size, further in the Internet because of their size. Note tha= t this may cause all hosts > >> attached to the link to use a reduced MTU even for link-local communic= ations, IPv6 and IPv4." > > > > The 1280 would be disappointing; I'm sure we can do better. >=20 > As has been said before, in theory there is no difference between theory > and practice, but in practice, there is. >=20 > Right now today a number of ISPs are planning to deploy 6RD, and we have > already seen clear evidence from 6to4 deployment that setting the MTU to > 1280 is a necessary evil at the moment. So I think this advice should be > in the specification, as a SHOULD. Otherwise we'd be misleading those > ISPs. You leave us with little hope. =20 > I don't like this any more than you do, from a long term perspective. It still nags me that I feel we can do better; in fact, I am sure we can... Thanks - Fred fred.l.templin@boeing.com > Brian From gis-softwires@m.gmane.org Sat Mar 6 18:28:31 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2B13A89E1 for ; Sat, 6 Mar 2010 18:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8c31tNSRfkj for ; Sat, 6 Mar 2010 18:28:30 -0800 (PST) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by core3.amsl.com (Postfix) with ESMTP id 9EA173A860E for ; Sat, 6 Mar 2010 18:28:30 -0800 (PST) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1No4lr-0005VS-Rg for softwires@ietf.org; Sun, 07 Mar 2010 01:55:03 +0100 Received: from i-195-137-1-136.freedom2surf.net ([195.137.1.136]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Mar 2010 01:55:03 +0100 Received: from T.E.Baldwin99 by i-195-137-1-136.freedom2surf.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 07 Mar 2010 01:55:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: softwires@ietf.org From: Timothy Baldwin Followup-To: gmane.ietf.dhc,gmane.ietf.softwires Date: Sun, 07 Mar 2010 00:33:14 +0000 Lines: 27 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: i-195-137-1-136.freedom2surf.net User-Agent: KNode/4.3.4 Cc: dhcwg@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 02:28:32 -0000 Durand, Alain wrote: > All - > > We'd like to announce the softwire WG LC on the 6rd technology. I've > copied both SOFTWIRE and DHC mailing lists and solicit comments from both > groups of experts. The draft is here: > > http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-07.txt The end of section 4 states: "The prefix lifetimes advertised in Router Advertisements or used by DHCP on the CE LAN side MUST be equal to or shorter than the IPv4 address lease time." PPP doesn't have the concept of a lease time, which makes that MUST impossible. Instead the advertised prefixes must be revoked if the IPv4 address changes, and if the prefix has not be written to persistent storage the advertised must be short (about a minute) to prevent prolong mis- configuration of the hosts in the event of the IPv4 address changing after a reboot of the router. In the case of DHCPv4, is it intended to prohibit assigning a new address to CE router before its address lease expires, even if the router reboots to the DHCPv4 INIT state? From ichiroumakino@gmail.com Sat Mar 6 23:26:42 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907313A8ED5; Sat, 6 Mar 2010 23:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deoNmTyAwawS; Sat, 6 Mar 2010 23:26:41 -0800 (PST) Received: from mail-ew0-f227.google.com (mail-ew0-f227.google.com [209.85.219.227]) by core3.amsl.com (Postfix) with ESMTP id 487A63A8CBD; Sat, 6 Mar 2010 23:26:41 -0800 (PST) Received: by ewy27 with SMTP id 27so1941553ewy.14 for ; Sat, 06 Mar 2010 23:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=xKPMz9owWJOiu3jCMH61wOPMeJaxdebsLUWN6Qpioas=; b=girOP4VJ6RvbmC8Ivqxn4ww2bxeDhSlqLjUTeUW1s1LMLPSC4QLoUocjJHdwtWjQ2P I7Hn1OhDkjVx4geQ1rh8LpZR469GjiFmB+mN1pOk3VJNwaKU+wXzpW2nY2gml7WsYuDx 7vlkeAJJPe9Rg4IXNu+xjkS3sUJeYeEZQVffs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=B2BuiMaNk/yI52rteJqxNvvni0gJpNSxt/tZ3lMauWKVVF+6JYExK3uwIYZsW6Uvt9 OUHFp/exj/Uw6NRuXgbOZxKFJ2Zd4KzeEHQY0kzfGxvLpNxScHd+wo1JIM5Vfpy0olY/ EHCNIUUdW+jO9+f4BbziezBVe+ZU7SuMMyRTs= Received: by 10.213.1.210 with SMTP id 18mr1529162ebg.58.1267946801357; Sat, 06 Mar 2010 23:26:41 -0800 (PST) Received: from [192.168.10.107] (235.85-200-4.bkkb.no [85.200.4.235]) by mx.google.com with ESMTPS id 16sm1781861ewy.15.2010.03.06.23.26.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Mar 2010 23:26:40 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Sun, 7 Mar 2010 08:27:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90C50A74-F51D-4696-A6F4-31E3F814B620@employees.org> References: To: Timothy Baldwin X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org, dhcwg@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 07:26:42 -0000 Timothy, >> We'd like to announce the softwire WG LC on the 6rd technology. I've >> copied both SOFTWIRE and DHC mailing lists and solicit comments from = both >> groups of experts. The draft is here: >>=20 >> = http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-07.txt >=20 > The end of section 4 states: > "The prefix lifetimes > advertised in Router Advertisements or used by DHCP on the CE LAN > side MUST be equal to or shorter than the IPv4 address lease time." >=20 > PPP doesn't have the concept of a lease time, which makes that MUST=20 > impossible. Instead the advertised prefixes must be revoked if the = IPv4=20 > address changes, and if the prefix has not be written to persistent = storage=20 > the advertised must be short (about a minute) to prevent prolong mis- > configuration of the hosts in the event of the IPv4 address changing = after a=20 > reboot of the router. >=20 > In the case of DHCPv4, is it intended to prohibit assigning a new = address to=20 > CE router before its address lease expires, even if the router reboots = to=20 > the DHCPv4 INIT state? the intention is to achieve some resemblance of a renumbering event. = difficult when you typically have zero overlap between the old and the = new prefix. cheers, Ole= From ichiroumakino@gmail.com Mon Mar 8 05:32:44 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8D33A6821; Mon, 8 Mar 2010 05:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FpRd8TMM1np; Mon, 8 Mar 2010 05:32:40 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id C750F3A6990; Mon, 8 Mar 2010 05:32:39 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id d26so891476eyd.51 for ; Mon, 08 Mar 2010 05:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=uiiCw8pgwpdnGYIcr3wcvwGRFJ3niDqpbxUnt4DgisI=; b=fKJPQujxpwWIL3ZkU8q2FuknvcADSSTXoCK5Hig5wFoDj2Gvt3vRbP1uEaLNlVRnA2 PdKRH5zi6NzNftl9fgBDzZC5puQlb1U23qWwaz4J+HvD7MkimU/BWlu7Rq2qe8nPtwLC yeu6K1ckg0Kj5OXiDFkXoCNTMtagO11iweyPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=QHNf45iOU9gCLMJu/iyc6KA832VDPNV/BC4Gbe55foG2w6mqgknIBMNQ6TkUQ45/wi vxOhC5tssQc4djQPXxrUAO69UmGT1f+HBbkKk/Wk7khqAWr2NGuFOozhXAs56lEh49tZ wN2GII4LqR+OEf2KAmNU8MQmayC1b+KNW/xGs= Received: by 10.213.50.1 with SMTP id x1mr2957828ebf.62.1268055160378; Mon, 08 Mar 2010 05:32:40 -0800 (PST) Received: from ams-otroan-87110.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id 5sm9566302eyf.35.2010.03.08.05.32.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Mar 2010 05:32:40 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 8 Mar 2010 14:33:04 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1211F394-5991-48F5-8A0C-C458478758DD@employees.org> References: To: "Durand, Alain" X-Mailer: Apple Mail (2.1077) Cc: softwires , DHC WG Subject: [Softwires] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 13:32:44 -0000 all, thank you very much for good and constructive comments! I've tried to summarize the comments received and the changes made below. cheers, Ole ** Include option Parameter Request List option for the DHCPv4 option: New text: The CE MUST include a Parameter Request List Option for the OPTION_6RD. Because the OPTION_6RD contains one IPv4MaskLen/6rdPrefixLen/6rdPrefix block, and because DHCP cannot convey more than one instance of an option, OPTION_6RD is limited to provision at most a single 6rd domain. Provisioning of a CE router connected to multiple 6rd domains is outside the scope of this protocol specification. => Accepted ** Loop avoidance Suggestion was to adopt solution in draft-nakibly-v6ops-tunnel-loops. Issues with scalability and checking of "well-known" bits in ISATAP addresses. => Keep existing text. ** MTU There are well documented issues with tunnels and MTU. There are issues with anycast and fragmentation. The draft references the existing mechanisms for tunnelling and MTU, and recommend following existing practice. Since the mechanism is contained within a single SP network, one can assume that the MTU is well managed. Just as in an MPLS network. => Keep existing text. Should the working group start a separate effort for a more general solution to MTU issues? ** Use of anycast There are issues with the use of anycast. The draft supports the use of unicast BR addresses too. The issues around ECMP, fragmentation and ICMP messages ending up on the wrong BR are to some extent operational. It depends on the network having a well maintained MTU as recommended in the draft. ECMP should be done on a per flow basis not on a per packet. => Keep existing text. ** Analysis of domain of applicability The draft already sets the context of the solution to within an SP network. More detail and operational scenarios might be more suitable to a 6rd operational document. => No action. ** IPv4 lease time in case of PPP What lease-time should be used on the LAN-side in IPv6 RAs when the IPv4 WAN side address is aquired via IPCP? Proposed new text: 6rd IPv6 address assignment and hence the IPv6 service itself is tied to the IPv4 address lease, thus the 6rd service is also tied to this in terms of authorization, accounting, etc. For example, the 6rd delegated prefix has the same lifetime as its associated IPv4 address. The prefix lifetimes advertised in Router Advertisements or used by DHCP on the CE LAN side MUST be equal to or shorter than the IPv4 address lease time. If the IPv4 lease time is not known, the lifetime of the 6rd delegated prefix SHOULD follow the defaults specified in . => Accepted. From remi.despres@free.fr Mon Mar 8 06:01:23 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8483A695B; Mon, 8 Mar 2010 06:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFAqlwmZ9Nn2; Mon, 8 Mar 2010 06:01:22 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id CC2C63A6804; Mon, 8 Mar 2010 06:01:19 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 8C713E081BE; Mon, 8 Mar 2010 15:01:17 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 08493E081B0; Mon, 8 Mar 2010 15:01:15 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <1211F394-5991-48F5-8A0C-C458478758DD@employees.org> Date: Mon, 8 Mar 2010 15:01:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <60D68822-8BB8-4900-B462-C89BEF4F4C86@free.fr> References: <1211F394-5991-48F5-8A0C-C458478758DD@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1077) Cc: "Durand, Alain" , softwires , DHC WG Subject: Re: [Softwires] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 14:01:23 -0000 Hi Ole, Thanks for this useful summary. The point below, discussed on Friday is one more for your list. Cheers, RD >=20 > De : Brian E Carpenter > Date : 5 mars 2010 21:37:59 HNEC >=20 > On 2010-03-06 05:52, Templin, Fred L wrote: >>> -----Original Message----- >>> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] >>> Sent: Friday, March 05, 2010 6:34 AM >>=20 >>>=20 >>>=20 >>> Until PMTUD is made reliable in IPv6 (btw an important objective), = all IPv6-enabled hosts should have >>> their MTU set to 1280 to avoid IPv6 blackholes. >>> This could in principle apply only to IPv6 packets that leave = customer sites, but as long as hosts >>> have only one MTU parameter, it has to apply to all packets. >>> Since typical hosts have longer default MTUs than 1280, advertising = MTU=3D1280 on links that offer >>> paths to the global Internet appears to be the only available tool = at hand. >>>=20 >>> The proposal is then to replace: >>> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined = automatically or configured >>> directly, on the LAN side by setting the MTU option in Router = Advertisements [RFC4861] messages to >>> the 6rd Tunnel MTU." >>> by: >>> "As long as the path MTU discovery has not been made reliable, a 6rd = CE SHOULD advertise on the LAN >>> side, in the MTU option of Router Advertisements [RFC4861], an MTU = of 1280 octets . This is to >>> prevent that longer packets that could have traversed the local 6rd = domain may be discarded, because >>> of their size, further in the Internet because of their size. Note = that this may cause all hosts >>> attached to the link to use a reduced MTU even for link-local = communications, IPv6 and IPv4." >>=20 >> The 1280 would be disappointing; I'm sure we can do better. >=20 > As has been said before, in theory there is no difference between = theory > and practice, but in practice, there is. >=20 > Right now today a number of ISPs are planning to deploy 6RD, and we = have > already seen clear evidence from 6to4 deployment that setting the MTU = to > 1280 is a necessary evil at the moment. So I think this advice should = be > in the specification, as a SHOULD. Otherwise we'd be misleading those > ISPs. >=20 > I don't like this any more than you do, from a long term perspective. >=20 > Brian From townsley@cisco.com Mon Mar 8 06:51:28 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDCE03A69A1 for ; Mon, 8 Mar 2010 06:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsdH1H-zaKmE for ; Mon, 8 Mar 2010 06:51:27 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D42A23A69AD for ; Mon, 8 Mar 2010 06:51:27 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACaelEurR7Hu/2dsb2JhbACDC5gdc6FdiCWPWoEyglxqBA X-IronPort-AV: E=Sophos;i="4.49,602,1262563200"; d="scan'208";a="244941501" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2010 14:51:32 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o28EpWRv025363 for ; Mon, 8 Mar 2010 14:51:32 GMT Received: from ams-townsley-87110.cisco.com (ams-townsley-87110.cisco.com [10.55.233.235]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o28EpUY21450 for ; Mon, 8 Mar 2010 06:51:30 -0800 (PST) Message-ID: <4B950EF1.6010304@cisco.com> Date: Mon, 08 Mar 2010 15:51:29 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: softwires@ietf.org References: <13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> In-Reply-To: <4B916BA7.3080400@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 14:51:29 -0000 On 3/5/10 9:37 PM, Brian E Carpenter wrote: > On 2010-03-06 05:52, Templin, Fred L wrote: > >> Remi, >> >> >>> -----Original Message----- >>> From: Rémi Després [mailto:remi.despres@free.fr] >>> Sent: Friday, March 05, 2010 6:34 AM >>> To: Templin, Fred L; Ole Troan; Brian E Carpenter >>> Cc: softwires@ietf.org >>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >>> >>> Fred, Ole, Brian, >>> >>> Le 4 mars 2010 à 22:03, Templin, Fred L a écrit : >>> >>> >>>>> -----Original Message----- >>>>> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan >>>>> >>>>> ...I can remove the sentence recommending advertising the tunnel MTU on the LAN-side interface. or >>>>> change it from a SHOULD to a MAY. as you say this is just to minimize the incidence of invoking >>>>> PMTUD. >>>>> >>>> Removing the sentence might be best. The MAY would be OK, >>>> but then you might need to also say something like: "(Note >>>> that advertising the tunnel MTU on the LAN-side interface >>>> would cause all hosts attached to the link to use a reduced >>>> MTU even for link-local communications.)" >>>> >>> Fred, Ole, Brian, >>> >>> Until PMTUD is made reliable in IPv6 (btw an important objective), all IPv6-enabled hosts should have >>> their MTU set to 1280 to avoid IPv6 blackholes. >>> This could in principle apply only to IPv6 packets that leave customer sites, but as long as hosts >>> have only one MTU parameter, it has to apply to all packets. >>> Since typical hosts have longer default MTUs than 1280, advertising MTU=1280 on links that offer >>> paths to the global Internet appears to be the only available tool at hand. >>> >>> The proposal is then to replace: >>> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined automatically or configured >>> directly, on the LAN side by setting the MTU option in Router Advertisements [RFC4861] messages to >>> the 6rd Tunnel MTU." >>> by: >>> "As long as the path MTU discovery has not been made reliable, a 6rd CE SHOULD advertise on the LAN >>> side, in the MTU option of Router Advertisements [RFC4861], an MTU of 1280 octets . This is to >>> prevent that longer packets that could have traversed the local 6rd domain may be discarded, because >>> of their size, further in the Internet because of their size. Note that this may cause all hosts >>> attached to the link to use a reduced MTU even for link-local communications, IPv6 and IPv4." >>> >> The 1280 would be disappointing; I'm sure we can do better. >> > As has been said before, in theory there is no difference between theory > and practice, but in practice, there is. > > Right now today a number of ISPs are planning to deploy 6RD, and we have > already seen clear evidence from 6to4 deployment that setting the MTU to > 1280 is a necessary evil at the moment. So I think this advice should be > in the specification, as a SHOULD. Otherwise we'd be misleading those > ISPs. > I don't think that the evidence from 6to4 is directly applicable to 6rd as the administrative domain of deployment is quite different between the two. Absent working automatic mechanisms, MTU is very much a administratively controlled item today. Since a given 6rd deployment is limited to one (or perhaps a few) administrative domain(s), the MTU problem is generally more tractable than with 6to4 which typically has no readily assignable responsible party to address a problem when it occurs. We do have evidence that 6rd works fine with a 1480 MTU over an IPv4-enabled link with MTU of 1500. Some bugs, not necessarily 6rd-specific, have been uncovered in the process, and fixed. That's a good thing. Let's not throw in the towel until the game is truly over. - Mark > I don't like this any more than you do, from a long term perspective. > > Brian > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From remi.despres@free.fr Mon Mar 8 07:37:32 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043333A69BA for ; Mon, 8 Mar 2010 07:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3XmwbkwQNoA for ; Mon, 8 Mar 2010 07:37:31 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id D66D53A6985 for ; Mon, 8 Mar 2010 07:37:29 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 54BA9E0813B; Mon, 8 Mar 2010 16:37:29 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 1BE5BE08061; Mon, 8 Mar 2010 16:37:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4B950EF1.6010304@cisco.com> Date: Mon, 8 Mar 2010 16:37:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> References: <13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> To: Mark Townsley X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:37:32 -0000 Hi Mark, Further comments below. Le 8 mars 2010 =E0 15:51, Mark Townsley a =E9crit : > On 3/5/10 9:37 PM, Brian E Carpenter wrote: >> On 2010-03-06 05:52, Templin, Fred L wrote: >> =20 >>> Remi, >>>=20 >>> =20 >>>> -----Original Message----- >>>> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] >>>> Sent: Friday, March 05, 2010 6:34 AM >>>> Fred, Ole, Brian, >>>>=20 >>>> Until PMTUD is made reliable in IPv6 (btw an important objective), = all IPv6-enabled hosts should have >>>> their MTU set to 1280 to avoid IPv6 blackholes. >>>> This could in principle apply only to IPv6 packets that leave = customer sites, but as long as hosts >>>> have only one MTU parameter, it has to apply to all packets. >>>> Since typical hosts have longer default MTUs than 1280, advertising = MTU=3D1280 on links that offer >>>> paths to the global Internet appears to be the only available tool = at hand. >>>>=20 >>>> The proposal is then to replace: >>>> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined = automatically or configured >>>> directly, on the LAN side by setting the MTU option in Router = Advertisements [RFC4861] messages to >>>> the 6rd Tunnel MTU." >>>> by: >>>> "As long as the path MTU discovery has not been made reliable, a = 6rd CE SHOULD advertise on the LAN >>>> side, in the MTU option of Router Advertisements [RFC4861], an MTU = of 1280 octets . This is to >>>> prevent that longer packets that could have traversed the local 6rd = domain may be discarded, because >>>> of their size, further in the Internet because of their size. Note = that this may cause all hosts >>>> attached to the link to use a reduced MTU even for link-local = communications, IPv6 and IPv4." >>>> =20 >>> The 1280 would be disappointing; I'm sure we can do better. >>> =20 >> As has been said before, in theory there is no difference between = theory >> and practice, but in practice, there is. >>=20 >> Right now today a number of ISPs are planning to deploy 6RD, and we = have >> already seen clear evidence from 6to4 deployment that setting the MTU = to >> 1280 is a necessary evil at the moment. So I think this advice should = be >> in the specification, as a SHOULD. Otherwise we'd be misleading those >> ISPs. >> =20 > I don't think that the evidence from 6to4 is directly applicable to = 6rd as the administrative domain of deployment is quite different = between the two. Absent working automatic mechanisms, MTU is very much a = administratively controlled item today. Since a given 6rd deployment is = limited to one (or perhaps a few) administrative domain(s), the MTU = problem is generally more tractable than with 6to4 which typically has = no readily assignable responsible party to address a problem when it = occurs. >=20 > We do have evidence that 6rd works fine with a 1480 MTU over an = IPv4-enabled link with MTU of 1500. Hi Mark, I certainly don't contest this where 6rd is deployed today (being as you = well know a happy user of Free's implementation ;-) ). But the point is that if one of my outgoing packets leaves Free's = network and reaches another network where the MTU is 1280, which is = permitted, it will be discarded. If PMTUD cannot be relied on, this can create a blackhole. =20 (Clearly paths to Google and to the IETF have MTUs at least 1480, which = is fine, but the recommended solution must work for all IPv6 servers. = Note that, as long as PMTU is considered unreliable, both Google and the = IETF should also better send IPv6 packets with an assumed 1280 path = MTU. =20 > Some bugs, not necessarily 6rd-specific, have been uncovered in the = process, and fixed. That's a good thing. > Let's not throw in the towel until the game is truly over. Be sure I will not throw the towel and continue to fight for IPv6 to be = reliably usable (first), and with more and more efficiency (next).=20 Cheers, RD From ichiroumakino@gmail.com Mon Mar 8 07:42:46 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9043A6A12 for ; Mon, 8 Mar 2010 07:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVnC570NiQwh for ; Mon, 8 Mar 2010 07:42:45 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id ACDA63A6A26 for ; Mon, 8 Mar 2010 07:42:40 -0800 (PST) Received: by ewy8 with SMTP id 8so158349ewy.28 for ; Mon, 08 Mar 2010 07:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=eDstwf7ov76hXBH4ek/CPj5eg2geFhUBrVMDR0cHvMc=; b=gcNm5GZGUYrsg+hFXeQy+ljvTIYn4GEBVn/aiEpFFb8CpJR2DjOoFbGStB/XXg0oeN ndsWXIo6An2LoK3+Td/SP7k5UacJaoFV4fSChs9TWHv6Nt5wU/haQkA8nXH0J3pSdXHL JAsMyVDlO2xx2EirbFiNsmi+vzAitiU2EWz30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=o3OQXfxHalJgvuuwwJdY+cvYjqUzdJkkhcQREEjsHQQmdOshADQiri8Hks+MgIL0f2 2xFhRxX/AUYUB2gXUb6CYr+L1YmT5v35ebFD85fJCFS35wJyuy7QAwhNp31lh2X1l4Ez l2dYf+Q2w60OHDXVJTn66NxPESGOPQ53CGq78= Received: by 10.213.107.20 with SMTP id z20mr3212286ebo.81.1268062961682; Mon, 08 Mar 2010 07:42:41 -0800 (PST) Received: from ams-otroan-87110.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id 5sm4137109eyh.1.2010.03.08.07.42.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Mar 2010 07:42:40 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Ole Troan In-Reply-To: <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> Date: Mon, 8 Mar 2010 16:43:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:42:46 -0000 Remi, >>>>> -----Original Message----- >>>>> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] >>>>> Sent: Friday, March 05, 2010 6:34 AM >=20 >>>>> Fred, Ole, Brian, >>>>>=20 >>>>> Until PMTUD is made reliable in IPv6 (btw an important objective), = all IPv6-enabled hosts should have >>>>> their MTU set to 1280 to avoid IPv6 blackholes. >>>>> This could in principle apply only to IPv6 packets that leave = customer sites, but as long as hosts >>>>> have only one MTU parameter, it has to apply to all packets. >>>>> Since typical hosts have longer default MTUs than 1280, = advertising MTU=3D1280 on links that offer >>>>> paths to the global Internet appears to be the only available tool = at hand. >>>>>=20 >>>>> The proposal is then to replace: >>>>> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined = automatically or configured >>>>> directly, on the LAN side by setting the MTU option in Router = Advertisements [RFC4861] messages to >>>>> the 6rd Tunnel MTU." >>>>> by: >>>>> "As long as the path MTU discovery has not been made reliable, a = 6rd CE SHOULD advertise on the LAN >>>>> side, in the MTU option of Router Advertisements [RFC4861], an = MTU of 1280 octets . This is to >>>>> prevent that longer packets that could have traversed the local = 6rd domain may be discarded, because >>>>> of their size, further in the Internet because of their size. Note = that this may cause all hosts >>>>> attached to the link to use a reduced MTU even for link-local = communications, IPv6 and IPv4." >>>>>=20 >>>> The 1280 would be disappointing; I'm sure we can do better. >>>>=20 >>> As has been said before, in theory there is no difference between = theory >>> and practice, but in practice, there is. >>>=20 >>> Right now today a number of ISPs are planning to deploy 6RD, and we = have >>> already seen clear evidence from 6to4 deployment that setting the = MTU to >>> 1280 is a necessary evil at the moment. So I think this advice = should be >>> in the specification, as a SHOULD. Otherwise we'd be misleading = those >>> ISPs. >>>=20 >> I don't think that the evidence from 6to4 is directly applicable to = 6rd as the administrative domain of deployment is quite different = between the two. Absent working automatic mechanisms, MTU is very much a = administratively controlled item today. Since a given 6rd deployment is = limited to one (or perhaps a few) administrative domain(s), the MTU = problem is generally more tractable than with 6to4 which typically has = no readily assignable responsible party to address a problem when it = occurs. >>=20 >> We do have evidence that 6rd works fine with a 1480 MTU over an = IPv4-enabled link with MTU of 1500. >=20 > Hi Mark, >=20 > I certainly don't contest this where 6rd is deployed today (being as = you well know a happy user of Free's implementation ;-) ). >=20 > But the point is that if one of my outgoing packets leaves Free's = network and reaches another network where the MTU is 1280, which is = permitted, it will be discarded. > If PMTUD cannot be relied on, this can create a blackhole. =20 >=20 > (Clearly paths to Google and to the IETF have MTUs at least 1480, = which is fine, but the recommended solution must work for all IPv6 = servers. Note that, as long as PMTU is considered unreliable, both = Google and the IETF should also better send IPv6 packets with an = assumed 1280 path MTU. =20 >=20 >> Some bugs, not necessarily 6rd-specific, have been uncovered in the = process, and fixed. That's a good thing. >=20 >=20 >> Let's not throw in the towel until the game is truly over. >=20 > Be sure I will not throw the towel and continue to fight for IPv6 to = be reliably usable (first), and with more and more efficiency (next).=20 but you are making an argument that _every_ IPv6 link should be a = maximum of 1280 bytes. I don't think that is something 6rd should = prescribe. cheers, Ole From Martin.Gysi@swisscom.com Mon Mar 8 08:03:18 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A5E3A6A1D for ; Mon, 8 Mar 2010 08:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjV+CMYpHOdv for ; Mon, 8 Mar 2010 08:03:17 -0800 (PST) Received: from mail.swisscom.com (outmail21.swisscom.com [138.190.32.11]) by core3.amsl.com (Postfix) with ESMTP id 1E9D33A69F5 for ; Mon, 8 Mar 2010 08:03:15 -0800 (PST) Received: by mrp.swissptt.ch; Mon, 8 Mar 2010 17:03:17 +0100 (MET) From: To: Date: Mon, 8 Mar 2010 17:03:01 +0100 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: Acq+zuBMJl4oCRt+T7eCkRIoU1jHdQACPbmw Message-ID: References: <13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco.com> In-Reply-To: <4B950EF1.6010304@cisco.com> Accept-Language: de-DE, de-CH Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, de-CH Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:03:18 -0000 TWFyaw0KDQoNCj5PbiAzLzUvMTAgOTozNyBQTSwgQnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo+ PiBPbiAyMDEwLTAzLTA2IDA1OjUyLCBUZW1wbGluLCBGcmVkIEwgd3JvdGU6DQo+PiAgICANCj4+ PiBSZW1pLA0KPj4+DQo+Pj4gICAgICANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+Pj4gRnJvbTogUsOpbWkgRGVzcHLDqXMgW21haWx0bzpyZW1pLmRlc3ByZXNAZnJlZS5mcl0N Cj4+Pj4gU2VudDogRnJpZGF5LCBNYXJjaCAwNSwgMjAxMCA2OjM0IEFNDQo+Pj4+IFRvOiBUZW1w bGluLCBGcmVkIEw7IE9sZSBUcm9hbjsgQnJpYW4gRSBDYXJwZW50ZXINCj4+Pj4gQ2M6IHNvZnR3 aXJlc0BpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogW1NvZnR3aXJlc10gU09GVFdJUkUgd29y a2luZyBncm91cCBsYXN0IGNhbGwgb24gNnJkDQo+Pj4+DQo+Pj4+IEZyZWQsIE9sZSwgQnJpYW4s DQo+Pj4+DQo+Pj4+IExlIDQgbWFycyAyMDEwIMOgIDIyOjAzLCBUZW1wbGluLCBGcmVkIEwgYSDD qWNyaXQgOg0KPj4+Pg0KPj4+PiAgICAgICAgDQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+Pj4+PiBGcm9tOiBPbGUgVHJvYW4gW21haWx0bzppY2hpcm91bWFraW5vQGdtYWls LmNvbV0gT24gQmVoYWxmIE9mIE9sZSBUcm9hbg0KPj4+Pj4+DQo+Pj4+Pj4gLi4uSSBjYW4gcmVt b3ZlIHRoZSBzZW50ZW5jZSByZWNvbW1lbmRpbmcgYWR2ZXJ0aXNpbmcgdGhlIHR1bm5lbCBNVFUg b24gdGhlIExBTi1zaWRlIGludGVyZmFjZS4gb3INCj4+Pj4+PiBjaGFuZ2UgaXQgZnJvbSBhIFNI T1VMRCB0byBhIE1BWS4gYXMgeW91IHNheSB0aGlzIGlzIGp1c3QgdG8gbWluaW1pemUgdGhlIGlu Y2lkZW5jZSBvZiBpbnZva2luZw0KPj4+Pj4+IFBNVFVELg0KPj4+Pj4+ICAgICAgICAgICAgDQo+ Pj4+PiBSZW1vdmluZyB0aGUgc2VudGVuY2UgbWlnaHQgYmUgYmVzdC4gVGhlIE1BWSB3b3VsZCBi ZSBPSywNCj4+Pj4+IGJ1dCB0aGVuIHlvdSBtaWdodCBuZWVkIHRvIGFsc28gc2F5IHNvbWV0aGlu ZyBsaWtlOiAiKE5vdGUNCj4+Pj4+IHRoYXQgYWR2ZXJ0aXNpbmcgdGhlIHR1bm5lbCBNVFUgb24g dGhlIExBTi1zaWRlIGludGVyZmFjZQ0KPj4+Pj4gd291bGQgY2F1c2UgYWxsIGhvc3RzIGF0dGFj aGVkIHRvIHRoZSBsaW5rIHRvIHVzZSBhIHJlZHVjZWQNCj4+Pj4+IE1UVSBldmVuIGZvciBsaW5r LWxvY2FsIGNvbW11bmljYXRpb25zLikiDQo+Pj4+PiAgICAgICAgICANCj4+Pj4gRnJlZCwgT2xl LCBCcmlhbiwNCj4+Pj4NCj4+Pj4gVW50aWwgUE1UVUQgaXMgbWFkZSByZWxpYWJsZSBpbiBJUHY2 IChidHcgYW4gaW1wb3J0YW50IG9iamVjdGl2ZSksIGFsbCBJUHY2LWVuYWJsZWQgaG9zdHMgc2hv dWxkIGhhdmUNCj4+Pj4gdGhlaXIgTVRVIHNldCB0byAxMjgwIHRvIGF2b2lkIElQdjYgYmxhY2to b2xlcy4NCj4+Pj4gVGhpcyBjb3VsZCBpbiBwcmluY2lwbGUgYXBwbHkgb25seSB0byBJUHY2IHBh Y2tldHMgdGhhdCBsZWF2ZSBjdXN0b21lciBzaXRlcywgYnV0IGFzIGxvbmcgYXMgaG9zdHMNCj4+ Pj4gaGF2ZSBvbmx5IG9uZSBNVFUgcGFyYW1ldGVyLCBpdCBoYXMgdG8gYXBwbHkgdG8gYWxsIHBh Y2tldHMuDQo+Pj4+IFNpbmNlIHR5cGljYWwgaG9zdHMgaGF2ZSBsb25nZXIgZGVmYXVsdCBNVFVz IHRoYW4gMTI4MCwgYWR2ZXJ0aXNpbmcgTVRVPTEyODAgb24gbGlua3MgdGhhdCBvZmZlcg0KPj4+ PiBwYXRocyB0byB0aGUgZ2xvYmFsIEludGVybmV0IGFwcGVhcnMgdG8gYmUgdGhlIG9ubHkgYXZh aWxhYmxlIHRvb2wgYXQgaGFuZC4NCj4+Pj4NCj4+Pj4gVGhlIHByb3Bvc2FsIGlzIHRoZW4gdG8g cmVwbGFjZToNCj4+Pj4gIkEgNnJkIENFIFNIT1VMRCBhZHZlcnRpc2UgdGhlIDZyZCBUdW5uZWwg TVRVLCB3aGV0aGVyIGRldGVybWluZWQgYXV0b21hdGljYWxseSBvciBjb25maWd1cmVkDQo+Pj4+ IGRpcmVjdGx5LCBvbiB0aGUgTEFOIHNpZGUgYnkgc2V0dGluZyB0aGUgTVRVIG9wdGlvbiBpbiBS b3V0ZXIgQWR2ZXJ0aXNlbWVudHMgW1JGQzQ4NjFdIG1lc3NhZ2VzIHRvDQo+Pj4+IHRoZSA2cmQg VHVubmVsIE1UVS4iDQo+Pj4+IGJ5Og0KPj4+PiAiQXMgbG9uZyBhcyB0aGUgcGF0aCBNVFUgZGlz Y292ZXJ5IGhhcyBub3QgYmVlbiBtYWRlIHJlbGlhYmxlLCBhIDZyZCBDRSBTSE9VTEQgYWR2ZXJ0 aXNlIG9uIHRoZSBMQU4NCj4+Pj4gc2lkZSwgaW4gdGhlIE1UVSBvcHRpb24gb2YgUm91dGVyIEFk dmVydGlzZW1lbnRzIFtSRkM0ODYxXSwgYW4gIE1UVSBvZiAxMjgwIG9jdGV0cyAuIFRoaXMgaXMg dG8NCj4+Pj4gcHJldmVudCB0aGF0IGxvbmdlciBwYWNrZXRzIHRoYXQgY291bGQgaGF2ZSB0cmF2 ZXJzZWQgdGhlIGxvY2FsIDZyZCBkb21haW4gbWF5IGJlIGRpc2NhcmRlZCwgYmVjYXVzZQ0KPj4+ PiBvZiB0aGVpciBzaXplLCBmdXJ0aGVyIGluIHRoZSBJbnRlcm5ldCBiZWNhdXNlIG9mIHRoZWly IHNpemUuIE5vdGUgdGhhdCB0aGlzIG1heSBjYXVzZSBhbGwgaG9zdHMNCj4+Pj4gYXR0YWNoZWQg dG8gdGhlIGxpbmsgdG8gdXNlIGEgcmVkdWNlZCBNVFUgZXZlbiBmb3IgbGluay1sb2NhbCBjb21t dW5pY2F0aW9ucywgSVB2NiBhbmQgSVB2NC4iDQo+Pj4+ICAgICAgICANCj4+PiBUaGUgMTI4MCB3 b3VsZCBiZSBkaXNhcHBvaW50aW5nOyBJJ20gc3VyZSB3ZSBjYW4gZG8gYmV0dGVyLg0KPj4+ICAg ICAgDQo+PiBBcyBoYXMgYmVlbiBzYWlkIGJlZm9yZSwgaW4gdGhlb3J5IHRoZXJlIGlzIG5vIGRp ZmZlcmVuY2UgYmV0d2VlbiB0aGVvcnkNCj4+IGFuZCBwcmFjdGljZSwgYnV0IGluIHByYWN0aWNl LCB0aGVyZSBpcy4NCj4+DQo+PiBSaWdodCBub3cgdG9kYXkgYSBudW1iZXIgb2YgSVNQcyBhcmUg cGxhbm5pbmcgdG8gZGVwbG95IDZSRCwgYW5kIHdlIGhhdmUNCj4+IGFscmVhZHkgc2VlbiBjbGVh ciBldmlkZW5jZSBmcm9tIDZ0bzQgZGVwbG95bWVudCB0aGF0IHNldHRpbmcgdGhlIE1UVSB0bw0K Pj4gMTI4MCBpcyBhIG5lY2Vzc2FyeSBldmlsIGF0IHRoZSBtb21lbnQuIFNvIEkgdGhpbmsgdGhp cyBhZHZpY2Ugc2hvdWxkIGJlDQo+PiBpbiB0aGUgc3BlY2lmaWNhdGlvbiwgYXMgYSBTSE9VTEQu IE90aGVyd2lzZSB3ZSdkIGJlIG1pc2xlYWRpbmcgdGhvc2UNCj4+IElTUHMuDQo+PiAgICANCj5J IGRvbid0IHRoaW5rIHRoYXQgdGhlIGV2aWRlbmNlIGZyb20gNnRvNCBpcyBkaXJlY3RseSBhcHBs aWNhYmxlIHRvIDZyZCANCj5hcyB0aGUgYWRtaW5pc3RyYXRpdmUgZG9tYWluIG9mIGRlcGxveW1l bnQgaXMgcXVpdGUgZGlmZmVyZW50IGJldHdlZW4gDQo+dGhlIHR3by4gQWJzZW50IHdvcmtpbmcg YXV0b21hdGljIG1lY2hhbmlzbXMsIE1UVSBpcyB2ZXJ5IG11Y2ggYSANCj5hZG1pbmlzdHJhdGl2 ZWx5IGNvbnRyb2xsZWQgaXRlbSB0b2RheS4gU2luY2UgYSBnaXZlbiA2cmQgZGVwbG95bWVudCBp cyANCj5saW1pdGVkIHRvIG9uZSAob3IgcGVyaGFwcyBhIGZldykgYWRtaW5pc3RyYXRpdmUgZG9t YWluKHMpLCB0aGUgTVRVIA0KPnByb2JsZW0gaXMgZ2VuZXJhbGx5IG1vcmUgdHJhY3RhYmxlIHRo YW4gd2l0aCA2dG80IHdoaWNoIHR5cGljYWxseSBoYXMgDQo+bm8gcmVhZGlseSBhc3NpZ25hYmxl IHJlc3BvbnNpYmxlIHBhcnR5IHRvIGFkZHJlc3MgYSBwcm9ibGVtIHdoZW4gaXQgb2NjdXJzLg0K DQo+V2UgZG8gaGF2ZSBldmlkZW5jZSB0aGF0IDZyZCB3b3JrcyBmaW5lIHdpdGggYSAxNDgwIE1U VSBvdmVyIGFuIA0KPklQdjQtZW5hYmxlZCBsaW5rIHdpdGggTVRVIG9mIDE1MDAuIFNvbWUgYnVn cywgbm90IG5lY2Vzc2FyaWx5IA0KPjZyZC1zcGVjaWZpYywgaGF2ZSBiZWVuIHVuY292ZXJlZCBp biB0aGUgcHJvY2VzcywgYW5kIGZpeGVkLiBUaGF0J3MgYSANCj5nb29kIHRoaW5nLiBMZXQncyBu b3QgdGhyb3cgaW4gdGhlIHRvd2VsIHVudGlsIHRoZSBnYW1lIGlzIHRydWx5IG92ZXIuDQoNCj4t IE1hcmsNCg0KSSBoYXZlIHRvIHN1cHBvcnQgeW91LiBUaGUgTVRVIGlzIG5vdCBhcmJpdHJhcnkg d2l0aGluIGEgc2VydmljZSBwcm92aWRlciBuZXR3b3JrLCBidXQgd2VsbCBlbmdpbmVlcmVkLiA2 UkQgaXMgbm90IHRhcmdldGVkIGZvciB0aGUgb3BlbiBJbnRlcm5ldCwgYnV0IGlzIHJlYWxseSBp bnRlbmRlZCBmb3IgU1AgdXNhZ2UuIEhlbmNlLCBhbiBNVFUgb2YgMTQ4MCBpcyB0aGUgd2F5IHRv IGdvOyBpbiBmYWN0LCB0aGUgTVRVIGNhbiBldmVuIGJlIGhpZ2hlciBwcm92aWRlZCB0aGF0IHRo ZSBTUCBtYWtlcyBzdXJlIHRoYXQgdGhlIG5ldHdvcmsgZWxlbWVudHMgYmV0d2VlbiBDUEUgYW5k IEJvcmRlciBSZWxheXMgYWxsIHN1cHBvcnQgYSBoaWdoZXIgTVRVLiBUaGF0IHdheSBpdCBpcyBw b3NzaWJsZSB0byBzdXBwb3J0IGFuIE1UVSBvZiAxNTAwIEJ5dGVzIGZvciBJUHY2IHVzaW5nIDZS RCENCg0KSSBhbHNvIGJlbGlldmUgdGhhdCB0aGlzIGRpc2N1c3Npb24gc2hvdWxkIGJlIHBsYWNl ZCBpbnRvIGEgc2VwYXJhdGUgb3BlcmF0aW9uYWwgZG9jdW1lbnQuDQoNClJlZ2FyZHMsDQpNYXJ0 aW4NCg== From remi.despres@free.fr Mon Mar 8 08:05:45 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619B33A6A35 for ; Mon, 8 Mar 2010 08:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-u5IKATnxbM for ; Mon, 8 Mar 2010 08:05:40 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 4B2283A69F3 for ; Mon, 8 Mar 2010 08:05:38 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 29F20E081B8; Mon, 8 Mar 2010 17:05:38 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 23EBAE08127; Mon, 8 Mar 2010 17:05:36 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 8 Mar 2010 17:05:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> To: Ole Troan X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:05:45 -0000 Le 8 mars 2010 =E0 16:43, Ole Troan a =E9crit : > but you are making an argument that _every_ IPv6 link should be a = maximum of 1280 bytes. I don't think that is something 6rd should = prescribe. Only every IPv6-enabled link where it is not known, by some exterior = means, that larger MTUs will work for all possible e2e paths. In my understanding, we MUST prefer a 100% reliable connectivity to a = 15.6% gain in MTU size (1480 instead of 1280, working in typical cases = but not in all). Now, if one could prove that there is no more blackhole possibility with = 1480 than with 1280, I would be glad to withdraw my proposed amendment. But the available proof is rather that blackholes are possible with = 1480, and not with 1280. (I have not been aware of this for long, but = being now well aware, I believe there is no real choice.) Like others, I am not enthusiastic about this, and will work improve the = future, but let's be consistent in the present, and make IPv6 reliable. = =20 Cheers, RD= From acassen@freebox.fr Mon Mar 8 08:11:43 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 488AD3A6904 for ; Mon, 8 Mar 2010 08:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSKc3yl32G-a for ; Mon, 8 Mar 2010 08:11:42 -0800 (PST) Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [212.27.42.2]) by core3.amsl.com (Postfix) with ESMTP id 77D793A69E1 for ; Mon, 8 Mar 2010 08:11:39 -0800 (PST) Received: from smtp2-g21.free.fr (localhost [127.0.0.1]) by smtp2-g21.free.fr (Postfix) with ESMTP id 75F434B017B; Mon, 8 Mar 2010 17:11:39 +0100 (CET) Received: from mail.lnxos.net (lnxos.staff.proxad.net [213.228.1.83]) by smtp2-g21.free.fr (Postfix) with ESMTP id 9D5B04B007C; Mon, 8 Mar 2010 17:11:37 +0100 (CET) Received: from [192.168.200.150] (lnxos-dev [192.168.200.150]) by mail.lnxos.net (Postfix) with ESMTP id 8D9BE80EE; Mon, 8 Mar 2010 17:11:37 +0100 (CET) From: Alexandre Cassen To: Martin.Gysi@swisscom.com In-Reply-To: References: <13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com> <"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com> <"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org> <700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco.com> Content-Type: text/plain; charset="UTF-8" Organization: Freebox S.A.S Date: Mon, 08 Mar 2010 17:09:52 +0100 Message-ID: <1268064592.23619.91.camel@lnxos-dev> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: acassen@freebox.fr List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:11:43 -0000 On Mon, 2010-03-08 at 17:03 +0100, Martin.Gysi@swisscom.com wrote: > Mark > I have to support you. The MTU is not arbitrary within a service > provider network, but well engineered. 6RD is not targeted for the > open Internet, but is really intended for SP usage. Hence, an MTU > of 1480 is the way to go; +1 AGREED ! -- Alexandre From satoru.matsushima@gmail.com Mon Mar 8 08:25:47 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B128E3A69BC for ; Mon, 8 Mar 2010 08:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCjQMj4lUMfB for ; Mon, 8 Mar 2010 08:25:46 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 2D76A3A684B for ; Mon, 8 Mar 2010 08:25:45 -0800 (PST) Received: by bwz3 with SMTP id 3so1120205bwz.29 for ; Mon, 08 Mar 2010 08:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=EA9DovZ53iVfDfXOI4qmmC40Ik3rfDnimbQig8exd3M=; b=cRh7NN7j8s9cKrl/wPY4qt/X3pRN2Lh1eoSqvBN0PENIxxWvdX1CUnrFpAdoOuzUaB YAdgPVt3muPSUfFU2WKYA3fDbbKda8uzhWI/SGSh6Kxm4FTKQJpKffOmT9W026wGE7hM A6e1LEh0WoNQTjSeiCZHMDT4vzbPYlSVFOM7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=KbSCuXQQqNw5x8osk6uokiaJLXQgdkl3bgMnEkyj6XUIDco1hSiwxrjiLMLQrNLH8/ YgyCWHteJsa0RG5Gk7+7M/3VQ3k81o7G7Uu1E4zswzaw8LDTkOkOLm0ra0ZFFZBqagFj l/9ehJSAmJOYx+fVhqQ/tvrWrY8ZbrwHFwAw0= Received: by 10.204.135.153 with SMTP id n25mr5441616bkt.156.1268065543102; Mon, 08 Mar 2010 08:25:43 -0800 (PST) Received: from [192.168.170.206] (93-63-164-158.ip28.fastwebnet.it [93.63.164.158]) by mx.google.com with ESMTPS id 15sm2288258bwz.12.2010.03.08.08.25.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Mar 2010 08:25:42 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: <4B950EF1.6010304@cisco.com> Date: Tue, 9 Mar 2010 01:25:20 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7BF45F64-574C-47CB-BB82-6B64CB27CEF3@gmail.com> References: <13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> To: Mark Townsley X-Mailer: Apple Mail (2.1077) Cc: softwires Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:25:47 -0000 How about "IPv6 over IPv4 over PPP over L2TP over IPv4 over Ethernet". It is majority of FTTH broadband environment in Japan. Even though the IPv6 MTU with 6rd is stable, but it does not mean = 1480byte MTU can be kept. --satoru On 2010/03/08, at 23:51, Mark Townsley wrote: > On 3/5/10 9:37 PM, Brian E Carpenter wrote: >> On 2010-03-06 05:52, Templin, Fred L wrote: >>=20 >>> Remi, >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: R=C3=A9mi Despr=C3=A9s [mailto:remi.despres@free.fr] >>>> Sent: Friday, March 05, 2010 6:34 AM >>>> To: Templin, Fred L; Ole Troan; Brian E Carpenter >>>> Cc: softwires@ietf.org >>>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >>>>=20 >>>> Fred, Ole, Brian, >>>>=20 >>>> Le 4 mars 2010 =C3=A0 22:03, Templin, Fred L a =C3=A9crit : >>>>=20 >>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole = Troan >>>>>>=20 >>>>>> ...I can remove the sentence recommending advertising the tunnel = MTU on the LAN-side interface. or >>>>>> change it from a SHOULD to a MAY. as you say this is just to = minimize the incidence of invoking >>>>>> PMTUD. >>>>>>=20 >>>>> Removing the sentence might be best. The MAY would be OK, >>>>> but then you might need to also say something like: "(Note >>>>> that advertising the tunnel MTU on the LAN-side interface >>>>> would cause all hosts attached to the link to use a reduced >>>>> MTU even for link-local communications.)" >>>>>=20 >>>> Fred, Ole, Brian, >>>>=20 >>>> Until PMTUD is made reliable in IPv6 (btw an important objective), = all IPv6-enabled hosts should have >>>> their MTU set to 1280 to avoid IPv6 blackholes. >>>> This could in principle apply only to IPv6 packets that leave = customer sites, but as long as hosts >>>> have only one MTU parameter, it has to apply to all packets. >>>> Since typical hosts have longer default MTUs than 1280, advertising = MTU=3D1280 on links that offer >>>> paths to the global Internet appears to be the only available tool = at hand. >>>>=20 >>>> The proposal is then to replace: >>>> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined = automatically or configured >>>> directly, on the LAN side by setting the MTU option in Router = Advertisements [RFC4861] messages to >>>> the 6rd Tunnel MTU." >>>> by: >>>> "As long as the path MTU discovery has not been made reliable, a = 6rd CE SHOULD advertise on the LAN >>>> side, in the MTU option of Router Advertisements [RFC4861], an MTU = of 1280 octets . This is to >>>> prevent that longer packets that could have traversed the local 6rd = domain may be discarded, because >>>> of their size, further in the Internet because of their size. Note = that this may cause all hosts >>>> attached to the link to use a reduced MTU even for link-local = communications, IPv6 and IPv4." >>>>=20 >>> The 1280 would be disappointing; I'm sure we can do better. >>>=20 >> As has been said before, in theory there is no difference between = theory >> and practice, but in practice, there is. >>=20 >> Right now today a number of ISPs are planning to deploy 6RD, and we = have >> already seen clear evidence from 6to4 deployment that setting the MTU = to >> 1280 is a necessary evil at the moment. So I think this advice should = be >> in the specification, as a SHOULD. Otherwise we'd be misleading those >> ISPs. >>=20 > I don't think that the evidence from 6to4 is directly applicable to = 6rd as the administrative domain of deployment is quite different = between the two. Absent working automatic mechanisms, MTU is very much a = administratively controlled item today. Since a given 6rd deployment is = limited to one (or perhaps a few) administrative domain(s), the MTU = problem is generally more tractable than with 6to4 which typically has = no readily assignable responsible party to address a problem when it = occurs. >=20 > We do have evidence that 6rd works fine with a 1480 MTU over an = IPv4-enabled link with MTU of 1500. Some bugs, not necessarily = 6rd-specific, have been uncovered in the process, and fixed. That's a = good thing. Let's not throw in the towel until the game is truly over. >=20 > - Mark >=20 >=20 >> I don't like this any more than you do, from a long term perspective. >>=20 >> Brian >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From remi.despres@free.fr Mon Mar 8 08:31:29 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1BAE3A6A76 for ; Mon, 8 Mar 2010 08:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0dohbsl3LbP for ; Mon, 8 Mar 2010 08:31:29 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 4A7843A6A80 for ; Mon, 8 Mar 2010 08:31:25 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 78EDAE0821B; Mon, 8 Mar 2010 17:31:23 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id BA929E08115; Mon, 8 Mar 2010 17:31:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 8 Mar 2010 17:31:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <49CC6015-D653-4006-BBBD-82E49E099FDF@free.fr> References: <13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco.co m> To: Martin Gysi , Mark Townsley , Ole Troan X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:31:30 -0000 Martin, Mark, Ole, You may be satisfied with the conclusion at the end. Regards, RD =20 Le 8 mars 2010 =E0 17:03, a =E9crit : > Mark >=20 >=20 >> On 3/5/10 9:37 PM, Brian E Carpenter wrote: >>> On 2010-03-06 05:52, Templin, Fred L wrote: >>>=20 >>>> Remi, >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] >>>>> Sent: Friday, March 05, 2010 6:34 AM >>>>> To: Templin, Fred L; Ole Troan; Brian E Carpenter >>>>> Cc: softwires@ietf.org >>>>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >>>>>=20 >>>>> Fred, Ole, Brian, >>>>>=20 >>>>> Le 4 mars 2010 =E0 22:03, Templin, Fred L a =E9crit : >>>>>=20 >>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of = Ole Troan >>>>>>>=20 >>>>>>> ...I can remove the sentence recommending advertising the tunnel = MTU on the LAN-side interface. or >>>>>>> change it from a SHOULD to a MAY. as you say this is just to = minimize the incidence of invoking >>>>>>> PMTUD. >>>>>>>=20 >>>>>> Removing the sentence might be best. The MAY would be OK, >>>>>> but then you might need to also say something like: "(Note >>>>>> that advertising the tunnel MTU on the LAN-side interface >>>>>> would cause all hosts attached to the link to use a reduced >>>>>> MTU even for link-local communications.)" >>>>>>=20 >>>>> Fred, Ole, Brian, >>>>>=20 >>>>> Until PMTUD is made reliable in IPv6 (btw an important objective), = all IPv6-enabled hosts should have >>>>> their MTU set to 1280 to avoid IPv6 blackholes. >>>>> This could in principle apply only to IPv6 packets that leave = customer sites, but as long as hosts >>>>> have only one MTU parameter, it has to apply to all packets. >>>>> Since typical hosts have longer default MTUs than 1280, = advertising MTU=3D1280 on links that offer >>>>> paths to the global Internet appears to be the only available tool = at hand. >>>>>=20 >>>>> The proposal is then to replace: >>>>> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined = automatically or configured >>>>> directly, on the LAN side by setting the MTU option in Router = Advertisements [RFC4861] messages to >>>>> the 6rd Tunnel MTU." >>>>> by: >>>>> "As long as the path MTU discovery has not been made reliable, a = 6rd CE SHOULD advertise on the LAN >>>>> side, in the MTU option of Router Advertisements [RFC4861], an = MTU of 1280 octets . This is to >>>>> prevent that longer packets that could have traversed the local = 6rd domain may be discarded, because >>>>> of their size, further in the Internet because of their size. Note = that this may cause all hosts >>>>> attached to the link to use a reduced MTU even for link-local = communications, IPv6 and IPv4." >>>>>=20 >>>> The 1280 would be disappointing; I'm sure we can do better. >>>>=20 >>> As has been said before, in theory there is no difference between = theory >>> and practice, but in practice, there is. >>>=20 >>> Right now today a number of ISPs are planning to deploy 6RD, and we = have >>> already seen clear evidence from 6to4 deployment that setting the = MTU to >>> 1280 is a necessary evil at the moment. So I think this advice = should be >>> in the specification, as a SHOULD. Otherwise we'd be misleading = those >>> ISPs. >>>=20 >> I don't think that the evidence from 6to4 is directly applicable to = 6rd=20 >> as the administrative domain of deployment is quite different between=20= >> the two. Absent working automatic mechanisms, MTU is very much a=20 >> administratively controlled item today. Since a given 6rd deployment = is=20 >> limited to one (or perhaps a few) administrative domain(s), the MTU=20= >> problem is generally more tractable than with 6to4 which typically = has=20 >> no readily assignable responsible party to address a problem when it = occurs. >=20 >> We do have evidence that 6rd works fine with a 1480 MTU over an=20 >> IPv4-enabled link with MTU of 1500. Some bugs, not necessarily=20 >> 6rd-specific, have been uncovered in the process, and fixed. That's a=20= >> good thing. Let's not throw in the towel until the game is truly = over. >=20 >> - Mark >=20 > I have to support you. The MTU is not arbitrary within a service = provider network, but well engineered. Agreed, and that's how it has been done.=20 (BTW, congratulation on the 6rd deployment at Swisscom.) > 6RD is not targeted for the open Internet, but is really intended for = SP usage. Yes, it is internal, but if it has IPv6 traffic that goes to the global = Internet, then it needs a guaranteed path MTU. (In IPv4, packets may be fragmented in the network if sent with a size = beyond the path MTU, but not in IPv6.) > Hence, an MTU of 1480 is the way to go; in fact, the MTU can even be = higher provided that the SP makes sure that the network elements between = CPE and Border Relays all support a higher MTU. That way it is possible = to support an MTU of 1500 Bytes for IPv6 using 6RD! >=20 > I also believe that this discussion should be placed into a separate = operational document. Note that it is only the sentence about the MTU option in RAs which is a = problem, namely: "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined = automatically or configured directly, on the LAN side by setting the MTU = option in Router Advertisements [RFC4861] messages to the 6rd Tunnel = MTU." Conclusion: If this sentence is deleted, rather than improved with words = like those I proposed, the inconsistency is at least avoided. I would regret the loss of information, but would no longer have a = strongly founded objection. =20 From ichiroumakino@gmail.com Mon Mar 8 08:32:48 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B2E3A6A4D for ; Mon, 8 Mar 2010 08:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sISABW6YHqCy for ; Mon, 8 Mar 2010 08:32:47 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 658B13A6A40 for ; Mon, 8 Mar 2010 08:32:44 -0800 (PST) Received: by ewy8 with SMTP id 8so203139ewy.28 for ; Mon, 08 Mar 2010 08:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=8/hwTHuSU7UsgYBprlECXmX/TnNVoMPR5YGVckaZLcU=; b=Ee+RrFoo59dLANGIpVpIxeRUMC5LwBM+KsbzCzEW75Rs9DO2mHCVdNXkmgTv4iJTMt ys2y3x0Qw5o0XmMjHuiQkA2NoKmniLIrw/qhLZq3XUkOiTwzy4TvLbmrf9mqRhvWuEKt Eark1r4/GQr2LDN8jUNOaHYgCCzQSXfUGk1gY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=U9mUvBwWt8gOc6nZI82cnx64roi2S52C8Xjv87C6ghhgCHsHOy/MajKUxN+5fj7kz6 XhqSY+u8/eY+f5YuVys2OXtpbh8O7USoCUCH10RrnqJyDJ0zKY3juY0PVrekp8ts19KE pRBy9n2DU7qjjObfdaOUMcQHwkD9IBD+GJIJI= Received: by 10.213.1.132 with SMTP id 4mr3054297ebf.11.1268065964331; Mon, 08 Mar 2010 08:32:44 -0800 (PST) Received: from ams-otroan-87110.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id 23sm9880746eya.10.2010.03.08.08.32.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Mar 2010 08:32:43 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Ole Troan In-Reply-To: <7BF45F64-574C-47CB-BB82-6B64CB27CEF3@gmail.com> Date: Mon, 8 Mar 2010 17:33:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0982E17C-442C-4890-9EE9-B597D583058E@employees.org> References: <13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org><"1267 0 0 5876.2679.231.camel"@lnxos-dev> <4B86D8F3.9000108@gmail.com><"E1829B60731D 174 0BB 7A0626B4FAF0A6495110D3CF"@XCH-NW-01V.nw.nos.boeing.com><"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <7BF45F64-574C-47CB-BB82-6B64CB27CEF3@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1077) Cc: softwires Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 16:32:48 -0000 Satoru, > How about "IPv6 over IPv4 over PPP over L2TP over IPv4 over Ethernet". > It is majority of FTTH broadband environment in Japan. >=20 > Even though the IPv6 MTU with 6rd is stable, but it does not mean = 1480byte MTU can be kept. the draft recommends the WAN-side IPv4 MTU - 20. which covers the above = too. cheers, Ole > On 2010/03/08, at 23:51, Mark Townsley wrote: >=20 >> On 3/5/10 9:37 PM, Brian E Carpenter wrote: >>> On 2010-03-06 05:52, Templin, Fred L wrote: >>>=20 >>>> Remi, >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] >>>>> Sent: Friday, March 05, 2010 6:34 AM >>>>> To: Templin, Fred L; Ole Troan; Brian E Carpenter >>>>> Cc: softwires@ietf.org >>>>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >>>>>=20 >>>>> Fred, Ole, Brian, >>>>>=20 >>>>> Le 4 mars 2010 =E0 22:03, Templin, Fred L a =E9crit : >>>>>=20 >>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of = Ole Troan >>>>>>>=20 >>>>>>> ...I can remove the sentence recommending advertising the tunnel = MTU on the LAN-side interface. or >>>>>>> change it from a SHOULD to a MAY. as you say this is just to = minimize the incidence of invoking >>>>>>> PMTUD. >>>>>>>=20 >>>>>> Removing the sentence might be best. The MAY would be OK, >>>>>> but then you might need to also say something like: "(Note >>>>>> that advertising the tunnel MTU on the LAN-side interface >>>>>> would cause all hosts attached to the link to use a reduced >>>>>> MTU even for link-local communications.)" >>>>>>=20 >>>>> Fred, Ole, Brian, >>>>>=20 >>>>> Until PMTUD is made reliable in IPv6 (btw an important objective), = all IPv6-enabled hosts should have >>>>> their MTU set to 1280 to avoid IPv6 blackholes. >>>>> This could in principle apply only to IPv6 packets that leave = customer sites, but as long as hosts >>>>> have only one MTU parameter, it has to apply to all packets. >>>>> Since typical hosts have longer default MTUs than 1280, = advertising MTU=3D1280 on links that offer >>>>> paths to the global Internet appears to be the only available tool = at hand. >>>>>=20 >>>>> The proposal is then to replace: >>>>> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined = automatically or configured >>>>> directly, on the LAN side by setting the MTU option in Router = Advertisements [RFC4861] messages to >>>>> the 6rd Tunnel MTU." >>>>> by: >>>>> "As long as the path MTU discovery has not been made reliable, a = 6rd CE SHOULD advertise on the LAN >>>>> side, in the MTU option of Router Advertisements [RFC4861], an = MTU of 1280 octets . This is to >>>>> prevent that longer packets that could have traversed the local = 6rd domain may be discarded, because >>>>> of their size, further in the Internet because of their size. Note = that this may cause all hosts >>>>> attached to the link to use a reduced MTU even for link-local = communications, IPv6 and IPv4." >>>>>=20 >>>> The 1280 would be disappointing; I'm sure we can do better. >>>>=20 >>> As has been said before, in theory there is no difference between = theory >>> and practice, but in practice, there is. >>>=20 >>> Right now today a number of ISPs are planning to deploy 6RD, and we = have >>> already seen clear evidence from 6to4 deployment that setting the = MTU to >>> 1280 is a necessary evil at the moment. So I think this advice = should be >>> in the specification, as a SHOULD. Otherwise we'd be misleading = those >>> ISPs. >>>=20 >> I don't think that the evidence from 6to4 is directly applicable to = 6rd as the administrative domain of deployment is quite different = between the two. Absent working automatic mechanisms, MTU is very much a = administratively controlled item today. Since a given 6rd deployment is = limited to one (or perhaps a few) administrative domain(s), the MTU = problem is generally more tractable than with 6to4 which typically has = no readily assignable responsible party to address a problem when it = occurs. >>=20 >> We do have evidence that 6rd works fine with a 1480 MTU over an = IPv4-enabled link with MTU of 1500. Some bugs, not necessarily = 6rd-specific, have been uncovered in the process, and fixed. That's a = good thing. Let's not throw in the towel until the game is truly over. >>=20 >> - Mark >>=20 >>=20 >>> I don't like this any more than you do, from a long term = perspective. >>>=20 >>> Brian >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Fred.L.Templin@boeing.com Mon Mar 8 09:54:03 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50A483A69E1; Mon, 8 Mar 2010 09:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU9BjuFRuq16; Mon, 8 Mar 2010 09:54:02 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 3AA0D3A68B2; Mon, 8 Mar 2010 09:54:02 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o28Hrvd3015008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Mar 2010 11:53:57 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o28Hrvd9008020; Mon, 8 Mar 2010 11:53:57 -0600 (CST) 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 o28HrMG6006956 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 8 Mar 2010 11:53:57 -0600 (CST) 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, 8 Mar 2010 09:53:46 -0800 From: "Templin, Fred L" To: Ole Troan , "Durand, Alain" Date: Mon, 8 Mar 2010 09:53:45 -0800 Thread-Topic: [dhcwg] 6rd LC - summary of comments Thread-Index: Acq+w9spOF+m0jS9RSKLW5CHFVHWegAIOlZw Message-ID: References: <1211F394-5991-48F5-8A0C-C458478758DD@employees.org> In-Reply-To: <1211F394-5991-48F5-8A0C-C458478758DD@employees.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 Cc: softwires , DHC WG Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 17:54:03 -0000 Ole, > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Ole Troan > Sent: Monday, March 08, 2010 5:33 AM > To: Durand, Alain > Cc: softwires; DHC WG; David Ward > Subject: [dhcwg] 6rd LC - summary of comments >=20 > all, >=20 > thank you very much for good and constructive comments! > I've tried to summarize the comments received and the changes made below. >=20 > cheers, > Ole >=20 >=20 >=20 > ** Include option Parameter Request List option for the DHCPv4 option: > New text: > The CE MUST include a Parameter Request List Option target=3D"RFC2132"> for the OPTION_6RD. Because the > OPTION_6RD contains one IPv4MaskLen/6rdPrefixLen/6rdPrefix > block, and because DHCP cannot convey more than one instance > of an option, OPTION_6RD is limited to provision at most a > single 6rd domain. Provisioning of a CE router connected to > multiple 6rd domains is outside the scope of this protocol > specification. >=20 > =3D> Accepted >=20 > ** Loop avoidance > Suggestion was to adopt solution in > draft-nakibly-v6ops-tunnel-loops. Issues with scalability and > checking of "well-known" bits in ISATAP addresses. >=20 > =3D> Keep existing text. >=20 > ** MTU > There are well documented issues with tunnels and MTU. There are > issues with anycast and fragmentation. The draft references the > existing mechanisms for tunnelling and MTU, and recommend following > existing practice. Since the mechanism is contained within a single > SP network, one can assume that the MTU is well managed. Just as in > an MPLS network. >=20 > =3D> Keep existing text. Should the working group start a separate > effort for a more general solution to MTU issues? If 6rd used SEAL, the CE would be able to set a much larger tunnel MTU (say, 64KB). Then, end systems in customer sites would be able to automatically discover and utilize larger MTUs as long as the SP network links can support them. (And no; I am *not* requiring the CE or BR devices to support segmentation and reassembly unless they want to.) But, SEAL is about more than just MTU - it also includes mechanism to detect and defeat IPv4 source address spoofing. Since the 6rd checks are useless if IPv4 source address spoofing is possible, it is necessary to consider the domain of applicability to determine whether anti- spoofing mitigations are needed. SEAL provides such a mitigation. > ** Use of anycast > There are issues with the use of anycast. The draft > supports the use of unicast BR addresses too. The issues around > ECMP, fragmentation and ICMP messages ending up on the wrong BR are > to some extent operational. It depends on the network having a well > maintained MTU as recommended in the draft. ECMP should be done on > a per flow basis not on a per packet. >=20 > =3D> Keep existing text. I have shown that there is a possibility for data corruption for BR use of anycast source address - to the point that the BRs MUST ensure that no fragmentation will occur when anycast source is used. That means that the BR MUST set DF=3D1 if it uses an anycast source address. The document needs to say that somewhere. > ** Analysis of domain of applicability > The draft already sets the context of the solution to within an SP > network. More detail and operational scenarios might be more > suitable to a 6rd operational document. >=20 > =3D> No action. I disagree; there are operational limitations that would limit applicability to only tightly-managed SP network scenarios as I have pointed out in my messages. The document therefore requires an applicability statement, as has been required for other "transition" mechanisms. Fred fred.l.templin@boeing.com > ** IPv4 lease time in case of PPP > What lease-time should be used on the LAN-side in IPv6 RAs when the > IPv4 WAN side address is aquired via IPCP? >=20 > Proposed new text: >=20 > 6rd IPv6 address assignment and hence the IPv6 service itself > is tied to the IPv4 address lease, thus the 6rd service is also > tied to this in terms of authorization, accounting, etc. For > example, the 6rd delegated prefix has the same lifetime as its > associated IPv4 address. The prefix lifetimes advertised in > Router Advertisements or used by DHCP on the CE LAN side MUST be > equal to or shorter than the IPv4 address lease time. If the > IPv4 lease time is not known, the lifetime of the 6rd delegated > prefix SHOULD follow the defaults specified in target=3D"RFC4861">. >=20 > =3D> Accepted. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From ichiroumakino@gmail.com Mon Mar 8 11:07:19 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8903A6AE1; Mon, 8 Mar 2010 11:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kElQODM3gClC; Mon, 8 Mar 2010 11:07:18 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id E6BF83A6A83; Mon, 8 Mar 2010 11:07:17 -0800 (PST) Received: by ewy8 with SMTP id 8so308193ewy.28 for ; Mon, 08 Mar 2010 11:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=aylkCVgfqZI42I/F60gdh9XKPV6WAZNpFPp8VzBrZUo=; b=pOdhqKPZkSWqOrGMc3NZsB6h91ksTt1FIelS0iAnGBH0Zji4g2iBZDAxlu4s1Y8TmJ 2dZR8jS5Jw9A325S9dc7nCxq7KOcCHJOyhhG41cahtxsTQQOEQ6X9+sTdoIvd2aY+FhG I8L59hOW2WsoNKV0GvvRJBPF/h9lj3nvsV8Zk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=jZBjZ4D1YhFBXYeheQZBmLSVhSezg7uBs6tUEEC6anpMCLTIMnXwrkIKb3jqWn9x5B XxzWWV/M+TxgdYU7uW7UJlCTFMZIuUbl7XNv5scDK9MGxby99k3dZLU3byCBWMj3SqYj 5Nq6bymct6QboELrdZQeNfhZKvc0/EBAAmCs0= Received: by 10.213.104.93 with SMTP id n29mr3232506ebo.6.1268075238424; Mon, 08 Mar 2010 11:07:18 -0800 (PST) Received: from ams-otroan-87110.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id 23sm10153487eya.10.2010.03.08.11.07.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Mar 2010 11:07:17 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 8 Mar 2010 20:07:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1211F394-5991-48F5-8A0C-C458478758DD@employees.org> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) Cc: "Durand, Alain" , softwires , DHC WG Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 19:07:19 -0000 Fred, [...] >> ** MTU >> There are well documented issues with tunnels and MTU. There are >> issues with anycast and fragmentation. The draft references the >> existing mechanisms for tunnelling and MTU, and recommend following >> existing practice. Since the mechanism is contained within a single >> SP network, one can assume that the MTU is well managed. Just as in >> an MPLS network. >>=20 >> =3D> Keep existing text. Should the working group start a separate >> effort for a more general solution to MTU issues? >=20 > If 6rd used SEAL, the CE would be able to set a much > larger tunnel MTU (say, 64KB). Then, end systems in > customer sites would be able to automatically discover > and utilize larger MTUs as long as the SP network links > can support them. (And no; I am *not* requiring the CE > or BR devices to support segmentation and reassembly > unless they want to.) not quite sure what the purpose of a 64KB MTU on the tunnel link would = be, but sure a 1500 byte MTU would have been nice. I'm unsure of the = consequences of reassembly/fragmentation on the tunnel end-points. so = far experience has shown that to be 'harmful'. would SEAL be any = different? 6rd is a patch to 6to4. one goal of 6rd was to be able to ride on an = existing 6to4 implementation with only small changes. SEAL would not be = that.=20 I'm fine with working on more general solutions to the MTU problem which = may then apply to any tunnel. I would not want to accept SEAL as that = solution without much more analysis. > But, SEAL is about more than just MTU - it also includes > mechanism to detect and defeat IPv4 source address spoofing. > Since the 6rd checks are useless if IPv4 source address > spoofing is possible, it is necessary to consider the > domain of applicability to determine whether anti- > spoofing mitigations are needed. SEAL provides such > a mitigation. I missed that part of SEAL. pointer? >> ** Use of anycast >> There are issues with the use of anycast. The draft >> supports the use of unicast BR addresses too. The issues around >> ECMP, fragmentation and ICMP messages ending up on the wrong BR are >> to some extent operational. It depends on the network having a well >> maintained MTU as recommended in the draft. ECMP should be done on >> a per flow basis not on a per packet. >>=20 >> =3D> Keep existing text. >=20 > I have shown that there is a possibility for data corruption > for BR use of anycast source address - to the point that the > BRs MUST ensure that no fragmentation will occur when anycast > source is used. That means that the BR MUST set DF=3D1 if it > uses an anycast source address. The document needs to say > that somewhere. it follows the rules and setting of the DF bit as specified in RFC4213. >> ** Analysis of domain of applicability >> The draft already sets the context of the solution to within an SP >> network. More detail and operational scenarios might be more >> suitable to a 6rd operational document. >>=20 >> =3D> No action. >=20 > I disagree; there are operational limitations that would > limit applicability to only tightly-managed SP network > scenarios as I have pointed out in my messages. The > document therefore requires an applicability statement, > as has been required for other "transition" mechanisms. in the introduction we have: 6rd specifies a protocol mechanism to deploy IPv6 to sites via a Service Provider's (SP's) IPv4 network. It builds on 6to4 [ RFC3056], with the key differentiator that it utilizes an SP's own = IPv6 address prefix rather than a well known prefix (2002::/16). By using the SP's IPv6 prefix, the operational domain of 6rd is limited to the SP network and under its direct control. =46rom the perspective of customer sites and the IPv6 Internet at large, the IPv6 service provided is equivalent to native IPv6. I'm not sure what more needs to be said. at least not in the basic = protocol spec. (which I originally wanted to be a single page saying: = this is 6to4 with a SP prefix instead of 2002::/16). :-) cheers, Ole= From Fred.L.Templin@boeing.com Mon Mar 8 12:00:53 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8503A6BC9; Mon, 8 Mar 2010 12:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCY5buLGYW76; Mon, 8 Mar 2010 12:00:48 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 175523A6BC8; Mon, 8 Mar 2010 12:00:30 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o28K0NW8006488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Mar 2010 12:00:24 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o28K0MDM017765; Mon, 8 Mar 2010 14:00:22 -0600 (CST) 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 o28K0KLc017634 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 8 Mar 2010 14:00:21 -0600 (CST) 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, 8 Mar 2010 12:00:20 -0800 From: "Templin, Fred L" To: Ole Troan Date: Mon, 8 Mar 2010 12:00:19 -0800 Thread-Topic: [dhcwg] 6rd LC - summary of comments Thread-Index: Acq+8rrxmBcca5CPRj65Mp6fxvgRyQAAQf/g Message-ID: References: <1211F394-5991-48 F5-8A0C-C458478758DD@employees.org> 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: "Durand, Alain" , softwires , DHC WG Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 20:00:53 -0000 Ole, > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of= Ole Troan > Sent: Monday, March 08, 2010 11:08 AM > To: Templin, Fred L > Cc: Durand, Alain; softwires; David Ward; DHC WG > Subject: Re: [dhcwg] 6rd LC - summary of comments >=20 > Fred, >=20 > [...] >=20 > >> ** MTU > >> There are well documented issues with tunnels and MTU. There are > >> issues with anycast and fragmentation. The draft references the > >> existing mechanisms for tunnelling and MTU, and recommend following > >> existing practice. Since the mechanism is contained within a single > >> SP network, one can assume that the MTU is well managed. Just as in > >> an MPLS network. > >> > >> =3D> Keep existing text. Should the working group start a separate > >> effort for a more general solution to MTU issues? > > > > If 6rd used SEAL, the CE would be able to set a much > > larger tunnel MTU (say, 64KB). Then, end systems in > > customer sites would be able to automatically discover > > and utilize larger MTUs as long as the SP network links > > can support them. (And no; I am *not* requiring the CE > > or BR devices to support segmentation and reassembly > > unless they want to.) >=20 > not quite sure what the purpose of a 64KB MTU on the tunnel link would be= , but sure a 1500 byte MTU > would have been nice. The 64KB MTU is to admit packets into the tunnel without any pre-conceived notion of an initial size restriction. Any size restrictions will then be discovered dynamically, with a reduced size conveyed back to the original source if necessary. > I'm unsure of the consequences of reassembly/fragmentation on the tunnel = end- > points. so far experience has shown that to be 'harmful'. would SEAL be a= ny different? With SEAL, the tunnel egress can choose to reassemble as much or as little as it likes, with the limiting case being that the egress performs no reassembly at all. In that case, SEAL still provides value since the tunnel will still be able to support larger MTUs (e.g., 9KB) as long as all links in the SP network between ingress->egress support an MTU at least that large. In the case that the egress decides to support some reassembly (e.g., up to 1500 bytes), SEAL avoids the issues incurred for IP fragmentation and reassembly since it uses a (much) larger ID to unambiguously associate fragments of the same packet. SEAL also has a way of gracefully "backing down" if reassembly becomes problematic due to excessive congestion so that "loss unit smaller than retransmission unit" would be a short-lived transient condition if it ever occurs in operational practice (which I am told should be rare). > 6rd is a patch to 6to4. one goal of 6rd was to be able to ride on an exis= ting 6to4 implementation > with only small changes. It is still my view that 6rd "closes the gap" between 6to4 and ISATAP. Indeed, all three are implemented within the same *.c module in the linux kernel. > SEAL would not be that. I have working code for RFC5320 with full segmentation and reassembly, but tunnel endpoints that do not wish to support reassembly can omit ~90% of that. =20 > I'm fine with working on more general solutions to the MTU problem which = may then apply to any > tunnel. I would not want to accept SEAL as that solution without much mor= e analysis. Then, let's get on with the analysis! > > But, SEAL is about more than just MTU - it also includes > > mechanism to detect and defeat IPv4 source address spoofing. > > Since the 6rd checks are useless if IPv4 source address > > spoofing is possible, it is necessary to consider the > > domain of applicability to determine whether anti- > > spoofing mitigations are needed. SEAL provides such > > a mitigation. >=20 > I missed that part of SEAL. pointer? (draft-templin-intarea-seal), Section 4.6. > >> ** Use of anycast > >> There are issues with the use of anycast. The draft > >> supports the use of unicast BR addresses too. The issues around > >> ECMP, fragmentation and ICMP messages ending up on the wrong BR are > >> to some extent operational. It depends on the network having a well > >> maintained MTU as recommended in the draft. ECMP should be done on > >> a per flow basis not on a per packet. > >> > >> =3D> Keep existing text. > > > > I have shown that there is a possibility for data corruption > > for BR use of anycast source address - to the point that the > > BRs MUST ensure that no fragmentation will occur when anycast > > source is used. That means that the BR MUST set DF=3D1 if it > > uses an anycast source address. The document needs to say > > that somewhere. >=20 > it follows the rules and setting of the DF bit as specified in RFC4213. RFC4213 does not examine the implications of setting the DF bit in the presence of anycast source address; 6rd must. =20 > >> ** Analysis of domain of applicability > >> The draft already sets the context of the solution to within an SP > >> network. More detail and operational scenarios might be more > >> suitable to a 6rd operational document. > >> > >> =3D> No action. > > > > I disagree; there are operational limitations that would > > limit applicability to only tightly-managed SP network > > scenarios as I have pointed out in my messages. The > > document therefore requires an applicability statement, > > as has been required for other "transition" mechanisms. >=20 > in the introduction we have: >=20 > 6rd specifies a protocol mechanism to deploy IPv6 to sites via a > Service Provider's (SP's) IPv4 network. It builds on 6to4 [ > RFC3056], with the key differentiator that it utilizes an SP's own IP= v6 address > prefix rather than a well known prefix (2002::/16). By using the > SP's IPv6 prefix, the operational domain of 6rd is limited to the SP > network and under its direct control. From the perspective of > customer sites and the IPv6 Internet at large, the IPv6 service > provided is equivalent to native IPv6. >=20 > I'm not sure what more needs to be said. at least not in the basic protoc= ol spec. (which I originally > wanted to be a single page saying: this is 6to4 with a SP prefix instead = of 2002::/16). :-) >From a few mails back, here are the items which I believe bear specific mention in an applicability statement: "During the NGTRANS days, the ISATAP team was strongly required to include a "Domain of Applicability" statement, and I think the same should be required of 6rd. I see a number of aspects of 6rd that IMHO would limit its applicability, including: =20 - IPv6 prefix tied to IPv4 address (renumbering implications) - potential black holes when ICMPs can't be translated - provider-aggregated addressing only (no provider-independent) - not compatible with multihoming via a single, stable IPv6 prefix - not compatible with traffic engineering (i.e., CE can't select specific BRs) - interactions with load balancing; ECMP within provider network - MTU clamping exposes degenerate MTUs to the customer network and doesn't allow for automatic discovery of larger MTUs - requires operators to exercise tight controls on link MTUs - requires operators to exercise tight controls on ICMP generation and ICMP filtering" Thanks - Fred fred.l.templin@boeing.com > cheers, > Ole > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From townsley@cisco.com Mon Mar 8 12:46:29 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378BD3A69E2 for ; Mon, 8 Mar 2010 12:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiFoluhg2KLh for ; Mon, 8 Mar 2010 12:46:28 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 556AB3A69AB for ; Mon, 8 Mar 2010 12:46:28 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABLxlEurR7H+/2dsb2JhbACbMHOiHJgphHgE X-IronPort-AV: E=Sophos;i="4.49,604,1262563200"; d="scan'208";a="493533460" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 08 Mar 2010 20:46:24 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o28KkOqT006319 for ; Mon, 8 Mar 2010 20:46:24 GMT Received: from ams-townsley-87110.cisco.com (ams-townsley-87110.cisco.com [10.55.233.235]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o28KkNY11213 for ; Mon, 8 Mar 2010 12:46:23 -0800 (PST) Message-ID: <4B95621E.9010003@cisco.com> Date: Mon, 08 Mar 2010 21:46:22 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: softwires@ietf.org References: <1211F394-5991-48 F5-8A0C-C458478758DD@employees.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 20:46:29 -0000 On 3/8/10 9:00 PM, Templin, Fred L wrote >>> But, SEAL is about more than just MTU - it also includes >>> mechanism to detect and defeat IPv4 source address spoofing. >>> Since the 6rd checks are useless if IPv4 source address >>> spoofing is possible, 6rd aims to be as good as the IPv4 deployment it rides upon in terms of anti-spoofing, no better. >>> it is necessary to consider the >>> domain of applicability to determine whether anti- >>> spoofing mitigations are needed. SEAL provides such >>> a mitigation. >>> >> I missed that part of SEAL. pointer? >> > (draft-templin-intarea-seal), Section 4.6. > Source address anti-spoofing measures (for v4 and v6) are within the scope of the SAVI WG. - Mark From ichiroumakino@gmail.com Mon Mar 8 12:56:31 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD9E3A6953; Mon, 8 Mar 2010 12:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edVEdBNn20pG; Mon, 8 Mar 2010 12:56:30 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 1F5063A6889; Mon, 8 Mar 2010 12:56:29 -0800 (PST) Received: by ewy8 with SMTP id 8so365905ewy.28 for ; Mon, 08 Mar 2010 12:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=PlqgcZq3geXvxU+kSMGtn/48qivOVMooywuKISEJ0xk=; b=d1quZmoT7VzBWisf2K9kZX7HipxLihRuXb8cYNc5Nq6TK3Gs+bhJc1XoW5sYz2lUaX 2HpfhOtbrpByq6lopkU5il7OCg6t+1jsCB60EZdhNcDLmj7J6JPMPxKTdvDP6aG20/qh AehqAddz10b2R4mS6AcAJvNO7sBKdfv1vxDQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=s6qSNVYv/mkPntEm0Cm2wH2YnQrMKn89IKQr/oxa79faN3Tfi3i+piPBCYApCqOh3x 5Zy6JE2YFYySd6FqwBOTG7LR/zjKZr3VPUa1EI87afDcTs0o1RXgWYjmOw15vpALeVea xBD1YrWmY6bo8Wq8+8cHln2Gh0YixU/25WR0w= Received: by 10.213.52.17 with SMTP id f17mr3335940ebg.69.1268081789208; Mon, 08 Mar 2010 12:56:29 -0800 (PST) Received: from ams-otroan-87110.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id 16sm2544332ewy.7.2010.03.08.12.56.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Mar 2010 12:56:28 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 8 Mar 2010 21:56:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <90023DF9-4324-4E15-ACFA-F9E9D369F247@employees.org> References: <1211F394-5991-48 F5-8A0C-C458478758DD@employees.org> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) Cc: "Durand, Alain" , softwires , DHC WG Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 20:56:32 -0000 Fred, [...] >>> If 6rd used SEAL, the CE would be able to set a much >>> larger tunnel MTU (say, 64KB). Then, end systems in >>> customer sites would be able to automatically discover >>> and utilize larger MTUs as long as the SP network links >>> can support them. (And no; I am *not* requiring the CE >>> or BR devices to support segmentation and reassembly >>> unless they want to.) >>=20 >> not quite sure what the purpose of a 64KB MTU on the tunnel link = would be, but sure a 1500 byte MTU >> would have been nice. >=20 > The 64KB MTU is to admit packets into the tunnel without any > pre-conceived notion of an initial size restriction. Any size > restrictions will then be discovered dynamically, with a > reduced size conveyed back to the original source if necessary. >=20 >> I'm unsure of the consequences of reassembly/fragmentation on the = tunnel end- >> points. so far experience has shown that to be 'harmful'. would SEAL = be any different? >=20 > With SEAL, the tunnel egress can choose to reassemble as much > or as little as it likes, with the limiting case being that the > egress performs no reassembly at all. In that case, SEAL still > provides value since the tunnel will still be able to support > larger MTUs (e.g., 9KB) as long as all links in the SP network > between ingress->egress support an MTU at least that large. >=20 > In the case that the egress decides to support some reassembly > (e.g., up to 1500 bytes), SEAL avoids the issues incurred for > IP fragmentation and reassembly since it uses a (much) larger > ID to unambiguously associate fragments of the same packet. > SEAL also has a way of gracefully "backing down" if reassembly > becomes problematic due to excessive congestion so that "loss > unit smaller than retransmission unit" would be a short-lived > transient condition if it ever occurs in operational practice > (which I am told should be rare). >=20 >> 6rd is a patch to 6to4. one goal of 6rd was to be able to ride on an = existing 6to4 implementation >> with only small changes. >=20 > It is still my view that 6rd "closes the gap" between 6to4 > and ISATAP. Indeed, all three are implemented within the > same *.c module in the linux kernel. OK, so we don't quite see that the same then. I see ISATAP and RFC2529 = as siblings. and 6to4 and 6rd together. all with automatic tunnels from = rfc1933 as their common ancestor. anyway, not particularly important. >=20 >> SEAL would not be that. >=20 > I have working code for RFC5320 with full segmentation and > reassembly, but tunnel endpoints that do not wish to support > reassembly can omit ~90% of that. >=20 >> I'm fine with working on more general solutions to the MTU problem = which may then apply to any >> tunnel. I would not want to accept SEAL as that solution without much = more analysis. >=20 > Then, let's get on with the analysis! sure, but let's do that on a separate thread. I do not want to make 6rd = dependent on SEAL at this point. >>> But, SEAL is about more than just MTU - it also includes >>> mechanism to detect and defeat IPv4 source address spoofing. >>> Since the 6rd checks are useless if IPv4 source address >>> spoofing is possible, it is necessary to consider the >>> domain of applicability to determine whether anti- >>> spoofing mitigations are needed. SEAL provides such >>> a mitigation. >>=20 >> I missed that part of SEAL. pointer? >=20 > (draft-templin-intarea-seal), Section 4.6. OK, still didn't get it. >>>> ** Use of anycast >>>> There are issues with the use of anycast. The draft >>>> supports the use of unicast BR addresses too. The issues around >>>> ECMP, fragmentation and ICMP messages ending up on the wrong BR = are >>>> to some extent operational. It depends on the network having a = well >>>> maintained MTU as recommended in the draft. ECMP should be done on >>>> a per flow basis not on a per packet. >>>>=20 >>>> =3D> Keep existing text. >>>=20 >>> I have shown that there is a possibility for data corruption >>> for BR use of anycast source address - to the point that the >>> BRs MUST ensure that no fragmentation will occur when anycast >>> source is used. That means that the BR MUST set DF=3D1 if it >>> uses an anycast source address. The document needs to say >>> that somewhere. >>=20 >> it follows the rules and setting of the DF bit as specified in = RFC4213. >=20 > RFC4213 does not examine the implications of setting the DF > bit in the presence of anycast source address; 6rd must. OK, what about:=20 "The use of an anycast source address may lead to any ICMP error message = generated on the path being sent to a different BR. Therefore using = dynamic tunnel MTU [section 3.2.2, RFC4213] is subject to IPv4 Path MTU = blackholes." >>>> ** Analysis of domain of applicability >>>> The draft already sets the context of the solution to within an SP >>>> network. More detail and operational scenarios might be more >>>> suitable to a 6rd operational document. >>>>=20 >>>> =3D> No action. >>>=20 >>> I disagree; there are operational limitations that would >>> limit applicability to only tightly-managed SP network >>> scenarios as I have pointed out in my messages. The >>> document therefore requires an applicability statement, >>> as has been required for other "transition" mechanisms. >>=20 >> in the introduction we have: >>=20 >> 6rd specifies a protocol mechanism to deploy IPv6 to sites via a >> Service Provider's (SP's) IPv4 network. It builds on 6to4 [ >> RFC3056], with the key differentiator that it utilizes an SP's own = IPv6 address >> prefix rather than a well known prefix (2002::/16). By using the >> SP's IPv6 prefix, the operational domain of 6rd is limited to the = SP >> network and under its direct control. =46rom the perspective of >> customer sites and the IPv6 Internet at large, the IPv6 service >> provided is equivalent to native IPv6. >>=20 >> I'm not sure what more needs to be said. at least not in the basic = protocol spec. (which I originally >> wanted to be a single page saying: this is 6to4 with a SP prefix = instead of 2002::/16). :-) >=20 > =46rom a few mails back, here are the items which I believe bear > specific mention in an applicability statement: >=20 > "During the NGTRANS days, the ISATAP team was strongly required > to include a "Domain of Applicability" statement, and I think > the same should be required of 6rd. I see a number of aspects > of 6rd that IMHO would limit its applicability, including: >=20 > - IPv6 prefix tied to IPv4 address (renumbering implications) > - potential black holes when ICMPs can't be translated > - provider-aggregated addressing only (no provider-independent) > - not compatible with multihoming via a single, stable IPv6 prefix > - not compatible with traffic engineering (i.e., CE can't select > specific BRs) > - interactions with load balancing; ECMP within provider network > - MTU clamping exposes degenerate MTUs to the customer network > and doesn't allow for automatic discovery of larger MTUs > - requires operators to exercise tight controls on link MTUs > - requires operators to exercise tight controls on ICMP > generation and ICMP filtering" as in: http://tools.ietf.org/html/rfc5214#section-4 we have covered that reasonably well already. I think some of those = issues could well be covered in a deployment document though. cheers, Ole From Fred.L.Templin@boeing.com Mon Mar 8 13:20:49 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8893A6A18 for ; Mon, 8 Mar 2010 13:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRK3G4QAmGAT for ; Mon, 8 Mar 2010 13:20:45 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 91B233A6A4B for ; Mon, 8 Mar 2010 13:20:25 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o28LKOix024829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Mar 2010 13:20:25 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o28LKO7e026941; Mon, 8 Mar 2010 15:20:24 -0600 (CST) 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 o28LKCPT026532 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 8 Mar 2010 15:20:23 -0600 (CST) 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; Mon, 8 Mar 2010 13:20:19 -0800 From: "Templin, Fred L" To: Mark Townsley , "softwires@ietf.org" Date: Mon, 8 Mar 2010 13:20:18 -0800 Thread-Topic: [Softwires] [dhcwg] 6rd LC - summary of comments Thread-Index: Acq/AI/coRotoaROS8+DDbzZ01NmogAA8Lmw Message-ID: References: <1211F394-5991-48 F5-8A0C-C458478758DD@employees.org> <4B95621E.9010003@cisco.com> In-Reply-To: <4B95621E.9010003@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 Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 21:20:50 -0000 Mark, > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Mark Townsley > Sent: Monday, March 08, 2010 12:46 PM > To: softwires@ietf.org > Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments >=20 > On 3/8/10 9:00 PM, Templin, Fred L wrote > >>> But, SEAL is about more than just MTU - it also includes > >>> mechanism to detect and defeat IPv4 source address spoofing. > >>> Since the 6rd checks are useless if IPv4 source address > >>> spoofing is possible, > 6rd aims to be as good as the IPv4 deployment it rides upon in terms of > anti-spoofing, no better. > >>> it is necessary to consider the > >>> domain of applicability to determine whether anti- > >>> spoofing mitigations are needed. SEAL provides such > >>> a mitigation. > >>> > >> I missed that part of SEAL. pointer? > >> > > (draft-templin-intarea-seal), Section 4.6. > > > Source address anti-spoofing measures (for v4 and v6) are within the > scope of the SAVI WG. I didn't know about that, but I'm not sure I see your point. What I have done in SEAL doesn't bear any resemblance to what I saw over in SAVI, yet it solves a real problem for tunneling in environments where source address spoofing is possible. If you want to broaden the domain of applicability for 6rd, then I think you should take a look at SEAL. On the other hand, if you think 6rd should only be deployed in environments where IPv4 source address spoofing is not possible, then there should be an applicability statement saying so. Fred fred.l.templin@boeing.com =20 > - Mark > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Fred.L.Templin@boeing.com Mon Mar 8 13:39:10 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B283A69C6; Mon, 8 Mar 2010 13:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp1BqeUKfBsD; Mon, 8 Mar 2010 13:39:06 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 122383A69DE; Mon, 8 Mar 2010 13:39:06 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o28Ld2es005476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Mar 2010 15:39:03 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o28Ld2cM001160; Mon, 8 Mar 2010 13:39:02 -0800 (PST) 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 o28Ld2sS001153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 8 Mar 2010 13:39:02 -0800 (PST) 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, 8 Mar 2010 13:39:02 -0800 From: "Templin, Fred L" To: Ole Troan Date: Mon, 8 Mar 2010 13:39:00 -0800 Thread-Topic: [dhcwg] 6rd LC - summary of comments Thread-Index: Acq/AdgA7pAjWVFrRj6tskbMQKRMzwAA1jYA Message-ID: References: <1211F394-5991-48 F5-8A0C-C458478758DD@employees.org> <90023DF9-4324-4E15-ACFA-F9E9D369F247@employees.org> In-Reply-To: <90023DF9-4324-4E15-ACFA-F9E9D369F247@employees.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 Cc: "Durand, Alain" , softwires , DHC WG Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 21:39:10 -0000 Ole, > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan > Sent: Monday, March 08, 2010 12:57 PM > To: Templin, Fred L > Cc: Durand, Alain; softwires; David Ward; DHC WG > Subject: Re: [dhcwg] 6rd LC - summary of comments >=20 > Fred, >=20 > [...] >=20 > >>> If 6rd used SEAL, the CE would be able to set a much > >>> larger tunnel MTU (say, 64KB). Then, end systems in > >>> customer sites would be able to automatically discover > >>> and utilize larger MTUs as long as the SP network links > >>> can support them. (And no; I am *not* requiring the CE > >>> or BR devices to support segmentation and reassembly > >>> unless they want to.) > >> > >> not quite sure what the purpose of a 64KB MTU on the tunnel link would= be, but sure a 1500 byte > MTU > >> would have been nice. > > > > The 64KB MTU is to admit packets into the tunnel without any > > pre-conceived notion of an initial size restriction. Any size > > restrictions will then be discovered dynamically, with a > > reduced size conveyed back to the original source if necessary. > > > >> I'm unsure of the consequences of reassembly/fragmentation on the tunn= el end- > >> points. so far experience has shown that to be 'harmful'. would SEAL b= e any different? > > > > With SEAL, the tunnel egress can choose to reassemble as much > > or as little as it likes, with the limiting case being that the > > egress performs no reassembly at all. In that case, SEAL still > > provides value since the tunnel will still be able to support > > larger MTUs (e.g., 9KB) as long as all links in the SP network > > between ingress->egress support an MTU at least that large. > > > > In the case that the egress decides to support some reassembly > > (e.g., up to 1500 bytes), SEAL avoids the issues incurred for > > IP fragmentation and reassembly since it uses a (much) larger > > ID to unambiguously associate fragments of the same packet. > > SEAL also has a way of gracefully "backing down" if reassembly > > becomes problematic due to excessive congestion so that "loss > > unit smaller than retransmission unit" would be a short-lived > > transient condition if it ever occurs in operational practice > > (which I am told should be rare). > > > >> 6rd is a patch to 6to4. one goal of 6rd was to be able to ride on an e= xisting 6to4 implementation > >> with only small changes. > > > > It is still my view that 6rd "closes the gap" between 6to4 > > and ISATAP. Indeed, all three are implemented within the > > same *.c module in the linux kernel. >=20 > OK, so we don't quite see that the same then. I see ISATAP and RFC2529 as= siblings. and 6to4 and 6rd > together. all with automatic tunnels from rfc1933 as their common ancesto= r. anyway, not particularly > important. The more accurate comparison is between 6rd and VET rather than 6rd and ISATAP. Both 6rd and VET work within a closed domain (which VET chooses to call an "enterprise" or "site", but for which an ISP SP network is simply one use case example) and both 6rd and VET deal with discovery and utilization of exit routers that can reach networks outside of the SP network domain. 6rd CE routers fit the same role as VET EBRs, and 6rd BRs fit the same role as VET EBGs. In many ways, 6rd is just VET with a number of shortcuts taken (e.g., anycast, stateless PD etc.). > >> SEAL would not be that. > > > > I have working code for RFC5320 with full segmentation and > > reassembly, but tunnel endpoints that do not wish to support > > reassembly can omit ~90% of that. > > > >> I'm fine with working on more general solutions to the MTU problem whi= ch may then apply to any > >> tunnel. I would not want to accept SEAL as that solution without much = more analysis. > > > > Then, let's get on with the analysis! >=20 > sure, but let's do that on a separate thread. I do not want to make 6rd d= ependent on SEAL at this > point. This gets back again to the crux question. If 6rd can go forward with robust MTU handling in the first iteration it would greatly reduce the pressure for ISPs to upgrade their entire infrastructure to native IPv6 - perhaps even indefinitely. So, why not get it right the first time? > >>> But, SEAL is about more than just MTU - it also includes > >>> mechanism to detect and defeat IPv4 source address spoofing. > >>> Since the 6rd checks are useless if IPv4 source address > >>> spoofing is possible, it is necessary to consider the > >>> domain of applicability to determine whether anti- > >>> spoofing mitigations are needed. SEAL provides such > >>> a mitigation. > >> > >> I missed that part of SEAL. pointer? > > > > (draft-templin-intarea-seal), Section 4.6. >=20 > OK, still didn't get it. Can you be more specific? Did you not understand what was written, or do you think there is something wrong with it? > >>>> ** Use of anycast > >>>> There are issues with the use of anycast. The draft > >>>> supports the use of unicast BR addresses too. The issues around > >>>> ECMP, fragmentation and ICMP messages ending up on the wrong BR are > >>>> to some extent operational. It depends on the network having a well > >>>> maintained MTU as recommended in the draft. ECMP should be done on > >>>> a per flow basis not on a per packet. > >>>> > >>>> =3D> Keep existing text. > >>> > >>> I have shown that there is a possibility for data corruption > >>> for BR use of anycast source address - to the point that the > >>> BRs MUST ensure that no fragmentation will occur when anycast > >>> source is used. That means that the BR MUST set DF=3D1 if it > >>> uses an anycast source address. The document needs to say > >>> that somewhere. > >> > >> it follows the rules and setting of the DF bit as specified in RFC4213= . > > > > RFC4213 does not examine the implications of setting the DF > > bit in the presence of anycast source address; 6rd must. >=20 > OK, what about: > "The use of an anycast source address may lead to any ICMP error message = generated on the path being > sent to a different BR. Therefore using dynamic tunnel MTU [section 3.2.2= , RFC4213] is subject to > IPv4 Path MTU blackholes." I have told you several times what is wrong with anycast source and DF=3D0. If you want to remain silent and allow open a potential for undetected data corruption, that seems like a serious omission. > >>>> ** Analysis of domain of applicability > >>>> The draft already sets the context of the solution to within an SP > >>>> network. More detail and operational scenarios might be more > >>>> suitable to a 6rd operational document. > >>>> > >>>> =3D> No action. > >>> > >>> I disagree; there are operational limitations that would > >>> limit applicability to only tightly-managed SP network > >>> scenarios as I have pointed out in my messages. The > >>> document therefore requires an applicability statement, > >>> as has been required for other "transition" mechanisms. > >> > >> in the introduction we have: > >> > >> 6rd specifies a protocol mechanism to deploy IPv6 to sites via a > >> Service Provider's (SP's) IPv4 network. It builds on 6to4 [ > >> RFC3056], with the key differentiator that it utilizes an SP's own = IPv6 address > >> prefix rather than a well known prefix (2002::/16). By using the > >> SP's IPv6 prefix, the operational domain of 6rd is limited to the SP > >> network and under its direct control. From the perspective of > >> customer sites and the IPv6 Internet at large, the IPv6 service > >> provided is equivalent to native IPv6. > >> > >> I'm not sure what more needs to be said. at least not in the basic pro= tocol spec. (which I > originally > >> wanted to be a single page saying: this is 6to4 with a SP prefix inste= ad of 2002::/16). :-) > > > > From a few mails back, here are the items which I believe bear > > specific mention in an applicability statement: > > > > "During the NGTRANS days, the ISATAP team was strongly required > > to include a "Domain of Applicability" statement, and I think > > the same should be required of 6rd. I see a number of aspects > > of 6rd that IMHO would limit its applicability, including: > > > > - IPv6 prefix tied to IPv4 address (renumbering implications) > > - potential black holes when ICMPs can't be translated > > - provider-aggregated addressing only (no provider-independent) > > - not compatible with multihoming via a single, stable IPv6 prefix > > - not compatible with traffic engineering (i.e., CE can't select > > specific BRs) > > - interactions with load balancing; ECMP within provider network > > - MTU clamping exposes degenerate MTUs to the customer network > > and doesn't allow for automatic discovery of larger MTUs > > - requires operators to exercise tight controls on link MTUs > > - requires operators to exercise tight controls on ICMP > > generation and ICMP filtering" >=20 > as in: > http://tools.ietf.org/html/rfc5214#section-4 >=20 > we have covered that reasonably well already. I think some of those issue= s could well be covered in a > deployment document though. I gave you a valid list of limitations above. These speak to the need for truth in advertising in terms of where 6rd is suited for operation and where it is not. Fred fred.l.templin@boeing.com > cheers, > Ole From brian.e.carpenter@gmail.com Mon Mar 8 14:06:47 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E73F3A69CA; Mon, 8 Mar 2010 14:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGhpXi+GRs4A; Mon, 8 Mar 2010 14:06:46 -0800 (PST) Received: from mail-px0-f191.google.com (mail-px0-f191.google.com [209.85.216.191]) by core3.amsl.com (Postfix) with ESMTP id E3ECE3A6A20; Mon, 8 Mar 2010 14:06:40 -0800 (PST) Received: by pxi29 with SMTP id 29so705939pxi.17 for ; Mon, 08 Mar 2010 14:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=2n5//A2H/QOoIskgVAhpxzpwxZsCPQNtYtjOv3vJFQc=; b=KQfHov4105ISicR/fCnne8EtDF8fshY8y1nVcbIS+4QteX3mX9VdA/VCy1VzMxuDbp rfAjGwoou2celhkY+sjDN38w5endKVHRzLHBMHkbvM24Cx3yGJDUGDYc7phF4a94DmfY q8oe/7wEGjbpB0sJznBMXbVij822c/UaJeCbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=efwwmE/w6oYKfQljy6XtkGImZZsWWCGluwg1STBeiao3u67LxtenfxXmaTf+coZ+BJ ZU76MeMlwYYpS/ipHKVHIkvHj2dunMDmVobyOBGevkXlu6Zn1hqw70e44XRUDlekgpsF OzpASQYDbDWihm+wSDubwqLaVMeSJMi6GaOcA= Received: by 10.142.195.2 with SMTP id s2mr2473004wff.76.1268086002219; Mon, 08 Mar 2010 14:06:42 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 23sm5059276pzk.10.2010.03.08.14.06.40 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Mar 2010 14:06:41 -0800 (PST) Message-ID: <4B9574F9.7010604@gmail.com> Date: Tue, 09 Mar 2010 11:06:49 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ole Troan References: <1211F394-5991-48F5-8A0C-C458478758DD@employees.org> In-Reply-To: <1211F394-5991-48F5-8A0C-C458478758DD@employees.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Durand, Alain" , softwires , DHC WG Subject: Re: [Softwires] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 22:06:47 -0000 Ole, I agree with this as a summary of the common ground in the discussions, even if a few people may disagree here and there. On this: > ** MTU > There are well documented issues with tunnels and MTU. There are > issues with anycast and fragmentation. The draft references the > existing mechanisms for tunnelling and MTU, and recommend following > existing practice. Since the mechanism is contained within a single > SP network, one can assume that the MTU is well managed. Just as in > an MPLS network. > > => Keep existing text. Should the working group start a separate > effort for a more general solution to MTU issues? Agreed to the existing text. Also, I'm not sure that the general discussion is specific to SOFTWIRE. Maybe it should be raised in INTAREA? Regards Brian Carpenter On 2010-03-09 02:33, Ole Troan wrote: > all, > > thank you very much for good and constructive comments! > I've tried to summarize the comments received and the changes made below. > > cheers, > Ole > > > > ** Include option Parameter Request List option for the DHCPv4 option: > New text: > The CE MUST include a Parameter Request List Option target="RFC2132"> for the OPTION_6RD. Because the > OPTION_6RD contains one IPv4MaskLen/6rdPrefixLen/6rdPrefix > block, and because DHCP cannot convey more than one instance > of an option, OPTION_6RD is limited to provision at most a > single 6rd domain. Provisioning of a CE router connected to > multiple 6rd domains is outside the scope of this protocol > specification. > > => Accepted > > ** Loop avoidance > Suggestion was to adopt solution in > draft-nakibly-v6ops-tunnel-loops. Issues with scalability and > checking of "well-known" bits in ISATAP addresses. > > => Keep existing text. > > ** MTU > There are well documented issues with tunnels and MTU. There are > issues with anycast and fragmentation. The draft references the > existing mechanisms for tunnelling and MTU, and recommend following > existing practice. Since the mechanism is contained within a single > SP network, one can assume that the MTU is well managed. Just as in > an MPLS network. > > => Keep existing text. Should the working group start a separate > effort for a more general solution to MTU issues? > > ** Use of anycast > There are issues with the use of anycast. The draft > supports the use of unicast BR addresses too. The issues around > ECMP, fragmentation and ICMP messages ending up on the wrong BR are > to some extent operational. It depends on the network having a well > maintained MTU as recommended in the draft. ECMP should be done on > a per flow basis not on a per packet. > > => Keep existing text. > > ** Analysis of domain of applicability > The draft already sets the context of the solution to within an SP > network. More detail and operational scenarios might be more > suitable to a 6rd operational document. > > => No action. > > ** IPv4 lease time in case of PPP > What lease-time should be used on the LAN-side in IPv6 RAs when the > IPv4 WAN side address is aquired via IPCP? > > Proposed new text: > > 6rd IPv6 address assignment and hence the IPv6 service itself > is tied to the IPv4 address lease, thus the 6rd service is also > tied to this in terms of authorization, accounting, etc. For > example, the 6rd delegated prefix has the same lifetime as its > associated IPv4 address. The prefix lifetimes advertised in > Router Advertisements or used by DHCP on the CE LAN side MUST be > equal to or shorter than the IPv4 address lease time. If the > IPv4 lease time is not known, the lifetime of the 6rd delegated > prefix SHOULD follow the defaults specified in target="RFC4861">. > > => Accepted. > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From root@core3.amsl.com Mon Mar 8 14:15:04 2010 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A51643A6A8F; Mon, 8 Mar 2010 14:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308221503.A51643A6A8F@core3.amsl.com> Date: Mon, 8 Mar 2010 14:15:02 -0800 (PST) Cc: softwires@ietf.org Subject: [Softwires] I-D Action:draft-ietf-softwire-dual-stack-lite-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 22:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion Author(s) : A. Durand, et al. Filename : draft-ietf-softwire-dual-stack-lite-04.txt Pages : 36 Date : 2010-03-08 This document revisits the dual-stack model and introduces the dual- stack lite technology aimed at better aligning the costs and benefits of deploying IPv6. Dual-stack lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-dual-stack-lite-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-softwire-dual-stack-lite-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-08140216.I-D@ietf.org> --NextPart-- From remi.despres@free.fr Mon Mar 8 14:25:52 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199A83A69F9; Mon, 8 Mar 2010 14:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.187 X-Spam-Level: X-Spam-Status: No, score=-1.187 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYS37pWnkYRy; Mon, 8 Mar 2010 14:25:45 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 6768B3A69E2; Mon, 8 Mar 2010 14:25:42 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0CC4CE08117; Mon, 8 Mar 2010 23:25:41 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 07CF0E08060; Mon, 8 Mar 2010 23:25:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 8 Mar 2010 23:25:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1211F394-5991-48 F5-8A0C-C458478758DD@employees.org> To: Alain Durand , softwires , DHC WG X-Mailer: Apple Mail (2.1077) Cc: "Templin, Fred L" Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 22:25:52 -0000 Le 8 mars 2010 =E0 21:00, Templin, Fred L a =E9crit : > With SEAL, the tunnel egress can choose to reassemble as much > or as little as it likes, with the limiting case being that the > egress performs no reassembly at all. In that case, SEAL still > provides value since the tunnel will still be able to support > larger MTUs (e.g., 9KB) as long as all links in the SP network > between ingress->egress support an MTU at least that large. The discussion on SEAL, despite some interesting technical issues, does = not belong to this last call discussion: - 6rd is an transition technique which, to be as useful as it can be for = rapid IPv6 deployments, should be stabilized asap.=20 - The DHCP option, which is specified in this document and nowhere else = is urgent. - Combining SEAL with 6rd is a disjoint subject.=20 > - potential black holes when ICMPs can't be translated - There is no potential blackhole caused by 6rd per se. - Potential blackholes of IPv6 packets as long as ICMPv6 error messages = and PMTUD are not treated properly belong to IPv6 in general, not to = 6rd.=20 - Such blackholes can be completely avoided in the short term, despite = buggy ICMPv6 and/or PMTUD treatments, by sending IPv6 packets that don't = exceed 1280 octets, the guaranteed IPv6 path MTU of RFC 2460. - Provided *the last sentence of the section 9.1 on MTUs is deleted* (as = already proposed in my previous e-mail), the document is therefore sound = in this respect. =20 IMHO, with modifications Ole has listed, and with the sentence deletion = above, the draft can be accepted. Regards, RD From arifumi@nttv6.net Wed Mar 10 03:04:18 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74D63A6B1E for ; Wed, 10 Mar 2010 03:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUSO4Da8-oPy for ; Wed, 10 Mar 2010 03:04:18 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id A87DF3A6AEE for ; Wed, 10 Mar 2010 03:04:12 -0800 (PST) Received: from dhcp-3-143.nttv6.com (dhcp-3-143.nttv6.com [192.47.163.143]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o2AB4FPx080922 for ; Wed, 10 Mar 2010 20:04:15 +0900 (JST) (envelope-from arifumi@nttv6.net) From: Arifumi Matsumoto Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Mar 2010 20:04:15 +0900 References: <20100302001443.4B47128C202@core3.amsl.com> To: softwires@ietf.org Message-Id: <783A5276-3851-4558-84DF-E5137E380ABC@nttv6.net> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Wed, 10 Mar 2010 20:04:15 +0900 (JST) Subject: [Softwires] Fwd: New Version Notification for draft-arifumi-softwire-dslite-global-addr-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 11:04:19 -0000 Hi, I submitted a very simple draft. Any comments are welcome. http://tools.ietf.org/html/draft-arifumi-softwire-dslite-global-addr-00 Begin forwarded message: > =1B$B:9=3DP?M=1B(B: IETF I-D Submission Tool > =1B$BF|;~=1B(B: 2010=1B$BG/=1B(B3=1B$B7n=1B(B2=1B$BF|=1B(B 09:14:43JST > =1B$B08@h=1B(B: arifumi@nttv6.net > Cc: fujisaki@syce.net > =1B$B7oL>=1B(B: New Version Notification for = draft-arifumi-softwire-dslite-global-addr-00=20 >=20 >=20 > A new version of I-D, draft-arifumi-softwire-dslite-global-addr-00.txt = has been successfuly submitted by Arifumi Matsumoto and posted to the = IETF repository. >=20 > Filename: draft-arifumi-softwire-dslite-global-addr > Revision: 00 > Title: Global IPv4 Address Configuration Option for = DS-Lite > Creation_date: 2010-03-02 > WG ID: Independent Submission > Number_of_pages: 6 >=20 > Abstract: > When an ISP tries to deploy IPv6 and take an action for IPv4 address > depletion, DS-Lite is reasonable approach for solving both of the > problems. However, it is troublesome for an ISP to have the existing > IPv4 service facilities and DS-Lite facilities at the same time for > not a short period of time. This document proposes a mechanism to > assign an IPv4 global address in DS-Lite framework, which makes every > customer to move to DS-Lite based network, and enables an ISP to > maintain single facility of the service network. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 -- Arifumi Matsumoto Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net From ichiroumakino@gmail.com Wed Mar 10 03:10:50 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3D463A6BAF; Wed, 10 Mar 2010 03:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqD5mNTLSAhc; Wed, 10 Mar 2010 03:10:49 -0800 (PST) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id C66463A68C8; Wed, 10 Mar 2010 03:10:44 -0800 (PST) Received: by ewy8 with SMTP id 8so1224791ewy.28 for ; Wed, 10 Mar 2010 03:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=4FgMXZ9YtEaxJerpDShMv/CSoXaaTVifJQAFT7uvOWo=; b=RyMqBjgxF+OF0+mbZSYGnZH1gbrCHb6znSG3WMTUAchjd+DxCecyI9X7aU1v6O4ZK8 by6Tac5UkKas5jBQJf7qDrZ6CzexZYn1x3ItQ87TwI3xeGw5egHFdZkw2krq0fUPizE6 lXYfqfTxSEPW9fR5IDhynWNgLt2D+LzZya6Po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=C2Z/4oDIwrtnJzHIxhGo1CoOQNuFWkyKZAugcrDoTUK2fTTibeM+/NPyMZFYVd6hHa ceu4Zc0qcADMvcZioSPJpyfW7aJtBz4LHHuUrZoWsz0oHSMSse/Btdo/kOrK3laCtGeX R4ETyeE1ZCaGn3jR3kHsG3ep3/fb9We1kj4eg= Received: by 10.213.100.139 with SMTP id y11mr783864ebn.50.1268219445244; Wed, 10 Mar 2010 03:10:45 -0800 (PST) Received: from dhcp-10-61-109-85.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id 14sm3853261ewy.2.2010.03.10.03.10.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Mar 2010 03:10:44 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Wed, 10 Mar 2010 12:12:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1211F394-5991-48 F5-8A0C-C458478758DD@employees.org> <90023DF9-4324-4E15-ACFA-F9E9D369F247@employees.org> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) Cc: "Durand, Alain" , softwires , DHC WG Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 11:10:50 -0000 Fred, [...] > This gets back again to the crux question. If 6rd can go > forward with robust MTU handling in the first iteration > it would greatly reduce the pressure for ISPs to upgrade > their entire infrastructure to native IPv6 - perhaps even > indefinitely. So, why not get it right the first time? if there was consensus on what's right... SEAL appears to be a solution described in section 3.1, RFC4459. the 6rd draft is leaning towards the solution described in section 3.3 = of RFC4459. >>>>> But, SEAL is about more than just MTU - it also includes >>>>> mechanism to detect and defeat IPv4 source address spoofing. >>>>> Since the 6rd checks are useless if IPv4 source address >>>>> spoofing is possible, it is necessary to consider the >>>>> domain of applicability to determine whether anti- >>>>> spoofing mitigations are needed. SEAL provides such >>>>> a mitigation. >>>>=20 >>>> I missed that part of SEAL. pointer? >>>=20 >>> (draft-templin-intarea-seal), Section 4.6. >>=20 >> OK, still didn't get it. >=20 > Can you be more specific? Did you not understand what > was written, or do you think there is something wrong > with it? OK, I see, so you pass a nonce around to use for verification against = source spoofing. that requires state. [...] >>> RFC4213 does not examine the implications of setting the DF >>> bit in the presence of anycast source address; 6rd must. >>=20 >> OK, what about: >> "The use of an anycast source address may lead to any ICMP error = message generated on the path being >> sent to a different BR. Therefore using dynamic tunnel MTU [section = 3.2.2, RFC4213] is subject to >> IPv4 Path MTU blackholes." >=20 > I have told you several times what is wrong with anycast > source and DF=3D0. If you want to remain silent and allow > open a potential for undetected data corruption, that > seems like a serious omission. sorry, yes I agree we should point that out. what about: "The use of an anycast source address may lead to any ICMP error = message generated on the path being sent to a different BR. Therefore = using dynamic tunnel MTU [section 3.2.2, RFC4213] is subject to IPv4 = Path MTU blackholes. Multiple BRs using the same anycast source address may send fragmented = packets to the same IPv6 CE at the same time. If the fragmented packets = from different BRs happen to use the same fragment ID, incorrect = reassembly may occur. For this reason a BR using an anycast source = address MUST set the IPv4 Don't Fragment flag." [...] cheers, Ole= From remi.despres@free.fr Wed Mar 10 05:02:01 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50853A68FE; Wed, 10 Mar 2010 05:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6opEMwE7Uzz; Wed, 10 Mar 2010 05:02:01 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 38B8C3A68DF; Wed, 10 Mar 2010 05:01:58 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id ED997E081E2; Wed, 10 Mar 2010 14:01:57 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5F242E08189; Wed, 10 Mar 2010 14:01:54 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 10 Mar 2010 14:01:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <33B12697-9314-45C7-B2F2-950B5072852F@free.fr> References: <1211F394-5991-48 F5-8A0C-C458478758DD@employees.org> <90023DF9-4324-4E15-ACFA-F9E9D369F247@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1077) Cc: "Durand, Alain" , softwires , "Templin, Fred L" , DHC WG Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 13:02:01 -0000 Le 10 mars 2010 =E0 12:12, Ole Troan a =E9crit : ... >> I have told you several times what is wrong with anycast >> source and DF=3D0. If you want to remain silent and allow >> open a potential for undetected data corruption, that >> seems like a serious omission. >=20 > sorry, yes I agree we should point that out. > what about: >=20 > "The use of an anycast source address may lead to any ICMP error = message generated on the path being sent to a different BR. Therefore = using dynamic tunnel MTU [section 3.2.2, RFC4213] is subject to IPv4 = Path MTU blackholes. >=20 > Multiple BRs using the same anycast source address may send fragmented = packets to the same IPv6 CE at the same time. If the fragmented packets = from different BRs happen to use the same fragment ID, incorrect = reassembly may occur. For this reason a BR using an anycast source = address MUST set the IPv4 Don't Fragment flag." Note that in "well managed" 6rd domains (ref. sec 9.1), there is no = fragmentation between BRs and CEs. The DF bit has therefore no effect. I don't see the need for this addition. RD= From ipng@69706e6720323030352d30312d31340a.nosense.org Wed Mar 10 13:12:04 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73F2C3A69F2 for ; Wed, 10 Mar 2010 13:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmP2u5TByyhl for ; Wed, 10 Mar 2010 13:12:03 -0800 (PST) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id 182333A69F0 for ; Wed, 10 Mar 2010 13:12:02 -0800 (PST) Received: from 219-90-180-250.ip.adam.com.au ([219.90.180.250] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NpTCB-0008Ga-Qw; Thu, 11 Mar 2010 07:41:59 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id A166B4930C; Thu, 11 Mar 2010 07:41:58 +1030 (CST) Date: Thu, 11 Mar 2010 07:41:58 +1030 From: Mark Smith To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Message-ID: <20100311074158.537d551a@opy.nosense.org> In-Reply-To: References: <"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org> <700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 21:12:04 -0000 On Mon, 8 Mar 2010 17:05:35 +0100 R=E9mi Despr=E9s wrote: >=20 > Le 8 mars 2010 =E0 16:43, Ole Troan a =E9crit : >=20 > > but you are making an argument that _every_ IPv6 link should be a maxim= um of 1280 bytes. I don't think that is something 6rd should prescribe. >=20 > Only every IPv6-enabled link where it is not known, by some exterior mean= s, that larger MTUs will work for all possible e2e paths. >=20 > In my understanding, we MUST prefer a 100% reliable connectivity to a 15.= 6% gain in MTU size (1480 instead of 1280, working in typical cases but not= in all). >=20 100% reliable connectivity on the Internet doesn't exist, regardless of whether the protocol is IPv4 or IPv6, or MTUs are large or small. Hosts need to be able to cope with packet loss, whether it be TCP acks, PMTUD feedback etc. PMTUD has it's issues, which is why methods defined in=20 http://tools.ietf.org/rfc/rfc4821.txt exist, that don't rely on routers sending back next link MTU information. The Linux kernel has had an implementation of it for at least two years. > Now, if one could prove that there is no more blackhole possibility with = 1480 than with 1280, I would be glad to withdraw my proposed amendment. >=20 Do you have evidence to support your view? Sure it's possible, but from my experience of running a 6to4 tunnel for quite a number of years with a local/initial MTU of 1472 bytes for years (1492 being because of PPPoE's 1492 MTU) without any issues that have ended up being because of broken PMTUD.=20 > But the available proof is rather that blackholes are possible with 1480,= and not with 1280. (I have not been aware of this for long, but being now = well aware, I believe there is no real choice.) >=20 Your right about 1280. However, following that logic, the IPv4 Internet should have an MTU of no greater than 576 bytes, because blackholes are possible with MTU's larger than that. Yet the common MTU on the IPv4 Internet is 1500. Sure there are occasional work arounds like MSS hacks having to be put in place, however they're a reasonable trade off verses having packet per second forwarding rates go up by around 3 times. > Like others, I am not enthusiastic about this, and will work improve the = future, but let's be consistent in the present, and make IPv6 reliable. = =20 >=20 > Cheers, > RD > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From brian.e.carpenter@gmail.com Wed Mar 10 13:24:03 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0064D3A6A0C for ; Wed, 10 Mar 2010 13:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsIc5Kkt9862 for ; Wed, 10 Mar 2010 13:24:01 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id BBFC83A69F3 for ; Wed, 10 Mar 2010 13:24:01 -0800 (PST) Received: by pwj8 with SMTP id 8so21078pwj.31 for ; Wed, 10 Mar 2010 13:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SXT3Vy2ENWEivcGkVJwwAEQy86cbljfvfeevaLW7ytQ=; b=BR5Fk1AYSUhTIkJqpXivcV5X1D3H1jZR0gNbesk7lpUWjGPgCf0gqbIo+udf0qCO08 c6YB4i2EY5zBOzYC1EyAsQKCyS3gD7dQdTu/qciL4rdaOwMCRa1IdDdn0UV9rvQDS7b6 m8I4M4xJkCk29LKXM/QrEh2ijrdPAzDORAjus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=A+1kru5b7T1GH4/dfDQHvtkvjb8o8Cxy8Ijh+zVXmQebipr2mP1iw+/eIYiIBVyyY+ b3/bhoRP6MqlZnaUI6vcHBfAC9Zdp+pubebtdfSO9GDKrsezlVHaCBHoKJxfRFzxTP2w J7yGolivFtgppgfoJVP6S3uXtm2Lo0EUYiu6k= Received: by 10.141.214.24 with SMTP id r24mr1197619rvq.27.1268256244662; Wed, 10 Mar 2010 13:24:04 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 23sm7914209pzk.6.2010.03.10.13.24.03 (version=SSLv3 cipher=RC4-MD5); Wed, 10 Mar 2010 13:24:04 -0800 (PST) Message-ID: <4B980DF2.8030201@gmail.com> Date: Thu, 11 Mar 2010 10:24:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith References: <"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org> <700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> In-Reply-To: <20100311074158.537d551a@opy.nosense.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 21:24:03 -0000 Mark, > Your right about 1280. However, following that logic, the IPv4 Internet > should have an MTU of no greater than 576 bytes, because blackholes are > possible with MTU's larger than that. Yet the common MTU on the IPv4 > Internet is 1500. That's true today. But my experience while travelling and staying in random hotels towards the end of the dial-up era was that I often had to clamp the IPv4 MTU at (say) 512 to make things actually work. I've had experience with 6to4 of abject PMTUD failures with remote servers trying to do 1480. So I think that Remy is correct as far as a fail safe solution *today* goes. Since 6RD is very much a transitional technique before an ISP is ready to run native, I don't see this as a significant inefficiency. Brian Regards Brian Carpenter From Washam.Fan@huaweisymantec.com Wed Mar 10 23:58:37 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108073A6B5E for ; Wed, 10 Mar 2010 23:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.322 X-Spam-Level: X-Spam-Status: No, score=-0.322 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NNU1Z9M6LrW for ; Wed, 10 Mar 2010 23:58:36 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 958793A6B66 for ; Wed, 10 Mar 2010 23:58:35 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Content-type: text/plain; charset=big5 Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KZ3002GOY5QQ870@hstga01-in.huaweisymantec.com> for softwires@ietf.org; Thu, 11 Mar 2010 15:58:38 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KZ300F1XY5QK620@hstml02-in.huaweisymantec.com> for softwires@ietf.org; Thu, 11 Mar 2010 15:58:38 +0800 (CST) Received: from [10.27.154.128] by hstml02-in.huaweisymantec.com (mshttpd); Thu, 11 Mar 2010 15:58:38 +0800 From: WashamFan To: Arifumi Matsumoto Message-id: Date: Thu, 11 Mar 2010 15:58:38 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <783A5276-3851-4558-84DF-E5137E380ABC@nttv6.net> References: <20100302001443.4B47128C202@core3.amsl.com> <783A5276-3851-4558-84DF-E5137E380ABC@nttv6.net> Content-transfer-encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] Fwd: New Version Notification for draft-arifumi-softwire-dslite-global-addr-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 07:58:37 -0000 Hi=2C Are you sure you are defining a DHCPv4 option=3F It seems to me you were intended to define a DHCPv6 option instead=2E You said the option defined in the draft could be combined with options defined in =5BI-D=2Eietf-softwire-ds-lite-tunnel-option=5D=2E I am not sure how DHCPv4 options combined with DHCPv6 options=2E Thanks=2C washam ----- Original Message ----- From=3A Arifumi Matsumoto =3Carifumi=40nttv6=2Enet=3E Date=3A Wednesday=2C March 10=2C 2010 7=3A04 pm Subject=3A =5BSoftwires=5D Fwd=3A New Version Notification for draft-ari= fumi-softwire-dslite-global-addr-00 To=3A softwires=40ietf=2Eorg =3E Hi=2C =3E = =3E I submitted a very simple draft=2E =3E Any comments are welcome=2E =3E = =3E http=3A//tools=2Eietf=2Eorg/html/draft-arifumi-softwire-dslite-glob= al-addr-00 =3E = =3E Begin forwarded message=3A =3E = =3E =3E =AEt=A5X=A4H=3A IETF I-D Submission Tool =3Cidsubmission=40ietf= =2Eorg=3E =3E =3E =A4=E9=AE=C9=3A 2010=A6=7E3=A4=EB2=A4=E9 09=3A14=3A43JST =3E =3E =A9=7B=A5=FD=3A arifumi=40nttv6=2Enet =3E =3E Cc=3A fujisaki=40syce=2Enet =3E =3E =A5=F3=A6W=3A New Version Notification for = =3E draft-arifumi-softwire-dslite-global-addr-00 = =3E =3E = =3E =3E = =3E =3E A new version of I-D=2C = =3E draft-arifumi-softwire-dslite-global-addr-00=2Etxt has been successf= uly = =3E submitted by Arifumi Matsumoto and posted to the IETF repository=2E =3E =3E = =3E =3E Filename=3A draft-arifumi-softwire-dslite-global-addr =3E =3E Revision=3A 00 =3E =3E Title=3A Global IPv4 Address Configuration Opti= on for = =3E DS-Lite =3E =3E Creation=5Fdate=3A 2010-03-02 =3E =3E WG ID=3A Independent Submission =3E =3E Number=5Fof=5Fpages=3A 6 =3E =3E = =3E =3E Abstract=3A =3E =3E When an ISP tries to deploy IPv6 and take an action for IPv4 ad= dress =3E =3E depletion=2C DS-Lite is reasonable approach for solving both of= the =3E =3E problems=2E However=2C it is troublesome for an ISP to have th= e existing =3E =3E IPv4 service facilities and DS-Lite facilities at the same time= for =3E =3E not a short period of time=2E This document proposes a mechani= sm to =3E =3E assign an IPv4 global address in DS-Lite framework=2C which mak= es every =3E =3E customer to move to DS-Lite based network=2C and enables an ISP= to =3E =3E maintain single facility of the service network=2E =3E =3E = =3E =3E = =3E =3E = =3E =3E The IETF Secretariat=2E =3E =3E = =3E =3E = =3E = =3E = =3E -- =3E Arifumi Matsumoto =3E Secure Communication Project =3E NTT Information Sharing Platform Laboratories =3E E-mail=3A arifumi=40nttv6=2Enet =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E Softwires mailing list =3E Softwires=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/softwires =3E From arifumi@nttv6.net Thu Mar 11 01:21:40 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F90A3A6A1A for ; Thu, 11 Mar 2010 01:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_DHCP=1.398, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwI-L-YUQdeR for ; Thu, 11 Mar 2010 01:21:36 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 324123A6AEF for ; Thu, 11 Mar 2010 01:21:34 -0800 (PST) Received: from dhcp-3-143.nttv6.com (dhcp-3-143.nttv6.com [192.47.163.143]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o2B9LTAh088978; Thu, 11 Mar 2010 18:21:29 +0900 (JST) (envelope-from arifumi@nttv6.net) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: Date: Thu, 11 Mar 2010 18:21:29 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <54DDB7A6-5983-448B-9FFB-3EC4EE934ED4@nttv6.net> References: <20100302001443.4B47128C202@core3.amsl.com> <783A5276-3851-4558-84DF-E5137E380ABC@nttv6.net> To: WashamFan X-Mailer: Apple Mail (2.1077) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Thu, 11 Mar 2010 18:21:29 +0900 (JST) Cc: softwires@ietf.org Subject: Re: [Softwires] Fwd: New Version Notification for draft-arifumi-softwire-dslite-global-addr-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 09:21:40 -0000 Hi, On 2010/03/11, at 16:58, WashamFan wrote: > Hi, >=20 > Are you sure you are defining a DHCPv4 option? It seems to me > you were intended to define a DHCPv6 option instead. I think both ways are possible. If defining DHCPv4 option, the router should request DHCPv4 messages in the configured IPv6 tunnel. If defining DHCPv6 option, the router should have an global=20 IPv4 address as well as IPv6 tunnel endpoint address at the same time, and should configure IPv6 tunnel and attach IPv4 global address to it. In the former case, the router has to decide whether it uses IPv4 global address or not by the reply from the DHCPv4 server that may not exist in the network. It may bring up implementation difficulty and also timing issue. So, as you suggest, it may be better to use DHCPv6. Kindest regards, >=20 > You said the option defined in the draft could be combined with > options defined in [I-D.ietf-softwire-ds-lite-tunnel-option]. > I am not sure how DHCPv4 options combined with DHCPv6 options. >=20 > Thanks, > washam >=20 > ----- Original Message ----- > From: Arifumi Matsumoto > Date: Wednesday, March 10, 2010 7:04 pm > Subject: [Softwires] Fwd: New Version Notification for = draft-arifumi-softwire-dslite-global-addr-00 > To: softwires@ietf.org >=20 >=20 >> Hi, >>=20 >> I submitted a very simple draft. >> Any comments are welcome. >>=20 >> = http://tools.ietf.org/html/draft-arifumi-softwire-dslite-global-addr-00 >>=20 >> Begin forwarded message: >>> A new version of I-D,=20 >> draft-arifumi-softwire-dslite-global-addr-00.txt has been successfuly=20= >> submitted by Arifumi Matsumoto and posted to the IETF repository. >>>=20 >>> Filename: draft-arifumi-softwire-dslite-global-addr >>> Revision: 00 >>> Title: Global IPv4 Address Configuration Option for=20= >> DS-Lite >>> Creation_date: 2010-03-02 >>> WG ID: Independent Submission >>> Number_of_pages: 6 >>>=20 >>> Abstract: >>> When an ISP tries to deploy IPv6 and take an action for IPv4 address >>> depletion, DS-Lite is reasonable approach for solving both of the >>> problems. However, it is troublesome for an ISP to have the = existing >>> IPv4 service facilities and DS-Lite facilities at the same time for >>> not a short period of time. This document proposes a mechanism to >>> assign an IPv4 global address in DS-Lite framework, which makes = every >>> customer to move to DS-Lite based network, and enables an ISP to >>> maintain single facility of the service network. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >>=20 >>=20 >> -- >> Arifumi Matsumoto >> Secure Communication Project >> NTT Information Sharing Platform Laboratories >> E-mail: arifumi@nttv6.net >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 -- Arifumi Matsumoto Secure Communication Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net From Washam.Fan@huaweisymantec.com Thu Mar 11 01:42:16 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43F143A6AE3 for ; Thu, 11 Mar 2010 01:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=1.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo-UkURA8yjx for ; Thu, 11 Mar 2010 01:42:15 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 955963A6B5D for ; Thu, 11 Mar 2010 01:42:14 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KZ4002HC2YIQ890@hstga01-in.huaweisymantec.com> for softwires@ietf.org; Thu, 11 Mar 2010 17:42:18 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KZ400FE32YHK620@hstml02-in.huaweisymantec.com> for softwires@ietf.org; Thu, 11 Mar 2010 17:42:17 +0800 (CST) Received: from [10.27.154.128] by hstml02-in.huaweisymantec.com (mshttpd); Thu, 11 Mar 2010 17:42:17 +0800 From: WashamFan To: Arifumi Matsumoto Message-id: Date: Thu, 11 Mar 2010 17:42:17 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal In-reply-to: <54DDB7A6-5983-448B-9FFB-3EC4EE934ED4@nttv6.net> References: <20100302001443.4B47128C202@core3.amsl.com> <783A5276-3851-4558-84DF-E5137E380ABC@nttv6.net> <54DDB7A6-5983-448B-9FFB-3EC4EE934ED4@nttv6.net> Cc: softwires@ietf.org Subject: Re: [Softwires] Fwd: New Version Notification for draft-arifumi-softwire-dslite-global-addr-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 09:42:16 -0000 Hi, > > Are you sure you are defining a DHCPv4 option? It seems to me > > you were intended to define a DHCPv6 option instead. > > I think both ways are possible. > > If defining DHCPv4 option, the router should request DHCPv4 > messages in the configured IPv6 tunnel. In that way, we can use DHCPv4 as is, no additional options need inventing. > If defining DHCPv6 option, the router should have an global > IPv4 address as well as IPv6 tunnel endpoint address at the > same time, and should configure IPv6 tunnel and attach IPv4 > global address to it. > > In the former case, the router has to decide whether it uses > IPv4 global address or not by the reply from the DHCPv4 server > that may not exist in the network. It may bring up implementation > difficulty and also timing issue. Yes. DS-Lite avoids IPv4 provision in the SP network, so it is hard for us to assume a DHCPv4 server would be there. > So, as you suggest, it may be better to use DHCPv6. ;-) Thanks, washam From remi.despres@free.fr Thu Mar 11 02:08:23 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C113A6B73 for ; Thu, 11 Mar 2010 02:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRrtDaZ1rtec for ; Thu, 11 Mar 2010 02:08:22 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 537263A6B02 for ; Thu, 11 Mar 2010 02:08:20 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 5A02CE081DF; Thu, 11 Mar 2010 11:08:21 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0BE99E08112; Thu, 11 Mar 2010 11:08:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20100311074158.537d551a@opy.nosense.org> Date: Thu, 11 Mar 2010 11:08:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0212B904-D0F8-473F-8EFC-7A1BF7ED884D@free.fr> References: <"A2529835-968 C-4E 9D-A730-9E950F5EDA6C"@employees.org> <700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 10:08:23 -0000 Le 10 mars 2010 =E0 22:11, Mark Smith a =E9crit : ... > 100% reliable connectivity on the Internet doesn't exist, regardless = of > whether the protocol is IPv4 or IPv6, or MTUs are large or small. = Hosts > need to be able to cope with packet loss, whether it be TCP acks, = PMTUD > feedback etc. It depends on what is meant by "connectivity". I took it as meaning that if all packets between two hosts have x% = chances to reach their destination, with x significantly > 0, there is = connectivity between them (the opposite of blackhole where some packets = have 0% chances to go through). But I don't know any official definition saying this. Your interpretation may therefore be as legitimate as this one.=20 >=20 >> But the available proof is rather that blackholes are possible with = 1480, and not with 1280. (I have not been aware of this for long, but = being now well aware, I believe there is no real choice.) >>=20 >=20 > Your right about 1280. > However, following that logic, the IPv4 Internet > should have an MTU of no greater than 576 bytes, because blackholes = are > possible with MTU's larger than that. In IPv4: - Packets can be fragmented in the network. - The minimum PMTU is 68, i.e. the maximum IPv4 header length plus the = minimum IPv4 fragment length (RFC 1858, RFC 2132) - All packets having its DF bit =3D 0, have no risk to be discarded = because of their size.=20 - In particular, a 1500B packet can traverse paths whose PMTUs are as = small as 576 (or even as small as 68). In IPv6: - Packets cannot be fragmented in the network - A minimum PMTU is standardized, i.e. 1280B. - 1500B packets cannot traverse any IPv6 path having as PMTU 1480 (or = 1280 or any value < 1500). This justifies a different behavior. Regards, RD= From ipng@69706e6720323030352d30312d31340a.nosense.org Thu Mar 11 05:55:16 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66B7A3A68B4 for ; Thu, 11 Mar 2010 05:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLhRLONNxfcg for ; Thu, 11 Mar 2010 05:55:15 -0800 (PST) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by core3.amsl.com (Postfix) with ESMTP id 519593A6B3B for ; Thu, 11 Mar 2010 05:54:59 -0800 (PST) Received: from 219-90-180-250.ip.adam.com.au ([219.90.180.250] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Npiqr-0005SE-6Q; Fri, 12 Mar 2010 00:25:01 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id C9AEA4930D; Fri, 12 Mar 2010 00:25:00 +1030 (CST) Date: Fri, 12 Mar 2010 00:25:00 +1030 From: Mark Smith To: =?ISO-8859-1?B?UultaSBEZXNwculz?= , softwires@ietf.org Message-ID: <20100312002500.6c7489ba@opy.nosense.org> In-Reply-To: <0212B904-D0F8-473F-8EFC-7A1BF7ED884D@free.fr> References: <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <0212B904-D0F8-473F-8EFC-7A1BF7ED884D@free.fr> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 13:55:16 -0000 On Thu, 11 Mar 2010 11:08:18 +0100 R=E9mi Despr=E9s wrote: >=20 > Le 10 mars 2010 =E0 22:11, Mark Smith a =E9crit : > ... > > 100% reliable connectivity on the Internet doesn't exist, regardless of > > whether the protocol is IPv4 or IPv6, or MTUs are large or small. Hosts > > need to be able to cope with packet loss, whether it be TCP acks, PMTUD > > feedback etc. >=20 > It depends on what is meant by "connectivity". > I took it as meaning that if all packets between two hosts have x% chance= s to reach their destination, with x significantly > 0, there is connectivi= ty between them (the opposite of blackhole where some packets have 0% chanc= es to go through). >=20 > But I don't know any official definition saying this. > Your interpretation may therefore be as legitimate as this one.=20 >=20 >=20 > >=20 > >> But the available proof is rather that blackholes are possible with 14= 80, and not with 1280. (I have not been aware of this for long, but being n= ow well aware, I believe there is no real choice.) > >>=20 > >=20 > > Your right about 1280. >=20 > > However, following that logic, the IPv4 Internet > > should have an MTU of no greater than 576 bytes, because blackholes are > > possible with MTU's larger than that. >=20 > In IPv4: > - Packets can be fragmented in the network. > - The minimum PMTU is 68, i.e. the maximum IPv4 header length plus the mi= nimum IPv4 fragment length (RFC 1858, RFC 2132) > - All packets having its DF bit =3D 0, have no risk to be discarded becau= se of their size.=20 > - In particular, a 1500B packet can traverse paths whose PMTUs are as sma= ll as 576 (or even as small as 68). >=20 It's late here, so I certainly won't claim an authoritative big picture view. However, I like the following quote, particularly the "biggest smallest" part : "I forget the exact terminology, but Brian is talking about the biggest packet one can send and be guaranteed it will not be fragmented. The is 576 bytes for IPv4 and 1280 bytes for IPv6. I think of it as the biggest smallest packet one can send :-)" http://www.ops.ietf.org/lists/v6ops/v6ops.2007/msg00835.html >=20 > In IPv6: > - Packets cannot be fragmented in the network > - A minimum PMTU is standardized, i.e. 1280B. > - 1500B packets cannot traverse any IPv6 path having as PMTU 1480 (or 128= 0 or any value < 1500). >=20 > This justifies a different behavior. >=20 > Regards, > RD From Fred.L.Templin@boeing.com Thu Mar 11 15:05:16 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC053A6833; Thu, 11 Mar 2010 15:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cR6fXdgHIhsc; Thu, 11 Mar 2010 15:05:14 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 47C7E3A6926; Thu, 11 Mar 2010 15:05:13 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2BN56Dm009591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Mar 2010 15:05:10 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2BN53EH010315; Thu, 11 Mar 2010 17:05:03 -0600 (CST) 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 o2BN517o010276 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 11 Mar 2010 17:05:02 -0600 (CST) 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; Thu, 11 Mar 2010 15:05:01 -0800 From: "Templin, Fred L" To: Ole Troan Date: Thu, 11 Mar 2010 15:04:59 -0800 Thread-Topic: [dhcwg] 6rd LC - summary of comments Thread-Index: AcrAQlaC+Fd+f3egR3mfGoklMsgwTgBKcIcA Message-ID: References: <1211F394-5991-48 F5-8A0C-C458478758DD@employees.org> <90023DF9-4324-4E15-ACFA-F9E9D369F247@employees.org> 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: "Durand, Alain" , softwires , DHC WG Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 23:05:16 -0000 Hi Ole, Catching up on the recent exchanges: > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan > Sent: Wednesday, March 10, 2010 3:12 AM > To: Templin, Fred L > Cc: Durand, Alain; softwires; David Ward; DHC WG > Subject: Re: [dhcwg] 6rd LC - summary of comments >=20 > Fred, >=20 > [...] >=20 > > This gets back again to the crux question. If 6rd can go > > forward with robust MTU handling in the first iteration > > it would greatly reduce the pressure for ISPs to upgrade > > their entire infrastructure to native IPv6 - perhaps even > > indefinitely. So, why not get it right the first time? >=20 > if there was consensus on what's right... Good question. > SEAL appears to be a solution described in section 3.1, RFC4459. No, that's not right; RFC4459, Section 3.1 talks about *outer* fragmentation and reassembly, but SEAL explicitly seeks to tune out any outer fragmentation whenever it occurs. SEAL is also not an example of an inner fragmentation scheme referred to in RFC4459, Section 3.4. Instead, SEAL is a mid-layer segmentation and reassembly approach described in RFC2764, Section 3.1.7. RFC4459 missed this approach in its analysis. > the 6rd draft is leaning towards the solution described in section 3.3 of= RFC4459. That section includes text that shows a clear need for an applicability statement. For example: "This approach is highly assumptive of the deployment scenario." =20 > >>>>> But, SEAL is about more than just MTU - it also includes > >>>>> mechanism to detect and defeat IPv4 source address spoofing. > >>>>> Since the 6rd checks are useless if IPv4 source address > >>>>> spoofing is possible, it is necessary to consider the > >>>>> domain of applicability to determine whether anti- > >>>>> spoofing mitigations are needed. SEAL provides such > >>>>> a mitigation. > >>>> > >>>> I missed that part of SEAL. pointer? > >>> > >>> (draft-templin-intarea-seal), Section 4.6. > >> > >> OK, still didn't get it. > > > > Can you be more specific? Did you not understand what > > was written, or do you think there is something wrong > > with it? >=20 > OK, I see, so you pass a nonce around to use for verification against sou= rce spoofing. that requires > state. That is true. Tunnel endpoints that wish to synchronize sequence numbers must maintain state, e.g., in neighbor cache entries. Tunnel endpoints that do not wish to synchronize sequence numbers can omit this state, but will not realize the benefits of avoiding off-path spoofing attacks. > [...] >=20 > >>> RFC4213 does not examine the implications of setting the DF > >>> bit in the presence of anycast source address; 6rd must. > >> > >> OK, what about: > >> "The use of an anycast source address may lead to any ICMP error messa= ge generated on the path > being > >> sent to a different BR. Therefore using dynamic tunnel MTU [section 3.= 2.2, RFC4213] is subject to > >> IPv4 Path MTU blackholes." > > > > I have told you several times what is wrong with anycast > > source and DF=3D0. If you want to remain silent and allow > > open a potential for undetected data corruption, that > > seems like a serious omission. >=20 > sorry, yes I agree we should point that out. > what about: >=20 > "The use of an anycast source address may lead to any ICMP error messag= e generated on the path > being sent to a different BR. Therefore using dynamic tunnel MTU [section= 3.2.2, RFC4213] is subject > to IPv4 Path MTU blackholes. >=20 > Multiple BRs using the same anycast source address may send fragmented pa= ckets to the same IPv6 CE at > the same time. If the fragmented packets from different BRs happen to use= the same fragment ID, > incorrect reassembly may occur. For this reason a BR using an anycast sou= rce address MUST set the > IPv4 Don't Fragment flag." That pretty much matches up with what I asked for, so I don't have a problem with it per se. Still, I feel we can do so much better of a service to end users if we can get them a solid 1500 as well as the ability to discover and utilize larger MTUs without any assumptions of what links might be in the ISP network path. Thanks - Fred fred.l.templin@boeing.com > [...] >=20 > cheers, > Ole From Fred.L.Templin@boeing.com Thu Mar 11 15:09:02 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC823A6965; Thu, 11 Mar 2010 15:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.408 X-Spam-Level: X-Spam-Status: No, score=-7.408 tagged_above=-999 required=5 tests=[AWL=0.891, BAYES_00=-2.599, GB_I_INVITATION=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FuDh3e6v1nx; Thu, 11 Mar 2010 15:09:01 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 38F803A695E; Thu, 11 Mar 2010 15:08:56 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2BN8u3O026740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Mar 2010 15:08:56 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2BN8tQg018687; Thu, 11 Mar 2010 15:08:55 -0800 (PST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2BN8tKM018675 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 11 Mar 2010 15:08:55 -0800 (PST) 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; Thu, 11 Mar 2010 15:08:55 -0800 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Ole Troan Date: Thu, 11 Mar 2010 15:08:54 -0800 Thread-Topic: [Softwires] [dhcwg] 6rd LC - summary of comments Thread-Index: AcrAUeUIoqElj7o7RxCB01XHg4aJFgBHXRdQ Message-ID: References: <1211F394-5991-48 F5-8A0C-C458478758DD@employees.org> <90023DF9-4324-4E15-ACFA-F9E9D369F247@employees.org> <33B12697-9314-45C7-B2F2-950B5072852F@free.fr> In-Reply-To: <33B12697-9314-45C7-B2F2-950B5072852F@free.fr> 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 Cc: "Durand, Alain" , softwires , DHC WG Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 23:09:02 -0000 Remi, > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Wednesday, March 10, 2010 5:02 AM > To: Ole Troan > Cc: Templin, Fred L; Durand, Alain; softwires; DHC WG > Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments >=20 >=20 > Le 10 mars 2010 =E0 12:12, Ole Troan a =E9crit : > ... > >> I have told you several times what is wrong with anycast > >> source and DF=3D0. If you want to remain silent and allow > >> open a potential for undetected data corruption, that > >> seems like a serious omission. > > > > sorry, yes I agree we should point that out. > > what about: > > > > "The use of an anycast source address may lead to any ICMP error messa= ge generated on the path > being sent to a different BR. Therefore using dynamic tunnel MTU [section= 3.2.2, RFC4213] is subject > to IPv4 Path MTU blackholes. > > > > Multiple BRs using the same anycast source address may send fragmented = packets to the same IPv6 CE > at the same time. If the fragmented packets from different BRs happen to = use the same fragment ID, > incorrect reassembly may occur. For this reason a BR using an anycast sou= rce address MUST set the > IPv4 Don't Fragment flag." >=20 > Note that in "well managed" 6rd domains (ref. sec 9.1), there is no fragm= entation between BRs and > CEs. > The DF bit has therefore no effect. > I don't see the need for this addition. Still, DF=3D0 is an open invitation to the network to fragment the packet if it decides to do so, and there is no recourse to say back to the network "you should not have fragmented that". DF=3D1 gives the network no leg to stand on whereby it could legitimately fragment the packet. Thanks - Fred fred.l.templin@boeing.com =20 >=20 > RD From Fred.L.Templin@boeing.com Thu Mar 11 15:21:54 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F653A6983 for ; Thu, 11 Mar 2010 15:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3itKZa1zOKY2 for ; Thu, 11 Mar 2010 15:21:51 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id D8ED33A6973 for ; Thu, 11 Mar 2010 15:21:29 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2BNLOsF005333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Mar 2010 17:21:25 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2BNLOYO004234; Thu, 11 Mar 2010 15:21:24 -0800 (PST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2BNLO23004231 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 11 Mar 2010 15:21:24 -0800 (PST) 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; Thu, 11 Mar 2010 15:21:24 -0800 From: "Templin, Fred L" To: Mark Smith , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Thu, 11 Mar 2010 15:21:23 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrAlm0ZbjgyJOLSRi64guyxV8hs1wA2aLQw Message-ID: References: <"A2529835-968 C- 4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CD B@f ree.fr><4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70A EF@employees.org><9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr><4B916BA7.308040 0@gmail.com> <4B950EF1.6010304@cisco .com><74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> In-Reply-To: <20100311074158.537d551a@opy.nosense.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 23:21:54 -0000 Hi Mark, > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Mark Smith > Sent: Wednesday, March 10, 2010 1:12 PM > To: R=E9mi Despr=E9s > Cc: softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > On Mon, 8 Mar 2010 17:05:35 +0100 > R=E9mi Despr=E9s wrote: >=20 > > > > Le 8 mars 2010 =E0 16:43, Ole Troan a =E9crit : > > > > > but you are making an argument that _every_ IPv6 link should be a max= imum of 1280 bytes. I don't > think that is something 6rd should prescribe. > > > > Only every IPv6-enabled link where it is not known, by some exterior me= ans, that larger MTUs will > work for all possible e2e paths. > > > > In my understanding, we MUST prefer a 100% reliable connectivity to a 1= 5.6% gain in MTU size (1480 > instead of 1280, working in typical cases but not in all). > > >=20 > 100% reliable connectivity on the Internet doesn't exist, regardless of > whether the protocol is IPv4 or IPv6, or MTUs are large or small. Hosts > need to be able to cope with packet loss, whether it be TCP acks, PMTUD > feedback etc. >=20 > PMTUD has it's issues, which is why methods defined in >=20 > http://tools.ietf.org/rfc/rfc4821.txt >=20 > exist, that don't rely on routers sending back next link MTU > information. The RFC4821 is indeed a potential tool for end systems to use that could make life much better in the transitional period of moving to larger MTUs in the Internet, and I highly support it. However, the tunnel endpoints still need to do their part to provide solid underpinnings over which the RFC4821 signaling riders, i.e., end system use of RFC4821 does not release the tunnel endpoints of their obligation to maintain a solid MTU. > The Linux kernel has had an implementation of it for at least two years. >=20 > > Now, if one could prove that there is no more blackhole possibility wit= h 1480 than with 1280, I > would be glad to withdraw my proposed amendment. > > >=20 > Do you have evidence to support your view? Sure it's possible, but from > my experience of running a 6to4 tunnel for quite a number of years with > a local/initial MTU of 1472 bytes for years (1492 being because of > PPPoE's 1492 MTU) without any issues that have ended up being because > of broken PMTUD. >=20 > > But the available proof is rather that blackholes are possible with 148= 0, and not with 1280. (I > have not been aware of this for long, but being now well aware, I believe= there is no real choice.) > > >=20 > Your right about 1280. However, following that logic, the IPv4 Internet > should have an MTU of no greater than 576 bytes, because blackholes are > possible with MTU's larger than that. Yet the common MTU on the IPv4 > Internet is 1500. Sure there are occasional work arounds like MSS hacks > having to be put in place, however they're a reasonable trade off > verses having packet per second forwarding rates go up by around 3 > times. I'd like to touch on this MSS clamping question for a moment. I think we can expect to see more and more non-TCP traffic, and this seems to be substantiated by at least one recent CAIDA study (reference needed). I think we may also be forgetting that VPNs are becoming more and more prevalent where there may be no visibility into the MSS option nor ability to clamp it. Hence, I do not see MSS clamping as being a viable recommended practice for all environments. Thanks - Fred fred.l.templin@boeing.com > > Like others, I am not enthusiastic about this, and will work improve th= e future, but let's be > consistent in the present, and make IPv6 reliable. > > > > Cheers, > > RD > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Fred.L.Templin@boeing.com Thu Mar 11 15:30:33 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681A33A6802 for ; Thu, 11 Mar 2010 15:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wU47-C-5AImK for ; Thu, 11 Mar 2010 15:30:32 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 9ACE93A67B6 for ; Thu, 11 Mar 2010 15:30:32 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2BNUYgC005093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Mar 2010 15:30:34 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2BNUXkW021242; Thu, 11 Mar 2010 15:30:33 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2BNUPiU020806 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 11 Mar 2010 15:30:26 -0800 (PST) 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; Thu, 11 Mar 2010 15:30:25 -0800 From: "Templin, Fred L" To: Brian E Carpenter , Mark Smith Date: Thu, 11 Mar 2010 15:30:24 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrAmSlCbv5ORinTQ16T1BDlGIwpcAA2IK/w Message-ID: References: <"A2529835-968 C -4E 9D-A730-9E950F5EDA6C"@employees.org> <700287C3-4EAA-4027-8CCC-17201B628 CDB@f ree.fr> <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D7 0AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7. 3080400@gmail.com><4B950EF1.6010304@cisco.com> <74EF8AD8-2DFE-4493-8AA8-6F7 9A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> In-Reply-To: <4B980DF2.8030201@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 23:30:33 -0000 Brian, > Since 6RD is very much a transitional technique > before an ISP is ready to run native, But, why limit the thinking with 6rd to only viewing it as a "transition mechanism"? Transition mechanism innovation was deemed complete in 2002 with the closing of NGTRANS, the emergence of v6ops, and the declaration of IPv6 as "operational". Yet, we still have IPv4 in widespread deployment and use and no sign of that use abating. 6rd already has us on a trajectory to deploy a *pretty good* IPv6 service in coexistence with IPv4. So, why not take the small additional step to make it *great*? Thanks - Fred fred.l.templin@boeing.com > Brian >=20 > Regards > Brian Carpenter > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Fred.L.Templin@boeing.com Thu Mar 11 15:33:29 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 122C63A68C8 for ; Thu, 11 Mar 2010 15:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoN3E3bsoeg5 for ; Thu, 11 Mar 2010 15:33:28 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 9B28D3A68B2 for ; Thu, 11 Mar 2010 15:33:26 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2BNXPhM020332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Mar 2010 15:33:27 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2BNXP4d019047; Thu, 11 Mar 2010 17:33:25 -0600 (CST) 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 o2BNWxEC018508 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 11 Mar 2010 17:33:25 -0600 (CST) 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; Thu, 11 Mar 2010 15:33:04 -0800 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Mark Smith Date: Thu, 11 Mar 2010 15:33:02 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrBAtSD7sDTx7inQXSqGqPNiP4BiwAcEJzg Message-ID: References: <"A2529835-968 C- 4E 9D-A730-9E950F5EDA6C"@employees.org><700287C3-4EAA-4027-8CCC-17201B628CD B@f ree.fr><4B8CD37A.5090203@gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70A EF@employees.org><9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr><4B916BA7.308040 0@gmail.com> <4B950EF1.6010304@cisco .com><74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr><20100311074158.537d551a@opy.nosense.org> <0212B904-D0F8-473F-8EFC-7A1BF7ED884D@free.fr> In-Reply-To: <0212B904-D0F8-473F-8EFC-7A1BF7ED884D@free.fr> 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 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 23:33:29 -0000 Remi, > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of R=E9mi Despr=E9s > Sent: Thursday, March 11, 2010 2:08 AM > To: Mark Smith > Cc: softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 >=20 > Le 10 mars 2010 =E0 22:11, Mark Smith a =E9crit : > ... > > 100% reliable connectivity on the Internet doesn't exist, regardless of > > whether the protocol is IPv4 or IPv6, or MTUs are large or small. Hosts > > need to be able to cope with packet loss, whether it be TCP acks, PMTUD > > feedback etc. >=20 > It depends on what is meant by "connectivity". > I took it as meaning that if all packets between two hosts have x% chance= s to reach their > destination, with x significantly > 0, there is connectivity between them= (the opposite of blackhole > where some packets have 0% chances to go through). >=20 > But I don't know any official definition saying this. > Your interpretation may therefore be as legitimate as this one. >=20 >=20 > > > >> But the available proof is rather that blackholes are possible with 14= 80, and not with 1280. (I > have not been aware of this for long, but being now well aware, I believe= there is no real choice.) > >> > > > > Your right about 1280. >=20 > > However, following that logic, the IPv4 Internet > > should have an MTU of no greater than 576 bytes, because blackholes are > > possible with MTU's larger than that. >=20 > In IPv4: > - Packets can be fragmented in the network. > - The minimum PMTU is 68, i.e. the maximum IPv4 header length plus the mi= nimum IPv4 fragment length > (RFC 1858, RFC 2132) > - All packets having its DF bit =3D 0, have no risk to be discarded becau= se of their size. > - In particular, a 1500B packet can traverse paths whose PMTUs are as sma= ll as 576 (or even as small > as 68). >=20 >=20 > In IPv6: > - Packets cannot be fragmented in the network > - A minimum PMTU is standardized, i.e. 1280B. > - 1500B packets cannot traverse any IPv6 path having as PMTU 1480 (or 128= 0 or any value < 1500). >=20 > This justifies a different behavior. All truly spoken. Fred fred.l.templin@boeing.com > Regards, > RD > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From townsley@cisco.com Thu Mar 11 15:35:37 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E773A68DB for ; Thu, 11 Mar 2010 15:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIc6F8HKLpj7 for ; Thu, 11 Mar 2010 15:35:36 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 274D03A6833 for ; Thu, 11 Mar 2010 15:35:36 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGoNmUurR7Ht/2dsb2JhbACaZHOjT5h3hHsE X-IronPort-AV: E=Sophos;i="4.49,623,1262563200"; d="scan'208";a="216999263" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 11 Mar 2010 23:35:42 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2BNZf9g001475 for ; Thu, 11 Mar 2010 23:35:42 GMT Received: from ams-townsley-87110.cisco.com (ams-townsley-87110.cisco.com [10.55.233.235]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2BNZeY06084 for ; Thu, 11 Mar 2010 15:35:41 -0800 (PST) Message-ID: <4B997E4B.6040009@cisco.com> Date: Fri, 12 Mar 2010 00:35:39 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: softwires@ietf.org References: <700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> In-Reply-To: <4B980DF2.8030201@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 23:35:37 -0000 On 3/10/10 10:24 PM, Brian E Carpenter wrote: > Mark, > > >> Your right about 1280. However, following that logic, the IPv4 Internet >> should have an MTU of no greater than 576 bytes, because blackholes are >> possible with MTU's larger than that. Yet the common MTU on the IPv4 >> Internet is 1500. >> > That's true today. But my experience while travelling and staying in > random hotels towards the end of the dial-up era was that I often > had to clamp the IPv4 MTU at (say) 512 to make things actually work. > I've had experience with 6to4 of abject PMTUD failures with remote servers > trying to do 1480. So I think that Remy is correct as far as a fail safe > solution *today* goes. And thank goodness we still don't fragment all IPv4 traffic >= 512 bytes. > Since 6RD is very much a transitional technique > before an ISP is ready to run native, I don't see this as a significant > inefficiency. > The problem in this logic is that the argument for 1280 is not about the MTU within the confines of the 6rd deployment, but outside across the Internet. As such, it would apply equally to native IPv6 as it would to 6rd. - Mark > Brian > > Regards > Brian Carpenter > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > From Fred.L.Templin@boeing.com Thu Mar 11 15:37:48 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0062E3A6922 for ; Thu, 11 Mar 2010 15:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Llcetf+Pmjyq for ; Thu, 11 Mar 2010 15:37:46 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id AE1A33A6833 for ; Thu, 11 Mar 2010 15:37:46 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2BNbl6Y007949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Mar 2010 15:37:47 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2BNblki025417; Thu, 11 Mar 2010 17:37:47 -0600 (CST) 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 o2BNbknN025412 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 11 Mar 2010 17:37:46 -0600 (CST) 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, 11 Mar 2010 15:37:46 -0800 From: "Templin, Fred L" To: Mark Smith , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "softwires@ietf.org" Date: Thu, 11 Mar 2010 15:37:44 -0800 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrBIoCYyt9VrxNoTvWiGw52PvLT4AAUNDww Message-ID: References: <4B8CD37A.5090203 @gmail.com><4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70A EF@employees.org><9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr><4B916BA7.308040 0@gmail.com> <4B950EF1.6010304@cisco .com><74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr>< 20100311074158.537d551a@opy.nosense.org><0212B904-D0F8-473F-8EFC-7A1BF7ED884D@free.fr> <20100312002500.6c7489ba@opy.nosense.org> In-Reply-To: <20100312002500.6c7489ba@opy.nosense.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 23:37:48 -0000 Mark, > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Mark Smith > Sent: Thursday, March 11, 2010 5:55 AM > To: R=E9mi Despr=E9s; softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > On Thu, 11 Mar 2010 11:08:18 +0100 > R=E9mi Despr=E9s wrote: >=20 > > > > Le 10 mars 2010 =E0 22:11, Mark Smith a =E9crit : > > ... > > > 100% reliable connectivity on the Internet doesn't exist, regardless = of > > > whether the protocol is IPv4 or IPv6, or MTUs are large or small. Hos= ts > > > need to be able to cope with packet loss, whether it be TCP acks, PMT= UD > > > feedback etc. > > > > It depends on what is meant by "connectivity". > > I took it as meaning that if all packets between two hosts have x% chan= ces to reach their > destination, with x significantly > 0, there is connectivity between them= (the opposite of blackhole > where some packets have 0% chances to go through). > > > > But I don't know any official definition saying this. > > Your interpretation may therefore be as legitimate as this one. > > > > > > > > > >> But the available proof is rather that blackholes are possible with = 1480, and not with 1280. (I > have not been aware of this for long, but being now well aware, I believe= there is no real choice.) > > >> > > > > > > Your right about 1280. > > > > > However, following that logic, the IPv4 Internet > > > should have an MTU of no greater than 576 bytes, because blackholes a= re > > > possible with MTU's larger than that. > > > > In IPv4: > > - Packets can be fragmented in the network. > > - The minimum PMTU is 68, i.e. the maximum IPv4 header length plus the = minimum IPv4 fragment length > (RFC 1858, RFC 2132) > > - All packets having its DF bit =3D 0, have no risk to be discarded bec= ause of their size. > > - In particular, a 1500B packet can traverse paths whose PMTUs are as s= mall as 576 (or even as > small as 68). > > >=20 > It's late here, so I certainly won't claim an authoritative big > picture view. However, I like the following quote, particularly the > "biggest smallest" part : >=20 > "I forget the exact terminology, but Brian is talking about the biggest > packet one can send and be guaranteed it will not be fragmented. The is > 576 bytes for IPv4 and 1280 bytes for IPv6. >=20 > I think of it as the biggest smallest packet one can send :-)" >=20 > http://www.ops.ietf.org/lists/v6ops/v6ops.2007/msg00835.html I wish it were true that we could unambiguously count on 576 everywhere, but 576 is only a recommendation (e.g., see RFC3819) whereas 68 is the *law* as accurately cited by Remi. Thanks - Fred fred.l.templin@boeing.com > > In IPv6: > > - Packets cannot be fragmented in the network > > - A minimum PMTU is standardized, i.e. 1280B. > > - 1500B packets cannot traverse any IPv6 path having as PMTU 1480 (or 1= 280 or any value < 1500). > > > > This justifies a different behavior. > > > > Regards, > > RD > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From brian.e.carpenter@gmail.com Thu Mar 11 17:46:04 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADB3A3A69AE for ; Thu, 11 Mar 2010 17:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jinliyoA1txT for ; Thu, 11 Mar 2010 17:46:03 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 145F53A697E for ; Thu, 11 Mar 2010 17:45:58 -0800 (PST) Received: by pwj6 with SMTP id 6so269165pwj.31 for ; Thu, 11 Mar 2010 17:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=g4GtxVirQdl2MU5ZNSre0QfMPXU/QaHcEIvagTho8WM=; b=aQNWfiF8mOel81Epe8dDghRMhXZ39xpoxbQsFbdAeHzOkDEOGAivkK/oFflqFLuGAs Rc2CS78JbR443IXn+9mUzcWoIMN1toujV6QKsqFCQbCXftelx4oOLCGxVFWDrA2KCAJm Z8E4Jg44Nfawho0HQxpjhYI40JGsd9upopS+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=Ws9mqxj+cyBXyiOsSYHASnhXDw7vsk1XP4kcnrOh29yzdmCtXYq/Qc14V3B6XGQsf/ WjBwekiebHFHgeDs4AtENdJZWTJuD3nzyC+guYdvQ3SFWTMyWDh+1trGagN+1WV3qK+F UBxhbF2FkwEHRqhO3MCuAV7aghTgzqXHJt8BI= Received: by 10.140.57.12 with SMTP id f12mr2295740rva.234.1268358362284; Thu, 11 Mar 2010 17:46:02 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 20sm680040pzk.3.2010.03.11.17.46.00 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Mar 2010 17:46:01 -0800 (PST) Message-ID: <4B999CED.30802@gmail.com> Date: Fri, 12 Mar 2010 14:46:21 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Townsley References: <700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> <4B997E4B.6040009@cisco.com> In-Reply-To: <4B997E4B.6040009@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 01:46:04 -0000 On 2010-03-12 12:35, Mark Townsley wrote: > On 3/10/10 10:24 PM, Brian E Carpenter wrote: >> Mark, >> >> >>> Your right about 1280. However, following that logic, the IPv4 Internet >>> should have an MTU of no greater than 576 bytes, because blackholes are >>> possible with MTU's larger than that. Yet the common MTU on the IPv4 >>> Internet is 1500. >>> >> That's true today. But my experience while travelling and staying in >> random hotels towards the end of the dial-up era was that I often >> had to clamp the IPv4 MTU at (say) 512 to make things actually work. >> I've had experience with 6to4 of abject PMTUD failures with remote >> servers >> trying to do 1480. So I think that Remy is correct as far as a fail safe >> solution *today* goes. > And thank goodness we still don't fragment all IPv4 traffic >= 512 bytes. >> Since 6RD is very much a transitional technique >> before an ISP is ready to run native, I don't see this as a significant >> inefficiency. >> > The problem in this logic is that the argument for 1280 is not about the > MTU within the confines of the 6rd deployment, but outside across the > Internet. As such, it would apply equally to native IPv6 as it would to > 6rd. My experience was that while I was using 6to4 I experienced MTU and MSS related problems, and they went away as soon as the university gave me native connectivity. I can't explain that rationally, of course. Brian From remi.despres@free.fr Fri Mar 12 02:38:34 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29FA3A67DD for ; Fri, 12 Mar 2010 02:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gUVSC5t7r3b for ; Fri, 12 Mar 2010 02:38:33 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 6B8C53A65A6 for ; Fri, 12 Mar 2010 02:38:30 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id ADF22E081C4; Fri, 12 Mar 2010 11:38:32 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 71802E08010; Fri, 12 Mar 2010 11:38:29 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4B997E4B.6040009@cisco.com> Date: Fri, 12 Mar 2010 11:38:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <700287C3-4EAA-4027-8CCC-17201B628CDB@f ree.fr> <4B8CD37A.5090203@gmail.com> <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> <4B997E4B.6040009@cisco.com> To: Mark Townsley X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 10:38:34 -0000 Le 12 mars 2010 =E0 00:35, Mark Townsley a =E9crit : > On 3/10/10 10:24 PM, Brian E Carpenter wrote: ... >>> That's true today. But my experience while travelling and staying in >> random hotels towards the end of the dial-up era was that I often >> had to clamp the IPv4 MTU at (say) 512 to make things actually work. >> I've had experience with 6to4 of abject PMTUD failures with remote = servers >> trying to do 1480. So I think that Remy is correct as far as a fail = safe >> solution *today* goes. > And thank goodness we still don't fragment all IPv4 traffic >=3D 512 = bytes. >> Since 6RD is very much a transitional technique >> before an ISP is ready to run native, I don't see this as a = significant >> inefficiency. >> =20 > The problem in this logic is that the argument for 1280 is not about = the MTU within the confines of the 6rd deployment, but outside across = the Internet. As such, it would apply equally to native IPv6 as it would = to 6rd. Yes, it DOES apply also to directly native IPv6. That's why it makes sense, in a 6rd RFC, to avoid dealing with any = recommendation to advertise on a LAN link another MTU than that of the = link itself. This means deleting this sentence: "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined = automatically or configured directly, on the LAN side by setting the MTU = option in Router Advertisements [RFC4861] messages to the 6rd Tunnel = MTU." RD= From yiu_lee@cable.comcast.com Fri Mar 12 10:16:29 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5374B3A6892; Fri, 12 Mar 2010 10:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.144 X-Spam-Level: *** X-Spam-Status: No, score=3.144 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APBGAFQMBn1N; Fri, 12 Mar 2010 10:16:28 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 687A33A6862; Fri, 12 Mar 2010 10:16:06 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.88335500; Fri, 12 Mar 2010 13:15:55 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 13:15:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 72.79.73.126 ([72.79.73.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Mar 2010 18:15:54 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3351244548_4020799" Date: Fri, 12 Mar 2010 13:15:48 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Softwires] [dhcwg] 6rd LC - summary of comments Thread-Index: AcrCEAo18oCQzNKt3ESiGAybjwIwjQ== From: "Lee, Yiu" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Durand, Alain" , "softwires" , "DHC WG" X-OriginalArrivalTime: 12 Mar 2010 18:15:56.0396 (UTC) FILETIME=[0F3642C0:01CAC210] Cc: "Templin, Fred L" Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 18:16:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3351244548_4020799 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable +1. I agree with the current text to handle MTU and I support to move forward for this draft. On 3/8/10 5:25 PM, "R=E9mi Despr=E9s" wrote: >=20 > Le 8 mars 2010 =E0 21:00, Templin, Fred L a =E9crit : >=20 >> With SEAL, the tunnel egress can choose to reassemble as much >> or as little as it likes, with the limiting case being that the >> egress performs no reassembly at all. In that case, SEAL still >> provides value since the tunnel will still be able to support >> larger MTUs (e.g., 9KB) as long as all links in the SP network >> between ingress->egress support an MTU at least that large. >=20 > The discussion on SEAL, despite some interesting technical issues, does n= ot > belong to this last call discussion: > - 6rd is an transition technique which, to be as useful as it can be for = rapid > IPv6 deployments, should be stabilized asap. > - The DHCP option, which is specified in this document and nowhere else i= s > urgent. > - Combining SEAL with 6rd is a disjoint subject. >=20 >=20 >> - potential black holes when ICMPs can't be translated >=20 > - There is no potential blackhole caused by 6rd per se. > - Potential blackholes of IPv6 packets as long as ICMPv6 error messages a= nd > PMTUD are not treated properly belong to IPv6 in general, not to 6rd. > - Such blackholes can be completely avoided in the short term, despite bu= ggy > ICMPv6 and/or PMTUD treatments, by sending IPv6 packets that don't exceed= 1280 > octets, the guaranteed IPv6 path MTU of RFC 2460. > - Provided *the last sentence of the section 9.1 on MTUs is deleted* (as > already proposed in my previous e-mail), the document is therefore sound = in > this respect. =20 >=20 > IMHO, with modifications Ole has listed, and with the sentence deletion a= bove, > the draft can be accepted. >=20 > Regards, > RD >=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --B_3351244548_4020799 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBT70t/VRN6uWKmaeFbm4ylb5oP3fzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAzMTIxODE1NDhaMA0GCSqGSIb3DQEBAQUABIIBAKb/ PEkDvrlmA1ULEe63ZEO+Rc5BgwDQZASo+P7A5agALdiPG/Z15J0yZInh2xBqkXLrwkhmW/Jl Bbq2F9bvvSBgDzPAX0SmGASvhYjEY/X66RaDqdFTnFdFc39nWACFZzipxYAhIKcRSERuHLwo n0W7cx94w3CwOmXVnvq6PcayG9REQ+clsRo0sG344KMQmISWLZpThij4/xnGnscCUMhwm8Ut tzHnlRI3vgfCPQlXze2MRrAJ6b+fHNPer0KhRj/ZAR7XNgCxpx96jCyn84KxbAa4sofX31w+ RkwBzpgjEaTEKelWmJcZk0wRlt2FGIEbrI/TqyRQLvw0n6o9lXA= --B_3351244548_4020799-- From yiu_lee@cable.comcast.com Fri Mar 12 10:34:18 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F693A6848 for ; Fri, 12 Mar 2010 10:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=4.770, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8YGLy6m2q1u for ; Fri, 12 Mar 2010 10:34:17 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 5AEF73A68CD for ; Fri, 12 Mar 2010 10:34:09 -0800 (PST) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74177686; Fri, 12 Mar 2010 13:34:11 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 13:34:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 72.79.73.126 ([72.79.73.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Mar 2010 18:34:11 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3351245649_4104101" Date: Fri, 12 Mar 2010 13:34:09 -0500 Message-ID: In-Reply-To: <783A5276-3851-4558-84DF-E5137E380ABC@nttv6.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Softwires] Fwd: New Version Notification for draft-arifumi-softwire-dslite-global-addr-00 Thread-Index: AcrCEpp0AdA5VRDQJkaH1AoYYY+57Q== From: "Lee, Yiu" To: "Arifumi Matsumoto" , X-OriginalArrivalTime: 12 Mar 2010 18:34:13.0072 (UTC) FILETIME=[9CE1BD00:01CAC212] Subject: Re: [Softwires] Fwd: New Version Notification for draft-arifumi-softwire-dslite-global-addr-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 18:34:18 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3351245649_4104101 Content-type: text/plain; charset="ISO-2022-JP" Content-transfer-encoding: 7bit Hi Arifumi, I tried to understand the rationale of this draft. So, are you thinking there is a scenario where a customer is on a DS-lite access network but the ISP still want to give him public v4 access? So the AFTR won't need to perform NAT-44 function for this customer? Thanks, Yiu On 3/10/10 6:04 AM, "Arifumi Matsumoto" wrote: > Hi, > > I submitted a very simple draft. > Any comments are welcome. > > http://tools.ietf.org/html/draft-arifumi-softwire-dslite-global-addr-00 > > Begin forwarded message: > >> $B:9=P?M(B: IETF I-D Submission Tool >> $BF|;~(B: 2010$BG/(B3$B7n(B2$BF|(B 09:14:43JST >> $B08@h(B: arifumi@nttv6.net >> Cc: fujisaki@syce.net >> $B7oL>(B: New Version Notification for draft-arifumi-softwire-dslite-global-addr-00 >> >> >> A new version of I-D, draft-arifumi-softwire-dslite-global-addr-00.txt has >> been successfuly submitted by Arifumi Matsumoto and posted to the IETF >> repository. >> >> Filename: draft-arifumi-softwire-dslite-global-addr >> Revision: 00 >> Title: Global IPv4 Address Configuration Option for DS-Lite >> Creation_date: 2010-03-02 >> WG ID: Independent Submission >> Number_of_pages: 6 >> >> Abstract: >> When an ISP tries to deploy IPv6 and take an action for IPv4 address >> depletion, DS-Lite is reasonable approach for solving both of the >> problems. However, it is troublesome for an ISP to have the existing >> IPv4 service facilities and DS-Lite facilities at the same time for >> not a short period of time. This document proposes a mechanism to >> assign an IPv4 global address in DS-Lite framework, which makes every >> customer to move to DS-Lite based network, and enables an ISP to >> maintain single facility of the service network. >> >> >> >> The IETF Secretariat. >> >> > > > -- > Arifumi Matsumoto > Secure Communication Project > NTT Information Sharing Platform Laboratories > E-mail: arifumi@nttv6.net > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --B_3351245649_4104101 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBR2uiXB5S53uC/Xt4slfo/n7CS+0zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAzMTIxODM0MDlaMA0GCSqGSIb3DQEBAQUABIIBADjl IjPaSThpR+IGqXiy5ThfRPYCSZH88x3g2aX3h4gaxS7saXVRPfMrquHANTPi67ztMAJtcbti F7kYjZbuxCVIWYgCPi7g9H8qi0jjnD/gpfV6ljPoS26eTaMVH1kHTkaB2I8jK9hQ+fV6e8+1 7sYEfabSGcV+iCA/0bPU0gUhxs6z+LVkxBSYgs5ifiXMRtqEsd67HRTwdOsGrURUkQAQvOQN HUN84ZW93xAw6bQCnvnwXnB/qknoanCKhiJVHN8c+wYKBnq61AxOw4h1DQZHxNYS1Po/TTwA U+gpqKYf6zHDBVCmYTVuuJiKTgA0eBQl6skDecAaZIcRTVy3f+c= --B_3351245649_4104101-- From yiu_lee@cable.comcast.com Fri Mar 12 14:06:31 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D48313A688B; Fri, 12 Mar 2010 14:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.759 X-Spam-Level: X-Spam-Status: No, score=0.759 tagged_above=-999 required=5 tests=[AWL=-2.385, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3, RCVD_NUMERIC_HELO=2.067, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-hixbcFvZxE; Fri, 12 Mar 2010 14:06:31 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 963203A6852; Fri, 12 Mar 2010 14:06:30 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.88352384; Fri, 12 Mar 2010 17:06:18 -0500 Received: from NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 17:06:19 -0500 Received: from mail pickup service by NJCHLEXCMB01.cable.comcast.com with Microsoft SMTPSVC; Fri, 12 Mar 2010 17:05:45 -0500 Received: from PAOAKEXCSMTP02.cable.comcast.com ([10.52.116.31]) by NJCHLEXCMB01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 15:32:04 -0500 Received: from PACDCEXCSMTP04.cable.comcast.com ([24.40.15.118]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 13:17:53 -0500 Received: from cable.comcast.com ([24.40.8.142]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 13:17:53 -0500 Received: from ([24.40.8.143]) by pacdcimi01.cable.comcast.com with ESMTP id 5503565.90736778; Fri, 12 Mar 2010 13:17:49 -0500 Received: from ([64.170.98.32]) by pacdcedge01.cable.comcast.com with ESMTP id 5302275.EDGE; Fri, 12 Mar 2010 13:17:48 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93FC83A6862; Fri, 12 Mar 2010 10:17:41 -0800 (PST) X-Original-To: dhcwg@core3.amsl.com Delivered-To: dhcwg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5374B3A6892; Fri, 12 Mar 2010 10:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APBGAFQMBn1N; Fri, 12 Mar 2010 10:16:28 -0800 (PST) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 687A33A6862; Fri, 12 Mar 2010 10:16:06 -0800 (PST) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.88335500; Fri, 12 Mar 2010 13:15:55 -0500 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 13:15:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 72.79.73.126 ([72.79.73.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Mar 2010 18:15:54 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Date: Fri, 12 Mar 2010 13:15:48 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Softwires] [dhcwg] 6rd LC - summary of comments Thread-Index: AcrCEAo18oCQzNKt3ESiGAybjwIwjQ== From: "Lee, Yiu" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , "Durand, Alain" , "softwires" , "DHC WG" X-OriginalArrivalTime: 12 Mar 2010 18:15:56.0396 (UTC) FILETIME=[0F3642C0:01CAC210] X-Mailman-Approved-At: Fri, 12 Mar 2010 10:17:28 -0800 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: multipart/mixed; boundary="===============2023037908==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org X-esp: ESP<-47>= SHA:<0> UHA:<9> ISC:<0> BAYES:<0> SenderID:<0> DKIM:<0> TS:<-59> SIG: DSC:<0> TRU_scam_spam: <0> TRU_ru_spamsubj: <0> TRU_playsites: <0> TRU_spam2: <0> TRU_embedded_image_spam: <0> TRU_profanity_spam: <0> TRU_legal_spam: <0> TRU_stock_spam: <0> TRU_watch_spam: <0> TRU_money_spam: <0> URL Real-Time Signatures: <0> TRU_marketing_spam: <3> TRU_urllinks: <0> TRU_phish_spam: <0> TRU_lotto_spam: <0> TRU_medical_spam: <0> TRU_html_image_spam: <0> TRU_freehosting: <0> TRU_adult_spam: <0> TRU_misc_spam: <0> TRU_spam1: <0> Cc: "Templin, Fred L" Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments X-BeenThere: softwires@ietf.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 22:06:31 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2023037908== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3351244548_4020799" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3351244548_4020799 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable +1. I agree with the current text to handle MTU and I support to move forward for this draft. On 3/8/10 5:25 PM, "R=E9mi Despr=E9s" wrote: >=20 > Le 8 mars 2010 =E0 21:00, Templin, Fred L a =E9crit : >=20 >> With SEAL, the tunnel egress can choose to reassemble as much >> or as little as it likes, with the limiting case being that the >> egress performs no reassembly at all. In that case, SEAL still >> provides value since the tunnel will still be able to support >> larger MTUs (e.g., 9KB) as long as all links in the SP network >> between ingress->egress support an MTU at least that large. >=20 > The discussion on SEAL, despite some interesting technical issues, does n= ot > belong to this last call discussion: > - 6rd is an transition technique which, to be as useful as it can be for = rapid > IPv6 deployments, should be stabilized asap. > - The DHCP option, which is specified in this document and nowhere else i= s > urgent. > - Combining SEAL with 6rd is a disjoint subject. >=20 >=20 >> - potential black holes when ICMPs can't be translated >=20 > - There is no potential blackhole caused by 6rd per se. > - Potential blackholes of IPv6 packets as long as ICMPv6 error messages a= nd > PMTUD are not treated properly belong to IPv6 in general, not to 6rd. > - Such blackholes can be completely avoided in the short term, despite bu= ggy > ICMPv6 and/or PMTUD treatments, by sending IPv6 packets that don't exceed= 1280 > octets, the guaranteed IPv6 path MTU of RFC 2460. > - Provided *the last sentence of the section 9.1 on MTUs is deleted* (as > already proposed in my previous e-mail), the document is therefore sound = in > this respect. =20 >=20 > IMHO, with modifications Ole has listed, and with the sentence deletion a= bove, > the draft can be accepted. >=20 > Regards, > RD >=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --B_3351244548_4020799 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBT70t/VRN6uWKmaeFbm4ylb5oP3fzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAzMTIxODE1NDhaMA0GCSqGSIb3DQEBAQUABIIBAKb/ PEkDvrlmA1ULEe63ZEO+Rc5BgwDQZASo+P7A5agALdiPG/Z15J0yZInh2xBqkXLrwkhmW/Jl Bbq2F9bvvSBgDzPAX0SmGASvhYjEY/X66RaDqdFTnFdFc39nWACFZzipxYAhIKcRSERuHLwo n0W7cx94w3CwOmXVnvq6PcayG9REQ+clsRo0sG344KMQmISWLZpThij4/xnGnscCUMhwm8Ut tzHnlRI3vgfCPQlXze2MRrAJ6b+fHNPer0KhRj/ZAR7XNgCxpx96jCyn84KxbAa4sofX31w+ RkwBzpgjEaTEKelWmJcZk0wRlt2FGIEbrI/TqyRQLvw0n6o9lXA= --B_3351244548_4020799-- --===============2023037908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --===============2023037908==-- From remi.despres@free.fr Sat Mar 13 03:42:29 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505FE3A6855; Sat, 13 Mar 2010 03:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POIRcznT7U6j; Sat, 13 Mar 2010 03:42:28 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 0F8653A67A7; Sat, 13 Mar 2010 03:38:25 -0800 (PST) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 9D5ACE08060; Sat, 13 Mar 2010 12:38:26 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 08529E0806F; Sat, 13 Mar 2010 12:38:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sat, 13 Mar 2010 12:38:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <205146B8-3DC2-4DE8-BE5D-CC1858033D79@free.fr> References: To: "Lee, Yiu" X-Mailer: Apple Mail (2.1077) Cc: softwires , "Templin, Fred L" , DHC WG Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments - MTU issue X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 11:42:29 -0000 Lee, 1. Good to have support for the 6rd RFC to progress now quickly. How to interpret your support is however not 100% clear: - either you agree on ALL what I propose, as the +1 suggests (i.e. with = the deletion of the last sentence of 9.1). - or you agree ONLY if this sentence is not deleted (as your "with the = current text" suggests). This is in fact a good opportunity to summarize, after many mails = exchanged on-list and off-list, the problem with the following sentence: << A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined = automatically or configured directly, on the LAN side by setting the MTU = option in Router Advertisements [RFC4861] messages to the 6rd Tunnel = MTU. >> 2. The rationale to delete the sentence is AFAICT: - A 6rd RFC is NOT the right place to recommend that the MTU advertised = to host, on a given link, should differ from the real MTU of this link: = the purpose of such a recommendation concerns IPv6 in general, not = specifically 6rd.=20 - Not having the sentence in the 6rd RFC doesn't prevent implementations = to advertise reduced MTUs.=20 - In any case, if advertising reduced MTUs is recommended, the = technically consistent value is fixed (not ISP dependent), and is 1280 = as explained below. 3. The reason why, for IPv6 in general, 1280 is the right default transmit = MTU comes from the following facts: - 1280 is the PMTU that is guaranteed to be supported across all IPv6 = paths. (Most paths are expected to have larger local MTUs than 1280, = e.g. 1480 for 6to4 or 6rd across Ethernet links, but the only guarantee = is "at least 1280").=20 - Standardizing a minimum PMTU was not needed in IPv4 because = fragmentation is permitted within the network, which is NOT the case in = IPv6. (The real minimum in IPv4, which is header + smallest fragment, = i.e. 68, is not, like 1280, a practicable value for a transmit MTU).=20 - 1280 is such that, on links having the most common MTU, i.e. 1500, a = small number of piled up encapsulations can be supported, with a good = margin in typical cases.=20 - Hosts having 1280 as their default transmit MTU are not prevented from = using larger MTUs on all e2e paths known to have larger MTUs: PMTU = Discovery is designed for this. (PMTUD has some reported short term = problems, but this should eventually be fixed.) 4. Coming back to the 6rd draft: - The text says: "The 6rd Tunnel MTU should be set to the known IPv4 MTU minus the size = of the encapsulating IPv4 header (20 bytes). For example, if the IPv4 = MTU is known to be 1500 bytes, the 6rd Tunnel MTU may be set to 1480 = bytes". The first sentence clearly suggests that some ISPs will have 6rd tunnel = MTUs smaller than 1480.=20 - Now, assume such an ISP has 1400 as its tunnel MTU. Then, if a 1480B = packet is sent to it (from some ISP where 1480 is supported) it will = fall into a blackhole: it will be discarded when entering the ISP = network that has the 1400 MTU.=20 Unless I am mistaken somewhere, the 6rd RFC MUST NOT recommended this to = happen. =20 On the other hand, if all hosts send 1280B packets maximum, the standard = value has its intended effect: NO MTU RELATED BLACKHOLE.=20 There is a cost in terms of performance of this MTU security but, thanks = to a good choice of the standard value, this cost remains quit = reasonable in typical cases: in the extreme case of TCP packets having = all their maximum size, using 12810 instead of 1280 as transmit MTU = reduces the number of packets by less than 17%). Note also that the transmit MTU of Teredo is AFAICT 1280. 5.=20 Conclusion: as more and more IPv6 will be deployed, it will be more and = more important to make all IPv6 specifications right, and for this to = understand how to avoid future blackholes. =20 Best regards, RD Le 12 mars 2010 =E0 19:15, Lee, Yiu a =E9crit : > +1. I agree with the current text to handle MTU and I support to move > forward for this draft. >=20 >=20 > On 3/8/10 5:25 PM, "R=E9mi Despr=E9s" wrote: >=20 >>=20 >> Le 8 mars 2010 =E0 21:00, Templin, Fred L a =E9crit : >>=20 >>> With SEAL, the tunnel egress can choose to reassemble as much >>> or as little as it likes, with the limiting case being that the >>> egress performs no reassembly at all. In that case, SEAL still >>> provides value since the tunnel will still be able to support >>> larger MTUs (e.g., 9KB) as long as all links in the SP network >>> between ingress->egress support an MTU at least that large. >>=20 >> The discussion on SEAL, despite some interesting technical issues, = does not >> belong to this last call discussion: >> - 6rd is an transition technique which, to be as useful as it can be = for rapid >> IPv6 deployments, should be stabilized asap. >> - The DHCP option, which is specified in this document and nowhere = else is >> urgent. >> - Combining SEAL with 6rd is a disjoint subject. >>=20 >>=20 >>> - potential black holes when ICMPs can't be translated >>=20 >> - There is no potential blackhole caused by 6rd per se. >> - Potential blackholes of IPv6 packets as long as ICMPv6 error = messages and >> PMTUD are not treated properly belong to IPv6 in general, not to 6rd. >> - Such blackholes can be completely avoided in the short term, = despite buggy >> ICMPv6 and/or PMTUD treatments, by sending IPv6 packets that don't = exceed 1280 >> octets, the guaranteed IPv6 path MTU of RFC 2460. >> - Provided *the last sentence of the section 9.1 on MTUs is deleted* = (as >> already proposed in my previous e-mail), the document is therefore = sound in >> this respect. =20 >>=20 >> IMHO, with modifications Ole has listed, and with the sentence = deletion above, >> the draft can be accepted. >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Mar 13 16:46:56 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6B843A689B for ; Sat, 13 Mar 2010 16:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EczPKxi2I6WU for ; Sat, 13 Mar 2010 16:46:55 -0800 (PST) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 4F1543A683E for ; Sat, 13 Mar 2010 16:46:50 -0800 (PST) Received: from 219-90-180-250.ip.adam.com.au ([219.90.180.250] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Nqbyk-0004Lb-Sz; Sun, 14 Mar 2010 11:16:51 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id C78004930C; Sun, 14 Mar 2010 11:16:49 +1030 (CST) Date: Sun, 14 Mar 2010 11:16:49 +1030 From: Mark Smith To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Message-ID: <20100314111649.407f51db@opy.nosense.org> In-Reply-To: References: <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> <4B997E4B.6040009@cisco.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 00:46:56 -0000 On Fri, 12 Mar 2010 11:38:28 +0100 R=E9mi Despr=E9s wrote: >=20 > Le 12 mars 2010 =E0 00:35, Mark Townsley a =E9crit : >=20 > > On 3/10/10 10:24 PM, Brian E Carpenter wrote: > ... > >>> That's true today. But my experience while travelling and staying in > >> random hotels towards the end of the dial-up era was that I often > >> had to clamp the IPv4 MTU at (say) 512 to make things actually work. > >> I've had experience with 6to4 of abject PMTUD failures with remote ser= vers > >> trying to do 1480. So I think that Remy is correct as far as a fail sa= fe > >> solution *today* goes. > > And thank goodness we still don't fragment all IPv4 traffic >=3D 512 by= tes. > >> Since 6RD is very much a transitional technique > >> before an ISP is ready to run native, I don't see this as a significant > >> inefficiency. > >> =20 > > The problem in this logic is that the argument for 1280 is not about th= e MTU within the confines of the 6rd deployment, but outside across the Int= ernet. As such, it would apply equally to native IPv6 as it would to 6rd. >=20 > Yes, it DOES apply also to directly native IPv6. > That's why it makes sense, in a 6rd RFC, to avoid dealing with any recomm= endation to advertise on a LAN link another MTU than that of the link itsel= f. >=20 > This means deleting this sentence: > "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined automat= ically or configured directly, on the LAN side by setting the MTU option in= Router Advertisements [RFC4861] messages to the 6rd Tunnel MTU." >=20 So all communications from hosts on the LAN is to the Internet?=20 If you shrink the LAN MTU for the tunnel's benefit (or even just the native IPv6 Internet's benefit), you also shrink the LAN's MTU for any communications between the devices on the LAN. Consider the performance impact of dropping the LAN MTU to 1280 if the chosen LAN MTU is 9000 bytes for local LAN performance. I don't think the presence of a 6RD tunnel always implies that the dominant traffic path is to and from the Internet and the LAN - it could be there just for remote management / reachability e.g. ssh, email, snmp, occasional software / OS upgrades and updates. An example of such a scenario might be where somebody puts a HPC cluster in remote colo somewhere in the world to gain the benefits of cheaper cooling and power, and the ISP/Colo provider uses 6RD to provide interim IPv6 connectivity. Because a very high percentage of large amounts traffic is local to the cluster, larger LAN MTUs provide performance benefits. That's all assuming that the directly upstream router is the 6RD tunnel end-point. If there is a routed local IPv6 infrastructure, does the 6RD tunnel's MTU now force the whole site to have a 1280 byte MTU? These are the sorts of scenarios which have made me wonder whether there should be some sort of mechanism to express different off-link and on-link MTUs or on-site and off-site MTUs (distinguished by an on-site aggregate prefix). Regards, Mark. From brian.e.carpenter@gmail.com Sat Mar 13 17:19:36 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A1F3A6833 for ; Sat, 13 Mar 2010 17:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XarvSr+UxFCD for ; Sat, 13 Mar 2010 17:19:35 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 78B043A67F8 for ; Sat, 13 Mar 2010 17:19:25 -0800 (PST) Received: by gwj18 with SMTP id 18so967858gwj.31 for ; Sat, 13 Mar 2010 17:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=fB8qBLdDVsUAan7FkSzTbfiP79/sz5LTCACV/CLaRkQ=; b=Fj1iT6k/rTcKb6YXfgiTiHtzCZQHk9y+E0gzc1L/24xUxE7VTTjiKj0gVo35D4zsTO 5p4m9+v+zTKE8HhlbIyrtsBVTPqtvYhQR9CXFQ+N1aIt4Kgumyc7Efj0VTJmTVqXt5Lb DstB5vC8ScqNTqHHIPZktMMjwkUyfsNCvgFOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=hujUH2chipcupwYXE6Y1DxW72j5S43McSb4TiFm4rfvT0B/sLmLOWuhnUxsHgf1vpY ZWBXPZpuO9OXzSJZ9SeCt8ThZE7cF3CZYzRjZ95S8vdHHvXMnh/9+qUfWYsZSs2e939O Ed36yGKwKIggD2Mo8CTjdwdUoGzAeEizYh8do= Received: by 10.101.128.25 with SMTP id f25mr2563693ann.95.1268529569335; Sat, 13 Mar 2010 17:19:29 -0800 (PST) Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id 20sm2516974iwn.1.2010.03.13.17.19.26 (version=SSLv3 cipher=RC4-MD5); Sat, 13 Mar 2010 17:19:28 -0800 (PST) Message-ID: <4B9C399A.1000800@gmail.com> Date: Sun, 14 Mar 2010 14:19:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Smith References: <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> <4B997E4B.6040009@cisco.com> <20100314111649.407f51db@opy.nosense.org> In-Reply-To: <20100314111649.407f51db@opy.nosense.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 01:19:37 -0000 On 2010-03-14 13:46, Mark Smith wrote: ... > These are the sorts of scenarios which have made me wonder whether > there should be some sort of mechanism to express different off-link > and on-link MTUs or on-site and off-site MTUs (distinguished by an > on-site aggregate prefix). I hope they're discussing that over in MIF. A different set of settings (not just MTU) per prefix seems entirely rational; a nice large MTU for a ULA prefix might make sense. Brian From ipng@69706e6720323030352d30312d31340a.nosense.org Sat Mar 13 18:00:04 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4E03A6868 for ; Sat, 13 Mar 2010 18:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0q7SDRW0yeW for ; Sat, 13 Mar 2010 18:00:04 -0800 (PST) Received: from smtp2.adam.net.au (smtp2.adam.net.au [202.136.110.251]) by core3.amsl.com (Postfix) with ESMTP id 57A7B3A686C for ; Sat, 13 Mar 2010 18:00:03 -0800 (PST) Received: from 219-90-180-250.ip.adam.com.au ([219.90.180.250] helo=opy.nosense.org) by smtp2.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1Nqd7c-0002my-Qr; Sun, 14 Mar 2010 12:30:05 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 604724930C; Sun, 14 Mar 2010 12:30:04 +1030 (CST) Date: Sun, 14 Mar 2010 12:30:03 +1030 From: Mark Smith To: Brian E Carpenter Message-ID: <20100314123003.1022a309@opy.nosense.org> In-Reply-To: <4B9C399A.1000800@gmail.com> References: <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> <4B997E4B.6040009@cisco.com> <20100314111649.407f51db@opy.nosense.org> <4B9C399A.1000800@gmail.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 02:00:05 -0000 On Sun, 14 Mar 2010 14:19:22 +1300 Brian E Carpenter wrote: > On 2010-03-14 13:46, Mark Smith wrote: > ... > > These are the sorts of scenarios which have made me wonder whether > > there should be some sort of mechanism to express different off-link > > and on-link MTUs or on-site and off-site MTUs (distinguished by an > > on-site aggregate prefix). > > I hope they're discussing that over in MIF. A different set of settings > (not just MTU) per prefix seems entirely rational; a nice large MTU > for a ULA prefix might make sense. > I've thought you could go a bit further, allowing nodes to have different MTUs on the local link. The current RA announced MTU is made the offlink unicast/multicast MTU, onlink multicast MTU and default MTU, if the following options aren't understood. E.g. for the 6RD scenario, this would be 1280 bytes. Another RA option is created to announce the maximum MTU of the link, being the largest that the link supports e.g. the maximum frame size the link layer can forward. If all switches were configured to support 9K byte frames, this value would be 9K. This would default to the normal or common link layer MTU values e.g. 1500 bytes for ethernet. A ND NA option is created for a node to announce it's local MRU. A sending node that understands these RA/ND NA options would then be able to send unicast packets up to the smallest value of it's local MTU, the maximum link MTU and the neighbor's MRU. E.g. if the local interface only supports 8K MTU/MRU, then in that node's NAs it would announce that 8K MRU, and other nodes that supported 9K MTUs would only send 8K frames to it. Regards, Mark. From remi.despres@free.fr Mon Mar 15 00:10:24 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D7F03A6917 for ; Mon, 15 Mar 2010 00:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEXSljl-+ZK2 for ; Mon, 15 Mar 2010 00:10:21 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 7D8283A6774 for ; Mon, 15 Mar 2010 00:10:16 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 2D167E08067; Mon, 15 Mar 2010 08:10:19 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 1BE4CE080A5; Mon, 15 Mar 2010 08:10:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20100314111649.407f51db@opy.nosense.org> Date: Mon, 15 Mar 2010 08:10:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1FF3C992-3BBB-48C2-8B11-381841111BD1@free.fr> References: <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> <4B997E4B.6040009@cisco.com> <20100314111649.407f51db@opy.n osense.org> To: Mark Smith X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 07:10:24 -0000 Mark, Note that the first and main purpose of this discussion is a final = consensus on the 6rd RFC, not to solve now ALL IPv6 remaining problems. In this context, the point I make is: 1) EITHER the proposed RFC continues to recommend that an MTU smaller = than that of the LAN link be advertised in RAs, in which case the = recommended value SHOULD BE 1280, 2) OR, the proposed RFC says nothing about RA-advertised MTUs.=20 Because choice 1 deals with a problem that is not 6rd specific, I = proposed to agree on choice 2. In view of your comments, choice 2 seems to also be yours. Would you confirm? =20 Regards, RD Le 14 mars 2010 =E0 01:46, Mark Smith a =E9crit : > On Fri, 12 Mar 2010 11:38:28 +0100 > R=E9mi Despr=E9s wrote: >=20 >>=20 >> Le 12 mars 2010 =E0 00:35, Mark Townsley a =E9crit : >>=20 >>> On 3/10/10 10:24 PM, Brian E Carpenter wrote: >> ... >>>>> That's true today. But my experience while travelling and staying = in >>>> random hotels towards the end of the dial-up era was that I often >>>> had to clamp the IPv4 MTU at (say) 512 to make things actually = work. >>>> I've had experience with 6to4 of abject PMTUD failures with remote = servers >>>> trying to do 1480. So I think that Remy is correct as far as a fail = safe >>>> solution *today* goes. >>> And thank goodness we still don't fragment all IPv4 traffic >=3D 512 = bytes. >>>> Since 6RD is very much a transitional technique >>>> before an ISP is ready to run native, I don't see this as a = significant >>>> inefficiency. >>>>=20 >>> The problem in this logic is that the argument for 1280 is not about = the MTU within the confines of the 6rd deployment, but outside across = the Internet. As such, it would apply equally to native IPv6 as it would = to 6rd. >>=20 >> Yes, it DOES apply also to directly native IPv6. >> That's why it makes sense, in a 6rd RFC, to avoid dealing with any = recommendation to advertise on a LAN link another MTU than that of the = link itself. >>=20 >> This means deleting this sentence: >> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined = automatically or configured directly, on the LAN side by setting the MTU = option in Router Advertisements [RFC4861] messages to the 6rd Tunnel = MTU." >>=20 >=20 > So all communications from hosts on the LAN is to the Internet?=20 Of course not. I wonder how you reached this conclusion. > If you shrink the LAN MTU for the tunnel's benefit (or even just the > native IPv6 Internet's benefit), you also shrink the LAN's MTU for any > communications between the devices on the LAN. Consider the = performance > impact of dropping the LAN MTU to 1280 if the chosen LAN MTU is 9000 > bytes for local LAN performance. I don't think the presence of a 6RD > tunnel always implies that the dominant traffic path is to and from = the > Internet and the LAN It doesn't. > - it could be there just for remote management / > reachability e.g. ssh, email, snmp, occasional software / OS upgrades > and updates. An example of such a scenario might be where somebody = puts > a HPC cluster in remote colo somewhere in the world to gain the > benefits of cheaper cooling and power, and the ISP/Colo provider uses > 6RD to provide interim IPv6 connectivity. Because a very high > percentage of large amounts traffic is local to the cluster, larger = LAN > MTUs provide performance benefits. >=20 > That's all assuming that the directly upstream router is the 6RD = tunnel > end-point. If there is a routed local IPv6 infrastructure, does the > 6RD tunnel's MTU now force the whole site to have a 1280 byte MTU? >=20 > These are the sorts of scenarios which have made me wonder whether > there should be some sort of mechanism to express different off-link > and on-link MTUs or on-site and off-site MTUs (distinguished by an > on-site aggregate prefix). >=20 >=20 > Regards, > Mark. From remi.despres@free.fr Mon Mar 15 00:24:35 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56FFF3A6A67 for ; Mon, 15 Mar 2010 00:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQGDu5ZmyP1z for ; Mon, 15 Mar 2010 00:24:34 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 055D03A6A6E for ; Mon, 15 Mar 2010 00:22:41 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 2F574E08134; Mon, 15 Mar 2010 08:22:44 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 240BFE08058; Mon, 15 Mar 2010 08:22:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4B9C399A.1000800@gmail.com> Date: Mon, 15 Mar 2010 08:22:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <24E82607-6A46-4FF6-A35E-8E7049DFCB12@free.fr> References: <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> <4B997E4B.6040009@cisco.com> <20100314111649.407f51db@opy.nosense.org> <4B9C399A.1000800@gmail.com> To: Brian E Carpenter , Mark Smith X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 07:24:35 -0000 Mark, Brian,=20 Le 14 mars 2010 =E0 02:19, Brian E Carpenter a =E9crit : > On 2010-03-14 13:46, Mark Smith wrote: > ... >> These are the sorts of scenarios which have made me wonder whether >> there should be some sort of mechanism to express different off-link >> and on-link MTUs or on-site and off-site MTUs (distinguished by an >> on-site aggregate prefix). >=20 > I hope they're discussing that over in MIF. A different set of = settings > (not just MTU) per prefix seems entirely rational; a nice large MTU > for a ULA prefix might make sense. 1. On-link path MTU being a well defined concept, having two different = default transmit MTUs for on-link and off-link makes a lot of sense. +1 for this idea. +1 also for this discussion to take place in a larger context than the = 6rd RFC. (But 6man could IMHO be a better place than MIF, because the = solution also concerns single-interface hosts.) 2. Even better than TWO default transmit MTUs, hosts should in my = understanding have FOUR: on-link and off-link, IPv4 and IPv6. Agreed? (Of course, hosts that discover larger MTUs for some e2e paths can, = independently from default values, apply these MTUs to these identified = paths.) Regards, RD From Fred.L.Templin@boeing.com Mon Mar 15 08:28:48 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295663A6B68 for ; Mon, 15 Mar 2010 08:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjPTYpPQiG8U for ; Mon, 15 Mar 2010 08:28:47 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 238CD3A698F for ; Mon, 15 Mar 2010 08:28:47 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2FFSj5Z004532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Mar 2010 10:28:45 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2FFSig9014201; Mon, 15 Mar 2010 08:28:44 -0700 (PDT) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2FFSimS014196 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 15 Mar 2010 08:28:44 -0700 (PDT) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Mon, 15 Mar 2010 08:28:44 -0700 From: "Templin, Fred L" To: Mark Smith , Brian E Carpenter Date: Mon, 15 Mar 2010 08:28:42 -0700 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrDGhcoyjBdTOw/STWIGd/UlathQwBOWE/g Message-ID: References: <4B8DABEE.3030407 @gmail.com><629F7D3E-108D-43A1-B1E 0-921922D70AEF@employees.org><9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr><4B9 16BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com><74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org><4B980DF2.8 030201@gmail.com> <4B997E4B.6040009@cisco.com>< 20100314111649.407f51db@opy.nosense.org><4B9C399A.1000800@gmail.com> <20100314123003.1022a309@opy.nosense.org> In-Reply-To: <20100314123003.1022a309@opy.nosense.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 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:28:48 -0000 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Mark Smith > Sent: Saturday, March 13, 2010 6:00 PM > To: Brian E Carpenter > Cc: softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > On Sun, 14 Mar 2010 14:19:22 +1300 > Brian E Carpenter wrote: >=20 > > On 2010-03-14 13:46, Mark Smith wrote: > > ... > > > These are the sorts of scenarios which have made me wonder whether > > > there should be some sort of mechanism to express different off-link > > > and on-link MTUs or on-site and off-site MTUs (distinguished by an > > > on-site aggregate prefix). > > > > I hope they're discussing that over in MIF. A different set of settings > > (not just MTU) per prefix seems entirely rational; a nice large MTU > > for a ULA prefix might make sense. > > >=20 > I've thought you could go a bit further, allowing nodes to have > different MTUs on the local link. Iljitsch van Beijnum talked about this not long ago: http://tools.ietf.org/id/draft-van-beijnum-multi-mtu-02.txt I talked about it years and years ago: http://tools.ietf.org/id/draft-templin-ndiscmtu-00.txt Fred fred.l.templin@boeing.com=20 > The current RA announced MTU is made the offlink unicast/multicast MTU, > onlink multicast MTU and default MTU, if the following options aren't > understood. E.g. for the 6RD scenario, this would be 1280 bytes. >=20 > Another RA option is created to announce the maximum MTU of the link, > being the largest that the link supports e.g. the maximum frame > size the link layer can forward. If all switches were configured to > support 9K byte frames, this value would be 9K. This would default to > the normal or common link layer MTU values e.g. 1500 bytes for ethernet. >=20 > A ND NA option is created for a node to announce it's local MRU. A > sending node that understands these RA/ND NA options would then be able > to send unicast packets up to the smallest value of it's local > MTU, the maximum link MTU and the neighbor's MRU. E.g. if the local > interface only supports 8K MTU/MRU, then in that node's NAs it would > announce that 8K MRU, and other nodes that supported 9K MTUs would only > send 8K frames to it. >=20 >=20 > Regards, > Mark. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Fred.L.Templin@boeing.com Mon Mar 15 09:15:51 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84BD83A6BA7 for ; Mon, 15 Mar 2010 09:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtaKEiY6ndif for ; Mon, 15 Mar 2010 09:15:50 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id A0F9E3A6979 for ; Mon, 15 Mar 2010 09:15:50 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2FGFmQo012289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Mar 2010 09:15:48 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2FGFl5P000599; Mon, 15 Mar 2010 09:15:47 -0700 (PDT) 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 o2FGFlb2000572 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 15 Mar 2010 09:15:47 -0700 (PDT) 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, 15 Mar 2010 09:15:47 -0700 From: "Templin, Fred L" To: Brian E Carpenter , Mark Smith Date: Mon, 15 Mar 2010 09:15:46 -0700 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrDFG/+dat3E8oiRkGhRTgfP6X13wBRWz5w Message-ID: References: <4B8DABEE.303040 7@gmail.com> <629F7D3E-108D-43A 1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@fre e.fr> <4B916BA7.3080400@gmail.com><4B950EF1.6010304@cisco .com> <74EF8AD8-2D FE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158 .537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com><4B997E4B.6040009@ci sco.com> <20100314111649.407f51db@opy.nosense.org> <4B9C399A.1000800@gmail.com> In-Reply-To: <4B9C399A.1000800@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:15:51 -0000 Brian, > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Brian E Carpenter > Sent: Saturday, March 13, 2010 5:19 PM > To: Mark Smith > Cc: softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > On 2010-03-14 13:46, Mark Smith wrote: > ... > > These are the sorts of scenarios which have made me wonder whether > > there should be some sort of mechanism to express different off-link > > and on-link MTUs or on-site and off-site MTUs (distinguished by an > > on-site aggregate prefix). >=20 > I hope they're discussing that over in MIF. A different set of settings > (not just MTU) per prefix seems entirely rational; a nice large MTU > for a ULA prefix might make sense. If you want to consider the IPv6 6rd global for off-site communications only, then that would be doable but I still think we should try for 1500 or larger instead of 1280 if at all possible. If you then want to consider an IPv6 ULA for on-site communications with larger MTU, that would be fine too. Within the customer site, however, both the 6rd global and ULA can be serviced using ISATAP if native IPv6 is not yet available. Fred fred.l.templin@boeing.com > Brian > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ipng@69706e6720323030352d30312d31340a.nosense.org Mon Mar 15 09:42:32 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ADD43A67F2 for ; Mon, 15 Mar 2010 09:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPSIvg-czpYW for ; Mon, 15 Mar 2010 09:42:31 -0700 (PDT) Received: from smtp4.adam.net.au (smtp4.adam.net.au [202.136.110.247]) by core3.amsl.com (Postfix) with ESMTP id 78F9E3A6C11 for ; Mon, 15 Mar 2010 09:42:30 -0700 (PDT) Received: from 219-90-175-231.ip.adam.com.au ([219.90.175.231] helo=opy.nosense.org) by smtp4.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NrDN5-00043o-VI; Tue, 16 Mar 2010 03:12:28 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 482804930C; Tue, 16 Mar 2010 03:12:27 +1030 (CST) Date: Tue, 16 Mar 2010 03:12:26 +1030 From: Mark Smith To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Message-ID: <20100316031226.0d2e9a7e@opy.nosense.org> In-Reply-To: <1FF3C992-3BBB-48C2-8B11-381841111BD1@free.fr> References: <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> <4B997E4B.6040009@cisco.com> <20100314111649.407f51db@opy.n osense.org> <1FF3C992-3BBB-48C2-8B11-381841111BD1@free.fr> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:42:32 -0000 On Mon, 15 Mar 2010 08:10:16 +0100 R=E9mi Despr=E9s wrote: > Mark, >=20 > Note that the first and main purpose of this discussion is a final consen= sus on the 6rd RFC, not to solve now ALL IPv6 remaining problems. >=20 > In this context, the point I make is: > 1) EITHER the proposed RFC continues to recommend that an MTU smaller tha= n that of the LAN link be advertised in RAs, in which case the recommended = value SHOULD BE 1280, > 2) OR, the proposed RFC says nothing about RA-advertised MTUs.=20 >=20 > Because choice 1 deals with a problem that is not 6rd specific, I propose= d to agree on choice 2. >=20 > In view of your comments, choice 2 seems to also be yours. > Would you confirm? =20 >=20 I don't strongly disagree with 1, as a SHOULD, however I would if it was a MUST. Possibly a MAY would be a better choice if the text were to remain. However, bearing in mind the possibility of multiple downstream subnets, I think 2 is probably the better option to reach consensus. Regards, Mark. > Regards, > RD >=20 >=20 > Le 14 mars 2010 =E0 01:46, Mark Smith a =E9crit : >=20 > > On Fri, 12 Mar 2010 11:38:28 +0100 > > R=E9mi Despr=E9s wrote: > >=20 > >>=20 > >> Le 12 mars 2010 =E0 00:35, Mark Townsley a =E9crit : > >>=20 > >>> On 3/10/10 10:24 PM, Brian E Carpenter wrote: > >> ... > >>>>> That's true today. But my experience while travelling and staying in > >>>> random hotels towards the end of the dial-up era was that I often > >>>> had to clamp the IPv4 MTU at (say) 512 to make things actually work. > >>>> I've had experience with 6to4 of abject PMTUD failures with remote s= ervers > >>>> trying to do 1480. So I think that Remy is correct as far as a fail = safe > >>>> solution *today* goes. > >>> And thank goodness we still don't fragment all IPv4 traffic >=3D 512 = bytes. > >>>> Since 6RD is very much a transitional technique > >>>> before an ISP is ready to run native, I don't see this as a signific= ant > >>>> inefficiency. > >>>>=20 > >>> The problem in this logic is that the argument for 1280 is not about = the MTU within the confines of the 6rd deployment, but outside across the I= nternet. As such, it would apply equally to native IPv6 as it would to 6rd. > >>=20 > >> Yes, it DOES apply also to directly native IPv6. > >> That's why it makes sense, in a 6rd RFC, to avoid dealing with any rec= ommendation to advertise on a LAN link another MTU than that of the link it= self. > >>=20 > >> This means deleting this sentence: > >> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined auto= matically or configured directly, on the LAN side by setting the MTU option= in Router Advertisements [RFC4861] messages to the 6rd Tunnel MTU." > >>=20 > >=20 > > So all communications from hosts on the LAN is to the Internet?=20 >=20 > Of course not. > I wonder how you reached this conclusion. >=20 > > If you shrink the LAN MTU for the tunnel's benefit (or even just the > > native IPv6 Internet's benefit), you also shrink the LAN's MTU for any > > communications between the devices on the LAN. Consider the performance > > impact of dropping the LAN MTU to 1280 if the chosen LAN MTU is 9000 > > bytes for local LAN performance. I don't think the presence of a 6RD > > tunnel always implies that the dominant traffic path is to and from the > > Internet and the LAN >=20 > It doesn't. >=20 > > - it could be there just for remote management / > > reachability e.g. ssh, email, snmp, occasional software / OS upgrades > > and updates. An example of such a scenario might be where somebody puts > > a HPC cluster in remote colo somewhere in the world to gain the > > benefits of cheaper cooling and power, and the ISP/Colo provider uses > > 6RD to provide interim IPv6 connectivity. Because a very high > > percentage of large amounts traffic is local to the cluster, larger LAN > > MTUs provide performance benefits. > >=20 > > That's all assuming that the directly upstream router is the 6RD tunnel > > end-point. If there is a routed local IPv6 infrastructure, does the > > 6RD tunnel's MTU now force the whole site to have a 1280 byte MTU? > >=20 > > These are the sorts of scenarios which have made me wonder whether > > there should be some sort of mechanism to express different off-link > > and on-link MTUs or on-site and off-site MTUs (distinguished by an > > on-site aggregate prefix). > >=20 > >=20 > > Regards, > > Mark. >=20 From remi.despres@free.fr Mon Mar 15 10:00:27 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF7F3A6BFB for ; Mon, 15 Mar 2010 10:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQV8TFWTn5Kf for ; Mon, 15 Mar 2010 10:00:26 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 6C7173A69DC for ; Mon, 15 Mar 2010 09:59:58 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 1311AE081A8; Mon, 15 Mar 2010 18:00:01 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id CB876E080A7; Mon, 15 Mar 2010 17:59:58 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20100316031226.0d2e9a7e@opy.nosense.org> Date: Mon, 15 Mar 2010 17:59:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> <4B997E4B.6040009@cisco.com> <20100314111649.407f51db@opy.n osense.org> <1FF3C992-3BBB-48C2-8B11-381841111BD1@free.fr> <20100316031226.0d2e9a7e@opy.nosense.org> To: Mark Smith X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 17:00:27 -0000 Le 15 mars 2010 =E0 17:42, Mark Smith a =E9crit : > On Mon, 15 Mar 2010 08:10:16 +0100 > R=E9mi Despr=E9s wrote: >=20 >> Mark, >>=20 >> Note that the first and main purpose of this discussion is a final = consensus on the 6rd RFC, not to solve now ALL IPv6 remaining problems. >>=20 >> In this context, the point I make is: >> 1) EITHER the proposed RFC continues to recommend that an MTU smaller = than that of the LAN link be advertised in RAs, in which case the = recommended value SHOULD BE 1280, >> 2) OR, the proposed RFC says nothing about RA-advertised MTUs.=20 >>=20 >> Because choice 1 deals with a problem that is not 6rd specific, I = proposed to agree on choice 2. >>=20 >> In view of your comments, choice 2 seems to also be yours. >> Would you confirm? =20 >>=20 >=20 > I don't strongly disagree with 1, as a SHOULD, however I would if it > was a MUST. Possibly a MAY would be a better choice if the text were = to > remain. Agreed: the MUST would be inappropriate. > However, bearing in mind the possibility of multiple downstream > subnets, I think 2 is probably the better option to reach consensus. We then do agree on 2. Let's hope others can adopt this as the desired consensus. Cheers, RD From remi.despres@free.fr Mon Mar 15 10:59:26 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529E13A69E5 for ; Mon, 15 Mar 2010 10:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhR9OFAvLsM1 for ; Mon, 15 Mar 2010 10:59:25 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 6AB1C3A69FE for ; Mon, 15 Mar 2010 10:59:20 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id D4D58E08002; Mon, 15 Mar 2010 18:59:24 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 9817DE08148; Mon, 15 Mar 2010 18:59:21 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <24E82607-6A46-4FF6-A35E-8E7049DFCB12@free.fr> Date: Mon, 15 Mar 2010 18:59:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B8DABEE.3030407@gmail.com> <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> <4B997E4B.6040009@cisco.com> <20100314111649.407f51db@opy.nosense.org> <4B9C399A.1000800@gmail.com> <24E82607-6A46-4FF6-A35E-8E7049DFCB 12@free.fr> To: Brian E Carpenter , Mark Smith X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 17:59:26 -0000 Le 15 mars 2010 =E0 08:22, R=E9mi Despr=E9s a =E9crit : > Even better than TWO default transmit MTUs, hosts should in my = understanding have FOUR: on-link and off-link, IPv4 and IPv6. Actually, it is a little more subtle than I first thought: - The link MTU being common to IPv6 and IPv4, one is enough. - In IPv6, the default transmit MTU for off-link transmissions SHOULD be = 1280. - In IPv4, there is no standard value to be recommended as default = transmit MTU for off-link destinations (the network will fragment where = needed). It may however be useful to have one that differs from the link = MTU, especially on links that support 9000B Jumbo Frames. =20 The bottom line could then be: - Hosts SHOULD have a least 2 default transmit MTUs, one for all on-link = transmissions and one for off-link IPv6 destinations. =20 - They MAY advantageously have third one, modifiable by advanced users, = for off-link IPv4. Thoughts? RD= From ichiroumakino@gmail.com Mon Mar 15 11:13:04 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61443A6B80 for ; Mon, 15 Mar 2010 11:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwB7WjzsLlk6 for ; Mon, 15 Mar 2010 11:13:04 -0700 (PDT) Received: from mail-ew0-f227.google.com (mail-ew0-f227.google.com [209.85.219.227]) by core3.amsl.com (Postfix) with ESMTP id 052C93A6B8A for ; Mon, 15 Mar 2010 11:11:52 -0700 (PDT) Received: by ewy27 with SMTP id 27so1261593ewy.14 for ; Mon, 15 Mar 2010 11:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=o1q0Zn1Ju/zpVPmCdY/p+LcHNXnSiCjdwcpxPj8HX8Q=; b=fN40MNY6Tqn1CO26y35maz7AvqPSIs9KR3yGO98l5juLC3ItWCLT3ILxIawVdgMj3E laNN6r1I3zT6sAAfAfF7LHwXkKtlrbLtjgnJ/gGyco+IA7rZM0R4DUFgwdMB1iN+T4+M V1aoByvGFN/XLMJJ7CMjkkOB2NC9y8mWj6sVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=wtovrh276ObkOPpiiJMCToxGkVOaqf+3fHtwZRSVnmwSbOPnvylUaF9Ajpx8FQlGo8 Cl7ymkY3uTYCN1AxsA6grftx/Eo6BPP/qlQsZ18SdX1L3MzPrp7lAbYU0J8Vh/VPy8Ac ylaVWjwe6bM1yLacnSe1MhL8YgBOXaC1XlvaA= Received: by 10.213.102.74 with SMTP id f10mr5032755ebo.70.1268676715940; Mon, 15 Mar 2010 11:11:55 -0700 (PDT) Received: from ams-otroan-87111.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id 15sm2742177ewy.0.2010.03.15.11.11.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 11:11:55 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: <20100316031226.0d2e9a7e@opy.nosense.org> Date: Mon, 15 Mar 2010 19:11:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <629F7D3E-108D-43A1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@free.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2DFE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158.537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> <4B997E4B.6040009@cisco.com> <20100314111649.407f51db@opy.n osense.org> <1FF3C992-3BBB-48C2-8B11-381841111BD1@free.fr> <20100316031226.0d2e9a7e@opy.nosense.org> To: softwires X-Mailer: Apple Mail (2.1077) Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 18:13:05 -0000 all, [...] >> In this context, the point I make is: >> 1) EITHER the proposed RFC continues to recommend that an MTU smaller = than that of the LAN link be advertised in RAs, in which case the = recommended value SHOULD BE 1280, >> 2) OR, the proposed RFC says nothing about RA-advertised MTUs.=20 >>=20 >> Because choice 1 deals with a problem that is not 6rd specific, I = proposed to agree on choice 2. >>=20 >> In view of your comments, choice 2 seems to also be yours. >> Would you confirm? =20 >>=20 >=20 > I don't strongly disagree with 1, as a SHOULD, however I would if it > was a MUST. Possibly a MAY would be a better choice if the text were = to > remain. >=20 > However, bearing in mind the possibility of multiple downstream > subnets, I think 2 is probably the better option to reach consensus. yes, I think so too. I'll remove that paragraph from the revision-08 = draft, unless someone has strong objections. do we have other last call comments that people feel haven't been = addressed fully? I have asked for a 5 minute slot in Anaheim to go through the LC = comments/resolutions, but there will not be time for extensive = discussions in the room. may I suggest that those interested in discussing MTU more generally = move to a separate thread? Best regards, Ole From yiu_lee@cable.comcast.com Mon Mar 15 12:03:04 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D991E3A6B95 for ; Mon, 15 Mar 2010 12:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nty22HdMZe1F for ; Mon, 15 Mar 2010 12:03:03 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 7B3AD3A6C7F for ; Mon, 15 Mar 2010 12:00:04 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74341668; Mon, 15 Mar 2010 15:00:06 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 15:00:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 69.241.25.0 ([69.241.25.0]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Mon, 15 Mar 2010 19:00:02 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3351509998_1370771" Date: Mon, 15 Mar 2010 14:59:58 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrEcbT4WLq7J4Lvt0eBE3qxDd+xpw== From: "Lee, Yiu" To: "Ole Troan" , "softwires" X-OriginalArrivalTime: 15 Mar 2010 19:00:03.0704 (UTC) FILETIME=[B85EA780:01CAC471] Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 19:03:05 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3351509998_1370771 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I agree with Ole. MTU problem isn't unique to 6RD, it also happens to DS-lite or any other tunneling technique. We should move forward for 6RD and perhaps start another draft for the MTU topic. Any thought? On 3/15/10 2:11 PM, "Ole Troan" wrote: > all, > > [...] > >>> In this context, the point I make is: >>> 1) EITHER the proposed RFC continues to recommend that an MTU smaller than >>> that of the LAN link be advertised in RAs, in which case the recommended >>> value SHOULD BE 1280, >>> 2) OR, the proposed RFC says nothing about RA-advertised MTUs. >>> >>> Because choice 1 deals with a problem that is not 6rd specific, I proposed >>> to agree on choice 2. >>> >>> In view of your comments, choice 2 seems to also be yours. >>> Would you confirm? >>> >> >> I don't strongly disagree with 1, as a SHOULD, however I would if it >> was a MUST. Possibly a MAY would be a better choice if the text were to >> remain. >> >> However, bearing in mind the possibility of multiple downstream >> subnets, I think 2 is probably the better option to reach consensus. > > yes, I think so too. I'll remove that paragraph from the revision-08 draft, > unless someone has strong objections. > > do we have other last call comments that people feel haven't been addressed > fully? > I have asked for a 5 minute slot in Anaheim to go through the LC > comments/resolutions, but there will not be time for extensive discussions in > the room. > > may I suggest that those interested in discussing MTU more generally move to a > separate thread? > > Best regards, > Ole > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --B_3351509998_1370771 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBQkCpqPrcydBLA0k/VebHnsumvzFjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAzMTUxODU5NThaMA0GCSqGSIb3DQEBAQUABIIBAHCE PcxYpdMi8uTY3fadfn5+AAAFudTEdCeESn2Y0A3+mn1ZUA+1AGqMDcfbOaMSGoCF+omNDNx2 zeQIehucDkG/5VmNSNcc4NzqpVY3y2PZB00vosHxB4NkydgWx1Ao9jtRIG00cCI/oVFZEVkQ mIYV6qyCJo3QrUj0agGjr3NtxmdkoVzylp9Z0k9EfmT6eUa45rMt8HkwHCogu7j/Fgyt3g6T v2QE2SumOqPCwGQNM+8Q8HhvCnqj+TDW77Z3bzu8062p91xkBO0fWmV8id4cFjS4e106h9H2 5iFz+IFICA/xlvsrvVxSQEQ3TuqoeRBhM5e++I8I0dfhaubAR2k= --B_3351509998_1370771-- From Fred.L.Templin@boeing.com Mon Mar 15 12:34:28 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F8F3A6944 for ; Mon, 15 Mar 2010 12:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyxiYf7ZYQ7X for ; Mon, 15 Mar 2010 12:34:27 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 291F33A6861 for ; Mon, 15 Mar 2010 12:34:27 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2FJYPOD001211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Mar 2010 12:34:26 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2FJYPZB014406; Mon, 15 Mar 2010 14:34:25 -0500 (CDT) 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 o2FJYOR4014392 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 15 Mar 2010 14:34:25 -0500 (CDT) 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, 15 Mar 2010 12:34:24 -0700 From: "Templin, Fred L" To: Brian E Carpenter , Mark Smith Date: Mon, 15 Mar 2010 12:34:23 -0700 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrDFG/+dat3E8oiRkGhRTgfP6X13wBRWz5wAAcBGCA= Message-ID: References: <4B8DABEE.303040 7@gmail.com> <629F7D3E-108D-43A 1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@fre e.fr> <4B916BA7.3080400@gmail.com><4B950EF1.6010304@cisco .com> <74EF8AD8-2D FE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158 .537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com><4B997E4B.6040009@ci sco.com><20100314111649.407f51db@opy.nosense.org><4B9C399A.1000800@gmail.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: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 19:34:29 -0000 Brian, > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Templin, Fred L > Sent: Monday, March 15, 2010 9:16 AM > To: Brian E Carpenter; Mark Smith > Cc: softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > Brian, >=20 > > -----Original Message----- > > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On= Behalf Of Brian E Carpenter > > Sent: Saturday, March 13, 2010 5:19 PM > > To: Mark Smith > > Cc: softwires@ietf.org > > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > > > > On 2010-03-14 13:46, Mark Smith wrote: > > ... > > > These are the sorts of scenarios which have made me wonder whether > > > there should be some sort of mechanism to express different off-link > > > and on-link MTUs or on-site and off-site MTUs (distinguished by an > > > on-site aggregate prefix). > > > > I hope they're discussing that over in MIF. A different set of settings > > (not just MTU) per prefix seems entirely rational; a nice large MTU > > for a ULA prefix might make sense. >=20 > If you want to consider the IPv6 6rd global for off-site > communications only, then that would be doable but I > still think we should try for 1500 or larger instead of > 1280 if at all possible. If you then want to consider an > IPv6 ULA for on-site communications with larger MTU, that > would be fine too. Going back slightly on what I said, what do you have in mind - a per-prefix MTU? As I understand it, routers advertise MTUs per-*link*; not per-*prefix*. Were you thinking we could invent a per-prefix MTU advertisement and use it to keep site-local communications at a higher MTU than global communications? I don't se any standard support mechanisms for something like that at this time unless I'm missing something. Thanks - Fred fred.l.templin@boeing.com =20 > Within the customer site, however, both the 6rd global > and ULA can be serviced using ISATAP if native IPv6 is > not yet available. >=20 > Fred > fred.l.templin@boeing.com >=20 > > Brian > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Fred.L.Templin@boeing.com Mon Mar 15 12:34:46 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D653A69F6 for ; Mon, 15 Mar 2010 12:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oO9VkY41EIQ for ; Mon, 15 Mar 2010 12:34:45 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 194FB3A6861 for ; Mon, 15 Mar 2010 12:34:45 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2FJYnSf001424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Mar 2010 12:34:50 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2FJYmHT015144; Mon, 15 Mar 2010 14:34:48 -0500 (CDT) 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 o2FJYm8R015121 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 15 Mar 2010 14:34:48 -0500 (CDT) 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, 15 Mar 2010 12:34:48 -0700 From: "Templin, Fred L" To: "Lee, Yiu" , Ole Troan , softwires Date: Mon, 15 Mar 2010 12:34:47 -0700 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrEcbT4WLq7J4Lvt0eBE3qxDd+xpwAA/eBQ 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 Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 19:34:46 -0000 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Lee, Yiu > Sent: Monday, March 15, 2010 12:00 PM > To: Ole Troan; softwires > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > I agree with Ole. MTU problem isn't unique to 6RD, it also happens to > DS-lite or any other tunneling technique. We should move forward for 6RD = and > perhaps start another draft for the MTU topic. >=20 > Any thought? Yes - 1500+ is within our grasp, so why let it slip through our fingers and settle for 1280? Fred fred.l.templin@boeing.com =20 > On 3/15/10 2:11 PM, "Ole Troan" wrote: >=20 > > all, > > > > [...] > > > >>> In this context, the point I make is: > >>> 1) EITHER the proposed RFC continues to recommend that an MTU smaller= than > >>> that of the LAN link be advertised in RAs, in which case the recommen= ded > >>> value SHOULD BE 1280, > >>> 2) OR, the proposed RFC says nothing about RA-advertised MTUs. > >>> > >>> Because choice 1 deals with a problem that is not 6rd specific, I pro= posed > >>> to agree on choice 2. > >>> > >>> In view of your comments, choice 2 seems to also be yours. > >>> Would you confirm? > >>> > >> > >> I don't strongly disagree with 1, as a SHOULD, however I would if it > >> was a MUST. Possibly a MAY would be a better choice if the text were t= o > >> remain. > >> > >> However, bearing in mind the possibility of multiple downstream > >> subnets, I think 2 is probably the better option to reach consensus. > > > > yes, I think so too. I'll remove that paragraph from the revision-08 dr= aft, > > unless someone has strong objections. > > > > do we have other last call comments that people feel haven't been addre= ssed > > fully? > > I have asked for a 5 minute slot in Anaheim to go through the LC > > comments/resolutions, but there will not be time for extensive discussi= ons in > > the room. > > > > may I suggest that those interested in discussing MTU more generally mo= ve to a > > separate thread? > > > > Best regards, > > Ole > > > > > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires From ichiroumakino@gmail.com Mon Mar 15 15:42:24 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744F63A698C for ; Mon, 15 Mar 2010 15:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vIpqlyDaWqW for ; Mon, 15 Mar 2010 15:42:23 -0700 (PDT) Received: from mail-ew0-f216.google.com (mail-ew0-f216.google.com [209.85.219.216]) by core3.amsl.com (Postfix) with ESMTP id 6CBD93A6979 for ; Mon, 15 Mar 2010 15:42:23 -0700 (PDT) Received: by ewy8 with SMTP id 8so1422906ewy.28 for ; Mon, 15 Mar 2010 15:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=Pc+o5wo/IsNSdk08d4woFs1oRUAMY9gvsTXpkYNcKZc=; b=l8FcOQI49rPfOVvN1ucGj8rCl9c4F5iJ2+xupgZpvHyq0OxBzcT8lQOrvT6aZVZJBA D5wSSbqWQW9rHk4tFSUZMzINmGP+Un0DFMvC6BsMKGAVRHkh5Q8eySlD1bYi6/3xttjf m85yvsv/ViQQdZcxjS2tmbP5zIVQikya6hWgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=QjIFY4u4dkxLPRB2YcC9lB7xj+oqnDvFuaU/KZ7GoIg6aGXLAbT+iOS/pXvb+wLTBg pAtren8NI+5SUe0Ql9zbuRzAp5cRSsmpgniUodnJeLYCVeHBEvVA0C+IgU5Jgy4/pA1S fBRdrX1yCBWWHWjICXR2np3mb9x/USCicCs9s= Received: by 10.213.110.135 with SMTP id n7mr5468281ebp.66.1268692947608; Mon, 15 Mar 2010 15:42:27 -0700 (PDT) Received: from ams-otroan-87111.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id 15sm2888017ewy.8.2010.03.15.15.42.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 15:42:26 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Mon, 15 Mar 2010 23:42:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2ECA9A72-78E7-4809-BC38-CE7195183EBA@employees.org> References: To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) Cc: softwires , "Lee, Yiu" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 22:42:24 -0000 >> I agree with Ole. MTU problem isn't unique to 6RD, it also happens to >> DS-lite or any other tunneling technique. We should move forward for = 6RD and >> perhaps start another draft for the MTU topic. >>=20 >> Any thought? >=20 > Yes - 1500+ is within our grasp, so why let it slip > through our fingers and settle for 1280? so what are you proposing? 1) that we leave current work on all tunnel-based solutions off the = table, while we work on a general solution for the MTU problem. 2) develop a general MTU solution in parallel with current work. cheers, Ole= From Fred.L.Templin@boeing.com Mon Mar 15 16:19:50 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C853A6A26 for ; Mon, 15 Mar 2010 16:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPpZwUKAcaac for ; Mon, 15 Mar 2010 16:19:44 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id CC44C3A69EF for ; Mon, 15 Mar 2010 16:18:21 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2FNIFNJ009855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Mar 2010 16:18:15 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2FNIFLu023064; Mon, 15 Mar 2010 16:18:15 -0700 (PDT) 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 o2FNIEU2023056 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 15 Mar 2010 16:18:14 -0700 (PDT) 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; Mon, 15 Mar 2010 16:18:15 -0700 From: "Templin, Fred L" To: Ole Troan Date: Mon, 15 Mar 2010 16:18:13 -0700 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrEkMs22COgIppNTLGYUVsSxgN+AAAABpPA Message-ID: References: <2ECA9A72-78E7-4809-BC38-CE7195183EBA@employees.org> In-Reply-To: <2ECA9A72-78E7-4809-BC38-CE7195183EBA@employees.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 Cc: softwires , "Lee, Yiu" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 23:19:51 -0000 Hi Ole, > -----Original Message----- > From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan > Sent: Monday, March 15, 2010 3:42 PM > To: Templin, Fred L > Cc: Lee, Yiu; softwires > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > >> I agree with Ole. MTU problem isn't unique to 6RD, it also happens to > >> DS-lite or any other tunneling technique. We should move forward for 6= RD and > >> perhaps start another draft for the MTU topic. > >> > >> Any thought? > > > > Yes - 1500+ is within our grasp, so why let it slip > > through our fingers and settle for 1280? >=20 > so what are you proposing? >=20 > 1) that we leave current work on all tunnel-based solutions off the table= , while we work on a general > solution for the MTU problem. >=20 > 2) develop a general MTU solution in parallel with current work. As you may or may not know, SEAL has been in the works for a long time now. This coming Aug/Sep will mark 8 years, and coincided with the closure of NGTRANS (search for "pool-pah"): ftp://ftp.ietf.org/ietf-mail-archive/ngtrans/2002-08.mail the declaration of IPv6 as "operational": http://www.ops.ietf.org/lists/v6ops/v6ops.2002/msg00000.html and the first meeting of the v6ops working group:=20 http://www.ops.ietf.org/lists/v6ops/v6ops.2002/msg00012.html RFC5320 has an experimental implementation to match the document's experimental category: http://osprey67.com/seal and now, 'draft-templin-intarea-seal' is ready for general consumption and development of interoperable implementations. In fact, if anyone wants to beat me to forward-porting the existing linux code to match the new spec, I would be glad to challenge them to a bake-off in the near future. Implementations for other OS's would of course also be welcome. As I said before, 6rd with a 1280 clamping might be pretty good, but why not go the extra step to remove artificial size restrictions and make it *great*. Thanks - Fred fred.l.templin@boeing.com=20 > cheers, > Ole From yiu_lee@cable.comcast.com Mon Mar 15 16:44:20 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D173A6783 for ; Mon, 15 Mar 2010 16:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.796 X-Spam-Level: X-Spam-Status: No, score=-5.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAepuGyP5xwj for ; Mon, 15 Mar 2010 16:44:18 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 5FFAC3A6811 for ; Mon, 15 Mar 2010 16:44:18 -0700 (PDT) Received: from ([10.52.116.31]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74374537; Mon, 15 Mar 2010 19:44:22 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 19:44:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 68.239.239.8 ([68.239.239.8]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Mon, 15 Mar 2010 23:44:20 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3351527058_177729" Date: Mon, 15 Mar 2010 19:44:18 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrEkMs22COgIppNTLGYUVsSxgN+AAAABpPAAAIiAJk= From: "Lee, Yiu" To: "Templin, Fred L" , "Ole Troan" X-OriginalArrivalTime: 15 Mar 2010 23:44:21.0447 (UTC) FILETIME=[6F93AD70:01CAC499] Cc: softwires Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 23:44:20 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3351527058_177729 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Fred, I support to have a different draft to describe operation recommendation for MTU in deployment with tunnel. And SEAL can be one of the recommendations. But I do not support to make SEAL a requirement to 6RD. Thanks, Yiu On 3/15/10 7:18 PM, "Templin, Fred L" wrote: > Hi Ole, > >> -----Original Message----- >> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan >> Sent: Monday, March 15, 2010 3:42 PM >> To: Templin, Fred L >> Cc: Lee, Yiu; softwires >> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >> >>>> I agree with Ole. MTU problem isn't unique to 6RD, it also happens to >>>> DS-lite or any other tunneling technique. We should move forward for 6RD >>>> and >>>> perhaps start another draft for the MTU topic. >>>> >>>> Any thought? >>> >>> Yes - 1500+ is within our grasp, so why let it slip >>> through our fingers and settle for 1280? >> >> so what are you proposing? >> >> 1) that we leave current work on all tunnel-based solutions off the table, >> while we work on a general >> solution for the MTU problem. >> >> 2) develop a general MTU solution in parallel with current work. > > As you may or may not know, SEAL has been in the works for > a long time now. This coming Aug/Sep will mark 8 years, and > coincided with the closure of NGTRANS (search for "pool-pah"): > > ftp://ftp.ietf.org/ietf-mail-archive/ngtrans/2002-08.mail > > the declaration of IPv6 as "operational": > > http://www.ops.ietf.org/lists/v6ops/v6ops.2002/msg00000.html > > and the first meeting of the v6ops working group: > > http://www.ops.ietf.org/lists/v6ops/v6ops.2002/msg00012.html > > RFC5320 has an experimental implementation to match the > document's experimental category: > > http://osprey67.com/seal > > and now, 'draft-templin-intarea-seal' is ready for general > consumption and development of interoperable implementations. > In fact, if anyone wants to beat me to forward-porting the > existing linux code to match the new spec, I would be glad > to challenge them to a bake-off in the near future. > Implementations for other OS's would of course also > be welcome. > > As I said before, 6rd with a 1280 clamping might be pretty > good, but why not go the extra step to remove artificial > size restrictions and make it *great*. > > Thanks - Fred > fred.l.templin@boeing.com > >> cheers, >> Ole --B_3351527058_177729 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBRsSoAY8VPzFroKmWSDHl3Aix4pKDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAzMTUyMzQ0MThaMA0GCSqGSIb3DQEBAQUABIIBAKsq LoOsPgWbwegr+DdyNG8uvhviw7rcXQ0+Qi3/BKhJqKcPh7lL51yPGtMpqyC9OhvUbdCUDkrC ZXiSnSsQi7hbsJ3/QKRlmX0E6Oc88nVmWEuN+C7p4vEzPKtqFRjKJQD/i9XehjczlVOCjc1K xKR7UXcrUtBvjv8f45xdZq75HPFDHSrsBHNKyP+5AGF8FcPpC9jpkvcqUtd4zvXFJTwUTyUW xI1in0u+vp+9M1C18bHgLRIo2XWcyOv5aBRyiJFIRD5jLlXpH+yK7MR40AMtJtnde4tlWhk4 H3GQ77QCFtjES+GLdLeo4Zv1tj3anwuo0oZn1l0MN3wuhD4sfFE= --B_3351527058_177729-- From alain_durand@cable.comcast.com Mon Mar 15 18:40:53 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7281C3A68C4 for ; Mon, 15 Mar 2010 18:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qocl2KytQ1Tn for ; Mon, 15 Mar 2010 18:40:50 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id B53EE3A6778 for ; Mon, 15 Mar 2010 18:40:46 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74379092; Mon, 15 Mar 2010 21:40:49 -0400 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 21:40:49 -0400 Received: from 71.230.252.107 ([71.230.252.107]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 16 Mar 2010 01:40:49 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 15 Mar 2010 21:40:47 -0400 From: "Durand, Alain" To: softwires Message-ID: Thread-Topic: Chair input on 6rd/MTU discussion Thread-Index: AcrEqbNK2jzDoF0DVkaYFgouo9qb6A== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3351534047_2448414" X-OriginalArrivalTime: 16 Mar 2010 01:40:49.0693 (UTC) FILETIME=[B4E564D0:01CAC4A9] Cc: Ole Troan Subject: [Softwires] Chair input on 6rd/MTU discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 01:40:53 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3351534047_2448414 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Wg, >=20 > As chairs, We=B9ve been looking at the MTU thread on 6rd. There has been ma= ny > good points made and we have had an healthy discussion. It is now time to= move > on with the base spec. MTU is one of the many operational issues with 6rd= . The > chairs and the authors discussed a while back to have a companion documen= t to > 6rd that will focus on exactly those operational considerations. We do be= lieve > that the 6rd MTU discussion belongs there. > In order to not tie the hands of that new document, it will be better if = the > base spec were to remain silent on the MTU issue. > This future operational document should be focused on 6rd and not try to = solve > the generic tunneling MTU discussion. > The generic work is important too, and certainly need to find a home. How= ever > this is a different topic, for future discussions with our ADs. >=20 - Alain & David. --B_3351534047_2448414 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Chair input on 6rd/MTU discussion Wg,
<= SPAN STYLE=3D'font-size:11pt'>
As chairs, We’ve been looking at the MTU thread on 6rd. There has bee= n many good points made and we have had an healthy discussion. It is now tim= e to move on with the base spec. MTU is one of the many operational issues w= ith 6rd. The chairs and the authors discussed a while back to have a compani= on document to 6rd that will focus on exactly those operational consideratio= ns. We do believe that the 6rd MTU discussion belongs there.
In order to not tie the hands of that new document, it will be better if th= e base spec were to remain silent on the MTU issue.
This future operational document should be focused on 6rd and not try to so= lve the generic tunneling MTU discussion.
The generic work is important too, and certainly need to find a home. Howev= er this is a different topic, for future discussions with our ADs.

=   - Alain & David. --B_3351534047_2448414-- From brian.e.carpenter@gmail.com Mon Mar 15 18:46:57 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336963A6847 for ; Mon, 15 Mar 2010 18:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFpH3WCF4PPk for ; Mon, 15 Mar 2010 18:46:56 -0700 (PDT) Received: from mail-pz0-f178.google.com (mail-pz0-f178.google.com [209.85.222.178]) by core3.amsl.com (Postfix) with ESMTP id 7B7763A63C9 for ; Mon, 15 Mar 2010 18:46:50 -0700 (PDT) Received: by pzk8 with SMTP id 8so3108110pzk.29 for ; Mon, 15 Mar 2010 18:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AzDQvNCjS1nk9Jsp0ytuxU20U81ZOXbKd7ayqgDEnjc=; b=X+75nT4Pp/UpyXXASXS+YUQjS7gwUpIVMUiJHBBP/lQ94tDP1TzEawqD4DhPqGZ7X1 yH8BGYfWNET3+VGD2MUd2s6epP2THiqxIfmSxflqSA+oVvSgu5327tymun4A6RRXJNlP FqatNC2syVlCEBHLiRszppJAfPG5nvXlyEAFU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=tkcVZQ1jLNk9EnQbiAmlJLqEYgr2GJumDQmix6QVkVHepz44RDDGDUedwjEeKtislx 7zzu7ZihVkkTejGVdi4foRbH9F0Sqrk5y7SyKZWJDsbEFXFPc3BZRjTlAgbBL6mqQdUU gDMvjYv32AuP7E+gqpEH2W7r6o2Hv5pZURCXo= Received: by 10.115.51.20 with SMTP id d20mr6149772wak.151.1268704015371; Mon, 15 Mar 2010 18:46:55 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm6301316pzk.8.2010.03.15.18.46.53 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 18:46:54 -0700 (PDT) Message-ID: <4B9EE30C.4080006@gmail.com> Date: Tue, 16 Mar 2010 14:46:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" References: <629F7D3E-108D-43A 1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@fre e.fr> <4B916BA7.3080400@gmail.com><4B950EF1.6010304@cisco .com> <74EF8AD8-2D FE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158 .537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com><4B997E4B.6040009@ci sco.com><20100314111649.407f51db@opy.nosense.org><4B9C399A.1000800@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" Subject: [Softwires] MTU per * [SOFTWIRE working group last call on 6rd] X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 01:46:57 -0000 Below... On 2010-03-16 08:34, Templin, Fred L wrote: > Brian, > >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Templin, Fred L >> Sent: Monday, March 15, 2010 9:16 AM >> To: Brian E Carpenter; Mark Smith >> Cc: softwires@ietf.org >> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >> >> Brian, >> >>> -----Original Message----- >>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Brian E Carpenter >>> Sent: Saturday, March 13, 2010 5:19 PM >>> To: Mark Smith >>> Cc: softwires@ietf.org >>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >>> >>> On 2010-03-14 13:46, Mark Smith wrote: >>> ... >>>> These are the sorts of scenarios which have made me wonder whether >>>> there should be some sort of mechanism to express different off-link >>>> and on-link MTUs or on-site and off-site MTUs (distinguished by an >>>> on-site aggregate prefix). >>> I hope they're discussing that over in MIF. A different set of settings >>> (not just MTU) per prefix seems entirely rational; a nice large MTU >>> for a ULA prefix might make sense. >> If you want to consider the IPv6 6rd global for off-site >> communications only, then that would be doable but I >> still think we should try for 1500 or larger instead of >> 1280 if at all possible. If you then want to consider an >> IPv6 ULA for on-site communications with larger MTU, that >> would be fine too. > > Going back slightly on what I said, what do you have > in mind - a per-prefix MTU? As I understand it, routers > advertise MTUs per-*link*; not per-*prefix*. Were you > thinking we could invent a per-prefix MTU advertisement > and use it to keep site-local communications at a higher > MTU than global communications? I don't se any standard > support mechanisms for something like that at this time > unless I'm missing something. That's why I said that I hope they are discussing this in MIF. Parameters per interface is one level of granularity, parameters per prefix is another. I haven't had time to see what MIF is up to. Brian > > Thanks - Fred > fred.l.templin@boeing.com > >> Within the customer site, however, both the 6rd global >> and ULA can be serviced using ISATAP if native IPv6 is >> not yet available. >> >> Fred >> fred.l.templin@boeing.com >> >>> Brian From townsley@cisco.com Mon Mar 15 19:06:01 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749323A69EF for ; Mon, 15 Mar 2010 19:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.414 X-Spam-Level: X-Spam-Status: No, score=-10.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdwKDu0fWcA6 for ; Mon, 15 Mar 2010 19:06:00 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B0EBF3A68EC for ; Mon, 15 Mar 2010 19:06:00 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.49,647,1262563200"; d="scan'208";a="100554461" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 16 Mar 2010 02:06:05 +0000 Received: from iwan-view3.cisco.com (iwan-view3.cisco.com [171.70.65.13]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2G265iV022991; Tue, 16 Mar 2010 02:06:05 GMT Received: from ams-townsley-87110.cisco.com (ams-townsley-87110.cisco.com [10.55.233.235]) by iwan-view3.cisco.com (8.11.2/CISCO.WS.1.2) with ESMTP id o2G263Y28600; Mon, 15 Mar 2010 19:06:04 -0700 (PDT) Message-ID: <4B9EE78A.1080908@cisco.com> Date: Tue, 16 Mar 2010 03:06:02 +0100 From: Mark Townsley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Durand, Alain" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: softwires , Ole Troan Subject: Re: [Softwires] Chair input on 6rd/MTU discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 02:06:01 -0000 I agree that the Tunnel-MTU derived method is not perfect by any means, but it does represent the most agreed-upon compromise in terms of implementation and running code at this time. It's a shame to have lost that fact from the RFC today, as I doubt that we are going to finish solving the generic issue in time for 6rd deployments to begin. C'est la vie. - Mark On 3/16/10 2:40 AM, Durand, Alain wrote: > Wg, > > > As chairs, We’ve been looking at the MTU thread on 6rd. There has > been many good points made and we have had an healthy discussion. > It is now time to move on with the base spec. MTU is one of the > many operational issues with 6rd. The chairs and the authors > discussed a while back to have a companion document to 6rd that > will focus on exactly those operational considerations. We do > believe that the 6rd MTU discussion belongs there. > In order to not tie the hands of that new document, it will be > better if the base spec were to remain silent on the MTU issue. > This future operational document should be focused on 6rd and not > try to solve the generic tunneling MTU discussion. > The generic work is important too, and certainly need to find a > home. However this is a different topic, for future discussions > with our ADs. > > - Alain & David. From brian.e.carpenter@gmail.com Mon Mar 15 19:58:16 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D133A6864 for ; Mon, 15 Mar 2010 19:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szHA98d2+Utx for ; Mon, 15 Mar 2010 19:58:15 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 643CC3A67F3 for ; Mon, 15 Mar 2010 19:58:15 -0700 (PDT) Received: by pwj6 with SMTP id 6so2416513pwj.31 for ; Mon, 15 Mar 2010 19:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=CXEpawAEXQ+DPoIsggnWqoBIg+aTbDCUf9EgwU3876U=; b=aZafrayt9jahYSJoHeqUcj01fQedT6PI7BoEfky872oQRowgvUYfi9jxLYcU4mD3hb mcMc9W4F2gBga1DHPRanEVdKbaClm+DBtQsM0F8qqj0gXDumGxCscIorh2WfzlOYAGDv UInNPMK4CPc5migUdUswqIPqMKYGPbwgYUQrc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=EHT4sVp03rL2A6SYtJHf3aYzQ8oa+gWmVAS4zOIuP3jQRLeNrUnTCu0LHMNFqr+uxN z9Lr9CiGtXdd8ZK4JY9PMroJRsQJPwYc/gA15N7idCQIJW/M/frP8YpYzdTsz+h0TzYD FqzhENJJYu7y02vI5YflSRwKmciOrZvtV1dm0= Received: by 10.115.101.31 with SMTP id d31mr1556677wam.71.1268708300237; Mon, 15 Mar 2010 19:58:20 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 21sm6349054pzk.4.2010.03.15.19.58.17 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 19:58:19 -0700 (PDT) Message-ID: <4B9EF3C8.8010101@gmail.com> Date: Tue, 16 Mar 2010 15:58:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <20100301183001.E751F3A896E@core3.amsl.com> In-Reply-To: <20100301183001.E751F3A896E@core3.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action:draft-despres-softwire-sam-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 02:58:16 -0000 R=C3=A9mi, Let's take it for granted that a) it is possible to design a general format for mapping rules, that would work in a variety of scenarios including map-and-encap and NAT; b) the format and examples in the draft are complete and correct; c) tunnel end points and NATs can be "taught" to obey such maps. Then consider this: > 2.7. Acquisition of Mapping Rules by Customer Nodes >=20 > For early experimentations or advanced uses, a customer SAM may > acquire the SAM rules of its SAM domain by administrative > configuration. But for extensive deployments, they must be acquired= > automatically. The DHCP of [RFC2131] and DHCPv6 of [RFC3315]) can b= e > used for this. Alternatively, in particular for scenarios where > NAT44s have to be traversed, using the DNS as proposed in section 6 > of [DNS-SD] can be a better approach. That implies that the map for a given point is acquired automatically, but it doesn't explain how the map is created. It seems that for usage at Internet scale, the maps would have to be generated and propagated automatically. Isn't this a hard problem (exactly the same problem that arises for LISP)? Or have I misunderstood the deployment model? (I have asked in the past what mapping mechanism RANGER would use. One answer to that question is: why not SAM? But then the question of how the maps are generated remains.) Brian From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Mar 16 01:44:16 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87813A6925 for ; Tue, 16 Mar 2010 01:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3qNf-1qXdlt for ; Tue, 16 Mar 2010 01:44:16 -0700 (PDT) Received: from smtp1.adam.net.au (smtp1.adam.net.au [202.136.110.253]) by core3.amsl.com (Postfix) with ESMTP id C4B033A67F5 for ; Tue, 16 Mar 2010 01:44:15 -0700 (PDT) Received: from 219-90-163-205.ip.adam.com.au ([219.90.163.205] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1NrSNr-0006RC-VS; Tue, 16 Mar 2010 19:14:16 +1030 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 5EFB94930C; Tue, 16 Mar 2010 19:14:15 +1030 (CST) Date: Tue, 16 Mar 2010 19:14:14 +1030 From: Mark Smith To: Brian E Carpenter Message-ID: <20100316191414.49b867c8@opy.nosense.org> In-Reply-To: <4B9EE30C.4080006@gmail.com> References: <629F7D3E-108D-43A 1-B1E0-921922D70AEF@employees.org> <9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@fre e.fr> <4B916BA7.3080400@gmail.com> <4B950EF1.6010304@cisco .com> <74EF8AD8-2D FE-4493-8AA8-6F79A3D66B83@free.fr> <20100311074158 .537d551a@opy.nosense.org> <4B980DF2.8030201@gmail.com> <4B997E4B.6040009@ci sco.com> <20100314111649.407f51db@opy.nosense.org> <4B9C399A.1000800@gmail.com> <4B9EE30C.4080006@gmail.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "softwires@ietf.org" , "Templin, Fred L" Subject: Re: [Softwires] MTU per * [SOFTWIRE working group last call on 6rd] X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 08:44:17 -0000 On Tue, 16 Mar 2010 14:46:52 +1300 Brian E Carpenter wrote: > Below... > > On 2010-03-16 08:34, Templin, Fred L wrote: > > Brian, > > > >> -----Original Message----- > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Templin, Fred L > >> Sent: Monday, March 15, 2010 9:16 AM > >> To: Brian E Carpenter; Mark Smith > >> Cc: softwires@ietf.org > >> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > >> > >> Brian, > >> > >>> -----Original Message----- > >>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Brian E Carpenter > >>> Sent: Saturday, March 13, 2010 5:19 PM > >>> To: Mark Smith > >>> Cc: softwires@ietf.org > >>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > >>> > >>> On 2010-03-14 13:46, Mark Smith wrote: > >>> ... > >>>> These are the sorts of scenarios which have made me wonder whether > >>>> there should be some sort of mechanism to express different off-link > >>>> and on-link MTUs or on-site and off-site MTUs (distinguished by an > >>>> on-site aggregate prefix). > >>> I hope they're discussing that over in MIF. A different set of settings > >>> (not just MTU) per prefix seems entirely rational; a nice large MTU > >>> for a ULA prefix might make sense. > >> If you want to consider the IPv6 6rd global for off-site > >> communications only, then that would be doable but I > >> still think we should try for 1500 or larger instead of > >> 1280 if at all possible. If you then want to consider an > >> IPv6 ULA for on-site communications with larger MTU, that > >> would be fine too. > > > > Going back slightly on what I said, what do you have > > in mind - a per-prefix MTU? As I understand it, routers > > advertise MTUs per-*link*; not per-*prefix*. Were you > > thinking we could invent a per-prefix MTU advertisement > > and use it to keep site-local communications at a higher > > MTU than global communications? I don't se any standard > > support mechanisms for something like that at this time > > unless I'm missing something. > > That's why I said that I hope they are discussing this > in MIF. Parameters per interface is one level of granularity, > parameters per prefix is another. I haven't had time to see > what MIF is up to. > I agree. I think there are 3 scopes for different MTUs - per link, per site (possibly distinguished by a prefix), and offsite i.e. the Internet. > Brian > > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> Within the customer site, however, both the 6rd global > >> and ULA can be serviced using ISATAP if native IPv6 is > >> not yet available. > >> > >> Fred > >> fred.l.templin@boeing.com > >> > >>> Brian From remi.despres@free.fr Tue Mar 16 02:54:45 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7703A694F for ; Tue, 16 Mar 2010 02:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.781 X-Spam-Level: X-Spam-Status: No, score=-1.781 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B20ZUOKVO7Ea for ; Tue, 16 Mar 2010 02:54:44 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 394CA3A692D for ; Tue, 16 Mar 2010 02:54:42 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 6D380E08179; Tue, 16 Mar 2010 10:54:46 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id EE587E08162; Tue, 16 Mar 2010 10:54:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4B9EF3C8.8010101@gmail.com> Date: Tue, 16 Mar 2010 10:54:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100301183001.E751F3A896E@core3.amsl.com> <4B9EF3C8.8010101@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1077) Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action:draft-despres-softwire-sam-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 09:54:45 -0000 Brian, Answers below. Le 16 mars 2010 =E0 03:58, Brian E Carpenter a =E9crit : > R=E9mi, >=20 > Let's take it for granted that >=20 > a) it is possible to design a general format for mapping rules, > that would work in a variety of scenarios including map-and-encap > and NAT; >=20 > b) the format and examples in the draft are complete and correct; >=20 > c) tunnel end points and NATs can be "taught" to obey such maps. >=20 > Then consider this: >=20 >> 2.7. Acquisition of Mapping Rules by Customer Nodes >>=20 >> For early experimentations or advanced uses, a customer SAM may >> acquire the SAM rules of its SAM domain by administrative >> configuration. But for extensive deployments, they must be = acquired >> automatically. The DHCP of [RFC2131] and DHCPv6 of [RFC3315]) can = be >> used for this. Alternatively, in particular for scenarios where >> NAT44s have to be traversed, using the DNS as proposed in section 6 >> of [DNS-SD] can be a better approach. >=20 > That implies that the map for a given point is acquired automatically, > but it doesn't explain how the map is created. In customer SAMs, mapping rules are always acquired automatically. In provider SAMs, there are many scenarios where it is reasonable to = configure them administratively. (This is like in 6rd, where 6rd = parameters are administratively configured in 6rd BRs, and automatically = acquired by 6rd CEs). > It seems that for usage > at Internet scale, the maps would have to be generated and propagated > automatically. Isn't this a hard problem I am not sure to understand what you mean by "the map". The hierarchy of exterior prefixes follows the classical model of CIDR = prefixes. That's all.=20 The example of section 3.4 (the planned Telecom-Bretagne experiment) = shows a 2-layer hierarchy of SAM domains, which may be a partial answer. Besides, deriving provider-SAM rules from locally available parameters = is internal to each provider-side BR. Where configuration of mapping rules in provider SAMs should be = automated, proprietary solutions are therefore possible. (Having a standard for this can be nice, but is not necessary). =20 > (exactly the same problem > that arises for LISP)? Or have I misunderstood the deployment model? In my understanding, the fact that LISP addresses have a distinct format = makes it necessary that LISP be supported both in source and destination = domains that communicate across the Internet core. On the contrary, SAM addresses are routable like any native addresses = everywhere outside of SAM domains themselves. The deployment can therefore be incremental (similarly to that of 6rd, = of which SAM is an extension).=20 RD From remi.despres@free.fr Tue Mar 16 04:11:36 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDDC3A696A for ; Tue, 16 Mar 2010 04:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWZVdv5ZNV7K for ; Tue, 16 Mar 2010 04:11:35 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 33FE63A69D6 for ; Tue, 16 Mar 2010 04:11:23 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id C5231E08153; Tue, 16 Mar 2010 12:11:27 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 79A27E081A4; Tue, 16 Mar 2010 12:11:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 16 Mar 2010 12:11:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AED8430-03D4-4BD9-B077-BE0CC8C2B162@free.fr> References: <2ECA9A72-78E7-4809-BC38-CE7195183EBA@employees.org> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) Cc: softwires , "Lee, Yiu" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 11:11:36 -0000 Le 16 mars 2010 =E0 00:18, Templin, Fred L a =E9crit : > As I said before, 6rd with a 1280 clamping might be pretty > good, but why not go the extra step to remove artificial > size restrictions and make it *great*. The reason why 6rd IS "great", is because it has been kept simple, and = in particular stateless. I therefore hope you don't mean that including SEAL in it would be an = improvement: that would destroy its main virtue. RD From Fred.L.Templin@boeing.com Tue Mar 16 10:31:40 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1C73A69DF for ; Tue, 16 Mar 2010 10:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwWC9+XyzPy1 for ; Tue, 16 Mar 2010 10:31:39 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 070CD3A6856 for ; Tue, 16 Mar 2010 10:31:36 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2GHVccK027552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Mar 2010 10:31:39 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2GHVbIs024184; Tue, 16 Mar 2010 12:31:37 -0500 (CDT) 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 o2GHVbAo024156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 16 Mar 2010 12:31:37 -0500 (CDT) 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; Tue, 16 Mar 2010 10:31:37 -0700 From: "Templin, Fred L" To: Mark Smith , Brian E Carpenter Date: Tue, 16 Mar 2010 10:31:34 -0700 Thread-Topic: MTU per * [SOFTWIRE working group last call on 6rd] Thread-Index: AcrE5OGrgKdH5klZTGqoHdiTLudg4QAR7Dhw Message-ID: References: <629F7D3E-108D-43 A 1-B1E0-921922D70AEF@employees.org><9F9C99FA-FFCA-4EBA-9ECE-CFEF76AD0C6C@fr e e.fr><4B916BA7.3080400@gmail.com><4B950EF1.6010304@cisco .com><74EF8AD8-2D FE-4493-8AA8-6F79A3D66B83@free.fr><20100311074158 .537d551a@opy.nosense.org><4B980DF2.8030201@gmail.com><4B997E4B.6040009@ci sco.com><20100314111649.407f5 1db@opy.nosense.org><4B9C399A.1000800@gmail.com><4B9EE30C.4080006@gmail.com> <20100316191414.49b867c8@opy.nosense.org> In-Reply-To: <20100316191414.49b867c8@opy.nosense.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 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MTU per * [SOFTWIRE working group last call on 6rd] X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 17:31:40 -0000 Mark and Brian, > -----Original Message----- > From: Mark Smith [mailto:ipng@69706e6720323030352d30312d31340a.nosense.or= g] > Sent: Tuesday, March 16, 2010 1:44 AM > To: Brian E Carpenter > Cc: Templin, Fred L; softwires@ietf.org > Subject: Re: MTU per * [SOFTWIRE working group last call on 6rd] >=20 > On Tue, 16 Mar 2010 14:46:52 +1300 > Brian E Carpenter wrote: >=20 > > Below... > > > > On 2010-03-16 08:34, Templin, Fred L wrote: > > > Brian, > > > > > >> -----Original Message----- > > >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org]= On Behalf Of Templin, Fred > L > > >> Sent: Monday, March 15, 2010 9:16 AM > > >> To: Brian E Carpenter; Mark Smith > > >> Cc: softwires@ietf.org > > >> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > > >> > > >> Brian, > > >> > > >>> -----Original Message----- > > >>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org= ] On Behalf Of Brian E > Carpenter > > >>> Sent: Saturday, March 13, 2010 5:19 PM > > >>> To: Mark Smith > > >>> Cc: softwires@ietf.org > > >>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > > >>> > > >>> On 2010-03-14 13:46, Mark Smith wrote: > > >>> ... > > >>>> These are the sorts of scenarios which have made me wonder whether > > >>>> there should be some sort of mechanism to express different off-li= nk > > >>>> and on-link MTUs or on-site and off-site MTUs (distinguished by an > > >>>> on-site aggregate prefix). > > >>> I hope they're discussing that over in MIF. A different set of sett= ings > > >>> (not just MTU) per prefix seems entirely rational; a nice large MTU > > >>> for a ULA prefix might make sense. > > >> If you want to consider the IPv6 6rd global for off-site > > >> communications only, then that would be doable but I > > >> still think we should try for 1500 or larger instead of > > >> 1280 if at all possible. If you then want to consider an > > >> IPv6 ULA for on-site communications with larger MTU, that > > >> would be fine too. > > > > > > Going back slightly on what I said, what do you have > > > in mind - a per-prefix MTU? As I understand it, routers > > > advertise MTUs per-*link*; not per-*prefix*. Were you > > > thinking we could invent a per-prefix MTU advertisement > > > and use it to keep site-local communications at a higher > > > MTU than global communications? I don't se any standard > > > support mechanisms for something like that at this time > > > unless I'm missing something. > > > > That's why I said that I hope they are discussing this > > in MIF. Parameters per interface is one level of granularity, > > parameters per prefix is another. I haven't had time to see > > what MIF is up to. > > >=20 > I agree. I think there are 3 scopes for different MTUs - per link, per > site (possibly distinguished by a prefix), and offsite i.e. the > Internet. In my understanding, per-link is what implementations do today. An MTU is assigned to an interface, and an interface is attached to a link. So, I don't see any existing mechanism for associating an MTU with a prefix unless for example each prefix could be associated with a different *interface*, and multiple interfaces could attach to the same link. I can't see that happening without significant modifications to IPv6 ND and the conceptual sending algorithm - can you? For example, there would need to be an MTU associated with each Prefix Information Option as part of the router and prefix discovery procedure and there would need to be a source address based interface selection as part of the sending algorithm. Fred fred.l.templin@boeing.com > > Brian > > > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > >> Within the customer site, however, both the 6rd global > > >> and ULA can be serviced using ISATAP if native IPv6 is > > >> not yet available. > > >> > > >> Fred > > >> fred.l.templin@boeing.com > > >> > > >>> Brian From Fred.L.Templin@boeing.com Tue Mar 16 10:42:56 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36D23A6A69 for ; Tue, 16 Mar 2010 10:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GfJSdNn05d5 for ; Tue, 16 Mar 2010 10:42:52 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id F1ABA3A6A56 for ; Tue, 16 Mar 2010 10:42:51 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2GHgvHg004826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Mar 2010 10:42:58 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2GHgvl8027100; Tue, 16 Mar 2010 10:42:57 -0700 (PDT) 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 o2GHguTB027076 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 16 Mar 2010 10:42:57 -0700 (PDT) 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; Tue, 16 Mar 2010 10:42:56 -0700 From: "Templin, Fred L" To: "Durand, Alain" , softwires Date: Tue, 16 Mar 2010 10:42:54 -0700 Thread-Topic: Chair input on 6rd/MTU discussion Thread-Index: AcrEqbNK2jzDoF0DVkaYFgouo9qb6AAhRO1A 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: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A649511DD4B7XCHNW01Vnwnos_" MIME-Version: 1.0 Cc: Ole Troan Subject: Re: [Softwires] Chair input on 6rd/MTU discussion X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 17:42:57 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A649511DD4B7XCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alain and David, I agree that 6rd has many operational limitations. I pointed out several th= at have not yet been fully addressed: http://www.ietf.org/mail-archive/web/softwires/current/msg01263.html That means that 6rd needs to have an applicability statement as part of its base document, as was required for transition mechanisms developed in the ngtrans and early phases of v6ops days. Fred fred.l.templin@boeing.com ________________________________ From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Durand, Alain Sent: Monday, March 15, 2010 6:41 PM To: softwires Cc: Ole Troan Subject: [Softwires] Chair input on 6rd/MTU discussion Wg, As chairs, We've been looking at the MTU thread on 6rd. There has been many= good points made and we have had an healthy discussion. It is now time to = move on with the base spec. MTU is one of the many operational issues with = 6rd. The chairs and the authors discussed a while back to have a companion = document to 6rd that will focus on exactly those operational considerations= . We do believe that the 6rd MTU discussion belongs there. In order to not tie the hands of that new document, it will be better if th= e base spec were to remain silent on the MTU issue. This future operational document should be focused on 6rd and not try to so= lve the generic tunneling MTU discussion. The generic work is important too, and certainly need to find a home. Howev= er this is a different topic, for future discussions with our ADs. - Alain & David. --_000_E1829B60731D1740BB7A0626B4FAF0A649511DD4B7XCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chair input on 6rd/MTU discussion

Alain and David,

 

I agree that 6rd has many operational = limitations. I pointed out several that

have not yet been fully addressed:

 

  http://www.ietf.org/mail-archive/web/softwires/current/msg01263.html=

 

That means that 6rd needs to have an applicability statement as part of

its base document, as was required for transition mechanisms developed

in the ngtrans and early phases of v6o= ps days.

 

Fred

fred.l.templin@boeing.com

 

From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Durand, Alain
Sent: Monday, March 15, 2010= 6:41 PM
To: softwires
Cc: Ole Troan
Subject: [Softwires] Chair i= nput on 6rd/MTU discussion

 

Wg,


As chairs, We’ve been looking at the MTU thread on 6rd. There has bee= n many good points made and we have had an healthy discussion. It is now time= to move on with the base spec. MTU is one of the many operational issues with = 6rd. The chairs and the authors discussed a while back to have a companion docum= ent to 6rd that will focus on exactly those operational considerations. We do believe that the 6rd MTU discussion belongs there.
In order to not tie the hands of that new document, it will be better if th= e base spec were to remain silent on the MTU issue.
This future operational document should be focused on 6rd and not try to so= lve the generic tunneling MTU discussion.
The generic work is important too, and certainly need to find a home. Howev= er this is a different topic, for future discussions with our ADs.

  - Alain & David.

--_000_E1829B60731D1740BB7A0626B4FAF0A649511DD4B7XCHNW01Vnwnos_-- From Fred.L.Templin@boeing.com Tue Mar 16 10:47:43 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A738D3A6808 for ; Tue, 16 Mar 2010 10:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywtLoxF1L2ef for ; Tue, 16 Mar 2010 10:47:41 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id BD8683A67F2 for ; Tue, 16 Mar 2010 10:47:41 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2GHljRg007729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Mar 2010 10:47:46 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2GHliEi000370; Tue, 16 Mar 2010 12:47:44 -0500 (CDT) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2GHliJY000338 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 16 Mar 2010 12:47:44 -0500 (CDT) 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; Tue, 16 Mar 2010 10:47:44 -0700 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Tue, 16 Mar 2010 10:47:41 -0700 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrE+XP1Ft94LUClSH2RSqzt7ylxogANq6IQ Message-ID: References: <2ECA9A72-78E7-4809-BC38-CE7195183EBA@employees.org> <8AED8430-03D4-4BD9-B077-BE0CC8C2B162@free.fr> In-Reply-To: <8AED8430-03D4-4BD9-B077-BE0CC8C2B162@free.fr> 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 Cc: softwires , "Lee, Yiu" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 17:47:43 -0000 Remi, > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Tuesday, March 16, 2010 4:11 AM > To: Templin, Fred L > Cc: Ole Troan; softwires; Lee, Yiu > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 >=20 > Le 16 mars 2010 =E0 00:18, Templin, Fred L a =E9crit : >=20 > > As I said before, 6rd with a 1280 clamping might be pretty > > good, but why not go the extra step to remove artificial > > size restrictions and make it *great*. >=20 > The reason why 6rd IS "great", is because it has been kept simple, and in= particular stateless. > I therefore hope you don't mean that including SEAL in it would be an imp= rovement: that would destroy > its main virtue. "Fully stateless" does not in itself translate to "greatness". I have identified a number of operational limitations, many of which would be addressed with a modicum of soft state. 6rd to me is not great if it would be deployed with full knowledge that it would have to be replaced in the near future due to limitations brought on primarily through strict adherence to statelessness as a "virtue". Fred fred.l.templin@boeing.com > RD From brian.e.carpenter@gmail.com Tue Mar 16 17:49:45 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242A03A6B5A for ; Tue, 16 Mar 2010 17:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thrarpoQKDkr for ; Tue, 16 Mar 2010 17:49:44 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 582143A6B63 for ; Tue, 16 Mar 2010 17:49:44 -0700 (PDT) Received: by pvh1 with SMTP id 1so292602pvh.31 for ; Tue, 16 Mar 2010 17:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=EZh32/aanQX0WlL9tg/2rpJm8HA2FhvIzj+63A9vhNk=; b=PNHPn6LHETBXCAOV72kYEUQTuCanC03AR0/m1NL8TJHL/La28tKqeyx+qJJUBYuUf9 M1b01NnfcW2uLXNYbh6To3aFCTrzWr3HXkUTylrQyGltq2lZrTKcUhov/nrZRce5Nj8A l2V0PsUQl6hWzLUFZh/IX9Ek7ECaJGXdAqRm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=fO6bWuZa04ux0czuP56cEdu8FjLegEeWjwi39Z5J6qzU2y9tKuv3cInQ2Y/90vTVSu s79vAv+ykf/fTzJsc5ixGdFBoIrLG7sAfRAou5bE4MT5bC2o1mKby/y+AYdxwFCeqr3U rR7TNSU+YY9alvfeQx7ivTrrsM7JRD2vnNISU= Received: by 10.115.39.39 with SMTP id r39mr95725waj.157.1268786990778; Tue, 16 Mar 2010 17:49:50 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm1771307pzk.5.2010.03.16.17.49.49 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Mar 2010 17:49:50 -0700 (PDT) Message-ID: <4BA02731.1080408@gmail.com> Date: Wed, 17 Mar 2010 13:49:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <20100301183001.E751F3A896E@core3.amsl.com> <4B9EF3C8.8010101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action:draft-despres-softwire-sam-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 00:49:45 -0000 > In customer SAMs, mapping rules are always acquired automatically. Fine, but who creates them in order from them to be acquired? Where do they come from? If there are a hundred million customer sites in the world, who or what creates their individual mapping rules? Regards Brian On 2010-03-16 22:54, R=C3=A9mi Despr=C3=A9s wrote: > Brian, >=20 > Answers below. >=20 > Le 16 mars 2010 =C3=A0 03:58, Brian E Carpenter a =C3=A9crit : >=20 >> R=C3=A9mi, >> >> Let's take it for granted that >> >> a) it is possible to design a general format for mapping rules, >> that would work in a variety of scenarios including map-and-encap >> and NAT; >> >> b) the format and examples in the draft are complete and correct; >> >> c) tunnel end points and NATs can be "taught" to obey such maps. >> >> Then consider this: >> >>> 2.7. Acquisition of Mapping Rules by Customer Nodes >>> >>> For early experimentations or advanced uses, a customer SAM may >>> acquire the SAM rules of its SAM domain by administrative >>> configuration. But for extensive deployments, they must be acquire= d >>> automatically. The DHCP of [RFC2131] and DHCPv6 of [RFC3315]) can = be >>> used for this. Alternatively, in particular for scenarios where >>> NAT44s have to be traversed, using the DNS as proposed in section 6= >>> of [DNS-SD] can be a better approach. >> That implies that the map for a given point is acquired automatically,= >> but it doesn't explain how the map is created. >=20 > In customer SAMs, mapping rules are always acquired automatically. > In provider SAMs, there are many scenarios where it is reasonable to co= nfigure them administratively. (This is like in 6rd, where 6rd parameters= are administratively configured in 6rd BRs, and automatically acquired b= y 6rd CEs). >=20 >=20 >> It seems that for usage >> at Internet scale, the maps would have to be generated and propagated >> automatically. Isn't this a hard problem >=20 > I am not sure to understand what you mean by "the map". > The hierarchy of exterior prefixes follows the classical model of CIDR = prefixes. That's all.=20 >=20 > The example of section 3.4 (the planned Telecom-Bretagne experiment) sh= ows a 2-layer hierarchy of SAM domains, which may be a partial answer. >=20 > Besides, deriving provider-SAM rules from locally available parameters = is internal to each provider-side BR. > Where configuration of mapping rules in provider SAMs should be automat= ed, proprietary solutions are therefore possible. > (Having a standard for this can be nice, but is not necessary). =20 >=20 >> (exactly the same problem >> that arises for LISP)? Or have I misunderstood the deployment model? >=20 > In my understanding, the fact that LISP addresses have a distinct forma= t makes it necessary that LISP be supported both in source and destinatio= n domains that communicate across the Internet core. > On the contrary, SAM addresses are routable like any native addresses e= verywhere outside of SAM domains themselves. > The deployment can therefore be incremental (similarly to that of 6rd, = of which SAM is an extension).=20 >=20 > RD >=20 >=20 >=20 >=20 From remi.despres@free.fr Wed Mar 17 00:42:34 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A813A62C1 for ; Wed, 17 Mar 2010 00:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDxOzXj7vG4E for ; Wed, 17 Mar 2010 00:42:33 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id A3D6A3A6849 for ; Wed, 17 Mar 2010 00:42:30 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 28325E080F5; Wed, 17 Mar 2010 08:42:35 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id E363EE080AA; Wed, 17 Mar 2010 08:42:32 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 17 Mar 2010 08:42:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6E2E4B62-DF6C-4485-A834-45A993AAAE52@free.fr> References: <20100223203618.G A13301@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <12670 0 5876.2679.231.camel@lnxos-dev><4B86D8F3.9000108@gmail.com> <700287C3-4EAA-4027-8CCC-17201B628CDB@free.fr> <4B8CD37A.5090203@gmail.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1077) Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 07:42:34 -0000 Fred, Here are some quick reactions to the list of issues you see for an = applicability-statement document on 6rd. =20 Le 2 mars 2010 =E0 17:51, Templin, Fred L a =E9crit : > I see a number of aspects > of 6rd that IMHO would limit its applicability, including: >=20 > - IPv6 prefix tied to IPv4 address (renumbering implications) A site has a valid IPv6 address as long as it has a valid IPv4 address.=20= > - potential black holes when ICMPs can't be translated I don't see which are these "ICMPs that can't be translated"? > - provider-aggregated addressing only (no provider-independent) I don't see the problem. > - not compatible with multihoming via a single, stable IPv6 prefix Same as previous point? > - not compatible with traffic engineering (i.e., CE can't select > specific BRs) It doesn't need to. > - interactions with load balancing; ECMP within provider network No problem, this is the advantage of stateless solutions. > - MTU clamping exposes degenerate MTUs to the customer network > and doesn't allow for automatic discovery of larger MTUs This is a general 6rd problem (not 6rd specific). =20 > - requires operators to exercise tight controls on link MTUs ISPs that want to use 6rd have to know which IPv4 MTU they support, this = MTU being at least sufficient to encapsulate 1280B IPv6 packets The draft is clear, and what it says is sufficient.=20 > - requires operators to exercise tight controls on ICMP > generation and ICMP filtering Nothing special, ICMPv6 error messages must be generated, and forwarded = as usual. Due to the absence of fragmentation of 6rd packets in 6rd domains, = ICMPv4 error messages can always be translated.=20 Regards, RD From remi.despres@free.fr Wed Mar 17 02:13:54 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CEEB3A681A; Wed, 17 Mar 2010 02:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[AWL=-0.837, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwjawH7v9-Mm; Wed, 17 Mar 2010 02:13:53 -0700 (PDT) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by core3.amsl.com (Postfix) with ESMTP id 668FF3A6820; Wed, 17 Mar 2010 02:13:50 -0700 (PDT) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id C0B75E08101; Wed, 17 Mar 2010 10:13:55 +0100 (CET) Received: from [192.168.0.10] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp6-g21.free.fr (Postfix) with ESMTP id 92D38E081BD; Wed, 17 Mar 2010 10:13:52 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-1-599739512 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <428863.89468.qm@web45507.mail.sp1.yahoo.com> Date: Wed, 17 Mar 2010 10:13:51 +0100 Message-Id: <03D3DDBD-1F2F-4C0E-ACE2-7D91C1D7EF77@free.fr> References: <428863.89468.qm@web45507.mail.sp1.yahoo.com> To: Gabi Nakibly X-Mailer: Apple Mail (2.1077) Cc: softwires , Ole Troan , DHC WG Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 09:13:54 -0000 --Apple-Mail-1-599739512 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 1 mars 2010 =E0 08:44, Gabi Nakibly a =E9crit : > ... > Second, regarding loops via internal relays the draft mentions that: > =20 > To avoid forwarding loops via other internal relays, the BR should > employ outgoing and incoming IPv4 packets filters, filtering out = all > known relay addresses for internal 6rd BRs, ISATAP routers or 6to4 > relays, including the well known anycast address space for 6to4. > =20 > Does the SP necessarily knows of every ISATAP router or 6to4 relay = deployed in the 6rd domain? After all, a customer can deploy an ISATAP = router or even a 6to4 relay for that matter without the knowledge of the = SP, while using a configured tunnel (by a tunnel broker) for its IPv6 = connectivity. Gabi, I didn't succeed to create a detailed configuration where a 6rd CE, = which is also an ISATAP router, can create a routing loop. Would you have one that you can share? Cheers, RD --Apple-Mail-1-599739512 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
...
Second, = regarding loops via internal relays the draft mentions that:
 
   = To avoid forwarding loops via other internal relays, the BR = should
   employ outgoing and incoming IPv4 packets = filters, filtering out all
   known relay addresses for = internal 6rd BRs, ISATAP routers or 6to4
   relays, = including the well known anycast address space for 6to4.
 
Does the = SP necessarily knows of every ISATAP router or 6to4 = relay deployed in the 6rd domain? After all, a customer can = deploy an ISATAP router or even a 6to4 relay for that = matter without the knowledge of the SP, while using = a configured tunnel (by a tunnel broker) for its IPv6 = connectivity.

To: softwires Message-ID: Thread-Topic: Meeting agenda Thread-Index: AcrF5WB1PbXc3S0xD0awNMr2Hlt/rg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3351669630_5287614" X-OriginalArrivalTime: 17 Mar 2010 15:20:32.0645 (UTC) FILETIME=[62A20B50:01CAC5E5] Subject: [Softwires] Meeting agenda X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 15:24:47 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3351669630_5287614 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The softwire wg will meet on Wednesday afternoon. Due to the short length of our slot (only one hour), we need to focus on key agenda items: Here is the proposed agenda that I posted on the IETF web site: 5 min: Administrativia, chair 5 min: 6rd: Ole Troan http://datatracker.ietf.org/doc/draft-ietf-softwire-ipv6-6rd/ 10 min: GI-DS-lite: Sri Gundavelli http://datatracker.ietf.org/doc/draft-gundavelli-softwire-gateway-init-ds-li te/ 40 min: PCP: Dan wing/Dave Thaler http://datatracker.ietf.org/doc/draft-wing-softwire-port-control-protocol/ We have received many other valuable agenda item submission, those will be reconsidered for the next IETF meeting. - Alain, softwire co-chair. --B_3351669630_5287614 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Meeting agenda The softwire wg will meet on Wednesday afternoon. Due to the short length = of our slot (only one hour), we need to focus on key agenda items:
Here is the proposed agenda that I posted on the IETF web site:
 5 min: Administrativia, chair
 5 min: 6rd: Ole Troan http://datatracker.ietf.org/doc/draft-ietf-softwire= -ipv6-6rd/
10 min: GI-DS-lite: Sri Gundavelli http://datatracker.ietf.or= g/doc/draft-gundavelli-softwire-gateway-init-ds-lite/
40 min: PCP: Dan wing/Dave Thaler http://datatracker.ietf.org/doc/= draft-wing-softwire-port-control-protocol/

We have received many other valuable agenda item submission, those will be = reconsidered for the next IETF meeting.

   - Alain, softwire co-chair. --B_3351669630_5287614-- From Fred.L.Templin@boeing.com Wed Mar 17 10:43:58 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D30733A67B3 for ; Wed, 17 Mar 2010 10:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.751 X-Spam-Level: X-Spam-Status: No, score=-4.751 tagged_above=-999 required=5 tests=[AWL=-1.671, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXjYnDW8GLLw for ; Wed, 17 Mar 2010 10:43:57 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id C03783A69D9 for ; Wed, 17 Mar 2010 10:43:57 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2HHi2iL013642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Mar 2010 10:44:03 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2HHi2Ph003657; Wed, 17 Mar 2010 12:44:02 -0500 (CDT) 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 o2HHi1B7003616 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 17 Mar 2010 12:44:02 -0500 (CDT) 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; Wed, 17 Mar 2010 10:44:01 -0700 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Wed, 17 Mar 2010 10:44:00 -0700 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrFpW3o4CQ4fSiTRsKDiVPOCm2VGwASWLbA Message-ID: References: <20100223203618.G A13301@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <12670 0 5876.2679.231.camel@lnxos-dev><4B86D8F3.9000108@gmail.com> <700287C3-4EAA-4027-8CCC-17201B628CDB@free.fr> <4B8CD37A.5090203@gmail.com> <6E2E4B62-DF6C-4485-A834-45A993AAAE52@free.fr> In-Reply-To: <6E2E4B62-DF6C-4485-A834-45A993AAAE52@free.fr> 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 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 17:43:58 -0000 Hi Remi, Responding to your post: > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Wednesday, March 17, 2010 12:43 AM > To: Templin, Fred L > Cc: Brian E Carpenter; softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > Fred, >=20 > Here are some quick reactions to the list of issues you see for an applic= ability-statement document > on 6rd. >=20 > Le 2 mars 2010 =E0 17:51, Templin, Fred L a =E9crit : > > I see a number of aspects > > of 6rd that IMHO would limit its applicability, including: > > > > - IPv6 prefix tied to IPv4 address (renumbering implications) > A site has a valid IPv6 address as long as it has a valid IPv4 address. The point is that, if a site's IPv4 address changes, its (6rd-derived) IPv6 prefix also changes. If that were the case, then all IPv6 routers and hosts within the site would have to renumber. Thus, as a limitation to the domain of applicability, 6rd is appropriate only to those sites that either a) are guaranteed to always have the same IPv4 address assignment, or b) can tolerate an IPv6 prefix renumbering event. This would need to be discussed in an applicability statement. > > - potential black holes when ICMPs can't be translated > I don't see which are these "ICMPs that can't be translated"? ICMPv4 messages are permitted by standards to contain only a minimal packet-in-error consisting of the IPv4 header plus 8 bytes beyond the header. For ipproto-41 packets, that means that only the first 8 bytes of the encapsulated IPv6 header may be present in the ICMPv4 header. That is not enough information for stateless translation to a corresponding ICMPv6 message, so unless some state is kept in the 6rd router no ICMPv6 message can be delivered to the original IPv6 source. Thus, 6rd has a potential black hole condition in environments where standards-compliant routers might produce only minimal ICMPv4 messages. =20 > > - provider-aggregated addressing only (no provider-independent) > I don't see the problem. Some end systems may wish to use a single and stable IPv6 source address prefix which the routing system can represent to multiple providers for fault tolerance and load balancing purposes. Thus, as a limitation to the domain of applicability, multihoming and traffic engineering would have to be directed by the end systems instead of the 6rd router, and session continuity cannot be preserved in the event of failure of a provider link.=20 =20 > > - not compatible with multihoming via a single, stable IPv6 prefix > Same as previous point? Discussed above. > > - not compatible with traffic engineering (i.e., CE can't select > > specific BRs) > It doesn't need to. In some 6rd domains, the routing system may give preference to certain BRs over others for reasons that are unrelated to (and perhaps in conflict with) the use of 6rd. So, unless the 6rd routers s become involved in explicit BR selection based on load balancing, ECMP, default router preferences, etc. any traffic engineering is at the whim of the network and not under the control of the 6rd router. This comment is oriented to the exclusive use of anycast for BR selection, while later versions of the 6rd spec (i.e., the Townsley/Troan spec) have hinted that unicast addresses may be made available at some point. Thus, if an applicability statement is included it should discuss traffic engineering assumptions in relation to anycast vs unicast BR addresses. > > - interactions with load balancing; ECMP within provider network > No problem, this is the advantage of stateless solutions. This folds into the discussion point above, and if an applicability statement is included it needs to discuss interactions between 6rd and network-based mechanisms such as load balancing and ECMP. > > - MTU clamping exposes degenerate MTUs to the customer network > > and doesn't allow for automatic discovery of larger MTUs > This is a general 6rd problem (not 6rd specific). Maybe you meant a general problem for tunneling? If an applicability statement is included, however, it should also mention the implications of MTU clamping.=20 =20 > > - requires operators to exercise tight controls on link MTUs > ISPs that want to use 6rd have to know which IPv4 MTU they support, this = MTU being at least > sufficient to encapsulate 1280B IPv6 packets > The draft is clear, and what it says is sufficient. If an applicability statement is included, it should also mention the need for well-managed MTUs in the provider network. > > - requires operators to exercise tight controls on ICMP > > generation and ICMP filtering > Nothing special, ICMPv6 error messages must be generated, and forwarded a= s usual. > Due to the absence of fragmentation of 6rd packets in 6rd domains, ICMPv4= error messages can always > be translated. This folds into the discussion above regarding standards- compliant ICMPv4s that contain insufficient information for translation. The point about fragmentation brings up a critical issue wrt the use of anycast as an IPv4 source address. If multiple 6rd BRs use the same IPv4 source address when sending tunneled packets to the same 6rd CE router, and the BRs do not coordinate the IP IDs they use, then collisions within the CE router reassembly cache can more readily lead to undetected data corruption than is the case for non-anycast. That means that when 6rd BRs use an anycast source address, there *really* needs to be strong assurance against fragmentation in the network. Clamping the MTU and setting DF=3D1 would be best in that case. Fred fred.l.templin@boeing.com > Regards, > RD >=20 From Fred.L.Templin@boeing.com Wed Mar 17 10:55:14 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAFF33A6816 for ; Wed, 17 Mar 2010 10:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.463 X-Spam-Level: X-Spam-Status: No, score=-5.463 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_51=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdA7Qu4zlWHb for ; Wed, 17 Mar 2010 10:55:13 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id D62F43A684A for ; Wed, 17 Mar 2010 10:55:12 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2HHt9j5002088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Mar 2010 12:55:10 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2HHt86l022955; Wed, 17 Mar 2010 10:55:08 -0700 (PDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2HHt72U022893 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 17 Mar 2010 10:55:08 -0700 (PDT) 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, 17 Mar 2010 10:55:07 -0700 From: "Templin, Fred L" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Date: Wed, 17 Mar 2010 10:55:05 -0700 Thread-Topic: [Softwires] SOFTWIRE working group last call on 6rd Thread-Index: AcrFpW3o4CQ4fSiTRsKDiVPOCm2VGwASWLbAAALb/lA= Message-ID: References: <20100223203618.G A13301@isc.org><13AB07B1-3E69-4F74-AB72-9E913E98B480@employees.org> <126700 5876.2679.231.camel@lnxos-dev><4B86D8F3.9000108@gmail.com><700287C3-4EAA-4027-8CCC-17201B628CDB@free.fr><4B8CD37A.5090203@gmail .com><6E2E4B62-DF6C-4485-A834-45A993AAAE52@free.fr> 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 Cc: "softwires@ietf.org" Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 17:55:14 -0000 Remi, I'm sorry, I forgot to add that the 6rd domain must be made secure against IPv4 source address spoofing. Domains that cannot ensure this may not qualify as being within the 6rd domain of applicability. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Templin, Fred L > Sent: Wednesday, March 17, 2010 10:44 AM > To: R=E9mi Despr=E9s > Cc: softwires@ietf.org > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >=20 > Hi Remi, >=20 > Responding to your post: >=20 > > -----Original Message----- > > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > > Sent: Wednesday, March 17, 2010 12:43 AM > > To: Templin, Fred L > > Cc: Brian E Carpenter; softwires@ietf.org > > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > > > > Fred, > > > > Here are some quick reactions to the list of issues you see for an appl= icability-statement document > > on 6rd. > > > > Le 2 mars 2010 =E0 17:51, Templin, Fred L a =E9crit : > > > I see a number of aspects > > > of 6rd that IMHO would limit its applicability, including: > > > > > > - IPv6 prefix tied to IPv4 address (renumbering implications) > > A site has a valid IPv6 address as long as it has a valid IPv4 address. >=20 > The point is that, if a site's IPv4 address changes, its > (6rd-derived) IPv6 prefix also changes. If that were the > case, then all IPv6 routers and hosts within the site > would have to renumber. Thus, as a limitation to the domain > of applicability, 6rd is appropriate only to those sites > that either a) are guaranteed to always have the same IPv4 > address assignment, or b) can tolerate an IPv6 prefix > renumbering event. This would need to be discussed in > an applicability statement. >=20 > > > - potential black holes when ICMPs can't be translated > > I don't see which are these "ICMPs that can't be translated"? >=20 > ICMPv4 messages are permitted by standards to contain only > a minimal packet-in-error consisting of the IPv4 header plus > 8 bytes beyond the header. For ipproto-41 packets, that means > that only the first 8 bytes of the encapsulated IPv6 header > may be present in the ICMPv4 header. That is not enough > information for stateless translation to a corresponding > ICMPv6 message, so unless some state is kept in the 6rd > router no ICMPv6 message can be delivered to the original > IPv6 source. Thus, 6rd has a potential black hole condition > in environments where standards-compliant routers might > produce only minimal ICMPv4 messages. >=20 > > > - provider-aggregated addressing only (no provider-independent) > > I don't see the problem. >=20 > Some end systems may wish to use a single and stable IPv6 > source address prefix which the routing system can represent > to multiple providers for fault tolerance and load balancing > purposes. Thus, as a limitation to the domain of applicability, > multihoming and traffic engineering would have to be directed > by the end systems instead of the 6rd router, and session > continuity cannot be preserved in the event of failure of > a provider link. >=20 > > > - not compatible with multihoming via a single, stable IPv6 prefix > > Same as previous point? >=20 > Discussed above. >=20 > > > - not compatible with traffic engineering (i.e., CE can't select > > > specific BRs) > > It doesn't need to. >=20 > In some 6rd domains, the routing system may give preference > to certain BRs over others for reasons that are unrelated to > (and perhaps in conflict with) the use of 6rd. So, unless > the 6rd routers s become involved in explicit BR selection > based on load balancing, ECMP, default router preferences, > etc. any traffic engineering is at the whim of the network > and not under the control of the 6rd router. >=20 > This comment is oriented to the exclusive use of anycast for > BR selection, while later versions of the 6rd spec (i.e., the > Townsley/Troan spec) have hinted that unicast addresses may > be made available at some point. Thus, if an applicability > statement is included it should discuss traffic engineering > assumptions in relation to anycast vs unicast BR addresses. >=20 > > > - interactions with load balancing; ECMP within provider network > > No problem, this is the advantage of stateless solutions. >=20 > This folds into the discussion point above, and if an > applicability statement is included it needs to discuss > interactions between 6rd and network-based mechanisms > such as load balancing and ECMP. >=20 > > > - MTU clamping exposes degenerate MTUs to the customer network > > > and doesn't allow for automatic discovery of larger MTUs > > This is a general 6rd problem (not 6rd specific). >=20 > Maybe you meant a general problem for tunneling? If an > applicability statement is included, however, it should > also mention the implications of MTU clamping. >=20 > > > - requires operators to exercise tight controls on link MTUs > > ISPs that want to use 6rd have to know which IPv4 MTU they support, thi= s MTU being at least > > sufficient to encapsulate 1280B IPv6 packets > > The draft is clear, and what it says is sufficient. >=20 > If an applicability statement is included, it should > also mention the need for well-managed MTUs in the > provider network. >=20 > > > - requires operators to exercise tight controls on ICMP > > > generation and ICMP filtering > > Nothing special, ICMPv6 error messages must be generated, and forwarded= as usual. > > Due to the absence of fragmentation of 6rd packets in 6rd domains, ICMP= v4 error messages can always > > be translated. >=20 > This folds into the discussion above regarding standards- > compliant ICMPv4s that contain insufficient information > for translation. >=20 > The point about fragmentation brings up a critical issue > wrt the use of anycast as an IPv4 source address. If > multiple 6rd BRs use the same IPv4 source address when > sending tunneled packets to the same 6rd CE router, and > the BRs do not coordinate the IP IDs they use, then > collisions within the CE router reassembly cache can > more readily lead to undetected data corruption than > is the case for non-anycast. That means that when 6rd > BRs use an anycast source address, there *really* needs > to be strong assurance against fragmentation in the > network. Clamping the MTU and setting DF=3D1 would be > best in that case. >=20 > Fred > fred.l.templin@boeing.com >=20 > > Regards, > > RD > > >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From wwwrun@core3.amsl.com Thu Mar 18 15:44:44 2010 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0D1B03A68A6; Thu, 18 Mar 2010 15:44:43 -0700 (PDT) To: shep@cisco.com From: IETF Secretariat Message-Id: <20100318224444.0D1B03A68A6@core3.amsl.com> Date: Thu, 18 Mar 2010 15:44:44 -0700 (PDT) Cc: rdroms.ietf@gmail.com, softwires@ietf.org, ipr-announce@ietf.org Subject: [Softwires] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-softwire-4over6vpns-00 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 22:44:44 -0000 Dear Greg Shepherd: An IPR disclosure that pertains to your Internet-Draft entitled "IPv4 unicast/multicast VPNs over an IPv6 core" (draft-ietf-softwire-4over6vpns) was submitted to the IETF Secretariat on 2010-03-12 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1293/). The title of the IPR disclosure is "Cisco's Statement of IPR relating to draft-ietf-softwire-4over6vpns-00." The IETF Secretariat From jason_livingood@cable.comcast.com Sun Mar 21 18:56:55 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22DC3A6885 for ; Sun, 21 Mar 2010 18:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.225 X-Spam-Level: *** X-Spam-Status: No, score=3.225 tagged_above=-999 required=5 tests=[AWL=-3.506, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aySJMqIbf0-v for ; Sun, 21 Mar 2010 18:56:48 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 0B3C83A67A4 for ; Sun, 21 Mar 2010 18:56:47 -0700 (PDT) Received: from ([24.40.15.92]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.88680704; Sun, 21 Mar 2010 21:56:40 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Mar 2010 21:56:40 -0400 Received: from 75.242.58.174 ([75.242.58.174]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Mon, 22 Mar 2010 01:56:39 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Sun, 21 Mar 2010 21:56:35 -0400 From: Jason Livingood To: , Reinaldo Penno , , Message-ID: Thread-Topic: Feedback on draft-wing-softwire-port-control-protocol-01 Thread-Index: AcrJYubSH2NZvvrJ7UCv0Q5UWgRGiw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3352053396_30095" X-OriginalArrivalTime: 22 Mar 2010 01:56:40.0227 (UTC) FILETIME=[E9EFDF30:01CAC962] Subject: [Softwires] Feedback on draft-wing-softwire-port-control-protocol-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 01:56:56 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3352053396_30095 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I thought I=B9d send over some feedback re this draft. Feel free to ignore some or all of my feedback. :-) 1 =AD Section 2 =AD Requirements I like the requirements but find it increasingly useful when documents call out requirements in a more direct fashion. Meaning, instead of Section 2 having a general list of 15 items you could call the out as REQ1 to REQ15. This is of course a matter of personal preference of course. If you use XML for your I-Ds, you could use this kind of list style: 2 =AD Requirement #2: Nothing to change but my expectation is that this can handle into the 10s of thousands to 100s of thousands of customers. 3 =AD Req 3: protocol semantics is --> protocol semantics are ? 4 =AD Req 4: reword (awkward) --> allows graceful definition of... 5 =AD Re 7: reword: ...can even be notified to a client --> ...can even be communicated to a client 6 =AD Req 8: ...detect if port control server --> ...detect if the port control server 7 =AD Req 9: either =B3an=B2 existing mapping or =B3existing mapping(s)=B2 -- based o= n your singular usage of mapping elsewhere, I=B9d suggest adding =B3an=B2 8 =AD Seeing Terminology in Section 3, I wonder if it makes sense to place th= e terminology before the requirements (which may argue for splitting section = 2 into Section 2 =AD Scope, then Section 3 =AD Terminology, then Section 4 =AD Protocol Requirements). In the terminology section, it=B9d be helpful to hav= e either direct terms or references relating to NAT64, NAT44, CP Router, and perhaps even NAT itself (some of this is in place already in your doc). Would also be nice to define stuff like Port Control Server, Port Requestor= , etc. (or whatever terms you prefer for these elements), which you touch on in Section 5 (so perhaps a mention that the definitions of specific functional elements X, Y, and Z can be found in Section XX =AD as an internal document reference). A separate debate is over the use of CP router vs. home gateway vs. whatever, but that=B9s not essential to continued work on th= e other points of your document for now. 9 =AD Req 12 and Req 14: =B3NATted environments=B2 seems awkward, as it essentially =3D Network Address Translationed environments. I may recommend the simpler =B3NAT environments=B2 or =B3environments using NAT=B2 as an alternativ= e 10 =AD ADD new Req: =B3Ability to set a Time to Live (TTL) or timer on the port assignment, after which time the mapping is deleted (destroyed);=B2 I would also then add one immediately after this: =B3Ability to communicate the TTL for a given mapping from the Port Control Server to the Port Requestor;=B2 (you describe Mapping TTL as the Port Mapping Lifetime in 7.1.2 and removal as Port Mapping Destruction in 7.1.4) 11 =AD Req 14: Recommend references be added for UPnP IGD and NAT-PMP 12 =AD Section 6: Discovery =8B may want to add =B3This list is for example purposes only and shall not restrict the potential methods for discovery.=B2 This would make it more clear that new discovery methods may be used over time, and therefore that the list is non-exclusive. 13 =AD Section 7.1.1, Note-4: Interesting question re challenge/response (to which I don=B9t have a comment at the moment). At some point I think we should collectively give some thought to avenues for abuse. 14 =AD Section 7.1.8: I could envision an eventual desire for more specific result codes relating to errors and other conditions. Thus, while 3-Delete= d my suffice for now, it may be nice to have that result be, say, 300. Thus, eventually you may have 301-Deleted-TTL expired, and 302-Deleted-AtClientRequest, and 303-Deleted-InternalError, etc. This could be more helpful from an operations standpoint. For example, I may want to monitor for 303 responses (in my example) and alarm if I see any or if it exceeds a certain threshold. Similarly, the 4 =AD Out of Resources result ma= y eventually have sub-variants like =ADMemory, -Storage, -Bandwidth, -whatever. The specific codes desired may only be learned upon implementation of the protocol, so I suppose I am simply suggesting you build in the ability to deliver more detailed result codes later, that are still within the genera= l categories you have laid out in the I-D. 15 =AD Section 8.1, Part 1: You repeat =B3a request=B2 in the 1st sentence Regards, Jason --B_3352053396_30095 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Feedback on draft-wing-softwire-port-control-protocol-01 I thought I’d send over some feedback re this draft.  Feel free= to ignore some or all of my feedback.  :-)

1 – Section 2 – Requirements
I like the requirements but find it increasingly useful when documents call= out requirements in a more direct fashion.  Meaning, instead of Sectio= n 2 having a general list of 15 items you could call the out as REQ1 to REQ1= 5.  This is of course a matter of personal preference of course. If you= use XML for your I-Ds, you could use this kind of list style:
<list style=3D"format REQ%d:" counter=3D"protocol_requirement= s_count">

2 – Requirement #2: Nothing to change but my expectation is that this= can handle into the 10s of thousands to 100s of thousands of customers.

3 – Req 3: protocol semantics is --> protocol semantics are ?

4 – Req 4: reword (awkward) --> allows graceful definition of...
5 – Re 7: reword: ...can even be notified to a client --> ...can e= ven be communicated to a client

6 – Req 8: ...detect if port control server --> ...detect if the p= ort control server

7 – Req 9: either “an” existing mapping or “existin= g mapping(s)” -- based on your singular usage of mapping elsewhere, I&= #8217;d suggest adding “an”

8 – Seeing Terminology in Section 3, I wonder if it makes sense to pl= ace the terminology before the requirements (which may argue for splitting s= ection 2 into Section 2 – Scope, then Section 3 – Terminology, t= hen Section 4 – Protocol Requirements).  In the terminology secti= on, it’d be helpful to have either direct terms or references relating= to NAT64, NAT44, CP Router, and perhaps even NAT itself (some of this is in= place already in your doc).  Would also be nice to define stuff like P= ort Control Server, Port Requestor, etc. (or whatever terms you prefer for t= hese elements), which you touch on in Section 5 (so perhaps a mention that t= he definitions of specific functional elements X, Y, and Z can be found in S= ection XX – as an internal document reference).  A separate debat= e is over the use of CP router vs. home gateway vs. whatever, but that’= ;s not essential to continued work on the other points of your document for = now.

9 – Req 12 and Req 14: “NATted environments” seems awkwar= d, as it essentially =3D Network Address Translationed environments.  I m= ay recommend the simpler “NAT environments” or “environmen= ts using NAT” as an alternative

10 – ADD new Req: “Ability to set a Time to Live (TTL) or timer= on the port assignment, after which time the mapping is deleted (destroyed)= ;”  I would also then add one immediately after this: “Abil= ity to communicate the TTL for a given mapping from the Port Control Server = to the Port Requestor;”  (you describe Mapping TTL as the Port Ma= pping Lifetime in 7.1.2 and removal as Port Mapping Destruction in 7.1.4)
11 – Req 14: Recommend references be added for UPnP IGD and NAT-PMP
12 – Section 6: Discovery — may want to add “This list is= for example purposes only and shall not restrict the potential methods for = discovery.”  This would make it more clear that new discovery met= hods may be used over time, and therefore that the list is non-exclusive.
13 – Section 7.1.1, Note-4: Interesting question re challenge/respons= e (to which I don’t have a comment at the moment).  At some point= I think we should collectively give some thought to avenues for abuse.

14 – Section 7.1.8: I could envision an eventual desire for more spec= ific result codes relating to errors and other conditions.  Thus, while= 3-Deleted my suffice for now, it may be nice to have that result be, say, 3= 00.  Thus, eventually you may have 301-Deleted-TTL expired, and 302-Del= eted-AtClientRequest, and 303-Deleted-InternalError, etc. This could be more= helpful from an operations standpoint.  For example, I may want to mon= itor for 303 responses (in my example) and alarm if I see any or if it excee= ds a certain threshold.  Similarly, the 4 – Out of Resources resu= lt may eventually have sub-variants like –Memory, -Storage, -Bandwidth= , -whatever.  The specific codes desired may only be learned upon imple= mentation of the protocol, so I suppose I am simply suggesting you build in = the ability to deliver more detailed result codes  later, that are stil= l within the general categories you have laid out in the I-D.

15 – Section 8.1, Part 1: You repeat “a request” in the 1= st sentence

Regards,
Jason --B_3352053396_30095-- From bingxuere.mail@gmail.com Mon Mar 22 07:28:48 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08DE23A688F for ; Mon, 22 Mar 2010 07:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.032 X-Spam-Level: ** X-Spam-Status: No, score=2.032 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcrqW4zuj5l4 for ; Mon, 22 Mar 2010 07:28:47 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 31C8E3A68EA for ; Mon, 22 Mar 2010 07:28:31 -0700 (PDT) Received: by pvh1 with SMTP id 1so2835835pvh.31 for ; Mon, 22 Mar 2010 07:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ypfUB5ceXGfxo4zNQQ2q9VXJJCPi9wc5WJ3mb1VPd4A=; b=acGCEg/14521xe+0w+tpnegIaGEGoqXkfb7zGaG4HBvV246CHm3S3jE3aeSWz8A7jB zMqA9fFIHreeyl7KsQbAoD8oGGzGbjdI9/B1iaVzRe7lWVsFywGXKlh1OJre1UidSxhu OMiXkaSkMC+0ubeWoEjUOYRYQjFk+xA4e92Qo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uo1iIZnYS+MjG7OM1M70+I6vaS6GVeRIgKjUso3wWoL9oezUpuBrCsatFTVfK9s/81 aiuQ9w4jHzALmkTyF6SrfHwHvsC9IBuaMXwRbmC8HlN3T0WOw3J/Ye9xXAu66aIX+CoQ dJD6sZ+11sDd6PF//JRA8YBo7/BUtcfzEJs64= MIME-Version: 1.0 Received: by 10.143.27.1 with SMTP id e1mr510528wfj.343.1269268125766; Mon, 22 Mar 2010 07:28:45 -0700 (PDT) Date: Mon, 22 Mar 2010 22:28:45 +0800 Message-ID: <327c9c3b1003220728n3db89ea6k788d90339e1334d7@mail.gmail.com> From: =?GB2312?B?y+/H7Q==?= To: softwires@ietf.org Content-Type: multipart/alternative; boundary=0050450294e3c2d5a2048264835e Subject: [Softwires] [Softwire] Questions on draft-boucadair-dslite-interco-v4v6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 14:28:48 -0000 --0050450294e3c2d5a2048264835e Content-Type: text/plain; charset=ISO-8859-1 Hi Boucadair, I'm wondering if I have missed something in this draft. I can understand that in this extended DS-Lite, ICXF is core stateless and it is quite scalable for core routers. However, since CPEs can send both IPv4 packet and IPv6 packet to AFTR, it will then include double NAT problem if we have to allocate private IPv4 address to CPEs. Then what is the advantage of this kind of DS-Lite vs. NAT666 plus dual stack? Thank you very much. Best regards Qiong SUN --0050450294e3c2d5a2048264835e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Boucadair,
=A0
I'm wondering if I have missed something in this draft. I can unde= rstand that in this extended DS-Lite, ICXF=A0is core stateless and it is qu= ite scalable for core routers. However,=A0 since CPEs can send both IPv4 pa= cket and IPv6 packet to AFTR, it will then=A0include double NAT problem if = we have to allocate private IPv4 address to CPEs. Then what is the advantag= e of this kind of DS-Lite vs. NAT666 plus dual stack?
=A0
Thank you very much.
=A0
Best regards
=A0
Qiong SUN
--0050450294e3c2d5a2048264835e-- From mohamed.boucadair@orange-ftgroup.com Mon Mar 22 11:09:59 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875EC28C10D for ; Mon, 22 Mar 2010 11:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[AWL=-1.896, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Flilw+mN-yGe for ; Mon, 22 Mar 2010 11:09:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by core3.amsl.com (Postfix) with ESMTP id B54123A6B57 for ; Mon, 22 Mar 2010 11:09:56 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 0E0C5374415; Mon, 22 Mar 2010 19:10:13 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id E9A5118003B; Mon, 22 Mar 2010 19:10:12 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.10]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 22 Mar 2010 19:10:13 +0100 From: To: =?utf-8?B?5a2Z55C8?= , "softwires@ietf.org" Date: Mon, 22 Mar 2010 19:10:09 +0100 Thread-Topic: [Softwires] [Softwire] Questions on draft-boucadair-dslite-interco-v4v6-03 Thread-Index: AcrJzAjLAeUJGefNRj+6qc7Ki5xtMwAHXtew Message-ID: <17726_1269281413_4BA7B284_17726_129285_1_94C682931C08B048B7A8645303FDC9F30EFD5B41F9@PUEXCB1B.nanterre.francetelecom.fr> References: <327c9c3b1003220728n3db89ea6k788d90339e1334d7@mail.gmail.com> In-Reply-To: <327c9c3b1003220728n3db89ea6k788d90339e1334d7@mail.gmail.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F30EFD5B41F9PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.3.22.174825 Subject: Re: [Softwires] [Softwire] Questions on draft-boucadair-dslite-interco-v4v6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 18:09:59 -0000 --_000_94C682931C08B048B7A8645303FDC9F30EFD5B41F9PUEXCB1Bnante_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBRaW9uZywNCg0KVGhhbmsgeW91IGZvciByZWFkaW5nIHRoZSBJRC4NCg0KQXMgZmFyIGFz IHRoZSBDUEUgaXMgY29uY2VybmVkLCB0aGlzIElEIGFzc3VtZXMgdGhlIHNhbWUgYmVoYXZpb3Vy IGFzIHBlciBEUy1MaXRlIGFyY2hpdGVjdHVyZSBkb2N1bWVudGVkIGluIGRyYWZ0LWlldGYtc29m dHdpcmUtZHVhbC1zdGFjay1saXRlLiBJbiBwYXJ0aWN1bGFyLCBubyBOQVQ0NCBpcyBlbmZvcmNl ZCBpbiB0aGUgQ1BFIGFuZCB0aGVyZWZvcmUgbm8gZG91YmxlIE5BVCB3b3VsZCBiZSBleHBlcmll bmNlZC4NCg0KQ2hlZXJzLA0KTWVkDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpEZSA6IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c29mdHdpcmVzLWJvdW5j ZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgPz8NCkVudm95w6kgOiBsdW5kaSAyMiBtYXJzIDIw MTAgMTU6MjkNCsOAIDogc29mdHdpcmVzQGlldGYub3JnDQpPYmpldCA6IFtTb2Z0d2lyZXNdIFtT b2Z0d2lyZV0gUXVlc3Rpb25zIG9uIGRyYWZ0LWJvdWNhZGFpci1kc2xpdGUtaW50ZXJjby12NHY2 LTAzDQoNCkhpIEJvdWNhZGFpciwNCg0KSSdtIHdvbmRlcmluZyBpZiBJIGhhdmUgbWlzc2VkIHNv bWV0aGluZyBpbiB0aGlzIGRyYWZ0LiBJIGNhbiB1bmRlcnN0YW5kIHRoYXQgaW4gdGhpcyBleHRl bmRlZCBEUy1MaXRlLCBJQ1hGIGlzIGNvcmUgc3RhdGVsZXNzIGFuZCBpdCBpcyBxdWl0ZSBzY2Fs YWJsZSBmb3IgY29yZSByb3V0ZXJzLiBIb3dldmVyLCAgc2luY2UgQ1BFcyBjYW4gc2VuZCBib3Ro IElQdjQgcGFja2V0IGFuZCBJUHY2IHBhY2tldCB0byBBRlRSLCBpdCB3aWxsIHRoZW4gaW5jbHVk ZSBkb3VibGUgTkFUIHByb2JsZW0gaWYgd2UgaGF2ZSB0byBhbGxvY2F0ZSBwcml2YXRlIElQdjQg YWRkcmVzcyB0byBDUEVzLiBUaGVuIHdoYXQgaXMgdGhlIGFkdmFudGFnZSBvZiB0aGlzIGtpbmQg b2YgRFMtTGl0ZSB2cy4gTkFUNjY2IHBsdXMgZHVhbCBzdGFjaz8NCg0KVGhhbmsgeW91IHZlcnkg bXVjaC4NCg0KQmVzdCByZWdhcmRzDQoNClFpb25nIFNVTg0KCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKgpUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyAodGhlICJtZXNz YWdlIikgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVz c2Vlcy4gCkFueSB1bmF1dGhvcmlzZWQgdXNlIG9yIGRpc3NlbWluYXRpb24gaXMgcHJvaGliaXRl ZC4KTWVzc2FnZXMgYXJlIHN1c2NlcHRpYmxlIHRvIGFsdGVyYXRpb24uIApGcmFuY2UgVGVsZWNv bSBHcm91cCBzaGFsbCBub3QgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBpZiBhbHRlcmVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIGFkZHJlc3Nl ZSBvZiB0aGlzIG1lc3NhZ2UsIHBsZWFzZSBjYW5jZWwgaXQgaW1tZWRpYXRlbHkgYW5kIGluZm9y bSB0aGUgc2VuZGVyLgoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgoK --_000_94C682931C08B048B7A8645303FDC9F30EFD5B41F9PUEXCB1Bnante_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzUyNyIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz01ODExMTAwMTgtMjIwMzIwMTA+PEZPTlQgZmFjZT0i Q291cmllciBOZXciIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+RGVhciBRaW9uZyw8L0ZPTlQ+PC9T UEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTgxMTEwMDE4 LTIyMDMyMDEwPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiANCmNvbG9yPSMwMDAwZmYgc2l6ZT0y PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BB TiBjbGFzcz01ODExMTAwMTgtMjIwMzIwMTA+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIA0KY29s b3I9IzAwMDBmZiBzaXplPTI+VGhhbmsgeW91IGZvciByZWFkaW5nIHRoZSBJRC48L0ZPTlQ+PC9T UEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTgxMTEwMDE4 LTIyMDMyMDEwPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiANCmNvbG9yPSMwMDAwZmYgc2l6ZT0y PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BB TiBjbGFzcz01ODExMTAwMTgtMjIwMzIwMTA+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIA0KY29s b3I9IzAwMDBmZiBzaXplPTI+QXMgZmFyIGFzIHRoZSBDUEUgaXMgY29uY2VybmVkLCB0aGlzIElE IGFzc3VtZXMgdGhlIHNhbWUgDQpiZWhhdmlvdXIgYXMgcGVyIERTLUxpdGUgYXJjaGl0ZWN0dXJl IGRvY3VtZW50ZWQgaW4gPFNQQU4gDQpjbGFzcz1oMT5kcmFmdC1pZXRmLXNvZnR3aXJlLWR1YWwt c3RhY2stbGl0ZS4gSW4gcGFydGljdWxhciwgbm8gTkFUNDQgaXMgDQplbmZvcmNlZCBpbiB0aGUg Q1BFIGFuZCB0aGVyZWZvcmUgbm8gZG91YmxlIE5BVCB3b3VsZCBiZSANCmV4cGVyaWVuY2VkLjwv U1BBTj48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4g Y2xhc3M9NTgxMTEwMDE4LTIyMDMyMDEwPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiANCmNvbG9y PSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPWgxPjwvU1BBTj48L0ZPTlQ+PC9TUEFOPiZuYnNw OzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NTgxMTEwMDE4LTIy MDMyMDEwPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxT UEFOIGNsYXNzPWgxPkNoZWVycyw8L1NQQU4+PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTU4MTExMDAxOC0yMjAzMjAxMD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyIgDQpjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz1oMT5NZWQ8 L1NQQU4+PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxCUj48 L0RJVj4NCjxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1mciBkaXI9bHRyIGFs aWduPWxlZnQ+DQo8SFIgdGFiSW5kZXg9LTE+DQo8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+ RGUmbmJzcDs6PC9CPiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZyANClttYWlsdG86c29mdHdp cmVzLWJvdW5jZXNAaWV0Zi5vcmddIDxCPkRlIGxhIHBhcnQgZGU8L0I+IA0KPz88QlI+PEI+RW52 b3nDqSZuYnNwOzo8L0I+IGx1bmRpIDIyIG1hcnMgMjAxMCAxNToyOTxCUj48Qj7DgCZuYnNwOzo8 L0I+IA0Kc29mdHdpcmVzQGlldGYub3JnPEJSPjxCPk9iamV0Jm5ic3A7OjwvQj4gW1NvZnR3aXJl c10gW1NvZnR3aXJlXSBRdWVzdGlvbnMgb24gDQpkcmFmdC1ib3VjYWRhaXItZHNsaXRlLWludGVy Y28tdjR2Ni0wMzxCUj48L0ZPTlQ+PEJSPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+SGkgQm91 Y2FkYWlyLCA8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkknbSB3b25kZXJpbmcgaWYg SSBoYXZlIG1pc3NlZCBzb21ldGhpbmcgaW4gdGhpcyBkcmFmdC4gSSBjYW4gdW5kZXJzdGFuZCAN CnRoYXQgaW4gdGhpcyBleHRlbmRlZCBEUy1MaXRlLCBJQ1hGJm5ic3A7aXMgY29yZSBzdGF0ZWxl c3MgYW5kIGl0IGlzIHF1aXRlIA0Kc2NhbGFibGUgZm9yIGNvcmUgcm91dGVycy4gSG93ZXZlciwm bmJzcDsgc2luY2UgQ1BFcyBjYW4gc2VuZCBib3RoIElQdjQgcGFja2V0IA0KYW5kIElQdjYgcGFj a2V0IHRvIEFGVFIsIGl0IHdpbGwgdGhlbiZuYnNwO2luY2x1ZGUgZG91YmxlIE5BVCBwcm9ibGVt IGlmIHdlIGhhdmUgDQp0byBhbGxvY2F0ZSBwcml2YXRlIElQdjQgYWRkcmVzcyB0byBDUEVzLiBU aGVuIHdoYXQgaXMgdGhlIGFkdmFudGFnZSBvZiB0aGlzIA0Ka2luZCBvZiBEUy1MaXRlIHZzLiBO QVQ2NjYgcGx1cyBkdWFsIHN0YWNrPzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhh bmsgeW91IHZlcnkgbXVjaC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkJlc3QgcmVn YXJkczwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+UWlvbmcgU1VOPC9ESVY+PFBSRT4q KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0 YWNobWVudHMgKHRoZSAibWVzc2FnZSIpIGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNv bGVseSBmb3IgdGhlIGFkZHJlc3NlZXMuIApBbnkgdW5hdXRob3Jpc2VkIHVzZSBvciBkaXNzZW1p bmF0aW9uIGlzIHByb2hpYml0ZWQuCk1lc3NhZ2VzIGFyZSBzdXNjZXB0aWJsZSB0byBhbHRlcmF0 aW9uLiAKRnJhbmNlIFRlbGVjb20gR3JvdXAgc2hhbGwgbm90IGJlIGxpYWJsZSBmb3IgdGhlIG1l c3NhZ2UgaWYgYWx0ZXJlZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuCklmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCBhZGRyZXNzZWUgb2YgdGhpcyBtZXNzYWdlLCBwbGVhc2UgY2FuY2VsIGl0IGlt bWVkaWF0ZWx5IGFuZCBpbmZvcm0gdGhlIHNlbmRlci4KKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioKPC9QUkU+PC9CT0RZPjwvSFRNTD4NCg== --_000_94C682931C08B048B7A8645303FDC9F30EFD5B41F9PUEXCB1Bnante_-- From yiu_lee@cable.comcast.com Mon Mar 22 13:03:50 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC3D3A6B9E for ; Mon, 22 Mar 2010 13:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFXaLnCkELG1 for ; Mon, 22 Mar 2010 13:03:49 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 2AF863A6B62 for ; Mon, 22 Mar 2010 13:02:53 -0700 (PDT) Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74911996; Mon, 22 Mar 2010 16:03:06 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Mar 2010 16:03:05 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Received: from 130.129.26.213 ([130.129.26.213]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Mon, 22 Mar 2010 20:03:03 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3352118580_581907" Date: Mon, 22 Mar 2010 16:03:00 -0400 Message-ID: In-Reply-To: <327c9c3b1003220728n3db89ea6k788d90339e1334d7@mail.gmail.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Softwires] [Softwire] Questions on draft-boucadair-dslite-interco-v4v6-03 Thread-Index: AcrJ+qwbDh0ovUliDEKydyliJrSJVw== From: "Lee, Yiu" To: =?gb2312?B?y+/H7Q==?= , X-OriginalArrivalTime: 22 Mar 2010 20:03:05.0043 (UTC) FILETIME=[AF1D7230:01CAC9FA] Subject: Re: [Softwires] [Softwire] Questions on draft-boucadair-dslite-interco-v4v6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 20:03:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3352118580_581907 Content-type: multipart/alternative; boundary="B_3352118580_540362" --B_3352118580_540362 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable As Med replied in a different email, the CPE is the B4 in the ds-lite draft which performs v4-over-v6 tunnel for v4 packets. No NAT-44 will happen in B4. On 3/22/10 10:28 AM, "=CB=EF=C7=ED" wrote: > Hi Boucadair,=20 > =20 > I'm wondering if I have missed something in this draft. I can understand = that > in this extended DS-Lite, ICXF is core stateless and it is quite scalable= for > core routers. However, since CPEs can send both IPv4 packet and IPv6 pac= ket > to AFTR, it will then include double NAT problem if we have to allocate > private IPv4 address to CPEs. Then what is the advantage of this kind of > DS-Lite vs. NAT666 plus dual stack? > =20 > Thank you very much. > =20 > Best regards > =20 > Qiong SUN >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --B_3352118580_540362 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable Re: [Softwires] [Softwire] Questions on draft-boucadair-dslite-inter= co-v4v6-03 As Med replied in a different email, the CPE is the B4 in the ds-lite draf= t which performs v4-over-v6 tunnel for v4 packets. No NAT-44 will happen in = B4.


On 3/22/10 10:28 AM, "=CB=EF=C7=ED" <bingxuere.mail@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi Boucadair,

I'm wondering if I have missed something in this draft. I can understand th= at in this extended DS-Lite, ICXF is core stateless and it is quite scalable= for core routers. However, since CPEs can send both IPv4 packet and IPv6 p= acket to AFTR, it will then include double NAT problem if we have to allocat= e private IPv4 address to CPEs. Then what is the advantage of this kind of D= S-Lite vs. NAT666 plus dual stack?

Thank you very much.

Best regards

Qiong SUN

___________= ____________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.= org/mailman/listinfo/softwires
--B_3352118580_540362-- --B_3352118580_581907 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIN2AYJKoZIhvcNAQcCoIINyTCCDcUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC C6QwggMPMIICeKADAgECAhBQgSObXgIsEiVC/GebCmGTMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wOTA4MDgwODQw MDJaFw0xMDA4MDgwODQwMDJaMEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx KDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCscC6PT5lvsXUq4lOfCGh5DV7ZnHkaKTZrdclNBGwIUu1H njC0937hsVMKSuyKXMiuGc2VS1sjvEzqtqcSiGBkX2ZhGszLppMjiNwb3McBc4slgNxK1OfX Q+g/C/Fi/pZbg3KU/V50QGQQsM0yO1HOK7FGyvOH023fNvQ7E0syH6NAbkmf4mQoHLFUMkjD mfdbtrnYeGvNjrX6hLMmUuo0Y6MAyJQdBDH8p+6V0/hjvYOA2yAW+ptxxEbPYGrm1/f2TYp2 o43bA9ri/P8Rtli6kaKQvC5HhReyNJLWWG2z8JjbqcQd1sP443WI1voiBbqOLNpu3KWnBRzC 3+n6eYhfAgMBAAGjWTBXMA4GA1UdDwEB/wQEAwID+DARBglghkgBhvhCAQEEBAMCBaAwJAYD VR0RBB0wG4EZeWl1X2xlZUBjYWJsZS5jb21jYXN0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBQUAA4GBAF+NiG7zCDaZsRKq54bnGbGi1nFyzFa4sL72O+J2vRZoyVU8tFpl9Xz/ BnTMU+olVJ+Q4wmnwuSJZ6rTblLTlKRVnkd3PBcnWYYVYSvwhKuTTmTX99RZHvGSTGJomy7M PuOLo/XqZgHgA/oZ38QQp76e9EPeM2nfFJHc9bTK0RlOMIIDPzCCAqigAwIBAgIBDTANBgkq hkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAG A1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMf Q2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3 dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcC Y1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8C AQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNv bmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/ r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCU YsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzCCBUowggQyoAMCAQICEEsVRXwTaRSoi7d3sapu92EwDQYJKoZIhvcNAQEFBQAwgd0x CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMjAeFw0wOTExMDUwMDAwMDBaFw0xMDExMDUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRAwDgYDVQQDFAdZaXUg TGVlMSgwJgYJKoZIhvcNAQkBFhl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArfUYyB1WddeTV1whaQNaHKstvQcFnloN37ZayFeM H8D3vKzrImHg6WIFOm7+kA5GsW+cO5au9HNL5fKSf1jYb4/EMuaEITqBpBK41nBok7jP3FiD KPt4TtsJsnqDRLaS2SS3YBSTZOzgdLU4mTjveMYmyFdeRbNsrO2v8bWkcQLE/zf5wSdGS6rF nDF8MXw70BkHmZte1eY+EYoi694+0ukeg9eKw5JFlmBrYAoE1oDxMHXXIV2ju/zC9kpK5DZC AVtofp+hL5A+pgnLxOsfPrRpcrkQeM1ryhujXCij/jdHMMdNS3+z97QSw8cNfG3PBF8KnBp6 67jVylTR/d3LCwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhF AQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1Ud DwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/oD2g O4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAxhdnbwrUOuIrJBrZ+T2mMOJJOT8gJp9gvzwJP HXevZ6DtqgrD0oNhI5bpXbgvIYjFHS9zgGi264F7qLxPYYwFF0qt0IQxUp3S72rrNtpTrBTS FoPjfuKzfK/6zv5NEExfChalzDKxKUrdymfCT3/eRPkAGRMBaADDpb1RRrmpLHDU4RZkiX48 LwLlTDFz+Yot/DO7YZCNpV38IKHN6mNfYzOUKL6zoFnY8Dd1q4dTO8d4lRU2bZUQ/i36WsXH pr9YsPKPd3dOsbO7EVIFUCZzUYPly1jZqG5Ns6KW5e26l/E2mMi5bkgq8ppqbjO0kpfZDcLO IpVMJvkYPT/6Jqx5MYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFCBI5teAiwSJUL8Z5sKYZMwCQYFKw4DAhoFAKBdMCMGCSqG SIb3DQEJBDEWBBQPJ/laNVq8a6NA3kWN2+gKttZRyDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAzMjIyMDAzMDBaMA0GCSqGSIb3DQEBAQUABIIBAHtI gu3IZEyDKqJh5Qp3gyFVhviJNoJVFRJDCmPHpmGFsCQ1Gdkg1NnySsg4A3+14D+zeVf14K6S BCCu9vTobmR2rMlTpZiI+/qQt4nvf1qLAkJlPL8aGUEO0dRY8KnAn8a4JkJ79lyWtm0Kivhk Mn1C4Sj0VvwtQQzjkyCRQFavAqeI9lGzOLpvMcXTIV1j8QkNZTcGsrlJhcrw7Ix432dZfDs6 Pva0S6XvNtyLVjuT/jfmmdmgf5LmIhK9Wie9zEA0rp1ALG/j0pY6LZY8+H4bIaiiXWLTVclP RWP+JGJfebswQdarM+tZsm8gIjx2PGBWIeXyCN51VXScrVPxp0A= --B_3352118580_581907-- From bingxuere.mail@gmail.com Mon Mar 22 18:14:25 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94403A68AB for ; Mon, 22 Mar 2010 18:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.257 X-Spam-Level: *** X-Spam-Status: No, score=3.257 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTiW6I061OlL for ; Mon, 22 Mar 2010 18:14:24 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 85FC53A689F for ; Mon, 22 Mar 2010 18:14:24 -0700 (PDT) Received: by gwj23 with SMTP id 23so373830gwj.31 for ; Mon, 22 Mar 2010 18:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=qgoW3vCds88u0HrJJNs48Alwsz2Rg1LpkesytopX7L4=; b=oQQJSUxyTFQdMcrCjiUsrTe7bIABZPMdQJzN/Nn1ZRUNIwvVE7rra/jBj3Cl0hK8Q9 R/MdlE6at16FQpBHskgX1e3WGybJdRrrpzoT68vdzfGlAg5/KFxPlLhXyLTQjMuObmxq OGRObYCjSvOuvFtWeDNwfCjMHwOlgZtB5KgGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=u3WYtAKatC0t8WD0lBhX6LnI4QS8lOvcGmVAYq4Q85uGqQ96TpFm3PsYSTuGzuz7D4 4BryY8cZ3xjNMEG9h1wk7yPNO8vhn64uIp+ILjDz0l0jNCfsfkD1TQlsxqlEfD61bm7b fCOZyjqfyow3Ow7bhKwsMBusp6jzGFn01/g7w= MIME-Version: 1.0 Received: by 10.90.204.3 with SMTP id b3mr5121521agg.80.1269306879623; Mon, 22 Mar 2010 18:14:39 -0700 (PDT) In-Reply-To: References: <327c9c3b1003220728n3db89ea6k788d90339e1334d7@mail.gmail.com> Date: Tue, 23 Mar 2010 09:14:39 +0800 Message-ID: <327c9c3b1003221814q1a470f40w8cab466675c81ddb@mail.gmail.com> From: =?GB2312?B?y+/H7Q==?= To: "Lee, Yiu" Content-Type: multipart/alternative; boundary=00163630eef9abc53d04826d8918 Cc: softwires@ietf.org Subject: Re: [Softwires] [Softwire] Questions on draft-boucadair-dslite-interco-v4v6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 01:14:25 -0000 --00163630eef9abc53d04826d8918 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Thank you. I can see that this kind of DS-Lite is good for core network. Bu= t in my consideration, the major problem which might impede the deployment of DS-Lite is that it has to take control of end-user's CPE. However, in this case, we not only have to deploy two endpoints, but also the addtional endpoint of AFTR. And the function of AFTR is a little too complicated, including double tunnel encapsulation, CGN, CGN-related ALG, etc. So why does CPE have to locate in IPv6-only environment? Can it possible that CPE can still send and receive IPv4 packet, while AFTR and ICXF locate in IPv6-only environment? Thank you. Qiong SUN =D4=DA 2010=C4=EA3=D4=C223=C8=D5 =C9=CF=CE=E74:03=A3=ACLee, Yiu =D0=B4=B5=C0=A3=BA > As Med replied in a different email, the CPE is the B4 in the ds-lite dra= ft > which performs v4-over-v6 tunnel for v4 packets. No NAT-44 will happen in > B4. > > > > On 3/22/10 10:28 AM, "=CB=EF=C7=ED" wrote: > > Hi Boucadair, > > I'm wondering if I have missed something in this draft. I can understand > that in this extended DS-Lite, ICXF is core stateless and it is quite > scalable for core routers. However, since CPEs can send both IPv4 packet = and > IPv6 packet to AFTR, it will then include double NAT problem if we have t= o > allocate private IPv4 address to CPEs. Then what is the advantage of this > kind of DS-Lite vs. NAT666 plus dual stack? > > Thank you very much. > > Best regards > > Qiong SUN > > ------------------------------ > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --00163630eef9abc53d04826d8918 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Thank you. I can see that this kind of DS-Lite is good for core network. Bu= t in my consideration, the major problem which might impede the deployment = of DS-Lite is that it has to take control of end-user's CPE. However, i= n this case, we not only have to deploy two endpoints, but also the addtion= al endpoint of AFTR. And the function of AFTR is a little too complicated, = including double tunnel encapsulation, CGN, CGN-related ALG, etc. So why do= es CPE have to locate in IPv6-only environment? Can it possible that CPE ca= n still send and receive IPv4 packet, while AFTR and ICXF locate in IPv6-on= ly environment?
 
Thank you.
 
Qiong SUN

=D4=DA 2010=C4=EA3=D4=C223=C8=D5 =C9=CF=CE=E74:0= 3=A3=ACLee, Yiu <Yiu_Lee@cable.comcast.com>=D0=B4=B5=C0=A3=BA
As Med replied in a different email, the CPE is the B4 in the d= s-lite draft which performs v4-over-v6 tunnel for v4 packets. No NAT-44 wil= l happen in B4.=20



On 3/22/10 10:28 AM, "=CB=EF=C7=ED"= <bingxuer= e.mail@gmail.com> wrote:
Hi Boucadair,

I'm wondering if I have missed = something in this draft. I can understand that in this extended DS-Lite, IC= XF is core stateless and it is quite scalable for core routers. However, si= nce CPEs can send both IPv4 packet and IPv6 packet to AFTR, it will then in= clude double NAT problem if we have to allocate private IPv4 address to CPE= s. Then what is the advantage of this kind of DS-Lite vs. NAT666 plus dual = stack?

Thank you very much.

Best regards

Qiong SUN

=
_________________________________________= ______
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--00163630eef9abc53d04826d8918-- From root@core3.amsl.com Tue Mar 23 10:00:01 2010 Return-Path: X-Original-To: softwires@ietf.org Delivered-To: softwires@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F1A983A6BFE; Tue, 23 Mar 2010 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100323170001.F1A983A6BFE@core3.amsl.com> Date: Tue, 23 Mar 2010 10:00:01 -0700 (PDT) Cc: softwires@ietf.org Subject: [Softwires] I-D Action:draft-ietf-softwire-ipv6-6rd-08.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : IPv6 via IPv4 Service Provider Networks "6rd" Author(s) : M. Townsley, O. Troan Filename : draft-ietf-softwire-ipv6-6rd-08.txt Pages : 19 Date : 2010-03-23 This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a Service Provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service which is equivalent to native IPv6 at the sites which are served by the mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-softwire-ipv6-6rd-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-23095952.I-D@ietf.org> --NextPart-- From pselkirk@isc.org Wed Mar 24 11:51:33 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB5DB3A6BED for ; Wed, 24 Mar 2010 11:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.13 X-Spam-Level: * X-Spam-Status: No, score=1.13 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm5njygHwgTk for ; Wed, 24 Mar 2010 11:51:32 -0700 (PDT) Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id 04DCD3A693E for ; Wed, 24 Mar 2010 11:51:32 -0700 (PDT) Received: by farside.isc.org (Postfix, from userid 10300) id F262CE60BC; Wed, 24 Mar 2010 18:51:48 +0000 (UTC) From: Paul Selkirk To: softwires@ietf.org In-reply-to: (message from Jason Livingood on Sun, 21 Mar 2010 21:56:35 -0400) References: Message-Id: <20100324185148.F262CE60BC@farside.isc.org> Date: Wed, 24 Mar 2010 18:51:48 +0000 (UTC) Subject: Re: [Softwires] Feedback on draft-wing-softwire-port-control-protocol-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 18:51:33 -0000 This is a reasonable protocol as far as it goes. However, I find it odd that the draft attempts to articially reduce the scope to a translating proxy for DS-lite and NAT64 only. There is nothing inherent in the base protocol that supports these restrictions. It is, to all appearances, "a general purpose NAT or Firewall port reservation protocol." In fact, given that the packet formats and most of the descriptive text are lifted wholesale from NAT-PMP, maybe we should call it NAT-PMPv2, with added support for proxying and address family translation. Specifically, the draft should be restructured to spell out the base client-server protocol, then address all the special cases: directly connected NAT44, NAT64, PCP/PCP proxy, UPnP/PCP proxy, NAT-PMP/PCP proxy, DS-lite, NAT444, etc. (Of course, if we accept that it's a general purpose NAT traversal protocol, then it would appear to be squarely within the charter for behave, and only marginally for softwire.) I support Jason's structural suggestions, and have the following comments to offer. 7.1.3 (Returning a Mapping) retains the following language from NAT-PMP: The source address of the packet MUST be used for the internal address in the mapping. This protocol is not intended to facilitate one device behind a NAT creating mappings for other devices. If there are legacy devices that require inbound mappings, permanent mappings can be created manually by the administrator, just as they are today. Not only is this nonsense in a proxying scenario, but it is directly at odds with requirement 13 (another application on the same host *or on a different host* can open the port.) Whatever the intent of this passage, it needs to be rewritten or removed. 7.1.3 also carries over this text, which I would like to see removed, but which I feel less strongly about: While a NAT gateway MUST NOT automatically create mappings for TCP when the client requests UDP, and vice versa, the NAT gateway MUST reserve the companion port so the same client can choose to map it in the future. For example, if a client requests to map TCP port 80, as long as the client maintains the lease for that TCP port mapping, another client with a different IP address MUST NOT be able to successfully acquire the mapping for UDP port 80. 7.1.5 (List Port Mappings) is a place-holder. In addition to the request and reply message formats, I'd like to see some justification for why this operation is needed (especially in relation to requirement 1: lightweight protocol). 7.2 (Interactions with Outgoing Sessions) says: There are a few important considerations when port forwarding is combined with a NAT that uses address pools. First and foremost, if there is a port forwarding mapping between certain external and internal addresses, all sessions originated by the host associated with the internal address should use the same external address present in the port forwarding mapping. (Pedantically, that's not "a few" considerations, that's one.) Address affinity is good for general operational stability, but the protocol supports non-affinitive mappings, by reporting the external address in all mapping responses. 8.3 (NAT or PCP Server reboot) says: With PCP, the NAT operated by the service provider and the PCP server are both expected to retain PCP-initiated port mapping information in permanent storage, so a reboot will cause no loss of port mapping information. This is a large and deliberate change from UPnP/NAT-PMP, and implies something analogous to a DHCP lease database. (However, my HGW DHCP server doesn't maintain its lease database across reboots either.) Section 9 (PCP and Dual Stack-Lite) specifically considers the cases of both tunneled requests and directly-proxied requests. Nevertheless, the IPv6 address used by the PCP Proxy MUST be the same as the one used to mount the IPv6 interface of the B4 element. I think I understand what this is trying to say (the IPv6 source address of the proxied request should be that of the proxy host), but I'm not sure I understand why it needs to be said. The DS-lite scenario needs to be spelled out in much more detail, especially since it's the ostensible reason that PCP is in softwire. DS-lite requires a proxy on the B4. Realistically, it should be a translating proxy (client-initiated UPnP and NAT-PMP to PCP). On the AFTR, the NAT mapping table is extended to include the IPv6 source address of B4, as well as the client's source IPv4 address, protocol, and port. This requires that the PCP proxy must be on the same host as the B4; this requirement should be made explicit. For NAT444, the interior NAT translates (NATs) the request packet, so it appears to be coming directly from a client. The interior NAT maintains its mapping, and the exterior NAT maintains its mapping. The proxy (interior NAT) needs to report the mapped exterior port number without change, but the interior NAT doesn't have to use the same port mapping as the exterior NAT. Regardless of the proxy type (DS-lite or NAT444), the reply message does not include the internal address of the original requestor. So the proxy MUST maintain state, to know where to direct the reply message (probably in the form of a pair of open sockets (to the client, and to the upstream server)). If we add the internal address to the reply message, then the proxy can be stateless. Of course, the retransmit timer defined in 7.1.1 requires state to be maintained, but it could be argued that it's the responsibility of the originating client to retransmit, and the proxy should statelessly relay the retransmision. This means that the retransmission behavior is that of the originating protocol (UPnP or NAT-PMP, if the proxy is translating), rather than that of PCP. In addition to adding the internal address to the reply message, I would also change 7.1.1 to say that retransmission only applies to native PCP (client-initiated PCP), not to proxy-initiated PCP. Hmm, I think I may have argued myself around to the position that PCP should be a proxy-specific protocol. At any rate, there should be more discussion of client-initiated PCP vs proxy-initiated PCP. paul From Washam.Fan@huaweisymantec.com Wed Mar 24 23:17:24 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E311E3A6C57 for ; Wed, 24 Mar 2010 23:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyq2YssIFw3w for ; Wed, 24 Mar 2010 23:17:24 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 992243A6C5C for ; Wed, 24 Mar 2010 23:17:06 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KZT002DVQT1HY80@hstga02-in.huaweisymantec.com> for softwires@ietf.org; Thu, 25 Mar 2010 14:17:26 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KZT00N2VQT11B20@hstml01-in.huaweisymantec.com> for softwires@ietf.org; Thu, 25 Mar 2010 14:17:25 +0800 (CST) Received: from [130.129.25.92] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 25 Mar 2010 14:17:25 +0800 From: WashamFan To: softwires@ietf.org Message-id: Date: Thu, 25 Mar 2010 14:17:25 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal Subject: [Softwires] pptx format X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 06:17:25 -0000 Hi, Is it any possible to upload ppt format presentation materials instead, My office tools can't open pptx files. Thanks, washam From brian.e.carpenter@gmail.com Thu Mar 25 07:08:48 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 794D53A68A7 for ; Thu, 25 Mar 2010 07:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTwJMxz-homA for ; Thu, 25 Mar 2010 07:08:47 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 8050F3A6837 for ; Thu, 25 Mar 2010 07:08:47 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so1400789fgb.13 for ; Thu, 25 Mar 2010 07:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=b8mddvOGwO096PgqAWg2epBfqyU3aiLHyOeQL0EKNno=; b=dRDGApo1QYxc7mIUv2loBJ6O9HTtwf0lzawpDLJErMXhOpoIIwQFGQaNGJXRcuIJSL avgkoK41BXVUWYwCqkySvNVaoMEjQIqS9Lq04oeAJWf/+QVft8Jh+TLxD1yLHQSy/3Id WkTxvMWUMVL+PnghutbkPXr2xLABWligUuFvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=icKdUssdOtdPHJ9B3o777/j28A+YuOdeuABsj5c3zDNMEHwoQPAdE8/cyPigeP9Cpe nSi+vs6OrqLbMMsziYFWqABvYAZ8txpt0ktUOk0gC+/Qb6hVkBmmugmZstIupyqgd5ah Npf2xNoYblmwyIOprDYBpj1E73AQmhdZMmfPs= Received: by 10.102.170.9 with SMTP id s9mr3847697mue.77.1269526145196; Thu, 25 Mar 2010 07:09:05 -0700 (PDT) Received: from [130.129.27.105] (dhcp-wireless-open-abg-27-105.meeting.ietf.org [130.129.27.105]) by mx.google.com with ESMTPS id j10sm7266859mue.48.2010.03.25.07.09.01 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Mar 2010 07:09:03 -0700 (PDT) Message-ID: <4BAB6E74.8070600@gmail.com> Date: Fri, 26 Mar 2010 03:08:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: WashamFan References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org Subject: Re: [Softwires] pptx format X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 14:08:48 -0000 Seconded. PDF is best, of course Brian On 2010-03-25 19:17, WashamFan wrote: > Hi, > > Is it any possible to upload ppt format presentation > materials instead, My office tools can't open pptx files. > > Thanks, > washam > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From Francis.Dupont@fdupont.fr Thu Mar 25 09:23:39 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6863D3A6C36 for ; Thu, 25 Mar 2010 09:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oi7Kqq+Lq0Th for ; Thu, 25 Mar 2010 09:23:38 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 3A80B3A681E for ; Thu, 25 Mar 2010 09:23:34 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id o2PGNtrl063949; Thu, 25 Mar 2010 16:23:55 GMT (envelope-from dupont@givry.fdupont.fr) Message-Id: <201003251623.o2PGNtrl063949@givry.fdupont.fr> From: Francis Dupont To: WashamFan In-reply-to: Your message of Thu, 25 Mar 2010 14:17:25 +0800. Date: Thu, 25 Mar 2010 17:23:55 +0100 Sender: Francis.Dupont@fdupont.fr Cc: softwires@ietf.org Subject: Re: [Softwires] pptx format X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 16:23:39 -0000 In your previous mail you wrote: Is it any possible to upload ppt format presentation materials instead, My office tools can't open pptx files. => IMHO PDF should be mandatory. Of course, a mix of pptx, ppt and pdf is a nightmare. Francis.Dupont@fdupont.fr PS: BTW if I can display .pptx they look terrible. From alain_durand@cable.comcast.com Thu Mar 25 09:45:31 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E9CF3A6C13 for ; Thu, 25 Mar 2010 09:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.734 X-Spam-Level: ** X-Spam-Status: No, score=2.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkPggCzsJWkz for ; Thu, 25 Mar 2010 09:45:29 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id D67E03A692B for ; Thu, 25 Mar 2010 09:45:05 -0700 (PDT) Received: from ([10.52.116.31]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.88892314; Thu, 25 Mar 2010 12:45:14 -0400 Received: from PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) by PAOAKEXCSMTP02.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 12:45:14 -0400 Received: from 130.129.28.14 ([130.129.28.14]) by PACORPEXCMB04.cable.comcast.com ([24.40.15.117]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 25 Mar 2010 16:45:13 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 25 Mar 2010 12:45:12 -0400 From: "Durand, Alain" To: Francis Dupont , WashamFan Message-ID: Thread-Topic: [Softwires] pptx format Thread-Index: AcrMOol4nwYMGUIz/UiuZOL9VSOrjA== In-Reply-To: <201003251623.o2PGNtrl063949@givry.fdupont.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Mar 2010 16:45:14.0026 (UTC) FILETIME=[8AAD40A0:01CACC3A] Cc: softwires@ietf.org Subject: Re: [Softwires] pptx format X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 16:45:31 -0000 I've replaced all the ppt/pptx by pdf files - Alain. On 3/25/10 12:23 PM, "Francis Dupont" wrote: > > In your previous mail you wrote: > > Is it any possible to upload ppt format presentation > materials instead, My office tools can't open pptx files. > > => IMHO PDF should be mandatory. Of course, a mix of pptx, ppt > and pdf is a nightmare. > > Francis.Dupont@fdupont.fr > > PS: BTW if I can display .pptx they look terrible. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From remi.despres@free.fr Thu Mar 25 16:08:43 2010 Return-Path: X-Original-To: softwires@core3.amsl.com Delivered-To: softwires@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38AE3A683C for ; Thu, 25 Mar 2010 16:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.556 X-Spam-Level: ** X-Spam-Status: No, score=2.556 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HeQL-v8y06l for ; Thu, 25 Mar 2010 16:08:43 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by core3.amsl.com (Postfix) with ESMTP id C62743A6C2B for ; Thu, 25 Mar 2010 16:08:40 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id C8B047000094; Fri, 26 Mar 2010 00:09:02 +0100 (CET) Received: from dhcp-wireless-open-abg-24-236.meeting.ietf.org (dhcp-wireless-open-abg-24-236.meeting.ietf.org [130.129.24.236]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 22E9D700008B; Fri, 26 Mar 2010 00:09:01 +0100 (CET) X-SFR-UUID: 20100325230902143.22E9D700008B@msfrf2102.sfr.fr Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20100324185148.F262CE60BC@farside.isc.org> Date: Thu, 25 Mar 2010 16:09:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <71E9FFF3-3918-4277-81FE-5B9CA9E893B5@free.fr> References: <20100324185148.F262CE60BC@farside.isc.org> To: softwires@ietf.org X-Mailer: Apple Mail (2.1077) Subject: Re: [Softwires] Feedback on draft-wing-softwire-port-control-protocol-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 23:08:43 -0000 Le 24 mars 2010 =E0 11:51, Paul Selkirk a =E9crit : > This is a reasonable protocol as far as it goes. However, I find it > odd that the draft attempts to articially reduce the scope to a > translating proxy for DS-lite and NAT64 only. >=20 > There is nothing inherent in the base protocol that supports these > restrictions. It is, to all appearances, "a general purpose NAT or > Firewall port reservation protocol." =20 +1 RD=