From peterd@iea-software.com Wed Dec 21 02:49:32 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033A221F84AA for ; Wed, 21 Dec 2011 02:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1-4G7SePsiO for ; Wed, 21 Dec 2011 02:49:31 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 5392F21F84A8 for ; Wed, 21 Dec 2011 02:49:31 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 21 Dec 2011 02:49:30 -0800 Date: Wed, 21 Dec 2011 02:49:27 -0800 (Pacific Standard Time) From: Peter Deacon To: Stefan Winter In-Reply-To: <4EF1A65F.9080609@restena.lu> Message-ID: References: <4EC1BD65.4040205@restena.lu> <4EEB1014.1030307@restena.lu> <5D36713D8A4E7348A7E10DF7437A4B9218583E44@SZXEML506-MBX.china.huawei.com> <4EF047A3.5090906@restena.lu> <4EF08F63.1010600@deployingradius.com> <5D36713D8A4E7348A7E10DF7437A4B9218584374@SZXEML506-MBX.china.huawei.com> <4EF1A65F.9080609@restena.lu> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 03 Jan 2012 08:09:36 -0800 Cc: softwires@ietf.org, Alan DeKok , GuoDayong Subject: Re: [Softwires] 6rd RADIUS attribute - grouped attributes X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 10:49:32 -0000 On Wed, 21 Dec 2011, Stefan Winter wrote: > If both drafts have their own complex encoding, it's double work: > everyone needs to write their own parser for their own attribute. As > time goes by, there will be more drafts needing to encode some complex > information. Consolidation of such complex types into a common format is > a good thing IMHO. >>> IPv6-6rd-Configuration Attribute >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Length | Extended-Type |M| Flag | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Suboptions | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Type 245, extended-type TBD. >> Using Extended-Type means you would have to wait for the extensions >> draft to be an RFC in order to be assigned an Extended-Type. > That's right. It is the only drawback. If you choose to go the > custom-encoding way, you avoid a bit of waiting time at the expense of > extra, non-reusable code in every 6rd implementation. >> Compromised solution I originally suggested (Currently >> draft-ietf-softwire-6rd-radius-attrib-04) sought to avoid dependencies >> on other drafts while at the same time providing maximum compatibility >> with existing and future systems. > It requires an implementer to write one parser specifically for the > 6rd-attribute, with no code re-use for other attributes that will be > defined in the future. The code needs to be maintained separately from > the a generic extended-attributes parser. That sounds rather > short-sighted to me and goes contrary to the claim of "compatibility > with future systems". > I'm not sure what "compatibility with existing systems" should mean. > Existing systems can't make anything out of the IPv6-6rd-Configuration > attribute, because they can't parse the content. All they can do is > ignore the attribute. They can do that with an extended-type attribute > just as well. I don't think this is correct. The extensions document describes a *data type* 'TLV'. My suggestion simply leverages this type in the same way IPv4 Address and IPv6 prefix type from existing RFCs are already being leveraged. If you implement extensions RFC in the future your implementation supports the TLV data type giving you the ability to encode and decode this attribute with configuration dictionaries. The wire format of IPv6-6rd-Configuration was intentionally made to be the same as a TLV. The compromise allowed someone to *choose* to implement the TLV type generically OR a much less flexible parser capable of handling just this attribute without having to also support extensions. Some vendors already support the TLV concept as it is necessary for wimax. It is possible to configure the -04 draft today with just configuration in some systems already supporting TLV. My understanding they were not willing to wait for extensions to move ahead with the 6rd draft. In that light my view was something that looked like a "TLV" was better than the alternative fixed format. If this constraint is invalid and they are willing to wait allowing 6rd draft to be dependent on extensions I agree it would certainly be the best approach for all concerned. regards, Peter From peterd@iea-software.com Wed Dec 21 21:50:18 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3D221F8B95 for ; Wed, 21 Dec 2011 21:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHOTIMbURXZd for ; Wed, 21 Dec 2011 21:50:17 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 9A71021F8B94 for ; Wed, 21 Dec 2011 21:50:17 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 21 Dec 2011 08:14:22 -0800 Date: Wed, 21 Dec 2011 08:14:17 -0800 (Pacific Standard Time) From: Peter Deacon To: Stefan Winter In-Reply-To: <4EF1E94D.2080006@restena.lu> Message-ID: References: <4EC1BD65.4040205@restena.lu> <4EEB1014.1030307@restena.lu> <5D36713D8A4E7348A7E10DF7437A4B9218583E44@SZXEML506-MBX.china.huawei.com> <4EF047A3.5090906@restena.lu> <4EF08F63.1010600@deployingradius.com> <5D36713D8A4E7348A7E10DF7437A4B9218584374@SZXEML506-MBX.china.huawei.com> <4EF1A65F.9080609@restena.lu> <4EF1E94D.2080006@restena.lu> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 03 Jan 2012 08:09:36 -0800 Cc: softwires@ietf.org, Alan DeKok , GuoDayong Subject: Re: [Softwires] 6rd RADIUS attribute - grouped attributes X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 05:50:18 -0000 On Wed, 21 Dec 2011, Stefan Winter wrote: >> I don't think this is correct. The extensions document describes a >> *data type* 'TLV'. My suggestion simply leverages this type in the same >> way IPv4 Address and IPv6 prefix type from existing RFCs are already >> being leveraged. >> >> If you implement extensions RFC in the future your implementation >> supports the TLV data type giving you the ability to encode and decode >> this attribute with configuration dictionaries. The wire format of >> IPv6-6rd-Configuration was intentionally made to be the same as a TLV. > Ah! I'm just looking at the -04 with this extra context. It's certainly > close. I think there's only one thing which is not inline: 6rdprefixLen > and 6rdPrefix immediately follow each other. In a version > compatible/analogous to the radius-extensions draft, the former would be > of type integer, the latter of type IPv6Address, and each would have its > own (Subtype,SubLen) tuple. > Any particular reason why the 6rdPrefixLen and 6rdPrefix are glued into > one blob in -04? If you ignore the 6rd references it is describing prefix data type defined a decade back in RFC3162 2.3 (Framed-IPv6-Prefix). Logically it counts as one field. regards, Peter From peterd@iea-software.com Thu Dec 22 04:07:51 2011 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03921F8B59 for ; Thu, 22 Dec 2011 04:07:51 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEzomPgLUm+V for ; Thu, 22 Dec 2011 04:07:50 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8B321F8B4E for ; Thu, 22 Dec 2011 04:07:50 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 22 Dec 2011 04:07:49 -0800 Date: Thu, 22 Dec 2011 04:07:45 -0800 (Pacific Standard Time) From: Peter Deacon To: Stefan Winter In-Reply-To: <4EF2DE99.7050207@restena.lu> Message-ID: References: <4EC1BD65.4040205@restena.lu> <4EEB1014.1030307@restena.lu> <5D36713D8A4E7348A7E10DF7437A4B9218583E44@SZXEML506-MBX.china.huawei.com> <4EF047A3.5090906@restena.lu> <4EF08F63.1010600@deployingradius.com> <5D36713D8A4E7348A7E10DF7437A4B9218584374@SZXEML506-MBX.china.huawei.com> <4EF1A65F.9080609@restena.lu> <4EF1E94D.2080006@restena.lu> <4EF2DE99.7050207@restena.lu> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 03 Jan 2012 08:09:36 -0800 Cc: softwires@ietf.org, Alan DeKok , GuoDayong Subject: Re: [Softwires] 6rd RADIUS attribute - grouped attributes X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 12:07:51 -0000 On Thu, 22 Dec 2011, Stefan Winter wrote: > Hi, >>> Any particular reason why the 6rdPrefixLen and 6rdPrefix are glued into >>> one blob in -04? >> If you ignore the 6rd references it is describing prefix data type >> defined a decade back in RFC3162 2.3 (Framed-IPv6-Prefix). Logically it >> counts as one field. > Framed-IPv6-Prefix and your data type are different. Frames-IPv6-Prefix > is of variable length, and requires to insert only those parts of the > IPv6 address which are relevant for the prefix length. You can pad with > more zeroes if you feel like it, but don't have to. (That in itself is a > rather inconvenient construct, and I like yours more than that one > actually.) Sure, if you opt to always pad with zeroes to the full 128 > bit, even if not necessary, you get the same fixed length as your > datatype requires. > Still, you have introduced a new data type > "almost-but-not-quite-Framed-IPv6-Address". There are a few areas implementors should take care to read the draft carefully. I don't have a better idea. > If you consider it a good idea, then fine - I'm sure you have much more > experience in terms of actual implementations than I do. From a design > point of view, I'd consider a pair of (int,IPv6-Address) cleaner than an > implicit struct. The "belong together" can be expressed in the RFC as > "both of the sub-TLVs have to appear exactly once". A IPv6 prefix describes one thing not a collection of related things belonging together. You can't pull apart a prefix into pieces that mean anything by themselves. By convention a prefix is always expressed as a single field wherever it is entered or displayed (fe80::/16) A prefix does not contain an IP Address. TLVs have no global type space. Elements of generally applicable composite types must be redefined separately within each instance they are used. regards, Peter From jiangsheng@huawei.com Wed Jan 11 23:25:23 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1541521F8463 for ; Wed, 11 Jan 2012 23:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkuOH6aqyQPE for ; Wed, 11 Jan 2012 23:25:22 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 65A0021F8467 for ; Wed, 11 Jan 2012 23:25:21 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXO0025MCM535@szxga05-in.huawei.com> for softwires@ietf.org; Thu, 12 Jan 2012 15:25:17 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXO00J4RCLW6N@szxga05-in.huawei.com> for softwires@ietf.org; Thu, 12 Jan 2012 15:25:17 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGJ97150; Thu, 12 Jan 2012 15:25:16 +0800 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jan 2012 15:25:07 +0800 Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.239]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Thu, 12 Jan 2012 15:25:06 +0800 Date: Thu, 12 Jan 2012 07:25:05 +0000 From: Sheng Jiang X-Originating-IP: [10.108.4.74] To: "softwires@ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B921858D880@SZXEML506-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: New Version Notification for draft-jiang-softwire-map-radius-00.txt Thread-index: AQHM0Ph4luPN3JPt0UmobrVhD5haeZYIUfQQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [Softwires] FW: New Version Notification for draft-jiang-softwire-map-radius-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 07:25:23 -0000 We have submitted a new draft "RADIUS Attribute for MAP". This document defines Radius attribute for MAP mechanism. It provides just enough information to form the correspondent DHCPv6 MAP option on BNG. Your review and comments are appreciated. Best regards, Sheng, Yu & Peter > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, January 12, 2012 3:04 PM > To: Sheng Jiang > Cc: peterd@iea-software.com; Eleven Fu(Yu); Sheng Jiang > Subject: New Version Notification for draft-jiang-softwire-map-radius- > 00.txt > > A new version of I-D, draft-jiang-softwire-map-radius-00.txt has been > successfully submitted by Sheng Jiang and posted to the IETF repository. > > Filename: draft-jiang-softwire-map-radius > Revision: 00 > Title: RADIUS Attribute for MAP > Creation date: 2012-01-12 > WG ID: Individual Submission > Number of pages: 14 > > Abstract: > Mapping of Address and Port (MAP) is a stateless mechanism for > running IPv4 over IPv6-only infrastructure. It provides both IPv4 > and > IPv6 connectivity services simultaneously during the IPv4/IPv6 co- > existing period. The Dynamic Host Configuration Protocol for IPv6 > (DHCPv6) MAP options has been defined to configure MAP Customer Edge > (CE). However, in many networks, the configuration information may > be > stored in Authentication Authorization and Accounting (AAA) servers > while user configuration is mainly from Broadband Network Gateway > (BNG) through DHCPv6 protocol. This document defines a Remote > Authentication Dial In User Service (RADIUS) attribute that carries > MAP configuration information from AAA server to BNG. The MAP RADIUS > attribute are designed following the simplify principle. It provides > just enough information to form the correspondent DHCPv6 MAP option. > > > > > > > The IETF Secretariat From leaf.y.yeh@huawei.com Fri Jan 13 03:27:45 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE0521F864F for ; Fri, 13 Jan 2012 03:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cdg53dfhCqut for ; Fri, 13 Jan 2012 03:27:44 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 814EC21F8644 for ; Fri, 13 Jan 2012 03:27:44 -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 <0LXQ006FKII2LO@szxga04-in.huawei.com> for softwires@ietf.org; Fri, 13 Jan 2012 19:27:38 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXQ00HF3IH5W7@szxga04-in.huawei.com> for softwires@ietf.org; Fri, 13 Jan 2012 19:27:38 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGH48944; Fri, 13 Jan 2012 19:27:38 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jan 2012 19:27:29 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.223]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Fri, 13 Jan 2012 19:27:18 +0800 Date: Fri, 13 Jan 2012 11:26:24 +0000 From: Leaf yeh In-reply-to: X-Originating-IP: [10.70.39.113] To: Wojciech Dec Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-mdt-softwire-map-translation-00.txt Thread-index: AczPiO1DFFhHaNh0+k2H3xnRA+iVFACTG8qg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120110110902.29249.74401.idtracker@ietfa.amsl.com> Cc: "softwires@ietf.org list" , "map-dt@external.cisco.com team" , "fine_sz@huawei.com" Subject: Re: [Softwires] New Version Notification for draft-mdt-softwire-map-translation-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 11:27:45 -0000 Comments and Questions: 1. Section 7.3 - Translating IPv6 Address and Port Number into IPv4 Address and Port Number at the BR At the BR, the IPv4 source address MUST be derived from the IPv6 source address (IPv4-translatable address) as per BMR MAP [I-D.mdt-softwire-mapping-address-and-port]. I suppose there is no BMR at BR, BMR sounds MAP-rules at CE, right? If yes, the above 'BMR' should be FMR. 2. Section 7.4 - Translating IPv4 Address and Port Number into IPv6 Address and Port Number at the CE / IPv6 Destination Address and Destination Port Number: If matching, the IPv6 destination address (IPv4-converted address) MUST be derived from the IPv4 destination address and the destination port number per FMR. I guess the above 'IPv4-converted address' might be 'IPv4-translatable' address per the address type and format definition in section 7.1. 3. Section 7.5 - Translating IPv6 Address and Port Number into IPv4 Address and Port Number at the CE / IPv4 Source Address and Source Port Number: At the CE, the IPv4 source address MUST be derived from the IPv6 source address (IPv6-converted address) as per FMR or DMR MAP [I-D.mdt-softwire-mapping-address-and-port]. I guess the above text might be 'At the CE, the IPv4 source address MUST be derived from the IPv6 source address (IPv6-converted address) as per DMR MAP or the IPv6 source address (IPv6-translatable address) as per FMR MAP.' 4. Section 7.5 - Translating IPv6 Address and Port Number into IPv4 Address and Port Number at the CE / IPv4 Destination Address and Destination Port Number: The source port number MUST be unchanged. I supposed the above 'source port' should be 'destination port' in the context. And in general speaking, both source port and destination port don't ever change in the MAP-T function of CE & BR, right? Best Regards, Leaf -----Original Message----- From: Wojciech Dec [mailto:wdec@cisco.com] Sent: Tuesday, January 10, 2012 7:14 PM To: map-dt@external.cisco.com team Subject: FW: New Version Notification for draft-mdt-softwire-map-translation-00.txt Hello All, Here's version 00 of the MAP-T draft. We welcome your feedback: http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 A new version of I-D, draft-mdt-softwire-map-translation-00.txt has been successfully submitted by Wojciech Dec and posted to the IETF repository. Filename: draft-mdt-softwire-map-translation Revision: 00 Title: MAP Translation (MAP-T) - specification Creation date: 2012-01-10 WG ID: Individual Submission Number of pages: 20 Abstract: This document specifies the "Mapping of Address and Port" (MAP) double stateless translation based solution (MAP-T) for providing IPv4 hosts connectivity to and across an IPv6 domain. Regards, Wojciech & Tsetuya From cx.cernet@gmail.com Wed Jan 18 20:01:41 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9AC21F84F8 for ; Wed, 18 Jan 2012 20:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5epuMlVNksrE for ; Wed, 18 Jan 2012 20:01:40 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9068A21F84F6 for ; Wed, 18 Jan 2012 20:01:40 -0800 (PST) Received: by pbbb2 with SMTP id b2so5472061pbb.31 for ; Wed, 18 Jan 2012 20:01:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LBE+XMjRnMJA6qNn7MrXqW9a6P/NHKcy++Z95lw6plY=; b=BDVzoGiN8bIiGMjw/Q18bQBRhzBj2FZhoSCzL6cI3drPQpRpdQffG88QjMdH/RoUn0 2xX/1eDCe0W0aBMOVgLjywiNGRt0Y687ChDKx0Bow+dfO9EIIdAxbDLi3kHvgoiWPHo8 YDDqMLQ/JcXMRROcOelJz+iv2BHRzpJw0UY1I= MIME-Version: 1.0 Received: by 10.68.196.198 with SMTP id io6mr5811265pbc.95.1326945699339; Wed, 18 Jan 2012 20:01:39 -0800 (PST) Received: by 10.142.65.4 with HTTP; Wed, 18 Jan 2012 20:01:39 -0800 (PST) In-Reply-To: References: <20120110110902.29249.74401.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2012 12:01:39 +0800 Message-ID: From: Congxiao Bao To: Leaf yeh Content-Type: multipart/alternative; boundary=e89a8ff1cc780b9e3804b6d99fcb Cc: "softwires@ietf.org list" , "map-dt@external.cisco.com team" , Wojciech Dec , "fine_sz@huawei.com" Subject: Re: [Softwires] New Version Notification for draft-mdt-softwire-map-translation-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 04:01:41 -0000 --e89a8ff1cc780b9e3804b6d99fcb Content-Type: text/plain; charset=ISO-8859-1 Hi Leaf, Thanks for your comments. Please see in lines: 2012/1/13 Leaf yeh > Comments and Questions: > > 1. Section 7.3 - Translating IPv6 Address and Port Number into IPv4 > Address and Port Number at the BR > > At the BR, the IPv4 source address MUST be derived from the IPv6 > source address (IPv4-translatable address) as per BMR MAP > [I-D.mdt-softwire-mapping-address-and-port]. > > I suppose there is no BMR at BR, BMR sounds MAP-rules at CE, right? If > yes, the above 'BMR' should be FMR. > Ok, We will sync with MAP document. > > > 2. Section 7.4 - Translating IPv4 Address and Port Number into IPv6 > Address and Port Number at the CE / IPv6 Destination Address and > Destination Port Number: > > If matching, the IPv6 destination address (IPv4-converted address) > MUST be derived from the IPv4 destination address and the destination port > number per FMR. > > I guess the above 'IPv4-converted address' might be 'IPv4-translatable' > address per the address type and format definition in section 7.1. > In RFC6052, we defined IPv4-converted address for default mapping rule (DMR), which includes the IPv4-translatable address used by other hosts behind translators, defined as FMR in MAP-T, therefore we agree to change it to IPv4-translatable address. > 3. Section 7.5 - Translating IPv6 Address and Port Number into IPv4 > Address and Port Number at the CE / IPv4 Source Address and Source Port > Number: > > At the CE, the IPv4 source address MUST be derived from the IPv6 > source address (IPv6-converted address) as per FMR or DMR MAP > [I-D.mdt-softwire-mapping-address-and-port]. > > I guess the above text might be 'At the CE, the IPv4 source address MUST > be derived from the IPv6 source address (IPv6-converted address) as per DMR > MAP or the IPv6 source address (IPv6-translatable address) as per FMR MAP.' > Same as above, agree. > 4. Section 7.5 - Translating IPv6 Address and Port Number into IPv4 > Address and Port Number at the CE / IPv4 Destination Address and > Destination Port Number: > > The source port number MUST be unchanged. > > I supposed the above 'source port' should be 'destination port' in the > context. And in general speaking, both source port and destination port > don't ever change in the MAP-T function of CE & BR, right? > Thanks. Sorry for copying error. We will correct it. Yes, in general speaking, both source port and destination port don't ever change in the MAP-T function of CE & BR. Best, Congxiao > > > Best Regards, > Leaf > > > -----Original Message----- > From: Wojciech Dec [mailto:wdec@cisco.com] > Sent: Tuesday, January 10, 2012 7:14 PM > To: map-dt@external.cisco.com team > Subject: FW: New Version Notification for > draft-mdt-softwire-map-translation-00.txt > > Hello All, > > Here's version 00 of the MAP-T draft. We welcome your feedback: > > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 > > A new version of I-D, draft-mdt-softwire-map-translation-00.txt has been > successfully submitted by Wojciech Dec and posted to the IETF repository. > > Filename: draft-mdt-softwire-map-translation > Revision: 00 > Title: MAP Translation (MAP-T) - specification > Creation date: 2012-01-10 > WG ID: Individual Submission > Number of pages: 20 > > Abstract: > This document specifies the "Mapping of Address and Port" (MAP) > double stateless translation based solution (MAP-T) for providing > IPv4 hosts connectivity to and across an IPv6 domain. > > > Regards, > Wojciech & Tsetuya > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --e89a8ff1cc780b9e3804b6d99fcb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Leaf,
Thanks for your comments. Please see in lines:

