From otroan@employees.org Sat Dec 1 00:45: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 E3CB121F85FF for ; Sat, 1 Dec 2012 00:45:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAHDqYKOQa8D for ; Sat, 1 Dec 2012 00:45:12 -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 B301621F852A for ; Sat, 1 Dec 2012 00:44:56 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAETCuVCQ/khL/2dsb2JhbABEwAYWc4IfAQU6PxALRlcGiCO+fZAgYQObbIpcgnM X-IronPort-AV: E=McAfee;i="5400,1158,6912"; a="147624005" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2012 08:44:52 +0000 Received: from [10.61.103.89] (dhcp-10-61-103-89.cisco.com [10.61.103.89]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB18iqdR005075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Dec 2012 08:44:52 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Sat, 1 Dec 2012 09:44:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9D4F2E9C-FA92-48D6-AF14-69BC86F3D4B9@employees.org> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> To: Qiong X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 01 Dec 2012 08:45:14 -0000 Qiong, > [Qiong] and a sub-mode for "source IPv6 address determiniation", how = to determine the encapsulated IPv6 source address. > 1) algorithmic, LAN prefix + embedded IPv4 address/PSID in Interface = Identifier (MAP)=20 > 2) WAN IPv6 address (DS-Lite, LW46, Public 4over6) > =20 > Right ? MAP could also create its tunnel endpoint address from the WAN prefix = (not address). so you'd have, for CPE tunnel end point address: 1) arbitrary IPv6 address (DS-lite) 2) WAN IPv6 address (DS-lite, LW46, Public 4over6) 3) Algorithmic End-user IPv6 prefix + Well known interface-id (MAP) cheers, Ole From otroan@employees.org Sat Dec 1 00:47:47 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 A011421F8563 for ; Sat, 1 Dec 2012 00:47:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkBvhROAM7OZ for ; Sat, 1 Dec 2012 00:47:47 -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 E2B4221F855F for ; Sat, 1 Dec 2012 00:47:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAITDuVCQ/khM/2dsb2JhbABEwAYWc4IeAQEEAXkQC0ZXBogdBr5+kCBhA5tsilyCcw X-IronPort-AV: E=McAfee;i="5400,1158,6912"; a="147624080" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2012 08:47:45 +0000 Received: from [10.61.103.89] (dhcp-10-61-103-89.cisco.com [10.61.103.89]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qB18ljgS030614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Dec 2012 08:47:45 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <50B9B5C7.107@viagenie.ca> Date: Sat, 1 Dec 2012 09:47:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <10C9FD27-2894-4495-90E1-15A9AC9D73B9@employees.org> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <50B9B5C7.107@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 01 Dec 2012 08:47:47 -0000 Simon, >>> Med: The rationale we adopted in this draft is as follows: >>>=20 >>> * there are three major flavors: full stateful, full stateless, and = binding mode >>> * all these modes can support assigning a full or a shared IPv4 = address >>=20 >> now you got me thinking, are these really the right modes from a CPE = perspective? >>=20 >> let me try to explain, with my CPE implementor hat on, what "modes" = would make sense? >>=20 >> - NAT placement. do I need a NAT on the CPE or not? >> (no NAT && no IPv4 address =3D=3D DS-lite) >> - full IPv4 address assigned. >> I can assign the IPv4 address to the tunnel endpoint interface, and = use that address for >> local applications, and as the outbound address of the NAT >> (mechanisms: MAP, Public 4over6) >> - IPv4 prefix assigned: >> I need to disable the CPE NAT, and use the assigned IPv4 prefix as = my LAN side DHCPv4 pool >> (mechanism: MAP) >> - Shared IPv4 address. >> I must enable a local NAT, I cannot assign the IPv4 address on the = "WAN" interface, but only use it >> for the outbound side of the NAT. >=20 > Interesting... But note that even just implementing MAP alone would = generate three of these "implementation modes". I would still like to = see this list added to an "implementation considerations" section. Stuff = like "you can't assign a partial address to a tunnel interface" may not = be obvious to implementers. >=20 >> then there might be a sub-modes for "tunnel endpoint determination" = i.e. how to determine an IPv6 tunnel end point address given an IPv4 = destination address and port. >> 1) algorithmic (MAP) >> 2) configured (Public 4over6, LW46, DS-lite) >>=20 >> and a sub-mode for IPv4 address configuration: >> 1) As "native IPv4" >> (Public4over6, LW46) >> 2) Embedded Address >> (MAP) >> 3) None >> DS-lite >>=20 >> does this make sense? >=20 > Totally appropriate for an "implementation considerations" section = IMHO. I'm suggesting to replace the current drafts "state*, binding modes" = with these modes. cheers, Ole From bingxuere@gmail.com Sat Dec 1 01:09: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 AFD6021F85EF for ; Sat, 1 Dec 2012 01:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.373 X-Spam-Level: X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+QfF-KtVwEJ for ; Sat, 1 Dec 2012 01:09:31 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06B0321F85E7 for ; Sat, 1 Dec 2012 01:09:30 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so1089111iaz.31 for ; Sat, 01 Dec 2012 01:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C17gyHz3jc2qFHDs2RbCTuS78C8MNqmjeLEKyifk0+s=; b=n+1TOKMq/tddbestqr/qFEsOpTf+1Sbbn3iw7X2L+OVWCU0OG70YVzPp2DFnVdz2B3 6Qfyz46e4edGrBRArEouYKA5lhlgHoDiD6WvRfISAp4KUHm3alJKxXx1Rd/goJAUXyMW /MB6LHq81bGdOogBApv8oVyWCbcU/4kQfuOKZD+JBvUCDaQucITLUfAlB0gJEUqETxG+ HcJPiEjaqWFZixiNa1hA/i+0Iblbxt1OLxOtKWc/uoIjgpbJpX1XpwjSLWlrZDVO9ies R9yQGic1MNg6MNTgD8mxIofbEcpyERk+1aNRnIARmP27hkyFc1Wsf7jJSdh82Z6PG/kb qs+w== Received: by 10.50.152.194 with SMTP id va2mr1109363igb.25.1354352970292; Sat, 01 Dec 2012 01:09:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Sat, 1 Dec 2012 01:08:49 -0800 (PST) In-Reply-To: <9D4F2E9C-FA92-48D6-AF14-69BC86F3D4B9@employees.org> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <9D4F2E9C-FA92-48D6-AF14-69BC86F3D4B9@employees.org> From: Qiong Date: Sat, 1 Dec 2012 17:08:49 +0800 Message-ID: To: =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/alternative; boundary=e89a8f3b9de9b1ddef04cfc6dfb2 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 01 Dec 2012 09:09:31 -0000 --e89a8f3b9de9b1ddef04cfc6dfb2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ole, On Sat, Dec 1, 2012 at 4:44 PM, Ole Tr=C3=B8an wrote= : > Qiong, > > > [Qiong] and a sub-mode for "source IPv6 address determiniation", how to > determine the encapsulated IPv6 source address. > > 1) algorithmic, LAN prefix + embedded IPv4 address/PSID in Interface > Identifier (MAP) > > 2) WAN IPv6 address (DS-Lite, LW46, Public 4over6) > > > > Right ? > > MAP could also create its tunnel endpoint address from the WAN prefix (no= t > address). > so you'd have, for CPE tunnel end point address: > Thanks for clarification. But if MAP uses the WAN prefix as its tunnel endpoint address, does BR need to keep all the records for CPEs (because the CPE's WAN prefix might be arbitary) ? Or do you mean the CPE's WAN prefix will be embedded with EA bits ? Would you please explain it a bit more ? > > 1) arbitrary IPv6 address (DS-lite) > Why it is arbitary ? Is it the source address of the tunnel endpoint ? Thanks Qiong 2) WAN IPv6 address (DS-lite, LW46, Public 4over6) > 3) Algorithmic End-user IPv6 prefix + Well known interface-id (MAP) > > > cheers, > Ole > > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --e89a8f3b9de9b1ddef04cfc6dfb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ole,

On Sat, D= ec 1, 2012 at 4:44 PM, Ole Tr=C3=B8an <otroan@employees.org> wrote:
Qiong,

> [Qiong] and a sub-mode for "source IPv6 address determiniation&qu= ot;, how to determine the encapsulated IPv6 source address.
> 1) algorithmic, LAN prefix + embedded IPv4 address/PSID in Interface I= dentifier (MAP)
> 2) WAN IPv6 address (DS-Lite, LW46, Public 4over6)
>
> Right ?

MAP could also create its tunnel endpoint address from the WAN prefix= (not address).
so you'd have, for CPE tunnel end point address:
T= hanks for clarification. But if MAP uses the WAN prefix as its tunnel endpo= int address, does BR need to keep all the records for CPEs (because the CPE= 's WAN prefix might be arbitary) ? Or do you mean the CPE's WAN pre= fix will be embedded with EA bits ? Would you please explain it a bit more = ?=C2=A0

1) arbitrary IPv6 address (DS-lite)
Why it is arbitary= ? Is it the source address of the tunnel endpoint ?

Thanks
Qion= g

2) WAN IPv6 address (DS-lite, LW46, Public 4over6)
3) Algorithmic End-user IPv6 prefix + Well known interface-id (MAP)



=C2=A0
cheers,
Ole




--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Be= ijing Research Institude


Open source code:
lightweight 4over6= : h= ttp://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--e89a8f3b9de9b1ddef04cfc6dfb2-- From otroan@employees.org Sat Dec 1 04:11:16 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 B7E3221F849E for ; Sat, 1 Dec 2012 04:11:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhD8a0OeBBlW for ; Sat, 1 Dec 2012 04:11:16 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id B25CC21F849B for ; Sat, 1 Dec 2012 04:11:15 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAL7yuVCQ/khM/2dsb2JhbABEwAYWc4IeAQEEATo/BQsLRlcGiB0GvmCQIGEDm2yKXIJz X-IronPort-AV: E=McAfee;i="5400,1158,6912"; a="10063051" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 01 Dec 2012 12:11:14 +0000 Received: from [10.61.102.248] (dhcp-10-61-102-248.cisco.com [10.61.102.248]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qB1CBDGx026590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Dec 2012 12:11:14 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Sat, 1 Dec 2012 13:11:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6DF21FCC-1B07-4826-B146-46D89FE579D6@employees.org> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <9D4F2E9C-FA92-48D6-AF14-69BC86F3D4B9@employees.org> To: Qiong X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 01 Dec 2012 12:11:16 -0000 Qiong, [...] > MAP could also create its tunnel endpoint address from the WAN prefix = (not address). > so you'd have, for CPE tunnel end point address: > Thanks for clarification. But if MAP uses the WAN prefix as its tunnel = endpoint address, does BR need to keep all the records for CPEs (because = the CPE's WAN prefix might be arbitary) ? Or do you mean the CPE's WAN = prefix will be embedded with EA bits ? Would you please explain it a bit = more ? =20 from MAP's perspective it doesn't matter if it is a /64 on the WAN or a = /56 delegated prefix. any prefix can have EA bits. > 1) arbitrary IPv6 address (DS-lite) > Why it is arbitary ? Is it the source address of the tunnel endpoint ? in DS-lite the tunnel concentrator learns the tunnel endpoint address = when the NAT bindings are created. so the CPE is free to pick whatever IPv6 address it has. this is = different from Public 4over6 and LW46 where the address has to be configured on both ends. cheers, Ole= From bingxuere@gmail.com Sat Dec 1 18:55:00 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 6F15521E8091 for ; Sat, 1 Dec 2012 18:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nt1lQHDqIUeA for ; Sat, 1 Dec 2012 18:54:59 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE7721F8CA9 for ; Sat, 1 Dec 2012 18:54:59 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so2786981ieb.31 for ; Sat, 01 Dec 2012 18:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jyxxatU9UFoazR06xnoG+GeXhxHBMbwns2w9DsB8Cl0=; b=vJu5NOo+fDvDbbuB/Qi/T5CandO/QRweDjZOmoImwIjrJ41G3JscwZ+DQ+zqvxdIUy 19JZ6GsqpwuDU+GmwX/bmKERYJjUQnwZvCqmE6KNv4vBwOmuMN1K9/jhszUn97TEGIxu FuzpO4OItrSAIQTPOFVWfgcjg+Ic8bAafz0Whf3FxxTB10wZFWdCfHuq9irfi9LnTUn7 Wlt4y2zbATZ82/jOhELEqIZOvEBDC0vevDfz/zcv//z4v8u0aywPcS8tqRurMQkDtXNh JDjqo0xVTpyBCR9pF6BzKH1razQ2zJPrCeioFKt0eSQy3KGAjfoimZtUIu4JzcODbS5D jj0w== Received: by 10.50.45.137 with SMTP id n9mr2821025igm.25.1354416899021; Sat, 01 Dec 2012 18:54:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Sat, 1 Dec 2012 18:54:17 -0800 (PST) In-Reply-To: <6DF21FCC-1B07-4826-B146-46D89FE579D6@employees.org> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <9D4F2E9C-FA92-48D6-AF14-69BC86F3D4B9@employees.org> <6DF21FCC-1B07-4826-B146-46D89FE579D6@employees.org> From: Qiong Date: Sun, 2 Dec 2012 10:54:17 +0800 Message-ID: To: =?UTF-8?Q?Ole_Tr=C3=B8an?= Content-Type: multipart/alternative; boundary=14dae93403a524dce904cfd5c2e5 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 02 Dec 2012 02:55:00 -0000 --14dae93403a524dce904cfd5c2e5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ole, Please see inline ~~ On Sat, Dec 1, 2012 at 8:11 PM, Ole Tr=C3=B8an wrote= : > Qiong, > > [...] > > > MAP could also create its tunnel endpoint address from the WAN prefix > (not address). > > so you'd have, for CPE tunnel end point address: > > Thanks for clarification. But if MAP uses the WAN prefix as its tunnel > endpoint address, does BR need to keep all the records for CPEs (because > the CPE's WAN prefix might be arbitary) ? Or do you mean the CPE's WAN > prefix will be embedded with EA bits ? Would you please explain it a bit > more ? > > from MAP's perspective it doesn't matter if it is a /64 on the WAN or a > /56 delegated prefix. > any prefix can have EA bits. > [Qiong] In theory, right. But I think it still have several issues here: 1) The /64 WAN prefix or a /56 delegated prefix does not have a flag saying "hey, I'm the one with EA bits". Then, how can a CPE choose which prefix to extract the EA bits ? Or do you need another configuration flag to indicate which prefix to embed to EA bits? 2) Some operators have adpoted stateful DHCPv6 on the WAN interface. In that case, multiple CPEs can be within the same /64 prefix in the WAN side with different last 64 bits. However, if EA bits is embedded in the WAN prefix, it will have extra impact on operators' addressing model, consuming more address. And also it seems difficult to configure non-contiguous addresses in DHCPv6 server for stateful dhcpv6 mode(configure a lot of pools with different /64 prefix?). And if I remember correctly, when dIVI-pd came out, it said clearly that it was designed for delegated prefix. I thought it was the original intension of current stateless solutions (please correct me if I'm wrong). And I do suggest to simplify the implementation, rather than leaving too much flexibility and increase the complexity. > > > 1) arbitrary IPv6 address (DS-lite) > > Why it is arbitary ? Is it the source address of the tunnel endpoint ? > > in DS-lite the tunnel concentrator learns the tunnel endpoint address whe= n > the NAT bindings are created. > so the CPE is free to pick whatever IPv6 address it has. this is differen= t > from Public 4over6 and LW46 [Qiong] In theory, right. But still, I have a few comments on it: 1) In DS-Lite, the operator may apply source address filtering for security consideration. Currently, we are applying the acl using WAN address. The arbitrary IPv6 address may lead this address filtering fail. 2) Even in DS-Lite, operators may adopt bulk port allocation for each subscriber (each subscriber will be reserved a port-set in AFTR when the first packet creates the NAT binding). If the CPE arbitrary chooses different IPv6 address, this port-set reservation can not work neither... 3) Current DS-Lite CPEs all choose the WAN address as the tunnel endpoint, which is simple and easy to manage. where the > address has to be configured on both ends. > [Qiong] Lw4o6 and public 4over6 can also use arbitary address if the lwAFTR does not do source address filtering/validation . The upstream packet only needs be decapsulated and the downstream packet can find the matching tunnel endpoint address using public v4 address and port. But still, for management and security reasons, I still suggest to use the WAN address as the tunnel endpoint address. Best wishes Qiong > > cheers, > Ole --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --14dae93403a524dce904cfd5c2e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ole,

Please see inline ~~


<= div class=3D"gmail_quote">On Sat, Dec 1, 2012 at 8:11 PM, Ole Tr=C3=B8an <otroan@employees.org> wrote:
Qiong,

[...]

> MAP could also create its tunnel endpoint address from the WAN prefix = (not address).
> so you'd have, for CPE tunnel end point address:
> Thanks for clarification. But if MAP uses the WAN prefix as its tunnel= endpoint address, does BR need to keep all the records for CPEs (because t= he CPE's WAN prefix might be arbitary) ? Or do you mean the CPE's W= AN prefix will be embedded with EA bits ? Would you please explain it a bit= more ?

from MAP's perspective it doesn't matter if it is a /64 on th= e WAN or a /56 delegated prefix.
any prefix can have EA bits.
[Qiong] In theory, right.= But I think it still have several issues here:
1) The /64 WAN prefix or= a /56 delegated prefix does not have a flag saying "hey, I'm the = one with EA bits". Then, how can a CPE choose which prefix to extract = the EA bits ? Or do you need another configuration flag to indicate which p= refix to embed to EA bits?
2) Some operators have adpoted stateful DHCPv6 on the WAN interface. In tha= t case, multiple CPEs can be within the same /64 prefix in the WAN side wit= h different last 64 bits. However, if EA bits is embedded in the WAN prefix= , it will have extra impact on operators' addressing model, consuming m= ore address. And also it seems difficult to configure non-contiguous addres= ses in DHCPv6 server for stateful dhcpv6 mode(configure a lot of pools with= different /64 prefix?).

And if I remember correctly, when dIVI-pd came out, it said clearly tha= t it was designed for delegated prefix. I thought it was the original inten= sion of current stateless solutions (please correct me if I'm wrong). A= nd I do suggest to simplify the implementation, rather than leaving too muc= h flexibility and increase the complexity.

> 1) arbitrary IPv6 address (DS-lite)
> Why it is arbitary ? Is it the source address of the tunnel endpoint ?=

in DS-lite the tunnel concentrator learns the tunnel endpoint address= when the NAT bindings are created.
so the CPE is free to pick whatever IPv6 address it has. this is different = from Public 4over6 and LW46
[Qiong] In theory, right. But = still, I have a few comments on it:
1) In DS-Lite, the operator may appl= y source address filtering for security consideration. Currently, we are ap= plying the acl using WAN address. The arbitrary IPv6 address may lead this = address filtering fail.
2) Even in DS-Lite, operators may adopt bulk port allocation for each subsc= riber (each subscriber will be reserved a port-set in AFTR when the first p= acket creates the NAT binding). If the CPE arbitrary chooses different IPv6= address, this port-set reservation can not work neither...
3) Current DS-Lite CPEs all choose the WAN address as the tunnel endpoint, = which is simple and easy to manage.

where the
address has to be configured on both ends.
[Qiong] Lw4= o6 and public 4over6 can also use arbitary address if the lwAFTR does not d= o source address filtering/validation . The upstream packet only needs be d= ecapsulated and the downstream packet can find the matching tunnel endpoint= address using public v4 address and port. But still, for management and se= curity reasons, I still suggest to use the WAN address as the tunnel endpoi= nt address.

Best wishes
Qiong

cheers,
Ole



--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom= Beijing Research Institude


Open source code:
lightweight 4ov= er6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--14dae93403a524dce904cfd5c2e5-- From ian.farrer@telekom.de Sun Dec 2 06:20:06 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 A4C7D21F842F for ; Sun, 2 Dec 2012 06:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qNfRERBqayG for ; Sun, 2 Dec 2012 06:20:02 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5A421F8168 for ; Sun, 2 Dec 2012 06:20:00 -0800 (PST) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 02 Dec 2012 15:19:58 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Sun, 2 Dec 2012 15:19:58 +0100 From: To: , Date: Sun, 2 Dec 2012 15:15:46 +0100 Thread-Topic: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3PoI09BtUmWLLnQP6MelSgyINd1QCCHIxw Message-ID: <8A1B81989BCFAE44A22B2B86BF2B76318954FEE360@HE111643.EMEA1.CDS.T-INTERNAL.COM> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <50B9B5C7.107@viagenie.ca> <10C9FD27-2894-4495-90E1-15A9AC9D73B9@employees.org> In-Reply-To: <10C9FD27-2894-4495-90E1-15A9AC9D73B9@employees.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires@ietf.org Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 02 Dec 2012 14:20:06 -0000 Hi Ole, Whichever state is selected, NAT is certainly fundamental to how the state = will operate and so we tried to weave it into the functional description. I= 'm not sure that provisioned NAT info enough to be able to use to unambiguo= usly define with operating 'mode' (for want of a better word) to use. One of the reasons for the use of state in the draft is try and define the = operating modes with as little overlap as possible (it's not 100%, but ther= e's only 1 exception at the moment for binding mode and MAP1:1). From this,= then it is easier to align the specific solution names to the state charac= teristics. But, with what you've suggested, there is more overlap, i.e. both 2&4 have = NAT functions that are supported by two different mechanisms. However, what you've said does raise the following point: The way that state is described in the draft at the moment is actually take= n from a concentrator perspective. This could be taken to be almost the inv= erse of the amount of state that is required from the CPEs perspective (i.e= . if all of the state is in the providers network (DS-Lite), then the CPE d= oesn't need it. If the providers network has less state ('per-customer', 's= tateless'), then the CPE needs to have more - i.e. dynamic state table for = NAT, configuration for local IPv4/port set, MAPing rules etc. Would describing the different states more from the CPE's perspective make = this clearer? Cheers, Ian -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Ole Tr=F8an Sent: Samstag, 1. Dezember 2012 09:48 To: Simon Perreault Cc: softwires@ietf.org Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-= cpe Simon, >>> Med: The rationale we adopted in this draft is as follows: >>>=20 >>> * there are three major flavors: full stateful, full stateless, and=20 >>> binding mode >>> * all these modes can support assigning a full or a shared IPv4=20 >>> address >>=20 >> now you got me thinking, are these really the right modes from a CPE per= spective? >>=20 >> let me try to explain, with my CPE implementor hat on, what "modes" woul= d make sense? >>=20 >> - NAT placement. do I need a NAT on the CPE or not? >> (no NAT && no IPv4 address =3D=3D DS-lite) >> - full IPv4 address assigned. >> I can assign the IPv4 address to the tunnel endpoint interface, and us= e that address for >> local applications, and as the outbound address of the NAT >> (mechanisms: MAP, Public 4over6) >> - IPv4 prefix assigned: >> I need to disable the CPE NAT, and use the assigned IPv4 prefix as my = LAN side DHCPv4 pool >> (mechanism: MAP) >> - Shared IPv4 address. >> I must enable a local NAT, I cannot assign the IPv4 address on the "WA= N" interface, but only use it >> for the outbound side of the NAT. >=20 > Interesting... But note that even just implementing MAP alone would gener= ate three of these "implementation modes". I would still like to see this l= ist added to an "implementation considerations" section. Stuff like "you ca= n't assign a partial address to a tunnel interface" may not be obvious to i= mplementers. >=20 >> then there might be a sub-modes for "tunnel endpoint determination" i.e.= how to determine an IPv6 tunnel end point address given an IPv4 destinatio= n address and port. >> 1) algorithmic (MAP) >> 2) configured (Public 4over6, LW46, DS-lite) >>=20 >> and a sub-mode for IPv4 address configuration: >> 1) As "native IPv4" >> (Public4over6, LW46) >> 2) Embedded Address >> (MAP) >> 3) None >> DS-lite >>=20 >> does this make sense? >=20 > Totally appropriate for an "implementation considerations" section IMHO. I'm suggesting to replace the current drafts "state*, binding modes" with t= hese modes. cheers, Ole _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Mon Dec 3 01: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 598B921F85B1 for ; Mon, 3 Dec 2012 01:04:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsUKE2koX90o for ; Mon, 3 Dec 2012 01:04:03 -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 99FEE21F865F for ; Mon, 3 Dec 2012 01:04:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKFqvFCQ/khL/2dsb2JhbABFwAAWc4IeAQEEATo/BQsLRlcGiB0GvjOQIGEDpkiCcw X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="147691785" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2012 09:03:43 +0000 Received: from dhcp-lys01-vla250-10-147-112-218.cisco.com (dhcp-lys01-vla250-10-147-112-218.cisco.com [10.147.112.218]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qB393gU3016002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 09:03:43 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Mon, 3 Dec 2012 10:03:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <61BAA5D0-6725-49BE-8857-945B7EC3380D@employees.org> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <9D4F2E9C-FA92-48D6-AF14-69BC86F3D4B9@employees.org> <6DF21FCC-1B07-4826-B146-46D89FE579D6@employees.org> To: Qiong X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 03 Dec 2012 09:04:04 -0000 Qiong, > from MAP's perspective it doesn't matter if it is a /64 on the WAN or = a /56 delegated prefix. > any prefix can have EA bits. > [Qiong] In theory, right. But I think it still have several issues = here: > 1) The /64 WAN prefix or a /56 delegated prefix does not have a flag = saying "hey, I'm the one with EA bits". Then, how can a CPE choose which = prefix to extract the EA bits ? Or do you need another configuration = flag to indicate which prefix to embed to EA bits? from the draft: "A MAP node finds its Basic Mapping Rule by doing a longest match between the End-user IPv6 prefix and the Rule IPv6 prefix in the Mapping Rules table. The rule is then used for IPv4 prefix, address or shared address assignment." cheers, Ole From otroan@employees.org Mon Dec 3 01:06: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 136A221F878C for ; Mon, 3 Dec 2012 01:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEqiNVj92Fgk for ; Mon, 3 Dec 2012 01:06:30 -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 DCE9421F845B for ; Mon, 3 Dec 2012 01:06:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKFqvFCQ/khN/2dsb2JhbABFwAAWc4IeAQEEAXkFCwtGVwYuh28GvjONWoJGYQOmSIJz X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="147691853" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 03 Dec 2012 09:06:28 +0000 Received: from dhcp-lys01-vla250-10-147-112-218.cisco.com (dhcp-lys01-vla250-10-147-112-218.cisco.com [10.147.112.218]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB396RQv023269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Dec 2012 09:06:28 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <8A1B81989BCFAE44A22B2B86BF2B76318954FEE360@HE111643.EMEA1.CDS.T-INTERNAL.COM> Date: Mon, 3 Dec 2012 10:06:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <50B9B5C7.107@viagenie.ca> <10C9FD27-2894-4495-90E1-15A9AC9D73B9@employees.org> <8A1B81989BCFAE44A22B2B86BF2B76318954FEE360@HE111643.EMEA1.CDS.T-INTERNAL.COM> To: X-Mailer: Apple Mail (2.1499) Cc: softwires@ietf.org Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 03 Dec 2012 09:06:31 -0000 Ian, > Whichever state is selected, NAT is certainly fundamental to how the = state will operate and so we tried to weave it into the functional = description. I'm not sure that provisioned NAT info enough to be able to = use to unambiguously define with operating 'mode' (for want of a better = word) to use. >=20 > One of the reasons for the use of state in the draft is try and define = the operating modes with as little overlap as possible (it's not 100%, = but there's only 1 exception at the moment for binding mode and MAP1:1). = =46rom this, then it is easier to align the specific solution names to = the state characteristics. I don't think you should try to define modes such that the map (no pun = intended) into the specific solution names. shouldn't the purpose of a "unified CPE", be for the CPE not to have to = care about the different "deployment modes" on the head end? > But, with what you've suggested, there is more overlap, i.e. both 2&4 = have NAT functions that are supported by two different mechanisms. >=20 > However, what you've said does raise the following point: >=20 > The way that state is described in the draft at the moment is actually = taken from a concentrator perspective. This could be taken to be almost = the inverse of the amount of state that is required from the CPEs = perspective (i.e. if all of the state is in the providers network = (DS-Lite), then the CPE doesn't need it. If the providers network has = less state ('per-customer', 'stateless'), then the CPE needs to have = more - i.e. dynamic state table for NAT, configuration for local = IPv4/port set, MAPing rules etc. >=20 > Would describing the different states more from the CPE's perspective = make this clearer? that would certainly help. although I don't think "state" is the = defining characteristic. cheers, Ole= From mohamed.boucadair@orange.com Mon Dec 3 01:55: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 2203021F88CD for ; Mon, 3 Dec 2012 01:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQYX8HBBiK86 for ; Mon, 3 Dec 2012 01:55:30 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4B66221F86A3 for ; Mon, 3 Dec 2012 01:55:30 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 08CDF22C57A; Mon, 3 Dec 2012 10:55:29 +0100 (CET) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id D588335C06F; Mon, 3 Dec 2012 10:55:28 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Mon, 3 Dec 2012 10:55:28 +0100 From: To: =?iso-8859-1?Q?Ole_Tr=F8an?= Date: Mon, 3 Dec 2012 10:55:28 +0100 Thread-Topic: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3PMfygLIw5gwpHR+CwwetyTs8jYgCBcS3g Message-ID: <94C682931C08B048B7A8645303FDC9F36E99E2DA5B@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> In-Reply-To: <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 03 Dec 2012 09:55:31 -0000 Hi Ole, As a background, the usual modes supported by a CPE are: IPv4-only, Dual-st= ack. A natural mode to be added to the list is IPv6-only ... but this mode = is not sufficient to reflect whether IPv4 service continuity features are e= nabled in the CPE or not. This draft focuses on this service: i.e., IPv4 se= rvice continuity when only an IPv6 prefix is configured to the CPE.=20 Now for the items you listed below, I do not see them as "modes" but as a s= et of actions to be enforced based on some trigger(s). The combination of t= he actions listed below will result in a "mode".=20 The CPE will need some trigger(s) to decide which modules are to be mounted= (e.g., NAT, port restriction, etc.) and how some configuration will be enf= orced (e.g., IPv6@ of the local IPv4-in-IPv6 tunnel, IPv4 address, etc.). S= everal cases are to be considered: (1) a CPE is complied to support only one mode: no issue here. (2) a CPE supports several modes but only one mode is explicitly configured= : once a mode is enabled, the behaviour of the CPE is similar to (1) (3) the CPE supports several modes but no mode is explicitly enabled: the C= PE will need additional triggers to decide which mode to activate (e.g., If= only a Remote IPv4-in-IPv6 Tunnel Endpoint is configured, this means the s= tateful mode must be enabled). A mode is defined as a set of actions (mount= a module, configuration actions).=20 The list of actions you provided needs to be captured somehow in the draft.= I will double check the text and see whether any item is missing in -00. Thanks.=20 Cheers, Med =20 >-----Message d'origine----- >De : Ole Tr=F8an [mailto:otroan@employees.org]=20 >Envoy=E9 : vendredi 30 novembre 2012 20:36 >=C0 : BOUCADAIR Mohamed OLNC/OLN >Cc : Simon Perreault; softwires@ietf.org >Objet : Re: [Softwires] Unified Softwire CPE:=20 >draft-bfmk-softwire-unified-cpe > >Med, et al, > >> Med: The rationale we adopted in this draft is as follows: >>=20 >> * there are three major flavors: full stateful, full=20 >stateless, and binding mode >> * all these modes can support assigning a full or a shared=20 >IPv4 address > >now you got me thinking, are these really the right modes from=20 >a CPE perspective? > >let me try to explain, with my CPE implementor hat on, what=20 >"modes" would make sense? > >- NAT placement. do I need a NAT on the CPE or not? > (no NAT && no IPv4 address =3D=3D DS-lite) >- full IPv4 address assigned. > I can assign the IPv4 address to the tunnel endpoint=20 >interface, and use that address for > local applications, and as the outbound address of the NAT > (mechanisms: MAP, Public 4over6) >- IPv4 prefix assigned: > I need to disable the CPE NAT, and use the assigned IPv4=20 >prefix as my LAN side DHCPv4 pool > (mechanism: MAP) >- Shared IPv4 address. > I must enable a local NAT, I cannot assign the IPv4 address=20 >on the "WAN" interface, but only use it > for the outbound side of the NAT. > >then there might be a sub-modes for "tunnel endpoint=20 >determination" i.e. how to determine an IPv6 tunnel end point=20 >address given an IPv4 destination address and port. >1) algorithmic (MAP) >2) configured (Public 4over6, LW46, DS-lite) > >and a sub-mode for IPv4 address configuration: >1) As "native IPv4" > (Public4over6, LW46) >2) Embedded Address > (MAP) >3) None > DS-lite > >does this make sense? > >cheers, >Ole > > >= From ssenthil@cisco.com Mon Dec 3 04:02:58 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 9810D21F86D3 for ; Mon, 3 Dec 2012 04:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdqRmv7xoE0d for ; Mon, 3 Dec 2012 04:02:57 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C5FC721F86D1 for ; Mon, 3 Dec 2012 04:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3889; q=dns/txt; s=iport; t=1354536177; x=1355745777; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ldPu4zLJA94VzkAUbhyBVtMAlbHaLYfsU6PvYEUAatY=; b=OqcXvfAli325rc0UPGOvyhtqGRZHXZhfofn+dE31VIenTBL2RBqCmTHd l17cvX6ZT7CwiyQ5DV/xyFgWTfebLZnHw7KZgc2HNzIzlZIKDi44i1aYz jo5Z+KO7E6+4VK3iU0kChElJmcvob03DEBmkbn5Jr5qskhKZe1sSA27Rl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGiUvFCtJV2a/2dsb2JhbABEwAAWc4IgAQQBAQFrCxIBCCIdLgsUEQIEAQ0FCIgIDL4eBIxAg2BhA4gpnh+CcoIh X-IronPort-AV: E=McAfee;i="5400,1158,6914"; a="148678673" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 03 Dec 2012 12:02:57 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qB3C2vEX029158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Dec 2012 12:02:57 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.148]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Mon, 3 Dec 2012 06:02:56 -0600 From: "Senthil Sivakumar (ssenthil)" To: "mohamed.boucadair@orange.com" , =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: AQHN0U4h/AgQwUpjbEC3q/SYGDKY0A== Date: Mon, 3 Dec 2012 12:02:56 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2DA5B@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.117.198.141] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 03 Dec 2012 12:02:58 -0000 On 12/3/12 4:55 AM, "mohamed.boucadair@orange.com" wrote: >Hi Ole, > >As a background, the usual modes supported by a CPE are: IPv4-only, >Dual-stack. A natural mode to be added to the list is IPv6-only ... but >this mode is not sufficient to reflect whether IPv4 service continuity >features are enabled in the CPE or not. This draft focuses on this >service: i.e., IPv4 service continuity when only an IPv6 prefix is >configured to the CPE. > >Now for the items you listed below, I do not see them as "modes" but as a >set of actions to be enforced based on some trigger(s). The combination >of the actions listed below will result in a "mode". > >The CPE will need some trigger(s) to decide which modules are to be >mounted (e.g., NAT, port restriction, etc.) and how some configuration >will be enforced (e.g., IPv6@ of the local IPv4-in-IPv6 tunnel, IPv4 >address, etc.). Several cases are to be considered: > >(1) a CPE is complied to support only one mode: no issue here. >(2) a CPE supports several modes but only one mode is explicitly >configured: once a mode is enabled, the behaviour of the CPE is similar >to (1) >(3) the CPE supports several modes but no mode is explicitly enabled: the >CPE will need additional triggers to decide which mode to activate (e.g., >If only a Remote IPv4-in-IPv6 Tunnel Endpoint is configured, this means >the stateful mode must be enabled). A mode is defined as a set of actions >(mount a module, configuration actions). To make this list complete, #4 should be CPE supports several modes and several modes are configured. Thanks Senthil > >The list of actions you provided needs to be captured somehow in the >draft. I will double check the text and see whether any item is missing >in -00. > >Thanks.=20 > >Cheers, >Med >=20 > >>-----Message d'origine----- >>De : Ole Tr=F8an [mailto:otroan@employees.org] >>Envoy=E9 : vendredi 30 novembre 2012 20:36 >>=C0 : BOUCADAIR Mohamed OLNC/OLN >>Cc : Simon Perreault; softwires@ietf.org >>Objet : Re: [Softwires] Unified Softwire CPE: >>draft-bfmk-softwire-unified-cpe >> >>Med, et al, >> >>> Med: The rationale we adopted in this draft is as follows: >>>=20 >>> * there are three major flavors: full stateful, full >>stateless, and binding mode >>> * all these modes can support assigning a full or a shared >>IPv4 address >> >>now you got me thinking, are these really the right modes from >>a CPE perspective? >> >>let me try to explain, with my CPE implementor hat on, what >>"modes" would make sense? >> >>- NAT placement. do I need a NAT on the CPE or not? >> (no NAT && no IPv4 address =3D=3D DS-lite) >>- full IPv4 address assigned. >> I can assign the IPv4 address to the tunnel endpoint >>interface, and use that address for >> local applications, and as the outbound address of the NAT >> (mechanisms: MAP, Public 4over6) >>- IPv4 prefix assigned: >> I need to disable the CPE NAT, and use the assigned IPv4 >>prefix as my LAN side DHCPv4 pool >> (mechanism: MAP) >>- Shared IPv4 address. >> I must enable a local NAT, I cannot assign the IPv4 address >>on the "WAN" interface, but only use it >> for the outbound side of the NAT. >> >>then there might be a sub-modes for "tunnel endpoint >>determination" i.e. how to determine an IPv6 tunnel end point >>address given an IPv4 destination address and port. >>1) algorithmic (MAP) >>2) configured (Public 4over6, LW46, DS-lite) >> >>and a sub-mode for IPv4 address configuration: >>1) As "native IPv4" >> (Public4over6, LW46) >>2) Embedded Address >> (MAP) >>3) None >> DS-lite >> >>does this make sense? >> >>cheers, >>Ole >> >> >> >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From sunqi.csnet.thu@gmail.com Mon Dec 3 05:13:52 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 8768421F8714 for ; Mon, 3 Dec 2012 05:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W98-1z0OqDHq for ; Mon, 3 Dec 2012 05:13:52 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F33E921F8704 for ; Mon, 3 Dec 2012 05:13:51 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so1874478pbc.31 for ; Mon, 03 Dec 2012 05:13:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Q+1Yitm7A0vDmY6lAV9DebXJGwKemOe2bW67mS+d3lU=; b=o5pmok0tWKcU4AkDaqGk645lDkL1q7lgQ2+eEHeqMlQ1B6qmCJBWBvo87u6i1b1O1d thYNlKk7FE6XWEnJH5Jq4kualDJmzBi6RkZfMUym9a0KsknnxxVnXFuo5JqmNhZ4Duic Lc+pBzMGTooM6iy4ocMpmRph1m1tHw11k/vVBYpoSkdp4Nq/fpFl7myN7mCLJjbVF4BZ fLTa9cLCSgA1SiwnmUyvTCUa6KS6+u/Z5vr6C1El/F/mESqPmjlOsZbhgeeQ4Pw03D1Y D6Sl9mmLZ3VWzEXt8LLnue96BPuk7MZAtH0aZzYyl49I/CNzbE80LJ9E8qdh8DcS1uId XpYQ== Received: by 10.68.241.231 with SMTP id wl7mr28674578pbc.164.1354540431670; Mon, 03 Dec 2012 05:13:51 -0800 (PST) Received: from [192.168.0.109] ([114.255.41.137]) by mx.google.com with ESMTPS id oi3sm8059204pbb.1.2012.12.03.05.13.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 05:13:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Mon, 3 Dec 2012 21:13:22 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <051213C3-F4A1-4EF2-9725-DBCD82975441@gmail.com> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <50B9B5C7.107@viagenie.ca> <10C9FD27-2894-4495-90E1-15A9AC9D73B9@employees.org> <8A1B81989BCFAE44A22B2B86BF2B76318954FEE360@HE111643.EMEA1.CDS.T-INTERNAL.COM> To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-Mailer: Apple Mail (2.1084) Cc: softwires@ietf.org Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 03 Dec 2012 13:13:52 -0000 Ole, On 2012-12-3, at =E4=B8=8B=E5=8D=885:06, Ole Tr=C3=B8an wrote: > Ian, >=20 >> Whichever state is selected, NAT is certainly fundamental to how the = state will operate and so we tried to weave it into the functional = description. I'm not sure that provisioned NAT info enough to be able to = use to unambiguously define with operating 'mode' (for want of a better = word) to use. >>=20 >> One of the reasons for the use of state in the draft is try and = define the operating modes with as little overlap as possible (it's not = 100%, but there's only 1 exception at the moment for binding mode and = MAP1:1). =46rom this, then it is easier to align the specific solution = names to the state characteristics. >=20 > I don't think you should try to define modes such that the map (no pun = intended) into the specific solution names. > shouldn't the purpose of a "unified CPE", be for the CPE not to have = to care about the different "deployment modes" on the head end? [Qi] I think the modes are "functional modes" rather than "deployment = modes". CPE has different functional characteristics under different = modes and it has to know what behavior it should perform under different = mode.=20 >=20 >> But, with what you've suggested, there is more overlap, i.e. both 2&4 = have NAT functions that are supported by two different mechanisms. >>=20 >> However, what you've said does raise the following point: >>=20 >> The way that state is described in the draft at the moment is = actually taken from a concentrator perspective. This could be taken to = be almost the inverse of the amount of state that is required from the = CPEs perspective (i.e. if all of the state is in the providers network = (DS-Lite), then the CPE doesn't need it. If the providers network has = less state ('per-customer', 'stateless'), then the CPE needs to have = more - i.e. dynamic state table for NAT, configuration for local = IPv4/port set, MAPing rules etc. >>=20 >> Would describing the different states more from the CPE's perspective = make this clearer? >=20 > that would certainly help. although I don't think "state" is the = defining characteristic. [Qi] IMHO, using state as the defining characteristic, the CPE can = determine which module to mount and which functionality to perform. Best Regards, Qi >=20 > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From mark@townsley.net Mon Dec 3 08:21:27 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 5CEB021F87E7 for ; Mon, 3 Dec 2012 08:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-2aA8xwAHYH for ; Mon, 3 Dec 2012 08:21:23 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFA021F87EE for ; Mon, 3 Dec 2012 08:21:22 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1362203eaa.31 for ; Mon, 03 Dec 2012 08:21:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=lFQ3rSW01+K8lwBlRaLasbbN4Oivu/C13myz2oLE908=; b=nerxjfMA0KpvGlrlmkOfMlcZijnSgmrWuWUHUr/7RXUCdMM8aXa8sh1eMWCGW39jQ/ q1XWB+9Di4fx6vuVkRukDUrwUCrD4hupkX0VszHHA2EQVkiIe8r1PC7ZhrZ8ermDg5WZ AYECMNj7JnZeF08VEevLVx0Tqn+ah+Pfz8NGgbEPyhkfAzd7+ZXD0MHjgn7TOKfv8dud QI0EzO8frerxi757+msiA/ePbUyYuVM4qAMNx9mHpPLTlZxOUe7PzwTvNpNGIhZf+rh3 BZ8nBhEoNFLSRSjJikkEr7uU3AFHjl2wd44/0UeHJaydtDVK9cBDBXB/aTcyKUKkl4q9 gWog== Received: by 10.14.174.198 with SMTP id x46mr31166006eel.23.1354551680407; Mon, 03 Dec 2012 08:21:20 -0800 (PST) Received: from ?IPv6:2001:420:c0c1:8:b8ab:d0c6:3bc3:1c9f? ([2001:420:c0c1:8:b8ab:d0c6:3bc3:1c9f]) by mx.google.com with ESMTPS id q44sm32094098eep.5.2012.12.03.08.21.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 08:21:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Mon, 3 Dec 2012 17:21:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <879A574D-0C40-4E98-8A3E-982CC198E93C@townsley.net> References: <439604D3-5BC4-4E50-898B-2CBB28764B03@townsley.net> To: Leaf yeh X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQkusp318AqgOSQg79F8wrXRUtWHZNuTK0+Nc+L3IOCphqUF/7S3+OX8X4zLrOcNV6qz2TO/ Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA 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, 03 Dec 2012 16:21:27 -0000 Let's get back to basics.=20 The encapsulation and forwarding of packets between tunnel endpoints is = supported by a combination of configuration state and mapped bits, if = any.=20 There are 48 bits of IPv4 address+port space. You can map 0 or more of = these bits into the 128 bits of IPv6 space. The more bits you map = between IPv4 and IPv6, the less configuration state you need to support = a given set of IPv4 endpoints over an IPv6 network. The less bits you = map, the more configuration state you need for that same number of = endpoints. The dial can be set to 0 mapped bits, somewhere in the = middle, or even cranked all the way to 48 from a theoretical perspective = (though IPv4 service with a single port seems pretty questionable, one = never knows...). =20 This is all easily supported with a single algorithm and a well-defined = set of parameters which can be configured via CLI, DHCP, TR69, or = pick-your-favorite-mechnanism. These well-defined set of parameters are = the coefficients into the single common algorithm that the network = equipment has to support. Having one configurable algorithm and protocol = to support is far better for the CPE industry than two or more. Since = this technology depends on the CPE industry for its success, it would = behoove us to keep that in mind. We should also remember that the CPE = industry is traditionally not particularly well represented in the IETF = vs. large equipment vendors and operators, so we may have to listen = especially carefully here.=20 So to the point below, one protocol that supports two kinds of = deployments is a Good Thing. In fact, the truly successful investments = in standard protocols are those which are general and flexible enough to = support uses the authors didn't even consider at the time (re: RFC = 5218). - Mark On Nov 30, 2012, at 5:13 AM, Leaf yeh wrote: > Mark - I think the only question that should be on the table is = whether a 1:1 rule is called something different or not - kind of like = how we refer to a /32 or /128 as a hostroute. >=20 > Even in the case of MAP-E 1:1, there still has 2 kinds of deployments: >=20 > a. map PSID into the EA bits of the delegated end-user IPv6 prefix; > b. length of EA bits =3D 0, which might mean no mapping at all; >=20 >=20 > Best Regards, > Leaf >=20 >=20 >=20 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf Of Mark Townsley > Sent: Thursday, November 29, 2012 10:04 PM > To: Lee, Yiu > Cc: softwires@ietf.org > Subject: Re: [Softwires] MAP-E 1:1 for HA >=20 >=20 > I think Rajiv's point is more about how summarization of routes in IP = brings fundamental scalability advantages for IP routers, not whether = the routes are programmed with a what is traditionally referred to as a = "routing protocol" or via CLI, DHCP, netconf/yang, XML, or however the = MAP rules are programmed in a given network. >=20 > Another way of saying this is that, in IP (v4, for example here) a /32 = route is no different than a /31, /24, etc. other than a /32 just = happens to refer to one address rather than two or more. The routing = system *could* be run with /32s everywhere, and while scalability would = suffer tremendously, hosts would have the flexibility to be numbered = with a static unique address no matter where the user connected to the = network. The system would have IP mobility built right in! No need for = Mobile IP tunnels! It's all possible right now, just turn the state = dial all the way to the right and enjoy. The point where your existing = equipment falls over requiring you to redesign the network accordingly = depends on the number of hosts, limitations in routers, churn and = convergence, etc. but there is nothing prohibiting this per se in the = protocol design - it's all just IP and CIDR. >=20 > Relating this to MAP: At one extreme, you can choose to setup rules in = advance such that rule aggregation is possible to a degree whereby MAP = can be supported inline with routers positioned where they normally = would for regular IPv6 forwarding. At the other extreme, you have less = aggregation and at some point you'll probably have to introduce = special-purpose tunnel concentrator hardware at specific locations. The = point where this crossover occurs isn't necessarily at the 1:1 MAP rule = point, it could be 2:1, 8:1, 256:1... it all depends on how many MAP = rules are supported by the vendor equipment chosen and the number of = endpoints being addressed. >=20 > Just as map supports 2^32:1,... 8192:1, 4096:1, 2048:1, 512:1, 256:1, = 128:1, 64:1, 32:1, 16:1, 8:1, 4:1, or 2:1, it follows pretty clearly = that it should also support 1:1 - to do otherwise would be arbitrary. I = think the only question that should be on the table is whether a 1:1 = rule is called something different or not - kind of like how we refer to = a /32 or /128 as a hostroute. We could have a MAP "hostrule" for 1:1, = and "aggregate-rule" for N:1. Vendor equipment optimized for 1:1 mode = would advertise how many "hostrules" it can support. A more general MAP = implementation might advertise x number of "rules", aggregate or not. = The protocol mechanism from Softwires remains happily agnostic to all of = this; To the protocol, its nothing more than semantics. >=20 > Bottom line, "Stateless operation" is a variable tipping point... It's = roughly the point where you can no longer affordably stuff all rules = into all border routers in your network. If you have 2 rules for = millions of endpoints, it's pretty easy to see that stateless operation = is possible. If you have millions of rules for millions of endpoints, = it's probably not. It's all highly dependent on the hardware, size, and = design of the network. >=20 > Softwires should focus on the best protocol design, and let the = vendors, operators and market battle over where to turn the dial and = what to optimize for in their implementations and deployments. >=20 > - Mark >=20 > On Nov 16, 2012, at 12:19 AM, Lee, Yiu wrote: >=20 >> Hi Rajiv, >>=20 >> With all due respect, I disagree the analogy. Comparing MAP-E to = routing >> protocol is comparing apple to orange. MAP-E is not a routing = protocol. >> MAP-E won't synchronize or exchange states between two BRs. Instead, = MAP-E >> requires to statically provision states (aka rules) in the BR. = Original >> MAP-E describes a mechanism to reduce user states in BR by using >> programatic logic. 1:1 MAP-E does not require any of the good stuff >> defined in MAP-E. I just found it odd to combine stateful and = stateless >> mechanisms in a single draft and use a same name. >>=20 >> Thanks, >> Yiu >>=20 >>=20 >> On 11/12/12 2:51 PM, "Rajiv Asati (rajiva)" wrote: >>=20 >>>=20 >>> Sure, and it is really a deployment choice (just like it is a = deployment >>> choice to use a dynamic routing protocol to advertise host routes or >>> summary routes or both in an IP network). But that's not to say that = we >>> need one protocol for advertising the host routes, and another for >>> advertising the summary routes. >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>> -----Original Message----- >>> From: Yiu Lee >>> Date: Monday, November 12, 2012 1:33 PM >>> To: Rajiv Asati , Softwires-wg list = >>> Subject: Re: [Softwires] MAP-E 1:1 for HA >>>=20 >>>> I am not talking about whether a MAP-domain should support 1 or N = CEs. >>>> What I am trying to say is MAP-E 1:1 requires the BR to know per >>>> subscriber information and the operator must pre-provision = per-subscriber >>>> based rules to every BR in the same domain. In addition, the BR = can't use >>>> programatic logic to reduce states. When the WG first decided to = work on >>>> a >>>> "stateless" solution, the goal was to make BR as stateless as = possible. >>>> MAP-E 1:1 in contrast requires to store all subscriber rules in the = BR >>>> and >>>> can't derive the CE's IPv6 address using programatic logic. I found = it >>>> odd >>>> to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 = looks a >>>> stateful solution to me. >>>>=20 >>>>=20 >>>> On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" = wrote: >>>>=20 >>>>>=20 >>>>> One can define a MAP-domain consisting of 1 CE or N CEs. This is = more of >>>>> a >>>>> deployment choice. >>>>>=20 >>>>> Cheers, >>>>> Rajiv >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: , Yiu Lee >>>>> Date: Friday, November 9, 2012 2:43 PM >>>>> To: Softwires-wg list >>>>> Subject: [Softwires] MAP-E 1:1 for HA >>>>>=20 >>>>>> I have a question for the HA design concept of MAP-E 1:1. The = central >>>>>> theme of MAP-E is to make BR as stateless as possible and use = Anycast >>>>>> address to identify the MAP-E BR. However, if we use MAP-E 1:1 = mode, >>>>>> the >>>>>> operator must have to pre-provision all >>>>>> the subscribe rules to all the BRs sharing the same Anycast = address >>>>>> for >>>>>> reliable HA. This requires operators to carefully plan out which = BRs >>>>>> support which subscribers. It is because BR is "per-subscriber >>>>>> stateful" >>>>>> in MAP-E 1:1 mode. Compared to the MAP-E design, >>>>>> HA in MAP-E only requires the operators to use the same set of = rules >>>>>> to >>>>>> cover the entire domain. IMHO, this contradicts the original = spirit of >>>>>> stateless solution and always puzzles me why MAP-E 1:1 bears the = MAP-E >>>>>> name. MAP-E and 1:1 MAP-E are two completely >>>>>> different solutions and target to different deployment scenarios. = I >>>>>> would love to hear others to comment in the ML how to resolve = this >>>>>> issue. >>>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Yiu >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From leaf.y.yeh@huawei.com Mon Dec 3 19:33: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 BA6B51F0C67 for ; Mon, 3 Dec 2012 19:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=-0.381, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6YecJq0c5KI for ; Mon, 3 Dec 2012 19:33:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B05011F0C61 for ; Mon, 3 Dec 2012 19:33:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMD57184; Tue, 04 Dec 2012 03:33:41 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Dec 2012 03:33:16 +0000 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Dec 2012 03:33:40 +0000 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.9]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Tue, 4 Dec 2012 11:33:32 +0800 From: Leaf yeh To: Mark Townsley Thread-Topic: [Softwires] MAP-E 1:1 for HA Thread-Index: AQHNvrJUhwE7DtDnmkmwZYkUbhoBV5firlkAgANWdgCAABXjAIAE8R2AgBVlWgCAAW4JkIAFAb0AgAE5z8A= Date: Tue, 4 Dec 2012 03:33:30 +0000 Message-ID: References: <439604D3-5BC4-4E50-898B-2CBB28764B03@townsley.net> <879A574D-0C40-4E98-8A3E-982CC198E93C@townsley.net> In-Reply-To: <879A574D-0C40-4E98-8A3E-982CC198E93C@townsley.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E 1:1 for HA 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, 04 Dec 2012 03:33:44 -0000 Mark - In fact, the truly successful investments in standard protocols are = those which are general and flexible enough to support uses the authors did= n't even consider at the time (re: RFC 5218). Good training point...Thanks. Best Regards, Leaf -----Original Message----- From: Mark Townsley [mailto:mark@townsley.net]=20 Sent: Tuesday, December 04, 2012 12:21 AM To: Leaf yeh Cc: Lee, Yiu; softwires@ietf.org Subject: Re: [Softwires] MAP-E 1:1 for HA Let's get back to basics.=20 The encapsulation and forwarding of packets between tunnel endpoints is sup= ported by a combination of configuration state and mapped bits, if any.=20 There are 48 bits of IPv4 address+port space. You can map 0 or more of thes= e bits into the 128 bits of IPv6 space. The more bits you map between IPv4 = and IPv6, the less configuration state you need to support a given set of I= Pv4 endpoints over an IPv6 network. The less bits you map, the more configu= ration state you need for that same number of endpoints. The dial can be se= t to 0 mapped bits, somewhere in the middle, or even cranked all the way to= 48 from a theoretical perspective (though IPv4 service with a single port = seems pretty questionable, one never knows...). =20 This is all easily supported with a single algorithm and a well-defined set= of parameters which can be configured via CLI, DHCP, TR69, or pick-your-fa= vorite-mechnanism. These well-defined set of parameters are the coefficient= s into the single common algorithm that the network equipment has to suppor= t. Having one configurable algorithm and protocol to support is far better = for the CPE industry than two or more. Since this technology depends on the= CPE industry for its success, it would behoove us to keep that in mind. We= should also remember that the CPE industry is traditionally not particular= ly well represented in the IETF vs. large equipment vendors and operators, = so we may have to listen especially carefully here.=20 So to the point below, one protocol that supports two kinds of deployments = is a Good Thing. In fact, the truly successful investments in standard prot= ocols are those which are general and flexible enough to support uses the a= uthors didn't even consider at the time (re: RFC 5218). - Mark On Nov 30, 2012, at 5:13 AM, Leaf yeh wrote: > Mark - I think the only question that should be on the table is whether a= 1:1 rule is called something different or not - kind of like how we refer = to a /32 or /128 as a hostroute. >=20 > Even in the case of MAP-E 1:1, there still has 2 kinds of deployments: >=20 > a. map PSID into the EA bits of the delegated end-user IPv6 prefix; > b. length of EA bits =3D 0, which might mean no mapping at all; >=20 >=20 > Best Regards, > Leaf >=20 >=20 >=20 > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On B= ehalf Of Mark Townsley > Sent: Thursday, November 29, 2012 10:04 PM > To: Lee, Yiu > Cc: softwires@ietf.org > Subject: Re: [Softwires] MAP-E 1:1 for HA >=20 >=20 > I think Rajiv's point is more about how summarization of routes in IP bri= ngs fundamental scalability advantages for IP routers, not whether the rout= es are programmed with a what is traditionally referred to as a "routing pr= otocol" or via CLI, DHCP, netconf/yang, XML, or however the MAP rules are p= rogrammed in a given network. >=20 > Another way of saying this is that, in IP (v4, for example here) a /32 ro= ute is no different than a /31, /24, etc. other than a /32 just happens to = refer to one address rather than two or more. The routing system *could* be= run with /32s everywhere, and while scalability would suffer tremendously,= hosts would have the flexibility to be numbered with a static unique addre= ss no matter where the user connected to the network. The system would have= IP mobility built right in! No need for Mobile IP tunnels! It's all possi= ble right now, just turn the state dial all the way to the right and enjoy.= The point where your existing equipment falls over requiring you to redesi= gn the network accordingly depends on the number of hosts, limitations in r= outers, churn and convergence, etc. but there is nothing prohibiting this p= er se in the protocol design - it's all just IP and CIDR. >=20 > Relating this to MAP: At one extreme, you can choose to setup rules in ad= vance such that rule aggregation is possible to a degree whereby MAP can be= supported inline with routers positioned where they normally would for reg= ular IPv6 forwarding. At the other extreme, you have less aggregation and a= t some point you'll probably have to introduce special-purpose tunnel conce= ntrator hardware at specific locations. The point where this crossover occu= rs isn't necessarily at the 1:1 MAP rule point, it could be 2:1, 8:1, 256:1= ... it all depends on how many MAP rules are supported by the vendor equipm= ent chosen and the number of endpoints being addressed. >=20 > Just as map supports 2^32:1,... 8192:1, 4096:1, 2048:1, 512:1, 256:1, 128= :1, 64:1, 32:1, 16:1, 8:1, 4:1, or 2:1, it follows pretty clearly that it s= hould also support 1:1 - to do otherwise would be arbitrary. I think the on= ly question that should be on the table is whether a 1:1 rule is called som= ething different or not - kind of like how we refer to a /32 or /128 as a h= ostroute. We could have a MAP "hostrule" for 1:1, and "aggregate-rule" for = N:1. Vendor equipment optimized for 1:1 mode would advertise how many "host= rules" it can support. A more general MAP implementation might advertise x = number of "rules", aggregate or not. The protocol mechanism from Softwires = remains happily agnostic to all of this; To the protocol, its nothing more = than semantics. >=20 > Bottom line, "Stateless operation" is a variable tipping point... It's ro= ughly the point where you can no longer affordably stuff all rules into all= border routers in your network. If you have 2 rules for millions of endpoi= nts, it's pretty easy to see that stateless operation is possible. If you h= ave millions of rules for millions of endpoints, it's probably not. It's al= l highly dependent on the hardware, size, and design of the network. >=20 > Softwires should focus on the best protocol design, and let the vendors, = operators and market battle over where to turn the dial and what to optimiz= e for in their implementations and deployments. >=20 > - Mark >=20 > On Nov 16, 2012, at 12:19 AM, Lee, Yiu wrote: >=20 >> Hi Rajiv, >>=20 >> With all due respect, I disagree the analogy. Comparing MAP-E to routing >> protocol is comparing apple to orange. MAP-E is not a routing protocol. >> MAP-E won't synchronize or exchange states between two BRs. Instead, MAP= -E >> requires to statically provision states (aka rules) in the BR. Original >> MAP-E describes a mechanism to reduce user states in BR by using >> programatic logic. 1:1 MAP-E does not require any of the good stuff >> defined in MAP-E. I just found it odd to combine stateful and stateless >> mechanisms in a single draft and use a same name. >>=20 >> Thanks, >> Yiu >>=20 >>=20 >> On 11/12/12 2:51 PM, "Rajiv Asati (rajiva)" wrote: >>=20 >>>=20 >>> Sure, and it is really a deployment choice (just like it is a deploymen= t >>> choice to use a dynamic routing protocol to advertise host routes or >>> summary routes or both in an IP network). But that's not to say that we >>> need one protocol for advertising the host routes, and another for >>> advertising the summary routes. >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>> -----Original Message----- >>> From: Yiu Lee >>> Date: Monday, November 12, 2012 1:33 PM >>> To: Rajiv Asati , Softwires-wg list >>> Subject: Re: [Softwires] MAP-E 1:1 for HA >>>=20 >>>> I am not talking about whether a MAP-domain should support 1 or N CEs. >>>> What I am trying to say is MAP-E 1:1 requires the BR to know per >>>> subscriber information and the operator must pre-provision per-subscri= ber >>>> based rules to every BR in the same domain. In addition, the BR can't = use >>>> programatic logic to reduce states. When the WG first decided to work = on >>>> a >>>> "stateless" solution, the goal was to make BR as stateless as possible= . >>>> MAP-E 1:1 in contrast requires to store all subscriber rules in the BR >>>> and >>>> can't derive the CE's IPv6 address using programatic logic. I found it >>>> odd >>>> to include MAP-1 1:1 be part of a stateless solution. MAP-E 1:1 looks = a >>>> stateful solution to me. >>>>=20 >>>>=20 >>>> On 11/10/12 1:34 AM, "Rajiv Asati (rajiva)" wrote: >>>>=20 >>>>>=20 >>>>> One can define a MAP-domain consisting of 1 CE or N CEs. This is more= of >>>>> a >>>>> deployment choice. >>>>>=20 >>>>> Cheers, >>>>> Rajiv >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: , Yiu Lee >>>>> Date: Friday, November 9, 2012 2:43 PM >>>>> To: Softwires-wg list >>>>> Subject: [Softwires] MAP-E 1:1 for HA >>>>>=20 >>>>>> I have a question for the HA design concept of MAP-E 1:1. The centra= l >>>>>> theme of MAP-E is to make BR as stateless as possible and use Anycas= t >>>>>> address to identify the MAP-E BR. However, if we use MAP-E 1:1 mode, >>>>>> the >>>>>> operator must have to pre-provision all >>>>>> the subscribe rules to all the BRs sharing the same Anycast address >>>>>> for >>>>>> reliable HA. This requires operators to carefully plan out which BRs >>>>>> support which subscribers. It is because BR is "per-subscriber >>>>>> stateful" >>>>>> in MAP-E 1:1 mode. Compared to the MAP-E design, >>>>>> HA in MAP-E only requires the operators to use the same set of rules >>>>>> to >>>>>> cover the entire domain. IMHO, this contradicts the original spirit= of >>>>>> stateless solution and always puzzles me why MAP-E 1:1 bears the MAP= -E >>>>>> name. MAP-E and 1:1 MAP-E are two completely >>>>>> different solutions and target to different deployment scenarios. I >>>>>> would love to hear others to comment in the ML how to resolve this >>>>>> issue. >>>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>> Yiu >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>=20 >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ian.farrer@telekom.de Tue Dec 4 09:53: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 80F9D21F8BA3 for ; Tue, 4 Dec 2012 09:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M15zH4j+uPlE for ; Tue, 4 Dec 2012 09:53:09 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 6989021F8A72 for ; Tue, 4 Dec 2012 09:53:09 -0800 (PST) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 04 Dec 2012 18:52:59 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 4 Dec 2012 18:52:59 +0100 From: To: Date: Tue, 4 Dec 2012 18:53:03 +0100 Thread-Topic: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: Ac3RNXz/TtpXktATTmOZH241WH5xogBESg9w Message-ID: <8A1B81989BCFAE44A22B2B86BF2B7631895539BCBC@HE111643.EMEA1.CDS.T-INTERNAL.COM> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <50B9B5C7.107@viagenie.ca> <10C9FD27-2894-4495-90E1-15A9AC9D73B9@employees.org> <8A1B81989BCFAE44A22B2B86BF2B76318954FEE360@HE111643.EMEA1.CDS.T-INTERNAL.COM> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires@ietf.org Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 04 Dec 2012 17:53:10 -0000 Hi Ole, Answers inline. Cheers, Ian -----Original Message----- From: Ole Tr=F8an [mailto:otroan@employees.org]=20 Sent: Montag, 3. Dezember 2012 10:06 To: Farrer, Ian Cc: simon.perreault@viagenie.ca; softwires@ietf.org Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-= cpe Ian, > Whichever state is selected, NAT is certainly fundamental to how the stat= e will operate and so we tried to weave it into the functional description.= I'm not sure that provisioned NAT info enough to be able to use to unambig= uously define with operating 'mode' (for want of a better word) to use. >=20 > One of the reasons for the use of state in the draft is try and define th= e operating modes with as little overlap as possible (it's not 100%, but th= ere's only 1 exception at the moment for binding mode and MAP1:1). From thi= s, then it is easier to align the specific solution names to the state char= acteristics. I don't think you should try to define modes such that the map (no pun inte= nded) into the specific solution names. shouldn't the purpose of a "unified CPE", be for the CPE not to have to car= e about the different "deployment modes" on the head end? Ian: But a MAP CPE does have to care about what is on the tunnel head end a= s it could be another mesh client, or it could be the BR. It uses a differe= nt mapping rule type for each, so it is aware of the capabilities of the he= ad end. > But, with what you've suggested, there is more overlap, i.e. both 2&4 hav= e NAT functions that are supported by two different mechanisms. >=20 > However, what you've said does raise the following point: >=20 > The way that state is described in the draft at the moment is actually ta= ken from a concentrator perspective. This could be taken to be almost the i= nverse of the amount of state that is required from the CPEs perspective (i= .e. if all of the state is in the providers network (DS-Lite), then the CPE= doesn't need it. If the providers network has less state ('per-customer', = 'stateless'), then the CPE needs to have more - i.e. dynamic state table fo= r NAT, configuration for local IPv4/port set, MAPing rules etc. >=20 > Would describing the different states more from the CPE's perspective mak= e this clearer? that would certainly help. although I don't think "state" is the defining c= haracteristic. Ian: Is the problem with the what's being described (i.e. the content and f= unctional differentiations) or the naming and terminology used to describe = it? cheers, Ole= From Tina.Tsou.Zouting@huawei.com Wed Dec 5 10:36:26 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 B8A2421F841C for ; Wed, 5 Dec 2012 10:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDiEByPvamGJ for ; Wed, 5 Dec 2012 10:36:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DCD9F21F8CB6 for ; Wed, 5 Dec 2012 10:36:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMF16335; Wed, 05 Dec 2012 18:36:22 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 18:34:01 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 18:34:29 +0000 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.39]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Wed, 5 Dec 2012 10:34:23 -0800 From: Tina TSOU To: "ian.farrer@telekom.de" Thread-Topic: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: AQHN0khV9YskOFlbW0GC3UgDD05lepgKibrJ Date: Wed, 5 Dec 2012 18:34:23 +0000 Message-ID: <8B727D3A-2531-49C8-808B-91EE79AC9453@huawei.com> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <50B9B5C7.107@viagenie.ca> <10C9FD27-2894-4495-90E1-15A9AC9D73B9@employees.org> <8A1B81989BCFAE44A22B2B86BF2B76318954FEE360@HE111643.EMEA1.CDS.T-INTERNAL.COM> , <8A1B81989BCFAE44A22B2B86BF2B7631895539BCBC@HE111643.EMEA1.CDS.T-INTERNAL.COM> In-Reply-To: <8A1B81989BCFAE44A22B2B86BF2B7631895539BCBC@HE111643.EMEA1.CDS.T-INTERNAL.COM> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_8B727D3A253149C8808B91EE79AC9453huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 05 Dec 2012 18:36:26 -0000 --_000_8B727D3A253149C8808B91EE79AC9453huaweicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Med, Ian and Suresh, Great job! Draft-bfmk is written very well to reach consensus. Two small comments are below. 1. I=92m not sure whether it is appropriate to put DS-Lite case into t= he document, since in DS-Lite case the CPE is only the tunnel end point wit= hout NAT, which is basically different with lw4over6/MAP. But if the object= ive of this document is to define an unified CPE for all the 4over6 mechani= sms, other mechanisms like public 4over6 should also be included in the doc= ument. My understanding may be wrong. 2. The title says =93unified softwire CPE=94, but in softwire, there a= re many other transition technologies, e.g., 6rd. To be specific, maybe 4ov= er6 CPE is more appropriate. Thank you, Tina On Dec 4, 2012, at 9:53 AM, "ian.farrer@telekom.de" > wrote: Hi Ole, Answers inline. Cheers, Ian -----Original Message----- From: Ole Tr=F8an [mailto:otroan@employees.org] Sent: Montag, 3. Dezember 2012 10:06 To: Farrer, Ian Cc: simon.perreault@viagenie.ca; softwi= res@ietf.org Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-= cpe Ian, Whichever state is selected, NAT is certainly fundamental to how the state = will operate and so we tried to weave it into the functional description. I= 'm not sure that provisioned NAT info enough to be able to use to unambiguo= usly define with operating 'mode' (for want of a better word) to use. One of the reasons for the use of state in the draft is try and define the = operating modes with as little overlap as possible (it's not 100%, but ther= e's only 1 exception at the moment for binding mode and MAP1:1). From this,= then it is easier to align the specific solution names to the state charac= teristics. I don't think you should try to define modes such that the map (no pun inte= nded) into the specific solution names. shouldn't the purpose of a "unified CPE", be for the CPE not to have to car= e about the different "deployment modes" on the head end? Ian: But a MAP CPE does have to care about what is on the tunnel head end a= s it could be another mesh client, or it could be the BR. It uses a differe= nt mapping rule type for each, so it is aware of the capabilities of the he= ad end. But, with what you've suggested, there is more overlap, i.e. both 2&4 have = NAT functions that are supported by two different mechanisms. However, what you've said does raise the following point: The way that state is described in the draft at the moment is actually take= n from a concentrator perspective. This could be taken to be almost the inv= erse of the amount of state that is required from the CPEs perspective (i.e= . if all of the state is in the providers network (DS-Lite), then the CPE d= oesn't need it. If the providers network has less state ('per-customer', 's= tateless'), then the CPE needs to have more - i.e. dynamic state table for = NAT, configuration for local IPv4/port set, MAPing rules etc. Would describing the different states more from the CPE's perspective make = this clearer? that would certainly help. although I don't think "state" is the defining c= haracteristic. Ian: Is the problem with the what's being described (i.e. the content and f= unctional differentiations) or the naming and terminology used to describe = it? cheers, Ole _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_8B727D3A253149C8808B91EE79AC9453huaweicom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear Med, Ian and Suresh,
Great job! Draft-bfmk is written very well to reach consensus.

Two small comments are below.

1.      I=92m not sure whether it is appropriate to = put DS-Lite case into the document, since in DS-Lite case the CPE is only the tunnel end point without NAT, which is basically different with lw4ove= r6/MAP. But if the objective of this document is to define an unified CPE f= or all the 4over6 mechanisms, other mechanisms like public 4over6 should al= so be included in the document. My understanding may be wrong.

2.      The title says =93unified softwire CPE=94, b= ut in softwire, there are many other transition technologies, e.g., 6rd. To be specific, maybe 4over6 CPE is more appropriate.


Thank you,
Tina

On Dec 4, 2012, at 9:53 AM, "= ian.farrer@telekom.de" <ian.farrer@telekom.de> wrote:

Hi Ole,

Answers inline.

Cheers,
Ian

-----Original Message-----
From: Ole Tr=F8an [mailto:otroan@employees.org]
Sent: Montag, 3. Dezember 2012 10:06
To: Farrer, Ian
Cc: simon.perreault@vi= agenie.ca; softwires@ietf.org
Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-un= ified-cpe

Ian,

Whichever state is selected, NAT is certain= ly fundamental to how the state will operate and so we tried to weave it in= to the functional description. I'm not sure that provisioned NAT info enoug= h to be able to use to unambiguously define with operating 'mode' (for want of a better word) to use.

One of the reasons for the use of state in = the draft is try and define the operating modes with as little overlap as p= ossible (it's not 100%, but there's only 1 exception at the moment for bind= ing mode and MAP1:1). From this, then it is easier to align the specific solution names to the state characteris= tics.

I don't think you should try to define modes such that the map (no pu= n intended) into the specific solution names.
shouldn't the purpose of a "unified CPE", be for the CPE no= t to have to care about the different "deployment modes" on the h= ead end?

Ian: But a MAP CPE does have to care about what is on the tunnel head= end as it could be another mesh client, or it could be the BR. It uses a d= ifferent mapping rule type for each, so it is aware of the capabilities of = the head end.

But, with what you've suggested, there is m= ore overlap, i.e. both 2&4 have NAT functions that are supported by two= different mechanisms.

However, what you've said does raise the fo= llowing point:

The way that state is described in the draf= t at the moment is actually taken from a concentrator perspective. This cou= ld be taken to be almost the inverse of the amount of state that is require= d from the CPEs perspective (i.e. if all of the state is in the providers network (DS-Lite), then the CPE do= esn't need it. If the providers network has less state ('per-customer', 'st= ateless'), then the CPE needs to have more - i.e. dynamic state table for N= AT, configuration for local IPv4/port set, MAPing rules etc.

Would describing the different states more = from the CPE's perspective make this clearer?

that would certainly help. although I don't think "state" i= s the defining characteristic.

Ian: Is the problem with the what's being described (i.e. the content= and functional differentiations) or the naming and terminology used to des= cribe it?


cheers,
Ole
_______________________________________________
Softwires mailing list
Softwires@ietf.org https://w= ww.ietf.org/mailman/listinfo/softwires
--_000_8B727D3A253149C8808B91EE79AC9453huaweicom_-- From mohamed.boucadair@orange.com Wed Dec 5 22:35:40 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 6E08221F8D4B for ; Wed, 5 Dec 2012 22:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S+uhjKCjqn0 for ; Wed, 5 Dec 2012 22:35:39 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id BB2CD21F8D36 for ; Wed, 5 Dec 2012 22:35:36 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id B72CB3B522F; Thu, 6 Dec 2012 07:35:34 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 99FE427C046; Thu, 6 Dec 2012 07:35:34 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Thu, 6 Dec 2012 07:35:34 +0100 From: To: Tina TSOU , "ian.farrer@telekom.de" Date: Thu, 6 Dec 2012 07:35:33 +0100 Thread-Topic: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Thread-Index: AQHN0khV9YskOFlbW0GC3UgDD05lepgKibrJgADHfHA= Message-ID: <94C682931C08B048B7A8645303FDC9F36E9A176EAC@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <50B9B5C7.107@viagenie.ca> <10C9FD27-2894-4495-90E1-15A9AC9D73B9@employees.org> <8A1B81989BCFAE44A22B2B86BF2B76318954FEE360@HE111643.EMEA1.CDS.T-INTERNAL.COM> , <8A1B81989BCFAE44A22B2B86BF2B7631895539BCBC@HE111643.EMEA1.CDS.T-INTERNAL.COM> <8B727D3A-2531-49C8-808B-91EE79AC9453@huawei.com> In-Reply-To: <8B727D3A-2531-49C8-808B-91EE79AC9453@huawei.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36E9A176EACPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.6.60017 Cc: "softwires@ietf.org" Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 06 Dec 2012 06:35:40 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E9A176EACPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tina, Many thanks for the comments. Some clarifications below: * DS-Lite is included in the scope for the reasons detailed in the draft (s= ee Section 1.1): (2) Simplify solution migration paths: Define a unified CPE behavior which allows for smooth migration between the different modes and (4) Re-usability: Maximize the re-use of existing functional blocks including Tunnel Endpoint, port restricted NAPT44, Forwarding behavior, etc. * Public 4over6 is already included in the draft: (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) [I-D.cui-softwire-b4-translated-ds-lite], [I-D.ietf-softwire-public-4over6] or MAP 1:= 1 [I-D.ietf-softwire-map] ): Requires a single per-subs= criber state (or a few) to be maintained in the Service Provider's network. * I agree with you the title should be updated to reflect the scope of the = draft. The proposed scope is IPv4 service continuity over IPv6 mechanisms. Cheers, Med ________________________________ De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De la p= art de Tina TSOU Envoy=E9 : mercredi 5 d=E9cembre 2012 19:34 =C0 : ian.farrer@telekom.de Cc : softwires@ietf.org Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-c= pe Dear Med, Ian and Suresh, Great job! Draft-bfmk is written very well to reach consensus. Two small comments are below. 1. I'm not sure whether it is appropriate to put DS-Lite case into the= document, since in DS-Lite case the CPE is only the tunnel end point witho= ut NAT, which is basically different with lw4over6/MAP. But if the objectiv= e of this document is to define an unified CPE for all the 4over6 mechanism= s, other mechanisms like public 4over6 should also be included in the docum= ent. My understanding may be wrong. 2. The title says "unified softwire CPE", but in softwire, there are m= any other transition technologies, e.g., 6rd. To be specific, maybe 4over6 = CPE is more appropriate. Thank you, Tina On Dec 4, 2012, at 9:53 AM, "ian.farrer@telekom.de" > wrote: Hi Ole, Answers inline. Cheers, Ian -----Original Message----- From: Ole Tr=F8an [mailto:otroan@employees.org] Sent: Montag, 3. Dezember 2012 10:06 To: Farrer, Ian Cc: simon.perreault@viagenie.ca; softwi= res@ietf.org Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-= cpe Ian, Whichever state is selected, NAT is certainly fundamental to how the state = will operate and so we tried to weave it into the functional description. I= 'm not sure that provisioned NAT info enough to be able to use to unambiguo= usly define with operating 'mode' (for want of a better word) to use. One of the reasons for the use of state in the draft is try and define the = operating modes with as little overlap as possible (it's not 100%, but ther= e's only 1 exception at the moment for binding mode and MAP1:1). From this,= then it is easier to align the specific solution names to the state charac= teristics. I don't think you should try to define modes such that the map (no pun inte= nded) into the specific solution names. shouldn't the purpose of a "unified CPE", be for the CPE not to have to car= e about the different "deployment modes" on the head end? Ian: But a MAP CPE does have to care about what is on the tunnel head end a= s it could be another mesh client, or it could be the BR. It uses a differe= nt mapping rule type for each, so it is aware of the capabilities of the he= ad end. But, with what you've suggested, there is more overlap, i.e. both 2&4 have = NAT functions that are supported by two different mechanisms. However, what you've said does raise the following point: The way that state is described in the draft at the moment is actually take= n from a concentrator perspective. This could be taken to be almost the inv= erse of the amount of state that is required from the CPEs perspective (i.e= . if all of the state is in the providers network (DS-Lite), then the CPE d= oesn't need it. If the providers network has less state ('per-customer', 's= tateless'), then the CPE needs to have more - i.e. dynamic state table for = NAT, configuration for local IPv4/port set, MAPing rules etc. Would describing the different states more from the CPE's perspective make = this clearer? that would certainly help. although I don't think "state" is the defining c= haracteristic. Ian: Is the problem with the what's being described (i.e. the content and f= unctional differentiations) or the naming and terminology used to describe = it? cheers, Ole _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_94C682931C08B048B7A8645303FDC9F36E9A176EACPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Tina,
 
Many thanks for the comments. Some clarificat= ions=20 below:
 
* DS-Lite is included in the scope for the re= asons=20 detailed in the draft (see Section 1.1):
   (2)  Simplify solution migration paths: Define a unified CPE beha=
vior
        which allows for smooth migration between the different modes
and
   (4)  Re-usability: Maximize the re-use of =
existing functional blocks
        including Tunnel Endpoint, port restricted NAPT44, Forwarding
        behavior, etc.
* Public 4over6 is already included in the=20 draft:
   (2)  Binding approach (e.g., Lightweight 4over6 (Lw4o6)
        [I-D.cui-softwire-b4-tran=
slated-ds-lite],
        [I-D.ietf-softwire-public-4over6=
] or MAP 1:1
        [I-D.ietf-softwire-map] ): Requires a =
single per-subscriber
        state (or a few) to be maintained in the Service Provider's
        network.
* I agree with you the title should be update= d to=20 reflect the scope of the draft. The proposed scope is IPv4 service=20 continuity over IPv6 mechanisms.
 
Cheers,
Med

De : softwires-bounces@ietf.org= =20 [mailto:softwires-bounces@ietf.org] De la part de Tina=20 TSOU
Envoy=E9 : mercredi 5 d=E9cembre 2012 19:34
=C0=  :=20 ian.farrer@telekom.de
Cc :=20 softwires@ietf.org
Objet : Re: [Softwires] Unified Softwir= e=20 CPE: draft-bfmk-softwire-unified-cpe

Dear Med, Ian and Suresh,
Great job! Draft-bfmk is written very well to re= ach=20 consensus.

Two= small=20 comments are below.

1.      = ;I=92m not sure whether it is appropriate to put DS-Lite case= into the=20 document, since in DS-Lite case the CPE is only the tunnel end point with= out=20 NAT, which is basically different with lw4over6/MAP. But if the objective= of=20 this document is to define an unified CPE for all the 4over6 mechanisms, = other=20 mechanisms like public 4over6 should also be included in the document. My= =20 understanding may be wrong.

2.      = ;The title says =93unified softwire CPE=94, but in softwire, = there are=20 many other transition technologies, e.g., 6rd. To be specific, maybe 4ove= r6=20 CPE is more appropriate.


Thank you,
Tina

On Dec 4, 2012, at 9:53 AM, "ian.farrer@telekom.de" <ian.farrer@telekom.de>=20 wrote:

Hi Ole,

Answers=20 inline.

Cheers,
Ian

-----Original=20 Message-----
From: Ole Tr=F8an [mailto:otroan@employees= .org]=20
Sent: Montag, 3. Dezember 2012 10:06
T= o:=20 Farrer, Ian
Cc: simon.perreault@viagenie.ca= ;=20 softwires@ietf.org
Subject:=20 Re: [Softwires] Unified Softwire CPE:=20 draft-bfmk-softwire-unified-cpe

Ian,

Whichever state is selected, NAT is=20 certainly fundamental to how the state will operate and so we tried t= o=20 weave it into the functional description. I'm not sure that provision= ed=20 NAT info enough to be able to use to unambiguously define with operat= ing=20 'mode' (for want of a better word) to use.

One of the reasons for the use of state= in=20 the draft is try and define the operating modes with as little overla= p as=20 possible (it's not 100%, but there's only 1 exception at the moment f= or=20 binding mode and MAP1:1). From this, then it is easier to align the=20 specific solution names to the state=20 characteristics.

I don't = think=20 you should try to define modes such that the map (no pun intended) into= the=20 specific solution names.
shouldn't the purpose of a "un= ified=20 CPE", be for the CPE not to have to care about the different "deploymen= t=20 modes" on the head end?

Ian: But a MAP= CPE=20 does have to care about what is on the tunnel head end as it could be=20 another mesh client, or it could be the BR. It uses a different mapping= rule=20 type for each, so it is aware of the capabilities of the head=20 end.

But, with what you've suggested, there = is=20 more overlap, i.e. both 2&4 have NAT functions that are supported= by=20 two different mechanisms.

However, what you've said does raise th= e=20 following point:

The way that state is described in the = draft=20 at the moment is actually taken from a concentrator perspective. This= =20 could be taken to be almost the inverse of the amount of state that i= s=20 required from the CPEs perspective (i.e. if all of the state is in th= e=20 providers network (DS-Lite), then the CPE doesn't need it. If the=20 providers network has less state ('per-customer', 'stateless'), then = the=20 CPE needs to have more - i.e. dynamic state table for NAT, configurat= ion=20 for local IPv4/port set, MAPing rules etc.

Would describing the different states m= ore=20 from the CPE's perspective make this=20 clearer?

that would certa= inly=20 help. although I don't think "state" is the defining=20 characteristic.

Ian: Is the problem wi= th=20 the what's being described (i.e. the content and functional=20 differentiations) or the naming and terminology used to describe=20 it?


cheers,Ole
_______________________________________________<= /SPAN>
Softwires=20 mailing list
Softwires@ietf.org
https://www.ie= tf.org/mailman/listinfo/softwires
--_000_94C682931C08B048B7A8645303FDC9F36E9A176EACPUEXCB1Bnante_-- From internet-drafts@ietf.org Sun Dec 9 23:15: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 F0A0821F8E53; Sun, 9 Dec 2012 23:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLu42pwIEMfD; Sun, 9 Dec 2012 23:15:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C8621F86E2; Sun, 9 Dec 2012 23:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121210071502.26470.53288.idtracker@ietfa.amsl.com> Date: Sun, 09 Dec 2012 23:15:02 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-6rd-radius-attrib-08.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: Mon, 10 Dec 2012 07:15:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : RADIUS Attribute for 6rd Author(s) : Dayong Guo Sheng Jiang Remi Despres Roberta Maglione Filename : draft-ietf-softwire-6rd-radius-attrib-08.txt Pages : 11 Date : 2012-12-09 Abstract: IPv6 Rapid Deployment (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd 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 DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-6rd-radius-attrib-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kristian.poscic@alcatel-lucent.com Mon Dec 10 12:06: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 F0BD621F866D for ; Mon, 10 Dec 2012 12:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.648 X-Spam-Level: X-Spam-Status: No, score=-9.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IGEmSgaTgMa for ; Mon, 10 Dec 2012 12:06:26 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 05B0621F8653 for ; Mon, 10 Dec 2012 12:06:25 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBAK6O6x014022 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 10 Dec 2012 21:06:24 +0100 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 10 Dec 2012 21:06:23 +0100 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.227]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 10 Dec 2012 15:06:21 -0500 From: "Poscic, Kristian (Kristian)" To: "softwires@ietf.org" Thread-Topic: MAP-E/T overlaping ranges and domains Thread-Index: Ac3XETWFsOgBqEDlSUKDU5M2A4wCIQ== Date: Mon, 10 Dec 2012 20:06:20 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AA2894A@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AA2894AUS70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [Softwires] MAP-E/T overlaping ranges and domains 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, 10 Dec 2012 20:06:28 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02AA2894AUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can someone clarify a few things for me: 1) Does MAP support this scenario (example): - (BMR) Rule 1: Rule IPv6 Prefix: 2001::/40 Rule IPv4 Prefix: 192.0.2.0/24 Rule EA-bits length: 12 - (BMR) Rule 2: Rule IPv6 Prefix: 2001::/40 Rule IPv4 Prefix: 200.0.2.0/24 Rule EA-bits length: 12 The only difference between these two rules above is the 'R= ule IPv4 Prefix', everything else is the same. My obvious answer would be t= hat this scenario is not supported but wanted to be sure that I'm not missi= ng anything. This scenario above would result in ambiguity between CEs, i.e. a single IA= -PD that is delegated to a CE can be associated with either of the two rul= es above (EA bits can be the same for a CE from 192.0.2.0/24 range and for = a CE from 200.0.2.0/24 range. In this example above, it is assumed that the delegated prefix (IA-PD) that= DHCPv6 Server is handing out to CEs is 2001::/40 with delegated prefix len= gth /56. This makes me believe that each rule must not only be uniqu= e (because the above two rules are unique) but instead each rule must have = a unique 'Rule IPv6 prefix' and a unique 'Rule IPv4 Prefix' per 'Rule IPv6= prefix' (IPv4 uniqueness is important in the downstream direction where lo= okup is performed based on IPv4). 2) What constitutes a MAP domain? I'd think a unique 'Rule IPv6 Prefix= ' which (assuming that 1) is correct) would mean that a Domain =3D BMR. In= other words, can a MAP domain contain a collection of BMRs? The drafts men= tion virtual-links, etc...but it would be simpler if we can say Domain=3DBM= R (not sure if this is accurate though). Of course, nodes sharing the same= set of those rules would be in the same MAP domain. 3) Is overlapping of 'Rule IPv6 Prefixes' supported? For example in the above case, can we have for Rule 2) the 'Rule IPv6 prefi= x' as 2001:0:80::/42. In this case the 'Rule IPv6 Prefix' from Rule 1 overlaps with 'Rule IPv6 Pr= efix' from Rule 2. I assume that this would not be supported for the same r= eason as in 1). I didn't think about the applicability of this scenario for= now, it is more of a theoretical question. Thanks, Kris --_000_7921F977B17D5B49B8DCC955A339D2F02AA2894AUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can someone clarify a few things for me:<= /p>

 

1)      Does MAP support this scenario (example):

-       = ;   (BMR) Rule 1:  

Rule IPv6 Prefix:          &= nbsp;    2001::/40

Rule IPv4 Prefix:          &= nbsp;    192.0.2.0/24

Rule EA-bits length:        12

-       = ;   (BMR) Rule 2:

Rule IPv6 Prefix:          &= nbsp;    2001::/40

Rule IPv4 Prefix:          &= nbsp;    200.0.2.0/24

Rule EA-bits length:        12

 

        &nbs= p;       The only difference between these tw= o rules above is the ‘Rule IPv4 Prefix’, everything else is the= same. My obvious answer would be that this scenario is not supported but w= anted to be sure that I’m not missing anything.

This scenario above would= result in ambiguity between CEs, i.e. a single IA-PD that is delegated to = a CE can be associated with either of the two  rules above (EA bits ca= n be the same for a CE from 192.0.2.0/24 range and for  a CE from 200.0.2.0/24 range.

In this example above, it= is assumed that the delegated prefix (IA-PD) that DHCPv6 Server is handing= out to CEs is 2001::/40 with delegated prefix length /56.

 

        &nbs= p;       This makes me believe that each rule= must not only be unique (because the above two rules are unique) but inste= ad each rule must have a unique  ‘Rule IPv6 prefix’ and a = unique ‘Rule IPv4 Prefix’ per ‘Rule IPv6 prefix’ (I= Pv4 uniqueness is important in the downstream direction where lookup is perfor= med based on IPv4).

 

2)      What constitutes a MAP domain? I’d think a un= ique ‘Rule IPv6 Prefix’ which  (assuming that 1) is correc= t) would mean that a Domain =3D BMR. In other words, can a MAP domain conta= in a collection of BMRs? The drafts mention virtual-links, etc…but it would be simpler if we can say Domain=3DBMR (not sure if = this is accurate though).  Of course, nodes sharing the same set of th= ose rules would be in the same MAP domain.

 

3)      Is overlapping of ‘Rule IPv6 Prefixes’ = supported?

For example in the above case, can we have fo= r Rule 2) the ‘Rule IPv6 prefix’ as 2001:0:80::/42.<= /p>

In this case the ‘Rule IPv6 Prefix̵= 7; from Rule 1 overlaps with ‘Rule IPv6 Prefix’ from Rule 2. I = assume that this would not be supported for the same reason as in 1). I did= n’t think about the applicability of this scenario for now, it is more of a theoretical question.

 

Thanks,

Kris

 

--_000_7921F977B17D5B49B8DCC955A339D2F02AA2894AUS70UWXCHMBA05z_-- From ssenthil@cisco.com Mon Dec 10 17:03: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 A90CB21F86B9 for ; Mon, 10 Dec 2012 17:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.074 X-Spam-Level: X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dW1CaLuFBuDp for ; Mon, 10 Dec 2012 17:03:04 -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 6706021F86CB for ; Mon, 10 Dec 2012 17:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18576; q=dns/txt; s=iport; t=1355187784; x=1356397384; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=wz28QDouH0vyOnYI4oKKcV6OBSqa2iNn91cSrSdzSF8=; b=XMopCnfMJw/a1GZvg0Q2F2yM9XXYy0M7/n85fkNacIw+OmrJjclZaTEU BqSov/4HbGeIVAqys1/iwswoLAEhuEJF4+2LkpP9rWNO00B0XUHy528MH egdAwhillq3y9C926pSFVBW7f0o/UrSv+M8GDRo9gfHpRf7Bg66PArVqU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOeFxlCtJV2a/2dsb2JhbABFgkm8JhZzgh4BAQEELV4BCBEDAQILHTkUCQgBAQQBEgiICag4kCGMP4NiYQOmToJzgiI X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="151471575" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 11 Dec 2012 01:03:03 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBB133wt000718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Dec 2012 01:03:03 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.80]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 19:03:03 -0600 From: "Senthil Sivakumar (ssenthil)" To: "Poscic, Kristian (Kristian)" , "softwires@ietf.org" Thread-Topic: [Softwires] MAP-E/T overlaping ranges and domains Thread-Index: Ac3XETWFsOgBqEDlSUKDU5M2A4wCIQAMnBmA Date: Tue, 11 Dec 2012 01:03:03 +0000 Message-ID: In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AA2894A@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.117.198.133] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D02322EB069xmbrcdx15ciscoc_" MIME-Version: 1.0 Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains 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, 11 Dec 2012 01:03:05 -0000 --_000_CB1B483277FEC94E9B58357040EE5D02322EB069xmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: , "Kristian (Kristian)" > Date: Monday, December 10, 2012 3:06 PM To: "softwires@ietf.org" > Subject: [Softwires] MAP-E/T overlaping ranges and domains Can someone clarify a few things for me: 1) Does MAP support this scenario (example): - (BMR) Rule 1: Rule IPv6 Prefix: 2001::/40 Rule IPv4 Prefix: 192.0.2.0/24 Rule EA-bits length: 12 - (BMR) Rule 2: Rule IPv6 Prefix: 2001::/40 Rule IPv4 Prefix: 200.0.2.0/24 Rule EA-bits length: 12 The only difference between these two rules above is the = =91Rule IPv4 Prefix=92, everything else is the same. My obvious answer woul= d be that this scenario is not supported but wanted to be sure that I=92m n= ot missing anything. This scenario above would result in ambiguity between CEs, i.e. a single IA= -PD that is delegated to a CE can be associated with either of the two rul= es above (EA bits can be the same for a CE from 192.0.2.0/24 range and for = a CE from 200.0.2.0/24 range. In this example above, it is assumed that the delegated prefix (IA-PD) that= DHCPv6 Server is handing out to CEs is 2001::/40 with delegated prefix len= gth /56. This makes me believe that each rule must not only be uniqu= e (because the above two rules are unique) but instead each rule must have = a unique =91Rule IPv6 prefix=92 and a unique =91Rule IPv4 Prefix=92 per = =91Rule IPv6 prefix=92 (IPv4 uniqueness is important in the downstream dire= ction where lookup is performed based on IPv4). [Senthil] Right. The rules must not be overlapping with one another. Each d= omain can have a single IPv6 & single IPv4 rule prefix only. The ipv6 and i= pv4 rule prefix should not overlap with other ipv6 and ipv4 rules prefixes = respectively in other domains. 2) What constitutes a MAP domain? I=92d think a unique =91Rule IPv6 Pr= efix=92 which (assuming that 1) is correct) would mean that a Domain =3D B= MR. In other words, can a MAP domain contain a collection of BMRs? The draf= ts mention virtual-links, etc=85but it would be simpler if we can say Domai= n=3DBMR (not sure if this is accurate though). Of course, nodes sharing th= e same set of those rules would be in the same MAP domain. [Senthil] Each MAP domain should have a single rule IPv6 prefix and single = IPv4 prefix. I think a single IPv4 prefix may be too restrictive in some d= eployments and people might want to use more than one prefix. But as you ha= ve shown EA length can cause ambiguity and hence makes it undeployable. 3) Is overlapping of =91Rule IPv6 Prefixes=92 supported? For example in the above case, can we have for Rule 2) the =91Rule IPv6 pre= fix=92 as 2001:0:80::/42. In this case the =91Rule IPv6 Prefix=92 from Rule 1 overlaps with =91Rule I= Pv6 Prefix=92 from Rule 2. I assume that this would not be supported for th= e same reason as in 1). I didn=92t think about the applicability of this sc= enario for now, it is more of a theoretical question. [Senthil] No, atleast in our implementation we have checks to make sure the= prefixes don=92t overlap. Thanks Senthil Thanks, Kris --_000_CB1B483277FEC94E9B58357040EE5D02322EB069xmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: <Poscic>, "Kristia= n (Kristian)" <kristian.poscic@alcatel-lucent.com>
Date: Monday, December 10, 2012 3:0= 6 PM
To: "softwires@ietf.org" <softwires@ietf.org>
Subject: [Softwires] MAP-E/T overla= ping ranges and domains

Can someone clarify a few things for me:<= /p>

 

1)    &nbs= p; Does MAP support this scenario (example):<= /o:p>

-      &= nbsp;   (BMR) Rule 1:  

Rule IPv6 Prefix:          &= nbsp;    2001::/40

Rule IPv4 Prefix:          &= nbsp;    192.0.2.0/24

Rule EA-bits length:        12

-      &= nbsp;   (BMR) Rule 2:

Rule IPv6 Prefix:          &= nbsp;    2001::/40

Rule IPv4 Prefix:          &= nbsp;    200.0.2.0/24

Rule EA-bits length:        12

 

        &nbs= p;       The only difference between these tw= o rules above is the =91Rule IPv4 Prefix=92, everything else is the same. M= y obvious answer would be that this scenario is not supported but wanted to= be sure that I=92m not missing anything.

This scenario above would= result in ambiguity between CEs, i.e. a single IA-PD that is delegated to = a CE can be associated with either of the two  rules above (EA bits ca= n be the same for a CE from 192.0.2.0/24 range and for  a CE from 200.0.2.0/24 range.

In this example above, it= is assumed that the delegated prefix (IA-PD) that DHCPv6 Server is handing= out to CEs is 2001::/40 with delegated prefix length /56.

 

        &nbs= p;       This makes me believe that each rule= must not only be unique (because the above two rules are unique) but inste= ad each rule must have a unique  =91Rule IPv6 prefix=92 and a unique = =91Rule IPv4 Prefix=92 per =91Rule IPv6 prefix=92 (IPv4 uniqueness is important in the downstream direction where lookup is perfor= med based on IPv4).

[Senthil] Right. The rules must not be overlapping with one another. E= ach domain can have a single IPv6 & single IPv4 rule prefix only. The i= pv6 and ipv4 rule prefix should not overlap with other ipv6 and ipv4 rules = prefixes respectively in other domains.

 

2)    &nbs= p; What constitutes a MAP domain? I=92d think a un= ique =91Rule IPv6 Prefix=92 which  (assuming that 1) is correct) would= mean that a Domain =3D BMR. In other words, can a MAP domain contain a col= lection of BMRs? The drafts mention virtual-links, etc=85but it would be simpler if we can say Domain=3DBMR (not sure if this= is accurate though).  Of course, nodes sharing the same set of those = rules would be in the same MAP domain.

[Senthil] Each MAP domain should have a single rule IPv6 prefix and si= ngle IPv4 prefix.  I think a single IPv4 prefix may be too restrictive= in some deployments and people might want to use more than one prefix. But= as you have shown EA length can cause ambiguity and hence makes it undeployable.

 

3)    &nbs= p; Is overlapping of =91Rule IPv6 Prefixes=92 supp= orted?

For example in the above case, can we have fo= r Rule 2) the =91Rule IPv6 prefix=92 as 2001:0:80::/42.

In this case the =91Rule IPv6 Prefix=92 from = Rule 1 overlaps with =91Rule IPv6 Prefix=92 from Rule 2. I assume that this= would not be supported for the same reason as in 1). I didn=92t think abou= t the applicability of this scenario for now, it is more of a theoretical question.

[Senthil] No, atleast in our implementation we have checks to make sur= e the prefixes don=92t overlap.

Thanks
Senthil

 

Thanks,

Kris

 

 --_000_CB1B483277FEC94E9B58357040EE5D02322EB069xmbrcdx15ciscoc_-- From kristian.poscic@alcatel-lucent.com Mon Dec 10 21:57:13 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 A4C6221F8719 for ; Mon, 10 Dec 2012 21:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.798 X-Spam-Level: X-Spam-Status: No, score=-8.798 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITjPa06jsnO0 for ; Mon, 10 Dec 2012 21:57:06 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5B721F85E6 for ; Mon, 10 Dec 2012 21:56:52 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBB5u8B7018905 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 11 Dec 2012 06:56:43 +0100 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 11 Dec 2012 06:56:14 +0100 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.227]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Tue, 11 Dec 2012 00:56:12 -0500 From: "Poscic, Kristian (Kristian)" To: "Senthil Sivakumar (ssenthil)" , "softwires@ietf.org" Thread-Topic: [Softwires] MAP-E/T overlaping ranges and domains Thread-Index: Ac3XETWFsOgBqEDlSUKDU5M2A4wCIQAMnBmAAALHBCA= Date: Tue, 11 Dec 2012 05:56:10 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AA28BCF@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <7921F977B17D5B49B8DCC955A339D2F02AA2894A@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AA28BCFUS70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains 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, 11 Dec 2012 05:57:13 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02AA28BCFUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Very helpful. Thanks! From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] Sent: Monday, December 10, 2012 5:03 PM To: Poscic, Kristian (Kristian); softwires@ietf.org Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains From: , "Kristian (Kristian)" > Date: Monday, December 10, 2012 3:06 PM To: "softwires@ietf.org" > Subject: [Softwires] MAP-E/T overlaping ranges and domains Can someone clarify a few things for me: 1) Does MAP support this scenario (example): - (BMR) Rule 1: Rule IPv6 Prefix: 2001::/40 Rule IPv4 Prefix: 192.0.2.0/24 Rule EA-bits length: 12 - (BMR) Rule 2: Rule IPv6 Prefix: 2001::/40 Rule IPv4 Prefix: 200.0.2.0/24 Rule EA-bits length: 12 The only difference between these two rules above is the 'R= ule IPv4 Prefix', everything else is the same. My obvious answer would be t= hat this scenario is not supported but wanted to be sure that I'm not missi= ng anything. This scenario above would result in ambiguity between CEs, i.e. a single IA= -PD that is delegated to a CE can be associated with either of the two rul= es above (EA bits can be the same for a CE from 192.0.2.0/24 range and for = a CE from 200.0.2.0/24 range. In this example above, it is assumed that the delegated prefix (IA-PD) that= DHCPv6 Server is handing out to CEs is 2001::/40 with delegated prefix len= gth /56. This makes me believe that each rule must not only be uniqu= e (because the above two rules are unique) but instead each rule must have = a unique 'Rule IPv6 prefix' and a unique 'Rule IPv4 Prefix' per 'Rule IPv6= prefix' (IPv4 uniqueness is important in the downstream direction where lo= okup is performed based on IPv4). [Senthil] Right. The rules must not be overlapping with one another. Each d= omain can have a single IPv6 & single IPv4 rule prefix only. The ipv6 and i= pv4 rule prefix should not overlap with other ipv6 and ipv4 rules prefixes = respectively in other domains. 2) What constitutes a MAP domain? I'd think a unique 'Rule IPv6 Prefix= ' which (assuming that 1) is correct) would mean that a Domain =3D BMR. In= other words, can a MAP domain contain a collection of BMRs? The drafts men= tion virtual-links, etc...but it would be simpler if we can say Domain=3DBM= R (not sure if this is accurate though). Of course, nodes sharing the same= set of those rules would be in the same MAP domain. [Senthil] Each MAP domain should have a single rule IPv6 prefix and single = IPv4 prefix. I think a single IPv4 prefix may be too restrictive in some d= eployments and people might want to use more than one prefix. But as you ha= ve shown EA length can cause ambiguity and hence makes it undeployable. 3) Is overlapping of 'Rule IPv6 Prefixes' supported? For example in the above case, can we have for Rule 2) the 'Rule IPv6 prefi= x' as 2001:0:80::/42. In this case the 'Rule IPv6 Prefix' from Rule 1 overlaps with 'Rule IPv6 Pr= efix' from Rule 2. I assume that this would not be supported for the same r= eason as in 1). I didn't think about the applicability of this scenario for= now, it is more of a theoretical question. [Senthil] No, atleast in our implementation we have checks to make sure the= prefixes don't overlap. Thanks Senthil Thanks, Kris --_000_7921F977B17D5B49B8DCC955A339D2F02AA28BCFUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Very helpful. Thanks!<= o:p>

 

 

From: Senthil = Sivakumar (ssenthil) [mailto:ssenthil@cisco.com]
Sent: Monday, December 10, 2012 5:03 PM
To: Poscic, Kristian (Kristian); softwires@ietf.org
Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains<= /o:p>

 

&n= bsp;

&n= bsp;

From: <Poscic>, "Kristian (Kristian)" <= ;kristian.poscic@alca= tel-lucent.com>
Date: Monday, December 10, 2012 3:06 PM
To: "softwires@ietf.org" <softwires@ietf.org&g= t;
Subject: [Softwires] MAP-E/T overlaping ranges and domains

&n= bsp;

Can someone clarify a fe= w things for me:

 =

1)&nbs= p;     Does MAP support= this scenario (example):

-  &= nbsp;       (BMR) Rule 1:&nb= sp; 

Rule IPv6 Prefix:     &nb= sp;         2001::/40

Rule IPv4 Prefix:     &nb= sp;         192.0.2.0/24=

Rule EA-bits length:    &= nbsp;   12

-  &= nbsp;       (BMR) Rule 2:

Rule IPv6 Prefix:     &nb= sp;         2001::/40

Rule IPv4 Prefix:     &nb= sp;         200.0.2.0/24=

Rule EA-bits length:    &= nbsp;   12

 =

    =             The only= difference between these two rules above is the ‘Rule IPv4 Prefix= 217;, everything else is the same. My obvious answer would be that this sce= nario is not supported but wanted to be sure that I’m not missing anything.

This scenario above would result in ambiguity between CEs, i.e. a single= IA-PD that is delegated to a CE can be associated with either of the two &= nbsp;rules above (EA bits can be the same for a CE from 192.0.2.0/24 range and for  a CE from 200.0.2.0/24 range.

In this example above, it is assumed that the delegated prefix (IA-PD) t= hat DHCPv6 Server is handing out to CEs is 2001::/40 with delegated prefix = length /56.

 =

    =             This mak= es me believe that each rule must not only be unique (because the above two= rules are unique) but instead each rule must have a unique  ‘Ru= le IPv6 prefix’ and a unique ‘Rule IPv4 Prefix’ per ‘Rule IPv6 prefix’ (IPv4 uniqueness is important in the do= wnstream direction where lookup is performed based on IPv4).

&n= bsp;

[Senthi= l] Right. The rules must not be overlapping with one another. Each domain c= an have a single IPv6 & single IPv4 rule prefix only. The ipv6 and ipv4= rule prefix should not overlap with other ipv6 and ipv4 rules prefixes respectively in other domains.

 =

2)&nbs= p;     What constitutes= a MAP domain? I’d think a unique ‘Rule IPv6 Prefix’ whic= h  (assuming that 1) is correct) would mean that a Domain =3D BMR. In = other words, can a MAP domain contain a collection of BMRs? The drafts mention virtual-links, etc…but it would be simpler if we = can say Domain=3DBMR (not sure if this is accurate though).  Of course= , nodes sharing the same set of those rules would be in the same MAP domain= .

&n= bsp;

[Senthi= l] Each MAP domain should have a single rule IPv6 prefix and single IPv4 pr= efix.  I think a single IPv4 prefix may be too restrictive in some dep= loyments and people might want to use more than one prefix. But as you have shown EA length can cause ambiguity and h= ence makes it undeployable.

 =

3)&nbs= p;     Is overlapping o= f ‘Rule IPv6 Prefixes’ supported?

For example in th= e above case, can we have for Rule 2) the ‘Rule IPv6 prefix’ as= 2001:0:80::/42.

In this case the = ‘Rule IPv6 Prefix’ from Rule 1 overlaps with ‘Rule IPv6 P= refix’ from Rule 2. I assume that this would not be supported for the= same reason as in 1). I didn’t think about the applicability of this scenario for now, it is more of a theoretical question.=

&n= bsp;

[Senthi= l] No, atleast in our implementation we have checks to make sure the prefix= es don’t overlap.

&n= bsp;

Thanks<= o:p>

Senthil=

 =

Thanks,

Kris <= /p>

 =

--_000_7921F977B17D5B49B8DCC955A339D2F02AA28BCFUS70UWXCHMBA05z_-- From fibrib@gmail.com Tue Dec 11 02:21:09 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 3C7DB21F8510 for ; Tue, 11 Dec 2012 02:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRJJYMIAPqz5 for ; Tue, 11 Dec 2012 02:21:07 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A95D21F84D9 for ; Tue, 11 Dec 2012 02:21:05 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1579044eaa.31 for ; Tue, 11 Dec 2012 02:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Swfi30R3fY2VA1tMh0mL4rw++PNpkDbLlzu0njlLOEE=; b=hy6QFEOZg9H63+rKVRKv1Etfwj1Qofn2G6YldC671DxgdEtOa4320c2pTULAZmmR/Z IwF5p5yAJnamKH2XyozJhCnsKHOWEPgbvzjO3B9uhTThyiXGUZrUZxRHtjOJZz+/9cqj YQEeTwYZVwsP6s9QPE4ZpH+h/WFXohXBtDoDOxCxQu6zqFxOf35ArDFSx8Tm9cWS4g84 UisOVhRqHw4tI5cVjxC4mPkkMTHYQ/fvc0eC9eKHwGYFmNBU6r02h5FjP/4MjOspbmBS ecAN1gfrH7WNQR4QJIlV5Sf3DfusP3JgmBSqRi0zI9O7O+S5cD2xKnirLkdMVI+D0/Yw Z+bQ== MIME-Version: 1.0 Received: by 10.14.194.4 with SMTP id l4mr59175684een.42.1355221265127; Tue, 11 Dec 2012 02:21:05 -0800 (PST) Received: by 10.14.127.1 with HTTP; Tue, 11 Dec 2012 02:21:04 -0800 (PST) In-Reply-To: References: <7921F977B17D5B49B8DCC955A339D2F02AA2894A@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Tue, 11 Dec 2012 19:21:04 +0900 Message-ID: From: Maoke To: "Senthil Sivakumar (ssenthil)" Content-Type: multipart/alternative; boundary=047d7b342bf2199a4404d0910abb Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains 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, 11 Dec 2012 10:21:09 -0000 --047d7b342bf2199a4404d0910abb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi Senthil, interesting discussion. see inline. 2012/12/11 Senthil Sivakumar (ssenthil) > > > From: , "Kristian (Kristian)" < > kristian.poscic@alcatel-lucent.com> > Date: Monday, December 10, 2012 3:06 PM > To: "softwires@ietf.org" > Subject: [Softwires] MAP-E/T overlaping ranges and domains > > Can someone clarify a few things for me:**** > > ** ** > > 1) Does MAP support this scenario (example):**** > > - (BMR) Rule 1: **** > > Rule IPv6 Prefix: 2001::/40**** > > Rule IPv4 Prefix: 192.0.2.0/24**** > > Rule EA-bits length: 12**** > > - (BMR) Rule 2:**** > > Rule IPv6 Prefix: 2001::/40**** > > Rule IPv4 Prefix: 200.0.2.0/24**** > > Rule EA-bits length: 12**** > > ** ** > > The only difference between these two rules above is the > =91Rule IPv4 Prefix=92, everything else is the same. My obvious answer wo= uld be > that this scenario is not supported but wanted to be sure that I=92m not > missing anything.**** > > This scenario above would result in ambiguity between CEs, i.e. a single > IA-PD that is delegated to a CE can be associated with either of the two > rules above (EA bits can be the same for a CE from 192.0.2.0/24 range > and for a CE from 200.0.2.0/24 range. > what is the consequence if the CE has the two rules? NOTE the delegation is independent of the IPv4 address in use. for example, we have 2001:0:00xx:y000::/52 for the CE, where xx (8 bits) is the same as the IPv4 suffix while y (4 bits) is applied for the PSID. if the source address has been selected from either rule ipv4 prefix, then the encapsulation or translation is determined and the BR can de-capsulate or de-translate that without any difficulty because the full IPv4 address is embedded in the IID part. when the response comes, the destination address of the IPv4 packet is also determined though they would be encapsulated with the same IPv6 prefix (not the same IPv6 CE address!). the only concern is: if such a configuration can make different source IPv4 address for the packets of the same session. if so, the session might be troubled especially it is connection-oriented. however, we may notice that NAT44 in the CE is not stateless. what is selected for the session initialization would be continuously used for the subsequent process of the same session. if the address is not shared so that there is no NAT44, the native IPv4 source address selection logic will decide the selection and makes it unique for a specific destination. therefore personally i doubt the above multi-rule case doesn't work. if i am right, it is not needed to make 'Rule IPv4 Prefix' unique per 'Rule IPv6 Prefix'. > **** > > In this example above, it is assumed that the delegated prefix (IA-PD) > that DHCPv6 Server is handing out to CEs is 2001::/40 with delegated pref= ix > length /56. > why /56 instead of /52? :P > **** > > ** ** > > This makes me believe that each rule must not only be > unique (because the above two rules are unique) but instead each rule mus= t > have a unique =91Rule IPv6 prefix=92 and a unique =91Rule IPv4 Prefix=92= per =91Rule > IPv6 prefix=92 (IPv4 uniqueness is important in the downstream direction > where lookup is performed based on IPv4). > > [Senthil] Right. The rules must not be overlapping with one another. > Each domain can have a single IPv6 & single IPv4 rule prefix only. The ip= v6 > and ipv4 rule prefix should not overlap with other ipv6 and ipv4 rules > prefixes respectively in other domains. > > **** > > ** ** > > 2) What constitutes a MAP domain? I=92d think a unique =91Rule IPv6 > Prefix=92 which (assuming that 1) is correct) would mean that a Domain = =3D > BMR. In other words, can a MAP domain contain a collection of BMRs? The > drafts mention virtual-links, etc=85but it would be simpler if we can say > Domain=3DBMR (not sure if this is accurate though). Of course, nodes sha= ring > the same set of those rules would be in the same MAP domain. > > [Senthil] Each MAP domain should have a single rule IPv6 prefix and > single IPv4 prefix. I think a single IPv4 prefix may be too restrictive = in > some deployments and people might want to use more than one prefix. But a= s > you have shown EA length can cause ambiguity and hence makes it > undeployable. > > **** > > ** ** > > 3) Is overlapping of =91Rule IPv6 Prefixes=92 supported?**** > > For example in the above case, can we have for Rule 2) the =91Rule IPv6 > prefix=92 as 2001:0:80::/42.**** > > In this case the =91Rule IPv6 Prefix=92 from Rule 1 overlaps with =91Rule= IPv6 > Prefix=92 from Rule 2. I assume that this would not be supported for the = same > reason as in 1). I didn=92t think about the applicability of this scenari= o > for now, it is more of a theoretical question. > again, let's observe the consequence. again, we have the independently delegated prefix for the CE. if the CE has the pd like 2001:0:81:6000::/54, it matches both rules surely. longest-match can determine which rule is in use (though not yet specified?). however, such a way may cause a subset of IPv4 residual addresses never used (i.e., wasted). in this example, the longest match to 2001:0:80::/42 may block 192.0.2.128/26 (192.0.2.128 - 192.0.2.191) from using. the really problematic stuff is both rule IPv4 prefixes and rule IPv6 prefixes are overlapped among two rules but not aggregated. Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/24, ea-length =3D 12 Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D 192.0.2.0= /26, ea-length =3D 12 and one CE-a has delegated prefix 2001:0:3f:5000::/52, while another CE-b has 2001:0:bf:5000::/54. such a delegation seems no problem at all. CE-a matches Rule 1 while CE-b matches Rule 2. then the trouble happens: CE-a will use the IPv4 address 192.0.2.63 with PSID =3D binary_0101, obviously; while CE-b have 40-55bits =3D 0x8fd4 =3D binary_1011 1111 0101 0000 then EA-bits =3D binary_11 1111 0101 00 then IPv4 suffix =3D binary_11 1111, PSID =3D binary_0101 00 when attached to 192.0.2.0/26, it will be 192.0.2.63 with PSID =3D binary_0101 00 i.e., CE-b's usable port-range is overlapped with CE-a on the same IPv4 address! therefore, IMHO, the constraint of BMR-making MUST ensure the (IPv4 address, port-range)-pair is not overlapped among different CE, therefore Rule IPv4 Prefixes cannot be overlapped among BMRs. this is necessary and sufficient. if i made mistakes, please point out without hesitation. thanks a lot! - maoke > [Senthil] No, atleast in our implementation we have checks to make sure > the prefixes don=92t overlap. > > Thanks > Senthil > > **** > > ** ** > > Thanks,**** > > Kris **** > > ** ** > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --047d7b342bf2199a4404d0910abb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi Senthil,

interesting discussion. see inline.

2012/12/11 Senthil Sivakumar (ssenthil) = <ssenthil@cisco.= com>


From: <Poscic>, "Kristia= n (Kristian)" <kristian.poscic@alcatel-lucent.com>
Date: Monday, December 10, 2012 3:0= 6 PM
To: "softwires@ietf.org" <softwires@ietf.org>
Subject: [Softwires] MAP-E/T overla= ping ranges and domains

Can someone clarify a few things for me:

=A0

1)=A0=A0=A0= =A0=A0 Does MAP support this scenario (example):

-=A0=A0=A0=A0= =A0=A0=A0=A0=A0 (BMR) Rule 1:=A0=A0

Rule IPv6 Prefix: =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2001::/40

Rule IPv4 Prefix: =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 192.0.2.0/24

Rule EA-bits length:=A0= =A0=A0=A0=A0=A0=A0 12

-=A0=A0=A0=A0= =A0=A0=A0=A0=A0 (BMR) Rule 2:

Rule IPv6 Prefix: =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2001::/40

Rule IPv4 Prefix: =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 200.0.2.0/24

Rule EA-bits length:=A0= =A0=A0=A0=A0=A0=A0 12

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The on= ly difference between these two rules above is the =91Rule IPv4 Prefix=92, = everything else is the same. My obvious answer would be that this scenario = is not supported but wanted to be sure that I=92m not missing anything.<= /u>

This scenario above would= result in ambiguity between CEs, i.e. a single IA-PD that is delegated to = a CE can be associated with either of the two =A0rules above (EA bits can b= e the same for a CE from = 192.0.2.0/24 range and for =A0a CE from 200.0.2.0/24 range.

<= div>
what is the consequence if the CE has the two rules?

NOTE t= he delegation is independent of the IPv4 address in use. for example, we ha= ve 2001:0:00xx:y000::/52 for the CE, where xx (8 bits) is the same as the I= Pv4 suffix while y (4 bits) is applied for the PSID. if the source address = has been selected from either rule ipv4 prefix, then the encapsulation or t= ranslation is determined and the BR can de-capsulate or de-translate that w= ithout any difficulty because the full IPv4 address is embedded in the IID = part. when the response comes, the destination address of the IPv4 packet i= s also determined though they would be encapsulated with the same IPv6 pref= ix (not the same IPv6 CE address!).

the only concern is: if such a configuration can make different source = IPv4 address for the packets of the same session. if so, the session might = be troubled especially it is connection-oriented. however, we may notice th= at NAT44 in the CE is not stateless. what is selected for the session initi= alization would be continuously used for the subsequent process of the same= session. if the address is not shared so that there is no NAT44, the nativ= e IPv4 source address selection logic will decide the selection and makes i= t unique for a specific destination.

therefore personally i doubt the above multi-rule case doesn't work= . if i am right, it is not needed to make 'Rule IPv4 Prefix' unique= per 'Rule IPv6 Prefix'.
=A0
<= p class=3D"MsoNormal" style=3D"margin-left:0.5in">

In this example above, it= is assumed that the delegated prefix (IA-PD) that DHCPv6 Server is handing= out to CEs is 2001::/40 with delegated prefix length /56.


why /56 instead of /52? :P
=A0<= /div>

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This m= akes me believe that each rule must not only be unique (because the above t= wo rules are unique) but instead each rule must have a unique =A0=91Rule IP= v6 prefix=92 and a unique =91Rule IPv4 Prefix=92 per =91Rule IPv6 prefix=92= (IPv4 uniqueness is important in the downstream direction where lookup is perfor= med based on IPv4).

[Senthil] Right. The rules must not be overlapping with one another. E= ach domain can have a single IPv6 & single IPv4 rule prefix only. The i= pv6 and ipv4 rule prefix should not overlap with other ipv6 and ipv4 rules = prefixes respectively in other domains.

=A0

2)=A0=A0=A0= =A0=A0 What constitutes a MAP domain? I=92d think a unique =91Rule I= Pv6 Prefix=92 which =A0(assuming that 1) is correct) would mean that a Doma= in =3D BMR. In other words, can a MAP domain contain a collection of BMRs? = The drafts mention virtual-links, etc=85but it would be simpler if we can say Domain=3DBMR (not sure if this= is accurate though).=A0 Of course, nodes sharing the same set of those rul= es would be in the same MAP domain.

[Senthil] Each MAP domain should have a single rule IPv6 prefix and si= ngle IPv4 prefix. =A0I think a single IPv4 prefix may be too restrictive in= some deployments and people might want to use more than one prefix. But as= you have shown EA length can cause ambiguity and hence makes it undeployable.

=A0

3)=A0=A0=A0= =A0=A0 Is overlapping of =91Rule IPv6 Prefixes=92 supported?<= u>

For example in the above case, can we have for Rule 2) the =91Rule IPv6 = prefix=92 as 2001:0:80::/42.

In this case the =91Rule IPv6 Prefix=92 from Rule 1 overlaps with =91Rul= e IPv6 Prefix=92 from Rule 2. I assume that this would not be supported for= the same reason as in 1). I didn=92t think about the applicability of this= scenario for now, it is more of a theoretical question.


again, let's observe the consequence. again, we hav= e the independently delegated prefix for the CE. if the CE has the pd like = 2001:0:81:6000::/54, it matches both rules surely.=A0 longest-match can det= ermine which rule is in use (though not yet specified?). however, such a wa= y may cause a subset of IPv4 residual addresses never used (i.e., wasted). = in this example, the longest match to 2001:0:80::/42 may block 192.0.2.128/26 (192.0.2.128 - 192.0.2.191) from u= sing.

the really problematic stuff is both rule IPv4 prefixes and rule IPv6 p= refixes are overlapped among two rules but not aggregated.

Rule 1) = rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/24, ea-length =3D 12
Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D 192.0.2.0/26, ea-length =3D 12

and one = CE-a has delegated prefix 2001:0:3f:5000::/52, while another CE-b has 2001:= 0:bf:5000::/54. such a delegation seems no problem at all. CE-a matches Rul= e 1 while CE-b matches Rule 2. then the trouble happens: CE-a will use the = IPv4 address 192.0.2.63 with PSID =3D binary_0101, obviously; while CE-b ha= ve

=A0=A0=A0 40-55bits =3D 0x8fd4 =3D binary_1011 1111 0101 0000
=A0=A0= =A0 then EA-bits =3D binary_11 1111 0101 00
=A0=A0=A0 then IPv4 suffix = =3D binary_11 1111, PSID =3D binary_0101 00
=A0=A0=A0 when attached to = 192.0.2.0/26, it will be 192.0.2.63 wit= h PSID =3D binary_0101 00

i.e., CE-b's usable port-range is overlapped with CE-a on the same = IPv4 address!

therefore, IMHO, the constraint of BMR-making MUST ens= ure the (IPv4 address, port-range)-pair is not overlapped among different C= E, therefore Rule IPv4 Prefixes cannot be overlapped among BMRs. this is ne= cessary and sufficient.

if i made mistakes, please point out without hesitation. thanks a lot!<= br>
- maoke

[Senthil] No, atleast in our implementation we have checks to make sur= e the prefixes don=92t overlap.

Thanks
Senthil

=A0

Thanks,

Kris

=A0

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


--047d7b342bf2199a4404d0910abb-- From ssenthil@cisco.com Tue Dec 11 11:33:37 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 6B17221F852D for ; Tue, 11 Dec 2012 11:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3K0ELxBiuNUa for ; Tue, 11 Dec 2012 11:33:35 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 87C0A21F8521 for ; Tue, 11 Dec 2012 11:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27469; q=dns/txt; s=iport; t=1355254415; x=1356464015; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=bn2N3UlFp/j8x2nDqrcx+CuSkRZ+Fv5TqDg1KRIqlL0=; b=DGFzV06G4GdoDyzBgBNqPI2FuRU6bI2ga8JK+7sog0N0HIrtqV7Y/ASd 9TVaUtBMAKYJ9t1LIwnuy4qgJI4gLnwyufIoDfoB5T0l3i1lvD2b7kT3r Hd8n+s3WTHYjQdzezxEbo5Gn10dfMEkzns/UIARKWk5V1bAwHkn7rTCsc Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAO6Jx1CtJV2Z/2dsb2JhbAA6CoJJqU+JGIhSTBZzgh4BAQEEAQEBJCQBIgsSAQgRAgEBAgsWBygEAgsUCQgBAQQOBQiHdwMPDKsOggQBhG4NiVSLYWkRg1FhA5QxjQ0DhQ6Cc4Ii X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="151601882" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 11 Dec 2012 19:33:34 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBBJXYRt026923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Dec 2012 19:33:34 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.80]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 13:33:34 -0600 From: "Senthil Sivakumar (ssenthil)" To: Maoke Thread-Topic: [Softwires] MAP-E/T overlaping ranges and domains Thread-Index: Ac3XETWFsOgBqEDlSUKDU5M2A4wCIQAMnBmAAB33kAAACNEVgA== Date: Tue, 11 Dec 2012 19:33:33 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.150.25.114] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D02322EE05Cxmbrcdx15ciscoc_" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains 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, 11 Dec 2012 19:33:37 -0000 --_000_CB1B483277FEC94E9B58357040EE5D02322EE05Cxmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Maoke, Please see inline for Senthil2 From: Maoke > Date: Tuesday, December 11, 2012 5:21 AM To: Senthil Sivakumar > Cc: "Poscic, Kristian (Kristian)" >, "softwires@ietf.org" > Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains hi Senthil, interesting discussion. see inline. 2012/12/11 Senthil Sivakumar (ssenthil) > From: , "Kristian (Kristian)" > Date: Monday, December 10, 2012 3:06 PM To: "softwires@ietf.org" > Subject: [Softwires] MAP-E/T overlaping ranges and domains Can someone clarify a few things for me: 1) Does MAP support this scenario (example): - (BMR) Rule 1: Rule IPv6 Prefix: 2001::/40 Rule IPv4 Prefix: 192.0.2.0/24 Rule EA-bits length: 12 - (BMR) Rule 2: Rule IPv6 Prefix: 2001::/40 Rule IPv4 Prefix: 200.0.2.0/24 Rule EA-bits length: 12 The only difference between these two rules above is the = =91Rule IPv4 Prefix=92, everything else is the same. My obvious answer woul= d be that this scenario is not supported but wanted to be sure that I=92m n= ot missing anything. This scenario above would result in ambiguity between CEs, i.e. a single IA= -PD that is delegated to a CE can be associated with either of the two rul= es above (EA bits can be the same for a CE from 192.0.2.0/24 range and for a CE from 200.0.2.0/24 range. what is the consequence if the CE has the two rules? NOTE the delegation is independent of the IPv4 address in use. for example,= we have 2001:0:00xx:y000::/52 for the CE, where xx (8 bits) is the same as= the IPv4 suffix while y (4 bits) is applied for the PSID. if the source ad= dress has been selected from either rule ipv4 prefix, then the encapsulatio= n or translation is determined and the BR can de-capsulate or de-translate = that without any difficulty because the full IPv4 address is embedded in th= e IID part. when the response comes, the destination address of the IPv4 pa= cket is also determined though they would be encapsulated with the same IPv= 6 prefix (not the same IPv6 CE address!). [Senthil2] I don=92t see any issues with correctly decapsulating/translatin= g the packet on the BR for v6->v4. The issue is with the v4->v6. You cannot= correctly know which of the two IP addresses to embed. With translation, t= he communication will definitely fail if you embed the wrong IP address. the only concern is: if such a configuration can make different source IPv4= address for the packets of the same session. if so, the session might be t= roubled especially it is connection-oriented. [Senthil2] It will. There is a 50% chance that you don=92t use the same add= ress as the one the that the client used. Because there is no state. however, we may notice that NAT44 in the CE is not stateless. what is selec= ted for the session initialization would be continuously used for the subse= quent process of the same session. if the address is not shared so that the= re is no NAT44, the native IPv4 source address selection logic will decide = the selection and makes it unique for a specific destination. [Senthil2] With NAT44, it is even more stricter, if the BR didn=92t pick th= e right IPv4 address the NAT44 state table wont match the incoming packet. therefore personally i doubt the above multi-rule case doesn't work. if i a= m right, it is not needed to make 'Rule IPv4 Prefix' unique per 'Rule IPv6 = Prefix'. In this example above, it is assumed that the delegated prefix (IA-PD) that= DHCPv6 Server is handing out to CEs is 2001::/40 with delegated prefix len= gth /56. why /56 instead of /52? :P This makes me believe that each rule must not only be uniqu= e (because the above two rules are unique) but instead each rule must have = a unique =91Rule IPv6 prefix=92 and a unique =91Rule IPv4 Prefix=92 per = =91Rule IPv6 prefix=92 (IPv4 uniqueness is important in the downstream dire= ction where lookup is performed based on IPv4). [Senthil] Right. The rules must not be overlapping with one another. Each d= omain can have a single IPv6 & single IPv4 rule prefix only. The ipv6 and i= pv4 rule prefix should not overlap with other ipv6 and ipv4 rules prefixes = respectively in other domains. 2) What constitutes a MAP domain? I=92d think a unique =91Rule IPv6 Pr= efix=92 which (assuming that 1) is correct) would mean that a Domain =3D B= MR. In other words, can a MAP domain contain a collection of BMRs? The draf= ts mention virtual-links, etc=85but it would be simpler if we can say Domai= n=3DBMR (not sure if this is accurate though). Of course, nodes sharing th= e same set of those rules would be in the same MAP domain. [Senthil] Each MAP domain should have a single rule IPv6 prefix and single = IPv4 prefix. I think a single IPv4 prefix may be too restrictive in some d= eployments and people might want to use more than one prefix. But as you ha= ve shown EA length can cause ambiguity and hence makes it undeployable. 3) Is overlapping of =91Rule IPv6 Prefixes=92 supported? For example in the above case, can we have for Rule 2) the =91Rule IPv6 pre= fix=92 as 2001:0:80::/42. In this case the =91Rule IPv6 Prefix=92 from Rule 1 overlaps with =91Rule I= Pv6 Prefix=92 from Rule 2. I assume that this would not be supported for th= e same reason as in 1). I didn=92t think about the applicability of this sc= enario for now, it is more of a theoretical question. again, let's observe the consequence. again, we have the independently dele= gated prefix for the CE. if the CE has the pd like 2001:0:81:6000::/54, it = matches both rules surely. longest-match can determine which rule is in us= e (though not yet specified?). however, such a way may cause a subset of IP= v4 residual addresses never used (i.e., wasted). in this example, the longe= st match to 2001:0:80::/42 may block 192.0.2.128/26 = (192.0.2.128 - 192.0.2.191) from using. [Senthil2] That is a bad thing if you have to waste any of the addresses, a= s that is what we are trying to conserve here. And all this pain of sharing= addresses is defeated. I guess the bigger question why should one have such a design and its usefu= lness. the really problematic stuff is both rule IPv4 prefixes and rule IPv6 prefi= xes are overlapped among two rules but not aggregated. Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/24, ea-length =3D 12 Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D 192.0.2.0= /26, ea-length =3D 12 [Senthil2] Well, I think you are trying to prove that one can have two rule= IPv6 prefixes but as long as the ipv4 addresses don=92t overlap then we wi= ll be able to unambiguosly encap/decap/translate the packets. But I wonder = what is the advantage of having two rule IPv6 prefixes. In the above case, = the /26 is a subset of /24, so really there is no real advantage of having = a separate rule ipv4 prefix. and one CE-a has delegated prefix 2001:0:3f:5000::/52, while another CE-b h= as 2001:0:bf:5000::/54. such a delegation seems no problem at all. CE-a mat= ches Rule 1 while CE-b matches Rule 2. then the trouble happens: CE-a will = use the IPv4 address 192.0.2.63 with PSID =3D binary_0101, obviously; while= CE-b have 40-55bits =3D 0x8fd4 =3D binary_1011 1111 0101 0000 then EA-bits =3D binary_11 1111 0101 00 then IPv4 suffix =3D binary_11 1111, PSID =3D binary_0101 00 when attached to 192.0.2.0/26, it will be 192.0.2.= 63 with PSID =3D binary_0101 00 i.e., CE-b's usable port-range is overlapped with CE-a on the same IPv4 add= ress! therefore, IMHO, the constraint of BMR-making MUST ensure the (IPv4 address= , port-range)-pair is not overlapped among different CE, therefore Rule IPv= 4 Prefixes cannot be overlapped among BMRs. this is necessary and sufficien= t. [Senthil2] I agree with your example and assertion above. But I really don= =92t see a good use case for having multiple rule IPv6 prefixes and overlap= ping rule IPv4 prefixes. Maybe the use case for a overlapping rule IPv4 case is more compelling, as = you can get two blocks of public addresses that overlap on the lower n bits= , where the n bits are not unique enough in the EA bits to identify which r= ule IPv4 address to chose (mostly an issue for BR in the v4->v6 direction). Thanks Senthil if i made mistakes, please point out without hesitation. thanks a lot! - maoke [Senthil] No, atleast in our implementation we have checks to make sure the= prefixes don=92t overlap. Thanks Senthil Thanks, Kris _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_CB1B483277FEC94E9B58357040EE5D02322EE05Cxmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1FBBA2528B627E4AB6E130F977F3AD34@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Maoke,
Please see inline for Senthil2

From: Maoke <fibrib@gmail.com>
Date: Tuesday, December 11, 2012 5:= 21 AM
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: "Poscic, Kristian (Kristia= n)" <kristian= .poscic@alcatel-lucent.com>, "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] MAP-E/T ov= erlaping ranges and domains

hi Senthil,

interesting discussion. see inline.

2012/12/11 Senthil Sivakumar (ssenthil) <ssenthil@cisco.= com>


From: <Poscic>, "Kristia= n (Kristian)" <kristian.poscic@alcatel-lucent.com>
Date: Monday, December 10, 2012 3:0= 6 PM
To: "softwires@ietf.org" <softwires@ietf.org>
Subject: [Softwires] MAP-E/T overla= ping ranges and domains

Can someone clarify a few things for me:

 

1) &nb= sp;    Does MAP support this scenario (example= ):

-          (BMR) Rule 1:  

Rule IPv6 Prefix:  &= nbsp;            200= 1::/40

Rule IPv4 Prefix:  &= nbsp;            192.0.2.0/24

Rule EA-bits length: = ;       12

-          (BMR) Rule 2:

Rule IPv6 Prefix:  &= nbsp;            200= 1::/40

Rule IPv4 Prefix:  &= nbsp;            200.0.2.0/24

Rule EA-bits length: = ;       12

 

        &nbs= p;       The only difference between these tw= o rules above is the =91Rule IPv4 Prefix=92, everything else is the same. M= y obvious answer would be that this scenario is not supported but wanted to= be sure that I=92m not missing anything.

This scenario above would= result in ambiguity between CEs, i.e. a single IA-PD that is delegated to = a CE can be associated with either of the two  rules above (EA bits ca= n be the same for a CE from 192.0.2.0/24 range an= d for  a CE from 200.0.2.0/24 range.


what is the consequence if the CE has the two rules?

NOTE the delegation is independent of the IPv4 address in use. for example,= we have 2001:0:00xx:y000::/52 for the CE, where xx (8 bits) is the same as= the IPv4 suffix while y (4 bits) is applied for the PSID. if the source ad= dress has been selected from either rule ipv4 prefix, then the encapsulation or translation is determined and = the BR can de-capsulate or de-translate that without any difficulty because= the full IPv4 address is embedded in the IID part. when the response comes= , the destination address of the IPv4 packet is also determined though they would be encapsulated with the = same IPv6 prefix (not the same IPv6 CE address!).

[Senthil2] I don=92t see any issues with correctly decapsulating/trans= lating the packet on the BR for v6->v4. The issue is with the v4->v6.= You cannot correctly know which of the two IP addresses to embed. With tra= nslation, the communication will definitely fail if you embed the wrong IP address. 

the only concern is: if such a configuration can make different source IPv4= address for the packets of the same session. if so, the session might be t= roubled especially it is connection-oriented.

[Senthil2] It will. There is a 50% chance that you don=92t use the sam= e address as the one the that the client used. Because there is no state.

however, we may notice that NAT44 in the CE is not stateless. what is = selected for the session initialization would be continuously used for the = subsequent process of the same session. if the address is not shared so tha= t there is no NAT44, the native IPv4 source address selection logic will decide the selection and makes it= unique for a specific destination.

[Senthil2] With NAT44, it is even more stricter, if the BR didn=92t pi= ck the right IPv4 address the NAT44 state table wont match the incoming pac= ket. 


therefore personally i doubt the above multi-rule case doesn't work. if i a= m right, it is not needed to make 'Rule IPv4 Prefix' unique per 'Rule IPv6 = Prefix'.
 

In this example above, it= is assumed that the delegated prefix (IA-PD) that DHCPv6 Server is handing= out to CEs is 2001::/40 with delegated prefix length /56.


why /56 instead of /52? :P
 

 

        &nbs= p;       This makes me believe that each rule= must not only be unique (because the above two rules are unique) but inste= ad each rule must have a unique  =91Rule IPv6 prefix=92 and a unique = =91Rule IPv4 Prefix=92 per =91Rule IPv6 prefix=92 (IPv4 uniqueness is important in the downstream direction where lookup is perfor= med based on IPv4).

[Senthil] Right. The rules must not be overlapping with one another. E= ach domain can have a single IPv6 & single IPv4 rule prefix only. The i= pv6 and ipv4 rule prefix should not overlap with other ipv6 and ipv4 rules = prefixes respectively in other domains.

 

2) &nb= sp;    What constitutes a MAP domain? I=92d th= ink a unique =91Rule IPv6 Prefix=92 which  (assuming that 1) is correc= t) would mean that a Domain =3D BMR. In other words, can a MAP domain conta= in a collection of BMRs? The drafts mention virtual-links, etc=85but it would be simpler i= f we can say Domain=3DBMR (not sure if this is accurate though).  Of c= ourse, nodes sharing the same set of those rules would be in the same MAP d= omain.

[Senthil] Each MAP domain should have a single rule IPv6 prefix and si= ngle IPv4 prefix.  I think a single IPv4 prefix may be too restrictive= in some deployments and people might want to use more than one prefix. But= as you have shown EA length can cause ambiguity and hence makes it undeployable.

 

3) &nb= sp;    Is overlapping of =91Rule IPv6 Prefixes= =92 supported?

For example in the above case, can we have for Rule 2) the =91Rule IPv6 = prefix=92 as 2001:0:80::/42.

In this case the =91Rule IPv6 Prefix=92 from Rule 1 overlaps with =91Rul= e IPv6 Prefix=92 from Rule 2. I assume that this would not be supported for= the same reason as in 1). I didn=92t think about the applicability of this= scenario for now, it is more of a theoretical question.


again, let's observe the consequence. again, we have the independently dele= gated prefix for the CE. if the CE has the pd like 2001:0:81:6000::/54, it = matches both rules surely.  longest-match can determine which rule is = in use (though not yet specified?). however, such a way may cause a subset of IPv4 residual addresses never used (i.e.,= wasted). in this example, the longest match to 2001:0:80::/42 may block 192.0.2.128/26 (192.0.2.128 - 192.0.2= .191) from using.

[Senthil2] That is a bad thing if you have to waste any of the address= es, as that is what we are trying to conserve here. And all this pain of sh= aring addresses is defeated.
I guess the bigger question why should one have such a design and its = usefulness. 

the really problematic stuff is both rule IPv4 prefixes and rule IPv6 prefi= xes are overlapped among two rules but not aggregated.

Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/24, ea-length =3D 12
Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D 192.0.2.0/26, ea-length =3D 12

[Senthil2] Well, I think you are trying to prove that one can have two= rule IPv6 prefixes but as long as the ipv4 addresses don=92t overlap then = we will be able to unambiguosly encap/decap/translate the packets. But I wo= nder what is the advantage of having two rule IPv6 prefixes. In the above case, the /26 is a subset of /24, so = really there is no real advantage of having a separate rule ipv4 prefix.

and one CE-a has delegated prefix 2001:0:3f:5000::/52, while another CE-b h= as 2001:0:bf:5000::/54. such a delegation seems no problem at all. CE-a mat= ches Rule 1 while CE-b matches Rule 2. then the trouble happens: CE-a will = use the IPv4 address 192.0.2.63 with PSID =3D binary_0101, obviously; while CE-b have

    40-55bits =3D 0x8fd4 =3D binary_1011 1111 0101 0000
    then EA-bits =3D binary_11 1111 0101 00
    then IPv4 suffix =3D binary_11 1111, PSID =3D binary_010= 1 00
    when attached to 192.0.2= .0/26, it will be 192.0.2.63 with PSID =3D binary_0101 00

i.e., CE-b's usable port-range is overlapped with CE-a on the same IPv4 add= ress!

therefore, IMHO, the constraint of BMR-making MUST ensure the (IPv4 address= , port-range)-pair is not overlapped among different CE, therefore Rule IPv= 4 Prefixes cannot be overlapped among BMRs. this is necessary and sufficien= t.

[Senthil2] I agree with your example and assertion above. But I really= don=92t see a good use case for having multiple rule IPv6 prefixes and ove= rlapping rule IPv4 prefixes.
Maybe the use case for a overlapping rule IPv4 case is more compelling= , as you can get two blocks of public addresses that overlap on the lower n= bits, where the n bits are not unique enough in the EA bits to identify wh= ich rule IPv4 address to chose (mostly an issue for BR in the v4->v6 direction).

Thanks
Senthil




if i made mistakes, please point out without hesitation. thanks a lot!

- maoke

[Senthil] No, atleast in our implementation we have checks to make sur= e the prefixes don=92t overlap.

Thanks
Senthil

 

Thanks,

Kris

 


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


 --_000_CB1B483277FEC94E9B58357040EE5D02322EE05Cxmbrcdx15ciscoc_-- From kristian.poscic@alcatel-lucent.com Tue Dec 11 15:05: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 BFAEC21F861F for ; Tue, 11 Dec 2012 15:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.031 X-Spam-Level: X-Spam-Status: No, score=-9.031 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnUIb69O6O8Z for ; Tue, 11 Dec 2012 15:05:03 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 02AFE21F861E for ; Tue, 11 Dec 2012 15:05:02 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBBN50Rh030408 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Dec 2012 00:05:00 +0100 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 12 Dec 2012 00:05:00 +0100 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.227]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Tue, 11 Dec 2012 18:04:56 -0500 From: "Poscic, Kristian (Kristian)" To: "Senthil Sivakumar (ssenthil)" , Maoke Thread-Topic: [Softwires] MAP-E/T overlaping ranges and domains Thread-Index: Ac3XETWFsOgBqEDlSUKDU5M2A4wCIQAMnBmAABvfHwAAE0uWgAADHXBA Date: Tue, 11 Dec 2012 23:04:55 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AA294C5@US70UWXCHMBA05.zam.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AA294C5US70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains 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, 11 Dec 2012 23:05:04 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02AA294C5US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For the first case where we would allow multiple Rule IPv4 prefixes per sin= gle Rule IPv6 prefix, I agree that downstream lookup would be problematic. But don't we even have a problem even before we get to that point...The who= le scenario presuppose that the two (or more) CEs would need the same deleg= ated IPv6 prefix - this process can be independent of MAP and the IA-PD is = assigned for example via DHCP server (plain IPv6 address assignment). It is simply not doable that a DHCP server hands out the same DHCP leases t= o two different clients. It seemed to me that this was not that big of a de= al in this discussion and I just wanted to make sure I'm not missing anythi= ng. For the overlapping cases I think as long as the bits from the shortest Rul= e IPv6 prefix length all the way to the PD length are unique, things should= work but carving out non-overlapping subnets,ports may be bigger trouble = for the operators than not . why /56 instead of /52? :P =3D> yes I agree it would be less wasteful. Kris From: Senthil Sivakumar (ssenthil) [mailto:ssenthil@cisco.com] Sent: Tuesday, December 11, 2012 11:34 AM To: Maoke Cc: Poscic, Kristian (Kristian); softwires@ietf.org Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains Hi Maoke, Please see inline for Senthil2 From: Maoke > Date: Tuesday, December 11, 2012 5:21 AM To: Senthil Sivakumar > Cc: "Poscic, Kristian (Kristian)" >, "softwires@ietf.org" > Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains hi Senthil, interesting discussion. see inline. 2012/12/11 Senthil Sivakumar (ssenthil) > --_000_7921F977B17D5B49B8DCC955A339D2F02AA294C5US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For the first case where = we would allow multiple Rule IPv4 prefixes per single Rule IPv6 prefix, I a= gree that downstream lookup would be problematic.

But don’t we even h= ave a problem even before we get to that point…The whole scenario pre= suppose that the two (or more) CEs would need the same delegated IPv6 prefix – this process can be independent of MAP and the IA-PD is ass= igned for example via DHCP server  (plain IPv6 address assignment).

It is simply not doable t= hat a DHCP server hands out the same DHCP leases to two different clients. = It seemed to me that this was not that big of a deal in this discussion and I just wanted to make sure I’m not missing anyth= ing.

 <= /p>

For the overlapping cases= I think as long as the bits from the shortest Rule IPv6 prefix length all = the way to the PD length are unique, things should work but carving out non-overlapping subnets,ports  may be bigger trouble = for the operators than not .

 <= /p>

why /56 instead of /52? :P     =3D> yes I agree it would be less wast= eful.

 <= /p>

Kris

 <= /p>

 <= /p>

From: Senthil = Sivakumar (ssenthil) [mailto:ssenthil@cisco.com]
Sent: Tuesday, December 11, 2012 11:34 AM
To: Maoke
Cc: Poscic, Kristian (Kristian); softwires@ietf.org
Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains<= /o:p>

 

Hi Maoke,=

Please see inline for Senth= il2

 

From: Maoke <fibrib@gmail.com>
Date: Tuesday, December 11, 2012 5:21 AM
To: Senthil Sivakumar <ssen= thil@cisco.com>
Cc: "Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com>= ;, "softwires@ietf.org"= <softwires@ietf.org>
Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains<= /o:p>

 

hi Senthil,

interesting discussion. see inline.

2012/12/11 Senthil Sivakuma= r (ssenthil) <ss= enthil@cisco.com>

 

--_000_7921F977B17D5B49B8DCC955A339D2F02AA294C5US70UWXCHMBA05z_-- From fibrib@gmail.com Tue Dec 11 17:24:30 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 B3FA221E80BA for ; Tue, 11 Dec 2012 17:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZcH9rAo8Olq for ; Tue, 11 Dec 2012 17:24:28 -0800 (PST) Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by ietfa.amsl.com (Postfix) with ESMTP id 2B13B21E8096 for ; Tue, 11 Dec 2012 17:24:28 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id k14so30937eaa.26 for ; Tue, 11 Dec 2012 17:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qv/TeUdEDGNOJG+laiGaNNIiEMBIcUYiUNe/S/EI9u0=; b=dMB8iU9kzuoaW1m4CbVBT5V8CBW2uhqr11tv95auQmvle1Kpaf/qEfuVKb36O3C0WX IweUFi2IDCsXk6kX2Hmsu6p6+e5TJV5rbtPeQR7Q63NCB76V4sQF6RI2omW71fFg667T oqbwXWk88vccO4hTxBTS8GYfWNDpyyJAKyBsOMHiHVdQHnEDAa+h3FJ+hxuj/igtQar4 LDFY0oGIo321I1x2fDOe4SG8L8+cyanEdV6pJ9RwSsYi3IKZQHJGy6gMI8m3PCgXtgh2 dcJzT53e9jtdxVXWdRgS8rUl6F2lERzv2C4fiS/NWUX/lNownsjENtH729hx1Iiry4St ZCHw== MIME-Version: 1.0 Received: by 10.14.203.8 with SMTP id e8mr338024eeo.2.1355275463594; Tue, 11 Dec 2012 17:24:23 -0800 (PST) Received: by 10.223.74.85 with HTTP; Tue, 11 Dec 2012 17:24:23 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Dec 2012 10:24:23 +0900 Message-ID: From: Maoke To: "Senthil Sivakumar (ssenthil)" Content-Type: multipart/alternative; boundary=047d7b343aba94922404d09da8ff Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains 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, 12 Dec 2012 01:24:30 -0000 --047d7b343aba94922404d09da8ff Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi Senthil, inline for maoke2 2012/12/12 Senthil Sivakumar (ssenthil) > Hi Maoke, > Please see inline for Senthil2 > > From: Maoke > Date: Tuesday, December 11, 2012 5:21 AM > To: Senthil Sivakumar > Cc: "Poscic, Kristian (Kristian)" , " > softwires@ietf.org" > Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains > > hi Senthil, > > interesting discussion. see inline. > > 2012/12/11 Senthil Sivakumar (ssenthil) > >> >> >> From: , "Kristian (Kristian)" < >> kristian.poscic@alcatel-lucent.com> >> Date: Monday, December 10, 2012 3:06 PM >> To: "softwires@ietf.org" >> Subject: [Softwires] MAP-E/T overlaping ranges and domains >> >> Can someone clarify a few things for me:**** >> >> ** ** >> >> 1) Does MAP support this scenario (example):**** >> >> - (BMR) Rule 1: **** >> >> Rule IPv6 Prefix: 2001::/40**** >> >> Rule IPv4 Prefix: 192.0.2.0/24**** >> >> Rule EA-bits length: 12**** >> >> - (BMR) Rule 2:**** >> >> Rule IPv6 Prefix: 2001::/40**** >> >> Rule IPv4 Prefix: 200.0.2.0/24**** >> >> Rule EA-bits length: 12**** >> >> ** ** >> >> The only difference between these two rules above is the >> =91Rule IPv4 Prefix=92, everything else is the same. My obvious answer w= ould be >> that this scenario is not supported but wanted to be sure that I=92m not >> missing anything.**** >> >> This scenario above would result in ambiguity between CEs, i.e. a single >> IA-PD that is delegated to a CE can be associated with either of the two >> rules above (EA bits can be the same for a CE from 192.0.2.0/24 range >> and for a CE from 200.0.2.0/24 range. >> > > what is the consequence if the CE has the two rules? > > NOTE the delegation is independent of the IPv4 address in use. for > example, we have 2001:0:00xx:y000::/52 for the CE, where xx (8 bits) is t= he > same as the IPv4 suffix while y (4 bits) is applied for the PSID. if the > source address has been selected from either rule ipv4 prefix, then the > encapsulation or translation is determined and the BR can de-capsulate or > de-translate that without any difficulty because the full IPv4 address is > embedded in the IID part. when the response comes, the destination addres= s > of the IPv4 packet is also determined though they would be encapsulated > with the same IPv6 prefix (not the same IPv6 CE address!). > > [Senthil2] I don=92t see any issues with correctly > decapsulating/translating the packet on the BR for v6->v4. The issue is > with the v4->v6. You cannot correctly know which of the two IP addresses = to > embed. With translation, the communication will definitely fail if you > embed the wrong IP address. > [maoke2] i cannot catch your point. you mean v4->v6 at BR, right? which IPv4 address to embed is determined by the session initiator. for example, if a host behind CE makes a connection to 8.8.8.8, and if the CE happens to have picking up 192.0.2.191 as the src IPv4 address, then the 8.8.8.8 will response 192.0.2.191 definitely. i don't see that BR needs to choose an IPv4 address to embed: the destination address in the packet replying to the session initiator is determined. > > the only concern is: if such a configuration can make different source > IPv4 address for the packets of the same session. if so, the session migh= t > be troubled especially it is connection-oriented. > > [Senthil2] It will. There is a 50% chance that you don=92t use the same > address as the one the that the client used. Because there is no state. > > however, we may notice that NAT44 in the CE is not stateless. what is > selected for the session initialization would be continuously used for th= e > subsequent process of the same session. if the address is not shared so > that there is no NAT44, the native IPv4 source address selection logic wi= ll > decide the selection and makes it unique for a specific destination. > > [Senthil2] With NAT44, it is even more stricter, if the BR didn=92t pick > the right IPv4 address the NAT44 state table wont match the incoming > packet. > [maoke2] misunderstanding. BR don't have the chance to *pick up* IPv4 address. > > > therefore personally i doubt the above multi-rule case doesn't work. if i > am right, it is not needed to make 'Rule IPv4 Prefix' unique per 'Rule IP= v6 > Prefix'. > > >> **** >> >> In this example above, it is assumed that the delegated prefix (IA-PD) >> that DHCPv6 Server is handing out to CEs is 2001::/40 with delegated pre= fix >> length /56. >> > > why /56 instead of /52? :P > > >> **** >> >> ** ** >> >> This makes me believe that each rule must not only be >> unique (because the above two rules are unique) but instead each rule mu= st >> have a unique =91Rule IPv6 prefix=92 and a unique =91Rule IPv4 Prefix= =92 per =91Rule >> IPv6 prefix=92 (IPv4 uniqueness is important in the downstream direction >> where lookup is performed based on IPv4). >> >> [Senthil] Right. The rules must not be overlapping with one another. >> Each domain can have a single IPv6 & single IPv4 rule prefix only. The i= pv6 >> and ipv4 rule prefix should not overlap with other ipv6 and ipv4 rules >> prefixes respectively in other domains. >> >> **** >> >> ** ** >> >> 2) What constitutes a MAP domain? I=92d think a unique =91Rule IPv6 >> Prefix=92 which (assuming that 1) is correct) would mean that a Domain = =3D >> BMR. In other words, can a MAP domain contain a collection of BMRs? The >> drafts mention virtual-links, etc=85but it would be simpler if we can sa= y >> Domain=3DBMR (not sure if this is accurate though). Of course, nodes sh= aring >> the same set of those rules would be in the same MAP domain. >> >> [Senthil] Each MAP domain should have a single rule IPv6 prefix and >> single IPv4 prefix. I think a single IPv4 prefix may be too restrictive= in >> some deployments and people might want to use more than one prefix. But = as >> you have shown EA length can cause ambiguity and hence makes it >> undeployable. >> >> **** >> >> ** ** >> >> 3) Is overlapping of =91Rule IPv6 Prefixes=92 supported?**** >> >> For example in the above case, can we have for Rule 2) the =91Rule IPv6 >> prefix=92 as 2001:0:80::/42.**** >> >> In this case the =91Rule IPv6 Prefix=92 from Rule 1 overlaps with =91Rul= e IPv6 >> Prefix=92 from Rule 2. I assume that this would not be supported for the= same >> reason as in 1). I didn=92t think about the applicability of this scenar= io >> for now, it is more of a theoretical question. >> > > again, let's observe the consequence. again, we have the independently > delegated prefix for the CE. if the CE has the pd like 2001:0:81:6000::/5= 4, > it matches both rules surely. longest-match can determine which rule is = in > use (though not yet specified?). however, such a way may cause a subset o= f > IPv4 residual addresses never used (i.e., wasted). in this example, the > longest match to 2001:0:80::/42 may block 192.0.2.128/26 (192.0.2.128 - > 192.0.2.191) from using. > > [Senthil2] That is a bad thing if you have to waste any of the > addresses, as that is what we are trying to conserve here. And all this > pain of sharing addresses is defeated. > [maoke2] agree that it is bad if we have waste. > I guess the bigger question why should one have such a design and its > usefulness. > [maoke2] the bigger question is not only about the significance of allowing it but also about the significance of forbidding it, and about what if it happens even we have tried to forbid it. i surely don't encourage any waste but try to understand what we might have if we don't forbid it -- in order to make a proper statement in the specification. > the really problematic stuff is both rule IPv4 prefixes and rule IPv6 > prefixes are overlapped among two rules but not aggregated. > > Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/24= , > ea-length =3D 12 > Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D 192.0.2= .0/26, > ea-length =3D 12 > > [Senthil2] Well, I think you are trying to prove that one can have two > rule IPv6 prefixes but as long as the ipv4 addresses don=92t overlap then= we > will be able to unambiguosly encap/decap/translate the packets. But I > wonder what is the advantage of having two rule IPv6 prefixes. > [maoke2] if all controlled by one party, it is true there is no obvious advantage at current understanding. however, what if two rule IPv6 prefixes are the reality, out of our control? ;-) > In the above case, the /26 is a subset of /24, so really there is no real > advantage of having a separate rule ipv4 prefix. > [maoke2] rule IPv4 prefix overlapping is another question. and i tried to show it is really harmful. in practice, it is understood that aggregateable IPv4 prefixes' corresponding IPv6 prefixes MUST be aggregated in the same way. > > and one CE-a has delegated prefix 2001:0:3f:5000::/52, while another CE-b > has 2001:0:bf:5000::/54. such a delegation seems no problem at all. CE-a > matches Rule 1 while CE-b matches Rule 2. then the trouble happens: CE-a > will use the IPv4 address 192.0.2.63 with PSID =3D binary_0101, obviously= ; > while CE-b have > > 40-55bits =3D 0x8fd4 =3D binary_1011 1111 0101 0000 > then EA-bits =3D binary_11 1111 0101 00 > then IPv4 suffix =3D binary_11 1111, PSID =3D binary_0101 00 > when attached to 192.0.2.0/26, it will be 192.0.2.63 with PSID =3D > binary_0101 00 > > i.e., CE-b's usable port-range is overlapped with CE-a on the same IPv4 > address! > > therefore, IMHO, the constraint of BMR-making MUST ensure the (IPv4 > address, port-range)-pair is not overlapped among different CE, therefore > Rule IPv4 Prefixes cannot be overlapped among BMRs. this is necessary and > sufficient. > > [Senthil2] I agree with your example and assertion above. But I really > don=92t see a good use case for having multiple rule IPv6 prefixes and > overlapping rule IPv4 prefixes. > [maoke2] when we deploy a MAP domain, it is definitely not necessary to make complicated scenarios. however, it is possible happen in reality: as prefix delegation is independent of the MAP deployment, it is possible that two MAP domains deployed so that a CE possibly joins both. i also highlight the use-case that MAP domain can be deployed across ASes, where the delegated prefix is not controlled by the party deploying MAP and surely the party cannot make sure if this pd is also used by another MAP deployment party or not. [maoke2] i have not yet concluded that the above scenario makes sense or not. however, your thread raises very important questions related to such a scenario and therefore we need to understand/clarify what does make sense what really doesn't. > Maybe the use case for a overlapping rule IPv4 case is more compelling, a= s > you can get two blocks of public addresses that overlap on the lower n > bits, where the n bits are not unique enough in the EA bits to identify > which rule IPv4 address to chose (mostly an issue for BR in the v4->v6 > direction). > thanks, maoke > > Thanks > Senthil > > > > > if i made mistakes, please point out without hesitation. thanks a lot! > > - maoke > > >> [Senthil] No, atleast in our implementation we have checks to make sure >> the prefixes don=92t overlap. >> >> Thanks >> Senthil >> >> **** >> >> ** ** >> >> Thanks,**** >> >> Kris **** >> >> ** ** >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > --047d7b343aba94922404d09da8ff Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable hi Senthil,

inline for maoke2

201= 2/12/12 Senthil Sivakumar (ssenthil) <ssenthil@cisco.com>
Hi Maoke,
Please see inline for Senthil2

From: Maoke <fibrib@gmail.com>
Date: Tuesday, December 11, 2012 5:= 21 AM
To: Senthil Sivakumar <ssenthil@cisco.com>=
Cc: "Poscic, Kristian (Kristia= n)" <kristian.poscic@alcatel-lucent.com>, "softwires@ietf.org" <= ;softwires@ietf.org= >
Subject: Re: [Softwires] MAP-E/T ov= erlaping ranges and domains

hi Senthil,

interesting discussion. see inline.

2012/12/11 Senthil Sivakumar (ssenthil) <ssenthil@cisco.= com>


From: <Poscic>, "Kristia= n (Kristian)" <kristian.poscic@alcatel-lucent.com>
Date: Monday, December 10, 2012 3:0= 6 PM
To: "softwires@ietf.org" <softwires@ietf.org>
Subject: [Softwires] MAP-E/T overla= ping ranges and domains

Can someone clarify a few things for me:

=A0

1)=A0=A0=A0= =A0=A0 Does MAP support this scenario (example):

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 (BMR) Rule 1:=A0=A0

Rule IPv6 Prefix: =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2001::/40

Rule IPv4 Prefix: =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 192.0.2.0/24

Rule EA-bits length:=A0= =A0=A0=A0=A0=A0=A0 12

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 (BMR) Rule 2:

Rule IPv6 Prefix: =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2001::/40

Rule IPv4 Prefix: =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 200.0.2.0/24

Rule EA-bits length:=A0= =A0=A0=A0=A0=A0=A0 12

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The on= ly difference between these two rules above is the =91Rule IPv4 Prefix=92, = everything else is the same. My obvious answer would be that this scenario = is not supported but wanted to be sure that I=92m not missing anything.<= /u>

This scenario above would= result in ambiguity between CEs, i.e. a single IA-PD that is delegated to = a CE can be associated with either of the two =A0rules above (EA bits can b= e the same for a CE from 192.0.2.0/24 range an= d for =A0a CE from 200.0.2.0/24 range.


what is the consequence if the CE has the two rules?

NOTE the delegation is independent of the IPv4 address in use. for example,= we have 2001:0:00xx:y000::/52 for the CE, where xx (8 bits) is the same as= the IPv4 suffix while y (4 bits) is applied for the PSID. if the source ad= dress has been selected from either rule ipv4 prefix, then the encapsulation or translation is determined and = the BR can de-capsulate or de-translate that without any difficulty because= the full IPv4 address is embedded in the IID part. when the response comes= , the destination address of the IPv4 packet is also determined though they would be encapsulated with the = same IPv6 prefix (not the same IPv6 CE address!).

[Senthil2] I don=92t see any issues with correctly decapsulating/trans= lating the packet on the BR for v6->v4. The issue is with the v4->v6.= You cannot correctly know which of the two IP addresses to embed. With tra= nslation, the communication will definitely fail if you embed the wrong IP address.=A0
<= /div>

[maoke2] i cannot catch your point. you mean v4-= >v6 at BR, right? which IPv4 address to embed is determined by the sessi= on initiator. for example, if a host behind CE makes a connection to 8.8.8.= 8, and if the CE happens to have picking up 192.0.2.191 as the src IPv4 add= ress, then the 8.8.8.8 will response 192.0.2.191 definitely. i don't se= e that BR needs to choose an IPv4 address to embed: the destination address= in the packet replying to the session initiator is determined.



the only concern is: if such a configuration can make different source IPv4= address for the packets of the same session. if so, the session might be t= roubled especially it is connection-oriented.

[Senthil2] It will. There is a 50% chance that you don=92t use the sam= e address as the one the that the client used. Because there is no state.

however, we may notice that NAT44 in the CE is not stateless. what is = selected for the session initialization would be continuously used for the = subsequent process of the same session. if the address is not shared so tha= t there is no NAT44, the native IPv4 source address selection logic will decide the selection and makes it= unique for a specific destination.

[Senthil2] With NAT44, it is even more stricter, if the BR didn= =92t pick the right IPv4 address the NAT44 state table wont match the incom= ing packet.=A0

[maoke2] misunderstanding. = BR don't have the chance to *pick up* IPv4 address.
=A0


therefore personally i doubt the above multi-rule case doesn't work. if= i am right, it is not needed to make 'Rule IPv4 Prefix' unique per= 'Rule IPv6 Prefix'.
=A0

In this example above, it= is assumed that the delegated prefix (IA-PD) that DHCPv6 Server is handing= out to CEs is 2001::/40 with delegated prefix length /56.


why /56 instead of /52? :P
=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This m= akes me believe that each rule must not only be unique (because the above t= wo rules are unique) but instead each rule must have a unique =A0=91Rule IP= v6 prefix=92 and a unique =91Rule IPv4 Prefix=92 per =91Rule IPv6 prefix=92= (IPv4 uniqueness is important in the downstream direction where lookup is perfor= med based on IPv4).

[Senthil] Right. The rules must not be overlapping with one another. E= ach domain can have a single IPv6 & single IPv4 rule prefix only. The i= pv6 and ipv4 rule prefix should not overlap with other ipv6 and ipv4 rules = prefixes respectively in other domains.

=A0

2)=A0=A0=A0= =A0=A0 What constitutes a MAP domain? I=92d think a unique = =91Rule IPv6 Prefix=92 which =A0(assuming that 1) is correct) would mean th= at a Domain =3D BMR. In other words, can a MAP domain contain a collection of BMRs? The drafts mention virtual-links, etc=85but it would be simpler i= f we can say Domain=3DBMR (not sure if this is accurate though).=A0 Of cour= se, nodes sharing the same set of those rules would be in the same MAP doma= in.

[Senthil] Each MAP domain should have a single rule IPv6 prefix and si= ngle IPv4 prefix. =A0I think a single IPv4 prefix may be too restrictive in= some deployments and people might want to use more than one prefix. But as= you have shown EA length can cause ambiguity and hence makes it undeployable.

=A0

3)=A0=A0=A0= =A0=A0 Is overlapping of =91Rule IPv6 Prefixes=92 supported?<= u>

For example in the above case, can we have for Rule 2) the =91Rule IPv6 = prefix=92 as 2001:0:80::/42.

In this case the =91Rule IPv6 Prefix=92 from Rule 1 overlaps with =91Rul= e IPv6 Prefix=92 from Rule 2. I assume that this would not be supported for= the same reason as in 1). I didn=92t think about the applicability of this= scenario for now, it is more of a theoretical question.


again, let's observe the consequence. again, we have the independently = delegated prefix for the CE. if the CE has the pd like 2001:0:81:6000::/54,= it matches both rules surely.=A0 longest-match can determine which rule is= in use (though not yet specified?). however, such a way may cause a subset of IPv4 residual addresses never used (i.e.,= wasted). in this example, the longest match to 2001:0:80::/42 may block 192.0.2.128/26 (192= .0.2.128 - 192.0.2.191) from using.

[Senthil2] That is a bad thing if you have to waste any of the a= ddresses, as that is what we are trying to conserve here. And all this pain= of sharing addresses is defeated.

[maoke2= ] agree that it is bad if we have waste.
=A0
I guess the bigger question why should one have such a design and its = usefulness.=A0

[maoke2] the bigger questio= n is not only about the significance of allowing it but also about the sign= ificance of forbidding it, and about what if it happens even we have tried = to forbid it. i surely don't encourage any waste but try to understand = what we might have if we don't forbid it -- in order to make a proper s= tatement in the specification.


the really problematic stuff is both rule IPv4 prefixes and rule IPv6 prefi= xes are overlapped among two rules but not aggregated.

Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/24, ea-length =3D 12
Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D 192.0.2.0/26, ea-length =3D 12

[Senthil2] Well, I think you are trying to prove that one can ha= ve two rule IPv6 prefixes but as long as the ipv4 addresses don=92t overlap= then we will be able to unambiguosly encap/decap/translate the packets. Bu= t I wonder=A0what is the advantage of having two rule IPv6 prefixes.

[maoke2] if all = controlled by one party, it is true there is no obvious advantage at curren= t understanding. however, what if two rule IPv6 prefixes are the reality, o= ut of our control? ;-)
=A0
In t= he above case, the /26 is a subset of /24, so really there is no real advan= tage of having a separate rule ipv4 prefix.

[maoke2] rule IPv4 prefix overlapping is anothe= r question. and i tried to show it is really harmful. in practice, it is un= derstood that aggregateable IPv4 prefixes' corresponding IPv6 prefixes = MUST be aggregated in the same way.
=A0

and one CE-a has delegated prefix 2001:0:3f:5000::/52, while another CE-b h= as 2001:0:bf:5000::/54. such a delegation seems no problem at all. CE-a mat= ches Rule 1 while CE-b matches Rule 2. then the trouble happens: CE-a will = use the IPv4 address 192.0.2.63 with PSID =3D binary_0101, obviously; while CE-b have

=A0=A0=A0 40-55bits =3D 0x8fd4 =3D binary_1011 1111 0101 0000
=A0=A0=A0 then EA-bits =3D binary_11 1111 0101 00
=A0=A0=A0 then IPv4 suffix =3D binary_11 1111, PSID =3D binary_0101 00
=A0=A0=A0 when attached to 192.0.2.0/26, it will be 192.0.2.63 with PSID =3D binary_0101 00

i.e., CE-b's usable port-range is overlapped with CE-a on the same IPv4= address!

therefore, IMHO, the constraint of BMR-making MUST ensure the (IPv4 address= , port-range)-pair is not overlapped among different CE, therefore Rule IPv= 4 Prefixes cannot be overlapped among BMRs. this is necessary and sufficien= t.

[Senthil2] I agree with your example and assertion above. But I = really don=92t see a good use case for having multiple rule IPv6 prefixes a= nd overlapping rule IPv4 prefixes.

[maoke2= ] when we deploy a MAP domain, it is definitely not necessary to make compl= icated scenarios. however, it is possible happen in reality: as prefix dele= gation is independent of the MAP deployment, it is possible that two MAP do= mains deployed so that a CE possibly joins both. i also highlight the use-c= ase that MAP domain can be deployed across ASes, where the delegated prefix= is not controlled by the party deploying MAP and surely the party cannot m= ake sure if this pd is also used by another MAP deployment party or not.
[maoke2] i have not yet concluded that the above scenario makes sense o= r not. however, your thread raises very important questions related to such= a scenario and therefore we need to understand/clarify what does make sens= e what really doesn't.
=A0
Maybe the use case for a overlapping rule IPv4 case is more compelling= , as you can get two blocks of public addresses that overlap on the lower n= bits, where the n bits are not unique enough in the EA bits to identify wh= ich rule IPv4 address to chose (mostly an issue for BR in the v4->v6 direction).
=
thanks,
maoke
=A0

Thanks
Senthil




if i made mistakes, please point out without hesitation. thanks a lot!

- maoke

[Senthil] No, atleast in our implementation we have checks to make sur= e the prefixes don=92t overlap.

Thanks
Senthil

=A0

Thanks,

Kris

=A0


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

--047d7b343aba94922404d09da8ff-- From ssenthil@cisco.com Wed Dec 12 10:45:51 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 AB24821F8818 for ; Wed, 12 Dec 2012 10:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.997 X-Spam-Level: X-Spam-Status: No, score=-9.997 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g67xJXefl6Rz for ; Wed, 12 Dec 2012 10:45:49 -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 2EB0E1F0CD9 for ; Wed, 12 Dec 2012 10:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39504; q=dns/txt; s=iport; t=1355337949; x=1356547549; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=lq005QuQU3ysu/xlzaIC0oCoSv+HOEhTJsdRtOpOIbg=; b=cAc6pKawHv1wYLywv6KNZ4sZY9p8NYqnF/9Z3Z8drQ4hR29L7YUYiVn4 T8J84LQZmpXxEOfVD8KTY4SQaT/8omFFV+6RA80MgNt3Huvl8Hzd/KDTY MMg7GnP5kQ2YndWqqkZxLZqtedlupi/YLArFuOeL4LajgH4qDIQZtieeO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFALLQyFCtJV2d/2dsb2JhbAA7CoJJqiGJGIhEUhZzgh4BAQEEAQEBFw0kASILEgEIEQIBAQILFgEGKAQCCxQJCAEBBA4FCId3Aw8Mry4BhFINiVWLYmkRg1FhA5JWgV2NDQOFDoJzgiI X-IronPort-AV: E=Sophos;i="4.84,267,1355097600"; d="scan'208,217";a="149232459" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 12 Dec 2012 18:45:44 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBCIjiLu025597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Dec 2012 18:45:44 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.80]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 12:45:44 -0600 From: "Senthil Sivakumar (ssenthil)" To: Maoke Thread-Topic: [Softwires] MAP-E/T overlaping ranges and domains Thread-Index: Ac3XETWFsOgBqEDlSUKDU5M2A4wCIQAMnBmAAB33kAAACNEVgAAWuzOAABnjvYA= Date: Wed, 12 Dec 2012 18:45:43 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.82.208.9] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D02322F063Axmbrcdx15ciscoc_" MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains 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, 12 Dec 2012 18:45:51 -0000 --_000_CB1B483277FEC94E9B58357040EE5D02322F063Axmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Please see [Senthil3] From: Maoke > Date: Tuesday, December 11, 2012 8:24 PM To: Senthil Sivakumar > Cc: "Poscic, Kristian (Kristian)" >, "softwires@ietf.org" > Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains hi Senthil, inline for maoke2 2012/12/12 Senthil Sivakumar (ssenthil) > Hi Maoke, Please see inline for Senthil2 From: Maoke > Date: Tuesday, December 11, 2012 5:21 AM To: Senthil Sivakumar > Cc: "Poscic, Kristian (Kristian)" >, "softwires@ietf.org" > Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains hi Senthil, interesting discussion. see inline. 2012/12/11 Senthil Sivakumar (ssenthil) > From: , "Kristian (Kristian)" > Date: Monday, December 10, 2012 3:06 PM To: "softwires@ietf.org" > Subject: [Softwires] MAP-E/T overlaping ranges and domains Can someone clarify a few things for me: 1) Does MAP support this scenario (example): - (BMR) Rule 1: Rule IPv6 Prefix: 2001::/40 Rule IPv4 Prefix: 192.0.2.0/24 Rule EA-bits length: 12 - (BMR) Rule 2: Rule IPv6 Prefix: 2001::/40 Rule IPv4 Prefix: 200.0.2.0/24 Rule EA-bits length: 12 The only difference between these two rules above is the = =91Rule IPv4 Prefix=92, everything else is the same. My obvious answer woul= d be that this scenario is not supported but wanted to be sure that I=92m n= ot missing anything. This scenario above would result in ambiguity between CEs, i.e. a single IA= -PD that is delegated to a CE can be associated with either of the two rul= es above (EA bits can be the same for a CE from 192.0.2.0/24 range and for a CE from 200.0.2.0/24 range. what is the consequence if the CE has the two rules? NOTE the delegation is independent of the IPv4 address in use. for example,= we have 2001:0:00xx:y000::/52 for the CE, where xx (8 bits) is the same as= the IPv4 suffix while y (4 bits) is applied for the PSID. if the source ad= dress has been selected from either rule ipv4 prefix, then the encapsulatio= n or translation is determined and the BR can de-capsulate or de-translate = that without any difficulty because the full IPv4 address is embedded in th= e IID part. when the response comes, the destination address of the IPv4 pa= cket is also determined though they would be encapsulated with the same IPv= 6 prefix (not the same IPv6 CE address!). [Senthil2] I don=92t see any issues with correctly decapsulating/translatin= g the packet on the BR for v6->v4. The issue is with the v4->v6. You cannot= correctly know which of the two IP addresses to embed. With translation, t= he communication will definitely fail if you embed the wrong IP address. [maoke2] i cannot catch your point. you mean v4->v6 at BR, right? which IPv= 4 address to embed is determined by the session initiator. for example, if = a host behind CE makes a connection to 8.8.8.8, and if the CE happens to ha= ve picking up 192.0.2.191 as the src IPv4 address, then the 8.8.8.8 will re= sponse 192.0.2.191 definitely. i don't see that BR needs to choose an IPv4 = address to embed: the destination address in the packet replying to the ses= sion initiator is determined. the only concern is: if such a configuration can make different source IPv4= address for the packets of the same session. if so, the session might be t= roubled especially it is connection-oriented. [Senthil2] It will. There is a 50% chance that you don=92t use the same add= ress as the one the that the client used. Because there is no state. however, we may notice that NAT44 in the CE is not stateless. what is selec= ted for the session initialization would be continuously used for the subse= quent process of the same session. if the address is not shared so that the= re is no NAT44, the native IPv4 source address selection logic will decide = the selection and makes it unique for a specific destination. [Senthil2] With NAT44, it is even more stricter, if the BR didn=92t pick th= e right IPv4 address the NAT44 state table wont match the incoming packet. [maoke2] misunderstanding. BR don't have the chance to *pick up* IPv4 addre= ss. [Senthil3] You are right, I missed that. But lets take your example: Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/24, ea-length =3D 12 Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D 192.0.2.0= /26, ea-length =3D 12 CE1 sends the packet with its prefix and using the global address 192.0.2.2= 0 sends a packet to the BR. The BR matches rule 1 (assuming that the longes= t matching prefix was that), and the resulting packet is a ipv4 packet with= a destination of 192.0.2.20 and the return packet comes back with the dest= ination of 192.0.2.20. That will match the rule2 because the longest prefix= match for the v4 address is 192.0.2.0/26. So we use rule2 to construct the= v6 packet. The destination v6 address is different now, even though you em= bedded the right v4 address in IID. How does that reach the CE-1? therefore personally i doubt the above multi-rule case doesn't work. if i a= m right, it is not needed to make 'Rule IPv4 Prefix' unique per 'Rule IPv6 = Prefix'. In this example above, it is assumed that the delegated prefix (IA-PD) that= DHCPv6 Server is handing out to CEs is 2001::/40 with delegated prefix len= gth /56. why /56 instead of /52? :P This makes me believe that each rule must not only be uniqu= e (because the above two rules are unique) but instead each rule must have = a unique =91Rule IPv6 prefix=92 and a unique =91Rule IPv4 Prefix=92 per = =91Rule IPv6 prefix=92 (IPv4 uniqueness is important in the downstream dire= ction where lookup is performed based on IPv4). [Senthil] Right. The rules must not be overlapping with one another. Each d= omain can have a single IPv6 & single IPv4 rule prefix only. The ipv6 and i= pv4 rule prefix should not overlap with other ipv6 and ipv4 rules prefixes = respectively in other domains. 2) What constitutes a MAP domain? I=92d think a unique =91Rule IPv6 Pr= efix=92 which (assuming that 1) is correct) would mean that a Domain =3D B= MR. In other words, can a MAP domain contain a collection of BMRs? The draf= ts mention virtual-links, etc=85but it would be simpler if we can say Domai= n=3DBMR (not sure if this is accurate though). Of course, nodes sharing th= e same set of those rules would be in the same MAP domain. [Senthil] Each MAP domain should have a single rule IPv6 prefix and single = IPv4 prefix. I think a single IPv4 prefix may be too restrictive in some d= eployments and people might want to use more than one prefix. But as you ha= ve shown EA length can cause ambiguity and hence makes it undeployable. 3) Is overlapping of =91Rule IPv6 Prefixes=92 supported? For example in the above case, can we have for Rule 2) the =91Rule IPv6 pre= fix=92 as 2001:0:80::/42. In this case the =91Rule IPv6 Prefix=92 from Rule 1 overlaps with =91Rule I= Pv6 Prefix=92 from Rule 2. I assume that this would not be supported for th= e same reason as in 1). I didn=92t think about the applicability of this sc= enario for now, it is more of a theoretical question. again, let's observe the consequence. again, we have the independently dele= gated prefix for the CE. if the CE has the pd like 2001:0:81:6000::/54, it = matches both rules surely. longest-match can determine which rule is in us= e (though not yet specified?). however, such a way may cause a subset of IP= v4 residual addresses never used (i.e., wasted). in this example, the longe= st match to 2001:0:80::/42 may block 192.0.2.128/26 = (192.0.2.128 - 192.0.2.191) from using. [Senthil2] That is a bad thing if you have to waste any of the addresses, a= s that is what we are trying to conserve here. And all this pain of sharing= addresses is defeated. [maoke2] agree that it is bad if we have waste. I guess the bigger question why should one have such a design and its usefu= lness. [maoke2] the bigger question is not only about the significance of allowing= it but also about the significance of forbidding it, and about what if it = happens even we have tried to forbid it. i surely don't encourage any waste= but try to understand what we might have if we don't forbid it -- in order= to make a proper statement in the specification. the really problematic stuff is both rule IPv4 prefixes and rule IPv6 prefi= xes are overlapped among two rules but not aggregated. Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/24, ea-length =3D 12 Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D 192.0.2.0= /26, ea-length =3D 12 [Senthil2] Well, I think you are trying to prove that one can have two rule= IPv6 prefixes but as long as the ipv4 addresses don=92t overlap then we wi= ll be able to unambiguosly encap/decap/translate the packets. But I wonder = what is the advantage of having two rule IPv6 prefixes. [maoke2] if all controlled by one party, it is true there is no obvious adv= antage at current understanding. however, what if two rule IPv6 prefixes ar= e the reality, out of our control? ;-) [Senthil3] Do you see a use case or a scenario that is happening, that we w= ould end up with multiple IPv6 rule prefixes and ipv4 rule prefixes? Thanks Senthil In the above case, the /26 is a subset of /24, so really there is no real a= dvantage of having a separate rule ipv4 prefix. [maoke2] rule IPv4 prefix overlapping is another question. and i tried to s= how it is really harmful. in practice, it is understood that aggregateable = IPv4 prefixes' corresponding IPv6 prefixes MUST be aggregated in the same w= ay. and one CE-a has delegated prefix 2001:0:3f:5000::/52, while another CE-b h= as 2001:0:bf:5000::/54. such a delegation seems no problem at all. CE-a mat= ches Rule 1 while CE-b matches Rule 2. then the trouble happens: CE-a will = use the IPv4 address 192.0.2.63 with PSID =3D binary_0101, obviously; while= CE-b have 40-55bits =3D 0x8fd4 =3D binary_1011 1111 0101 0000 then EA-bits =3D binary_11 1111 0101 00 then IPv4 suffix =3D binary_11 1111, PSID =3D binary_0101 00 when attached to 192.0.2.0/26, it will be 192.0.2.= 63 with PSID =3D binary_0101 00 i.e., CE-b's usable port-range is overlapped with CE-a on the same IPv4 add= ress! therefore, IMHO, the constraint of BMR-making MUST ensure the (IPv4 address= , port-range)-pair is not overlapped among different CE, therefore Rule IPv= 4 Prefixes cannot be overlapped among BMRs. this is necessary and sufficien= t. [Senthil2] I agree with your example and assertion above. But I really don= =92t see a good use case for having multiple rule IPv6 prefixes and overlap= ping rule IPv4 prefixes. [maoke2] when we deploy a MAP domain, it is definitely not necessary to mak= e complicated scenarios. however, it is possible happen in reality: as pref= ix delegation is independent of the MAP deployment, it is possible that two= MAP domains deployed so that a CE possibly joins both. i also highlight th= e use-case that MAP domain can be deployed across ASes, where the delegated= prefix is not controlled by the party deploying MAP and surely the party c= annot make sure if this pd is also used by another MAP deployment party or = not. [maoke2] i have not yet concluded that the above scenario makes sense or no= t. however, your thread raises very important questions related to such a s= cenario and therefore we need to understand/clarify what does make sense wh= at really doesn't. Maybe the use case for a overlapping rule IPv4 case is more compelling, as = you can get two blocks of public addresses that overlap on the lower n bits= , where the n bits are not unique enough in the EA bits to identify which r= ule IPv4 address to chose (mostly an issue for BR in the v4->v6 direction). thanks, maoke Thanks Senthil if i made mistakes, please point out without hesitation. thanks a lot! - maoke [Senthil] No, atleast in our implementation we have checks to make sure the= prefixes don=92t overlap. Thanks Senthil Thanks, Kris _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires --_000_CB1B483277FEC94E9B58357040EE5D02322F063Axmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1DB925B299DA9145BBC6C8A269F9035F@cisco.com> Content-Transfer-Encoding: quoted-printable

Please see [Senthil3]
From: Maoke <fibrib@gmail.com>
Date: Tuesday, December 11, 2012 8:= 24 PM
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: "Poscic, Kristian (Kristia= n)" <kristian= .poscic@alcatel-lucent.com>, "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] MAP-E/T ov= erlaping ranges and domains

hi Senthil,

inline for maoke2

2012/12/12 Senthil Sivakumar (ssenthil) <ssenthil@cisco.= com>
Hi Maoke,
Please see inline for Senthil2

From: Maoke <fibrib@gmail.com>
Date: Tuesday, December 11, 2012 5:= 21 AM
To: Senthil Sivakumar <ssenthil@cisco.com>=
Cc: "Poscic, Kristian (Kristia= n)" <kristian.poscic@alcatel-lucent.com>, "softwires@ietf.org" <softwires@ietf= .org>
Subject: Re: [Softwires] MAP-E/T ov= erlaping ranges and domains

hi Senthil,

interesting discussion. see inline.

2012/12/11 Senthil Sivakumar (ssenthil) <ssenthil@cisco.= com>


From: <Poscic>, "Kristia= n (Kristian)" <kristian.poscic@alcatel-lucent.com>
Date: Monday, December 10, 2012 3:0= 6 PM
To: "softwires@ietf.org" <softwires@ietf.org>
Subject: [Softwires] MAP-E/T overla= ping ranges and domains

Can someone clarify a few things for me:

 

1) &nb= sp;    Does MAP support this scenario (example= ):

-          (BMR) Rule 1:  

Rule IPv6 Prefix:  &= nbsp;            200= 1::/40

Rule IPv4 Prefix:  &= nbsp;            192.0.2.0/24

Rule EA-bits length: = ;       12

-          (BMR) Rule 2:

Rule IPv6 Prefix:  &= nbsp;            200= 1::/40

Rule IPv4 Prefix:  &= nbsp;            200.0.2.0/24

Rule EA-bits length: = ;       12

 

        &nbs= p;       The only difference between these tw= o rules above is the =91Rule IPv4 Prefix=92, everything else is the same. M= y obvious answer would be that this scenario is not supported but wanted to= be sure that I=92m not missing anything.

This scenario above would= result in ambiguity between CEs, i.e. a single IA-PD that is delegated to = a CE can be associated with either of the two  rules above (EA bits ca= n be the same for a CE from 192.0.2.0/24 range an= d for  a CE from 200.0.2.0/24 range.


what is the consequence if the CE has the two rules?

NOTE the delegation is independent of the IPv4 address in use. for example,= we have 2001:0:00xx:y000::/52 for the CE, where xx (8 bits) is the same as= the IPv4 suffix while y (4 bits) is applied for the PSID. if the source ad= dress has been selected from either rule ipv4 prefix, then the encapsulation or translation is determined and = the BR can de-capsulate or de-translate that without any difficulty because= the full IPv4 address is embedded in the IID part. when the response comes= , the destination address of the IPv4 packet is also determined though they would be encapsulated with the = same IPv6 prefix (not the same IPv6 CE address!).

[Senthil2] I don=92t see any issues with correctly decapsulating/trans= lating the packet on the BR for v6->v4. The issue is with the v4->v6.= You cannot correctly know which of the two IP addresses to embed. With tra= nslation, the communication will definitely fail if you embed the wrong IP address. 

[maoke2] i cannot catch your point. you mean v4->v6 at BR, right? which = IPv4 address to embed is determined by the session initiator. for example, = if a host behind CE makes a connection to 8.8.8.8, and if the CE happens to= have picking up 192.0.2.191 as the src IPv4 address, then the 8.8.8.8 will response 192.0.2.191 definitely. i= don't see that BR needs to choose an IPv4 address to embed: the destinatio= n address in the packet replying to the session initiator is determined.



the only concern is: if such a configuration can make different source IPv4= address for the packets of the same session. if so, the session might be t= roubled especially it is connection-oriented.

[Senthil2] It will. There is a 50% chance that you don=92t use the sam= e address as the one the that the client used. Because there is no state.

however, we may notice that NAT44 in the CE is not stateless. what is = selected for the session initialization would be continuously used for the = subsequent process of the same session. if the address is not shared so tha= t there is no NAT44, the native IPv4 source address selection logic will decide the selection and makes it= unique for a specific destination.

[Senthil2] With NAT44, it is even more stricter, if the BR didn=92t pi= ck the right IPv4 address the NAT44 state table wont match the incoming pac= ket. 

[maoke2] misunderstanding. BR don't have the chance to *pick up* IPv4 addre= ss.

[Senthil3] You are right, I missed that. But lets take your example:
Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/24, ea-length = =3D 12
Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D 192.0.2.0/26, ea-length = =3D 12

CE1 sends the packet with its prefix and using the global address 192.= 0.2.20 sends a packet to the BR. The BR matches rule 1 (assuming that the l= ongest matching prefix was that), and the resulting packet is a ipv4 packet= with a destination of 192.0.2.20 and the return packet comes back with the destination of 192.0.2.20. That = will match the rule2 because the longest prefix match for the v4 address is= 192.0.2.0/26. So we use rule2 to construct the v6 packet. The destination = v6 address is different now, even though you embedded the right v4 address in IID. How does that reach the C= E-1? 

 


therefore personally i doubt the above multi-rule case doesn't work. if i a= m right, it is not needed to make 'Rule IPv4 Prefix' unique per 'Rule IPv6 = Prefix'.
 

In this example above, it= is assumed that the delegated prefix (IA-PD) that DHCPv6 Server is handing= out to CEs is 2001::/40 with delegated prefix length /56.


why /56 instead of /52? :P
 

 

        &nbs= p;       This makes me believe that each rule= must not only be unique (because the above two rules are unique) but inste= ad each rule must have a unique  =91Rule IPv6 prefix=92 and a unique = =91Rule IPv4 Prefix=92 per =91Rule IPv6 prefix=92 (IPv4 uniqueness is important in the downstream direction where lookup is perfor= med based on IPv4).

[Senthil] Right. The rules must not be overlapping with one another. E= ach domain can have a single IPv6 & single IPv4 rule prefix only. The i= pv6 and ipv4 rule prefix should not overlap with other ipv6 and ipv4 rules = prefixes respectively in other domains.

 

2) &nb= sp;    What constitutes a MAP domain? I=92d th= ink a unique =91Rule IPv6 Prefix=92 which  (assuming that 1) is correc= t) would mean that a Domain =3D BMR. In other words, can a MAP domain conta= in a collection of BMRs? The drafts mention virtual-links, etc=85but it would be simpler i= f we can say Domain=3DBMR (not sure if this is accurate though).  Of c= ourse, nodes sharing the same set of those rules would be in the same MAP d= omain.

[Senthil] Each MAP domain should have a single rule IPv6 prefix and si= ngle IPv4 prefix.  I think a single IPv4 prefix may be too restrictive= in some deployments and people might want to use more than one prefix. But= as you have shown EA length can cause ambiguity and hence makes it undeployable.

 

3) &nb= sp;    Is overlapping of =91Rule IPv6 Prefixes= =92 supported?

For example in the above case, can we have for Rule 2) the =91Rule IPv6 = prefix=92 as 2001:0:80::/42.

In this case the =91Rule IPv6 Prefix=92 from Rule 1 overlaps with =91Rul= e IPv6 Prefix=92 from Rule 2. I assume that this would not be supported for= the same reason as in 1). I didn=92t think about the applicability of this= scenario for now, it is more of a theoretical question.


again, let's observe the consequence. again, we have the independently dele= gated prefix for the CE. if the CE has the pd like 2001:0:81:6000::/54, it = matches both rules surely.  longest-match can determine which rule is = in use (though not yet specified?). however, such a way may cause a subset of IPv4 residual addresses never used (i.e.,= wasted). in this example, the longest match to 2001:0:80::/42 may block 192.0.2.128/26 (192= .0.2.128 - 192.0.2.191) from using.

[Senthil2] That is a bad thing if you have to waste any of the address= es, as that is what we are trying to conserve here. And all this pain of sh= aring addresses is defeated.

[maoke2] agree that it is bad if we have waste.
 
I guess the bigger question why should one have such a design and its = usefulness. 

[maoke2] the bigger question is not only about the significance of allowing= it but also about the significance of forbidding it, and about what if it = happens even we have tried to forbid it. i surely don't encourage any waste= but try to understand what we might have if we don't forbid it -- in order to make a proper statement in the s= pecification.


the really problematic stuff is both rule IPv4 prefixes and rule IPv6 prefi= xes are overlapped among two rules but not aggregated.

Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/24, ea-length =3D 12
Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D 192.0.2.0/26, ea-length =3D 12

[Senthil2] Well, I think you are trying to prove that one can have two= rule IPv6 prefixes but as long as the ipv4 addresses don=92t overlap then = we will be able to unambiguosly encap/decap/translate the packets. But I wo= nder what is the advantage of having two rule IPv6 prefixes.

[maoke2] if all controlled by one party, it is true there is no obvious adv= antage at current understanding. however, what if two rule IPv6 prefixes ar= e the reality, out of our control? ;-)

[Senthil3] Do you see a use case or a scenario that is happening, that= we would end up with multiple IPv6 rule prefixes and ipv4 rule prefixes?

Thanks
Senthil

 
In the above case, the /26 is a subset of /24, so really there is no r= eal advantage of having a separate rule ipv4 prefix.

[maoke2] rule IPv4 prefix overlapping is another question. and i tried to s= how it is really harmful. in practice, it is understood that aggregateable = IPv4 prefixes' corresponding IPv6 prefixes MUST be aggregated in the same w= ay.
 

and one CE-a has delegated prefix 2001:0:3f:5000::/52, while another CE-b h= as 2001:0:bf:5000::/54. such a delegation seems no problem at all. CE-a mat= ches Rule 1 while CE-b matches Rule 2. then the trouble happens: CE-a will = use the IPv4 address 192.0.2.63 with PSID =3D binary_0101, obviously; while CE-b have

    40-55bits =3D 0x8fd4 =3D binary_1011 1111 0101 0000
    then EA-bits =3D binary_11 1111 0101 00
    then IPv4 suffix =3D binary_11 1111, PSID =3D binary_010= 1 00
    when attached to 192.0.2.0/26, it will be 192.0.2.63 with PSID =3D binary_01= 01 00

i.e., CE-b's usable port-range is overlapped with CE-a on the same IPv4 add= ress!

therefore, IMHO, the constraint of BMR-making MUST ensure the (IPv4 address= , port-range)-pair is not overlapped among different CE, therefore Rule IPv= 4 Prefixes cannot be overlapped among BMRs. this is necessary and sufficien= t.

[Senthil2] I agree with your example and assertion above. But I really= don=92t see a good use case for having multiple rule IPv6 prefixes and ove= rlapping rule IPv4 prefixes.

[maoke2] when we deploy a MAP domain, it is definitely not necessary to mak= e complicated scenarios. however, it is possible happen in reality: as pref= ix delegation is independent of the MAP deployment, it is possible that two= MAP domains deployed so that a CE possibly joins both. i also highlight the use-case that MAP domain can = be deployed across ASes, where the delegated prefix is not controlled by th= e party deploying MAP and surely the party cannot make sure if this pd is a= lso used by another MAP deployment party or not.

[maoke2] i have not yet concluded that the above scenario makes sense or no= t. however, your thread raises very important questions related to such a s= cenario and therefore we need to understand/clarify what does make sense wh= at really doesn't.
 
Maybe the use case for a overlapping rule IPv4 case is more compelling= , as you can get two blocks of public addresses that overlap on the lower n= bits, where the n bits are not unique enough in the EA bits to identify wh= ich rule IPv4 address to chose (mostly an issue for BR in the v4->v6 direction).

thanks,
maoke
 

Thanks
Senthil




if i made mistakes, please point out without hesitation. thanks a lot!

- maoke

[Senthil] No, atleast in our implementation we have checks to make sur= e the prefixes don=92t overlap.

Thanks
Senthil

 

Thanks,

Kris

 


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



 --_000_CB1B483277FEC94E9B58357040EE5D02322F063Axmbrcdx15ciscoc_-- From kristian.poscic@alcatel-lucent.com Wed Dec 12 15:03:01 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 C48A921F86BA for ; Wed, 12 Dec 2012 15:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.419 X-Spam-Level: X-Spam-Status: No, score=-9.419 tagged_above=-999 required=5 tests=[AWL=0.829, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRpynISbu6mk for ; Wed, 12 Dec 2012 15:03:00 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 638E821F86B7 for ; Wed, 12 Dec 2012 15:02:59 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBCN2ZOR031259 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 13 Dec 2012 00:02:58 +0100 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 00:02:50 +0100 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.227]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Wed, 12 Dec 2012 18:02:43 -0500 From: "Poscic, Kristian (Kristian)" To: "softwires@ietf.org" Thread-Topic: dhcp/radius in MAT-E/T Thread-Index: Ac3YvCkKqx0/6H1lRXCrBD33fX32UA== Date: Wed, 12 Dec 2012 23:02:42 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AA2A3B9@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AA2A3B9US70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [Softwires] dhcp/radius in MAT-E/T 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, 12 Dec 2012 23:03:01 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02AA2A3B9US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Has any further work been done on: draft-mdt-softwire-map-dhcp-option-03 draft-jiang-softwire-map-radius-02 There are many codes still missing in those two drafts. Last I remember was some discussion via emails where it was debated with DH= C folks whether those options should be passed via DHCPv6 or not...I was wo= ndering if those discussions have progressed in Atlanta. Thanks, Kris --_000_7921F977B17D5B49B8DCC955A339D2F02AA2A3B9US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Has any further work been done on:

 

draft-mdt-softwir= e-map-dhcp-option-03

draft-jiang-softwire-m= ap-radius-02

 

There are many codes still missing in those two draf= ts.

 

Last I remember was some discussion via emails where= it was debated with DHC folks whether those options should be passed via D= HCPv6 or not…I was wondering if those discussions have progressed in = Atlanta.

 

Thanks,

Kris

--_000_7921F977B17D5B49B8DCC955A339D2F02AA2A3B9US70UWXCHMBA05z_-- From Ted.Lemon@nominum.com Wed Dec 12 16:28: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 94C4A21E8092 for ; Wed, 12 Dec 2012 16:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.054 X-Spam-Level: X-Spam-Status: No, score=-106.054 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_TOWRITE=1.05, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huI9YAsLdVg1 for ; Wed, 12 Dec 2012 16:28:23 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 67CD41F0CB4 for ; Wed, 12 Dec 2012 16:28:10 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUMkhFOxpJhXF84V1nUrD9BxdNj/W91A9@postini.com; Wed, 12 Dec 2012 16:28:10 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 428C4F800A for ; Wed, 12 Dec 2012 16:28:04 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 38742190052; Wed, 12 Dec 2012 16:28:04 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 12 Dec 2012 16:28:04 -0800 From: Ted Lemon To: "Poscic, Kristian (Kristian)" Thread-Topic: [Softwires] dhcp/radius in MAT-E/T Thread-Index: Ac3YvCkKqx0/6H1lRXCrBD33fX32UAAT5r4A Date: Thu, 13 Dec 2012 00:28:02 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474382AF@mbx-01.win.nominum.com> References: <7921F977B17D5B49B8DCC955A339D2F02AA2A3B9@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AA2A3B9@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <725CA22E867E4947945455641E9FC7F7@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] dhcp/radius in MAT-E/T 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, 13 Dec 2012 00:28:23 -0000 On Dec 12, 2012, at 6:02 PM, "Poscic, Kristian (Kristian)" wrote: > Last I remember was some discussion via emails where it was debated with = DHC folks whether those options should be passed via DHCPv6 or not=85I was = wondering if those discussions have progressed in Atlanta. We decided to write a document summarizing the issues. You can get a sens= e of the discussion by reading the DHC meeting minutes for the Atlanta meet= ing=97it's the last set of issues before the "raw transcript" section. From leaf.y.yeh@huawei.com Wed Dec 12 17:16:42 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 2568C21F8578 for ; Wed, 12 Dec 2012 17:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.936 X-Spam-Level: X-Spam-Status: No, score=-5.936 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_TOWRITE=1.05] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grYfWCfPR90b for ; Wed, 12 Dec 2012 17:16:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2F82221F8233 for ; Wed, 12 Dec 2012 17:16:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANU06039; Thu, 13 Dec 2012 01:16:38 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Dec 2012 01:15:45 +0000 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Dec 2012 01:16:37 +0000 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.9]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Thu, 13 Dec 2012 09:16:29 +0800 From: Leaf yeh To: Ted Lemon , "Poscic, Kristian (Kristian)" Thread-Topic: [Softwires] dhcp/radius in MAT-E/T Thread-Index: Ac3YvCkKqx0/6H1lRXCrBD33fX32UAAT5r4AAA8tsKA= Date: Thu, 13 Dec 2012 01:16:28 +0000 Message-ID: References: <7921F977B17D5B49B8DCC955A339D2F02AA2A3B9@US70UWXCHMBA05.zam.alcatel-lucent.com> <8D23D4052ABE7A4490E77B1A012B6307474382AF@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474382AF@mbx-01.win.nominum.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "softwires@ietf.org" Subject: Re: [Softwires] dhcp/radius in MAT-E/T 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, 13 Dec 2012 01:16:42 -0000 What does 'MAT-E/T' mean? Sounds 'MAP-E/T' in Softwire-WG? Best Regards, Leaf -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Ted Lemon Sent: Thursday, December 13, 2012 8:28 AM To: Poscic, Kristian (Kristian) Cc: softwires@ietf.org Subject: Re: [Softwires] dhcp/radius in MAT-E/T On Dec 12, 2012, at 6:02 PM, "Poscic, Kristian (Kristian)" wrote: > Last I remember was some discussion via emails where it was debated with = DHC folks whether those options should be passed via DHCPv6 or not...I was = wondering if those discussions have progressed in Atlanta. We decided to write a document summarizing the issues. You can get a sens= e of the discussion by reading the DHC meeting minutes for the Atlanta meet= ing-it's the last set of issues before the "raw transcript" section. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From jiangsheng@huawei.com Wed Dec 12 17:19: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 CD17F21F89AE for ; Wed, 12 Dec 2012 17:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiXmDK+++Z1Q for ; Wed, 12 Dec 2012 17:19:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF7121F88CC for ; Wed, 12 Dec 2012 17:19:33 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMK99975; Thu, 13 Dec 2012 01:19:33 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Dec 2012 01:18:40 +0000 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Dec 2012 09:19:31 +0800 Received: from SZXEML545-MBS.china.huawei.com ([169.254.2.174]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 13 Dec 2012 09:19:27 +0800 From: Sheng Jiang To: "Poscic, Kristian (Kristian)" , "softwires@ietf.org" Thread-Topic: dhcp/radius in MAT-E/T Thread-Index: Ac3YvCkKqx0/6H1lRXCrBD33fX32UAAE0dfw Date: Thu, 13 Dec 2012 01:19:25 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239FD45D5@szxeml545-mbs.china.huawei.com> References: <7921F977B17D5B49B8DCC955A339D2F02AA2A3B9@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AA2A3B9@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.140] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9239FD45D5szxeml545mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-jiang-softwire-map-radius@ietf.org" Subject: Re: [Softwires] dhcp/radius in MAT-E/T 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, 13 Dec 2012 01:19:35 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9239FD45D5szxeml545mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgZGlkIHByZXNlbnQgZHJhZnQtamlhbmctc29mdHdpcmUtbWFwLXJhZGl1cy0wMiBpbiBBdGxh bnRhIGFuZCBjb250aW51ZSB3b3JraW5nIG9uIGl0Lg0KDQpTaW5jZSB5b3Ugc3RhdGUg4oCcdGhl cmUgYXJlIG1hbnkgY29kZXMgc3RpbGwgbWlzc2luZ+KAnSwgaWYgeW91IGNhbiBnaXZlIG1lIGEg ZGV0YWlsZWQgbWFpbCB0byBleHBsYWluIHdoYXQgaXMgbWlzc2luZywgaXQgbWlnaHQgYmUgdmVy eSBnb29kIGNvbnRyaWJ1dGlvbnMuDQoNCk1hbnkgdGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMsDQoN ClNoZW5nDQoNCkZyb206IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c29mdHdp cmVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQb3NjaWMsIEtyaXN0aWFuIChLcmlz dGlhbikNClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxMywgMjAxMiA3OjAzIEFNDQpUbzogc29m dHdpcmVzQGlldGYub3JnDQpTdWJqZWN0OiBbU29mdHdpcmVzXSBkaGNwL3JhZGl1cyBpbiBNQVQt RS9UDQoNCkhhcyBhbnkgZnVydGhlciB3b3JrIGJlZW4gZG9uZSBvbjoNCg0KZHJhZnQtbWR0LXNv ZnR3aXJlLW1hcC1kaGNwLW9wdGlvbi0wMzxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LW1kdC1zb2Z0d2lyZS1tYXAtZGhjcC1vcHRpb24vPg0KZHJhZnQtamlhbmctc29mdHdp cmUtbWFwLXJhZGl1cy0wMjxodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpp YW5nLXNvZnR3aXJlLW1hcC1yYWRpdXMvPg0KDQpUaGVyZSBhcmUgbWFueSBjb2RlcyBzdGlsbCBt aXNzaW5nIGluIHRob3NlIHR3byBkcmFmdHMuDQoNCkxhc3QgSSByZW1lbWJlciB3YXMgc29tZSBk aXNjdXNzaW9uIHZpYSBlbWFpbHMgd2hlcmUgaXQgd2FzIGRlYmF0ZWQgd2l0aCBESEMgZm9sa3Mg d2hldGhlciB0aG9zZSBvcHRpb25zIHNob3VsZCBiZSBwYXNzZWQgdmlhIERIQ1B2NiBvciBub3Ti gKZJIHdhcyB3b25kZXJpbmcgaWYgdGhvc2UgZGlzY3Vzc2lvbnMgaGF2ZSBwcm9ncmVzc2VkIGlu IEF0bGFudGEuDQoNClRoYW5rcywNCktyaXMNCg== --_000_5D36713D8A4E7348A7E10DF7437A4B9239FD45D5szxeml545mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglw YW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OiMxRjQ5N0QiPldlIGRpZCBwcmVzZW50IGRyYWZ0LWppYW5nLXNvZnR3aXJlLW1hcC1yYWRpdXMt MDIgaW4gQXRsYW50YSBhbmQgY29udGludWUgd29ya2luZyBvbiBpdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPlNpbmNlIHlvdSBzdGF0ZSDigJx0aGVyZSBhcmUgbWFu eSBjb2RlcyBzdGlsbCBtaXNzaW5n4oCdLCBpZiB5b3UgY2FuIGdpdmUgbWUgYSBkZXRhaWxlZCBt YWlsIHRvIGV4cGxhaW4gd2hhdCBpcyBtaXNzaW5nLCBpdCBtaWdodCBiZSB2ZXJ5IGdvb2QgY29u dHJpYnV0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPk1hbnkg dGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjoj MUY0OTdEIj5TaGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNvZnR3aXJlcy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlBvc2NpYywgS3Jpc3RpYW4gKEtyaXN0aWFuKTxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgRGVjZW1iZXIgMTMsIDIwMTIgNzowMyBBTTxicj4NCjxiPlRvOjwvYj4gc29m dHdpcmVzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtTb2Z0d2lyZXNdIGRoY3AvcmFk aXVzIGluIE1BVC1FL1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IYXMgYW55 IGZ1cnRoZXIgd29yayBiZWVuIGRvbmUgb246PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1kdC1zb2Z0d2lyZS1tYXAtZGhj cC1vcHRpb24vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2JhY2tncm91bmQ6I0VERjVGRiI+ ZHJhZnQtbWR0LXNvZnR3aXJlLW1hcC1kaGNwLW9wdGlvbi0wMzwvc3Bhbj48L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxh IGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamlhbmctc29mdHdp cmUtbWFwLXJhZGl1cy8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDp3aGl0 ZSI+ZHJhZnQtamlhbmctc29mdHdpcmUtbWFwLXJhZGl1cy0wMjwvc3Bhbj48L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGVyZSBhcmUgbWFueSBjb2RlcyBzdGlsbCBtaXNzaW5nIGluIHRob3NlIHR3 byBkcmFmdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5MYXN0IEkgcmVtZW1iZXIgd2FzIHNvbWUgZGlz Y3Vzc2lvbiB2aWEgZW1haWxzIHdoZXJlIGl0IHdhcyBkZWJhdGVkIHdpdGggREhDIGZvbGtzIHdo ZXRoZXIgdGhvc2Ugb3B0aW9ucyBzaG91bGQgYmUgcGFzc2VkIHZpYSBESENQdjYgb3Igbm904oCm SSB3YXMgd29uZGVyaW5nIGlmIHRob3NlIGRpc2N1c3Npb25zIGhhdmUgcHJvZ3Jlc3NlZCBpbiBB dGxhbnRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5LcmlzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B9239FD45D5szxeml545mbschi_-- From leaf.y.yeh@huawei.com Wed Dec 12 17:28:09 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 1712D21F8473 for ; Wed, 12 Dec 2012 17:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy8UyYdZMp2L for ; Wed, 12 Dec 2012 17:28:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C83121F8467 for ; Wed, 12 Dec 2012 17:28:08 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANU06569; Thu, 13 Dec 2012 01:28:07 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Dec 2012 01:27:14 +0000 Received: from SZXEML441-HUB.china.huawei.com (10.82.67.179) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 13 Dec 2012 01:28:06 +0000 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.9]) by szxeml441-hub.china.huawei.com ([10.82.67.179]) with mapi id 14.01.0323.003; Thu, 13 Dec 2012 09:27:57 +0800 From: Leaf yeh To: "Poscic, Kristian (Kristian)" , "softwires@ietf.org" Thread-Topic: dhcp/radius in MAT-E/T Thread-Index: Ac3YvCkKqx0/6H1lRXCrBD33fX32UAAFDkQg Date: Thu, 13 Dec 2012 01:27:56 +0000 Message-ID: References: <7921F977B17D5B49B8DCC955A339D2F02AA2A3B9@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AA2A3B9@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Softwires] dhcp/radius in MAT-E/T 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, 13 Dec 2012 01:28:09 -0000 FYI, draft-mdt-softwire-map-dhcp-option-03 has been adopted by the Softwir= e-WG as draft-ietf-softwire-map-dhcp-01. Best Regards, Leaf From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Poscic, Kristian (Kristian) Sent: Thursday, December 13, 2012 7:03 AM To: softwires@ietf.org Subject: [Softwires] dhcp/radius in MAT-E/T Has any further work been done on: draft-mdt-softwire-map-dhcp-option-03 draft-jiang-softwire-map-radius-02 There are many codes still missing in those two drafts. Last I remember was some discussion via emails where it was debated with DH= C folks whether those options should be passed via DHCPv6 or not...I was wo= ndering if those discussions have progressed in Atlanta. Thanks, Kris From fibrib@gmail.com Wed Dec 12 17:49: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 800F821E8039 for ; Wed, 12 Dec 2012 17:49:12 -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=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVnKIi3J1BpS for ; Wed, 12 Dec 2012 17:49:10 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E411C21F88DC for ; Wed, 12 Dec 2012 17:49:09 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so947418eek.31 for ; Wed, 12 Dec 2012 17:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=icxo5EEjJe1x7h3hGR7RvX4hiZdgJ6YbV9NYxvlPERs=; b=IjWxk40HRkjTrepMIwoxzUBbT+oQNoKFzT0dcDQLUo6i1MP+jtXT4s78zBKjPuBM5V fF1iOmdG66AxB6csYGFV3oZdp9NqDUhMsFMarnkoiIv71BFvNguow3SPCpsjgwC++82R gO9r/QKndoQIUEB36nxM6AFfKZMO2OnXrj2LK186sz0o3C53ymET1GTHmnXTpjdyCvMY Vk3WVr3XACEWm9L2sSkPkXJvhAEXIi8WX8PyWAb9athX8UP2a8NAB43olWjcxsHIYmv5 OSGmKlINTRCgnigftBNpATbDqBODa0g6UygRdxGsColqxopATpmrJZYqy1NCUHivlmwO ejlQ== MIME-Version: 1.0 Received: by 10.14.0.133 with SMTP id 5mr420091eeb.29.1355363349074; Wed, 12 Dec 2012 17:49:09 -0800 (PST) Received: by 10.14.127.1 with HTTP; Wed, 12 Dec 2012 17:49:08 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Dec 2012 10:49:08 +0900 Message-ID: From: Maoke To: "Senthil Sivakumar (ssenthil)" Content-Type: multipart/alternative; boundary=047d7b66fef3f6919404d0b21ef0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains 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, 13 Dec 2012 01:49:12 -0000 --047d7b66fef3f6919404d0b21ef0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2012/12/13 Senthil Sivakumar (ssenthil) > > Please see [Senthil3] > From: Maoke > Date: Tuesday, December 11, 2012 8:24 PM > > To: Senthil Sivakumar > Cc: "Poscic, Kristian (Kristian)" , " > softwires@ietf.org" > Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains > > hi Senthil, > > inline for maoke2 > > 2012/12/12 Senthil Sivakumar (ssenthil) > >> Hi Maoke, >> Please see inline for Senthil2 >> >> From: Maoke >> Date: Tuesday, December 11, 2012 5:21 AM >> To: Senthil Sivakumar >> Cc: "Poscic, Kristian (Kristian)" , = " >> softwires@ietf.org" >> Subject: Re: [Softwires] MAP-E/T overlaping ranges and domains >> >> hi Senthil, >> >> interesting discussion. see inline. >> >> 2012/12/11 Senthil Sivakumar (ssenthil) >> >>> >>> >>> From: , "Kristian (Kristian)" < >>> kristian.poscic@alcatel-lucent.com> >>> Date: Monday, December 10, 2012 3:06 PM >>> To: "softwires@ietf.org" >>> Subject: [Softwires] MAP-E/T overlaping ranges and domains >>> >>> Can someone clarify a few things for me:**** >>> >>> ** ** >>> >>> 1) Does MAP support this scenario (example):**** >>> >>> - (BMR) Rule 1: **** >>> >>> Rule IPv6 Prefix: 2001::/40**** >>> >>> Rule IPv4 Prefix: 192.0.2.0/24**** >>> >>> Rule EA-bits length: 12**** >>> >>> - (BMR) Rule 2:**** >>> >>> Rule IPv6 Prefix: 2001::/40**** >>> >>> Rule IPv4 Prefix: 200.0.2.0/24**** >>> >>> Rule EA-bits length: 12**** >>> >>> ** ** >>> >>> The only difference between these two rules above is th= e >>> =91Rule IPv4 Prefix=92, everything else is the same. My obvious answer = would be >>> that this scenario is not supported but wanted to be sure that I=92m no= t >>> missing anything.**** >>> >>> This scenario above would result in ambiguity between CEs, i.e. a singl= e >>> IA-PD that is delegated to a CE can be associated with either of the tw= o >>> rules above (EA bits can be the same for a CE from 192.0.2.0/24 range >>> and for a CE from 200.0.2.0/24 range. >>> >> >> what is the consequence if the CE has the two rules? >> >> NOTE the delegation is independent of the IPv4 address in use. for >> example, we have 2001:0:00xx:y000::/52 for the CE, where xx (8 bits) is = the >> same as the IPv4 suffix while y (4 bits) is applied for the PSID. if the >> source address has been selected from either rule ipv4 prefix, then the >> encapsulation or translation is determined and the BR can de-capsulate o= r >> de-translate that without any difficulty because the full IPv4 address i= s >> embedded in the IID part. when the response comes, the destination addre= ss >> of the IPv4 packet is also determined though they would be encapsulated >> with the same IPv6 prefix (not the same IPv6 CE address!). >> >> [Senthil2] I don=92t see any issues with correctly >> decapsulating/translating the packet on the BR for v6->v4. The issue is >> with the v4->v6. You cannot correctly know which of the two IP addresses= to >> embed. With translation, the communication will definitely fail if you >> embed the wrong IP address. >> > > [maoke2] i cannot catch your point. you mean v4->v6 at BR, right? which > IPv4 address to embed is determined by the session initiator. for example= , > if a host behind CE makes a connection to 8.8.8.8, and if the CE happens = to > have picking up 192.0.2.191 as the src IPv4 address, then the 8.8.8.8 wil= l > response 192.0.2.191 definitely. i don't see that BR needs to choose an > IPv4 address to embed: the destination address in the packet replying to > the session initiator is determined. > > >> >> the only concern is: if such a configuration can make different source >> IPv4 address for the packets of the same session. if so, the session mig= ht >> be troubled especially it is connection-oriented. >> >> [Senthil2] It will. There is a 50% chance that you don=92t use the same >> address as the one the that the client used. Because there is no state. >> >> however, we may notice that NAT44 in the CE is not stateless. what is >> selected for the session initialization would be continuously used for t= he >> subsequent process of the same session. if the address is not shared so >> that there is no NAT44, the native IPv4 source address selection logic w= ill >> decide the selection and makes it unique for a specific destination. >> >> [Senthil2] With NAT44, it is even more stricter, if the BR didn=92t pic= k >> the right IPv4 address the NAT44 state table wont match the incoming >> packet. >> > > [maoke2] misunderstanding. BR don't have the chance to *pick up* IPv4 > address. > > [Senthil3] You are right, I missed that. But lets take your example: > Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/24= , > ea-length =3D 12 > Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D 192.0.2= .0/26, > ea-length =3D 12 > > CE1 sends the packet with its prefix and using the global address > 192.0.2.20 sends a packet to the BR. The BR matches rule 1 (assuming that > the longest matching prefix was that), and the resulting packet is a ipv4 > packet with a destination of 192.0.2.20 and the return packet comes back > with the destination of 192.0.2.20. That will match the rule2 because the > longest prefix match for the v4 address is 192.0.2.0/26. So we use rule2 > to construct the v6 packet. The destination v6 address is different now, > even though you embedded the right v4 address in IID. How does that reach > the CE-1? > [maoke3] we are on the same floor that rule IPv4 prefix MUST NOT overlap among different CEs. but multiple rules can share the same rule IPv6 prefix (as long as the rule IPv4 prefixes are not overlapped). > > > >> >> >> therefore personally i doubt the above multi-rule case doesn't work. if = i >> am right, it is not needed to make 'Rule IPv4 Prefix' unique per 'Rule I= Pv6 >> Prefix'. >> >> >>> **** >>> >>> In this example above, it is assumed that the delegated prefix (IA-PD) >>> that DHCPv6 Server is handing out to CEs is 2001::/40 with delegated pr= efix >>> length /56. >>> >> >> why /56 instead of /52? :P >> >> >>> **** >>> >>> ** ** >>> >>> This makes me believe that each rule must not only be >>> unique (because the above two rules are unique) but instead each rule m= ust >>> have a unique =91Rule IPv6 prefix=92 and a unique =91Rule IPv4 Prefix= =92 per =91Rule >>> IPv6 prefix=92 (IPv4 uniqueness is important in the downstream directio= n >>> where lookup is performed based on IPv4). >>> >>> [Senthil] Right. The rules must not be overlapping with one another. >>> Each domain can have a single IPv6 & single IPv4 rule prefix only. The = ipv6 >>> and ipv4 rule prefix should not overlap with other ipv6 and ipv4 rules >>> prefixes respectively in other domains. >>> >>> **** >>> >>> ** ** >>> >>> 2) What constitutes a MAP domain? I=92d think a unique =91Rule IPv= 6 >>> Prefix=92 which (assuming that 1) is correct) would mean that a Domain= =3D >>> BMR. In other words, can a MAP domain contain a collection of BMRs? The >>> drafts mention virtual-links, etc=85but it would be simpler if we can s= ay >>> Domain=3DBMR (not sure if this is accurate though). Of course, nodes s= haring >>> the same set of those rules would be in the same MAP domain. >>> >>> [Senthil] Each MAP domain should have a single rule IPv6 prefix and >>> single IPv4 prefix. I think a single IPv4 prefix may be too restrictiv= e in >>> some deployments and people might want to use more than one prefix. But= as >>> you have shown EA length can cause ambiguity and hence makes it >>> undeployable. >>> >>> **** >>> >>> ** ** >>> >>> 3) Is overlapping of =91Rule IPv6 Prefixes=92 supported?**** >>> >>> For example in the above case, can we have for Rule 2) the =91Rule IPv6 >>> prefix=92 as 2001:0:80::/42.**** >>> >>> In this case the =91Rule IPv6 Prefix=92 from Rule 1 overlaps with =91Ru= le IPv6 >>> Prefix=92 from Rule 2. I assume that this would not be supported for th= e same >>> reason as in 1). I didn=92t think about the applicability of this scena= rio >>> for now, it is more of a theoretical question. >>> >> >> again, let's observe the consequence. again, we have the independently >> delegated prefix for the CE. if the CE has the pd like 2001:0:81:6000::/= 54, >> it matches both rules surely. longest-match can determine which rule is= in >> use (though not yet specified?). however, such a way may cause a subset = of >> IPv4 residual addresses never used (i.e., wasted). in this example, the >> longest match to 2001:0:80::/42 may block 192.0.2.128/26 (192.0.2.128 - >> 192.0.2.191) from using. >> >> [Senthil2] That is a bad thing if you have to waste any of the >> addresses, as that is what we are trying to conserve here. And all this >> pain of sharing addresses is defeated. >> > > [maoke2] agree that it is bad if we have waste. > > >> I guess the bigger question why should one have such a design and its >> usefulness. >> > > [maoke2] the bigger question is not only about the significance of > allowing it but also about the significance of forbidding it, and about > what if it happens even we have tried to forbid it. i surely don't > encourage any waste but try to understand what we might have if we don't > forbid it -- in order to make a proper statement in the specification. > > >> the really problematic stuff is both rule IPv4 prefixes and rule IPv6 >> prefixes are overlapped among two rules but not aggregated. >> >> Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/2= 4, >> ea-length =3D 12 >> Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D >> 192.0.2.0/26, ea-length =3D 12 >> >> [Senthil2] Well, I think you are trying to prove that one can have two >> rule IPv6 prefixes but as long as the ipv4 addresses don=92t overlap the= n we >> will be able to unambiguosly encap/decap/translate the packets. But I >> wonder what is the advantage of having two rule IPv6 prefixes. >> > > [maoke2] if all controlled by one party, it is true there is no obvious > advantage at current understanding. however, what if two rule IPv6 prefix= es > are the reality, out of our control? ;-) > > [Senthil3] Do you see a use case or a scenario that is happening, that > we would end up with multiple IPv6 rule prefixes and ipv4 rule prefixes? > [maoke3] as the above, it is possible that two or more parties are deploying MAP domains on some common CEs, if the MAP domain !=3D AS is allowed. to clarify: with multiple rules where rule IPv6 prefixes can be shared / overlapped but rule IPv4 prefixes must not. thanks, - maoke > > Thanks > Senthil > > > >> In the above case, the /26 is a subset of /24, so really there is no >> real advantage of having a separate rule ipv4 prefix. >> > > [maoke2] rule IPv4 prefix overlapping is another question. and i tried to > show it is really harmful. in practice, it is understood that aggregateab= le > IPv4 prefixes' corresponding IPv6 prefixes MUST be aggregated in the same > way. > > >> >> and one CE-a has delegated prefix 2001:0:3f:5000::/52, while another CE-= b >> has 2001:0:bf:5000::/54. such a delegation seems no problem at all. CE-a >> matches Rule 1 while CE-b matches Rule 2. then the trouble happens: CE-a >> will use the IPv4 address 192.0.2.63 with PSID =3D binary_0101, obviousl= y; >> while CE-b have >> >> 40-55bits =3D 0x8fd4 =3D binary_1011 1111 0101 0000 >> then EA-bits =3D binary_11 1111 0101 00 >> then IPv4 suffix =3D binary_11 1111, PSID =3D binary_0101 00 >> when attached to 192.0.2.0/26, it will be 192.0.2.63 with PSID =3D >> binary_0101 00 >> >> i.e., CE-b's usable port-range is overlapped with CE-a on the same IPv4 >> address! >> >> therefore, IMHO, the constraint of BMR-making MUST ensure the (IPv4 >> address, port-range)-pair is not overlapped among different CE, therefor= e >> Rule IPv4 Prefixes cannot be overlapped among BMRs. this is necessary an= d >> sufficient. >> >> [Senthil2] I agree with your example and assertion above. But I really >> don=92t see a good use case for having multiple rule IPv6 prefixes and >> overlapping rule IPv4 prefixes. >> > > [maoke2] when we deploy a MAP domain, it is definitely not necessary to > make complicated scenarios. however, it is possible happen in reality: as > prefix delegation is independent of the MAP deployment, it is possible th= at > two MAP domains deployed so that a CE possibly joins both. i also highlig= ht > the use-case that MAP domain can be deployed across ASes, where the > delegated prefix is not controlled by the party deploying MAP and surely > the party cannot make sure if this pd is also used by another MAP > deployment party or not. > > [maoke2] i have not yet concluded that the above scenario makes sense or > not. however, your thread raises very important questions related to such= a > scenario and therefore we need to understand/clarify what does make sense > what really doesn't. > > >> Maybe the use case for a overlapping rule IPv4 case is more compelling, >> as you can get two blocks of public addresses that overlap on the lower = n >> bits, where the n bits are not unique enough in the EA bits to identify >> which rule IPv4 address to chose (mostly an issue for BR in the v4->v6 >> direction). >> > > thanks, > maoke > > >> >> Thanks >> Senthil >> >> >> >> >> if i made mistakes, please point out without hesitation. thanks a lot! >> >> - maoke >> >> >>> [Senthil] No, atleast in our implementation we have checks to make >>> sure the prefixes don=92t overlap. >>> >>> Thanks >>> Senthil >>> >>> **** >>> >>> ** ** >>> >>> Thanks,**** >>> >>> Kris **** >>> >>> ** ** >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> > --047d7b66fef3f6919404d0b21ef0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

2012/12/13 Senthil Sivakumar (ssenthil) = <ssenthil@cisco.com>

Please see [Senthil3]
From: Maoke <fibrib@gmail.com>
Date: Tuesday, December 11, 2012 8:= 24 PM

To: Senthil Sivakumar <ssenthil@cisco.com>=
Cc: "Poscic, Kristian (Kristia= n)" <kristian.poscic@alcatel-lucent.com>, "softwires@ietf.org" <= ;softwires@ietf.org= >
Subject: Re: [Softwires] MAP-E/T ov= erlaping ranges and domains

hi Senthil,

inline for maoke2

2012/12/12 Senthil Sivakumar (ssenthil) <ssenthil@cisco.= com>
Hi Maoke,
Please see inline for Senthil2

From: Maoke <fibrib@gmail.com>
Date: Tuesday, December 11, 2012 5:= 21 AM
To: Senthil Sivakumar <ssenthil@cisco.com>=
Cc: "Poscic, Kristian (Kristia= n)" <kristian.poscic@alcatel-lucent.com>, "softwires@ietf.org" <softwires@ietf= .org>
Subject: Re: [Softwires] MAP-E/T ov= erlaping ranges and domains

hi Senthil,

interesting discussion. see inline.

2012/12/11 Senthil Sivakumar (ssenthil) <ssenthil@cisco.= com>


From: <Poscic>, "Kristia= n (Kristian)" <kristian.poscic@alcatel-lucent.com>
Date: Monday, December 10, 2012 3:0= 6 PM
To: "softwires@ietf.org" <softwires@ietf.org>
Subject: [Softwires] MAP-E/T overla= ping ranges and domains

Can someone clarify a few things for me:

=A0

1)=A0=A0=A0= =A0=A0 Does MAP support this scenario (example):

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 (BMR) Rule 1:=A0=A0

Rule IPv6 Prefix: =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2001::/40

Rule IPv4 Prefix: =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 192.0.2.0/24

Rule EA-bits length:=A0= =A0=A0=A0=A0=A0=A0 12

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 (BMR) Rule 2:

Rule IPv6 Prefix: =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2001::/40

Rule IPv4 Prefix: =A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 200.0.2.0/24

Rule EA-bits length:=A0= =A0=A0=A0=A0=A0=A0 12

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The on= ly difference between these two rules above is the =91Rule IPv4 Prefix=92, = everything else is the same. My obvious answer would be that this scenario = is not supported but wanted to be sure that I=92m not missing anything.<= /u>

This scenario above would= result in ambiguity between CEs, i.e. a single IA-PD that is delegated to = a CE can be associated with either of the two =A0rules above (EA bits can b= e the same for a CE from 192.0.2.0/24 range an= d for =A0a CE from 200.0.2.0/24 range.


what is the consequence if the CE has the two rules?

NOTE the delegation is independent of the IPv4 address in use. for example,= we have 2001:0:00xx:y000::/52 for the CE, where xx (8 bits) is the same as= the IPv4 suffix while y (4 bits) is applied for the PSID. if the source ad= dress has been selected from either rule ipv4 prefix, then the encapsulation or translation is determined and = the BR can de-capsulate or de-translate that without any difficulty because= the full IPv4 address is embedded in the IID part. when the response comes= , the destination address of the IPv4 packet is also determined though they would be encapsulated with the = same IPv6 prefix (not the same IPv6 CE address!).

[Senthil2] I don=92t see any issues with correctly decapsulating/trans= lating the packet on the BR for v6->v4. The issue is with the v4->v6.= You cannot correctly know which of the two IP addresses to embed. With tra= nslation, the communication will definitely fail if you embed the wrong IP address.=A0

[maoke2] i cannot catch your point. you mean v4->v6 at BR, right? which = IPv4 address to embed is determined by the session initiator. for example, = if a host behind CE makes a connection to 8.8.8.8, and if the CE happens to= have picking up 192.0.2.191 as the src IPv4 address, then the 8.8.8.8 will response 192.0.2.191 definitely. i= don't see that BR needs to choose an IPv4 address to embed: the destin= ation address in the packet replying to the session initiator is determined= .



the only concern is: if such a configuration can make different source IPv4= address for the packets of the same session. if so, the session might be t= roubled especially it is connection-oriented.

[Senthil2] It will. There is a 50% chance that you don=92t use the sam= e address as the one the that the client used. Because there is no state.

however, we may notice that NAT44 in the CE is not stateless. what is = selected for the session initialization would be continuously used for the = subsequent process of the same session. if the address is not shared so tha= t there is no NAT44, the native IPv4 source address selection logic will decide the selection and makes it= unique for a specific destination.

[Senthil2] With NAT44, it is even more stricter, if the BR didn=92t pi= ck the right IPv4 address the NAT44 state table wont match the incoming pac= ket.=A0

[maoke2] misunderstanding. BR don't have the chance to *pick up* IPv4 a= ddress.

[Senthil3] You are right, I missed that. But lets take your example:
Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D=A0192.0.2.0/24, ea-length =3D = 12
Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D=A0192.0.2.0/26, ea-length =3D = 12

CE1 sends the packet with its prefix and using the global addres= s 192.0.2.20 sends a packet to the BR. The BR matches rule 1 (assuming that= the longest matching prefix was that), and the resulting packet is a ipv4 = packet with a destination of 192.0.2.20 and the return packet comes back with the destination of 192.0.2.20. That = will match the rule2 because the longest prefix match for the v4 address is= 192.0.2.0/26. So we = use rule2 to construct the v6 packet. The destination v6 address is differe= nt now, even though you embedded the right v4 address in IID. How does that reach the C= E-1?=A0

[maoke3] we are on the same floor = that rule IPv4 prefix MUST NOT overlap among different CEs. but multiple ru= les can share the same rule IPv6 prefix (as long as the rule IPv4 prefixes = are not overlapped).
=A0

=A0


therefore personally i doubt the above multi-rule case doesn't work. if= i am right, it is not needed to make 'Rule IPv4 Prefix' unique per= 'Rule IPv6 Prefix'.
=A0

In this example above, it= is assumed that the delegated prefix (IA-PD) that DHCPv6 Server is handing= out to CEs is 2001::/40 with delegated prefix length /56.


why /56 instead of /52? :P
=A0

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This m= akes me believe that each rule must not only be unique (because the above t= wo rules are unique) but instead each rule must have a unique =A0=91Rule IP= v6 prefix=92 and a unique =91Rule IPv4 Prefix=92 per =91Rule IPv6 prefix=92= (IPv4 uniqueness is important in the downstream direction where lookup is perfor= med based on IPv4).

[Senthil] Right. The rules must not be overlapping with one another. E= ach domain can have a single IPv6 & single IPv4 rule prefix only. The i= pv6 and ipv4 rule prefix should not overlap with other ipv6 and ipv4 rules = prefixes respectively in other domains.

=A0

2)=A0=A0=A0= =A0=A0 What constitutes a MAP domain? I=92d think a unique = =91Rule IPv6 Prefix=92 which =A0(assuming that 1) is correct) would mean th= at a Domain =3D BMR. In other words, can a MAP domain contain a collection of BMRs? The drafts mention virtual-links, etc=85but it would be simpler i= f we can say Domain=3DBMR (not sure if this is accurate though).=A0 Of cour= se, nodes sharing the same set of those rules would be in the same MAP doma= in.

[Senthil] Each MAP domain should have a single rule IPv6 prefix and si= ngle IPv4 prefix. =A0I think a single IPv4 prefix may be too restrictive in= some deployments and people might want to use more than one prefix. But as= you have shown EA length can cause ambiguity and hence makes it undeployable.

=A0

3)=A0=A0=A0= =A0=A0 Is overlapping of =91Rule IPv6 Prefixes=92 supported?<= u>

For example in the above case, can we have for Rule 2) the =91Rule IPv6 = prefix=92 as 2001:0:80::/42.

In this case the =91Rule IPv6 Prefix=92 from Rule 1 overlaps with =91Rul= e IPv6 Prefix=92 from Rule 2. I assume that this would not be supported for= the same reason as in 1). I didn=92t think about the applicability of this= scenario for now, it is more of a theoretical question.


again, let's observe the consequence. again, we have the independently = delegated prefix for the CE. if the CE has the pd like 2001:0:81:6000::/54,= it matches both rules surely.=A0 longest-match can determine which rule is= in use (though not yet specified?). however, such a way may cause a subset of IPv4 residual addresses never used (i.e.,= wasted). in this example, the longest match to 2001:0:80::/42 may block 192.0.2.128/26 (192= .0.2.128 - 192.0.2.191) from using.

[Senthil2] That is a bad thing if you have to waste any of the address= es, as that is what we are trying to conserve here. And all this pain of sh= aring addresses is defeated.

[maoke2] agree that it is bad if we have waste.
=A0
I guess the bigger question why should one have such a design and its = usefulness.=A0

[maoke2] the bigger question is not only about the significance of allowing= it but also about the significance of forbidding it, and about what if it = happens even we have tried to forbid it. i surely don't encourage any w= aste but try to understand what we might have if we don't forbid it -- in order to make a proper statement in t= he specification.


the really problematic stuff is both rule IPv4 prefixes and rule IPv6 prefi= xes are overlapped among two rules but not aggregated.

Rule 1) rule IPv6 prefix =3D 2001::/40, rule IPv4 prefix =3D 192.0.2.0/24, ea-length =3D 12
Rule 2) rule IPv6 prefix =3D 2001:0:80::/42, rule IPv4 prefix =3D 192.0.2.0/26, ea-length =3D 12

[Senthil2] Well, I think you are trying to prove that one can have two= rule IPv6 prefixes but as long as the ipv4 addresses don=92t overlap then = we will be able to unambiguosly encap/decap/translate the packets. But I wo= nder=A0what is the advantage of having two rule IPv6 prefixes.

[maoke2] if all controlled by one party, it is true there is no obvious adv= antage at current understanding. however, what if two rule IPv6 prefixes ar= e the reality, out of our control? ;-)

[Senthil3] Do you see a use case or a scenario that is happening= , that we would end up with multiple IPv6 rule prefixes and ipv4 rule prefi= xes?

[maoke3] as the above, it is possible= that two or more parties are deploying MAP domains on some common CEs, if = the MAP domain !=3D AS is allowed. to clarify: with multiple rules where ru= le IPv6 prefixes can be shared / overlapped but rule IPv4 prefixes must not= .

thanks,
- maoke
=A0

Thanks
Senthil

=A0
In the above case, the /26 is a subset of /24, so really there is no r= eal advantage of having a separate rule ipv4 prefix.

[maoke2] rule IPv4 prefix overlapping is another question. and i tried to s= how it is really harmful. in practice, it is understood that aggregateable = IPv4 prefixes' corresponding IPv6 prefixes MUST be aggregated in the sa= me way.
=A0

and one CE-a has delegated prefix 2001:0:3f:5000::/52, while another CE-b h= as 2001:0:bf:5000::/54. such a delegation seems no problem at all. CE-a mat= ches Rule 1 while CE-b matches Rule 2. then the trouble happens: CE-a will = use the IPv4 address 192.0.2.63 with PSID =3D binary_0101, obviously; while CE-b have

=A0=A0=A0 40-55bits =3D 0x8fd4 =3D binary_1011 1111 0101 0000
=A0=A0=A0 then EA-bits =3D binary_11 1111 0101 00
=A0=A0=A0 then IPv4 suffix =3D binary_11 1111, PSID =3D binary_0101 00
=A0=A0=A0 when attached to 192.0.2.0/26, it will be 192.0.2.63 with PSID =3D binary_0101 00

i.e., CE-b's usable port-range is overlapped with CE-a on the same IPv4= address!

therefore, IMHO, the constraint of BMR-making MUST ensure the (IPv4 address= , port-range)-pair is not overlapped among different CE, therefore Rule IPv= 4 Prefixes cannot be overlapped among BMRs. this is necessary and sufficien= t.

[Senthil2] I agree with your example and assertion above. But I really= don=92t see a good use case for having multiple rule IPv6 prefixes and ove= rlapping rule IPv4 prefixes.

[maoke2] when we deploy a MAP domain, it is definitely not necessary to mak= e complicated scenarios. however, it is possible happen in reality: as pref= ix delegation is independent of the MAP deployment, it is possible that two= MAP domains deployed so that a CE possibly joins both. i also highlight the use-case that MAP domain can = be deployed across ASes, where the delegated prefix is not controlled by th= e party deploying MAP and surely the party cannot make sure if this pd is a= lso used by another MAP deployment party or not.

[maoke2] i have not yet concluded that the above scenario makes sense or no= t. however, your thread raises very important questions related to such a s= cenario and therefore we need to understand/clarify what does make sense wh= at really doesn't.
=A0
Maybe the use case for a overlapping rule IPv4 case is more compelling= , as you can get two blocks of public addresses that overlap on the lower n= bits, where the n bits are not unique enough in the EA bits to identify wh= ich rule IPv4 address to chose (mostly an issue for BR in the v4->v6 direction).

thanks,
maoke
=A0

Thanks
Senthil




if i made mistakes, please point out without hesitation. thanks a lot!

- maoke

[Senthil] No, atleast in our implementation we have checks to make sur= e the prefixes don=92t overlap.

Thanks
Senthil

=A0

Thanks,

Kris

=A0


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

--047d7b66fef3f6919404d0b21ef0-- From kristian.poscic@alcatel-lucent.com Wed Dec 12 21:59:47 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 498C021F881A for ; Wed, 12 Dec 2012 21:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.523 X-Spam-Level: X-Spam-Status: No, score=-9.523 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk1gTCr4sH-6 for ; Wed, 12 Dec 2012 21:59:46 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8288F21F8667 for ; Wed, 12 Dec 2012 21:59:44 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBD5xde8020465 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 13 Dec 2012 06:59:40 +0100 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 13 Dec 2012 06:59:39 +0100 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.227]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Thu, 13 Dec 2012 00:59:36 -0500 From: "Poscic, Kristian (Kristian)" To: Sheng Jiang , "softwires@ietf.org" Thread-Topic: dhcp/radius in MAT-E/T Thread-Index: Ac3YvCkKqx0/6H1lRXCrBD33fX32UAAE0dfwAAm7AQA= Date: Thu, 13 Dec 2012 05:59:36 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AA2A833@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <7921F977B17D5B49B8DCC955A339D2F02AA2A3B9@US70UWXCHMBA05.zam.alcatel-lucent.com> <5D36713D8A4E7348A7E10DF7437A4B9239FD45D5@szxeml545-mbs.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239FD45D5@szxeml545-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AA2A833US70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "draft-jiang-softwire-map-radius@ietf.org" Subject: Re: [Softwires] dhcp/radius in MAT-E/T 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, 13 Dec 2012 05:59:47 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02AA2A833US70UWXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2ssIHRoYW5rcy4NCg0KSW4gREhDUCB0aGVyZSBhcmUgc3RpbGwgYSBmZXcgb3B0aW9uLWNvZGVz IHVuZGVmaW5lZCwgc3VjaCBhcyBvcHRpb24tY29kZTogT1BUSU9OX01BUF9QT1JUUEFSQU1TIChU QkQ0KSwgZXRj4oCmIG5vdCBzdXJlIGlmIHRoaXMgaGFzIGJlZW4gYXNzaWduZWQgYnkgSUFOQS4g QnV0IEkgbmVlZCB0byBsb29rIHRoZSB0cmFuc2NyaXB0IGZyb20gdGhlIERIQyBmb2xrcyBmaXJz dCB0byBzZWUgd2hlcmUgaXMgdGhpcyBoZWFkaW5nLg0KDQoNCg0KRm9yIFJhZGl1cyBpdCBzZWVt cyBvaywgSSB3YXMgY29uZnVzZWQgYnkgdGhlDQoNCiAg4oCYVHlwZSAgVEJE4oCZIGluIHNlY3Rp b24gNC4xLCBwYWdlIDUuDQoNCg0KDQpCdXQgSSBzZWUgbm93IHRoYXQgdGhlIHR5cGVzIGFyZSBk ZWZpbmVkIGZ1cnRoZXIgYmVsb3cgaW4gdGhlIGRyYWZ0Lg0KDQpUaGFua3MgYWdhaW4uDQoNCkty aXMNCg0KDQoNCg0KRnJvbTogU2hlbmcgSmlhbmcgW21haWx0bzpqaWFuZ3NoZW5nQGh1YXdlaS5j b21dDQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDEyLCAyMDEyIDU6MTkgUE0NClRvOiBQb3Nj aWMsIEtyaXN0aWFuIChLcmlzdGlhbik7IHNvZnR3aXJlc0BpZXRmLm9yZw0KQ2M6IGRyYWZ0LWpp YW5nLXNvZnR3aXJlLW1hcC1yYWRpdXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBkaGNwL3JhZGl1 cyBpbiBNQVQtRS9UDQoNCldlIGRpZCBwcmVzZW50IGRyYWZ0LWppYW5nLXNvZnR3aXJlLW1hcC1y YWRpdXMtMDIgaW4gQXRsYW50YSBhbmQgY29udGludWUgd29ya2luZyBvbiBpdC4NCg0KU2luY2Ug eW91IHN0YXRlIOKAnHRoZXJlIGFyZSBtYW55IGNvZGVzIHN0aWxsIG1pc3NpbmfigJ0sIGlmIHlv dSBjYW4gZ2l2ZSBtZSBhIGRldGFpbGVkIG1haWwgdG8gZXhwbGFpbiB3aGF0IGlzIG1pc3Npbmcs IGl0IG1pZ2h0IGJlIHZlcnkgZ29vZCBjb250cmlidXRpb25zLg0KDQpNYW55IHRoYW5rcyBhbmQg YmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQpGcm9tOiBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86c29mdHdpcmVzLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQb3NjaWMsIEtyaXN0aWFuIChLcmlzdGlhbikN ClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxMywgMjAxMiA3OjAzIEFNDQpUbzogc29mdHdpcmVz QGlldGYub3JnPG1haWx0bzpzb2Z0d2lyZXNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbU29mdHdpcmVz XSBkaGNwL3JhZGl1cyBpbiBNQVQtRS9UDQoNCkhhcyBhbnkgZnVydGhlciB3b3JrIGJlZW4gZG9u ZSBvbjoNCg0KZHJhZnQtbWR0LXNvZnR3aXJlLW1hcC1kaGNwLW9wdGlvbi0wMzxodHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1kdC1zb2Z0d2lyZS1tYXAtZGhjcC1vcHRpb24v Pg0KZHJhZnQtamlhbmctc29mdHdpcmUtbWFwLXJhZGl1cy0wMjxodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWppYW5nLXNvZnR3aXJlLW1hcC1yYWRpdXMvPg0KDQpUaGVyZSBh cmUgbWFueSBjb2RlcyBzdGlsbCBtaXNzaW5nIGluIHRob3NlIHR3byBkcmFmdHMuDQoNCkxhc3Qg SSByZW1lbWJlciB3YXMgc29tZSBkaXNjdXNzaW9uIHZpYSBlbWFpbHMgd2hlcmUgaXQgd2FzIGRl YmF0ZWQgd2l0aCBESEMgZm9sa3Mgd2hldGhlciB0aG9zZSBvcHRpb25zIHNob3VsZCBiZSBwYXNz ZWQgdmlhIERIQ1B2NiBvciBub3TigKZJIHdhcyB3b25kZXJpbmcgaWYgdGhvc2UgZGlzY3Vzc2lv bnMgaGF2ZSBwcm9ncmVzc2VkIGluIEF0bGFudGEuDQoNClRoYW5rcywNCktyaXMNCg== --_000_7921F977B17D5B49B8DCC955A339D2F02AA2A833US70UWXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciLCJzZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOiMxRjQ5N0QiPk9rLCB0aGFua3MuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gREhDUCB0aGVyZSBhcmUgc3RpbGwgYSBmZXcgb3B0aW9u LWNvZGVzIHVuZGVmaW5lZCwgc3VjaCBhcyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPm9wdGlvbi1jb2RlOiBPUFRJT05fTUFQX1BPUlRQQVJBTVMgKFRC RDQpLCBldGPigKYgbm90IHN1cmUgaWYgdGhpcyBoYXMgYmVlbiBhc3NpZ25lZCBieSBJQU5BLiBC dXQgSSBuZWVkIHRvIGxvb2sgdGhlIHRyYW5zY3JpcHQgZnJvbSB0aGUgREhDIGZvbGtzIGZpcnN0 IHRvIHNlZSB3aGVyZSBpcyB0aGlzIGhlYWRpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkZvciBSYWRpdXMgaXQgc2VlbXMgb2ssIEkgd2FzIGNvbmZ1c2VkIGJ5IHRoZSA8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwO+KA mFR5cGUmbmJzcDsgVEJE4oCZIGluIHNlY3Rpb24gNC4xLCBwYWdlIDUuIDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgSSBzZWUgbm93IHRoYXQgdGhlIHR5cGVzIGFyZSBk ZWZpbmVkIGZ1cnRoZXIgYmVsb3cgaW4gdGhlIGRyYWZ0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBhZ2Fpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9ImxpbmUtaGVpZ2h0OjE0LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPktyaXMgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJsaW5lLWhlaWdodDoxNC40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTaGVuZyBK aWFuZyBbbWFpbHRvOmppYW5nc2hlbmdAaHVhd2VpLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIERlY2VtYmVyIDEyLCAyMDEyIDU6MTkgUE08YnI+DQo8Yj5Ubzo8L2I+IFBvc2Np YywgS3Jpc3RpYW4gKEtyaXN0aWFuKTsgc29mdHdpcmVzQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9i PiBkcmFmdC1qaWFuZy1zb2Z0d2lyZS1tYXAtcmFkaXVzQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJFOiBkaGNwL3JhZGl1cyBpbiBNQVQtRS9UPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+V2UgZGlkIHByZXNlbnQgZHJh ZnQtamlhbmctc29mdHdpcmUtbWFwLXJhZGl1cy0wMiBpbiBBdGxhbnRhIGFuZCBjb250aW51ZSB3 b3JraW5nIG9uIGl0Ljwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPlNpbmNlIHlvdSBzdGF0ZSDigJx0aGVyZSBhcmUgbWFueSBjb2RlcyBzdGlsbCBtaXNz aW5n4oCdLCBpZiB5b3UgY2FuIGdpdmUgbWUgYSBkZXRhaWxlZCBtYWlsIHRvIGV4cGxhaW4gd2hh dCBpcyBtaXNzaW5nLCBpdCBtaWdodCBiZSB2ZXJ5IGdvb2QgY29udHJpYnV0aW9ucy48L3NwYW4+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5NYW55IHRoYW5rcyBh bmQgYmVzdCByZWdhcmRzLDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPlNoZW5nPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj4NCjxhIGhyZWY9Im1haWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZyI+ c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86c29mdHdpcmVz LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBvc2NpYywgS3Jpc3RpYW4gKEtyaXN0aWFuKTxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgRGVjZW1iZXIgMTMsIDIwMTIgNzowMyBBTTxicj4NCjxiPlRv OjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNvZnR3aXJlc0BpZXRmLm9yZyI+c29mdHdpcmVzQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbU29mdHdpcmVzXSBkaGNwL3JhZGl1cyBpbiBN QVQtRS9UPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5IYXMgYW55IGZ1cnRoZXIgd29yayBiZWVuIGRvbmUgb246PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWR0LXNv ZnR3aXJlLW1hcC1kaGNwLW9wdGlvbi8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dy b3VuZDojRURGNUZGIj5kcmFmdC1tZHQtc29mdHdpcmUtbWFwLWRoY3Atb3B0aW9uLTAzPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamlhbmctc29mdHdpcmUtbWFwLXJhZGl1cy8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7YmFja2dyb3VuZDp3aGl0ZSI+ZHJhZnQtamlhbmctc29mdHdp cmUtbWFwLXJhZGl1cy0wMjwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoZXJlIGFyZSBtYW55IGNvZGVzIHN0 aWxsIG1pc3NpbmcgaW4gdGhvc2UgdHdvIGRyYWZ0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+TGFzdCBJIHJlbWVtYmVyIHdh cyBzb21lIGRpc2N1c3Npb24gdmlhIGVtYWlscyB3aGVyZSBpdCB3YXMgZGViYXRlZCB3aXRoIERI QyBmb2xrcyB3aGV0aGVyIHRob3NlIG9wdGlvbnMgc2hvdWxkIGJlIHBhc3NlZCB2aWEgREhDUHY2 IG9yIG5vdOKApkkgd2FzIHdvbmRlcmluZyBpZiB0aG9zZSBkaXNjdXNzaW9ucyBoYXZlIHByb2dy ZXNzZWQgaW4NCiBBdGxhbnRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj5LcmlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_7921F977B17D5B49B8DCC955A339D2F02AA2A833US70UWXCHMBA05z_-- From sunqi.csnet.thu@gmail.com Thu Dec 13 19:07:06 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 8858421F8C0B; Thu, 13 Dec 2012 19:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehKYMU1c4r33; Thu, 13 Dec 2012 19:06:53 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C7E4D21F8C16; Thu, 13 Dec 2012 19:06:53 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so1111238dae.31 for ; Thu, 13 Dec 2012 19:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=8tJwehCSyU7YV6bwb9ZDgtRrPxVWscdZ7ZIHIghwzZc=; b=zkFO2Gug/mugBw2rJhdgoKyAaBkIDjJeVeDNO2eCDsALyalxlT+3T+BsLxL7DZ7dH8 EZQpsM0m1JkCS9N+TFzrx0dVSA+L4gLxYHSKiUwm6XEzNvs4c+bkmmo1WeKkDvQJvb6o exiTALBwUUOet9uZemxS+xcI0eDxeuU9Ui85zfJbH6fEYAl1G/iKhWF7wRWGtEWx/7zG Vw9OYyibb7nc22kE2Xl6VDtcIPVioTvxiu0YNzOcQKKeI6wzzb3yJoAxyfkD/sWHNtf1 LyYNuVlYPCJn78w1Eab/njmQg2ZML5QMHFkuJxJAGWhllTlFoKtQGKPnGXN5x1xQ1tt7 RiCw== Received: by 10.68.223.131 with SMTP id qu3mr11626424pbc.89.1355454413449; Thu, 13 Dec 2012 19:06:53 -0800 (PST) Received: from ?IPv6:2001:da8:215:6819:9284:dff:fef3:d346? ([2001:da8:215:6819:9284:dff:fef3:d346]) by mx.google.com with ESMTPS id ix9sm2077668pbc.7.2012.12.13.19.06.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 13 Dec 2012 19:06:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-14--809912885 From: Qi Sun In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E9A176EAC@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 14 Dec 2012 11:06:48 +0800 Message-Id: <64EEC0CC-0132-420E-A91C-7735850ACE72@gmail.com> References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <50B9B5C7.107@viagenie.ca> <10C9FD27-2894-4495-90E1-15A9AC9D73B9@employees.org> <8A1B81989BCFAE44A22B2B86BF2B76318954FEE360@HE111643.EMEA1.CDS.T-INTERNAL.COM> , <8A1B81989BCFAE44A22B2B86BF2B7631895539BCBC@HE111643.EMEA1.CDS.T-INTERNAL.COM> <8B727D3A-2531-49C8-808B-91EE79AC9453@huawei.com> <94C682931C08B048B7A8645303FDC9F36E9A176EAC@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org WG" , IETF Working Group DHC Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe 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, 14 Dec 2012 03:07:06 -0000 --Apple-Mail-14--809912885 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear authors, Thank you for your hard work! I think we are trying to move forward.=20 I have some comments on the provisioning method. In the section 4.4 that there is a new sub-option OPTION_MAP_BIND. It is = the sub-option of OPTION_MAP (OPTION_SW) used to convey an IPv4 address. = Considering OPTION_MAP (OPTION_SW) is a DHCPv6 option, it is a little = confusing that we are going to use DHCPv6 for IPv4 resources allocation. = IMHO, this should be the decision of DHC WG, which hasn't published the = outcome of this issue. Is it possible that we make this part clearer? Best Regards, Qi On 2012-12-6, at =E4=B8=8B=E5=8D=882:35, = wrote: > Hi Tina, > =20 > Many thanks for the comments. Some clarifications below: > =20 > * DS-Lite is included in the scope for the reasons detailed in the = draft (see Section 1.1): > (2) Simplify solution migration paths: Define a unified CPE = behavior > which allows for smooth migration between the different modes > and > (4) Re-usability: Maximize the re-use of existing functional = blocks > including Tunnel Endpoint, port restricted NAPT44, Forwarding > behavior, etc. > * Public 4over6 is already included in the draft: > (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) > [I-D.cui-softwire-b4-translated-ds-lite], > [I-D.ietf-softwire-public-4over6] or MAP 1:1 > [I-D.ietf-softwire-map] ): Requires a single per-subscriber > state (or a few) to be maintained in the Service Provider's > network. > * I agree with you the title should be updated to reflect the scope of = the draft. The proposed scope is IPv4 service continuity over IPv6 = mechanisms. > =20 > Cheers, > Med >=20 > De : softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] De = la part de Tina TSOU > Envoy=C3=A9 : mercredi 5 d=C3=A9cembre 2012 19:34 > =C3=80 : ian.farrer@telekom.de > Cc : softwires@ietf.org > Objet : Re: [Softwires] Unified Softwire CPE: = draft-bfmk-softwire-unified-cpe >=20 > Dear Med, Ian and Suresh, > Great job! Draft-bfmk is written very well to reach consensus. > Two small comments are below. > 1. I=E2=80=99m not sure whether it is appropriate to put DS-Lite = case into the document, since in DS-Lite case the CPE is only the tunnel = end point without NAT, which is basically different with lw4over6/MAP. = But if the objective of this document is to define an unified CPE for = all the 4over6 mechanisms, other mechanisms like public 4over6 should = also be included in the document. My understanding may be wrong. > 2. The title says =E2=80=9Cunified softwire CPE=E2=80=9D, but in = softwire, there are many other transition technologies, e.g., 6rd. To be = specific, maybe 4over6 CPE is more appropriate. >=20 > Thank you, > Tina >=20 > On Dec 4, 2012, at 9:53 AM, "ian.farrer@telekom.de" = wrote: >=20 >> Hi Ole, >>=20 >> Answers inline. >>=20 >> Cheers, >> Ian >>=20 >> -----Original Message----- >> From: Ole Tr=C3=B8an [mailto:otroan@employees.org]=20 >> Sent: Montag, 3. Dezember 2012 10:06 >> To: Farrer, Ian >> Cc: simon.perreault@viagenie.ca; softwires@ietf.org >> Subject: Re: [Softwires] Unified Softwire CPE: = draft-bfmk-softwire-unified-cpe >>=20 >> Ian, >>=20 >>> Whichever state is selected, NAT is certainly fundamental to how the = state will operate and so we tried to weave it into the functional = description. I'm not sure that provisioned NAT info enough to be able to = use to unambiguously define with operating 'mode' (for want of a better = word) to use. >>>=20 >>> One of the reasons for the use of state in the draft is try and = define the operating modes with as little overlap as possible (it's not = 100%, but there's only 1 exception at the moment for binding mode and = MAP1:1). =46rom this, then it is easier to align the specific solution = names to the state characteristics. >>=20 >> I don't think you should try to define modes such that the map (no = pun intended) into the specific solution names. >> shouldn't the purpose of a "unified CPE", be for the CPE not to have = to care about the different "deployment modes" on the head end? >>=20 >> Ian: But a MAP CPE does have to care about what is on the tunnel head = end as it could be another mesh client, or it could be the BR. It uses a = different mapping rule type for each, so it is aware of the capabilities = of the head end. >>=20 >>> But, with what you've suggested, there is more overlap, i.e. both = 2&4 have NAT functions that are supported by two different mechanisms. >>>=20 >>> However, what you've said does raise the following point: >>>=20 >>> The way that state is described in the draft at the moment is = actually taken from a concentrator perspective. This could be taken to = be almost the inverse of the amount of state that is required from the = CPEs perspective (i.e. if all of the state is in the providers network = (DS-Lite), then the CPE doesn't need it. If the providers network has = less state ('per-customer', 'stateless'), then the CPE needs to have = more - i.e. dynamic state table for NAT, configuration for local = IPv4/port set, MAPing rules etc. >>>=20 >>> Would describing the different states more from the CPE's = perspective make this clearer? >>=20 >> that would certainly help. although I don't think "state" is the = defining characteristic. >>=20 >> Ian: Is the problem with the what's being described (i.e. the content = and functional differentiations) or the naming and terminology used to = describe it? >>=20 >>=20 >> cheers, >> 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 --Apple-Mail-14--809912885 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear authors,

Thank you for your hard = work! I think we are trying to move forward. 

I have some comments on = the provisioning method.
In the section 4.4 that there is a new = sub-option OPTION_MAP_BIND. It is the sub-option of OPTION_MAP = (OPTION_SW) used to convey an IPv4 address. Considering OPTION_MAP = (OPTION_SW) is a DHCPv6 option, it is a little confusing that we are = going to use DHCPv6 for IPv4 resources allocation. IMHO, this should be = the decision of DHC WG, which hasn't published the outcome of this = issue.

Is it possible that we make this part clearer?

Best Regards,
Qi


Hi = Tina,
 
Many thanks for the = comments. Some clarifications=20 below:
 
* DS-Lite is included = in the scope for the reasons=20 detailed in the draft (see Section 1.1):
   (2)  Simplify solution migration paths: Define a =
unified CPE behavior
        which allows for smooth migration between the different modes
and
   (4)  Re-usability: Maximize the =
re-use of existing functional blocks
        including Tunnel Endpoint, port restricted NAPT44, Forwarding
        behavior, etc.
* Public 4over6 is = already included in the=20 draft:
   (2)  Binding approach (e.g., Lightweight 4over6 =
(Lw4o6)
        [I-D.cui-softwire-b4-translated-ds-=
lite],
        [I-D.ietf-softwire-public-4over6] or =
MAP 1:1
        [I-D.ietf-softwire-map] ): Requires a single =
per-subscriber
        state (or a few) to be maintained in the Service Provider's
        network.
* I agree with you the = title should be updated to=20 reflect the scope of the draft. The proposed scope is IPv4 service=20= continuity over IPv6 mechanisms.
 
Cheers,
Med

De : softwires-bounces@ietf.org=20= [mailto:softwires-bounces@ietf.org] De la part de Tina=20 TSOU
Envoy=C3=A9 : mercredi 5 d=C3=A9cembre 2012 = 19:34
=C3=80 :=20 ian.farrer@telekom.de
Cc&n= bsp;:=20 softwires@ietf.org
Objet = ;: Re: [Softwires] Unified Softwire=20 CPE: draft-bfmk-softwire-unified-cpe

Dear Med, Ian and Suresh,
Great job! Draft-bfmk is written = very well to reach=20 consensus.
Two small=20 comments are below.
1.      I=E2=80=99m not sure whether it is appropriate to put = DS-Lite case into the=20 document, since in DS-Lite case the CPE is only the tunnel end point = without=20 NAT, which is basically different with lw4over6/MAP. But if the = objective of=20 this document is to define an unified CPE for all the 4over6 = mechanisms, other=20 mechanisms like public 4over6 should also be included in the document. = My=20 understanding may be wrong.
2.      The title says =E2=80=9Cunified softwire CPE=E2=80=9D, = but in softwire, there are=20 many other transition technologies, e.g., 6rd. To be specific, maybe = 4over6=20 CPE is more appropriate.

Thank you,
Tina

On Dec 4, 2012, at 9:53 AM, "ian.farrer@telekom.de" <ian.farrer@telekom.de>=20 wrote:

Hi Ole,

Answers=20 = inline.

Cheers,
Ian

-----Original=20 Message-----
From: Ole Tr=C3=B8an = [mailto:otroan@employees.org]=20
Sent: Montag, 3. Dezember 2012 = 10:06
To:=20 Farrer, Ian
Cc: simon.perreault@viagenie.ca;=20 softwires@ietf.org
= Subject:=20 Re: [Softwires] Unified Softwire CPE:=20 = draft-bfmk-softwire-unified-cpe

Ian,

Whichever state is selected, NAT is=20= certainly fundamental to how the state will operate and so we = tried to=20 weave it into the functional description. I'm not sure that = provisioned=20 NAT info enough to be able to use to unambiguously define with = operating=20 'mode' (for want of a better word) to use.

One of the reasons for the use of = state in=20 the draft is try and define the operating modes with as little = overlap as=20 possible (it's not 100%, but there's only 1 exception at the = moment for=20 binding mode and MAP1:1). =46rom this, then it is easier to align = the=20 specific solution names to the state=20 characteristics.

I = don't think=20 you should try to define modes such that the map (no pun intended) = into the=20 specific solution names.
shouldn't the purpose of a = "unified=20 CPE", be for the CPE not to have to care about the different = "deployment=20 modes" on the head end?

Ian: But a = MAP CPE=20 does have to care about what is on the tunnel head end as it could = be=20 another mesh client, or it could be the BR. It uses a different = mapping rule=20 type for each, so it is aware of the capabilities of the head=20 end.

But, with what you've suggested, = there is=20 more overlap, i.e. both 2&4 have NAT functions that are = supported by=20 two different mechanisms.

However, what you've said does raise = the=20 following point:

The way that state is described in = the draft=20 at the moment is actually taken from a concentrator perspective. = This=20 could be taken to be almost the inverse of the amount of state = that is=20 required from the CPEs perspective (i.e. if all of the state is in = the=20 providers network (DS-Lite), then the CPE doesn't need it. If the=20= providers network has less state ('per-customer', 'stateless'), = then the=20 CPE needs to have more - i.e. dynamic state table for NAT, = configuration=20 for local IPv4/port set, MAPing rules etc.

Would describing the different = states more=20 from the CPE's perspective make this=20 clearer?

that would = certainly=20 help. although I don't think "state" is the defining=20 characteristic.

Ian: Is the problem = with=20 the what's being described (i.e. the content and functional=20 differentiations) or the naming and terminology used to describe=20 = it?


cheers,
Ole
_______________________________________________
Softwires=20 mailing list
Softwires@ietf.org
= https://www.ietf.= org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= --Apple-Mail-14--809912885-- From suresh.krishnan@ericsson.com Sun Dec 16 20:36: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 51CAF21F892A for ; Sun, 16 Dec 2012 20:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ayjb-szAPKdn for ; Sun, 16 Dec 2012 20:36:11 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6F421F8512 for ; Sun, 16 Dec 2012 20:36:11 -0800 (PST) Received: from EUSAAHC005.ericsson.se ([147.117.188.87]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qBH4a8vH015448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Dec 2012 22:36:08 -0600 Received: from eusaamw0712.eamcs.ericsson.se (147.117.20.181) by EUSAAHC005.ericsson.se (147.117.188.87) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 16 Dec 2012 23:36:08 -0500 Received: from [164.48.125.18] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 16 Dec 2012 23:36:06 -0500 Message-ID: <50CEA09E.8000204@ericsson.com> Date: Sun, 16 Dec 2012 23:33:34 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Softwires WG X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Yong Cui , Ralph Droms Subject: [Softwires] Second working group last call for draft-ietf-softwire-public-4over6-04 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, 17 Dec 2012 04:36:12 -0000 Hi all, This message starts a second softwire working group last call on advancing the draft about providing Public IPv4 over IPv6 Access Network as a Standards Track RFC. The authors believe that this version has addressed the issues raised during the previous WGLC. The draft is available at http://www.ietf.org/id/draft-ietf-softwire-public-4over6-04.txt http://tools.ietf.org/html/draft-ietf-softwire-public-4over6-04 Substantive comments and statements of support/opposition for advancing this document should be directed to the mailing list. Editorial suggestions can be sent directly to the authors. The chairs will send in their comments as well during the last call period. This last call will conclude on January 4, 2013. Regards, Suresh & Yong From mohamed.boucadair@orange.com Mon Dec 17 00:54:52 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 2E09421F8A4E for ; Mon, 17 Dec 2012 00:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wG-Ntjjz-LsW for ; Mon, 17 Dec 2012 00:54:51 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 889F221F8A46 for ; Mon, 17 Dec 2012 00:54:41 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3D08618C3CF; Mon, 17 Dec 2012 09:54:40 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 16BC44C102; Mon, 17 Dec 2012 09:54:40 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Mon, 17 Dec 2012 09:54:39 +0100 From: To: Suresh Krishnan , Softwires WG Date: Mon, 17 Dec 2012 09:54:39 +0100 Thread-Topic: [Softwires] Second working group last call for draft-ietf-softwire-public-4over6-04 Thread-Index: Ac3cEA2iMBpls8C/QFSjT6HnZfWN0QAIxerA Message-ID: <94C682931C08B048B7A8645303FDC9F36E9D16E4C8@PUEXCB1B.nanterre.francetelecom.fr> References: <50CEA09E.8000204@ericsson.com> In-Reply-To: <50CEA09E.8000204@ericsson.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: Yong Cui , Ralph Droms Subject: Re: [Softwires] Second working group last call for draft-ietf-softwire-public-4over6-04 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, 17 Dec 2012 08:54:52 -0000 Dear Suresh, all, With all due respect to the authors of this draft, I really think this docu= ment should not move forward.=20 The feature described in this draft can be easily integrated in the current= unified CPE effort (binding mode: MAP1:1/Lw4over6) or the document needs t= o be extended to cover the port restriction feature. Cheers, Med >-----Message d'origine----- >De : softwires-bounces@ietf.org=20 >[mailto:softwires-bounces@ietf.org] De la part de Suresh Krishnan >Envoy=E9 : lundi 17 d=E9cembre 2012 05:34 >=C0 : Softwires WG >Cc : Yong Cui; Ralph Droms >Objet : [Softwires] Second working group last call for=20 >draft-ietf-softwire-public-4over6-04 > >Hi all, > This message starts a second softwire working group last call on >advancing the draft about providing Public IPv4 over IPv6=20 >Access Network >as a Standards Track RFC. The authors believe that this version has >addressed the issues raised during the previous WGLC. The draft >is available at > >http://www.ietf.org/id/draft-ietf-softwire-public-4over6-04.txt >http://tools.ietf.org/html/draft-ietf-softwire-public-4over6-04 > >Substantive comments and statements of support/opposition for advancing >this document should be directed to the mailing list. Editorial >suggestions can be sent directly to the authors. The chairs=20 >will send in >their comments as well during the last call period. This last call will >conclude on January 4, 2013. > >Regards, >Suresh & Yong > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires >= From sunqi.csnet.thu@gmail.com Mon Dec 17 01:07:37 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 2D51721F8A6A for ; Mon, 17 Dec 2012 01:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa-JdEFzNFUZ for ; Mon, 17 Dec 2012 01:07:33 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C35A21F88E3 for ; Mon, 17 Dec 2012 01:07:33 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so2423010dae.31 for ; Mon, 17 Dec 2012 01:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rfFtPxHJgIT3tnqyTs0Ae49EgCD50i0BJTD3UjlIlJE=; b=NajVXssxEJefTQ1WjFdOfe/dY3R3OQLeTrtydQbXYmcG2+sVGd4PKhg4pgyPJdcydN Q9t3XI3eMuY+obIIyWGRFwyeXgUqgmFdtaAz2BAPRU9qlRTYxFUk+j5CTMK47+ikXH1H /QESxO/VCoG3bhh7MosFsfi9h40dPPLRpokFIYju/URkfOaIm1TmkF+ksZ6cqAYLGAxG 80NUIhWS4DkE2U+JvMgFyEbIffF0fmPjogCXvmH6LKmoChocMOsp19iJiNNMWBvMuGme rU1szQREStnz2y1uQKHGPKvkHqtlh82jyNIjU3QSBq5R6S6PRrEcDEFSlYuMFhK8nhHC j2xQ== Received: by 10.68.237.167 with SMTP id vd7mr41577663pbc.161.1355735252941; Mon, 17 Dec 2012 01:07:32 -0800 (PST) Received: from [192.168.0.106] ([114.255.41.137]) by mx.google.com with ESMTPS id l5sm8244868paz.14.2012.12.17.01.07.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Dec 2012 01:07:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <50CEA09E.8000204@ericsson.com> Date: Mon, 17 Dec 2012 17:07:23 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50CEA09E.8000204@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Second working group last call for draft-ietf-softwire-public-4over6-04 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, 17 Dec 2012 09:07:37 -0000 Dear Suresh, I support the draft moving forward. Best Regards, Qi Sun On 2012-12-17, at =E4=B8=8B=E5=8D=8812:33, Suresh Krishnan wrote: > Hi all, > This message starts a second softwire working group last call on > advancing the draft about providing Public IPv4 over IPv6 Access = Network > as a Standards Track RFC. The authors believe that this version has > addressed the issues raised during the previous WGLC. The draft > is available at >=20 > http://www.ietf.org/id/draft-ietf-softwire-public-4over6-04.txt > http://tools.ietf.org/html/draft-ietf-softwire-public-4over6-04 >=20 > Substantive comments and statements of support/opposition for = advancing > this document should be directed to the mailing list. Editorial > suggestions can be sent directly to the authors. The chairs will send = in > their comments as well during the last call period. This last call = will > conclude on January 4, 2013. >=20 > Regards, > Suresh & Yong >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From internet-drafts@ietf.org Tue Dec 18 17:44: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 CB98C21E8039; Tue, 18 Dec 2012 17:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JhiJck2kGEF; Tue, 18 Dec 2012 17:44:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F9221F85BC; Tue, 18 Dec 2012 17:44:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121219014443.2612.14655.idtracker@ietfa.amsl.com> Date: Tue, 18 Dec 2012 17:44:43 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-6rd-radius-attrib-09.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: Wed, 19 Dec 2012 01:44:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : RADIUS Attribute for 6rd Author(s) : Dayong Guo Sheng Jiang Remi Despres Roberta Maglione Filename : draft-ietf-softwire-6rd-radius-attrib-09.txt Pages : 11 Date : 2012-12-18 Abstract: IPv6 Rapid Deployment (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd 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 acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-6rd-radius-attrib-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mohamed.boucadair@orange.com Wed Dec 19 09:01:48 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 D1AAA21F8932 for ; Wed, 19 Dec 2012 09:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oNAiXJbVOL3 for ; Wed, 19 Dec 2012 09:01:48 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2402B21F8820 for ; Wed, 19 Dec 2012 09:01:47 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 66AB122C795 for ; Wed, 19 Dec 2012 18:01:47 +0100 (CET) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 4FFBB27C067 for ; Wed, 19 Dec 2012 18:01:47 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Wed, 19 Dec 2012 18:01:47 +0100 From: To: Softwires WG Date: Wed, 19 Dec 2012 18:01:46 +0100 Thread-Topic: draft-bfmk-softwire-unified-cpe-01.txt Thread-Index: Ac3eCfRsWwhMX0P8RHGCaxpNo029kgAADyKg Message-ID: <94C682931C08B048B7A8645303FDC9F36E9D4AEF1D@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Subject: [Softwires] draft-bfmk-softwire-unified-cpe-01.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: Wed, 19 Dec 2012 17:01:48 -0000 Dear all, This version integrates most of the comments we received in the mailing lis= t.=20 Please check if your comment has been integrated in this version. If not, p= lease let us know.=20 Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : mercredi 19 d=E9cembre 2012 17:57 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-bfmk-softwire-unified-cpe-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Unified IPv4-in-IPv6 Softwire CPE Author(s) : Mohamed Boucadair Ian Farrer Suresh Krishnan Filename : draft-bfmk-softwire-unified-cpe-01.txt Pages : 13 Date : 2012-12-19 Abstract: Transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity over IPv6-only provider networks. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo describes a specification whereby a single CPE can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4 in IPv6 services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe There's also a htmlized version available at: http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-bfmk-softwire-unified-cpe-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From prvs=698fdfcdd=B.Nagaraj@ril.com Mon Dec 24 02:33: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 6C63421F8860 for ; Mon, 24 Dec 2012 02:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUUblPkVoL5k for ; Mon, 24 Dec 2012 02:33:12 -0800 (PST) Received: from gwsmtp010.ril.com (unknown [203.199.41.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDE621F884F for ; Mon, 24 Dec 2012 02:33:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,346,1355077800"; d="scan'208";a="342178405" Received: from unknown (HELO outpostfix02.ril.com) ([10.66.8.169]) by gwsmtp010.ril.com with SMTP; 24 Dec 2012 16:03:06 +0530 Received: from SIDCEXHUB01.in.ril.com (sidcexhub01.in.ril.com [10.66.15.11]) by outpostfix02.ril.com (Postfix) with SMTP id 67F92A15840 for ; Mon, 24 Dec 2012 15:29:06 +0530 (IST) Received: from SIDCMBX01.in.ril.com ([10.66.15.21]) by SIDCEXHUB01.in.ril.com ([10.66.15.11]) with mapi; Mon, 24 Dec 2012 16:03:06 +0530 From: To: Date: Mon, 24 Dec 2012 16:03:04 +0530 Thread-Topic: Welcome to the "Softwires" mailing list Thread-Index: Ac3hweiQeC6ODxtdRsmPJWA5wLh2ZQAABntA Message-ID: <535880CE4DA34C46ACCE610DC45B9D4602CD72D8D7@SIDCMBX01.in.ril.com> References: In-Reply-To: Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-IN Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: [Softwires] FW: Welcome to the "Softwires" mailing list 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, 24 Dec 2012 10:35:16 -0000 With regards, = B.Nagaraj Cabin 3, 2A, 2nd floor, = RCP complex, = Thane Belapur Road Ghonsoli, Navi Mumbai-400701 Phone: = Work: +912244773047 Mobile: +919867564147 -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of softwires-request@ietf.org Sent: Monday, December 24, 2012 4:02 PM To: B Nagaraj Subject: Welcome to the "Softwires" mailing list Welcome to the Softwires@ietf.org mailing list! To post to this list, send your email to: softwires@ietf.org General information about the mailing list is at: https://www.ietf.org/mailman/listinfo/softwires If you ever want to unsubscribe or change your options (eg, switch to or fr= om digest mode, change your password, etc.), visit your subscription page a= t: https://www.ietf.org/mailman/options/softwires/b.nagaraj%40ril.com You can also make such adjustments via email by sending a message to: Softwires-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and= you will get back a message with instructions. You must know your password to change your options (including changing the = password, itself) or to unsubscribe. It is: radha1964 Normally, Mailman will remind you of your ietf.org mailing list passwords o= nce every month, although you can disable this if you prefer. This reminde= r will also include instructions on how to unsubscribe or change your accou= nt options. There is also a button on your options page that will email yo= ur current password to you. "Confidentiality Warning: This message and any attachments are intended onl= y for the use of the intended recipient(s). = are confidential and may be privileged. If you are not the intended recipie= nt. you are hereby notified that any = review. re-transmission. conversion to hard copy. copying. circulation or o= ther use of this message and any attachments is = strictly prohibited. If you are not the intended recipient. please notify t= he sender immediately by return email. = and delete this message and any attachments from your system. Virus Warning: Although the company has taken reasonable precautions to ens= ure no viruses are present in this email. = The company cannot accept responsibility for any loss or damage arising fro= m the use of this email or attachment." From tom.taylor.stds@gmail.com Mon Dec 24 05:41: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 92B1021F88F1 for ; Mon, 24 Dec 2012 05:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5EuXSN3QmtG for ; Mon, 24 Dec 2012 05:41:46 -0800 (PST) Received: from mail-ia0-f177.google.com (mail-ia0-f177.google.com [209.85.210.177]) by ietfa.amsl.com (Postfix) with ESMTP id CB28721F88D0 for ; Mon, 24 Dec 2012 05:41:45 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id u21so5753613ial.8 for ; Mon, 24 Dec 2012 05:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=/X+n+BCOfGX1nuVJiLxUfUwWG4AhZOFNcl4f25XQrhw=; b=dduQriaMHtHhWob8/W3ZtqbRSWrygeHWgA6MwcfFBePctj1XX81qEIC2vRDpQt98Rb vrPqXIrnvod85ztJnc+WOI154w2pIQR+hRJHV9PlmTvL5HV9FHOfhUloZ18vYhYzScGo KiRfp7xaTiIvJ7XSaX3SRwFO7gEoUVVrpD9h9qEfJy0RomP89UMg9Gn5ZmX6cuQ2YPgS JJMzxFXvB4qw8WpWueriGc3knv/Om3Iv+k/3hM8h1UJtZpHT80prgjowT4mtlKZ7b/dV mzw4kFUQ1JDsbTX6qV3kKgTFnIP1UUctCb7tKd2qPOAXdnUpAM69KWodMOg5/zgUbI6t ACfA== X-Received: by 10.50.190.163 with SMTP id gr3mr19568127igc.28.1356356500256; Mon, 24 Dec 2012 05:41:40 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-100-109.tor.primus.ca. [173.206.100.109]) by mx.google.com with ESMTPS id uj6sm16899805igb.4.2012.12.24.05.41.38 (version=SSLv3 cipher=OTHER); Mon, 24 Dec 2012 05:41:39 -0800 (PST) Message-ID: <50D85B92.7020704@gmail.com> Date: Mon, 24 Dec 2012 08:41:38 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Softwires , congxiao@cernet.edu.cn, ot@cisco.com, satoru.matsushima@g.softbank.co.jp, tetsuya@ipinfusion.com, wdec@cisco.com, xing@cernet.edu.cn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121224-0, 23/12/2012), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Presentation of the port mapping algorithm in draft-ietf-softwire-map-02.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: Mon, 24 Dec 2012 13:41:46 -0000 I think Section 5.1 of draft-ietf-softwire-map-02.txt, which presents the port mapping algorithm, can be improved a bit. Partly the problem is that a couple of symbols are not explained clearly enough. In addition, it would be helpful to the general reader to explain the underlying strategy represented by the formula before getting into the formula itself. I propose modified text below. Minor changes are marked with ^^^, while larger additions and deletions are delimited by .. and .. . Tom Taylor 5.1. Port mapping algorithm The port mapping algorithm is used in domains whose rules allow IPv4 address sharing. Different CEs indexed by Port-Set Identifier ^^^^^^^^^^^^^^ ^ (PSID) sharing the same external IPv4 address MUST have ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ non-overlapping port-sets. The two extreme cases are: (1) the port numbers are not contiguous for each PSID, but uniformly distributed across the port range (0-65535); (2) the port numbers are contiguous in a single range for each PSID. These two extremes can be encompassed by a single port allocation strategy as follows. The available range of port space is divided into a sequence of blocks of M*R consecutive values, where M is the maximum number of consecutive port values to be allocated to a given CE within a given block, and R is the number of CEs sharing each external IPv4 address. Each CE is then allocated a range of M bits within each successive block. The position of the CE's allocated range is determined by the value of its assigned PSID. The port mapping algorithm proposed here to implement that strategy is called the Generalized Modulus ^^^^^^^^^^^^^^^^^^^^^^^^^^ Algorithm (GMA). ^^^ For a given sharing ratio (R) and the maximum number of contiguous ports (M), the GMA algorithm is defined as: 1. The set of port numbers (P) allocated to a given PSID is ^^^^^^ ^ ^^^^^^^^^^^^ ^^ composed of: P = R * M * j + M * K + i P = (j * M*R) + (PSID * M) + i where j, PSID, and i are indexes with ranges given below. The first term of this formula points to the first port number in the j'th block of M*R bits. The second term points to the first port number in the range allocated to a given PSID within that block. Finally, the index i selects a specific port number within that range. Where: * PSID = 0 to R - 1 ^^ * Block index: j = (4096 / (M*R)) to ((65536 / (M*R)) - 1, ^^^^^ ^^^^^ ^^^^^ if the port numbers (0 - 4095) are excluded. If M and R are not powers of 2, the lower end of the range of j has to be rounded up and the upper end rounded down to avoid allocating port numbers outside the range 4096-65535. In that case, some port numbers at the ends of that range are not allocated (wasted). * Contiguous Port index: i = 0 to M - 1 2. The PSID (K) of a given port number (P) is determined by: K = (floor(P/M)) % R 2. Given a port number P, the corresponding PSID can be calculated as PSID = (floor(P / M)) % R Where: * % is the modulus operator * floor(arg) is a function that returns the largest integer not greater than arg. 5.1.1. Bit Representation of the Algorithm Given a sharing ratio (R=2^k) and a maximum number of contiguous ^^^^^ ports (M=2^m), for any PSID (K) and available ports (P) can be represented as: the binary representation of a given port number P partitions neatly into three fields, as shown in Figure 2 below. The rightmost m bits contain the value of the range index i. The middle k bits contain the value of the PSID. Finally, the leftmost a bits contain the block index j, where a is the number of bits required to represent the quantity A = (65536 / (M*R)) - 1 which is the upper bound of j. 0 8 15 +---------------+----------+------+-------------------+ | P | ----------------+-----------------+-------------------+ | A (j) | PSID | M (i) | ^^^^ +---------------+----------+------+-------------------+ |<----a bits--->|<-----k bits---->|<------m bits----->| Figure 2: Bit representation Where j and i are the same indexes defined in the port mapping algorithm. Thus for any port number P, the PSID can be obtained by bit mask ^^^^ ^ operation. For a > 0, j MUST be larger than 0. This ensures that the algorithm excludes the system ports ([I-D.ietf-tsvwg-iana-ports]). For a = 0, j MAY be 0 to allow for the provisioning of the system ports. From tom.taylor.stds@gmail.com Mon Dec 24 10:57:34 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 3F72521F87EA for ; Mon, 24 Dec 2012 10:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91tQjocK1Npn for ; Mon, 24 Dec 2012 10:57:33 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id B38BC21F87E3 for ; Mon, 24 Dec 2012 10:57:33 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id 17so9227797iea.16 for ; Mon, 24 Dec 2012 10:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=AXoUT3Fmj5iJBzcGAwlv39evQI+5qz07ZxX59Bf4d/4=; b=F1BDxM0Vi/ioBkFA48hm7sEr4qm30M2amWlrqbYzQ2h6FBemLi2+Ta/Y5o8DDdePHi nrNCx9vZThWzfw0/aWA9jKqpl1RQEV9M8fT9FPXqYbnxJL00hR4sDqrhMfpIG6u1EXmL WuBWTM1rsgDiicUYHJo+YlAxViGLied0ehGSUstmqYWs3dU8uBOY6wzIyHmNqUv29V3n JQIc71sl9vDpRlbH7GkT8s1MTcUk7atn38GLC1JPk5KRrV7kZ/aqIjgYObekPcUPtqkA fbsbBYqHm/uUO9fe323DTZKbSmLWA3b25tkpIv28Ia7DvCls5qeOOXNiK/8hMYl6AjCI JG1g== X-Received: by 10.42.51.142 with SMTP id e14mr18091847icg.2.1356375453350; Mon, 24 Dec 2012 10:57:33 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-100-109.tor.primus.ca. [173.206.100.109]) by mx.google.com with ESMTPS id i9sm22893083igl.9.2012.12.24.10.57.32 (version=SSLv3 cipher=OTHER); Mon, 24 Dec 2012 10:57:32 -0800 (PST) Message-ID: <50D8A59B.70603@gmail.com> Date: Mon, 24 Dec 2012 13:57:31 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121224-1, 24/12/2012), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] a=0 is outside the scope of the GMA in draft-ietf-softwire-map-02 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, 24 Dec 2012 18:57:34 -0000 I hate to raise an old topic, but based on the explanation in the text I proposed in my previous note, a is the number of bits required to represent the value 65536/(M*R) - 1. Even if this value comes out to zero (implying just one block and all ports for a given CE are in a single consecutive range), surely one bit is required to represent that value. Thus a=0 may be a possible partitioning of the binary representation of the port number P, but it falls outside the scope of the Generalized Modulus Algorithm. We are left with the choice of discarding the GMA as an explanation for the partitioning of P (leaving a simple procedural declaration in its place) or excluding a=0 from the set of possible values of a. Tom Taylor From pengwu.thu@gmail.com Tue Dec 25 16:33:06 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 B8A5521F8BD3 for ; Tue, 25 Dec 2012 16:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oatMS4BZbXrv for ; Tue, 25 Dec 2012 16:33:06 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE5321F8AD1 for ; Tue, 25 Dec 2012 16:33:05 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so7683576oag.17 for ; Tue, 25 Dec 2012 16:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/GJIn/lcfcfJcxkycGIg0KeUJbXTrxMXOXftTnLe/Og=; b=TEqNLCYeE5h7D9wnvtWiCJ0S1zSrbaOLE4yGw47FmFBK6fcQ47Y9peIRcK4T9fgP++ q7+6+NHZlu8KY/1lmc2WU+1xo/4idydmzWx+Kunk82AEB9YXkusuHLNtwlraLECZQ+6W vw9Ij6/8HfiiNKUWn+eYCgAjaFAtZ9mzBS1frlPNYS/RBdnhlq+V7nJvwIORiyiG1Pj0 uOCP6mfzy0MCxGjsD4R9yIsdY31Xn7stSVEi45TWV+Npp3k1iZY8cLTkY3ZSNAztPzDw HDZgKrpm/rhCm1v1uDCtwsxfrzYC1GoY/bkCkxv2fQRk0S9fFcG78TeH2AZiUZkG4l60 QGwA== MIME-Version: 1.0 Received: by 10.60.0.199 with SMTP id 7mr9758422oeg.139.1356481985543; Tue, 25 Dec 2012 16:33:05 -0800 (PST) Received: by 10.60.121.6 with HTTP; Tue, 25 Dec 2012 16:33:05 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E9D16E4C8@PUEXCB1B.nanterre.francetelecom.fr> References: <50CEA09E.8000204@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E9D16E4C8@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 26 Dec 2012 08:33:05 +0800 Message-ID: From: Peng Wu To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Second working group last call for draft-ietf-softwire-public-4over6-04 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, 26 Dec 2012 00:33:06 -0000 Hi Med, On Mon, Dec 17, 2012 at 4:54 PM, wrote: > The feature described in this draft can be easily integrated in the current unified CPE effort (binding mode: MAP1:1/Lw4over6) or the document needs to be extended to cover the port restriction feature. Comparing to address sharing transition mechanism, public 4over6 is easier to implement and is more compatible to current network. On the CE side, with public 4over6 there is no need to modify the DHCP(v4/v6) client to support port-set allocation. ALG related implementations are also not necessary. On the BR side, DHCP server doesn't have to adapt on how to maintain the IPv4 address + port-set pool. In general, there are much fewer modifications to the current network elements. On the other hand, with full IPv4 addresses assigned, public 4over6 CEs can running application servers freely, which is of great importance to the IPv6 transition for ICPs. As for regular users, upnp,nat-pmp service can be supported much better with public 4over6. Public 4over6 is simple and clean for ISPs, ICPs and end-users. We simply put the features they need in these cases and call it done. If we do it in the CPE draft and the port-set involved draft, we overloaded it with features they do not need at all. Cheers, Peng From wang.cui1@zte.com.cn Thu Dec 27 01:29:47 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 BA12D21F8414 for ; Thu, 27 Dec 2012 01:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.491 X-Spam-Level: X-Spam-Status: No, score=-90.491 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2LtD4GOk57G for ; Thu, 27 Dec 2012 01:29:44 -0800 (PST) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3C23021F8319 for ; Thu, 27 Dec 2012 01:29:42 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 4CBAC95EF5 for ; Thu, 27 Dec 2012 17:29:31 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 5BE21716890; Thu, 27 Dec 2012 17:18:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qBR9TFcX008033; Thu, 27 Dec 2012 17:29:15 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02AA2894A@US70UWXCHMBA05.zam.alcatel-lucent.com> To: "Poscic, Kristian (Kristian)" , Maoke , "Senthil Sivakumar (ssenthil)" MIME-Version: 1.0 X-KeepSent: 3654BA23:2BE26817-48257AE1:0031F105; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.cui1@zte.com.cn Date: Thu, 27 Dec 2012 17:29:14 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-27 17:29:11, Serialize complete at 2012-12-27 17:29:11 Content-Type: multipart/alternative; boundary="=_alternative 00341DE048257AE1_=" X-MAIL: mse02.zte.com.cn qBR9TFcX008033 Cc: "softwires@ietf.org" Subject: [Softwires] =?gb2312?b?tPC4tDogIE1BUC1FL1Qgb3ZlcmxhcGluZyByYW5n?= =?gb2312?b?ZXMgYW5kIGRvbWFpbnM=?= 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, 27 Dec 2012 09:29:47 -0000 This is a multipart message in MIME format. --=_alternative 00341DE048257AE1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGkgU2VudGloaWwgYW5kIE1hb2tlLA0KICBUaGluZ3MgY29tZSBhIGxpdHRsZSBjb25mdXNlZCwg bGV0IHVzIGNvbWUgdG8gdGhlIGZpcnN0IGVtYWlsIEtyaXMgaGFkIA0Kc2VudCBhbmQgSSBjdXQg c29tZSBkaXNjdXNzaW9uIGZyb20gYmVmb3JlIGVtYWlsczoNCg0KMSkgICAgICBEb2VzIE1BUCBz dXBwb3J0IHRoaXMgc2NlbmFyaW8gKGV4YW1wbGUpOg0KLSAgICAgICAgICAoQk1SKSBSdWxlIDE6 IA0KUnVsZSBJUHY2IFByZWZpeDogICAgICAgICAgICAgICAyMDAxOjovNDANClJ1bGUgSVB2NCBQ cmVmaXg6ICAgICAgICAgICAgICAgMTkyLjAuMi4wLzI0DQpSdWxlIEVBLWJpdHMgbGVuZ3RoOiAg ICAgICAgMTINCi0gICAgICAgICAgKEJNUikgUnVsZSAyOg0KUnVsZSBJUHY2IFByZWZpeDogICAg ICAgICAgICAgICAyMDAxOjovNDANClJ1bGUgSVB2NCBQcmVmaXg6ICAgICAgICAgICAgICAgMjAw LjAuMi4wLzI0DQpSdWxlIEVBLWJpdHMgbGVuZ3RoOiAgICAgICAgMTINCiANCkRpc2N1c3Npb24g ZnJvbSBiZWZvcmUgZW1haWxzOg0KICB3aGF0IGlzIHRoZSBjb25zZXF1ZW5jZSBpZiB0aGUgQ0Ug aGFzIHRoZSB0d28gcnVsZXM/DQpOT1RFIHRoZSBkZWxlZ2F0aW9uIGlzIGluZGVwZW5kZW50IG9m IHRoZSBJUHY0IGFkZHJlc3MgaW4gdXNlLiBmb3IgDQpleGFtcGxlLCB3ZSBoYXZlIDIwMDE6MDow MHh4OnkwMDA6Oi81MiBmb3IgdGhlIENFLCB3aGVyZSB4eCAoOCBiaXRzKSBpcyANCnRoZSBzYW1l IGFzIHRoZSBJUHY0IHN1ZmZpeCB3aGlsZSB5ICg0IGJpdHMpIGlzIGFwcGxpZWQgZm9yIHRoZSBQ U0lELiBpZiANCnRoZSBzb3VyY2UgYWRkcmVzcyBoYXMgYmVlbiBzZWxlY3RlZCBmcm9tIGVpdGhl ciBydWxlIGlwdjQgcHJlZml4LCB0aGVuIA0KdGhlIGVuY2Fwc3VsYXRpb24gb3IgdHJhbnNsYXRp b24gaXMgZGV0ZXJtaW5lZCBhbmQgdGhlIEJSIGNhbiBkZS1jYXBzdWxhdGUgDQpvciBkZS10cmFu c2xhdGUgdGhhdCB3aXRob3V0IGFueSBkaWZmaWN1bHR5IGJlY2F1c2UgdGhlIGZ1bGwgSVB2NCBh ZGRyZXNzIA0KaXMgZW1iZWRkZWQgaW4gdGhlIElJRCBwYXJ0LiB3aGVuIHRoZSByZXNwb25zZSBj b21lcywgdGhlIGRlc3RpbmF0aW9uIA0KYWRkcmVzcyBvZiB0aGUgSVB2NCBwYWNrZXQgaXMgYWxz byBkZXRlcm1pbmVkIHRob3VnaCB0aGV5IHdvdWxkIGJlIA0KZW5jYXBzdWxhdGVkIHdpdGggdGhl IHNhbWUgSVB2NiBwcmVmaXggKG5vdCB0aGUgc2FtZSBJUHY2IENFIGFkZHJlc3MhKS4gDQoNCltT ZW50aGlsMl0gSSBkb26hr3Qgc2VlIGFueSBpc3N1ZXMgd2l0aCBjb3JyZWN0bHkgDQpkZWNhcHN1 bGF0aW5nL3RyYW5zbGF0aW5nIHRoZSBwYWNrZXQgb24gdGhlIEJSIGZvciB2Ni0+djQuIFRoZSBp c3N1ZSBpcyANCndpdGggdGhlIHY0LT52Ni4gWW91IGNhbm5vdCBjb3JyZWN0bHkga25vdyB3aGlj aCBvZiB0aGUgdHdvIElQIGFkZHJlc3NlcyANCnRvIGVtYmVkLiBXaXRoIHRyYW5zbGF0aW9uLCB0 aGUgY29tbXVuaWNhdGlvbiB3aWxsIGRlZmluaXRlbHkgZmFpbCBpZiB5b3UgDQplbWJlZCB0aGUg d3JvbmcgSVAgYWRkcmVzcy4gDQoNCiAgICBbbWFva2UyXSBpIGNhbm5vdCBjYXRjaCB5b3VyIHBv aW50LiB5b3UgbWVhbiB2NC0+djYgYXQgQlIsIHJpZ2h0PyANCndoaWNoIElQdjQgYWRkcmVzcyB0 byBlbWJlZCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBzZXNzaW9uIGluaXRpYXRvci4gZm9yIA0KZXhh bXBsZSwgaWYgYSBob3N0IGJlaGluZCBDRSBtYWtlcyBhIGNvbm5lY3Rpb24gdG8gOC44LjguOCwg YW5kIGlmIHRoZSBDRSAgDQogICAgICAgICAgICAgaGFwcGVucyB0byBoYXZlIHBpY2tpbmcgdXAg MTkyLjAuMi4xOTEgYXMgdGhlIHNyYyBJUHY0IA0KYWRkcmVzcywgdGhlbiB0aGUgOC44LjguOCB3 aWxsIHJlc3BvbnNlIDE5Mi4wLjIuMTkxIGRlZmluaXRlbHkuIGkgZG9uJ3QgDQpzZWUgdGhhdCBC UiBuZWVkcyB0byBjaG9vc2UgYW4gSVB2NCBhZGRyZXNzIHRvIGVtYmVkOiB0aGUgZGVzdGluYXRp b24gDQphZGRyZXNzIGluIHRoZSBwYWNrZXQgcmVwbHlpbmcgdG8gdGhlIHNlc3Npb24gaW5pdGlh dG9yIGlzIGRldGVybWluZWQuIA0KDQpbTGluZGFdOiBJIHRoaW5rIE1hb2tlIGlzIHJpZ2h0LCBC UiBuZWVkbid0IHRvIGNob29zZSBhbiBJUHY0IGFkZHJlc3MgdG8gDQplbWJlZCBiZWNhdXNlIHRo ZSBJUHY0IGFkZHJlc3MgaXMgYWxyZWFkeSBpbiB0aGUgaW5ib3VuZCBwYWNrZXQncyANCmRlc3Rp bmF0aW9uIGFkZHJlc3MgZmllbGQuIA0KQlVUIHdoZW4gdGhlIGVuY2Fwc3VsYXRlZCBWNiBwYWNr ZXQgYXJyaXZlZCBhdCBDRSwgQ0UgZGUtY2Fwc3VsYXRlZCB0aGUgVjYgDQpwYWNrZXQgYW5kIHRo ZW4gY2hlY2sgdGhlIE5BVCBiaW5kaW5nIHRhYmxlIGFjY29yZGluZyB0byB0aGUgVjQgDQpkZXN0 aW5hdGlvbiBhZGRyZXNzIDE5Mi4wLjIuMTkxLCB0aGVuIHRyYW5zbGF0ZWQgMTkyLjAuMi4xOTEg dG8gDQpjb3JyZXNwb25kaW5nIFY0IGFkZHJlc3Mgb2YgdGhlIGhvc3QgYmVoaW5kIHRoaXMgQ0Ur UG9ydCwgYW5kIHRoZW4gZm9yd2FyZCANCnRoZSBWNCBwYWNrZXQgdG8gdGhlIGNvcnJlc3BvbmRp bmcgYXBwbGljYXRpb24gYXQgdGhlIGhvc3QuIEkgY2FuJ3QgZmluZCANCmFueSBpc3N1ZXMgYXQg Q0UuIEFtIGkgbWlzc3VuZGVyc3RhbmRpbmcgPw0KDQpBbmQgYmVjYXVzZSB0aGVyZSB3ZXJlIHR3 byBWNCBhZGRyZXNzIGJsb2NrIGF0IHRoaXMgQ0UsIGlmIG9uZSBWNCBhZGRyZXNzIA0KYmxvY2sg aGFkIG5vIFY0IGFkZHJlc3MgdG8gYWxsb2NhdGUgZm9yIG5ldyBzZXNzaW9ucywgdGhlbiBDRSBj b3VsZCB1c2UgDQphbm90aGVyIFY0IGFkZHJlc3MgYmxvY2sgdG8gY3JlYXRlIG5ldyBzZXNzaW9u cy4NClNvIEkgdGhpbmsgaWYgYSBNQVAgZG9tYWluIHN1cHBvcnRzIHNldmVyYWwgQk1ScyB3aXRo IHNhbWUgUnVsZWQgSVB2NiANCnByZWZpeCBhbmQgZGlmZmVyZW50IFJ1bGVkIElQdjQgcHJlZml4 IGlzIE9LLiAgSWYgSSBtaXN1bmRlcnN0YW5kIHBsZWFzZSANCnBvaW50IG91dCB3aXRob3V0IGhl c3RpdGFudC4gDQoNClRoYW5rcy4NCkxpbmRhDQoNCg0KDQoNCiJQb3NjaWMsIEtyaXN0aWFuIChL cmlzdGlhbikiIDxrcmlzdGlhbi5wb3NjaWNAYWxjYXRlbC1sdWNlbnQuY29tPiANCreivP7Iyzog IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnDQoyMDEyLTEyLTExIDA0OjA2DQoNCsrVvP7Iyw0K InNvZnR3aXJlc0BpZXRmLm9yZyIgPHNvZnR3aXJlc0BpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0K W1NvZnR3aXJlc10gTUFQLUUvVCBvdmVybGFwaW5nIHJhbmdlcyBhbmQgZG9tYWlucw0KDQoNCg0K DQoNCg0KQ2FuIHNvbWVvbmUgY2xhcmlmeSBhIGZldyB0aGluZ3MgZm9yIG1lOg0KIA0KMSkgICAg ICBEb2VzIE1BUCBzdXBwb3J0IHRoaXMgc2NlbmFyaW8gKGV4YW1wbGUpOg0KLSAgICAgICAgICAo Qk1SKSBSdWxlIDE6IA0KUnVsZSBJUHY2IFByZWZpeDogICAgICAgICAgICAgICAyMDAxOjovNDAN ClJ1bGUgSVB2NCBQcmVmaXg6ICAgICAgICAgICAgICAgMTkyLjAuMi4wLzI0DQpSdWxlIEVBLWJp dHMgbGVuZ3RoOiAgICAgICAgMTINCi0gICAgICAgICAgKEJNUikgUnVsZSAyOg0KUnVsZSBJUHY2 IFByZWZpeDogICAgICAgICAgICAgICAyMDAxOjovNDANClJ1bGUgSVB2NCBQcmVmaXg6ICAgICAg ICAgICAgICAgMjAwLjAuMi4wLzI0DQpSdWxlIEVBLWJpdHMgbGVuZ3RoOiAgICAgICAgMTINCiAN CiAgICAgICAgICAgICAgICBUaGUgb25seSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlc2UgdHdvIHJ1 bGVzIGFib3ZlIGlzIHRoZSANCqGuUnVsZSBJUHY0IFByZWZpeKGvLCBldmVyeXRoaW5nIGVsc2Ug aXMgdGhlIHNhbWUuIE15IG9idmlvdXMgYW5zd2VyIHdvdWxkIA0KYmUgdGhhdCB0aGlzIHNjZW5h cmlvIGlzIG5vdCBzdXBwb3J0ZWQgYnV0IHdhbnRlZCB0byBiZSBzdXJlIHRoYXQgSaGvbSBub3Qg DQptaXNzaW5nIGFueXRoaW5nLg0KVGhpcyBzY2VuYXJpbyBhYm92ZSB3b3VsZCByZXN1bHQgaW4g YW1iaWd1aXR5IGJldHdlZW4gQ0VzLCBpLmUuIGEgc2luZ2xlIA0KSUEtUEQgdGhhdCBpcyBkZWxl Z2F0ZWQgdG8gYSBDRSBjYW4gYmUgYXNzb2NpYXRlZCB3aXRoIGVpdGhlciBvZiB0aGUgdHdvIA0K cnVsZXMgYWJvdmUgKEVBIGJpdHMgY2FuIGJlIHRoZSBzYW1lIGZvciBhIENFIGZyb20gMTkyLjAu Mi4wLzI0IHJhbmdlIGFuZCANCmZvciAgYSBDRSBmcm9tIDIwMC4wLjIuMC8yNCByYW5nZS4NCklu IHRoaXMgZXhhbXBsZSBhYm92ZSwgaXQgaXMgYXNzdW1lZCB0aGF0IHRoZSBkZWxlZ2F0ZWQgcHJl Zml4IChJQS1QRCkgDQp0aGF0IERIQ1B2NiBTZXJ2ZXIgaXMgaGFuZGluZyBvdXQgdG8gQ0VzIGlz IDIwMDE6Oi80MCB3aXRoIGRlbGVnYXRlZCANCnByZWZpeCBsZW5ndGggLzU2Lg0KIA0KICAgICAg ICAgICAgICAgIFRoaXMgbWFrZXMgbWUgYmVsaWV2ZSB0aGF0IGVhY2ggcnVsZSBtdXN0IG5vdCBv bmx5IGJlIA0KdW5pcXVlIChiZWNhdXNlIHRoZSBhYm92ZSB0d28gcnVsZXMgYXJlIHVuaXF1ZSkg YnV0IGluc3RlYWQgZWFjaCBydWxlIG11c3QgDQpoYXZlIGEgdW5pcXVlICChrlJ1bGUgSVB2NiBw cmVmaXihryBhbmQgYSB1bmlxdWUgoa5SdWxlIElQdjQgUHJlZml4oa8gcGVyIA0Koa5SdWxlIElQ djYgcHJlZml4oa8gKElQdjQgdW5pcXVlbmVzcyBpcyBpbXBvcnRhbnQgaW4gdGhlIGRvd25zdHJl YW0gDQpkaXJlY3Rpb24gd2hlcmUgbG9va3VwIGlzIHBlcmZvcm1lZCBiYXNlZCBvbiBJUHY0KS4N CiANCjIpICAgICAgV2hhdCBjb25zdGl0dXRlcyBhIE1BUCBkb21haW4/IEmhr2QgdGhpbmsgYSB1 bmlxdWUgoa5SdWxlIElQdjYgDQpQcmVmaXihryB3aGljaCAgKGFzc3VtaW5nIHRoYXQgMSkgaXMg Y29ycmVjdCkgd291bGQgbWVhbiB0aGF0IGEgRG9tYWluID0gDQpCTVIuIEluIG90aGVyIHdvcmRz LCBjYW4gYSBNQVAgZG9tYWluIGNvbnRhaW4gYSBjb2xsZWN0aW9uIG9mIEJNUnM/IFRoZSANCmRy YWZ0cyBtZW50aW9uIHZpcnR1YWwtbGlua3MsIGV0Y6GtYnV0IGl0IHdvdWxkIGJlIHNpbXBsZXIg aWYgd2UgY2FuIHNheSANCkRvbWFpbj1CTVIgKG5vdCBzdXJlIGlmIHRoaXMgaXMgYWNjdXJhdGUg dGhvdWdoKS4gIE9mIGNvdXJzZSwgbm9kZXMgDQpzaGFyaW5nIHRoZSBzYW1lIHNldCBvZiB0aG9z ZSBydWxlcyB3b3VsZCBiZSBpbiB0aGUgc2FtZSBNQVAgZG9tYWluLg0KIA0KMykgICAgICBJcyBv dmVybGFwcGluZyBvZiChrlJ1bGUgSVB2NiBQcmVmaXhlc6GvIHN1cHBvcnRlZD8NCkZvciBleGFt cGxlIGluIHRoZSBhYm92ZSBjYXNlLCBjYW4gd2UgaGF2ZSBmb3IgUnVsZSAyKSB0aGUgoa5SdWxl IElQdjYgDQpwcmVmaXihryBhcyAyMDAxOjA6ODA6Oi80Mi4NCkluIHRoaXMgY2FzZSB0aGUgoa5S dWxlIElQdjYgUHJlZml4oa8gZnJvbSBSdWxlIDEgb3ZlcmxhcHMgd2l0aCChrlJ1bGUgDQpJUHY2 IFByZWZpeKGvIGZyb20gUnVsZSAyLiBJIGFzc3VtZSB0aGF0IHRoaXMgd291bGQgbm90IGJlIHN1 cHBvcnRlZCBmb3IgDQp0aGUgc2FtZSByZWFzb24gYXMgaW4gMSkuIEkgZGlkbqGvdCB0aGluayBh Ym91dCB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGlzIA0Kc2NlbmFyaW8gZm9yIG5vdywgaXQgaXMg bW9yZSBvZiBhIHRoZW9yZXRpY2FsIHF1ZXN0aW9uLg0KIA0KVGhhbmtzLA0KS3JpcyANCiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1h aWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KDQoNCg== --=_alternative 00341DE048257AE1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPmhpIFNlbnRpaGlsIGFuZCBNYW9rZSw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPiZuYnNwOyBUaGluZ3MgY29t ZSBhIGxpdHRsZSBjb25mdXNlZCwgbGV0DQp1cyBjb21lIHRvIHRoZSBmaXJzdCBlbWFpbCBLcmlz IGhhZCBzZW50IGFuZCBJIGN1dCBzb21lIGRpc2N1c3Npb24gZnJvbQ0KYmVmb3JlIGVtYWlsczo8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjEpICZuYnNwOyAm bmJzcDsgJm5ic3A7RG9lcyBNQVAgc3VwcG9ydA0KdGhpcyBzY2VuYXJpbyAoZXhhbXBsZSk6PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4tICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsoQk1SKQ0KUnVsZSAxOiAmbmJzcDsgPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5SdWxlIElQdjYgUHJlZml4OiAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIwMDE6Oi80MDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+UnVsZSBJUHY0IFByZWZpeDogJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxOTIuMC4yLjAvMjQ8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJ1bGUgRUEtYml0cyBsZW5ndGg6ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsxMjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ2FsaWJyaSI+LSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KEJNUikNClJ1 bGUgMjo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJ1bGUgSVB2NiBQ cmVmaXg6ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg MjAwMTo6LzQwPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5SdWxlIElQ djQgUHJlZml4OiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IDIwMC4wLjIuMC8yNDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ UnVsZSBFQS1iaXRzIGxlbmd0aDogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzEyPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPkRpc2N1c3Npb24g ZnJvbSBiZWZvcmUgZW1haWxzOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+d2hhdA0KaXMgdGhl IGNvbnNlcXVlbmNlIGlmIHRoZSBDRSBoYXMgdGhlIHR3byBydWxlcz88L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Tk9URSB0aGUgZGVsZWdhdGlvbiBpcyBpbmRlcGVuZGVu dCBvZiB0aGUNCklQdjQgYWRkcmVzcyBpbiB1c2UuIGZvciBleGFtcGxlLCB3ZSBoYXZlIDIwMDE6 MDowMHh4OnkwMDA6Oi81MiBmb3IgdGhlDQpDRSwgd2hlcmUgeHggKDggYml0cykgaXMgdGhlIHNh bWUgYXMgdGhlIElQdjQgc3VmZml4IHdoaWxlIHkgKDQgYml0cykgaXMNCmFwcGxpZWQgZm9yIHRo ZSBQU0lELiBpZiB0aGUgc291cmNlIGFkZHJlc3MgaGFzIGJlZW4gc2VsZWN0ZWQgZnJvbSBlaXRo ZXINCnJ1bGUgaXB2NCBwcmVmaXgsIHRoZW4gdGhlIGVuY2Fwc3VsYXRpb24gb3IgdHJhbnNsYXRp b24gaXMgZGV0ZXJtaW5lZCBhbmQNCnRoZSBCUiBjYW4gZGUtY2Fwc3VsYXRlIG9yIGRlLXRyYW5z bGF0ZSB0aGF0IHdpdGhvdXQgYW55IGRpZmZpY3VsdHkgYmVjYXVzZQ0KdGhlIGZ1bGwgSVB2NCBh ZGRyZXNzIGlzIGVtYmVkZGVkIGluIHRoZSBJSUQgcGFydC4gd2hlbiB0aGUgcmVzcG9uc2UgY29t ZXMsDQp0aGUgZGVzdGluYXRpb24gYWRkcmVzcyBvZiB0aGUgSVB2NCBwYWNrZXQgaXMgYWxzbyBk ZXRlcm1pbmVkIHRob3VnaCB0aGV5DQp3b3VsZCBiZSBlbmNhcHN1bGF0ZWQgd2l0aCB0aGUgc2Ft ZSBJUHY2IHByZWZpeCAobm90IHRoZSBzYW1lIElQdjYgQ0UgYWRkcmVzcyEpLg0KPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5bU2VudGhpbDJdIEkgZG9uoa90 IHNlZSBhbnkgaXNzdWVzIHdpdGgNCmNvcnJlY3RseSBkZWNhcHN1bGF0aW5nL3RyYW5zbGF0aW5n IHRoZSBwYWNrZXQgb24gdGhlIEJSIGZvciB2Ni0mZ3Q7djQuDQpUaGUgaXNzdWUgaXMgd2l0aCB0 aGUgdjQtJmd0O3Y2LiBZb3UgY2Fubm90IGNvcnJlY3RseSBrbm93IHdoaWNoIG9mIHRoZQ0KdHdv IElQIGFkZHJlc3NlcyB0byBlbWJlZC4gV2l0aCB0cmFuc2xhdGlvbiwgdGhlIGNvbW11bmljYXRp b24gd2lsbCBkZWZpbml0ZWx5DQpmYWlsIGlmIHlvdSBlbWJlZCB0aGUgd3JvbmcgSVAgYWRkcmVz cy4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsg Jm5ic3A7IFttYW9rZTJdIGkgY2Fubm90IGNhdGNoIHlvdXINCnBvaW50LiB5b3UgbWVhbiB2NC0m Z3Q7djYgYXQgQlIsIHJpZ2h0PyB3aGljaCBJUHY0IGFkZHJlc3MgdG8gZW1iZWQgaXMNCmRldGVy bWluZWQgYnkgdGhlIHNlc3Npb24gaW5pdGlhdG9yLiBmb3IgZXhhbXBsZSwgaWYgYSBob3N0IGJl aGluZCBDRSBtYWtlcw0KYSBjb25uZWN0aW9uIHRvIDguOC44LjgsIGFuZCBpZiB0aGUgQ0UgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7aGFwcGVucyB0byBoYXZlIHBpY2tpbmcgdXAgMTkyLjAuMi4xOTENCmFzIHRoZSBzcmMgSVB2 NCBhZGRyZXNzLCB0aGVuIHRoZSA4LjguOC44IHdpbGwgcmVzcG9uc2UgMTkyLjAuMi4xOTEgZGVm aW5pdGVseS4NCmkgZG9uJ3Qgc2VlIHRoYXQgQlIgbmVlZHMgdG8gY2hvb3NlIGFuIElQdjQgYWRk cmVzcyB0byBlbWJlZDogdGhlIGRlc3RpbmF0aW9uDQphZGRyZXNzIGluIHRoZSBwYWNrZXQgcmVw bHlpbmcgdG8gdGhlIHNlc3Npb24gaW5pdGlhdG9yIGlzIGRldGVybWluZWQuDQo8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNhbGlicmkiPltMaW5kYV06IEkgdGhpbmsgTWFv a2UgaXMgcmlnaHQsIEJSIG5lZWRuJ3QNCnRvIGNob29zZSBhbiBJUHY0IGFkZHJlc3MgdG8gZW1i ZWQgYmVjYXVzZSB0aGUgSVB2NCBhZGRyZXNzIGlzIGFscmVhZHkNCmluIHRoZSBpbmJvdW5kIHBh Y2tldCdzIGRlc3RpbmF0aW9uIGFkZHJlc3MgZmllbGQuIDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0iQ2FsaWJyaSI+QlVUIHdoZW4gdGhlIGVuY2Fwc3VsYXRlZCBWNiBwYWNrZXQgYXJy aXZlZA0KYXQgQ0UsIENFIGRlLWNhcHN1bGF0ZWQgdGhlIFY2IHBhY2tldCBhbmQgdGhlbiBjaGVj ayB0aGUgTkFUIGJpbmRpbmcgdGFibGUNCmFjY29yZGluZyB0byB0aGUgVjQgZGVzdGluYXRpb24g YWRkcmVzcyAxOTIuMC4yLjE5MSwgdGhlbiB0cmFuc2xhdGVkIDE5Mi4wLjIuMTkxDQp0byBjb3Jy ZXNwb25kaW5nIFY0IGFkZHJlc3Mgb2YgdGhlIGhvc3QgYmVoaW5kIHRoaXMgQ0UrUG9ydCwgYW5k IHRoZW4gZm9yd2FyZA0KdGhlIFY0IHBhY2tldCB0byB0aGUgY29ycmVzcG9uZGluZyBhcHBsaWNh dGlvbiBhdCB0aGUgaG9zdC4gSSBjYW4ndCBmaW5kDQphbnkgaXNzdWVzIGF0IENFLiBBbSBpIG1p c3N1bmRlcnN0YW5kaW5nID88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNh bGlicmkiPkFuZCBiZWNhdXNlIHRoZXJlIHdlcmUgdHdvIFY0IGFkZHJlc3MgYmxvY2sNCmF0IHRo aXMgQ0UsIGlmIG9uZSBWNCBhZGRyZXNzIGJsb2NrIGhhZCBubyBWNCBhZGRyZXNzIHRvIGFsbG9j YXRlIGZvciBuZXcNCnNlc3Npb25zLCB0aGVuIENFIGNvdWxkIHVzZSBhbm90aGVyIFY0IGFkZHJl c3MgYmxvY2sgdG8gY3JlYXRlIG5ldyBzZXNzaW9ucy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9IkNhbGlicmkiPlNvIEkgdGhpbmsgaWYgYSBNQVAgZG9tYWluIHN1cHBvcnRzIHNldmVy YWwNCkJNUnMgd2l0aCBzYW1lIFJ1bGVkIElQdjYgcHJlZml4IGFuZCBkaWZmZXJlbnQgUnVsZWQg SVB2NCBwcmVmaXggaXMgT0suDQombmJzcDtJZiBJIG1pc3VuZGVyc3RhbmQgcGxlYXNlIHBvaW50 IG91dCB3aXRob3V0IGhlc3RpdGFudC4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJDYWxpYnJpIj5UaGFua3MuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDYWxp YnJpIj5MaW5kYTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj4mcXVvdDtQb3NjaWMsIEtyaXN0aWFuDQooS3Jpc3RpYW4pJnF1b3Q7ICZs dDtrcmlzdGlhbi5wb3NjaWNAYWxjYXRlbC1sdWNlbnQuY29tJmd0OzwvYj4gPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3NvZnR3aXJlcy1i b3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PjIwMTItMTItMTEgMDQ6MDY8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7c29mdHdpcmVzQGlldGYub3JnJnF1b3Q7ICZsdDtzb2Z0 d2lyZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2 Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5bU29mdHdpcmVzXSBNQVAtRS9UIG92ZXJsYXBpbmcgcmFuZ2Vz DQphbmQgZG9tYWluczwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5DYW4gc29tZW9uZSBjbGFyaWZ5IGEgZmV3IHRoaW5n cyBmb3IgbWU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjEpICZuYnNwOyAmbmJzcDsg Jm5ic3A7RG9lcyBNQVAgc3VwcG9ydA0KdGhpcyBzY2VuYXJpbyAoZXhhbXBsZSk6PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4tICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsoQk1SKQ0KUnVsZSAxOiAmbmJzcDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj5SdWxlIElQdjYgUHJlZml4OiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIwMDE6Oi80MDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+UnVsZSBJUHY0IFByZWZpeDogJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAxOTIuMC4yLjAvMjQ8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJ1bGUgRUEtYml0cyBsZW5ndGg6ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsxMjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+LSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KEJNUikNClJ1bGUgMjo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJ1bGUgSVB2NiBQcmVmaXg6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMjAwMTo6 LzQwPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5SdWxlIElQdjQgUHJl Zml4OiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIw MC4wLjIuMC8yNDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+UnVsZSBF QS1iaXRzIGxlbmd0aDogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzEyPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7IFRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGVzZSB0d28g cnVsZXMgYWJvdmUgaXMgdGhlDQqhrlJ1bGUgSVB2NCBQcmVmaXihrywgZXZlcnl0aGluZyBlbHNl IGlzIHRoZSBzYW1lLiBNeSBvYnZpb3VzIGFuc3dlcg0Kd291bGQgYmUgdGhhdCB0aGlzIHNjZW5h cmlvIGlzIG5vdCBzdXBwb3J0ZWQgYnV0IHdhbnRlZCB0byBiZSBzdXJlIHRoYXQNCkmhr20gbm90 IG1pc3NpbmcgYW55dGhpbmcuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij5UaGlzIHNjZW5hcmlvIGFib3ZlIHdvdWxkIHJlc3VsdCBpbiBhbWJpZ3VpdHkNCmJldHdlZW4g Q0VzLCBpLmUuIGEgc2luZ2xlIElBLVBEIHRoYXQgaXMgZGVsZWdhdGVkIHRvIGEgQ0UgY2FuIGJl IGFzc29jaWF0ZWQNCndpdGggZWl0aGVyIG9mIHRoZSB0d28gJm5ic3A7cnVsZXMgYWJvdmUgKEVB IGJpdHMgY2FuIGJlIHRoZSBzYW1lIGZvciBhDQpDRSBmcm9tIDE5Mi4wLjIuMC8yNCByYW5nZSBh bmQgZm9yICZuYnNwO2EgQ0UgZnJvbSAyMDAuMC4yLjAvMjQgcmFuZ2UuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5JbiB0aGlzIGV4YW1wbGUgYWJvdmUsIGl0IGlzIGFz c3VtZWQgdGhhdA0KdGhlIGRlbGVnYXRlZCBwcmVmaXggKElBLVBEKSB0aGF0IERIQ1B2NiBTZXJ2 ZXIgaXMgaGFuZGluZyBvdXQgdG8gQ0VzIGlzDQoyMDAxOjovNDAgd2l0aCBkZWxlZ2F0ZWQgcHJl Zml4IGxlbmd0aCAvNTYuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4m bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7IFRoaXMgbWFrZXMg bWUgYmVsaWV2ZSB0aGF0IGVhY2ggcnVsZSBtdXN0IG5vdCBvbmx5IGJlIHVuaXF1ZQ0KKGJlY2F1 c2UgdGhlIGFib3ZlIHR3byBydWxlcyBhcmUgdW5pcXVlKSBidXQgaW5zdGVhZCBlYWNoIHJ1bGUg bXVzdCBoYXZlDQphIHVuaXF1ZSAmbmJzcDuhrlJ1bGUgSVB2NiBwcmVmaXihryBhbmQgYSB1bmlx dWUgoa5SdWxlIElQdjQgUHJlZml4oa8NCnBlciChrlJ1bGUgSVB2NiBwcmVmaXihryAoSVB2NCB1 bmlxdWVuZXNzIGlzIGltcG9ydGFudCBpbiB0aGUgZG93bnN0cmVhbQ0KZGlyZWN0aW9uIHdoZXJl IGxvb2t1cCBpcyBwZXJmb3JtZWQgYmFzZWQgb24gSVB2NCkuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPjIpICZuYnNwOyAmbmJzcDsgJm5ic3A7V2hhdCBjb25zdGl0dXRlcw0KYSBNQVAg ZG9tYWluPyBJoa9kIHRoaW5rIGEgdW5pcXVlIKGuUnVsZSBJUHY2IFByZWZpeKGvIHdoaWNoICZu YnNwOyhhc3N1bWluZw0KdGhhdCAxKSBpcyBjb3JyZWN0KSB3b3VsZCBtZWFuIHRoYXQgYSBEb21h aW4gPSBCTVIuIEluIG90aGVyIHdvcmRzLCBjYW4NCmEgTUFQIGRvbWFpbiBjb250YWluIGEgY29s bGVjdGlvbiBvZiBCTVJzPyBUaGUgZHJhZnRzIG1lbnRpb24gdmlydHVhbC1saW5rcywNCmV0Y6Gt YnV0IGl0IHdvdWxkIGJlIHNpbXBsZXIgaWYgd2UgY2FuIHNheSBEb21haW49Qk1SIChub3Qgc3Vy ZSBpZiB0aGlzDQppcyBhY2N1cmF0ZSB0aG91Z2gpLiAmbmJzcDtPZiBjb3Vyc2UsIG5vZGVzIHNo YXJpbmcgdGhlIHNhbWUgc2V0IG9mIHRob3NlDQpydWxlcyB3b3VsZCBiZSBpbiB0aGUgc2FtZSBN QVAgZG9tYWluLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4zKSAmbmJzcDsgJm5ic3A7 ICZuYnNwO0lzIG92ZXJsYXBwaW5nIG9mDQqhrlJ1bGUgSVB2NiBQcmVmaXhlc6GvIHN1cHBvcnRl ZD88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkZvciBleGFtcGxlIGlu IHRoZSBhYm92ZSBjYXNlLCBjYW4gd2UgaGF2ZQ0KZm9yIFJ1bGUgMikgdGhlIKGuUnVsZSBJUHY2 IHByZWZpeKGvIGFzIDIwMDE6MDo4MDo6LzQyLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ2FsaWJyaSI+SW4gdGhpcyBjYXNlIHRoZSChrlJ1bGUgSVB2NiBQcmVmaXihrw0KZnJvbSBS dWxlIDEgb3ZlcmxhcHMgd2l0aCChrlJ1bGUgSVB2NiBQcmVmaXihryBmcm9tIFJ1bGUgMi4gSSBh c3N1bWUNCnRoYXQgdGhpcyB3b3VsZCBub3QgYmUgc3VwcG9ydGVkIGZvciB0aGUgc2FtZSByZWFz b24gYXMgaW4gMSkuIEkgZGlkbqGvdA0KdGhpbmsgYWJvdXQgdGhlIGFwcGxpY2FiaWxpdHkgb2Yg dGhpcyBzY2VuYXJpbyBmb3Igbm93LCBpdCBpcyBtb3JlIG9mIGENCnRoZW9yZXRpY2FsIHF1ZXN0 aW9uLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UaGFua3MsPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5LcmlzIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTb2Z0d2lyZXMgbWFpbGlu ZyBsaXN0PGJyPg0KU29mdHdpcmVzQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXM8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 00341DE048257AE1_=-- From damien.saucez@gmail.com Sun Dec 30 12:45:17 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 ED8B721F855A; Sun, 30 Dec 2012 12:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TBhXF6UEbJw; Sun, 30 Dec 2012 12:45:16 -0800 (PST) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) by ietfa.amsl.com (Postfix) with ESMTP id ED4D921F8558; Sun, 30 Dec 2012 12:45:12 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id z2so5641569wey.32 for ; Sun, 30 Dec 2012 12:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=MwLjU9i7XROJzrbNZNYiIHjd7YvbOW8WMcXyE/ze4sk=; b=npmdov2LZ5hXELEQZGMN2yVZuCkkQT9DdFuDHaONiB1jx6e3CNn544dsQuMDg+6WJK NIWFSnvj2wbTAsj8KNBGCScGH4ExX6BSDkJ+j4+3DZmpaq5gaZYumO2x+UwKEutBXDQq fl3Uwh/elaAxZq/RZmQO8DbJjDagQ68KYU9/a7T3eCPitpJhwsQrUR2AHgyPilsYlU6C lyzcj52YuKcbBcKbim28MrpnEVWAV18/Ir/ytTU29xUZ0kLFrFo5tskeO2hHbcXTBGA8 W1Img+QyKrDeEqmtGJRnZJCPTP/VG7RI86nECQgAcrwH2BOCpiGhbzDR98GzTUzes1YI BPNg== X-Received: by 10.180.109.195 with SMTP id hu3mr52180372wib.31.1356900312248; Sun, 30 Dec 2012 12:45:12 -0800 (PST) Received: from [172.16.139.253] (44.189.101.84.rev.sfr.net. [84.101.189.44]) by mx.google.com with ESMTPS id hg17sm72626675wib.1.2012.12.30.12.45.10 (version=SSLv3 cipher=OTHER); Sun, 30 Dec 2012 12:45:11 -0800 (PST) From: Damien Saucez Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 30 Dec 2012 21:45:09 +0100 Message-Id: <0A534525-59E1-418E-826B-177655767B17@gmail.com> To: draft-xu-softwire-ip-in-udp@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: Softwires@ietf.org, LISP mailing list list Subject: [Softwires] draft-xu-softwire-ip-in-udp 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, 30 Dec 2012 20:45:17 -0000 Hello, Interesting document, have you ever though of LISP to do that? Regards, Damien Saucez From tom.taylor.stds@gmail.com Sun Dec 30 14:05:58 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 DB88F21F8ABD for ; Sun, 30 Dec 2012 14:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z02RSIX-V3E5 for ; Sun, 30 Dec 2012 14:05:58 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id ACB5321F8AB0 for ; Sun, 30 Dec 2012 14:05:46 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id 16so14636882iea.12 for ; Sun, 30 Dec 2012 14:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=9c4gDoSek70VnEN0VFF0QgZEoCXNCKCOQZAXEevWtwU=; b=w6H7koIyexjlOS/TCQgnZSbpuqZSPfoJp6WI0XTWaIYbYxHtVrM2MSIRYxhSF66K7e B9wHH7lMCPMAEIRXYO+OWty2Z2H0PbXw1xwZMc5/opa4mtD83CIb490Qm/veL8SKUQBJ wHHjo5O4LlPKrdRFys5NBsIniq16GvpUeeDTsg8ue9glRDMhXq7Fn+rFMoX0Jw8mppc4 7aNPaJk7jZEcPPSJ9zDHUK3NIQbRbIUGKwtQrbhpbdWE3oeCDnuxriIM8gDphMBhHSwo h3pQ/+Dg4z40I+MBmQS1rJ4Q9oNAAZBBALPJya8hRzSdXJa6PSvJBkJmgvY7eUl+pYbg aC8g== X-Received: by 10.50.76.195 with SMTP id m3mr35479933igw.64.1356905145827; Sun, 30 Dec 2012 14:05:45 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-100-109.tor.primus.ca. [173.206.100.109]) by mx.google.com with ESMTPS id 10sm36083296ign.5.2012.12.30.14.05.44 (version=SSLv3 cipher=OTHER); Sun, 30 Dec 2012 14:05:45 -0800 (PST) Message-ID: <50E0BAB8.5050601@gmail.com> Date: Sun, 30 Dec 2012 17:05:44 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Softwires References: <50D8A59B.70603@gmail.com> In-Reply-To: <50D8A59B.70603@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121230-0, 30/12/2012), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Reconsideration: Re: a=0 is outside the scope of the GMA in draft-ietf-softwire-map-02 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, 30 Dec 2012 22:05:59 -0000 On thinking it over some more, I realize that a=0 is a valid outcome of the GMA. It represents the case of a single block where in which all of the ports for each CE are consecutive. The text should note this. I will make specific text suggestions in a more extensive E-mail once I deal with the individual issues I see in the draft. On 24/12/2012 1:57 PM, Tom Taylor wrote: > I hate to raise an old topic, but based on the explanation in the text I > proposed in my previous note, a is the number of bits required to > represent the value 65536/(M*R) - 1. Even if this value comes out to > zero (implying just one block and all ports for a given CE are in a > single consecutive range), surely one bit is required to represent that > value. Thus a=0 may be a possible partitioning of the binary > representation of the port number P, but it falls outside the scope of > the Generalized Modulus Algorithm. > > We are left with the choice of discarding the GMA as an explanation for > the partitioning of P (leaving a simple procedural declaration in its > place) or excluding a=0 from the set of possible values of a. > > Tom Taylor From bingxuere@gmail.com Sun Dec 30 19:41:25 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 A956221F8B65 for ; Sun, 30 Dec 2012 19:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.256 X-Spam-Level: X-Spam-Status: No, score=-3.256 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN-KiBwajKzS for ; Sun, 30 Dec 2012 19:41:24 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id B39D721F8B64 for ; Sun, 30 Dec 2012 19:41:21 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id qd14so14725908ieb.34 for ; Sun, 30 Dec 2012 19:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UeH2zER6LfO/wy/NzmYTZzC1t0M34DMEtAX2JTNafRM=; b=cyVMRqa7rFLmsVsgRuGprjAc4sLr0xf6ZYJsolx8AK34LbR0ym7/ctWzrJtyV1e163 NEsWEE9DF6ZQuFjRuIYkLWorduKZxHhZ0p9w9zQuQ1LphJ4+wWdWmhbIaLgaErbXQGlI 2ehv/hdSggn+1bEykshcv9ry6HXB49PEfVRl1cE0dVB3u3shpL3bGYDAdK07PqO57dnp N7GrXMP6tVYosG0PwFgN3iaLPnCVzHmQsUY9f6l+p57HKaxn/yU96vi4wyEGMSKAvvNY XTFnw4w+dmoP8SHRF/1V53II/z4iSfAnbMGWLWMCuhfT2DCCecZcYma8hUI+8zjzDUX9 sY6Q== Received: by 10.50.161.130 with SMTP id xs2mr35332901igb.34.1356925281273; Sun, 30 Dec 2012 19:41:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.76.200 with HTTP; Sun, 30 Dec 2012 19:40:41 -0800 (PST) In-Reply-To: <50CEA09E.8000204@ericsson.com> References: <50CEA09E.8000204@ericsson.com> From: Qiong Date: Mon, 31 Dec 2012 11:40:41 +0800 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=14dae934106d60875e04d21dc96d Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Second working group last call for draft-ietf-softwire-public-4over6-04 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, 31 Dec 2012 03:41:25 -0000 --14dae934106d60875e04d21dc96d Content-Type: text/plain; charset=UTF-8 Dear Suresh, I support this document to move forward. This version has solved all the technical issues, and it is quite simple for some specific use case. I think it is ready to move forward :) Merry Christmas and Happy new year ! Qiong On Mon, Dec 17, 2012 at 12:33 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi all, > This message starts a second softwire working group last call on > advancing the draft about providing Public IPv4 over IPv6 Access Network > as a Standards Track RFC. The authors believe that this version has > addressed the issues raised during the previous WGLC. The draft > is available at > > http://www.ietf.org/id/draft-ietf-softwire-public-4over6-04.txt > http://tools.ietf.org/html/draft-ietf-softwire-public-4over6-04 > > Substantive comments and statements of support/opposition for advancing > this document should be directed to the mailing list. Editorial > suggestions can be sent directly to the authors. The chairs will send in > their comments as well during the last call period. This last call will > conclude on January 4, 2013. > > Regards, > Suresh & Yong > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --14dae934106d60875e04d21dc96d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Suresh,

I support this do= cument to move forward. This version has solved all the technical issues, a= nd it is quite simple for some specific use case. I think it is ready to mo= ve forward :)

Merry Christmas and Happy new year !

Qiong
=


On Mon, Dec 1= 7, 2012 at 12:33 PM, Suresh Krishnan <suresh.krishnan@ericsson.= com> wrote:
Hi all,
=C2=A0 This message starts a second softwire working group last call on
advancing the draft about providing Public IPv4 over IPv6 Access Network as a Standards Track RFC. The authors believe that this version has
addressed the issues raised during the previous WGLC. The draft
is available at

http://www.ietf.org/id/draft-ietf-softwire-public-4over6= -04.txt
http://tools.ietf.org/html/draft-ietf-softwire-public-4o= ver6-04

Substantive comments and statements of support/opposition for advancing
this document should be directed to the mailing list. Editorial
suggestions can be sent directly to the authors. The chairs will send in their comments as well during the last call period. This last call will
conclude on January 4, 2013.

Regards,
Suresh & Yong

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



--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Be= ijing Research Institude


Open source code:
lightweight 4over6= : h= ttp://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--14dae934106d60875e04d21dc96d-- From tom.taylor.stds@gmail.com Mon Dec 31 15:44:47 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 1CA6C21F8961 for ; Mon, 31 Dec 2012 15:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-Aj98vIAqmK for ; Mon, 31 Dec 2012 15:44:46 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id 560DD21F8962 for ; Mon, 31 Dec 2012 15:44:46 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id 13so15413818iea.35 for ; Mon, 31 Dec 2012 15:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=Vbt0DEkDggQskmLd91qmQSNwrXX1Wm7ypYgxa1MMxy4=; b=iOg7X/dR3Tfl9+/XkNVZHG4UVMvEfoH5A1M8Cs6huV28jO6ClYc+CsJr93WJh0CSn6 vQQcPbiRsVix+8pZuKkzjFfU9smLv/fSURDTp4ZwhkUj5bEZR7MUijNlm6hFt6chsSce pZJswrxWy0oPdk450kfuDzCILZ7BRViPsQOvYfsGDRj79QoLRaqaFrbcu6HGerGJKC7Z QedjjRdHQCC02Ya4BUGkYXbEzPH6xk9dIrVY8zvKOJj5GIH2BzCI2R+I4JS7aAb5Rzmy ctUViFAeBEW7Iizd5CspK9vj5Jh0UeKZHrXKHRBIOnVYe+DwLcVVnaQwIreB4SIpVeIU EZZA== X-Received: by 10.43.69.206 with SMTP id yd14mr32003844icb.57.1356997472691; Mon, 31 Dec 2012 15:44:32 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-100-109.tor.primus.ca. [173.206.100.109]) by mx.google.com with ESMTPS id c3sm38746607igj.1.2012.12.31.15.44.31 (version=SSLv3 cipher=OTHER); Mon, 31 Dec 2012 15:44:31 -0800 (PST) Message-ID: <50E2235E.8080601@gmail.com> Date: Mon, 31 Dec 2012 18:44:30 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121231-1, 31/12/2012), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Excluded ports in draft-ietf-softwire-map-02 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, 31 Dec 2012 23:44:47 -0000 draft-ietf-softwire-map-02 mentions excluded ports in several places: Section 5.1: talks about excluding ports 0-4095. The reason for choosing that limit is not given at that point. Further discussion below. Section 5.1.1 says: For a > 0, j MUST be larger than 0. This ensures that the algorithm excludes the system ports ([I-D.ietf-tsvwg-iana-ports]). For a = 0, j MAY be 0 to allow for the provisioning of the system ports. There is no basis for these statements. The actual requirement to ensure exclusion of the system ports is that (j * the block size M*R) is 1024 or greater for some j in the range 1 .. (2^a - 1). This is always satisfied for block sizes up to 32768. However, for block sizes less than 1024, exclusion of the system ports requires that j be restricted to values 1024/(M*R) or higher. BTW, a block size less than 1024 fits into 10 bits or less, implying a >= 6. With regard to the second statement, it's not clear why system ports can be allocated if there is only a single block (a = 0) and not in any other case. In fact, if there is a single block, the result of allowing system ports to be allocated is that they would all go to one or a few CEs with the lowest values of PSID. This is illustrated in the last example of Section 5.1.2. In fact, in the single block case, to exclude system ports one would exclude the lower values of PSID. Section 5.1.3 says: To simplify the GMA port mapping algorithm the defaults are chosen so that the PSID field starts on a nibble boundary and the excluded port range (0-1023) is extended to 0-4095. Now we see the origin of that number 4096 in Section 5.1. However, the effect of extending the excluded port range, following the reasoning above, is that for block sizes less than 4096, the minimum value of j is 4096/(M*R). This requires a to be at least 4. The defaults imply a block size of 4096 and a minimum j value of 1, giving 15 usable blocks in the range 4096-65536. The parameters identified in Section 5.1.3 are incomplete. They are enough to derive the block size M*R and the beginning value of j, but not the individual parameters M (maximum consecutive ports per CE) and R (number of CEs sharing the same IP address). Without those parameters the complete set of port numbers allocated to a given CE cannot be calculated. Note that the examples specify R. Recommendations =============== Based on the above analysis, I propose the following: 1) When defining the limits for j in section 5.1, use a value of E (for lowest permitted port value) in place of 4096. Mention that in the case of a single block (M*R >= 32768), j can only have the value zero and to exclude port numbers below E one instead excludes PSID values from 0 to ceil(E/M) - 1. 2) Delete the paragraph cited in Section 5.1.1. 3) Modify the text in Section 5.1.3 as follows: ... o Offset bits (a) : 4, implying a block size of 4096. This combination of defaults simplifies the GMA port mapping algorithm by ensuring that the PSID high-order bit lies on a nibble boundary and making the lower limit on the index j equal to 1. Also add the parameter R (say) to the set of provisioned values, with a suitable default.