2012/1/13 Leaf yeh <leaf.y.yeh@huawei.com>
Comments and Questions:

1. Sec= tion 7.3 - Translating IPv6 Address and Port Number into IPv4 Address and P= ort Number at the BR

<quote> At the BR, the IPv4 source address MUST be derived from t= he IPv6 source address (IPv4-translatable address) as per BMR MAP [I-D.mdt-= softwire-mapping-address-and-port].

I suppose there is no BMR at BR,= BMR sounds MAP-rules at CE, right? If yes, the above 'BMR' should = be FMR.
=A0
=A0O= k, We will sync with MAP document.
=A0


2. Section 7.4 - Translating = IPv4 Address and Port Number into IPv6 Address and Port Number at the CE / = IPv6 Destination Address and Destination Port Number:

<quote> If matching, the IPv6 destination address (IPv4-converted= address) MUST be derived from the IPv4 destination address and the destina= tion port number per FMR.

I guess the above 'IPv4-converted addr= ess' might be 'IPv4-translatable' address per the address type = and format definition in section 7.1.
=A0
In RFC6052, we defined IPv4-converted addre= ss for default mapping rule (DMR),=A0which includes the IPv4-translatable address used by other ho= sts behind translators,=A0def= ined as FMR in MAP-T, therefore we agree to change it to IPv4-translatable = address.
=A0
3. Section 7.5 - Translating IPv6 Add= ress and Port Number into IPv4 Address and Port Number at the CE / IPv4 Sou= rce Address and Source Port Number:

<quote> At the CE, the IPv4 source address MUST be derived from t= he IPv6 source address (IPv6-converted address) as per FMR or DMR MAP [I-D.= mdt-softwire-mapping-address-and-port].

I guess the above text might= be 'At the CE, the IPv4 source address MUST be derived from the IPv6 s= ource address (IPv6-converted address) as per DMR MAP or the IPv6 source ad= dress (IPv6-translatable address) as per FMR MAP.'
Same as above, agree.

4. Section 7.5 - Translating IPv6= Address and Port Number into IPv4 Address and Port Number at the CE / IPv4= Destination Address and Destination Port Number:

<quote> The source port number MUST be unchanged.

I suppos= ed the above 'source port' should be 'destination port' in = the context. And in general speaking, both source port and destination port= don't ever change in the MAP-T function of CE & BR, right?
=A0
=A0Thanks. Sorry for copying error. We will= correct it. Yes, in general speaking, both sour= ce port and destination port don't ever change in the MAP-T function of= CE & BR.
= =A0
Best,
= =A0
Congxiao<= /span>
= =A0


Best Regards,
Leaf


-----Original Message-----
From: Wojciech Dec = [mailto:wdec@cisco.com]
Sent: Tues= day, January 10, 2012 7:14 PM
To: map-dt@external.cisco.com team
Subject: FW: New Version Notification for draft-mdt-softwire-map-translatio= n-00.txt

Hello All,

Here's version 00 of the MAP-T draft.= We welcome your feedback:

http://tools.ietf.org= /html/draft-mdt-softwire-map-translation-00

A new version of I-D, draft-mdt-softwire-map-translation-00.txt has bee= n
successfully submitted by Wojciech Dec and posted to the IETF reposito= ry.

Filename: =A0draft-mdt-softwire-map-translation
Revision: =A0= 00
Title: =A0 MAP Translation (MAP-T) - specification
Creation date: =A0201= 2-01-10
WG ID: =A0 Individual Submission
Number of pages: 20

A= bstract:
=A0 This document specifies the &quot;Mapping of Address an= d Port&quot; (MAP)
=A0 double stateless translation based solution (MAP-T) for providing
= =A0 IPv4 hosts connectivity to and across an IPv6 domain.


Regard= s,
Wojciech & Tsetuya


_______________________= ________________________
Softwires mailing list
Softwires@i= etf.org
https://www.ietf.org/mailman/listinfo/softwires

--e89a8ff1cc780b9e3804b6d99fcb-- From despres.remi@laposte.net Sat Jan 28 09:59:46 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AC021F84EA for ; Sat, 28 Jan 2012 09:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GzoQA1YkmRi for ; Sat, 28 Jan 2012 09:59:46 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 7E91121F84E6 for ; Sat, 28 Jan 2012 09:59:42 -0800 (PST) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 1DFAB94004B for ; Sat, 28 Jan 2012 18:59:36 +0100 (CET) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 28 Jan 2012 18:59:35 +0100 Message-Id: To: Softwires WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 17:59:46 -0000 Hello all, The new version of the proposed unified 4rd has just ben posted. It is available at: http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03 A major evolution since the previous version has been to have in it two = variants. - The Header-mapping variant is as in the previous version - The Encapsulation variant is added after comments received, and = accepted, that some use cases cannot be satisfied if the Header-mapping = variant is the only one.=20 Compared to the alternative approach of several MAP documents, the = single-document approach is expected to avoid duplicate specifications, = and to facilitate consistency checks of the design. Besides: - Header-mapping provides more complete transparency to IPv4 packets = than solutions using twice the IPv6/IPv4 translation of RFC6145. - It has also the advantage of a simpler and self-sufficient = specification. - The algorithm which permits BRs to forward datagram fragments without = datagram reassembly is included. - The problem of fragmented datagrams from shared address CEs that must = have different Identification if they go to common destinations is = covered. - The design re-introduces the Domain IPv6 suffix which in some earlier = 4rd designs, and somehow has been lost.=20 - The port-set algorithm is without parameter. All questions and comments will be most welcome. Regards, RD= From fibrib@gmail.com Sat Jan 28 20:38:10 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9112121F84B4 for ; Sat, 28 Jan 2012 20:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHEaPnOTd-2G for ; Sat, 28 Jan 2012 20:38:09 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7201A21F84A5 for ; Sat, 28 Jan 2012 20:38:09 -0800 (PST) Received: by qcsf16 with SMTP id f16so1922392qcs.31 for ; Sat, 28 Jan 2012 20:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ek4DXRAowpp7VyolbPAszt3xDYnudi5P1zrW2odeHfE=; b=T562oVmG6qY8HuNry93doEPp5DNKqgjf/INfqTz33DskygIoKQmDpvIWqVSGl3svwK KfT53Opn0sWS5f4zdxiC8wMnpNgJALb4TrlUuyIrdQji0Mi8nf1XgSrT/UN0xNyQfNGW H8/xItr2Iq4F3lbHZGVERGdV42LRG96go25Kw= MIME-Version: 1.0 Received: by 10.224.202.65 with SMTP id fd1mr15704086qab.12.1327811887928; Sat, 28 Jan 2012 20:38:07 -0800 (PST) Received: by 10.229.211.72 with HTTP; Sat, 28 Jan 2012 20:38:07 -0800 (PST) In-Reply-To: References: Date: Sun, 29 Jan 2012 13:38:07 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30050eeae895c304b7a34b34 Cc: Softwires WG Subject: Re: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 04:38:10 -0000 --20cf30050eeae895c304b7a34b34 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi, it a little confuses me that the new version introduces 2 variants - what is the technical difference of 4rd-U encapsulation variant vs. MAP-E? (except written in a single or some separated documents) on the other hand, it is unfair to state the benefit "Header-mapping provides more complete transparency to IPv4 packets than solutions using twice the IPv6/IPv4 translation of RFC6145" without mentioning the (at least the following two pieces of) cost: 1. losing the compatibility with single translation; 2. putting ICMPv4 PDU as the payload of IPv6 directly, with neither IP header nor ICMP header has the address checksum information - this will disable firewall preventing attacks. best regards, maoke 2012/1/29 R=E9mi Despr=E9s > Hello all, > > The new version of the proposed unified 4rd has just ben posted. > It is available at: > http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03 > > A major evolution since the previous version has been to have in it two > variants. > - The Header-mapping variant is as in the previous version > - The Encapsulation variant is added after comments received, and > accepted, that some use cases cannot be satisfied if the Header-mapping > variant is the only one. > > Compared to the alternative approach of several MAP documents, the > single-document approach is expected to avoid duplicate specifications, a= nd > to facilitate consistency checks of the design. > Besides: > - Header-mapping provides more complete transparency to IPv4 packets than > solutions using twice the IPv6/IPv4 translation of RFC6145. > - It has also the advantage of a simpler and self-sufficient specificatio= n. > - The algorithm which permits BRs to forward datagram fragments without > datagram reassembly is included. > - The problem of fragmented datagrams from shared address CEs that must > have different Identification if they go to common destinations is covere= d. > - The design re-introduces the Domain IPv6 suffix which in some earlier > 4rd designs, and somehow has been lost. > - The port-set algorithm is without parameter. > > All questions and comments will be most welcome. > > Regards, > RD > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf30050eeae895c304b7a34b34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Remi,
=A0
it a little confuses me that the new= version introduces 2 variants - what is the technical difference of 4rd-U= =A0encapsulation variant=A0vs. MAP-E?=A0(except written in a=A0single or=A0= some=A0separated documents)
=A0
on the other hand, it is unfair to state the benefit=A0&= quot;Header-mapping provides more complete transparency to IPv4 packets tha= n solutions using twice the IPv6/IPv4 translation of RFC6145" without = mentioning=A0the (at least the following two pieces of)=A0cost: 1. losing t= he compatibility with single translation; 2.=A0putting ICMPv4 PDU as=A0the = payload of IPv6 directly, with=A0neither IP header nor ICMP header has the= =A0address checksum information - this=A0will disable firewall preventing a= ttacks.
=A0
best regards,
maoke
2012/1/29 R=E9mi Despr=E9s <despres.remi@laposte.net>
Hello all,

The new version of the proposed unified 4rd has just ben posted.
It is available at:
=A0http://tools.ietf.org/html/draft-despres-softwire-4rd-u-0= 3

A major evolution since the previous version has been to have in it two var= iants.
- The Header-mapping variant is as in the previous version
- The Encapsulation variant is added after comments received, and accepted,= that some use cases cannot be satisfied if the Header-mapping variant is t= he only one.

Compared to the alternative approach of several MAP documents, the single-d= ocument approach is expected to avoid duplicate specifications, and to faci= litate consistency checks of the design.
Besides:
- Header-mapping provides more complete transparency to IPv4 packets than s= olutions using twice the IPv6/IPv4 translation of RFC6145.
- It has also the advantage of a simpler and self-sufficient specification.=
- The algorithm which permits BRs to forward datagram fragments without dat= agram reassembly is included.
- The problem of fragmented datagrams from shared address CEs that must hav= e different Identification if they go to common destinations is covered. - The design re-introduces the Domain IPv6 suffix which in some earlier 4rd= designs, and somehow has been lost.
- The port-set algorithm is without parameter.

All questions and comments will be most welcome.

Regards,
RD
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf30050eeae895c304b7a34b34-- From despres.remi@laposte.net Mon Jan 30 01:22:23 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A261021F8476 for ; Mon, 30 Jan 2012 01:22:23 -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=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gueIu2FzPXMv for ; Mon, 30 Jan 2012 01:22:22 -0800 (PST) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.119]) by ietfa.amsl.com (Postfix) with ESMTP id 715BF21F8460 for ; Mon, 30 Jan 2012 01:22:21 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2507.sfr.fr (SMTP Server) with ESMTP id C8A4E7000074; Mon, 30 Jan 2012 10:22:20 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2507.sfr.fr (SMTP Server) with ESMTP id 52A5E700006C; Mon, 30 Jan 2012 10:22:20 +0100 (CET) X-SFR-UUID: 20120130092220338.52A5E700006C@msfrf2507.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-85--431694929 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 30 Jan 2012 10:22:19 +0100 Message-Id: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> References: To: Maoke X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG Subject: Re: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 09:22:23 -0000 --Apple-Mail-85--431694929 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Maoke, Good to see you back in technical discussions, of which we had so many = useful ones. More in line. =20 Le 2012-01-29 =E0 05:38, Maoke a =E9crit : > hi Remi, > =20 > it a little confuses me that the new version introduces 2 variants > - what is the technical difference of 4rd-U encapsulation variant vs. = MAP-E? (except written in a single or some separated documents) No difference (as said). > =20 > on the other hand, it is unfair to state the benefit "Header-mapping = provides more complete transparency to IPv4 packets than solutions using = twice the IPv6/IPv4 translation of RFC6145" without mentioning the (at = least the following two pieces of) > cost: 1. Not clear AFAIK. It can be discussed if you expand, but less subjective issues like those = below are IMHO more important. > losing the compatibility with single translation; 2. I don't see this because, in my understanding: - IPv6-only CPEs, in order to work with IPv4 shared addresses processed = by BRs are stateless, MUST be modified anyway. - Unmodified IPv6-only CPEs don't need to be modified to work with = shared addresses processed by stateful NAT64/DNS64 (with known = limitations NAT-related limitations, but this is understood).=20 - 4rd-U can coexist with NAT64/DNS64 in ISP networks. (Provided IPv4 = address-spaces used by NAT64 and 4rd-U are disjoint, there is AFAIK no = operational issue. If you have a specific configuration that illustrates your concern, it = could be discussed with more details. > putting ICMPv4 PDU as the payload of IPv6 directly, with neither IP = header nor ICMP header has the address checksum information - this will = disable firewall preventing attacks. For a site having a customer-provided CPE that integrates a firewall to = take advantage of stateless IPv4-address sharing, its FW MUST be = upgraded anyway. Adding to it 4rd-U support is for this a logical = solution. =20 If the FW-CPE is not modified, its operation across IPv6-only networks = remains IPv6-only (translatable to IPv4 by NAT64 if supported by the = ISP). Adding a note on this in the document would be possible, if found = useful. =20 Cheers, RD > =20 > best regards, > maoke > 2012/1/29 R=E9mi Despr=E9s > Hello all, >=20 > The new version of the proposed unified 4rd has just ben posted. > It is available at: > http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03 >=20 > A major evolution since the previous version has been to have in it = two variants. > - The Header-mapping variant is as in the previous version > - The Encapsulation variant is added after comments received, and = accepted, that some use cases cannot be satisfied if the Header-mapping = variant is the only one. >=20 > Compared to the alternative approach of several MAP documents, the = single-document approach is expected to avoid duplicate specifications, = and to facilitate consistency checks of the design. > Besides: > - Header-mapping provides more complete transparency to IPv4 packets = than solutions using twice the IPv6/IPv4 translation of RFC6145. > - It has also the advantage of a simpler and self-sufficient = specification. > - The algorithm which permits BRs to forward datagram fragments = without datagram reassembly is included. > - The problem of fragmented datagrams from shared address CEs that = must have different Identification if they go to common destinations is = covered. > - The design re-introduces the Domain IPv6 suffix which in some = earlier 4rd designs, and somehow has been lost. > - The port-set algorithm is without parameter. >=20 > All questions and comments will be most welcome. >=20 > Regards, > RD > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 --Apple-Mail-85--431694929 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Maoke,

Good to see you back in technical discussions, = of which we had so many useful ones.
More in = line.

 
Le 2012-01-29 = =E0 05:38, Maoke a =E9crit :

hi = Remi,
 
it a little confuses me that the new = version introduces 2 variants

- what is the technical difference of = 4rd-U encapsulation variant vs. MAP-E? (except written in = a single or some separated = documents)

No difference (as = said).

 
on the other hand, it is unfair to = state the benefit "Header-mapping provides more complete = transparency to IPv4 packets than solutions using twice the IPv6/IPv4 = translation of RFC6145" without mentioning the (at least the = following two pieces of)

 cost: 1. =

Not clear AFAIK.
It can = be discussed if you expand, but less subjective issues like those = below are IMHO more important.

losing the compatibility with single translation; = 2.

I don't see this because, in my = understanding:
- IPv6-only CPEs, in order to work with IPv4 = shared addresses processed by BRs are stateless, MUST be = modified anyway.
- Unmodified IPv6-only CPEs don't need to be = modified to work with shared addresses processed by stateful NAT64/DNS64 = (with known limitations NAT-related limitations, but this is = understood). 
- 4rd-U can coexist with NAT64/DNS64 in ISP = networks. (Provided IPv4 address-spaces used by NAT64 and 4rd-U are = disjoint, there is AFAIK no operational = issue.

If you have a specific configuration = that illustrates your concern, it could be discussed with more = details.

 putting = ICMPv4 PDU as the payload of IPv6 directly, with neither IP = header nor ICMP header has the address checksum information - = this will disable firewall preventing attacks. =


For a site having = a customer-provided CPE that integrates a firewall to take = advantage of stateless IPv4-address sharing, its FW  MUST be = upgraded anyway. Adding to it 4rd-U support is for this a = logical solution.  
If the FW-CPE is not modified, its = operation across IPv6-only networks remains IPv6-only (translatable to = IPv4 by NAT64 if supported by the ISP).
Adding a note on this = in the document would be possible, if found useful. =  

Cheers,
RD

<= div>
 
best regards,
maoke
2012/1/29 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Hello all,

The new version of the proposed unified 4rd has just ben posted.
It is available at:
 http://tools.ietf.org/html/draft-despres-softwire-4rd-u-= 03

A major evolution since the previous version has been to have in it two = variants.
- The Header-mapping variant is as in the previous version
- The Encapsulation variant is added after comments received, and = accepted, that some use cases cannot be satisfied if the Header-mapping = variant is the only one.

Compared to the alternative approach of several MAP documents, the = single-document approach is expected to avoid duplicate specifications, = and to facilitate consistency checks of the design.
Besides:
- Header-mapping provides more complete transparency to IPv4 packets = than solutions using twice the IPv6/IPv4 translation of RFC6145.
- It has also the advantage of a simpler and self-sufficient = specification.
- The algorithm which permits BRs to forward datagram fragments without = datagram reassembly is included.
- The problem of fragmented datagrams from shared address CEs that must = have different Identification if they go to common destinations is = covered.
- The design re-introduces the Domain IPv6 suffix which in some earlier = 4rd designs, and somehow has been lost.
- The port-set algorithm is without parameter.

All questions and comments will be most welcome.

Regards,
RD
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


= --Apple-Mail-85--431694929-- From fibrib@gmail.com Mon Jan 30 02:47:50 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBD321F8670 for ; Mon, 30 Jan 2012 02:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIRQY91chjzd for ; Mon, 30 Jan 2012 02:47:49 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 290FD21F8636 for ; Mon, 30 Jan 2012 02:47:49 -0800 (PST) Received: by qcsf16 with SMTP id f16so2469277qcs.31 for ; Mon, 30 Jan 2012 02:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OypXENAWHFNy6lQ360laaygTEXpTxNanSjjsqGIDY5Y=; b=B4AzrtEQQ4+SWMaf8n5MvDMpUZzbJrZ6b4tP6eAb0mQ1Hd229MY2Y9Ztnl2VkcnVD+ mKiUx18W1K1bPGTlaOez44fg34Zn1tgR64lfCra7qSiMRalR7KzS4zDmujY2dgtmoTE1 pZow+vYRSD1r7Ij5gTcE5F31nx73BihkHHEX8= MIME-Version: 1.0 Received: by 10.229.102.155 with SMTP id g27mr6159075qco.103.1327920468586; Mon, 30 Jan 2012 02:47:48 -0800 (PST) Received: by 10.229.211.72 with HTTP; Mon, 30 Jan 2012 02:47:48 -0800 (PST) In-Reply-To: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> References: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> Date: Mon, 30 Jan 2012 19:47:48 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=0023544706d8d1eff004b7bc93c4 Cc: Softwires WG Subject: Re: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 10:47:50 -0000 --0023544706d8d1eff004b7bc93c4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/1/30 R=E9mi Despr=E9s > Hi Maoke, > > Good to see you back in technical discussions, of which we had so many > useful ones. > More in line. > > > Le 2012-01-29 =E0 05:38, Maoke a =E9crit : > > hi Remi, > > it a little confuses me that the new version introduces 2 variants > > > - what is the technical difference of 4rd-U encapsulation variant vs. > MAP-E? (except written in a single or some separated documents) > > > No difference (as said). > > > on the other hand, it is unfair to state the benefit "Header-mapping > provides more complete transparency to IPv4 packets than solutions using > twice the IPv6/IPv4 translation of RFC6145" without mentioning the (at > least the following two pieces of) > > > cost: 1. > > > Not clear AFAIK. > It can be discussed if you expand, but less subjective issues like those > below are IMHO more important. > > losing the compatibility with single translation; 2. > > > I don't see this because, in my understanding: > - IPv6-only CPEs, in order to work with IPv4 shared addresses processed b= y > BRs are stateless, MUST be modified anyway. > - Unmodified IPv6-only CPEs don't need to be modified to work with shared > addresses processed by stateful NAT64/DNS64 (with known limitations > NAT-related limitations, but this is understood). > - 4rd-U can coexist with NAT64/DNS64 in ISP networks. (Provided IPv4 > address-spaces used by NAT64 and 4rd-U are disjoint, there is AFAIK no > operational issue. > > well, if address spaces (as well as routings) are totally disjoint, it is hard to call it as "coexist", ;-) and definitely there is no compatibility to single translation in RFC6145 at all. as the result, RFC6145 provides a unified solution, while 4rd-U requires ISP (who prefer to use translation) disjointly deploy their networks for single and double translations. > > > If you have a specific configuration that illustrates your concern, it > could be discussed with more details. > > putting ICMPv4 PDU as the payload of IPv6 directly, with neither IP > header nor ICMP header has the address checksum information - this will > disable firewall preventing attacks. > > > > For a site having a customer-provided CPE that integrates a firewall to > take advantage of stateless IPv4-address sharing, its FW MUST be upgrade= d > anyway. Adding to it 4rd-U support is for this a logical solution. > > the attack preventing should be done everywhere, including in the middle of the IPv6 domain. however, IPv6-containing-ICMPv4 loses information checksum regarding the original IPv4 addresses and therefore (no matter how the firewall is upgraded) the consistency check is not possible. it should be a big security concern. this is one of the major reasons that i don't think putting ICMPv4 into IPv6 directly is a good idea. either full encapsulation or Simple IP/ICMP translation is far better. best, maoke > > If the FW-CPE is not modified, its operation across IPv6-only networks > remains IPv6-only (translatable to IPv4 by NAT64 if supported by the ISP)= . > Adding a note on this in the document would be possible, if found useful. > > Cheers, > RD > > > > best regards, > maoke > 2012/1/29 R=E9mi Despr=E9s > >> Hello all, >> >> The new version of the proposed unified 4rd has just ben posted. >> It is available at: >> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03 >> >> A major evolution since the previous version has been to have in it two >> variants. >> - The Header-mapping variant is as in the previous version >> - The Encapsulation variant is added after comments received, and >> accepted, that some use cases cannot be satisfied if the Header-mapping >> variant is the only one. >> >> Compared to the alternative approach of several MAP documents, the >> single-document approach is expected to avoid duplicate specifications, = and >> to facilitate consistency checks of the design. >> Besides: >> - Header-mapping provides more complete transparency to IPv4 packets tha= n >> solutions using twice the IPv6/IPv4 translation of RFC6145. >> - It has also the advantage of a simpler and self-sufficient >> specification. >> - The algorithm which permits BRs to forward datagram fragments without >> datagram reassembly is included. >> - The problem of fragmented datagrams from shared address CEs that must >> have different Identification if they go to common destinations is cover= ed. >> - The design re-introduces the Domain IPv6 suffix which in some earlier >> 4rd designs, and somehow has been lost. >> - The port-set algorithm is without parameter. >> >> All questions and comments will be most welcome. >> >> Regards, >> RD >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > > --0023544706d8d1eff004b7bc93c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/1/30 R=E9mi Despr=E9s <despres.remi@laposte.net>
Hi Maoke,

Good to se= e you back in technical discussions, of which we had so many useful ones.
More in line.

=A0
Le = 2012-01-29 =E0 05:38, Maoke a =E9crit :

hi Remi,
= =A0
it a little confuses me that the new version introduces 2 var= iants

- what is the t= echnical difference of 4rd-U=A0encapsulation variant=A0vs. MAP-E?=A0(except= written in a=A0single or=A0some=A0separated documents)

No difference (as said).

=A0
on = the other hand, it is unfair to state the benefit=A0"Header-mapping pr= ovides more complete transparency to IPv4 packets than solutions using twic= e the IPv6/IPv4 translation of RFC6145" without mentioning=A0the (at l= east the following two pieces of)

=A0cost: 1.

Not clear AFAIK.
It can be discusse= d if you expand,=A0but less subjective issues like those below are IMHO mor= e important.

losing the compatibili= ty with single translation; 2.

= I don't see this because, in my understanding:
- IPv6-only CP= Es, in order to work with IPv4 shared addresses processed by BRs are=A0stat= eless,=A0MUST=A0be modified anyway.
- Unmodified IPv6-only CPEs don't need to be modified to work with= shared addresses processed by stateful NAT64/DNS64 (with known limitations= NAT-related=A0limitations, but this is understood).=A0
- 4rd-U c= an coexist with NAT64/DNS64 in ISP networks. (Provided IPv4 address-spaces = used by NAT64 and 4rd-U are disjoint, there is AFAIK no operational issue.<= /div>
=A0
=A0
well, if ad= dress spaces (as well as routings) are totally=A0disjoint,=A0it is hard to = call=A0it as "coexist", ;-) and definitely there is no compatibil= ity to single translation in RFC6145 at all. as the result, RFC6145=A0provi= des a unified solution, while 4rd-U requires ISP (who prefer to use transla= tion)=A0disjointly deploy their networks for single and double translations= .
=A0
=A0

If you have a specific configuration that illu= strates your concern, it could be discussed with more details.

=A0putting ICMPv4 = PDU as=A0the payload of IPv6 directly, with=A0neither IP header nor ICMP he= ader has the=A0address checksum information - this=A0will disable firewall = preventing attacks.


For a site having a c= ustomer-provided CPE that integrates a firewall=A0to take advantage of stat= eless IPv4-address sharing, its FW =A0MUST be upgraded anyway. Adding to it= 4rd-U support is=A0for this=A0a logical solution.=A0=A0
=A0
=A0
this is one of the major reasons that i don't think = putting ICMPv4 into IPv6 directly is a good idea. either full encapsulation= or Simple IP/ICMP translation is far better.
=A0
best= ,
maoke
=A0
=A0
If the FW-CPE is not modified, its operation a= cross IPv6-only networks remains IPv6-only (translatable to IPv4 by NAT64 i= f supported by the ISP).
Adding a note on this in the document wo= uld be possible, if found useful. =A0

Cheers,
RD


=A0
best regards,
maoke
2012/1/29 R=E9mi Despr=E9s <despres.remi@laposte.net&= gt;
Hello all,

The new version of the proposed unified 4rd has just ben posted.
It is available at:
=A0http://tools.ietf.org/html/draft-despres-softwire-4rd-u-0= 3

A major evolution since the previous version has been to have in it two var= iants.
- The Header-mapping variant is as in the previous version
- The Encapsulation variant is added after comments received, and accepted,= that some use cases cannot be satisfied if the Header-mapping variant is t= he only one.

Compared to the alternative approach of several MAP documents, the single-d= ocument approach is expected to avoid duplicate specifications, and to faci= litate consistency checks of the design.
Besides:
- Header-mapping provides more complete transparency to IPv4 packets than s= olutions using twice the IPv6/IPv4 translation of RFC6145.
- It has also the advantage of a simpler and self-sufficient specification.=
- The algorithm which permits BRs to forward datagram fragments without dat= agram reassembly is included.
- The problem of fragmented datagrams from shared address CEs that must hav= e different Identification if they go to common destinations is covered. - The design re-introduces the Domain IPv6 suffix which in some earlier 4rd= designs, and somehow has been lost.
- The port-set algorithm is without parameter.

All questions and comments will be most welcome.

Regards,
RD
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



--0023544706d8d1eff004b7bc93c4-- From despres.remi@laposte.net Mon Jan 30 03:21:54 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085E821F86AD for ; Mon, 30 Jan 2012 03:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNUNtJyzC4EJ for ; Mon, 30 Jan 2012 03:21:53 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4B76221F8618 for ; Mon, 30 Jan 2012 03:21:52 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 2784E70000D2; Mon, 30 Jan 2012 12:21:51 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 737EC7000078; Mon, 30 Jan 2012 12:21:50 +0100 (CET) X-SFR-UUID: 20120130112150473.737EC7000078@msfrf2412.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-87--424524701 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 30 Jan 2012 12:21:49 +0100 Message-Id: <3069401B-458B-41E2-B6B3-B9FA8811CC30@laposte.net> References: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Softwires WG Subject: Re: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 11:21:54 -0000 --Apple-Mail-87--424524701 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-01-30 =E0 11:47, Maoke a =E9crit : >=20 > 2012/1/30 R=E9mi Despr=E9s > Hi Maoke, >=20 > Good to see you back in technical discussions, of which we had so many = useful ones. > More in line. >=20 > =20 > Le 2012-01-29 =E0 05:38, Maoke a =E9crit : >=20 >> hi Remi, >> =20 >> it a little confuses me that the new version introduces 2 variants >=20 >> - what is the technical difference of 4rd-U encapsulation variant vs. = MAP-E? (except written in a single or some separated documents) >=20 > No difference (as said). >=20 >> =20 >> on the other hand, it is unfair to state the benefit "Header-mapping = provides more complete transparency to IPv4 packets than solutions using = twice the IPv6/IPv4 translation of RFC6145" without mentioning the (at = least the following two pieces of) >=20 >> cost: 1. >=20 > Not clear AFAIK. > It can be discussed if you expand, but less subjective issues like = those below are IMHO more important. >=20 >> losing the compatibility with single translation; 2. >=20 > I don't see this because, in my understanding: > - IPv6-only CPEs, in order to work with IPv4 shared addresses = processed by BRs are stateless, MUST be modified anyway. > - Unmodified IPv6-only CPEs don't need to be modified to work with = shared addresses processed by stateful NAT64/DNS64 (with known = limitations NAT-related limitations, but this is understood).=20 > - 4rd-U can coexist with NAT64/DNS64 in ISP networks. (Provided IPv4 = address-spaces used by NAT64 and 4rd-U are disjoint, there is AFAIK no = operational issue. > =20 > =20 > well, if address spaces (as well as routings) are totally disjoint, it = is hard to call it as "coexist", ;-) Do you mean it would be difficult to route some of the ISP IPv4 = prefix(es) to the NAT64 and some to the 4rd-U BR? Isn't there already the same need if there are several NAT64s? (They = must work with disjoint IPv4 address spaces.) =20 > and definitely there is no compatibility to single translation in = RFC6145 at all. as the result, RFC6145 provides a unified solution, = while 4rd-U requires ISP (who prefer to use translation) disjointly = deploy their networks for single and double translations. > =20 > =20 >=20 > If you have a specific configuration that illustrates your concern, it = could be discussed with more details. Could you, for the sake of a less abstract discussion, describe at least = one configuration you have in mind, in which some IPv4 addresses are = statelessly shared, and in which there is the RFC6145 compatibility you = are talking about. Without that, I can't figure out what you mean.=20 (The goal remains customer service, without harm if this happens to be = possible without full support of RFC4125, right?) RD >=20 >> putting ICMPv4 PDU as the payload of IPv6 directly, with neither IP = header nor ICMP header has the address checksum information - this will = disable firewall preventing attacks. >=20 >=20 > For a site having a customer-provided CPE that integrates a firewall = to take advantage of stateless IPv4-address sharing, its FW MUST be = upgraded anyway. Adding to it 4rd-U support is for this a logical = solution. =20 > =20 > =20 > the attack preventing should be done everywhere, including in the = middle of the IPv6 domain. however, IPv6-containing-ICMPv4 loses = information checksum regarding the original IPv4 addresses and therefore = (no matter how the firewall is upgraded) the consistency check is not = possible. it should be a big security concern. > =20 > this is one of the major reasons that i don't think putting ICMPv4 = into IPv6 directly is a good idea. either full encapsulation or Simple = IP/ICMP translation is far better. > =20 > best, > maoke > =20 > =20 > If the FW-CPE is not modified, its operation across IPv6-only networks = remains IPv6-only (translatable to IPv4 by NAT64 if supported by the = ISP). > Adding a note on this in the document would be possible, if found = useful. =20 >=20 > Cheers, > RD >=20 >=20 >> =20 >> best regards, >> maoke >> 2012/1/29 R=E9mi Despr=E9s >> Hello all, >>=20 >> The new version of the proposed unified 4rd has just ben posted. >> It is available at: >> http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03 >>=20 >> A major evolution since the previous version has been to have in it = two variants. >> - The Header-mapping variant is as in the previous version >> - The Encapsulation variant is added after comments received, and = accepted, that some use cases cannot be satisfied if the Header-mapping = variant is the only one. >>=20 >> Compared to the alternative approach of several MAP documents, the = single-document approach is expected to avoid duplicate specifications, = and to facilitate consistency checks of the design. >> Besides: >> - Header-mapping provides more complete transparency to IPv4 packets = than solutions using twice the IPv6/IPv4 translation of RFC6145. >> - It has also the advantage of a simpler and self-sufficient = specification. >> - The algorithm which permits BRs to forward datagram fragments = without datagram reassembly is included. >> - The problem of fragmented datagrams from shared address CEs that = must have different Identification if they go to common destinations is = covered. >> - The design re-introduces the Domain IPv6 suffix which in some = earlier 4rd designs, and somehow has been lost. >> - The port-set algorithm is without parameter. >>=20 >> All questions and comments will be most welcome. >>=20 >> Regards, >> RD >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 >=20 --Apple-Mail-87--424524701 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

2012/1/30 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Hi Maoke,

Good to = see you back in technical discussions, of which we had so many useful = ones.
More in = line.

 
Le 2012-01-29 = =E0 05:38, Maoke a =E9crit :

hi Remi, =
 
it a little confuses me that the new version = introduces 2 variants

- what is the technical difference of = 4rd-U encapsulation variant vs. MAP-E? (except written in = a single or some separated documents)

No difference (as = said).

 
on the other hand, it is unfair to = state the benefit "Header-mapping provides more complete = transparency to IPv4 packets than solutions using twice the IPv6/IPv4 = translation of RFC6145" without mentioning the (at least the = following two pieces of)

 cost: 1. =

Not clear = AFAIK.
It can be discussed if you expand, but less = subjective issues like those below are IMHO more important.

losing the = compatibility with single translation; = 2.

I don't see this because, = in my understanding:
- IPv6-only CPEs, in order to work with = IPv4 shared addresses processed by BRs = are stateless, MUST be modified anyway.
- Unmodified IPv6-only CPEs don't need to be modified to work with = shared addresses processed by stateful NAT64/DNS64 (with known = limitations NAT-related limitations, but this is = understood). 
- 4rd-U can coexist with NAT64/DNS64 in ISP = networks. (Provided IPv4 address-spaces used by NAT64 and 4rd-U are = disjoint, there is AFAIK no operational issue.
=
 
 
well= , if address spaces (as well as routings) are = totally disjoint, it is hard to call it as "coexist", = ;-)

Do you mean it would be = difficult to route some of the ISP IPv4 prefix(es) to the NAT64 and some = to the 4rd-U BR?
Isn't there already the same need if there = are several NAT64s? (They must work with disjoint IPv4 address = spaces.)
  

and definitely there is no compatibility to = single translation in RFC6145 at all. as the result, = RFC6145 provides a unified solution, while 4rd-U requires ISP (who = prefer to use translation) disjointly deploy their networks for = single and double translations.
 
 

If you have a specific configuration = that illustrates your concern, it could be discussed with more = details.

<= /div>
Could you, for the sake of a less abstract discussion, = describe at least one configuration you have in mind, in which some IPv4 = addresses are statelessly shared, and in which there is the RFC6145 = compatibility you are talking about.
Without that, I can't = figure out what you mean. 
(The goal remains customer = service, without harm if this happens to be possible without full = support of RFC4125, = right?)

RD






 putting = ICMPv4 PDU as the payload of IPv6 directly, with neither IP = header nor ICMP header has the address checksum information - = this will disable firewall preventing attacks.


For a site having = a customer-provided CPE that integrates a firewall to take = advantage of stateless IPv4-address sharing, its FW  MUST be = upgraded anyway. Adding to it 4rd-U support is for this a = logical solution.  
=
 
 
the = attack preventing should be done everywhere, including in the middle of = the IPv6 domain. however, IPv6-containing-ICMPv4 loses = information checksum regarding the original IPv4 addresses and = therefore (no matter how the firewall is upgraded) the consistency check = is not possible. it should be a big security concern.
 
this is one of the major reasons that i don't = think putting ICMPv4 into IPv6 directly is a good idea. either full = encapsulation or Simple IP/ICMP translation is far better. =
 
best,
maoke
 
 
If the FW-CPE is not modified, its = operation across IPv6-only networks remains IPv6-only (translatable to = IPv4 by NAT64 if supported by the ISP).
Adding a note on this = in the document would be possible, if found useful.  

Cheers,
RD


 
best regards,
maoke
2012/1/29 R=E9mi Despr=E9s <despres.remi@laposte.net>
Hello all,

The new version of the proposed unified 4rd has just ben posted.
It is available at:
 http://tools.ietf.org/html/draft-despres-softwire-4rd-u-= 03

A major evolution since the previous version has been to have in it two = variants.
- The Header-mapping variant is as in the previous version
- The Encapsulation variant is added after comments received, and = accepted, that some use cases cannot be satisfied if the Header-mapping = variant is the only one.

Compared to the alternative approach of several MAP documents, the = single-document approach is expected to avoid duplicate specifications, = and to facilitate consistency checks of the design.
Besides:
- Header-mapping provides more complete transparency to IPv4 packets = than solutions using twice the IPv6/IPv4 translation of RFC6145.
- It has also the advantage of a simpler and self-sufficient = specification.
- The algorithm which permits BRs to forward datagram fragments without = datagram reassembly is included.
- The problem of fragmented datagrams from shared address CEs that must = have different Identification if they go to common destinations is = covered.
- The design re-introduces the Domain IPv6 suffix which in some earlier = 4rd designs, and somehow has been lost.
- The port-set algorithm is without parameter.

All questions and comments will be most welcome.

Regards,
RD
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires




= --Apple-Mail-87--424524701-- From ichiroumakino@gmail.com Mon Jan 30 03:31:44 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2C521F86B9 for ; Mon, 30 Jan 2012 03:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2OfjG0mVRqh for ; Mon, 30 Jan 2012 03:31:43 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC2A21F86B7 for ; Mon, 30 Jan 2012 03:31:43 -0800 (PST) Received: by wgbgn7 with SMTP id gn7so3517159wgb.1 for ; Mon, 30 Jan 2012 03:31:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=C2dOm+pGvaJBvXdwmNX1Dt2gGWvtuYx19LFaHlIH34A=; b=MuJFKdZ05pAVJjefUNHtrTpYuPj6Rwr2E5d/fTf5ey18N9AXoqf0lGb+xdtRng63xO 9sLs9HJ7K4M4pulVClYSYacrnShoeGEXQuwLvN96uzz6WVwB5LjLyBEBW3tzbMqHjR8P UVVspgg+yCcw3K06IV5uDx41YooiHmGezXios= Received: by 10.180.85.105 with SMTP id g9mr8114836wiz.12.1327923102599; Mon, 30 Jan 2012 03:31:42 -0800 (PST) Received: from [173.38.129.125] ([173.38.129.125]) by mx.google.com with ESMTPS id l12sm30469351wiw.0.2012.01.30.03.31.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jan 2012 03:31:41 -0800 (PST) Sender: Ole Troan From: =?iso-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jan 2012 12:31:39 +0100 Message-Id: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> To: softwires WG Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 11:31:44 -0000 hi, the MAP (Mapping of address and port) design team has now written and = published the following sets of drafts. the base document (port mapping algorithm): = http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03 = http://tools.ietf.org/rfcdiff?url2=3Ddraft-mdt-softwire-mapping-address-an= d-port-03.txt the encapsulation document (MAP-E): http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 the translation document (MAP-T): http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 the DHCP option (MAP-DHCP): http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02 there is a MAP deployment document coming soon. the solution described in this set of documents, are written to satisfy = the following from the softwires charter: 4. Developments for stateless legacy IPv4 carried over IPv6=20 - develop a solution motivation document to be published as an RFC=20= - develop a protocol specification response to the solution=20 motivation document; this work item will not be taken through=20 in the design team's view, this set of documents are ready to be adopted = as working group documents. comments? for the MAP design team, Ole= From ot@cisco.com Mon Jan 30 03:41:28 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7490121F86B4 for ; Mon, 30 Jan 2012 03:41:28 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5MKFVL8Tobq for ; Mon, 30 Jan 2012 03:41:27 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9B721F86AA for ; Mon, 30 Jan 2012 03:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ot@cisco.com; l=3225; q=dns/txt; s=iport; t=1327923687; x=1329133287; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=F2z74wjgWWVEXUg1KT0JQyYuymPTM/PhGU+HHBrvgSs=; b=RHtklBcK4wF4/xLNUSBZdUG8q5394HcWNl3AvVYS/k4kwirKTASESfyR YDQVqf5kdumMLG7XoyiSRf36jReNXTIHNDk3b0q5t0aLJzRs4QEXcgnoJ Ehb3Bi8qtk+E1L1h8JZoNUp5Pr6gUji3zZLaVQHDPdrGy7sfDIC1Cakta Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArAFABKBJk+Q/khM/2dsb2JhbABDhDlSqUyBBYFyAQEBAwEMBgEQVgUHBAkCEQQBAQMCIwMCAkYJCAYTIodamj4BjGGRKYEvhw0GAx0EAwQwgxkDFQILAwJkglUzYwSVGoVWjHw X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="127976423" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 30 Jan 2012 11:41:26 +0000 Received: from [173.38.129.125] ([173.38.129.125]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0UBfP7l006577; Mon, 30 Jan 2012 11:41:26 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Mon, 30 Jan 2012 12:41:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <705AC902-5143-42E5-841B-5B1D3348B628@cisco.com> <89A006C2-B3FB-4B08-9308-2B81023D9C80@cisco.com> To: Leaf yeh X-Mailer: Apple Mail (2.1251.1) Cc: softwires WG , "map-dt@external.cisco.com team" , "fine_sz@huawei.com" Subject: Re: [Softwires] More changes to revision 03. X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 11:41:28 -0000 Leaf, OK, I'll get it in the next revision. cheers, Ole On Jan 30, 2012, at 12:38 , Leaf yeh wrote: > Ole - what's the difference? > =20 > I suggested the following text for the readable . > =20 > Given: > End-user IPv6 prefix: 2001:db8:0012:34::/56 > Basic Mapping Rule: {2001:db8:00::/40 (Rule IPv6 prefix), > 192.0.2.0/24 (Rule IPv4 prefix), > 16 (Rule EA-bits length)} > PSID offset: 4 (default value as per section 5.1.3) > =20 > We get the IPv4 address, its sharing ratio and port-set: > =20 > EA bits offset: 40 > IPv4 suffix bits (p): Length of IPv4 address (32) - IPv4 prefix = length (24) =3D 8 > IPv4 address: 192.0.2.18 (0x12) > =E3=80=80=E3=80=80 > =E3=80=80=E3=80=80Sharing ratio: 256 (16 - (32 - 24) =3D 8. = 2^8 =3D 256) > =20 > =20 > Cheers, > Leaf > =20 > =20 > -----Original Message----- > From: Ole Tr=C3=B8an [mailto:ot@cisco.com] > Sent: Monday, January 30, 2012 6:16 PM > To: Leaf yeh > Cc: fine_sz@huawei.com; map-dt@external.cisco.com team > Subject: Re: More changes to revision 03. > =20 > Leaf, > =20 > > Again C&Qs on the examples in the newly updated candidate of MAP-03: > >=20 > > A. Section 5.2 - Given: > > End-user IPv6 prefix: 2001:db8:0012:34::/56 > > Basic Mapping Rule: {2001:db8:00::/40 (Rule IPv6 prefix), > > 192.0.2.0/24 (Rule IPv4 prefix), > > 16 (Rule EA-bits length)} > > Sharing ratio: 256 (16 - (32 - 24) =3D 8. 2^8 =3D 256) > > PSID offset: 4 > >=20 > > We get IPv4 address and port-set: > > EA bits offset: 40 > > IPv4 suffix bits (p): Length of IPv4 address (32) - > > IPv4 prefix length (24) =3D 8 > > =E2=80=A6. > >=20 > > C1. The =E2=80=98End-user IPv6 prefix=E2=80=99 shall be express as = =E2=80=982001:db8:0012:3400::/56=E2=80=99 as per the section 2.3 of = RFC4291; > =20 > fixed. > =20 > > C2. The sharing ratio sounds a calculated result, not a =E2=80=98given= =E2=80=99 condition; > =20 > what's the difference? > =20 > =20 > >=20 > > B. Section 5.3 - Given: > > IPv4 destination address: 192.0.2.18 > > IPv4 destination port: 9030 > > Forwarding Mapping Rule: {2001:db8:00::/40 (Rule IPv6 = prefix), > > 192.0.2.0/24 (Rule IPv4 prefix), > > 16 (Rule EA-bits length)} > >=20 > > We get IPv6 address: > > IPv4 suffix bits (p): 32 - 24 =3D 8 (18 (0x12)) > > PSID length: 8 > > PSID: 0x34 (9030 (0x2346)) > > EA bits: 0x1234 > > MAP IPv6 address: 2001:db8:0012:3400:00c0:0002:1200:3400 > >=20 > > C3. I suppose the default =E2=80=98PSID offset: 4=E2=80=99 seems = need to express in the =E2=80=98given=E2=80=99 conditions; > =20 > OK > =20 > > Q1. Have the draft stated the =E2=80=98u=E2=80=99 bits in the = Interface-ID should be 0x00? > =20 > it states that it is based on 6052. I think that should be sufficient. > =20 > cheers, > Ole > =20 > =20 From leaf.y.yeh@huawei.com Mon Jan 30 03:41:29 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A9521F86AA for ; Mon, 30 Jan 2012 03:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0923kVoywRti for ; Mon, 30 Jan 2012 03:41:28 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4083221F86B2 for ; Mon, 30 Jan 2012 03:41:28 -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 <0LYM008P50C8KX@szxga03-in.huawei.com> for softwires@ietf.org; Mon, 30 Jan 2012 19:38:32 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYM00DPK0C86C@szxga03-in.huawei.com> for softwires@ietf.org; Mon, 30 Jan 2012 19:38:32 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGP85999; Mon, 30 Jan 2012 19:38:32 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 30 Jan 2012 19:38:30 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.45]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Mon, 30 Jan 2012 19:38:27 +0800 Date: Mon, 30 Jan 2012 11:38:26 +0000 From: Leaf yeh In-reply-to: <89A006C2-B3FB-4B08-9308-2B81023D9C80@cisco.com> X-Originating-IP: [10.70.39.113] To: =?utf-8?B?T2xlIFRyw7hhbg==?= Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_xkKZUXZCQOO7Ttj3WEN07g)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: More changes to revision 03. Thread-index: AQHM22Vx2lSu+BsFOki9pMX9WA2whZYkrnvg//+FFICAAJk+0A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <705AC902-5143-42E5-841B-5B1D3348B628@cisco.com> <89A006C2-B3FB-4B08-9308-2B81023D9C80@cisco.com> Cc: softwires WG , "map-dt@external.cisco.com team" , "fine_sz@huawei.com" Subject: Re: [Softwires] More changes to revision 03. X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 11:41:29 -0000 --Boundary_(ID_xkKZUXZCQOO7Ttj3WEN07g) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 T2xlIC0gd2hhdCdzIHRoZSBkaWZmZXJlbmNlPw0KDQoNCg0KSSBzdWdnZXN0ZWQgdGhlIGZvbGxv d2luZyB0ZXh0IGZvciB0aGUgcmVhZGFibGUgLg0KDQoNCg0KR2l2ZW46DQoNCiAgICBFbmQtdXNl ciBJUHY2IHByZWZpeDogICAyMDAxOmRiODowMDEyOjM0OjovNTYNCg0KICAgIEJhc2ljIE1hcHBp bmcgUnVsZTogICAgezIwMDE6ZGI4OjAwOjovNDAgKFJ1bGUgSVB2NiBwcmVmaXgpLA0KDQogICAg ICAgICAgICAgICAgICAgICAgICAxOTIuMC4yLjAvMjQgKFJ1bGUgSVB2NCBwcmVmaXgpLA0KDQog ICAgICAgICAgICAgICAgICAgICAgICAxNiAoUnVsZSBFQS1iaXRzIGxlbmd0aCl9DQoNCiAgICBQ U0lEIG9mZnNldDogICAgICAgICAgIDQgIChkZWZhdWx0IHZhbHVlIGFzIHBlciBzZWN0aW9uIDUu MS4zKQ0KDQoNCg0KV2UgZ2V0IHRoZSBJUHY0IGFkZHJlc3MsIGl0cyBzaGFyaW5nIHJhdGlvIGFu ZCBwb3J0LXNldDoNCg0KDQoNCiAgICBFQSBiaXRzIG9mZnNldDogICAgICAgNDANCg0KICAgIElQ djQgc3VmZml4IGJpdHMgKHApOiAgICBMZW5ndGggb2YgSVB2NCBhZGRyZXNzICgzMikgLSBJUHY0 IHByZWZpeCBsZW5ndGggKDI0KSA9IDgNCg0KICAgIElQdjQgYWRkcmVzczogICAgICAgIDE5Mi4w LjIuMTggKDB4MTIpDQoNCuOAgOOAgA0KDQrjgIDjgIBTaGFyaW5nIHJhdGlvOiAgICAgICAgIDI1 NiAoMTYgLSAoMzIgLSAyNCkgPSA4LiAyXjggPSAyNTYpDQoNCg0KDQoNCg0KQ2hlZXJzLA0KDQpM ZWFmDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogT2xlIFRy w7hhbiBbbWFpbHRvOm90QGNpc2NvLmNvbV0NCg0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDMwLCAy MDEyIDY6MTYgUE0NCg0KVG86IExlYWYgeWVoDQoNCkNjOiBmaW5lX3N6QGh1YXdlaS5jb207IG1h cC1kdEBleHRlcm5hbC5jaXNjby5jb20gdGVhbQ0KDQpTdWJqZWN0OiBSZTogTW9yZSBjaGFuZ2Vz IHRvIHJldmlzaW9uIDAzLg0KDQoNCg0KTGVhZiwNCg0KDQoNCj4gQWdhaW4gQyZRcyBvbiB0aGUg ZXhhbXBsZXMgaW4gdGhlIG5ld2x5IHVwZGF0ZWQgY2FuZGlkYXRlIG9mIE1BUC0wMzoNCg0KPg0K DQo+IEEuICAgICBTZWN0aW9uIDUuMiAtIEdpdmVuOg0KDQo+ICAgIEVuZC11c2VyIElQdjYgcHJl Zml4OiAgMjAwMTpkYjg6MDAxMjozNDo6LzU2DQoNCj4gICAgQmFzaWMgTWFwcGluZyBSdWxlOiAg ICB7MjAwMTpkYjg6MDA6Oi80MCAoUnVsZSBJUHY2IHByZWZpeCksDQoNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAxOTIuMC4yLjAvMjQgKFJ1bGUgSVB2NCBwcmVmaXgpLA0KDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgMTYgKFJ1bGUgRUEtYml0cyBsZW5ndGgpfQ0KDQo+ICAgIFNo YXJpbmcgcmF0aW86ICAgICAgICAgMjU2ICgxNiAtICgzMiAtIDI0KSA9IDguIDJeOCA9IDI1NikN Cg0KPiAgICBQU0lEIG9mZnNldDogICAgICAgICAgIDQNCg0KPg0KDQo+ICAgV2UgZ2V0IElQdjQg YWRkcmVzcyBhbmQgcG9ydC1zZXQ6DQoNCj4gICAgRUEgYml0cyBvZmZzZXQ6ICAgICAgIDQwDQoN Cj4gICAgSVB2NCBzdWZmaXggYml0cyAocCk6IExlbmd0aCBvZiBJUHY0IGFkZHJlc3MgKDMyKSAt DQoNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIElQdjQgcHJlZml4IGxlbmd0aCAoMjQpID0g OA0KDQo+IOKApi4NCg0KPg0KDQo+IEMxLiBUaGUg4oCYRW5kLXVzZXIgSVB2NiBwcmVmaXjigJkg c2hhbGwgYmUgZXhwcmVzcyBhcyDigJgyMDAxOmRiODowMDEyOjM0MDA6Oi81NuKAmSBhcyBwZXIg dGhlIHNlY3Rpb24gMi4zIG9mIFJGQzQyOTE7DQoNCg0KDQpmaXhlZC4NCg0KDQoNCj4gQzIuIFRo ZSBzaGFyaW5nIHJhdGlvIHNvdW5kcyBhIGNhbGN1bGF0ZWQgcmVzdWx0LCBub3QgYSDigJhnaXZl buKAmSBjb25kaXRpb247DQoNCg0KDQp3aGF0J3MgdGhlIGRpZmZlcmVuY2U/DQoNCg0KDQoNCg0K Pg0KDQo+IEIuICAgICBTZWN0aW9uIDUuMyAtIEdpdmVuOg0KDQo+ICAgICAgIElQdjQgZGVzdGlu YXRpb24gYWRkcmVzczogMTkyLjAuMi4xOA0KDQo+ICAgICAgIElQdjQgZGVzdGluYXRpb24gcG9y dDogICAgOTAzMA0KDQo+ICAgICAgIEZvcndhcmRpbmcgTWFwcGluZyBSdWxlOiAgezIwMDE6ZGI4 OjAwOjovNDAgKFJ1bGUgSVB2NiBwcmVmaXgpLA0KDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDE5Mi4wLjIuMC8yNCAoUnVsZSBJUHY0IHByZWZpeCksDQoNCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMTYgKFJ1bGUgRUEtYml0cyBsZW5ndGgpfQ0KDQo+DQoN Cj4gICAgIFdlIGdldCBJUHY2IGFkZHJlc3M6DQoNCj4gICAgICAgSVB2NCBzdWZmaXggYml0cyAo cCk6IDMyIC0gMjQgPSA4ICgxOCAoMHgxMikpDQoNCj4gICAgICAgUFNJRCBsZW5ndGg6ICAgICAg ICAgIDgNCg0KPiAgICAgICBQU0lEOiAgICAgICAgICAgICAgICAgMHgzNCAoOTAzMCAoMHgyMzQ2 KSkNCg0KPiAgICAgICBFQSBiaXRzOiAgICAgICAgICAgICAgMHgxMjM0DQoNCj4gICAgICAgTUFQ IElQdjYgYWRkcmVzczogICAgIDIwMDE6ZGI4OjAwMTI6MzQwMDowMGMwOjAwMDI6MTIwMDozNDAw DQoNCj4NCg0KPiBDMy4gSSBzdXBwb3NlIHRoZSBkZWZhdWx0IOKAmFBTSUQgb2Zmc2V0OiA04oCZ IHNlZW1zIG5lZWQgdG8gZXhwcmVzcyBpbiB0aGUg4oCYZ2l2ZW7igJkgY29uZGl0aW9uczsNCg0K DQoNCk9LDQoNCg0KDQo+IFExLiBIYXZlIHRoZSBkcmFmdCBzdGF0ZWQgdGhlIOKAmHXigJkgYml0 cyBpbiB0aGUgSW50ZXJmYWNlLUlEIHNob3VsZCBiZSAweDAwPw0KDQoNCg0KaXQgc3RhdGVzIHRo YXQgaXQgaXMgYmFzZWQgb24gNjA1Mi4gSSB0aGluayB0aGF0IHNob3VsZCBiZSBzdWZmaWNpZW50 Lg0KDQoNCg0KY2hlZXJzLA0KDQpPbGUNCg0KDQoNCg0K --Boundary_(ID_xkKZUXZCQOO7Ttj3WEN07g) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Iue6r+aWh+acrCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KcHJlDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7 DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLn uq/mlofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r Oue6r+aWh+acrDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4u SFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8i Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTt9DQovKiBQYWdlIERlZmluaXRpb25zICovDQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0 IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls ZT0idGV4dC1qdXN0aWZ5LXRyaW06cHVuY3R1YXRpb24iPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbGUgLSB3 aGF0J3MgdGhlIGRpZmZlcmVuY2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHN1Z2dlc3Rl ZCB0aGUgZm9sbG93aW5nIHRleHQgZm9yIHRoZSByZWFkYWJsZSAuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5HaXZlbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVuZC11c2VyIElQdjYg cHJlZml4OiZuYnNwOyZuYnNwOyAyMDAxOmRiODowMDEyOjM0OjovNTY8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEJhc2ljIE1hcHBpbmcgUnVsZTombmJzcDsmbmJzcDsmbmJzcDsgezIwMDE6 ZGI4OjAwOjovNDAgKFJ1bGUgSVB2NiBwcmVmaXgpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMTkyLjAuMi4wLzI0IChSdWxlIElQdjQgcHJlZml4KSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE2IChSdWxlIEVBLWJpdHMgbGVuZ3RoKX08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7IFBTSUQgb2Zmc2V0OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0Jm5ic3A7IDxzcGFuIHN0eWxlPSJjb2xv cjpyZWQiPg0KKGRlZmF1bHQgdmFsdWUgYXMgcGVyIHNlY3Rpb24gNS4xLjMpPC9zcGFuPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+V2UgZ2V0IHRoZSBJUHY0IGFkZHJlc3MsIGl0cyBzaGFyaW5n IHJhdGlvIGFuZCBwb3J0LXNldDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw OyZuYnNwOyBFQSBiaXRzIG9mZnNldDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgNDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7ICZuYnNwO0lQdjQgc3VmZml4IGJpdHMgKHApOiAm bmJzcDsmbmJzcDsmbmJzcDtMZW5ndGggb2YgSVB2NCBhZGRyZXNzICgzMikgLSBJUHY0IHByZWZp eCBsZW5ndGggKDI0KSA9IDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7ICZuYnNwO0lQdjQgYWRkcmVz czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTkyLjAuMi4xOCAo PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+MHgxMjwvc3Bhbj4pPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9 kyI+44CA44CAPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2T O2NvbG9yOnJlZCI+44CA44CAPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 cmVkIj5TaGFyaW5nIHJhdGlvOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAyNTYgKDE2IC0gKDMyIC0gMjQpID0gOC4gMl44ID0gMjU2KTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+TGVhZjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPkZyb206IE9sZSBUcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7DuDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+YW4gW21haWx0bzpvdEBjaXNjby5jb21dDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+U2VudDogTW9u ZGF5LCBKYW51YXJ5IDMwLCAyMDEyIDY6MTYgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VG86IExlYWYgeWVoPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t VVMiPkNjOiBmaW5lX3N6QGh1YXdlaS5jb207IG1hcC1kdEBleHRlcm5hbC5jaXNjby5jb20gdGVh bTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5TdWJqZWN0OiBSZTogTW9yZSBjaGFuZ2VzIHRvIHJldmlzaW9uIDAzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+TGVhZiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg QWdhaW4gQyZhbXA7UXMgb24gdGhlIGV4YW1wbGVzIGluIHRoZSBuZXdseSB1cGRhdGVkIGNhbmRp ZGF0ZSBvZiBNQVAtMDM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgQS4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VjdGlvbiA1LjIgLSBHaXZlbjo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBFbmQtdXNlciBJUHY2IHByZWZpeDombmJzcDsgMjAwMTpkYjg6MDAx MjozNDo6LzU2PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQmFzaWMgTWFwcGluZyBS dWxlOiZuYnNwOyZuYnNwOyZuYnNwOyB7MjAwMTpkYjg6MDA6Oi80MCAoUnVsZSBJUHY2IHByZWZp eCksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgMTkyLjAuMi4wLzI0IChSdWxlIElQdjQgcHJlZml4KSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxNiAoUnVsZSBFQS1iaXRzIGxlbmd0 aCl9PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgU2hhcmluZyByYXRpbzombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjU2ICgxNiAtICgzMiAt IDI0KSA9IDguIDJeOCA9IDI1Nik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBQU0lE IG9mZnNldDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7Jm5i c3A7IFdlIGdldCBJUHY0IGFkZHJlc3MgYW5kIHBvcnQtc2V0OjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEVBIGJpdHMgb2Zmc2V0OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA0MDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElQdjQgc3VmZml4IGJp dHMgKHApOiBMZW5ndGggb2YgSVB2NCBhZGRyZXNzICgzMikgLTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElQdjQgcHJlZml4IGxlbmd0aCAoMjQpID0g ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igKY8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi Pi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBDMS4gVGhlIDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij7igJg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPkVuZC11c2VyIElQdjYgcHJlZml4PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPuKAmTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+IHNoYWxsIGJlDQogZXhwcmVzcyBh cyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+4oCYPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4yMDAxOmRiODowMDEy OjM0MDA6Oi81Njwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiBhcyBw ZXIgdGhlIHNlY3Rpb24gMi4zIG9mIFJGQzQyOTE7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5m aXhlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgQzIuIFRoZSBzaGFyaW5nIHJhdGlv IHNvdW5kcyBhIGNhbGN1bGF0ZWQgcmVzdWx0LCBub3QgYQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAmDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+Z2l2ZW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCZPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj4gY29uZGl0aW9uOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+d2hhdCdzIHRo ZSBkaWZmZXJlbmNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZn dDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgQi4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VjdGlv biA1LjMgLSBHaXZlbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBJUHY0IGRlc3RpbmF0aW9uIGFkZHJlc3M6IDE5Mi4wLjIuMTg8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJUHY0IGRlc3RpbmF0aW9uIHBv cnQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7IDkwMzA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBGb3J3YXJkaW5nIE1hcHBpbmcgUnVsZTombmJzcDsgezIwMDE6 ZGI4OjAwOjovNDAgKFJ1bGUgSVB2NiBwcmVmaXgpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDE5Mi4wLjIuMC8yNCAoUnVsZSBJUHY0IHByZWZpeCksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTYgKFJ1bGUgRUEtYml0cyBsZW5ndGgp fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFdlIGdldCBJUHY2IGFkZHJlc3M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSVB2NCBzdWZmaXggYml0cyAocCk6IDMyIC0gMjQgPSA4ICgxOCAo MHgxMikpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 UFNJRCBsZW5ndGg6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBQU0lEOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAweDM0ICg5 MDMwICgweDIzNDYpKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEVBIGJpdHM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDB4MTIzNDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1BUCBJUHY2IGFkZHJlc3M6Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIwMDE6ZGI4OjAwMTI6MzQwMDowMGMwOjAwMDI6MTIwMDoz NDAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDsmbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgQzMuIEkgc3VwcG9zZSB0aGUg ZGVmYXVsdCA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+4oCYPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5QU0lEIG9m ZnNldDogNDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KIHNlZW1z IG5lZWQgdG8gZXhwcmVzcyBpbiB0aGUgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPuKAmDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+Z2l2ZW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCZPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4g Y29uZGl0aW9uczs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9LPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mZ3Q7IFExLiBIYXZlIHRoZSBkcmFmdCBzdGF0ZWQgdGhlIDwvc3Bhbj4NCjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PuKAmDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+dTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJk8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPiBiaXRzIGluIHRoZSBJbnRlcmZhY2UtSUQgc2hvdWxkIGJlIDB4MDA/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5pdCBzdGF0ZXMgdGhhdCBpdCBpcyBiYXNlZCBvbiA2 MDUyLiBJIHRoaW5rIHRoYXQgc2hvdWxkIGJlIHN1ZmZpY2llbnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj5jaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9sZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --Boundary_(ID_xkKZUXZCQOO7Ttj3WEN07g)-- From rajiva@cisco.com Mon Jan 30 05:20:35 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2010B21F86C8 for ; Mon, 30 Jan 2012 05:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.316 X-Spam-Level: X-Spam-Status: No, score=-5.316 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hf1zdlO70EQm for ; Mon, 30 Jan 2012 05:20:34 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD0421F86C6 for ; Mon, 30 Jan 2012 05:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2230; q=dns/txt; s=iport; t=1327929634; x=1329139234; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=21dGj0EDl8JRe9CAcftUD9i80UHx44UzEWHY2/i5MDw=; b=G3auBWhW49+XIR6GnSs04jTctdxVxoiWQcxdFJfvSUoBwFuqg0dICi5t H7NB5BaUxiOIjCXwAVUEdSjYdgOvtGZvgmll15ihIh6hEt/ICTPRio3lB pKMFK7Fn0iPD2amme1qkItvSqzY3h66V+7fFCAurOoY90JrZ77g9i+Spt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4HAF+YJk+tJXG//2dsb2JhbABDhQuoWHICgQWBcgEBAQMBAQEBDwEQETMHCwULAgEIGgImAgICJTABAQQTGweHWgmaHwGMYZE1gS+HDwEnAwQ1AQUIB4J/AxUCCwMCgzkzYwSVGpJR X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="54833315" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jan 2012 13:20:33 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0UDKXHH009150; Mon, 30 Jan 2012 13:20:33 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 07:20:34 -0600 Received: from 72.163.43.38 ([72.163.43.38]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Mon, 30 Jan 2012 13:20:34 +0000 References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> Content-Transfer-Encoding: base64 From: "Rajiv Asati (rajiva)" Content-Type: text/plain; charset="utf-8" Thread-Topic: [Softwires] MAP documents - next steps Thread-Index: AczfUfJIfyEu5y5XQZOl6s/0KLh1iA== In-Reply-To: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> Message-ID: <7CBB29AF-0670-4471-B10C-C53FB63C5B5C@cisco.com> Date: Mon, 30 Jan 2012 12:39:41 +0000 To: =?UTF-8?B?T2xlIFRyw7hhbg==?= MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 30 Jan 2012 13:20:34.0316 (UTC) FILETIME=[F2A534C0:01CCDF51] Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 13:20:35 -0000 WWVzLiBJIHN1cHBvcnQgV0cgYWRvcHRpb24gKGFuZCBjYXJyeSBvbiB0aGUgZGlzY3Vzc2lvbiBm dXJ0aGVyKS4NCg0KQ2hlZXJzLA0KUmFqaXYNCg0KU2VudCBmcm9tIG15IFBob25lDQoNCk9uIEph biAzMCwgMjAxMiwgYXQgMTE6MzEgQU0sIE9sZSBUcsO4YW4gPG90cm9hbkBlbXBsb3llZXMub3Jn PiB3cm90ZToNCg0KPiBoaSwNCj4gDQo+IHRoZSBNQVAgKE1hcHBpbmcgb2YgYWRkcmVzcyBhbmQg cG9ydCkgZGVzaWduIHRlYW0gaGFzIG5vdyB3cml0dGVuIGFuZCBwdWJsaXNoZWQgdGhlIGZvbGxv d2luZyBzZXRzIG9mIGRyYWZ0cy4NCj4gDQo+IHRoZSBiYXNlIGRvY3VtZW50IChwb3J0IG1hcHBp bmcgYWxnb3JpdGhtKToNCj4gIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1kdC1z b2Z0d2lyZS1tYXBwaW5nLWFkZHJlc3MtYW5kLXBvcnQtMDMNCj4gIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWR0LXNvZnR3aXJlLW1hcHBpbmctYWRkcmVzcy1hbmQt cG9ydC0wMy50eHQNCj4gDQo+IHRoZSBlbmNhcHN1bGF0aW9uIGRvY3VtZW50IChNQVAtRSk6DQo+ ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tZHQtc29mdHdpcmUtbWFwLWVuY2Fw c3VsYXRpb24tMDANCj4gDQo+IHRoZSB0cmFuc2xhdGlvbiBkb2N1bWVudCAoTUFQLVQpOg0KPiAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWR0LXNvZnR3aXJlLW1hcC10cmFuc2xh dGlvbi0wMA0KPiANCj4gdGhlIERIQ1Agb3B0aW9uIChNQVAtREhDUCk6DQo+ICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tZHQtc29mdHdpcmUtbWFwLWRoY3Atb3B0aW9uLTAyDQo+ IA0KPiB0aGVyZSBpcyBhIE1BUCBkZXBsb3ltZW50IGRvY3VtZW50IGNvbWluZyBzb29uLg0KPiAN Cj4gdGhlIHNvbHV0aW9uIGRlc2NyaWJlZCBpbiB0aGlzIHNldCBvZiBkb2N1bWVudHMsIGFyZSB3 cml0dGVuIHRvIHNhdGlzZnkgdGhlIGZvbGxvd2luZyBmcm9tIHRoZSBzb2Z0d2lyZXMgY2hhcnRl cjoNCj4gICA0LiBEZXZlbG9wbWVudHMgZm9yIHN0YXRlbGVzcyBsZWdhY3kgSVB2NCBjYXJyaWVk IG92ZXIgSVB2NiANCj4gICAgICAtIGRldmVsb3AgYSBzb2x1dGlvbiBtb3RpdmF0aW9uIGRvY3Vt ZW50IHRvIGJlIHB1Ymxpc2hlZCBhcyBhbiBSRkMgDQo+ICAgICAgLSBkZXZlbG9wIGEgcHJvdG9j b2wgc3BlY2lmaWNhdGlvbiByZXNwb25zZSB0byB0aGUgc29sdXRpb24gDQo+ICAgICAgICBtb3Rp dmF0aW9uIGRvY3VtZW50OyB0aGlzIHdvcmsgaXRlbSB3aWxsIG5vdCBiZSB0YWtlbiB0aHJvdWdo IA0KPiANCj4gaW4gdGhlIGRlc2lnbiB0ZWFtJ3MgdmlldywgdGhpcyBzZXQgb2YgZG9jdW1lbnRz IGFyZSByZWFkeSB0byBiZSBhZG9wdGVkIGFzIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnRzLg0KPiAN Cj4gY29tbWVudHM/DQo+IA0KPiBmb3IgdGhlIE1BUCBkZXNpZ24gdGVhbSwNCj4gT2xlDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNvZnR3aXJl cyBtYWlsaW5nIGxpc3QNCj4gU29mdHdpcmVzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQo= From tomasz.mrugalski@gmail.com Mon Jan 30 11:15:55 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6693921F8543 for ; Mon, 30 Jan 2012 11:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmHq0ixeRQT4 for ; Mon, 30 Jan 2012 11:15:54 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 69DEC21F8540 for ; Mon, 30 Jan 2012 11:15:54 -0800 (PST) Received: by wicr5 with SMTP id r5so4287363wic.31 for ; Mon, 30 Jan 2012 11:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=KTRiX1q3eWSHST59yUsGs1ryZ0u7OcrEKqXM8vrGfkQ=; b=v/cmTAX8um74t1ZpE/P0MLHuYEdomXJOfdOzpxP4w2dTobSjMuKZNLX3/f4f+ujwgK sBC/1xaJjYlyrEAoW4kJpCJ6rEEz0FE42tAqUkmvxj6sxW6Kccth0Iw1aLPB1Lt/iTV4 eURR9IOLtZz2Ct+1LaU7gMo1UotQjTx3yuwSw= Received: by 10.180.77.200 with SMTP id u8mr29504545wiw.18.1327950953534; Mon, 30 Jan 2012 11:15:53 -0800 (PST) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id bj10sm32270956wib.9.2012.01.30.11.15.51 (version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 11:15:52 -0800 (PST) Message-ID: <4F26EC65.2010804@gmail.com> Date: Mon, 30 Jan 2012 20:15:49 +0100 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: softwires@ietf.org References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> <7CBB29AF-0670-4471-B10C-C53FB63C5B5C@cisco.com> In-Reply-To: <7CBB29AF-0670-4471-B10C-C53FB63C5B5C@cisco.com> X-TagToolbar-Keys: D20120130201549199 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 19:15:55 -0000 On 30.01.2012 13:39, Rajiv Asati (rajiva) wrote: > Yes. I support WG adoption (and carry on the discussion further). For what it is worth, I support WG adoption. Cheers, Tomek MAP design team member, map-dhcp editor > On Jan 30, 2012, at 11:31 AM, Ole Trøan wrote: > >> hi, >> >> the MAP (Mapping of address and port) design team has now written and published the following sets of drafts. >> >> the base document (port mapping algorithm): >> http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03 >> http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-mapping-address-and-port-03.txt >> >> the encapsulation document (MAP-E): >> http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 >> >> the translation document (MAP-T): >> http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 >> >> the DHCP option (MAP-DHCP): >> http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02 >> >> there is a MAP deployment document coming soon. >> >> the solution described in this set of documents, are written to satisfy the following from the softwires charter: >> 4. Developments for stateless legacy IPv4 carried over IPv6 >> - develop a solution motivation document to be published as an RFC >> - develop a protocol specification response to the solution >> motivation document; this work item will not be taken through >> >> in the design team's view, this set of documents are ready to be adopted as working group documents. >> >> comments? >> >> for the MAP design team, >> Ole >> _______________________________________________ >> 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 rajiva@cisco.com Mon Jan 30 14:26:07 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EE111E80C7 for ; Mon, 30 Jan 2012 14:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k444nTdVI3q for ; Mon, 30 Jan 2012 14:26:05 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E077911E80C2 for ; Mon, 30 Jan 2012 14:26:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5486; q=dns/txt; s=iport; t=1327962365; x=1329171965; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=sDeBKyja8hmsobNNfT3tvnOQRMCgSC70nG3ehUYykJo=; b=fie3PTpZQVSogIi0Jn5lFZ6KuTLJTyQszvYV1gteZxCb8XmjOhXAM5Fy 3HGl8r9v9o1LV/U3QONKUia08YTYw+L64VpjBW08Fbm5D5eNOqAxrD90g FvdPBdXfmqTzE7jowM01ho7pu4nPLubjYIbiG+xbtZ3tnVYl0w+zF3I/3 U=; X-IronPort-AV: E=Sophos;i="4.71,591,1320624000"; d="scan'208";a="52374108" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 30 Jan 2012 22:26:04 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q0UMQ4wh027800; Mon, 30 Jan 2012 22:26:04 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 16:26:04 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 30 Jan 2012 16:26:04 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C073C63F7@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More changes to revision 03. Thread-Index: AQHM22Vx2lSu+BsFOki9pMX9WA2whZYkrnvg//+FFICAAJk+0IAAdkuQ From: "Rajiv Asati (rajiva)" To: "Leaf yeh" , =?utf-8?B?T2xlIFRyw7hhbg==?= X-OriginalArrivalTime: 30 Jan 2012 22:26:04.0779 (UTC) FILETIME=[278583B0:01CCDF9E] Cc: softwires WG , map-dt@external.cisco.com, fine_sz@huawei.com Subject: Re: [Softwires] More changes to revision 03. X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:26:07 -0000 PiBDMi4gVGhlIHNoYXJpbmcgcmF0aW8gc291bmRzIGEgY2FsY3VsYXRlZCByZXN1bHQsIG5vdCBh IOKAmGdpdmVu4oCZIGNvbmRpdGlvbjsNCg0KSSB3b3VsZCB2ZXJ5IG11Y2ggZmF2b3IgaGF2aW5n IGEgc2hhcmluZyByYXRpbyBhcyBhICdnaXZlbicgdmFyaWFibGUsIGluc3RlYWQgb2YgYSBjYWxj dWxhdGVkIHJlc3VsdCAoYW5kIGluc3RlYWQgb2YgRUEtYml0IGxlbmd0aCwgaWYgbmVlZGVkIGJl KSBzaW5jZSBpdCBpcyBlYXNpZXIgdG8gdW5kZXJzdGFuZCwgZXhwbGFpbiBhbmQgd29yayBpdCBv dXQuDQoNCkluIGZhY3QsIG1vc3Qgb2YgdGhlIGV4YW1wbGVzIGluY2x1ZGVkIGluIHRoZSBkb2N1 bWVudCBzaG93IHRoZSBzaGFyaW5nLXJhdGlvIGJlaW5nIHVzZWQgYXMgYSBnaXZlbiB2YXJpYWJs ZSwgc28gd2UganVzdCBuZWVkIHRvIHVwZGF0ZSB0aGUgcnVsZXMuDQoJDQpDaGVlcnMsDQpSYWpp dg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc29mdHdpcmVzLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4g QmVoYWxmIE9mIExlYWYgeWVoDQo+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAzMCwgMjAxMiA2OjM4 IEFNDQo+IFRvOiBPbGUgVHLDuGFuDQo+IENjOiBzb2Z0d2lyZXMgV0c7IG1hcC1kdEBleHRlcm5h bC5jaXNjby5jb20gdGVhbTsgZmluZV9zekBodWF3ZWkuY29tDQo+IFN1YmplY3Q6IFJlOiBbU29m dHdpcmVzXSBNb3JlIGNoYW5nZXMgdG8gcmV2aXNpb24gMDMuDQo+IA0KPiBPbGUgLSB3aGF0J3Mg dGhlIGRpZmZlcmVuY2U/DQo+IA0KPiANCj4gDQo+IEkgc3VnZ2VzdGVkIHRoZSBmb2xsb3dpbmcg dGV4dCBmb3IgdGhlIHJlYWRhYmxlIC4NCj4gDQo+IA0KPiANCj4gR2l2ZW46DQo+IA0KPiAgICAg RW5kLXVzZXIgSVB2NiBwcmVmaXg6ICAgMjAwMTpkYjg6MDAxMjozNDo6LzU2DQo+IA0KPiAgICAg QmFzaWMgTWFwcGluZyBSdWxlOiAgICB7MjAwMTpkYjg6MDA6Oi80MCAoUnVsZSBJUHY2IHByZWZp eCksDQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAxOTIuMC4yLjAvMjQgKFJ1bGUgSVB2 NCBwcmVmaXgpLA0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgMTYgKFJ1bGUgRUEtYml0 cyBsZW5ndGgpfQ0KPiANCj4gICAgIFBTSUQgb2Zmc2V0OiAgICAgICAgICAgNCAgKGRlZmF1bHQg dmFsdWUgYXMgcGVyIHNlY3Rpb24gNS4xLjMpDQo+IA0KPiANCj4gDQo+IFdlIGdldCB0aGUgSVB2 NCBhZGRyZXNzLCBpdHMgc2hhcmluZyByYXRpbyBhbmQgcG9ydC1zZXQ6DQo+IA0KPiANCj4gDQo+ ICAgICBFQSBiaXRzIG9mZnNldDogICAgICAgNDANCj4gDQo+ICAgICBJUHY0IHN1ZmZpeCBiaXRz IChwKTogICAgTGVuZ3RoIG9mIElQdjQgYWRkcmVzcyAoMzIpIC0gSVB2NCBwcmVmaXggbGVuZ3Ro ICgyNCkgPSA4DQo+IA0KPiAgICAgSVB2NCBhZGRyZXNzOiAgICAgICAgMTkyLjAuMi4xOCAoMHgx MikNCj4gDQo+IA0KPiANCj4g44CA44CAU2hhcmluZyByYXRpbzogICAgICAgICAyNTYgKDE2IC0g KDMyIC0gMjQpID0gOC4gMl44ID0gMjU2KQ0KPiANCj4gDQo+IA0KPiANCj4gDQo+IENoZWVycywN Cj4gDQo+IExlYWYNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiANCj4gRnJvbTogT2xlIFRyw7hhbiBbbWFpbHRvOm90QGNpc2NvLmNvbV0NCj4gDQo+ IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAzMCwgMjAxMiA2OjE2IFBNDQo+IA0KPiBUbzogTGVhZiB5 ZWgNCj4gDQo+IENjOiBmaW5lX3N6QGh1YXdlaS5jb207IG1hcC1kdEBleHRlcm5hbC5jaXNjby5j b20gdGVhbQ0KPiANCj4gU3ViamVjdDogUmU6IE1vcmUgY2hhbmdlcyB0byByZXZpc2lvbiAwMy4N Cj4gDQo+IA0KPiANCj4gTGVhZiwNCj4gDQo+IA0KPiANCj4gPiBBZ2FpbiBDJlFzIG9uIHRoZSBl eGFtcGxlcyBpbiB0aGUgbmV3bHkgdXBkYXRlZCBjYW5kaWRhdGUgb2YgTUFQLTAzOg0KPiANCj4g Pg0KPiANCj4gPiBBLiAgICAgU2VjdGlvbiA1LjIgLSBHaXZlbjoNCj4gDQo+ID4gICAgRW5kLXVz ZXIgSVB2NiBwcmVmaXg6ICAyMDAxOmRiODowMDEyOjM0OjovNTYNCj4gDQo+ID4gICAgQmFzaWMg TWFwcGluZyBSdWxlOiAgICB7MjAwMTpkYjg6MDA6Oi80MCAoUnVsZSBJUHY2IHByZWZpeCksDQo+ IA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgMTkyLjAuMi4wLzI0IChSdWxlIElQdjQg cHJlZml4KSwNCj4gDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAxNiAoUnVsZSBFQS1i aXRzIGxlbmd0aCl9DQo+IA0KPiA+ICAgIFNoYXJpbmcgcmF0aW86ICAgICAgICAgMjU2ICgxNiAt ICgzMiAtIDI0KSA9IDguIDJeOCA9IDI1NikNCj4gDQo+ID4gICAgUFNJRCBvZmZzZXQ6ICAgICAg ICAgICA0DQo+IA0KPiA+DQo+IA0KPiA+ICAgV2UgZ2V0IElQdjQgYWRkcmVzcyBhbmQgcG9ydC1z ZXQ6DQo+IA0KPiA+ICAgIEVBIGJpdHMgb2Zmc2V0OiAgICAgICA0MA0KPiANCj4gPiAgICBJUHY0 IHN1ZmZpeCBiaXRzIChwKTogTGVuZ3RoIG9mIElQdjQgYWRkcmVzcyAoMzIpIC0NCj4gDQo+ID4g ICAgICAgICAgICAgICAgICAgICAgICAgIElQdjQgcHJlZml4IGxlbmd0aCAoMjQpID0gOA0KPiAN Cj4gPiDigKYuDQo+IA0KPiA+DQo+IA0KPiA+IEMxLiBUaGUg4oCYRW5kLXVzZXIgSVB2NiBwcmVm aXjigJkgc2hhbGwgYmUgZXhwcmVzcyBhcyDigJgyMDAxOmRiODowMDEyOjM0MDA6Oi81NuKAmQ0K PiBhcyBwZXIgdGhlIHNlY3Rpb24gMi4zIG9mIFJGQzQyOTE7DQo+IA0KPiANCj4gDQo+IGZpeGVk Lg0KPiANCj4gDQo+IA0KPiA+IEMyLiBUaGUgc2hhcmluZyByYXRpbyBzb3VuZHMgYSBjYWxjdWxh dGVkIHJlc3VsdCwgbm90IGEg4oCYZ2l2ZW7igJkgY29uZGl0aW9uOw0KPiANCj4gDQo+IA0KPiB3 aGF0J3MgdGhlIGRpZmZlcmVuY2U/DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gPg0KPiANCj4gPiBC LiAgICAgU2VjdGlvbiA1LjMgLSBHaXZlbjoNCj4gDQo+ID4gICAgICAgSVB2NCBkZXN0aW5hdGlv biBhZGRyZXNzOiAxOTIuMC4yLjE4DQo+IA0KPiA+ICAgICAgIElQdjQgZGVzdGluYXRpb24gcG9y dDogICAgOTAzMA0KPiANCj4gPiAgICAgICBGb3J3YXJkaW5nIE1hcHBpbmcgUnVsZTogIHsyMDAx OmRiODowMDo6LzQwIChSdWxlIElQdjYgcHJlZml4KSwNCj4gDQo+ID4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgMTkyLjAuMi4wLzI0IChSdWxlIElQdjQgcHJlZml4KSwNCj4gDQo+ ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTYgKFJ1bGUgRUEtYml0cyBsZW5n dGgpfQ0KPiANCj4gPg0KPiANCj4gPiAgICAgV2UgZ2V0IElQdjYgYWRkcmVzczoNCj4gDQo+ID4g ICAgICAgSVB2NCBzdWZmaXggYml0cyAocCk6IDMyIC0gMjQgPSA4ICgxOCAoMHgxMikpDQo+IA0K PiA+ICAgICAgIFBTSUQgbGVuZ3RoOiAgICAgICAgICA4DQo+IA0KPiA+ICAgICAgIFBTSUQ6ICAg ICAgICAgICAgICAgICAweDM0ICg5MDMwICgweDIzNDYpKQ0KPiANCj4gPiAgICAgICBFQSBiaXRz OiAgICAgICAgICAgICAgMHgxMjM0DQo+IA0KPiA+ICAgICAgIE1BUCBJUHY2IGFkZHJlc3M6ICAg ICAyMDAxOmRiODowMDEyOjM0MDA6MDBjMDowMDAyOjEyMDA6MzQwMA0KPiANCj4gPg0KPiANCj4g PiBDMy4gSSBzdXBwb3NlIHRoZSBkZWZhdWx0IOKAmFBTSUQgb2Zmc2V0OiA04oCZIHNlZW1zIG5l ZWQgdG8gZXhwcmVzcyBpbiB0aGUg4oCYZ2l2ZW7igJkNCj4gY29uZGl0aW9uczsNCj4gDQo+IA0K PiANCj4gT0sNCj4gDQo+IA0KPiANCj4gPiBRMS4gSGF2ZSB0aGUgZHJhZnQgc3RhdGVkIHRoZSDi gJh14oCZIGJpdHMgaW4gdGhlIEludGVyZmFjZS1JRCBzaG91bGQgYmUgMHgwMD8NCj4gDQo+IA0K PiANCj4gaXQgc3RhdGVzIHRoYXQgaXQgaXMgYmFzZWQgb24gNjA1Mi4gSSB0aGluayB0aGF0IHNo b3VsZCBiZSBzdWZmaWNpZW50Lg0KPiANCj4gDQo+IA0KPiBjaGVlcnMsDQo+IA0KPiBPbGUNCj4g DQo+IA0KPiANCj4gDQoNCg== From jiangsheng@huawei.com Mon Jan 30 18:32:59 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33DB21F8513 for ; Mon, 30 Jan 2012 18:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.06 X-Spam-Level: X-Spam-Status: No, score=-6.06 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykK2H6rm9ADb for ; Mon, 30 Jan 2012 18:32:59 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 096D521F8512 for ; Mon, 30 Jan 2012 18:32:59 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYN00KMA5QRNB@szxga05-in.huawei.com> for softwires@ietf.org; Tue, 31 Jan 2012 10:32:51 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYN00FS85QRKB@szxga05-in.huawei.com> for softwires@ietf.org; Tue, 31 Jan 2012 10:32:51 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGQ29024; Tue, 31 Jan 2012 10:32:03 +0800 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jan 2012 10:31:42 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.236]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Tue, 31 Jan 2012 10:32:14 +0800 Date: Tue, 31 Jan 2012 02:32:00 +0000 From: Sheng Jiang In-reply-to: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> X-Originating-IP: [10.108.4.88] To: =?iso-8859-1?Q?Ole_Tr=F8an?= , softwires WG Message-id: <5D36713D8A4E7348A7E10DF7437A4B92185A9E61@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [Softwires] MAP documents - next steps Thread-index: AQHM30LEZSO+XkBctUeRjik6fMX3WZYloRIw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 02:32:59 -0000 I support WG adoption for this series of documents. As a complementarity, we have written a MAP Radius document: "RADIUS Attribute for MAP" http://tools.ietf.org/html/draft-jiang-softwire-map-radius-00 This document defines Radius attribute for MAP mechanism. It provides just enough information to form the correspondent DHCPv6 MAP option on BNG. Best regards, Sheng > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Ole Tr?an > Sent: Monday, January 30, 2012 7:32 PM > To: softwires WG > Subject: [Softwires] MAP documents - next steps > > hi, > > the MAP (Mapping of address and port) design team has now written and > published the following sets of drafts. > > the base document (port mapping algorithm): > http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and- > port-03 > http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-mapping- > address-and-port-03.txt > > the encapsulation document (MAP-E): > http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 > > the translation document (MAP-T): > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 > > the DHCP option (MAP-DHCP): > http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02 > > there is a MAP deployment document coming soon. > > the solution described in this set of documents, are written to satisfy > the following from the softwires charter: > 4. Developments for stateless legacy IPv4 carried over IPv6 > - develop a solution motivation document to be published as an > RFC > - develop a protocol specification response to the solution > motivation document; this work item will not be taken through > > in the design team's view, this set of documents are ready to be > adopted as working group documents. > > comments? > > for the MAP design team, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Tina.Tsou.Zouting@huawei.com Mon Jan 30 21:55:14 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40FD21F8627 for ; Mon, 30 Jan 2012 21:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1utv2LaKLl9M for ; Mon, 30 Jan 2012 21:55:13 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 338F621F8625 for ; Mon, 30 Jan 2012 21:55:13 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYN00HAYF39V8@szxga05-in.huawei.com> for softwires@ietf.org; Tue, 31 Jan 2012 13:54:45 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYN00F7DF384Z@szxga05-in.huawei.com> for softwires@ietf.org; Tue, 31 Jan 2012 13:54:45 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGQ47617; Tue, 31 Jan 2012 13:54:45 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jan 2012 13:54:17 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Tue, 31 Jan 2012 13:54:24 +0800 Date: Tue, 31 Jan 2012 05:54:23 +0000 From: Tina TSOU In-reply-to: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> X-Originating-IP: [10.212.246.47] To: =?iso-8859-1?Q?Ole_Tr=F8an?= , softwires WG Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [Softwires] MAP documents - next steps Thread-index: AQHM30LDofe4jTvGEUWGWdY/dXcKWZYl+Pow X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 05:55:14 -0000 Tina > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Ole Tr?an > Sent: Monday, January 30, 2012 3:32 AM > To: softwires WG > Subject: [Softwires] MAP documents - next steps > > hi, > > the MAP (Mapping of address and port) design team has now written and > published the following sets of drafts. > > the base document (port mapping algorithm): > http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port- > 03 > http://tools.ietf.org/rfcdiff?url2=draft-mdt-softwire-mapping-address- > and-port-03.txt > > the encapsulation document (MAP-E): > http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 > > the translation document (MAP-T): > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 > > the DHCP option (MAP-DHCP): > http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02 > > there is a MAP deployment document coming soon. Support. And there is a "port set algorithms analysis" document was discussed and decided targeting for an informational RFC to justify the MAP algorithm. The document was written, just a matter of forming into I-D form now. It is coming soon as well, and requires the same treatment as in the same set. > > the solution described in this set of documents, are written to satisfy > the following from the softwires charter: > 4. Developments for stateless legacy IPv4 carried over IPv6 > - develop a solution motivation document to be published as an RFC > - develop a protocol specification response to the solution > motivation document; this work item will not be taken through > > in the design team's view, this set of documents are ready to be adopted > as working group documents. > > comments? > > for the MAP design team, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From wdec.ietf@gmail.com Mon Jan 30 23:13:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBAC21F875D for ; Mon, 30 Jan 2012 23:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aoyClUNpS5M for ; Mon, 30 Jan 2012 23:13:05 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D448321F875A for ; Mon, 30 Jan 2012 23:13:04 -0800 (PST) Received: by qcsg13 with SMTP id g13so166816qcs.31 for ; Mon, 30 Jan 2012 23:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bkOIITI7QUyIbEP2/KrdyGNvB7M8oTQ61qUCFkUtm4U=; b=EQCu+EPy2GJ6jOG0nPUXqqjxpEB+AH/Ga6q7WU03Bcn84F5NMMvqZjgwgnCMjDJp9L SBtaucRTyUkuSuA0cKp6GfdSLmWq+FwJ09bzmq8p/5pBd6q7aNkOMucgCtuYdD3WM4Tc w8YU0FaTijPn7orIRrnONu/jlBsXaOdIvCjZ4= MIME-Version: 1.0 Received: by 10.224.203.67 with SMTP id fh3mr26462050qab.13.1327993984352; Mon, 30 Jan 2012 23:13:04 -0800 (PST) Received: by 10.229.237.194 with HTTP; Mon, 30 Jan 2012 23:13:04 -0800 (PST) In-Reply-To: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> Date: Tue, 31 Jan 2012 08:13:04 +0100 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/alternative; boundary=20cf300fb08db3803204b7cdb142 Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 07:13:05 -0000 --20cf300fb08db3803204b7cdb142 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support On 30 January 2012 12:31, Ole Tr=F8an wrote: > hi, > > the MAP (Mapping of address and port) design team has now written and > published the following sets of drafts. > > the base document (port mapping algorithm): > http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-0= 3 > > http://tools.ietf.org/rfcdiff?url2=3Ddraft-mdt-softwire-mapping-address-a= nd-port-03.txt > > the encapsulation document (MAP-E): > http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 > > the translation document (MAP-T): > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 > > the DHCP option (MAP-DHCP): > http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02 > > there is a MAP deployment document coming soon. > > the solution described in this set of documents, are written to satisfy > the following from the softwires charter: > 4. Developments for stateless legacy IPv4 carried over IPv6 > - develop a solution motivation document to be published as an RFC > - develop a protocol specification response to the solution > motivation document; this work item will not be taken through > > in the design team's view, this set of documents are ready to be adopted > as working group documents. > > comments? > > for the MAP design team, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf300fb08db3803204b7cdb142 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support

On 30 January 2012 12:31, Ole Tr= =F8an <otroan@= employees.org> wrote:
hi,

the MAP (Mapping of address and port) design team has now written and publi= shed the following sets of drafts.

the base document (port mapping algorithm):
=A0http://tools.ietf.org/html/draft-mdt-softw= ire-mapping-address-and-port-03
=A0http://tools.ietf.org/rfcdif= f?url2=3Ddraft-mdt-softwire-mapping-address-and-port-03.txt

the encapsulation document (MAP-E):
=A0http://tools.ietf.org/html/draft-mdt-softwire-map= -encapsulation-00

the translation document (MAP-T):
=A0http://tools.ietf.org/html/draft-mdt-softwire-map-t= ranslation-00

the DHCP option (MAP-DHCP):
=A0http://tools.ietf.org/html/draft-mdt-softwire-map-d= hcp-option-02

there is a MAP deployment document coming soon.

the solution described in this set of documents, are written to satisfy the= following from the softwires charter:
=A0 4. Developments for stateless legacy IPv4 carried over IPv6
=A0 =A0 =A0- develop a solution motivation document to be published as an = RFC
=A0 =A0 =A0- develop a protocol specification response to the solution
=A0 =A0 =A0 =A0motivation document; this work item will not be taken throu= gh

in the design team's view, this set of documents are ready to be adopte= d as working group documents.

comments?

for the MAP design team,
Ole
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf300fb08db3803204b7cdb142-- From tetsuya@ipinfusion.com Tue Jan 31 00:19:12 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD5C21F8713 for ; Tue, 31 Jan 2012 00:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCSiJN4GuvkM for ; Tue, 31 Jan 2012 00:19:11 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B438E21F84CF for ; Tue, 31 Jan 2012 00:19:11 -0800 (PST) Received: by pbdy7 with SMTP id y7so454896pbd.31 for ; Tue, 31 Jan 2012 00:19:11 -0800 (PST) Received: by 10.68.141.111 with SMTP id rn15mr48064220pbb.76.1327997951372; Tue, 31 Jan 2012 00:19:11 -0800 (PST) Received: from [192.168.0.6] (c-76-102-170-31.hsd1.ca.comcast.net. [76.102.170.31]) by mx.google.com with ESMTPS id w4sm46301224pbf.4.2012.01.31.00.19.06 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jan 2012 00:19:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Tetsuya Murakami In-Reply-To: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> Date: Tue, 31 Jan 2012 00:19:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <257A0EE4-C5D0-45C4-A7FB-B38EDD81B759@ipinfusion.com> References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> To: =?utf-8?Q?Ole_Tr=C3=B8an?= X-Mailer: Apple Mail (2.1251.1) Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 08:19:12 -0000 Support. It is worth to adopt these drafts as WG drafts. Thanks, Tetsuya On 2012/01/30, at 3:31, Ole Tr=C3=B8an wrote: > hi, >=20 > the MAP (Mapping of address and port) design team has now written and = published the following sets of drafts. >=20 > the base document (port mapping algorithm): > = http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03 > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-mdt-softwire-mapping-address-an= d-port-03.txt >=20 > the encapsulation document (MAP-E): > http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 >=20 > the translation document (MAP-T): > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 >=20 > the DHCP option (MAP-DHCP): > http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02 >=20 > there is a MAP deployment document coming soon. >=20 > the solution described in this set of documents, are written to = satisfy the following from the softwires charter: > 4. Developments for stateless legacy IPv4 carried over IPv6=20 > - develop a solution motivation document to be published as an = RFC=20 > - develop a protocol specification response to the solution=20 > motivation document; this work item will not be taken through=20= >=20 > in the design team's view, this set of documents are ready to be = adopted as working group documents. >=20 > comments? >=20 > for the MAP design team, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Tue Jan 31 01:15:05 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DCF21F8750 for ; Tue, 31 Jan 2012 01:15:04 -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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qe+nyuyrVrdY for ; Tue, 31 Jan 2012 01:15:04 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 21B2321F874F for ; Tue, 31 Jan 2012 01:15:03 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id EE4F470001B2; Tue, 31 Jan 2012 10:15:02 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id C10F8700018F; Tue, 31 Jan 2012 10:15:02 +0100 (CET) X-SFR-UUID: 20120131091502790.C10F8700018F@msfrf2414.sfr.fr Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> Date: Tue, 31 Jan 2012 10:15:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> To: Softwires WG , =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 09:15:05 -0000 Le 2012-01-30 =E0 12:31, Ole Tr=F8an a =E9crit : ... > in the design team's view, this set of documents are ready to be = adopted as working group documents. >=20 > comments? Thanks Ole for the documents. I will review them and comment. Some members of the MAP team expressed on the Softwire list, after you, = their support for these becoming WG documents now. This isn't surprising, of course, since you already made it "for the MAP = design team". But there is an important point: it was decided, after the Taipei = meeting, to explore in parallel for the next meeting MAP and 4rd-U (ref. = Alain's email = www.ietf.org/mail-archive/web/softwires/current/msg03296.html). In this context, promoting MAP documents to WG status NOW would be = premature. Now that both MAP and 4rd-U drafts are available, with a lot of = commonality but also with some substantial differences, fair evaluation = of the two approaches can start in Softwire. BTW, among subjects covered in = /www.ietf.org/id/draft-despres-softwire-4rd-u-03 and AFAIK not covered = in MAP drafts so far, there is: - How BRs can forward packets of fragmented datagrams on the fly, rather = than reassembling them (sec 4.5.2 of 4rd-U-03) - Avoidance of Identification ambiguities for datagrams from = shared-address CEs to the IPv4 Internet. Comments on these (among others) are welcome. Other point: due to a typo, the 4rd-U draft is presented as = Informational, it is of course intended for the Standards track (will be = corrected in the next version). Regards, RD >=20 > for the MAP design team, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From satoru.matsushima@gmail.com Tue Jan 31 05:28:24 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EDC21F855E for ; Tue, 31 Jan 2012 05:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgvrsmCeZY3W for ; Tue, 31 Jan 2012 05:28:23 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B70421F85A1 for ; Tue, 31 Jan 2012 05:28:22 -0800 (PST) Received: by pbdy7 with SMTP id y7so209904pbd.31 for ; Tue, 31 Jan 2012 05:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5Z5Fv9uxKzoLA7tygxukYD5tGmgH+UubyGrdp8e0pEU=; b=jpOnCh2No2iMIgyL7cSPnDcDdbiELwddOLSDFtxSdvV7/JDdtJkGx+cRo0eRUpOszr Pso8CFwge+qt95pP2rPP6V8AsPILpDSmf8YNU3rDCYO5ghAvVM9xRHBw+i596taL5UM3 iT/vo+zwR4fI+yqimld1p9flSBPZ2Vu4T046g= Received: by 10.68.216.4 with SMTP id om4mr32954957pbc.19.1328016502442; Tue, 31 Jan 2012 05:28:22 -0800 (PST) Received: from ?IPv6:2400:21dd:2684:200:6963:c454:e4d7:2c92? ([2400:21dd:2684:200:6963:c454:e4d7:2c92]) by mx.google.com with ESMTPS id z5sm55460400pbc.5.2012.01.31.05.28.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jan 2012 05:28:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> Date: Tue, 31 Jan 2012 22:28:17 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5AAB067C-B5EF-4F75-B844-AFC33A96261C@employees.org> To: =?utf-8?Q?Ole_Tr=C3=B8an?= X-Mailer: Apple Mail (2.1251.1) Cc: softwires WG Subject: Re: [Softwires] MAP documents - next steps X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 13:28:24 -0000 Hi, I'm in favor of the MAP documents suit. I support to adopt these as = WG documents. cheers, --satoru On 2012/01/30, at 20:31, Ole Tr=C3=B8an wrote: > hi, >=20 > the MAP (Mapping of address and port) design team has now written and = published the following sets of drafts. >=20 > the base document (port mapping algorithm): > = http://tools.ietf.org/html/draft-mdt-softwire-mapping-address-and-port-03 > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-mdt-softwire-mapping-address-an= d-port-03.txt >=20 > the encapsulation document (MAP-E): > http://tools.ietf.org/html/draft-mdt-softwire-map-encapsulation-00 >=20 > the translation document (MAP-T): > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-00 >=20 > the DHCP option (MAP-DHCP): > http://tools.ietf.org/html/draft-mdt-softwire-map-dhcp-option-02 >=20 > there is a MAP deployment document coming soon. >=20 > the solution described in this set of documents, are written to = satisfy the following from the softwires charter: > 4. Developments for stateless legacy IPv4 carried over IPv6=20 > - develop a solution motivation document to be published as an = RFC=20 > - develop a protocol specification response to the solution=20 > motivation document; this work item will not be taken through=20= >=20 > in the design team's view, this set of documents are ready to be = adopted as working group documents. >=20 > comments? >=20 > for the MAP design team, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From leaf.y.yeh@huawei.com Tue Jan 31 17:36:31 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6582911E80B5 for ; Tue, 31 Jan 2012 17:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13WUa21R3Q3e for ; Tue, 31 Jan 2012 17:36:30 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 486DE11E809D for ; Tue, 31 Jan 2012 17:36:30 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYO002NGXSRZK@szxga05-in.huawei.com> for softwires@ietf.org; Wed, 01 Feb 2012 09:36:27 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYO00F71XSI00@szxga05-in.huawei.com> for softwires@ietf.org; Wed, 01 Feb 2012 09:36:27 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGR28546; Wed, 01 Feb 2012 09:36:18 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 01 Feb 2012 09:35:56 +0800 Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.45]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 01 Feb 2012 09:36:08 +0800 Date: Wed, 01 Feb 2012 01:36:06 +0000 From: Leaf yeh X-Originating-IP: [10.70.39.113] To: softwires WG Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [Softwires] More changes to revision 03. - Sent again in text Thread-index: AQHM4IHpkImcNDpvvUqUUEK4En+SDA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <067E6CE33034954AAC05C9EC85E2577C073C63F7@XMB-RCD-111.cisco.com> Subject: Re: [Softwires] More changes to revision 03. - Sent again in text X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 01:36:31 -0000 UmFqaXYgLSBJIHdvdWxkIHZlcnkgbXVjaCBmYXZvciBoYXZpbmcgYSBzaGFyaW5nIHJhdGlvIGFz IGEgJ2dpdmVuJyB2YXJpYWJsZS4NCg0KVGhvdWdoIFJhaml2IHByZWZlcnMgJ3NoYXJpbmcgcmF0 aW8nIHRvICdFQS1iaXQgbGVuZ3RoJywgd2hpY2ggaXMgYSBsaXR0bGUgZGlmZmVyZW50IGZyb20g dGhlIHRleHQgb2Ygc2VjdGlvbiA1LA0KDQpJJ2QgYWxzbyBsaWtlIHRoZSBkcmFmdCBjb3VsZCBk ZWZpbmUgYW4gZXhwbGljaXQgZm9ybWF0IGZvciB0aGUgZXhwcmVzc2lvbiBvZiB0aGUgTUFQIHJ1 bGVzIGluY2x1ZGluZyBCTVIsIEZNUiAmIERNUi4NCg0KQlRXLCBtb3JlIHF1ZXN0aW9ucyBvbiB0 aGUgZXhhbXBsZSBvZiBETVIgaW4gc2VjdGlvbiA1LjQsDQoNCjxRdW90ZT4gLSB7MjAwMTpkYjg6 MDAwMTowMDAwOiZsdDtpbnRlcmZhY2UtaWQ+Oi8xMjggKFJ1bGUgSVB2NiBwcmVmaXgpLA0KMC4w LjAuMC8wIChSdWxlIElQdjQgcHJlZml4KSwNCjE5Mi4wLjIuMSAoQlIgSVB2NCBhZGRyZXNzKX0N Cg0KUTEuIMKgV2hhdCBkb2VzIOKAmCZsdOKAmSBtZWFuIGhlcmU/DQpRMi4gwqBEb2VzIOKAmGlu dGVyZmFjZS1pZD46LzEyOOKAmSBzb3VuZCBhIHByZWZpeCBoZXJlPw0KUTMuIMKgSXMgdGhlIEJS IElQdjQgYWRkcmVzcyAoMTkyLjAuMi4xKSBuZWNlc3NhcnkgaGVyZT8gVGhlcmUgc2VlbXMgbm8g SVB2NCBhZGRyZXNzIGluIHRoZSBCTVIgJiBGTVIsIGJ1dCB0aGV5IGFsc28gd29yayB3ZWxsIGZv ciB0aGUgTUFQIGZvcndhcmRpbmcgZnVuY3Rpb24uDQoNCg0KQmVzdCBSZWdhcmRzLA0KTGVhZg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSYWppdiBBc2F0aSAocmFqaXZh KSBbbWFpbHRvOnJhaml2YUBjaXNjby5jb21dIA0KU2VudDogVHVlc2RheSwgSmFudWFyeSAzMSwg MjAxMiA2OjI2IEFNDQpUbzogTGVhZiB5ZWg7IE9sZSBUcsO4YW4NCkNjOiBzb2Z0d2lyZXMgV0c7 IG1hcC1kdEBleHRlcm5hbC5jaXNjby5jb207IGZpbmVfc3pAaHVhd2VpLmNvbQ0KU3ViamVjdDog UkU6IFtTb2Z0d2lyZXNdIE1vcmUgY2hhbmdlcyB0byByZXZpc2lvbiAwMy4NCg0KPiBDMi4gVGhl IHNoYXJpbmcgcmF0aW8gc291bmRzIGEgY2FsY3VsYXRlZCByZXN1bHQsIG5vdCBhIOKAmGdpdmVu 4oCZIGNvbmRpdGlvbjsNCg0KSSB3b3VsZCB2ZXJ5IG11Y2ggZmF2b3IgaGF2aW5nIGEgc2hhcmlu ZyByYXRpbyBhcyBhICdnaXZlbicgdmFyaWFibGUsIGluc3RlYWQgb2YgYSBjYWxjdWxhdGVkIHJl c3VsdCAoYW5kIGluc3RlYWQgb2YgRUEtYml0IGxlbmd0aCwgaWYgbmVlZGVkIGJlKSBzaW5jZSBp dCBpcyBlYXNpZXIgdG8gdW5kZXJzdGFuZCwgZXhwbGFpbiBhbmQgd29yayBpdCBvdXQuDQoNCklu IGZhY3QsIG1vc3Qgb2YgdGhlIGV4YW1wbGVzIGluY2x1ZGVkIGluIHRoZSBkb2N1bWVudCBzaG93 IHRoZSBzaGFyaW5nLXJhdGlvIGJlaW5nIHVzZWQgYXMgYSBnaXZlbiB2YXJpYWJsZSwgc28gd2Ug anVzdCBuZWVkIHRvIHVwZGF0ZSB0aGUgcnVsZXMuDQrCoMKgwqDCoMKgwqDCoMKgIA0KQ2hlZXJz LA0KUmFqaXYNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNvZnR3 aXJlcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uDQo+IEJlaGFsZiBPZiBMZWFmIHllaA0KPiBTZW50OiBNb25kYXksIEphbnVhcnkgMzAsIDIw MTIgNjozOCBBTQ0KPiBUbzogT2xlIFRyw7hhbg0KPiBDYzogc29mdHdpcmVzIFdHOyBtYXAtZHRA ZXh0ZXJuYWwuY2lzY28uY29tIHRlYW07IGZpbmVfc3pAaHVhd2VpLmNvbQ0KPiBTdWJqZWN0OiBS ZTogW1NvZnR3aXJlc10gTW9yZSBjaGFuZ2VzIHRvIHJldmlzaW9uIDAzLg0KPiANCj4gT2xlIC0g d2hhdCdzIHRoZSBkaWZmZXJlbmNlPw0KPiANCj4gDQo+IA0KPiBJIHN1Z2dlc3RlZCB0aGUgZm9s bG93aW5nIHRleHQgZm9yIHRoZSByZWFkYWJsZSAuDQo+IA0KPiANCj4gDQo+IEdpdmVuOg0KPiAN Cj7CoMKgwqDCoCBFbmQtdXNlciBJUHY2IHByZWZpeDrCoMKgIDIwMDE6ZGI4OjAwMTI6MzQ6Oi81 Ng0KPiANCj7CoMKgwqDCoCBCYXNpYyBNYXBwaW5nIFJ1bGU6wqDCoMKgIHsyMDAxOmRiODowMDo6 LzQwIChSdWxlIElQdjYgcHJlZml4KSwNCj4gDQo+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIDE5Mi4wLjIuMC8yNCAoUnVsZSBJUHY0IHByZWZpeCksDQo+ IA0KPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxNiAo UnVsZSBFQS1iaXRzIGxlbmd0aCl9DQo+IA0KPsKgwqDCoMKgIFBTSUQgb2Zmc2V0OsKgwqDCoMKg wqDCoMKgwqDCoMKgIDTCoCAoZGVmYXVsdCB2YWx1ZSBhcyBwZXIgc2VjdGlvbiA1LjEuMykNCj4g DQo+IA0KPiANCj4gV2UgZ2V0IHRoZSBJUHY0IGFkZHJlc3MsIGl0cyBzaGFyaW5nIHJhdGlvIGFu ZCBwb3J0LXNldDoNCj4gDQo+IA0KPiANCj7CoMKgwqDCoCBFQSBiaXRzIG9mZnNldDrCoMKgwqDC oMKgwqAgNDANCj4gDQo+wqDCoMKgwqAgSVB2NCBzdWZmaXggYml0cyAocCk6wqDCoMKgIExlbmd0 aCBvZiBJUHY0IGFkZHJlc3MgKDMyKSAtIElQdjQgcHJlZml4IGxlbmd0aCAoMjQpID0gOA0KPiAN Cj7CoMKgwqDCoCBJUHY0IGFkZHJlc3M6wqDCoMKgwqDCoMKgwqAgMTkyLjAuMi4xOCAoMHgxMikN Cj4gDQo+IA0KPiANCj4g44CA44CAU2hhcmluZyByYXRpbzrCoMKgwqDCoMKgwqDCoMKgIDI1NiAo MTYgLSAoMzIgLSAyNCkgPSA4LiAyXjggPSAyNTYpDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gQ2hl ZXJzLA0KPiANCj4gTGVhZg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IA0KPiBGcm9tOiBPbGUgVHLDuGFuIFttYWlsdG86b3RAY2lzY28uY29tXQ0K PiANCj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDMwLCAyMDEyIDY6MTYgUE0NCj4gDQo+IFRvOiBM ZWFmIHllaA0KPiANCj4gQ2M6IGZpbmVfc3pAaHVhd2VpLmNvbTsgbWFwLWR0QGV4dGVybmFsLmNp c2NvLmNvbSB0ZWFtDQo+IA0KPiBTdWJqZWN0OiBSZTogTW9yZSBjaGFuZ2VzIHRvIHJldmlzaW9u IDAzLg0KPiANCj4gDQo+IA0KPiBMZWFmLA0KPiANCj4gDQo+IA0KPiA+IEFnYWluIEMmUXMgb24g dGhlIGV4YW1wbGVzIGluIHRoZSBuZXdseSB1cGRhdGVkIGNhbmRpZGF0ZSBvZiBNQVAtMDM6DQo+ IA0KPiA+DQo+IA0KPiA+IEEuwqDCoMKgwqAgU2VjdGlvbiA1LjIgLSBHaXZlbjoNCj4gDQo+ID7C oMKgwqAgRW5kLXVzZXIgSVB2NiBwcmVmaXg6wqAgMjAwMTpkYjg6MDAxMjozNDo6LzU2DQo+IA0K PiA+wqDCoMKgIEJhc2ljIE1hcHBpbmcgUnVsZTrCoMKgwqAgezIwMDE6ZGI4OjAwOjovNDAgKFJ1 bGUgSVB2NiBwcmVmaXgpLA0KPiANCj4gPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgMTkyLjAuMi4wLzI0IChSdWxlIElQdjQgcHJlZml4KSwNCj4g DQo+ID7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IDE2IChSdWxlIEVBLWJpdHMgbGVuZ3RoKX0NCj4gDQo+ID7CoCDCoMKgU2hhcmluZyByYXRpbzrC oMKgwqDCoMKgwqDCoMKgIDI1NiAoMTYgLSAoMzIgLSAyNCkgPSA4LiAyXjggPSAyNTYpDQo+IA0K PiA+wqDCoMKgIFBTSUQgb2Zmc2V0OsKgwqDCoMKgwqDCoMKgwqDCoMKgIDQNCj4gDQo+ID4NCj4g DQo+ID7CoMKgIFdlIGdldCBJUHY0IGFkZHJlc3MgYW5kIHBvcnQtc2V0Og0KPiANCj4gPsKgwqDC oCBFQSBiaXRzIG9mZnNldDrCoMKgwqDCoMKgwqAgNDANCj4gDQo+ID7CoMKgwqAgSVB2NCBzdWZm aXggYml0cyAocCk6IExlbmd0aCBvZiBJUHY0IGFkZHJlc3MgKDMyKSAtDQo+IA0KPiA+wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgSVB2NCBwcmVmaXgg bGVuZ3RoICgyNCkgPSA4DQo+IA0KPiA+IOKApi4NCj4gDQo+ID4NCj4gDQo+ID4gQzEuIFRoZSDi gJhFbmQtdXNlciBJUHY2IHByZWZpeOKAmSBzaGFsbCBiZSBleHByZXNzIGFzIOKAmDIwMDE6ZGI4 OjAwMTI6MzQwMDo6LzU24oCZDQo+IGFzIHBlciB0aGUgc2VjdGlvbiAyLjMgb2YgUkZDNDI5MTsN Cj4gDQo+IA0KPiANCj4gZml4ZWQuDQo+IA0KPiANCj4gDQo+ID4gQzIuIFRoZSBzaGFyaW5nIHJh dGlvIHNvdW5kcyBhIGNhbGN1bGF0ZWQgcmVzdWx0LCBub3QgYSDigJhnaXZlbuKAmSBjb25kaXRp b247DQo+IA0KPiANCj4gDQo+IHdoYXQncyB0aGUgZGlmZmVyZW5jZT8NCj4gDQo+IA0KPiANCj4g DQo+IA0KPiA+DQo+IA0KPiA+IEIuwqDCoMKgwqAgU2VjdGlvbiA1LjMgLSBHaXZlbjoNCj4gDQo+ ID7CoMKgwqDCoMKgwqAgSVB2NCBkZXN0aW5hdGlvbiBhZGRyZXNzOiAxOTIuMC4yLjE4DQo+IA0K PiA+wqDCoMKgwqDCoMKgIElQdjQgZGVzdGluYXRpb24gcG9ydDrCoMKgwqAgOTAzMA0KPiANCj4g PsKgwqDCoMKgwqDCoCBGb3J3YXJkaW5nIE1hcHBpbmcgUnVsZTrCoCB7MjAwMTpkYjg6MDA6Oi80 MCAoUnVsZSBJUHY2IHByZWZpeCksDQo+IA0KPiA+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDE5Mi4wLjIuMC8yNCAoUnVs ZSBJUHY0IHByZWZpeCksDQo+IA0KPiA+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDE2IChSdWxlIEVBLWJpdHMgbGVuZ3Ro KX0NCj4gDQo+ID4NCj4gDQo+ID7CoMKgwqDCoCBXZSBnZXQgSVB2NiBhZGRyZXNzOg0KPiANCj4g PsKgwqDCoMKgwqDCoCBJUHY0IHN1ZmZpeCBiaXRzIChwKTogMzIgLSAyNCA9IDggKDE4ICgweDEy KSkNCj4gDQo+ID7CoMKgwqDCoMKgwqAgUFNJRCBsZW5ndGg6wqDCoMKgwqDCoMKgwqDCoMKgIDgN Cj4gDQo+ID7CoMKgwqDCoMKgwqAgUFNJRDrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCAweDM0ICg5MDMwICgweDIzNDYpKQ0KPiANCj4gPsKgwqDCoMKgwqDCoCBFQSBiaXRzOsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIDB4MTIzNA0KPiANCj4gPsKgwqDCoMKgwqDCoCBNQVAgSVB2 NiBhZGRyZXNzOsKgwqDCoMKgIDIwMDE6ZGI4OjAwMTI6MzQwMDowMGMwOjAwMDI6MTIwMDozNDAw DQo+IA0KPiA+DQo+IA0KPiA+IEMzLiBJIHN1cHBvc2UgdGhlIGRlZmF1bHQg4oCYUFNJRCBvZmZz ZXQ6IDTigJkgc2VlbXMgbmVlZCB0byBleHByZXNzIGluIHRoZSDigJhnaXZlbuKAmQ0KPiBjb25k aXRpb25zOw0KPiANCj4gDQo+IA0KPiBPSw0KPiANCj4gDQo+IA0KPiA+IFExLiBIYXZlIHRoZSBk cmFmdCBzdGF0ZWQgdGhlIOKAmHXigJkgYml0cyBpbiB0aGUgSW50ZXJmYWNlLUlEIHNob3VsZCBi ZSAweDAwPw0KPiANCj4gDQo+IA0KPiBpdCBzdGF0ZXMgdGhhdCBpdCBpcyBiYXNlZCBvbiA2MDUy LiBJIHRoaW5rIHRoYXQgc2hvdWxkIGJlIHN1ZmZpY2llbnQuDQo+IA0KPiANCj4gDQo+IGNoZWVy cywNCj4gDQo+IE9sZQ0KPiANCj4gDQo+IA0KPiANCg0K From fibrib@gmail.com Tue Jan 31 18:04:04 2012 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3DA11E808E for ; Tue, 31 Jan 2012 18:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TkgaeiQXRtE for ; Tue, 31 Jan 2012 18:04:04 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAEDF21F848F for ; Tue, 31 Jan 2012 18:04:03 -0800 (PST) Received: by qcsg13 with SMTP id g13so449320qcs.31 for ; Tue, 31 Jan 2012 18:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u59e+yUlGs9L7HahF7yUmNFeOpws026gBg5nwOjYB/U=; b=viA5ejaSMqYMqFMEz7xe8CLETMmxBjJHTReWmvUwpKGaHGqQFHjzzUt9+cLmEcjwLx mky3GKeKMY1cXn7Y2Kt4j9LnDc6dwyWILQYAO3q1Jj9q7XX86gkQfX00scvUUc/QKsd+ GhCaodZSz5G5/jbdLY9HXlrCdC36Bj/dLpjk0= MIME-Version: 1.0 Received: by 10.224.202.65 with SMTP id fd1mr30677241qab.12.1328061843215; Tue, 31 Jan 2012 18:04:03 -0800 (PST) Received: by 10.229.211.72 with HTTP; Tue, 31 Jan 2012 18:04:03 -0800 (PST) In-Reply-To: <3069401B-458B-41E2-B6B3-B9FA8811CC30@laposte.net> References: <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> <3069401B-458B-41E2-B6B3-B9FA8811CC30@laposte.net> Date: Wed, 1 Feb 2012 11:04:03 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf30050eea6795e704b7dd7e68 Cc: Softwires WG Subject: Re: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 02:04:05 -0000 --20cf30050eea6795e704b7dd7e68 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/1/30 R=E9mi Despr=E9s > > and definitely there is no compatibility to single translation in RFC6145 > at all. as the result, RFC6145 provides a unified solution, while 4rd-U > requires ISP (who prefer to use translation) disjointly deploy their > networks for single and double translations. > > >> >> >> If you have a specific configuration that illustrates your concern, it >> could be discussed with more details. >> > > Could you, for the sake of a less abstract discussion, describe at least > one configuration you have in mind, in which some IPv4 addresses are > statelessly shared, and in which there is the RFC6145 compatibility you a= re > talking about. > Without that, I can't figure out what you mean. > (The goal remains customer service, without harm if this happens to be > possible without full support of RFC4125, right?) > to my best understanding, one of the merits of the translation approach is: when an end system changes its stack from ipv4 to ipv6, as long as the ipv4-translatable ipv6 address is applied, its peers in the past can keep using the same ipv4 address (as the temporal-unique identifier) to have access to it. in other words, the stack-changing doesn't impact already-existing peers, but enlarges the opportunity for the new connections from native ipv6 peers. separating single translation and double translation with deploying disjoint ipv4 (as well as corresponding ipv6) spaces is meaningless in this term. i think this is a clear-enough use-case but if i still make any confusion, i may draw some pictures for you offline. i have investigated, technically, what if we had updated RFC6145 with carrying ICMPv4 messages in IPv6 directly instead of translating to ICMPv6, specially for double translation, but i found 1) the necessity is weak, according to the transparency check for RFC6145 end-to-end behavior in double-translation; 2) it is impossible to make decision among alternatives due to lack of knowledge about the remote stack (i.e. cannot distinguish single or double translation with no state nor complicated dynamic configuration); and 3) it is harmful to have ICMPv4 in IPv6 payload (as i mentioned previously). my conclusion is: for RFC6145, it is a wise choice to keep using a unified translation algorithm no matter the case is single or double. - M. > RD > --20cf30050eea6795e704b7dd7e68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/1/30 R=E9mi Despr=E9s <despres.remi@laposte.n= et>

and definitely there is no compatibility to single = translation in RFC6145 at all. as the result, RFC6145=A0provides a unified = solution, while 4rd-U requires ISP (who prefer to use translation)=A0disjoi= ntly deploy their networks for single and double translations.
=A0
<= div style=3D"word-wrap:break-word">
=A0

If you have a specific configuration that illu= strates your concern, it could be discussed with more details.
<= /div>

Could y= ou, for the sake of a less abstract discussion, describe at least one confi= guration you have in mind, in which some IPv4 addresses are statelessly sha= red, and in which there is the RFC6145 compatibility you are talking about.=
Without that, I can't figure out what you mean.=A0
(The = goal remains customer service, without harm if=A0this happens to be possibl= e without full support of RFC4125, right?)

to my best understanding, one of the merits of the translati= on approach is: when an end system changes its stack from ipv4 to ipv6, as = long as the ipv4-translatable ipv6 address is applied, its peers in the pas= t can keep using the same ipv4 address (as the temporal-unique identifier) = to have access to it. in other words, the stack-changing doesn't impact= already-existing peers, but enlarges the opportunity for the new connectio= ns from native ipv6 peers. separating single translation and double transla= tion with deploying disjoint ipv4 (as well as corresponding ipv6) spaces is= meaningless in this term.

i think this is a clear-enough use-case but if i still = make any confusion, i may draw some pictures for you offline.=A0
=
i have investigated, technically, what if we had updated RFC= 6145 with carrying ICMPv4 messages in IPv6 directly instead of translating = to ICMPv6, specially for double translation, but i found 1) the necessity i= s weak, according to the transparency check for RFC6145 end-to-end behavior= in double-translation; 2) it is impossible to make decision among alternat= ives due to lack of knowledge about the remote stack (i.e. cannot distingui= sh single or double translation with no state nor complicated dynamic confi= guration); and 3) it is harmful to have ICMPv4 in IPv6 payload (as i mentio= ned previously).=A0my conclusion is: for RFC6145, it is a wise choice to ke= ep using a unified translation algorithm no matter the case is single or do= uble.=A0

- M.=A0


RD

--20cf30050eea6795e704b7dd7e68--