From gnocuil@gmail.com Fri Nov 1 00:40:38 2013 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 3EC4311E80FB for ; Fri, 1 Nov 2013 00:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7j5-4AtPsXDi for ; Fri, 1 Nov 2013 00:40:37 -0700 (PDT) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8315921F9994 for ; Fri, 1 Nov 2013 00:40:37 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id q19so2397879qeb.38 for ; Fri, 01 Nov 2013 00:40:37 -0700 (PDT) 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=qsqYmlnohBZFcfgD1X72Wi+Zpn0qkc0bxoaeg4tLwLc=; b=if35g8uUzDvuwL8lvNN5Q6egW79pF/HeOXYEj1zfC2+iO/jgwT9VNGhsMCqgbI0Z+V XnD9pEPfucuJJ2aJSG8O84nB5NdV0Q83SyK2QO52jR9WRBu48E4uedHJGgwCtHX5BNl4 vTVnc94RofFHjSx2ZvGS08zTw5tFoVBOkKysqCyH7yXqA1F81TiVhTShD1i6EqItrXLd 7p3n/yVUoSRjnIO+z0nn5LXXxew3tmvpbilIqTHvSoHgGvKeqtdskQcvB7/mEZyecfvm w0sKwOzqfVRInasi2ihxwGuib7cI2US2lP96CWZlOWZWEXDmacHkCfsxA4iV8cXA8ztM vtaA== X-Received: by 10.49.129.65 with SMTP id nu1mr2119344qeb.50.1383291636911; Fri, 01 Nov 2013 00:40:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.185.33 with HTTP; Fri, 1 Nov 2013 00:40:16 -0700 (PDT) In-Reply-To: References: <060.522e9001bcb47e4a09fed369a8090c45@tools.ietf.org> From: Cong Liu Date: Fri, 1 Nov 2013 15:40:16 +0800 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=047d7b678198a393ba04ea18ae54 Cc: softwires , draft-ietf-softwire-map-dhcp@tools.ietf.org Subject: Re: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e 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, 01 Nov 2013 07:40:38 -0000 --047d7b678198a393ba04ea18ae54 Content-Type: text/plain; charset=ISO-8859-1 Hi Ole, 2013/10/30 Ole Troan > which documents describe these features? > > I've read https://tools.ietf.org/html/draft-ietf-softwire-lw4over6-01combined with how LW46 is proposed to be provisioned in MAP DHCP. I'm > clearly missing some text somewhere. > The features are described in lw4o6-base https://tools.ietf.org/html/draft-ietf-softwire-lw4over6-01: About binding table: In section 1, "Lightweight 4over6 features keeping per-subscriber state in the service provider's network." In section 3, "An lwAFTR is an IPv4-in-IPv6 tunnel endpoint which maintains per-subscriber address binding only and does not perform a NAPT44 function." In section 4, "The lwAFTR needs to know the binding between ... Note that this is per-subscriber state as opposed to per-flow state in the regular AFTR case." About dynamic IPv4 provisioning: In section 5.1, "An lwB4 MUST support dynamic port-restricted IPv4 address provisioning ..." In section 7, "There are several dynamically provisioning protocols for IPv4 address and port set ..." Best Regards, Cong --047d7b678198a393ba04ea18ae54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ole,

2013/10/30 Ole Troan <ot@cisco.com>
which documents describe these features?

I've read https://tools.ietf.org/html/draft-ietf-softwir= e-lw4over6-01 combined with how LW46 is proposed to be provisioned in M= AP DHCP. I'm clearly missing some text somewhere.
=A0
The features are described in lw4o6-base=A0= https://tools.ietf.org/html/draft-ietf-softwire-lw4over6-01:
About binding ta= ble:
In sec= tion 1, "Lightweight 4over6 features keeping per-subscriber state in t= he service provider's network."
In section= 3, "An lwAFTR is an IPv4-in-IPv6 tunnel endpoint which maintains per-= subscriber address binding only and does not perform a NAPT44 function.&quo= t;
In section 4, &q= uot;The lwAFTR needs to know the binding between ... Note that this is per-= subscriber state as opposed to per-flow state in the regular AFTR case.&quo= t;

About dynamic IPv4 pro= visioning:
= In section 5.1, "An lwB4 MUST support dy= namic port-restricted IPv4 address=A0p= rovisioning ..."
In section 7, &q= uot;There are several dynamically provisionin= g protocols for IPv4 address=A0and por= t set ..."=A0

Best Regards,
Cong
--047d7b678198a393ba04ea18ae54-- From gnocuil@gmail.com Fri Nov 1 02:12:06 2013 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 7A82611E8119 for ; Fri, 1 Nov 2013 02:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdKb1tB6u3on for ; Fri, 1 Nov 2013 02:12:06 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFFE11E8127 for ; Fri, 1 Nov 2013 02:12:02 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id k15so471074qaq.5 for ; Fri, 01 Nov 2013 02:12:02 -0700 (PDT) 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=ef5cpw5slX3/5rzrhWpNw+Bj3n4vcq4syEomzryoGh4=; b=SRkuaMHUUDoYluKhzBuyWW/VRn93VqQ18ycTAN/6bBdMlFj9+g9+QMm3K73DmSTE7j dewGj0hjspAdYn2T8lw2Iw91AKknYXyRtnPkegpnwfVX0WiAJyXgrs7z0FfglncDINbf SPwewY2SMMqnYSMnrBaf9xnmzDrCJ7NVejClIpFGMbCDT9igF0IwVYks5BGwt0Sw1bsV eMuzgtPWpMB79IQyea95kTAzBMSV+o5pphPU5Gju38HmegP1LTvmYcem4sOrAViAvh1g 5c9xKhQE24g4EoYpsapbb5TsOMV5T8SMV4WE6vNmW8ny8AqoACl20XLLgiiiKyVnz5vn ZPFg== X-Received: by 10.224.167.147 with SMTP id q19mr560790qay.119.1383297121925; Fri, 01 Nov 2013 02:12:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.185.33 with HTTP; Fri, 1 Nov 2013 02:11:41 -0700 (PDT) In-Reply-To: <360A36EE-1369-4235-849F-CEA38FAECAE3@employees.org> References: <060.6dbd5be52b65a0ac9dd85f78f8b56c74@tools.ietf.org> <360A36EE-1369-4235-849F-CEA38FAECAE3@employees.org> From: Cong Liu Date: Fri, 1 Nov 2013 17:11:41 +0800 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=089e0149cc8892401104ea19f5b2 Cc: softwires Subject: Re: [Softwires] [softwire] #28: Dealing with DHCPv4-over-DHCPv6 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, 01 Nov 2013 09:12:06 -0000 --089e0149cc8892401104ea19f5b2 Content-Type: text/plain; charset=ISO-8859-1 Dear Ole, 2013/10/30 Ole Troan > MAP is incompatible with dynamic IPv4 address assignment using DHCPv4. > Yes, dynamic IPv4 address assignment is only used by lw4o6. But OPTION_S46_IPV4ADDRESS in map-dhcp-05 is also proposed for only lw4o6, so I think it's not a problem to have a discussion of dynamic IPv4 provisioning. > either you can consider MAP DHCP as the building block used by a separate > document describing the > DHCPv4 address assignment case. or we can split out LW46 provisioning from > MAP DHCP altogether. > I think the key problem here is the scope of the document: whether "softwire-dhcp" discussing both static and dynamic IPv4 provisioning, or "stateless-softwire-dhcp" discussing only static provisioning. I'm just suggesting "softwire-dhcp" solution. Best Regards, Cong --089e0149cc8892401104ea19f5b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Ole,

2013/10/30 Ole Troan <otroan@employees.org>=
MAP is incompatible w= ith dynamic IPv4 address assignment using DHCPv4.
=

Yes, dynamic IPv4 address assignment is only used = by lw4o6. But=A0OPTION_S46_I= PV4ADDRESS in map-dhcp-05 is also proposed for only lw4o6,
so I think it's not= a problem to have a discussion of dynamic IPv4 provisioning.
<= div>=A0
either you can consid= er MAP DHCP as the building block used by a separate document describing th= e
DHCPv4 address assignment case. or we can split out LW46 provisioning from = MAP DHCP altogether.

I think the = key problem here is the scope of the document: whether "softwire-dhcp&= quot; discussing both static and dynamic IPv4 provisioning,
or "stateless-softwire-dhcp" discussing only static pr= ovisioning. I'm just suggesting "softwire-dhcp" solution.

Best Regards,
Cong
--089e0149cc8892401104ea19f5b2-- From otroan@employees.org Fri Nov 1 04:28:01 2013 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 CD7A611E829F for ; Fri, 1 Nov 2013 04:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDcKhxFxb4TO for ; Fri, 1 Nov 2013 04:27:56 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A0BC511E819E for ; Fri, 1 Nov 2013 04:27:50 -0700 (PDT) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJWPc1KQ/khR/2dsb2JhbABZgwfAbIEeFnSCJQEBBAF5BQsLDjhXBhMbh2YGvS6PWAeDIIEOA5AumWWDJzs X-IronPort-AV: E=Sophos;i="4.93,616,1378857600"; d="asc'?scan'208";a="87832423" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 01 Nov 2013 11:27:49 +0000 Received: from dhcp-10-61-107-140.cisco.com (dhcp-10-61-107-140.cisco.com [10.61.107.140]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA1BRjXX029729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Nov 2013 11:27:45 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_21F106BA-A58A-44AB-8E93-E9876C74EDF8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: Date: Fri, 1 Nov 2013 12:27:44 +0100 Message-Id: <57AE1075-0596-43E5-9812-0F1F2DEFF3FB@employees.org> References: <060.6dbd5be52b65a0ac9dd85f78f8b56c74@tools.ietf.org> <360A36EE-1369-4235-849F-CEA38FAECAE3@employees.org> To: Cong Liu X-Mailer: Apple Mail (2.1816) Cc: softwires Subject: Re: [Softwires] [softwire] #28: Dealing with DHCPv4-over-DHCPv6 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, 01 Nov 2013 11:28:01 -0000 --Apple-Mail=_21F106BA-A58A-44AB-8E93-E9876C74EDF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > 2013/10/30 Ole Troan > MAP is incompatible with dynamic IPv4 address assignment using DHCPv4. >=20 > Yes, dynamic IPv4 address assignment is only used by lw4o6. But = OPTION_S46_IPV4ADDRESS in map-dhcp-05 is also proposed for only lw4o6, > so I think it's not a problem to have a discussion of dynamic IPv4 = provisioning. > =20 > either you can consider MAP DHCP as the building block used by a = separate document describing the > DHCPv4 address assignment case. or we can split out LW46 provisioning = from MAP DHCP altogether. >=20 > I think the key problem here is the scope of the document: whether = "softwire-dhcp" discussing both static and dynamic IPv4 provisioning, to nitpick, MAP DHCP is also dynamic by the way, just that the IPv4 = address lifetime is equal to the IPv6 prefix lifetime. > or "stateless-softwire-dhcp" discussing only static provisioning. I'm = just suggesting "softwire-dhcp" solution. I would be in favour of having separate drafts, that can be combined to = create more complex solutions. if you want the LW46 mechanism to be fully described in one provisioning = document, then I would be in favour of doing that in a separate = document, and remove the existing LW46 text from MAP DHCP. cheers, Ole (and please don't read from this that I support doing DHCPv4 address = assignment for these mechanisms, I am far from convinced that it is = needed). --Apple-Mail=_21F106BA-A58A-44AB-8E93-E9876C74EDF8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSc5AwAAoJEFuJXizso86gEhAH/iVvJLX7n4INqd2nDJcbSirh GLMkZB1J+Mriky2xqO5NzR3wxHTaJTqYdR0JVksNxEWVmm8UN3r3VnF2QqZTMuZu fO3QYStNoZQK/xoJTIc3HWDl+JMV3cWJIVlkEHFpnaZCF7pRkS726tEoXtBWUkG8 NcfT0UWuyGP5ElAMGOVEldfu7PBcb9t7VGGCmS9GghXqZ+Pav0QLR/+1N5ARSAPo 2VXrqASVLg9yOlA1Lf1Oj4mYdveDcJSfPp0NqwKTSRgrZNiZXCGhZ+oq7PgQODoY y766G6k1W482c8lwsRlVbwmErXKhVFp6Lic7O7JDyVA/e0EKvzPHi/avZrjIN/M= =CNdw -----END PGP SIGNATURE----- --Apple-Mail=_21F106BA-A58A-44AB-8E93-E9876C74EDF8-- From ot@cisco.com Fri Nov 1 04:38:40 2013 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 21DE711E820D for ; Fri, 1 Nov 2013 04:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-37jR4rTJzz for ; Fri, 1 Nov 2013 04:38:31 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9657D11E8223 for ; Fri, 1 Nov 2013 04:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1809; q=dns/txt; s=iport; t=1383305905; x=1384515505; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=w23QJSeINhrbjVjGXCapmstrEtxNW8kYDwh7Ab+3SMw=; b=IZgwt89Nu75r/L/ghTZmttsMViV5MKGIHd2Lx0Ze+u3o70fq9nhbaZnX bkLo2XQMUbDi+KJRZlr8DupDATPb/JV8LLmlMg5MHQEPLekqVSMqG0F5y 3LRRRHZXERitFOG0BFVCeiIp8c6DQo6cHz5dAmqOUWxDUmK1sz/mdHB9/ g=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAO6Rc1KQ/khM/2dsb2JhbABZgwc4wDSBHxZ0giUBAQEDAXkFCwsOOFcGiBQGDb0eBI9YB4MggQ4DkC6HXJIJgyc7 X-IronPort-AV: E=Sophos;i="4.93,616,1378857600"; d="asc'?scan'208";a="19183435" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 01 Nov 2013 11:38:08 +0000 Received: from dhcp-10-61-107-140.cisco.com (dhcp-10-61-107-140.cisco.com [10.61.107.140]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA1Bc099022657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Nov 2013 11:38:02 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_D4B794F6-F62F-4D44-A224-2AC4B6C7C51C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: Date: Fri, 1 Nov 2013 12:38:00 +0100 Message-Id: References: <060.522e9001bcb47e4a09fed369a8090c45@tools.ietf.org> To: Cong Liu X-Mailer: Apple Mail (2.1816) Cc: softwires , draft-ietf-softwire-map-dhcp@tools.ietf.org Subject: Re: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e 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, 01 Nov 2013 11:38:40 -0000 --Apple-Mail=_D4B794F6-F62F-4D44-A224-2AC4B6C7C51C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Cong, > which documents describe these features? >=20 > I've read https://tools.ietf.org/html/draft-ietf-softwire-lw4over6-01 = combined with how LW46 is proposed to be provisioned in MAP DHCP. I'm = clearly missing some text somewhere. > =20 > The features are described in lw4o6-base = https://tools.ietf.org/html/draft-ietf-softwire-lw4over6-01: [...] > About dynamic IPv4 provisioning: > In section 5.1, "An lwB4 MUST support dynamic port-restricted IPv4 = address provisioning ..." > In section 7, "There are several dynamically provisioning protocols = for IPv4 address and port set ..."=20 yes, but where are those specified? what is "dynamic" port-restricted IPv4 address provisioning? how do you deal with the possible conflict with the = OPTION_S46_IPV4ADDRESS option? cheers, Ole --Apple-Mail=_D4B794F6-F62F-4D44-A224-2AC4B6C7C51C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSc5KYAAoJEP0up8EdT99JqToH/0Yujvz8fl4Xas8oW6Mv1EVH Zwcz93BTVZpXt7K31fwdHIBV46RtMgZynXnqeQI3/VtKXx3hHKW8tP+sxjpL27dd ftL9FmxJ9GqnIPbOx/2sVpxKyzhJ4u/rxKCkuEEpSTJ59MLHmetHgW+BX25jy7/F q800fYcbJatvSdP9C5kILM2rPC9GLg+wFJKMIZBvQ4P1zoQzMrdgUyjJC/UJBWpt qPAqvLu1lly5cNJsFmUGuXehSCoK62QFikF6CnUAKq4OT937Unxbg+tzD+d/qYAw 60YSJV3knWmL2jaF16ZRpNTMg4VbXuxwmmNZq6eDYd9HXcdhWTDwtepFSl7V6ng= =PPFI -----END PGP SIGNATURE----- --Apple-Mail=_D4B794F6-F62F-4D44-A224-2AC4B6C7C51C-- From Ted.Lemon@nominum.com Fri Nov 1 04:59:19 2013 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 F0CD211E828B for ; Fri, 1 Nov 2013 04:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZw3-3w5p8iA for ; Fri, 1 Nov 2013 04:59:13 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5C73711E82EA for ; Fri, 1 Nov 2013 04:59:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUnOXjKFsi0O+zoWxTIxIUtJ8ON4OwanL@postini.com; Fri, 01 Nov 2013 04:59:13 PDT 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 3CE5C1B82E5 for ; Fri, 1 Nov 2013 04:59:08 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 1A433190043; Fri, 1 Nov 2013 04:59:08 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([fe80::882a:a799:3165:f4ae]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.03.0158.001; Fri, 1 Nov 2013 04:59:08 -0700 From: Ted Lemon To: Ole Troan Thread-Topic: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e Thread-Index: AQHO1XdsQnsQHVjoCUyZHrIlSFZm7ZoQdaAAgABCbACAAAXmgA== Date: Fri, 1 Nov 2013 11:59:07 +0000 Message-ID: References: <060.522e9001bcb47e4a09fed369a8090c45@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0F58792C1A685C4398E67EEF9CDD5E43@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires , "draft-ietf-softwire-map-dhcp@tools.ietf.org" Subject: Re: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e 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, 01 Nov 2013 11:59:20 -0000 On Nov 1, 2013, at 7:38 AM, Ole Troan wrote: > how do you deal with the possible conflict with the OPTION_S46_IPV4ADDRES= S option? The v4 and v6 servers are in the same administrative domain. Why would th= ere be a conflict? From sunqi.csnet.thu@gmail.com Fri Nov 1 06:14:26 2013 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 DC34921E82C6 for ; Fri, 1 Nov 2013 06:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSv5WePa4JFf for ; Fri, 1 Nov 2013 06:14:25 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 17A1B21E822C for ; Fri, 1 Nov 2013 06:11:45 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id bj1so3996151pad.39 for ; Fri, 01 Nov 2013 06:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AsXZ8abC2e1O0HHTvobpNCSz80QL0RxeLTPEyGtbvZg=; b=txOk9XkwucI02XjAAg91IOdNTu5ZzTFXeuKG2deKDobf4bkIh3gWNh1ugk04dzF4Yo fmcWaty6K7sQMtSH8OxJyhKpxDT2+f3K1wqW1XNI2B6OvPcyZy1dvJ8hb24ezjHTJc19 s7btx+3QQu7zPpnPEPW4J/criSnPNT2AvvaG9zl4LZj14K4vq/Jo5VkyVZB40aK3wGlS xCEHzT4yb2WXb4k4DX3DYitO11xDWFgximE9YoOWk0h6mBCHv0Z70vnKGoP3r9RgBeOW 4QM3nml09Xx86WoYN8fiT5s3x+uyhIfWe0PWhnW9PntJAseRNwof8G0IvskGKLo8ZkRl TZJQ== X-Received: by 10.68.253.129 with SMTP id aa1mr1449736pbd.189.1383311505713; Fri, 01 Nov 2013 06:11:45 -0700 (PDT) Received: from [192.168.199.122] ([166.111.68.231]) by mx.google.com with ESMTPSA id x8sm10793585pbf.0.2013.11.01.06.11.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Nov 2013 06:11:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Qi Sun In-Reply-To: <57AE1075-0596-43E5-9812-0F1F2DEFF3FB@employees.org> Date: Fri, 1 Nov 2013 21:11:40 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <597A7C2F-3EC1-40F2-8571-A54523A0259F@gmail.com> References: <060.6dbd5be52b65a0ac9dd85f78f8b56c74@tools.ietf.org> <360A36EE-1369-4235-849F-CEA38FAECAE3@employees.org> <57AE1075-0596-43E5-9812-0F1F2DEFF3FB@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1085) Cc: softwires Subject: Re: [Softwires] [softwire] #28: Dealing with DHCPv4-over-DHCPv6 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, 01 Nov 2013 13:14:27 -0000 Dear Ole, Please see inline. >> MAP is incompatible with dynamic IPv4 address assignment using = DHCPv4. >>=20 >> Yes, dynamic IPv4 address assignment is only used by lw4o6. But = OPTION_S46_IPV4ADDRESS in map-dhcp-05 is also proposed for only lw4o6, >> so I think it's not a problem to have a discussion of dynamic IPv4 = provisioning. >>=20 >> either you can consider MAP DHCP as the building block used by a = separate document describing the >> DHCPv4 address assignment case. or we can split out LW46 provisioning = from MAP DHCP altogether. >>=20 >> I think the key problem here is the scope of the document: whether = "softwire-dhcp" discussing both static and dynamic IPv4 provisioning, >=20 > to nitpick, MAP DHCP is also dynamic by the way, just that the IPv4 = address lifetime is equal to the IPv6 prefix lifetime. [Qi] IMO, map-dhcp has an assumption that the mapping between IPv4 = address and IPv6 prefix is pre-determined, which is a static mapping. = But that assumption is not always true. We should allow flexibility for = the users to use a dynamic mapping. >=20 >> or "stateless-softwire-dhcp" discussing only static provisioning. I'm = just suggesting "softwire-dhcp" solution. >=20 > I would be in favour of having separate drafts, that can be combined = to create more complex solutions. [Qi] If one draft can make it clear, I don't think we need a = combination. >=20 > (and please don't read from this that I support doing DHCPv4 address = assignment for these mechanisms, I am far from convinced that it is = needed). [Qi] There are requirements for it. And it follows DHC's consensus.=20 Thanks, Qi >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ot@cisco.com Fri Nov 1 06:53:31 2013 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 02D5C11E8394 for ; Fri, 1 Nov 2013 06:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG+JYFOf6bNw for ; Fri, 1 Nov 2013 06:53:25 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 08D3A21E8316 for ; Fri, 1 Nov 2013 06:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1802; q=dns/txt; s=iport; t=1383313706; x=1384523306; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=vuVW8XHbcMtzVc83031xZMj6YMAWyjlWPB/TH4UgsL8=; b=cBkLB53HJezPf4rxDMk38tgydD6gLCho2bdB7qQuWy3/TltbZg61lCSb kVmINeoDzt2iLAD73RuUr43IKgk/WC8y4wMvChc3YGUyrmrAL7HOM24zN yuftp+CMKJZQfdgkJIM6IJ1zPqCG8uAe1PK0t4pnh0b58uDfjWbxbbN+0 c=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALSwc1KQ/khN/2dsb2JhbABZgwfAbYEeFnSCJQEBAQMBeRALRlcGiBQGvT6PWAeDIIEOA5Auh1ySCYMnOw X-IronPort-AV: E=Sophos;i="4.93,617,1378857600"; d="asc'?scan'208";a="87834775" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 01 Nov 2013 13:48:19 +0000 Received: from dhcp-10-61-107-140.cisco.com (dhcp-10-61-107-140.cisco.com [10.61.107.140]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA1DmC6u003926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Nov 2013 13:48:14 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_2F02C0E3-38B7-418C-ADFD-A3FAF04B384C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: Date: Fri, 1 Nov 2013 14:48:11 +0100 Message-Id: References: <060.522e9001bcb47e4a09fed369a8090c45@tools.ietf.org> To: Ted Lemon X-Mailer: Apple Mail (2.1816) Cc: softwires , "draft-ietf-softwire-map-dhcp@tools.ietf.org" Subject: Re: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e 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, 01 Nov 2013 13:53:31 -0000 --Apple-Mail=_2F02C0E3-38B7-418C-ADFD-A3FAF04B384C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ted, >> how do you deal with the possible conflict with the = OPTION_S46_IPV4ADDRESS option? >=20 > The v4 and v6 servers are in the same administrative domain. Why = would there be a conflict? if we are creating two ways to provision an IPv4 address for LW46. one = with DHCPv6 OPTION_S46_IPV4ADDRESS and the other being DHCPv4, then we are creating the additional complexity for the client. it has to pick one of the = mechanisms. or should it use both IPv4 addresses and ranges? regardless this has to be = specified somewhere. if we follow the principle of DHCPv6 is used to provision the link-layer = (aka tunnel), DHCPv4 is used to configure the IPv4 protocol. then I wonder if we = shouldn't really _only_ use DHCPv4 for LW46 IPv4 configuration. does that make sense? cheers, Ole --Apple-Mail=_2F02C0E3-38B7-418C-ADFD-A3FAF04B384C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSc7EcAAoJEP0up8EdT99Jn80IANjqpI7y+uVhRq9b5ocSgHs1 4wNExHGkiZn5TPnv7pLL8CpXXqsrtTCZ5FzOWPGfk84EsYWXXJXX3wq+uAeQlBcq OnHTYx8hvsNb2lSxiAzMN+ahlC58U6wm/1iMW/TG4sbcVGE7/5UljjitG/N04YKo tzOELfAyfrTLTUz19JFe/rbrCvf6OTY+tv0KksYLZVxyYUBn5Z8h4uByX1Eg5r3N ePY8noYg2EYRU9kZA57siTwBcpu4+BgBRfgKq2axwdfKc3+P8qAmiQFjzoRyR76z T2wZ3S797+WOUeT/0oMEqPVfJylBuGRGX43M1qg2YL2nN7yaHxf0VGX+IGcgjp8= =VDRT -----END PGP SIGNATURE----- --Apple-Mail=_2F02C0E3-38B7-418C-ADFD-A3FAF04B384C-- From Ted.Lemon@nominum.com Fri Nov 1 06:54:17 2013 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 9D7AF11E836D for ; Fri, 1 Nov 2013 06:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txfzeEHAXrLH for ; Fri, 1 Nov 2013 06:54:11 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6827611E8390 for ; Fri, 1 Nov 2013 06:50:38 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUnOxqhCVuhto9+woFL1QvaXqeIonOeVS@postini.com; Fri, 01 Nov 2013 06:50:38 PDT 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 7767A1B8280 for ; Fri, 1 Nov 2013 06:50:34 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 18AA9190043; Fri, 1 Nov 2013 06:50:34 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([fe80::882a:a799:3165:f4ae]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.03.0158.001; Fri, 1 Nov 2013 06:50:34 -0700 From: Ted Lemon To: Ole Troan Thread-Topic: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e Thread-Index: AQHO1XdsQnsQHVjoCUyZHrIlSFZm7ZoQdaAAgABCbACAAAXmgIAAHnmAgAAAqYA= Date: Fri, 1 Nov 2013 13:50:33 +0000 Message-ID: References: <060.522e9001bcb47e4a09fed369a8090c45@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <6BDAB1950E8E5443BC935F082C23E7B9@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires Subject: Re: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e 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, 01 Nov 2013 13:54:17 -0000 On Nov 1, 2013, at 9:48 AM, Ole Troan wrote: > if we follow the principle of DHCPv6 is used to provision the link-layer = (aka tunnel), > DHCPv4 is used to configure the IPv4 protocol. then I wonder if we should= n't really > _only_ use DHCPv4 for LW46 IPv4 configuration. does that make sense? DHCPv6 would still deliver the AFTR address, right? I don't personally se= e a lot of value in having two ways of delivering the IPv4 address for lw4o= ver6, but maybe the authors can explain? From otroan@employees.org Fri Nov 1 06:54:39 2013 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 86CFA11E813B for ; Fri, 1 Nov 2013 06:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.488 X-Spam-Level: X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na38j9H+LzxW for ; Fri, 1 Nov 2013 06:54:31 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2221211E81D3 for ; Fri, 1 Nov 2013 06:51:54 -0700 (PDT) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALSwc1KQ/khN/2dsb2JhbABZgwfAbYEeFnSCJQEBBAF5EAtGVwYuh2YGvT6PWAeDIIEOA5AumWWDJzs X-IronPort-AV: E=Sophos;i="4.93,617,1378857600"; d="asc'?scan'208";a="161293596" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Nov 2013 13:51:53 +0000 Received: from dhcp-10-61-107-140.cisco.com (dhcp-10-61-107-140.cisco.com [10.61.107.140]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA1DpnGT004655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Nov 2013 13:51:50 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_6B90A48A-CEE2-4ABA-B381-97ED2A990FDE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: <597A7C2F-3EC1-40F2-8571-A54523A0259F@gmail.com> Date: Fri, 1 Nov 2013 14:51:49 +0100 Message-Id: <9FF90F00-84F4-4AD9-9C44-739C4A938056@employees.org> References: <060.6dbd5be52b65a0ac9dd85f78f8b56c74@tools.ietf.org> <360A36EE-1369-4235-849F-CEA38FAECAE3@employees.org> <57AE1075-0596-43E5-9812-0F1F2DEFF3FB@employees.org> <597A7C2F-3EC1-40F2-8571-A54523A0259F@gmail.com> To: Qi Sun X-Mailer: Apple Mail (2.1816) Cc: softwires Subject: Re: [Softwires] [softwire] #28: Dealing with DHCPv4-over-DHCPv6 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, 01 Nov 2013 13:54:39 -0000 --Apple-Mail=_6B90A48A-CEE2-4ABA-B381-97ED2A990FDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Qi, >>> MAP is incompatible with dynamic IPv4 address assignment using = DHCPv4. >>>=20 >>> Yes, dynamic IPv4 address assignment is only used by lw4o6. But = OPTION_S46_IPV4ADDRESS in map-dhcp-05 is also proposed for only lw4o6, >>> so I think it's not a problem to have a discussion of dynamic IPv4 = provisioning. >>>=20 >>> either you can consider MAP DHCP as the building block used by a = separate document describing the >>> DHCPv4 address assignment case. or we can split out LW46 = provisioning from MAP DHCP altogether. >>>=20 >>> I think the key problem here is the scope of the document: whether = "softwire-dhcp" discussing both static and dynamic IPv4 provisioning, >>=20 >> to nitpick, MAP DHCP is also dynamic by the way, just that the IPv4 = address lifetime is equal to the IPv6 prefix lifetime. >=20 > [Qi] IMO, map-dhcp has an assumption that the mapping between IPv4 = address and IPv6 prefix is pre-determined, which is a static mapping. = But that assumption is not always true. We should allow flexibility for = the users to use a dynamic mapping. yes, MAP has that assumption. >>> or "stateless-softwire-dhcp" discussing only static provisioning. = I'm just suggesting "softwire-dhcp" solution. >>=20 >> I would be in favour of having separate drafts, that can be combined = to create more complex solutions. >=20 > [Qi] If one draft can make it clear, I don't think we need a = combination. I think the difference is that MAP-DHCP is really there to provision the = link-layer (tunnel). if we follow the principle (that I also stated to Ted), that DHCPv6 is = used to provision the link-layer, and DHCPv4 is used to provision the IPv4 layer. then I think the = "fallout" of that should be that we'd remove the OPTION_S46_IPV4ADDRESS from the MAP DHCP draft. are you fine with that approach? >> (and please don't read from this that I support doing DHCPv4 address = assignment for these mechanisms, I am far from convinced that it is = needed). >=20 > [Qi] There are requirements for it. And it follows DHC's consensus.=20 I don't think it is appropriate for you to declare DHC WG consensus. in = any case this would have to be consensus in softwires, wouldn't it? cheers, Ole --Apple-Mail=_6B90A48A-CEE2-4ABA-B381-97ED2A990FDE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSc7H1AAoJEFuJXizso86g9r8IAK6MrCBGsuub31S73fcG5L1A 3XypubqjpzLOMdLPc4/wxzcpO6c3g8DzfcMqYUzByWxEg4zzwcIE96P6F6iDn/fw qWeylvT+q99cz5fNfJivjhkRSaJEpzfuSg4buReX906ViFsxvGmWa5K63NkeTKdj fBKJGqfPyukSZ58jKieMUtzsE0mIEe29CLsuRuSkvsUyUIk1UlwIgX9aTNdyhTiG N6VsT8QcGCGcsSkek5fEbljUn2LCV8SzN9aItP29aG9d6yE/at78kmDHXC2epnIP ulXwihl/ozp7BnC6wURs5adGst87C1ATs7pWorATpKhMr758UTceDWPBJ9CX0oA= =ip3f -----END PGP SIGNATURE----- --Apple-Mail=_6B90A48A-CEE2-4ABA-B381-97ED2A990FDE-- From ot@cisco.com Fri Nov 1 06:54:55 2013 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 A409811E813B for ; Fri, 1 Nov 2013 06:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkUpf2Y6CsTg for ; Fri, 1 Nov 2013 06:54:49 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id C85CE11E833C for ; Fri, 1 Nov 2013 06:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1727; q=dns/txt; s=iport; t=1383313957; x=1384523557; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=EE3owGCv6dG2xs0yKvPHxdfrI5j50pM/S7yDo+HqOZ0=; b=WvCbvvYnsV6JO+kbtwOP/8+fJMdAj8NkSvtdwRvjKrfrZlJ3nkfDsanY lztaMROxTsjwUdCmm+l6gF8XkJYn5i6Yco+9Xucjw6JmSlp8ENG0KtLGM C2EZJYPMQW/5dnJM7cA6alsqweqkzZvcHmmhjN53tOAx9n+LiVXM5+fcv I=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJqxc1KQ/khN/2dsb2JhbABZgwfAbYEeFnSCJQEBAQMBeQULCxguVwYTiAEGvT6PWAeDIIEOA5Auh1ySCYMnOw X-IronPort-AV: E=Sophos;i="4.93,617,1378857600"; d="asc'?scan'208";a="18710487" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 01 Nov 2013 13:52:36 +0000 Received: from dhcp-10-61-107-140.cisco.com (dhcp-10-61-107-140.cisco.com [10.61.107.140]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA1DpnGU004655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Nov 2013 13:52:31 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_FFFC8B1B-ED0E-4341-910A-948A4CDBC281"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: Date: Fri, 1 Nov 2013 14:52:29 +0100 Message-Id: References: <060.522e9001bcb47e4a09fed369a8090c45@tools.ietf.org> To: Ted Lemon X-Mailer: Apple Mail (2.1816) Cc: softwires Subject: Re: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e 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, 01 Nov 2013 13:54:55 -0000 --Apple-Mail=_FFFC8B1B-ED0E-4341-910A-948A4CDBC281 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 01 Nov 2013, at 14:50 , Ted Lemon wrote: > On Nov 1, 2013, at 9:48 AM, Ole Troan wrote: >> if we follow the principle of DHCPv6 is used to provision the = link-layer (aka tunnel), >> DHCPv4 is used to configure the IPv4 protocol. then I wonder if we = shouldn't really >> _only_ use DHCPv4 for LW46 IPv4 configuration. does that make sense? >=20 > DHCPv6 would still deliver the AFTR address, right? I don't = personally see a lot of value in having two ways of delivering the IPv4 = address for lw4over6, but maybe the authors can explain? absolutely, the AFTR address is part of link-layer provisioning, so that = would be done with DHCPv6. but 'nothing' else. cheers, Ole --Apple-Mail=_FFFC8B1B-ED0E-4341-910A-948A4CDBC281 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSc7IeAAoJEP0up8EdT99JUtAH/32zgaLkDf1WZVHWoSpckDwa duRLQ0bUp1TIM7cuVi4a/CR66i7VYWAcrPdrCZ+RV/6P+YBksYWOLOCpnHe7aoYh WW12SMnRMD8+MiT2U/pR1isIZkWRvTPh/w0O+W50W5x+I7psbI3c2wn2maysYgEN wodZORxjg2tGWUi1ygH3K+Xa+nUcZo4pZmu0hB27G9Emc2j01owJ42czu7KiIWWo TkcKc+A3MiaNQHiLgifOJhNi2tgl0noUnyKaxs4s9HfJuvLo1VVx49dgzEHfNz2Q 0zIc5wiBW8qMHRIl0epndC2HzEVhM6wQiGZIwBCdEdQCUnQLYKKmP6SesLW6kXk= =wCxy -----END PGP SIGNATURE----- --Apple-Mail=_FFFC8B1B-ED0E-4341-910A-948A4CDBC281-- From yiu_lee@cable.comcast.com Fri Nov 1 08:02:51 2013 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 BAA4621E83BE for ; Fri, 1 Nov 2013 08:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.231 X-Spam-Level: X-Spam-Status: No, score=-5.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WudqOmkeP-cv for ; Fri, 1 Nov 2013 08:02:46 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 08A0021E80E6 for ; Fri, 1 Nov 2013 08:02:45 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.102541076; Fri, 01 Nov 2013 09:02:42 -0600 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.2.318.1; Fri, 1 Nov 2013 11:02:42 -0400 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.16]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Fri, 1 Nov 2013 11:02:35 -0400 From: "Lee, Yiu" Thread-Topic: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e Thread-Index: AQHO1xNlL0M/E3IDTE2LTmO1hEdxvg== Date: Fri, 1 Nov 2013 15:02:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [68.87.16.247] x-wiganss: 0100000001001Epacdcexhub04.cable.comcast.com ID0048 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3466148554_422611" MIME-Version: 1.0 To: Ted Lemon , Ole Troan Cc: softwires Subject: Re: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e 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, 01 Nov 2013 15:02:51 -0000 --B_3466148554_422611 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I agree there is no added value to have two ways to do the same thing. I guess the discussion here is whether lw46 should use dhcpv4-over-dhcpv6 or OPTION_S46_IPV4ADDRESS option in map-dhcp. No matter what we decide, we should only need one. I tend to agree with Ole to take out S46 option from the map-dhcp and let the map-dhcp draft focus on map. On 11/1/13 9:50 AM, "Ted Lemon" wrote: >On Nov 1, 2013, at 9:48 AM, Ole Troan wrote: >> if we follow the principle of DHCPv6 is used to provision the >>link-layer (aka tunnel), >> DHCPv4 is used to configure the IPv4 protocol. then I wonder if we >>shouldn't really >> _only_ use DHCPv4 for LW46 IPv4 configuration. does that make sense? > >DHCPv6 would still deliver the AFTR address, right? I don't personally >see a lot of value in having two ways of delivering the IPv4 address for >lw4over6, but maybe the authors can explain? > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3466148554_422611 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAhv91O+XLvFe6aL7jamWK/zANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzEwMjkwMDAwMDBa Fw0xNDEwMjkyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC68JKaZEJ0LViFfKWqzK16 nmjp8sC/1jA2TzrY2At4mju7v3WF1auk6Vqu2eTNoOIrkAvmseseON8/1jekEzEcDejhGAIf WypQyVw0Dxi+0FVdUi59simiUcP3S4bU9sCIUbJl9Pbl83gtzqZ6rg20K0OHgHWCJ/Yk47qd y8aHN8iOX88YFKzvYM5tbDp2La6c1cO5aXujFL5/31Ua6Q+YB/C/vqRtUxGgqU/akpem+mUl sVlmJEyeBcS8M4goFFWeHidg17gjtMFEdZOwmueJ8+mlVpo+LFlE9Mm8Kk+qEwLLbdht8vDX hpmnpT/ZQBGFhI2lF9x5Cy6nw50PpIEvAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUoLfLQmNdcYV5HlfkXY4zHV0EjpQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBRECrUaqaZ9idV79Ty+gKD3ikFYrD/oXOAYQUeccSscBzy8DlahjhnDM8NXaA2ny5vI85/ vMJl3WUWD5J7Ft9L8uw9k0EfsUCIqZQp+9mZcXtqynCeKcAL/p2Ys0p//aqf00wyWooUwhPW aniWqP1+VqoTHVrIOQ1xrbBeLbm3f3F4DXVxO9wRlFndeyqStECo9jamYsLnHOFeCfxtmXE/ czOemMA3ZFWeycKD688z2vrDK5RS54fyTUZBpDR+xZJ0tQIDZu4cwoVd0tD+3yjgDpxCdSw7 zkWyqCZ/MmhTlMx0Jc7b2X3QcHNud5lDyYgy8tvaUjlQTrW3Hx2XbeFXMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAhv91O+XLvFe6aL7jamWK/zAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFIgZ JuwxUdT4aqNaJo49jPxgoPP7MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMTEwMTE1MDIzM1owDQYJKoZIhvcNAQEBBQAEggEAY+k5olI/Z3Xan7mm3wk6 1uTVkcZphDm4IIvK4hLJ3xXi55EwHWCq1Lc9MaWYpyfnZEBVm4Gka0EysBcxjRtPrQZNHtEC 0roNLrI5zokldqqVoU4V+Dc8ogJMUGGtzmAe6xmsXiibXIzT9+k7BV3qoqG+VTwzPpJF0cK7 O3/o5M+pH+zCsN0IzC0xpc4+lhTfjGDfM95Wj7OekIT+nr4j7MMtu6onQod3qIbZq/+H2xgJ 6sXY56u8dXB+qkR+xiIG5wYlpuZJOLIsI3d2zIAtDnjr/NYz+saAqyaYCpVL8NErThg6e/oW W5gnDyqLRfIuzwfWwB1Inl6FiPZ5Tw20tw== --B_3466148554_422611-- From gnocuil@gmail.com Fri Nov 1 08:04:32 2013 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 A12FB21E837A for ; Fri, 1 Nov 2013 08:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5R9olP9uoBz for ; Fri, 1 Nov 2013 08:04:32 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DE51621E821A for ; Fri, 1 Nov 2013 08:04:31 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id j15so671137qaq.19 for ; Fri, 01 Nov 2013 08:04:26 -0700 (PDT) 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=6jOdWh5/1cw58hd5r6oy2rIrJMc/Ixyn0jj3uovLy70=; b=CesLurmE5tOS7klmhoeCMrp4mHwRB1EFDfm7s1KZyrI9U9peuMvBEOo0w7Ic32bE8m f6dCGnuLYQlxZdawfFacpocndCGBgkMNGWNJsjZaZHevCtVJvrZoOSxW6JapWmgwWSEz nsh5HCE72x2GlyfaF6cNmj+o647qytTHq+dUZcmviYKy7s49YeSY4lKNBMTy6xeEILeF tfzGhS71KYhzEBgtTQyxgiIVvAwFvDZr/sfXLKRJV9XE1I9ktnv0nfLnzDyL/HVWcWHX S66UdqPUsDQvaJp5+yHxiB5xF990RN4yMSMfohfWWcsN1deJD3T+0d8vibWUeYxb6qEV 4FAQ== X-Received: by 10.224.88.193 with SMTP id b1mr4642408qam.81.1383318266635; Fri, 01 Nov 2013 08:04:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.185.33 with HTTP; Fri, 1 Nov 2013 08:04:06 -0700 (PDT) In-Reply-To: References: <060.522e9001bcb47e4a09fed369a8090c45@tools.ietf.org> From: Cong Liu Date: Fri, 1 Nov 2013 23:04:06 +0800 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=001a11c2d758e4ecdb04ea1ee105 Cc: softwires Subject: Re: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e 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, 01 Nov 2013 15:04:32 -0000 --001a11c2d758e4ecdb04ea1ee105 Content-Type: text/plain; charset=ISO-8859-1 Hi Ole, 2013/11/1 Ole Troan > > On 01 Nov 2013, at 14:50 , Ted Lemon wrote: > > > On Nov 1, 2013, at 9:48 AM, Ole Troan wrote: > >> if we follow the principle of DHCPv6 is used to provision the > link-layer (aka tunnel), > >> DHCPv4 is used to configure the IPv4 protocol. then I wonder if we > shouldn't really > >> _only_ use DHCPv4 for LW46 IPv4 configuration. does that make sense? > > > > DHCPv6 would still deliver the AFTR address, right? I don't personally > see a lot of value in having two ways of delivering the IPv4 address for > lw4over6, but maybe the authors can explain? > > absolutely, the AFTR address is part of link-layer provisioning, so that > would be done with DHCPv6. but 'nothing' else. > Besides DHCPv4-based method, PCP is also proposed for lw4o6 IPv4 configuration. According to http://tools.ietf.org/html/draft-perreault-softwire-lw4over6-pcp-00, the provisioning process is the same: (1) Provision AFTR address by DHCPv6 option; (2) Provision (IPv4 address + ports) by PCP Do you mean DHCPv6 in step(1) should be avoided ? Best Regards, Cong --001a11c2d758e4ecdb04ea1ee105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ole,

2013/11/1 Ole Troan <ot@cisco.com>

On 01 Nov 2013, at 14:50 , Ted Lemon <Ted.Lemon@nominum.com> wrote:

> On Nov 1, 2013, at 9:48 AM, Ole Troan <ot@cisco.com> wrote:
>> if we follow the principle of DHCPv6 is used to provision the link= -layer (aka tunnel),
>> DHCPv4 is used to configure the IPv4 protocol. then I wonder if we= shouldn't really
>> _only_ use DHCPv4 for LW46 IPv4 configuration. does that make sens= e?
>
> DHCPv6 would still deliver the AFTR address, right? =A0 I don't pe= rsonally see a lot of value in having two ways of delivering the IPv4 addre= ss for lw4over6, but maybe the authors can explain?

absolutely, the AFTR address is part of link-layer provisioning, so t= hat would be done with DHCPv6. but 'nothing' else.
=

Besides DHCPv4-based method, PCP is also proposed for l= w4o6 IPv4 configuration. According to=A0http://tools= .ietf.org/html/draft-perreault-softwire-lw4over6-pcp-00, the provisioni= ng process is the same:
(1) Provision AFTR address by=A0DHCPv6 option;
(2) Provision= (IPv4 address + ports) by PCP=A0

Do you mean DHCP= v6 in step(1) should be avoided ?

Best Regards,
Cong

--001a11c2d758e4ecdb04ea1ee105-- From ot@cisco.com Fri Nov 1 08:25:31 2013 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 4749F11E81C3 for ; Fri, 1 Nov 2013 08:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6jKsVB7GM+4 for ; Fri, 1 Nov 2013 08:25:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8869E11E817D for ; Fri, 1 Nov 2013 08:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1984; q=dns/txt; s=iport; t=1383319517; x=1384529117; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=yvukm8+KB3g3H7EnTEQ+lIbKPdM9Z6E3LMjqEBZmd0I=; b=K2VTYC6fTdVdOQTdRHdT7LUWF/w67COjZ8TyIIjI4IjhAlN6jcPmK272 DCR4/nNkfJjCHPkFAas8NPQfadCSHFxLAmQ7do3ZCInNaci9AlnTqESW7 Jy9S2MObn6kgLFW/VDA345vwf8QZBk/LjN3rRYBAxdN6LDHXuzV0YiQ7y w=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOzGc1KQ/khR/2dsb2JhbABZgwc4wDeBHhZ0giUBAQEDAXkQCw44VwaIFAYNvTuPWAeDIIEOA5Auh1yBL5Bagyc7 X-IronPort-AV: E=Sophos;i="4.93,617,1378857600"; d="asc'?scan'208";a="161297306" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 01 Nov 2013 15:25:16 +0000 Received: from dhcp-10-61-97-40.cisco.com (dhcp-10-61-97-40.cisco.com [10.61.97.40]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA1FP9rX030993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 1 Nov 2013 15:25:11 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_0C95059E-749B-434D-8976-5D4F5D015EB5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: Date: Fri, 1 Nov 2013 16:25:08 +0100 Message-Id: References: <060.522e9001bcb47e4a09fed369a8090c45@tools.ietf.org> To: Cong Liu X-Mailer: Apple Mail (2.1816) Cc: softwires Subject: Re: [Softwires] [softwire] #27: lw4o6 is not a subset of map-e 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, 01 Nov 2013 15:25:31 -0000 --Apple-Mail=_0C95059E-749B-434D-8976-5D4F5D015EB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > >> if we follow the principle of DHCPv6 is used to provision the = link-layer (aka tunnel), > >> DHCPv4 is used to configure the IPv4 protocol. then I wonder if we = shouldn't really > >> _only_ use DHCPv4 for LW46 IPv4 configuration. does that make = sense? > > > > DHCPv6 would still deliver the AFTR address, right? I don't = personally see a lot of value in having two ways of delivering the IPv4 = address for lw4over6, but maybe the authors can explain? >=20 > absolutely, the AFTR address is part of link-layer provisioning, so = that would be done with DHCPv6. but 'nothing' else. >=20 > Besides DHCPv4-based method, PCP is also proposed for lw4o6 IPv4 = configuration. According to = http://tools.ietf.org/html/draft-perreault-softwire-lw4over6-pcp-00, the = provisioning process is the same: > (1) Provision AFTR address by DHCPv6 option; > (2) Provision (IPv4 address + ports) by PCP=20 >=20 > Do you mean DHCPv6 in step(1) should be avoided ? no. Ole --Apple-Mail=_0C95059E-749B-434D-8976-5D4F5D015EB5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSc8fVAAoJEP0up8EdT99JDu8H/0nElZN78n8MfcvJRdIIy0hj 3G2LO0U/+rUl/3i9mJSWwCrxiYP36MPYuo73kcQIM4yeBPCLiK+6NqYAYlPaF6zy eQ2sXDVYimJ6bWgREdt0EQO3RKHIonY6kD2/gmS1z9XTZkma7/y+NdBiB62WtY8H eZkTijlgDmBNtYkuDxChiVC6jt0rAC36p7Yef74c48oke9q6xVH7kSew4VgEsmA9 HtzyKGk5wylnbg998qtTBAgdl8r+X/vwr1NOeWdwaSGrcPWn/At1fKaMoa7D4k1I 0tCTAPYpx5LW6YExHLqwoTyt9Mx83pmXcyXRkPAS4NMrXvCMI5922lahyqbj8p4= =TKOc -----END PGP SIGNATURE----- --Apple-Mail=_0C95059E-749B-434D-8976-5D4F5D015EB5-- From internet-drafts@ietf.org Mon Nov 4 18:57:36 2013 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 4579921E83A0; Mon, 4 Nov 2013 18:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNTiQT0KvDPV; Mon, 4 Nov 2013 18:57:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 615CC21E80F1; Mon, 4 Nov 2013 18:57:35 -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.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131105025735.10172.69180.idtracker@ietfa.amsl.com> Date: Mon, 04 Nov 2013 18:57:35 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-mib-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 02:57:36 -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 : DS-Lite Management Information Base (MIB) Author(s) : Yu Fu Sheng Jiang Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-dslite-mib-04.txt Pages : 21 Date : 2013-11-04 Abstract: This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for Dual-Stack Lite (DS-Lite). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-dslite-mib-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-dslite-mib-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eleven.fuyu@huawei.com Wed Nov 6 01:42:28 2013 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 3A3B111E80F2; Wed, 6 Nov 2013 01:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A19DG2CpJWvR; Wed, 6 Nov 2013 01:42:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E650521E80AD; Wed, 6 Nov 2013 01:42:21 -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.7-GA FastPath queued) with ESMTP id AZY12529; Wed, 06 Nov 2013 09:42:20 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 09:41:14 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 09:41:56 +0000 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.31]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 17:41:51 +0800 From: "Fuyu (Eleven)" To: Dave Thaler , "softwires@ietf.org" Thread-Topic: [Softwires] Early MIB doctor review of draft-ietf-softwire-dslite-mib-03 Thread-Index: Ac7BYkvSQL3SrrVPTZSNhm48v5yxIgZbR29w Date: Wed, 6 Nov 2013 09:41:51 +0000 Message-ID: References: <45e71b4ab8434c19bfae92f68572ba75@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <45e71b4ab8434c19bfae92f68572ba75@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.25] Content-Type: multipart/alternative; boundary="_000_EF6A204047BD994A860EE26D5F23BF58415C48BFnkgeml505mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Benoit Claise , "behave@ietf.org" Subject: Re: [Softwires] Early MIB doctor review of draft-ietf-softwire-dslite-mib-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 09:42:28 -0000 --_000_EF6A204047BD994A860EE26D5F23BF58415C48BFnkgeml505mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIERhdmUsDQoNClRoYW5rcyBhIGxvdCAgZm9yIHlvdXIgcmV2aWV3LiBXZSBoYXZlIHJldmlz ZWQgYW4gdXBkYXRlZCB2ZXJzaW9uIGJhc2VkIG9uIHlvdXIgY29tbWVudHMgYXMgZHJhZnQtaWV0 Zi1zb2Z0d2lyZS1kc2xpdGUtbWliLTA0LiAgUGxlYXNlIHNlZSBteSByZXBseSBiZWxvdzoNCg0K QmVzdCByZWdhcmRzLA0KDQpZdQ0KDQoNCkZyb206IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZlIFRo YWxlcg0KU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMDUsIDIwMTMgODo0MyBBTQ0KVG86IHNvZnR3 aXJlc0BpZXRmLm9yZw0KQ2M6IEJlbm9pdCBDbGFpc2U7IGJlaGF2ZUBpZXRmLm9yZw0KU3ViamVj dDogW1NvZnR3aXJlc10gRWFybHkgTUlCIGRvY3RvciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zb2Z0 d2lyZS1kc2xpdGUtbWliLTAzDQoNCkJlbm9pdCBhc2tlZCBtZSB0byBkbyBhbiBlYXJseSBNSUIg ZG9jdG9yIHJldmlldyBvZiB0aGlzIGRvY3VtZW50LiAgTXkNCmZ1bGwgY29tbWVudHMgYXJlIGlu IHRoZSBtYXJrZWQgdXAgY29weSBhdA0KaHR0cDovL3Jlc2VhcmNoLm1pY3Jvc29mdC5jb20vfmR0 aGFsZXIvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1kc2xpdGUtbWliLTAzLnBkZg0KKHRoZXJl4oCZcyBh bHNvIGEgLmRvY3ggdmVyc2lvbiBpZiB5b3UgcmVwbGFjZSB0aGUgLnBkZiBleHRlbnNpb24gd2l0 aCAuZG9jeCkNCg0KSeKAmXZlIGFsc28gY2PigJllZCB0aGUgYmVoYXZlIFdHIG9uIHRoaXMgbWFp bCBzaW5jZSBtYW55IG9mIG15IGNvbW1lbnRzIGNvbmNlcm4NCnRoZSByZWxhdGlvbnNoaXAgYmV0 d2VlbiBkcmFmdC1pZXRmLWJlaGF2ZS1uYXQtbWliICBhbmQgdGhlIHRyYW5zbGF0aW9uIHBhcnRz IG9mDQp0aGlzIGRyYWZ0Lg0KDQpBIHNob3J0IHN1bW1hcnkgb2YgdGhlIGhpZ2ggbGV2ZWwgaXNz dWVzIGluIG15IHJldmlldyBpczoNCg0KMSkgICAgICBUaGUgZG9jIGlzIG5vdCBhbGlnbmVkIHdp dGggZHJhZnQtaWV0Zi1iZWhhdmUtbmF0LW1pYi4gIEl0IGN1cnJlbnRseSBjb250aW51ZXMNCg0K c29tZSBwcmFjdGljZXMgdGhhdCB3ZeKAmXJlIHRyeWluZyB0byBkZXByZWNhdGUgYXMgZGlzY3Vz c2VkIGluIHNlY3Rpb24gMy4xIG9mDQoNCmRyYWZ0LWlldGYtYmVoYXZlLW5hdC1taWIuDQoNCg0K DQpbWXVdOiBBbGwgb2JqZWN0cyByZWxhdGVkIHRvIFRoZSBOQVQtTUlCIGhhdmUgYmVlbiB1cGRh dGVkIGFjY29yZGluZyB0byB0aGUgZHJhZnQtaWV0Zi1iZWhhdmUtbmF0LW1pYi4NCg0KDQoNCjIp ICAgICAgQm9pbGVycGxhdGUgbmVlZHMgdG8gYmUgdXBkYXRlZCB0byBtYXRjaCBsYXRlc3QgTUlC IGJvaWxlcnBsYXRlIChzZWUgaW5saW5lDQoNCmNvbW1lbnRzIGZvciBwb2ludGVycykuDQoNCg0K DQpbWXVdOiBJdCBoYXMgYWxyZWFkeSBiZWVuIHVwZGF0ZWQgaW4gdGhlIDA0IHZlcnNpb24uDQoN Cg0KDQozKSAgICAgIEFueSBJbmV0UG9ydE51bWJlciBvYmplY3QgYWxsb3dpbmcgMCBuZWVkcyB0 byBleHBsYWluIHdoYXQgMCBtZWFucyBpbiB0aGF0DQoNCm9iamVjdCwgYXMgcmVxdWlyZWQgYnkg UkZDIDQwMDEuDQoNCg0KDQpbWXVdOiBUaGUgSW5ldFBvcnROdW1iZXIgb2JqZWN0cyBhbGxvd2lu ZyAwIGluIHRoZSBEUy1MaXRlIE1JQiBoYXZlIGJlZW4gZGVsZXRlZCBpbiB0aGUgdXBkYXRlZCB2 ZXJzaW9uLg0KDQoNCg0KNCkgICAgICBEcmFmdCBjdXJyZW50bHkgcmVxdWlyZXMgd3JpdGUgc3Vw cG9ydCBpbiBhbGwgaW1wbGVtZW50YXRpb25zLiAgUmVjb21tZW5kDQoNCmhhdmluZyBhIHJlYWQt b25seSBjb21wbGlhbmNlIHN0YXRlbWVudCBzaW5jZSBub3dhZGF5cyBtYW55IGZvbGtzIGRvbuKA mXQNCg0Kd2FudCB3cml0ZSBzdXBwb3J0IHZpYSBNSUJzLg0KDQpbWXVdOiBBbGwgdGhlIG9iamVj dCByZXF1aXJlcyB3cml0ZSBzdXBwb3J0IGluIHRoZSAwMyB2ZXJzaW9uIGhhZCBiZWVuIGRlZmlu ZWQgdG8g4oCdcmVhZC1vbmx54oCdIGFzIHJlY29tbWVuZCBpbiBuZXcgdmVyc2lvbiBleGNlcHQg dGhlDQoNCiAgICAgICAgIG9iamVjdCDigJxkc2xpdGVBRlRSQWxhcm1Db25uZWN0TnVtYmVy4oCd LiBUaGUgb2JqZWN0IGluZGljYXRlcyB0aGUgdGhyZXNob2xkIG9mIHRoZSB0dW5uZWwgbnVtYmVy IG9mIHdoaWNoIGNhbiBiZSBjb25uZWN0ZWQgdG8gdGhlIEFGVFIuDQoNCiAgICAgICAgSXQgaXMg YWx3YXlzIHNldCBieSB0aGUgbmV0d29yayBtYW5hZ2VyIGZvciB0aGUgcGVyZm9ybWFuY2UgY29u c2lkZXJhdGlvbi4NCg0KDQotRGF2ZQ0KDQo= --_000_EF6A204047BD994A860EE26D5F23BF58415C48BFnkgeml505mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNv bnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8 jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0K cC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFn cmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2lu LXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuSFRNTFByZWZvcm1hdHRl ZCwgbGkuSFRNTFByZWZvcm1hdHRlZCwgZGl2LkhUTUxQcmVmb3JtYXR0ZWQNCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0K CWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3 aGl0ZSIgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+SGksIERhdmUsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPlRoYW5rcyBhIGxvdCAmbmJzcDtm b3IgeW91ciByZXZpZXcuIFdlIGhhdmUgcmV2aXNlZCBhbiB1cGRhdGVkIHZlcnNpb24gYmFzZWQg b24geW91ciBjb21tZW50cyBhcyBkcmFmdC1pZXRmLXNvZnR3aXJlLWRzbGl0ZS1taWItMDQuICZu YnNwO1BsZWFzZSBzZWUgbXkNCiByZXBseSBiZWxvdzogPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6d2luZG93dGV4dCI+WXU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBz b2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZw0KIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0 Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+RGF2ZSBUaGFsZXI8YnI+DQo8Yj5TZW50OjwvYj4g U2F0dXJkYXksIE9jdG9iZXIgMDUsIDIwMTMgODo0MyBBTTxicj4NCjxiPlRvOjwvYj4gc29mdHdp cmVzQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBCZW5vaXQgQ2xhaXNlOyBiZWhhdmVAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1NvZnR3aXJlc10gRWFybHkgTUlCIGRvY3RvciByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1zb2Z0d2lyZS1kc2xpdGUtbWliLTAzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJl bm9pdCBhc2tlZCBtZSB0byBkbyBhbiBlYXJseSBNSUIgZG9jdG9yIHJldmlldyBvZiB0aGlzIGRv Y3VtZW50LiZuYnNwOyBNeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+ZnVsbCBjb21tZW50cyBhcmUgaW4gdGhlIG1hcmtlZCB1cCBjb3B5IGF0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3Jlc2VhcmNoLm1pY3Jvc29mdC5jb20v fmR0aGFsZXIvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1kc2xpdGUtbWliLTAzLnBkZiI+aHR0cDovL3Jl c2VhcmNoLm1pY3Jvc29mdC5jb20vfmR0aGFsZXIvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1kc2xpdGUt bWliLTAzLnBkZjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPih0aGVyZeKAmXMgYWxzbyBhIC5kb2N4IHZlcnNpb24gaWYgeW91IHJlcGxhY2UgdGhl IC5wZGYgZXh0ZW5zaW9uIHdpdGggLmRvY3gpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPknigJl2ZSBhbHNvIGNj4oCZZWQgdGhlIGJlaGF2ZSBXRyBvbiB0aGlzIG1haWwgc2lu Y2UgbWFueSBvZiBteSBjb21tZW50cyBjb25jZXJuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj50aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gZHJhZnQtaWV0Zi1iZWhh dmUtbmF0LW1pYiAmbmJzcDthbmQgdGhlIHRyYW5zbGF0aW9uIHBhcnRzIG9mPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj50aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BIHNob3J0IHN1bW1hcnkgb2YgdGhlIGhpZ2ggbGV2ZWwg aXNzdWVzIGluIG15IHJldmlldyBpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+MSk8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgZG9jIGlzIG5vdCBhbGlnbmVk IHdpdGggZHJhZnQtaWV0Zi1iZWhhdmUtbmF0LW1pYi4mbmJzcDsgSXQgY3VycmVudGx5IGNvbnRp bnVlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnNv bWUgcHJhY3RpY2VzIHRoYXQgd2XigJlyZSB0cnlpbmcgdG8gZGVwcmVjYXRlIGFzIGRpc2N1c3Nl ZCBpbiBzZWN0aW9uIDMuMSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPmRyYWZ0LWlldGYtYmVoYXZlLW5hdC1taWIuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY20i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+W1l1XTogQWxsIG9iamVjdHMgcmVsYXRlZCB0byBU aGUgTkFULU1JQiBoYXZlIGJlZW4gdXBkYXRlZCBhY2NvcmRpbmcgdG8gdGhlDQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5k cmFmdC1pZXRmLWJlaGF2ZS1uYXQtbWliLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4yKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkJvaWxlcnBsYXRlIG5lZWRzIHRvIGJlIHVwZGF0ZWQgdG8gbWF0Y2ggbGF0ZXN0IE1JQiBi b2lsZXJwbGF0ZSAoc2VlIGlubGluZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPmNvbW1lbnRzIGZvciBwb2ludGVycykuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY20i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+W1l1XTogSXQgaGFzIGFscmVhZHkgYmVlbiB1cGRh dGVkIGluIHRoZSAwNCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LTE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4zKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkFueSBJbmV0UG9ydE51bWJlciBvYmplY3QgYWxsb3dpbmcgMCBuZWVkcyB0byBleHBsYWluIHdo YXQgMCBtZWFucyBpbiB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+b2JqZWN0LCBhcyByZXF1aXJlZCBieSBSRkMgNDAwMS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5bWXVdOiBUaGUgSW5ldFBvcnROdW1iZXIg b2JqZWN0cyBhbGxvd2luZyAwIGluIHRoZSBEUy1MaXRlIE1JQiBoYXZlIGJlZW4gZGVsZXRlZCBp biB0aGUgdXBkYXRlZCB2ZXJzaW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY20iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjQpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+RHJhZnQgY3VycmVudGx5IHJlcXVpcmVzIHdyaXRlIHN1cHBvcnQgaW4gYWxsIGltcGxlbWVu dGF0aW9ucy4mbmJzcDsgUmVjb21tZW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+aGF2aW5nIGEgcmVhZC1vbmx5IGNvbXBsaWFuY2Ugc3RhdGVtZW50 IHNpbmNlIG5vd2FkYXlzIG1hbnkgZm9sa3MgZG9u4oCZdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPndhbnQgd3JpdGUgc3VwcG9ydCB2aWEgTUlCcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjp3aW5kb3d0ZXh0Ij5bWXVdOiBBbGwgdGhlIG9iamVjdCByZXF1aXJlcyB3cml0ZSBz dXBwb3J0IGluIHRoZSAwMyB2ZXJzaW9uIGhhZCBiZWVuIGRlZmluZWQgdG8g4oCdcmVhZC1vbmx5 4oCdIGFzIHJlY29tbWVuZCBpbg0KIG5ldyB2ZXJzaW9uIGV4Y2VwdCB0aGUgPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO29iamVjdCDigJxkc2xpdGVBRlRSQWxhcm1Db25uZWN0TnVtYmVy4oCd LiBUaGUgb2JqZWN0IGluZGljYXRlcyB0aGUgdGhyZXNob2xkIG9mIHRoZSB0dW5uZWwgbnVtYmVy IG9mIHdoaWNoIGNhbiBiZSBjb25uZWN0ZWQgdG8gdGhlIEFGVFIuPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEl0IGlzIGFsd2F5cyBzZXQgYnkgdGhlIG5ldHdvcmsgbWFuYWdlciBmb3IgdGhlIHBlcmZvcm1h bmNlIGNvbnNpZGVyYXRpb24uIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tRGF2ZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EF6A204047BD994A860EE26D5F23BF58415C48BFnkgeml505mbxchi_-- From otroan@employees.org Thu Nov 7 15:24:31 2013 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 9A8ED21E8094; Thu, 7 Nov 2013 15:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.537 X-Spam-Level: X-Spam-Status: No, score=-10.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwsrLgGDKFlE; Thu, 7 Nov 2013 15:24:25 -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 55CDE11E812F; Thu, 7 Nov 2013 15:24:24 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAO8ffFKQ/khM/2dsb2JhbABagwfAGYEnFnSCJQEBBAF5BQsLDjhXBi6HYAa9QY9ZB4MggRADkC6ZaIMnOw X-IronPort-AV: E=Sophos;i="4.93,654,1378857600"; d="asc'?scan'208";a="18867041" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 07 Nov 2013 23:24:23 +0000 Received: from dhcp-10-61-110-227.cisco.com (dhcp-10-61-110-227.cisco.com [10.61.110.227]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA7NOJw6008215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Nov 2013 23:24:19 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_244C2386-FBAE-43A3-B6CD-9FD2B3E8B2F9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ole Troan In-Reply-To: <1382D295-2339-4BD8-A4FC-CCFF6FE6A549@me.com> Date: Fri, 8 Nov 2013 00:24:18 +0100 Message-Id: References: <1382D295-2339-4BD8-A4FC-CCFF6FE6A549@me.com> To: Ian Farrer X-Mailer: Apple Mail (2.1816) Cc: Softwires , "dhcwg@ietf.org WG" , draft-ietf-softwire-map-dhcp@tools.ietf.org, draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org Subject: Re: [Softwires] Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts 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, 07 Nov 2013 23:24:31 -0000 --Apple-Mail=_244C2386-FBAE-43A3-B6CD-9FD2B3E8B2F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ian, > =46rom a discussion with Bernie and Tomeck earlier: To give some = clarity about what the different 4o6 provisioning mechanisms are = suitable for, can we add in some text to bound the scope of map-dhcp to = provisioning static v4 configuration parameters (i.e. precluding dynamic = v4 leasing) with no additional DHCPv4 options and add in an informative = pointer to using DHCPv4 over DHCPv6 for dynamic/additional options? >=20 > Likewise, I=92m putting a similar back pointer to MAP-DHCP in the = dhc-v4-configuration draft: >=20 > For the most simple IPv4 provisioning case, where the client only = needs to receive a static IPv4 address range assignment (with no dynamic = address leasing or additional IPv4 configuration), DHCPv6 based = approaches [ietf-softwire-map-dhcp] may provide a suitable solution. >=20 > The DHCPv4oDHCPv6 doc should have a similar pointer to map-dhcp for = static as well. could you propose some text? I'm not quite sure what bounding of scope you'd like to see. all the lifetimes of configuration information defined in MAP DHCP are = bounded by the lifetimes of the tunnel, i.e. the lifetime of the End-user IPv6 prefix. the IPv4 address assignment will be as dynamic as the underlaying IPv6 = assignment is. what using DHCPv4 address leases gets you, is separate lease times. = given that, this mode is incompatible with MAP-T and -E, I'm not quite sure what this document can say about it? cheers, Ole --Apple-Mail=_244C2386-FBAE-43A3-B6CD-9FD2B3E8B2F9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSfCEiAAoJEFuJXizso86gTuQH/RXkA4Fk47fZWU7Ct6dKnA+y qFkx2t0W2+4lgvAbwTKD91xs+Xyga6aTpmpwhNUG1zeRYC0yXwimsSkJU2PXVSWD 4T32cwt/vYhM9K/3dg1sq8DDE+l0cgnujNtycf+WYE4Cprl9TJTW24p3BUOvEjJ8 RYRh6gEHABYiQHqWXwCgCYw9Yw9nm+l+JnCom8iRBve6N6xwFIQLwMjDVOq+n464 XkKjv3YOkF2n/Hp/GY7xwWTNYi9z0EUTiFWBPK677ftCwq4i91YdKDUNtM8a9caX GZiWyQlDB8LuwuXzQAomQ4T4i8buKFwxaF04OQIDwLxIhO86IYNKYys9mzFhjWI= =wcoj -----END PGP SIGNATURE----- --Apple-Mail=_244C2386-FBAE-43A3-B6CD-9FD2B3E8B2F9-- From internet-drafts@ietf.org Fri Nov 8 09:34:01 2013 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 DDA1821E81B9; Fri, 8 Nov 2013 09:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHzjsWGhNeP4; Fri, 8 Nov 2013 09:34:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BBD21E8149; Fri, 8 Nov 2013 09:34:01 -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.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131108173401.7015.82982.idtracker@ietfa.amsl.com> Date: Fri, 08 Nov 2013 09:34:01 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 17:34:02 -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 : Lightweight 4over6: An Extension to the DS-Lite Architec= ture Author(s) : Yong Cui Qiong Sun Mohamed Boucadair Tina Tsou Yiu L. Lee Ian Farrer Filename : draft-ietf-softwire-lw4over6-02.txt Pages : 20 Date : 2013-11-08 Abstract: Dual-Stack Lite (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called Lightweight 4over6 which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 Address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ianfarrer@gmx.com Fri Nov 8 09:42:51 2013 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 A857521E8138 for ; Fri, 8 Nov 2013 09:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8rNJfOmZOPW for ; Fri, 8 Nov 2013 09:42:46 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 7F78311E81D0 for ; Fri, 8 Nov 2013 09:42:27 -0800 (PST) Received: from dhcp-a251.meeting.ietf.org ([31.133.162.81]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lg6op-1Vz2aP1Ftr-00pcWj for ; Fri, 08 Nov 2013 18:42:19 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ian Farrer In-Reply-To: <20131108173401.7015.82982.idtracker@ietfa.amsl.com> Date: Fri, 8 Nov 2013 09:42:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131108173401.7015.82982.idtracker@ietfa.amsl.com> To: Softwires X-Mailer: Apple Mail (2.1816) X-Provags-ID: V03:K0:+pmsJlxmoScRmzUA7d+Mwi0nTJF3cTAMlyGPchzliY49IaUGZua jd9DoD9PAzhZwu32LQTafLgmSwIAuxd5AL6e++SJWrNM2uobf3I/mWRczci3t05Roqgyu1x cAN3lNMFDAG/6aWbfZNpiAHpwgAfXkaeoXh6Y8/MqZtniA7l5vaOqdsxVl4LDp8xTkQHKvZ 1nGHbkeAsNINmNnzy3BUA== Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-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: Fri, 08 Nov 2013 17:42:51 -0000 Dear All, I=92ve just posted a new version of the lw4o6 draft based on the outcome = of Tuesday=92s Softwire meeting. Many thanks, Ian On 8 Nov 2013, at 09:34, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Softwires Working Group of the IETF. >=20 > Title : Lightweight 4over6: An Extension to the = DS-Lite Architecture > Author(s) : Yong Cui > Qiong Sun > Mohamed Boucadair > Tina Tsou > Yiu L. Lee > Ian Farrer > Filename : draft-ietf-softwire-lw4over6-02.txt > Pages : 20 > Date : 2013-11-08 >=20 > Abstract: > Dual-Stack Lite (RFC 6333) describes an architecture for = transporting > IPv4 packets over an IPv6 network. This document specifies an > extension to DS-Lite called Lightweight 4over6 which moves the > Network Address and Port Translation (NAPT) function from the > centralized DS-Lite tunnel concentrator to the tunnel client located > in the Customer Premises Equipment (CPE). This removes the > requirement for a Carrier Grade NAT function in the tunnel > concentrator and reduces the amount of centralized state that must = be > held to a per-subscriber level. In order to delegate the NAPT > function and make IPv4 Address sharing possible, port-restricted = IPv4 > addresses are allocated to the CPEs. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6 >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ian.farrer@telekom.de Mon Nov 11 03:54:25 2013 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 CC15C21E8091; Mon, 11 Nov 2013 03:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDubIqHL9n5s; Mon, 11 Nov 2013 03:54:20 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE7A11E8114; Mon, 11 Nov 2013 03:54:18 -0800 (PST) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 11 Nov 2013 12:54:16 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.39]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 11 Nov 2013 12:54:16 +0100 From: To: , Date: Mon, 11 Nov 2013 12:54:16 +0100 Thread-Topic: ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts Thread-Index: Ac7e1L5mPJ6JmXHYTGG/XjGCLEur0Q== Message-ID: In-Reply-To: <16404066.36068.1383866712355.JavaMail.trustmail@he111467> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires@ietf.org, dhcwg@ietf.org, draft-ietf-softwire-map-dhcp@tools.ietf.org, draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org Subject: Re: [Softwires] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts 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, 11 Nov 2013 11:54:25 -0000 Hi Ole, How about: -- The solution described in this document is suitable for provisioning IPv4 addressing and other configuration necessary for establishing softwire connectivity using DHCPv6. This means that the lifetime of the IPv4 configuration is bound to the lifetime of the DHCPv6 lease. For MAP-E and MAP-T, this is necessary due to the mapping between the IPv4 and the IPv6 address. Lightweight 4over6 allows for the de-coupling of the IPv4 and IPv6 lease times. If this is required, then DHCPv4 over DHCPv6 [ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address leasing. Additional DHCPv4 options are not transported natively in DHCPv6. If these are required for client provisioning, then DHCPINFORM transported in DHCPv4 over DHCPv6 should be used. =8B Does that cover it? Cheers, Ian On 08/11/2013 00:24, "Ole Troan" wrote: >Ian, > >> From a discussion with Bernie and Tomeck earlier: To give some clarity >>about what the different 4o6 provisioning mechanisms are suitable for, >>can we add in some text to bound the scope of map-dhcp to provisioning >>static v4 configuration parameters (i.e. precluding dynamic v4 leasing) >>with no additional DHCPv4 options and add in an informative pointer to >>using DHCPv4 over DHCPv6 for dynamic/additional options? >>=20 >> Likewise, I=B9m putting a similar back pointer to MAP-DHCP in the >>dhc-v4-configuration draft: >>=20 >> For the most simple IPv4 provisioning case, where the client only needs >>to receive a static IPv4 address range assignment (with no dynamic >>address leasing or additional IPv4 configuration), DHCPv6 based >>approaches [ietf-softwire-map-dhcp] may provide a suitable solution. >>=20 >> The DHCPv4oDHCPv6 doc should have a similar pointer to map-dhcp for >>static as well. > >could you propose some text? >I'm not quite sure what bounding of scope you'd like to see. >all the lifetimes of configuration information defined in MAP DHCP are >bounded by the lifetimes of the tunnel, >i.e. the lifetime of the End-user IPv6 prefix. > >the IPv4 address assignment will be as dynamic as the underlaying IPv6 >assignment is. > >what using DHCPv4 address leases gets you, is separate lease times. given >that, this mode is incompatible with MAP-T and -E, >I'm not quite sure what this document can say about it? > >cheers, >Ole > From otroan@employees.org Mon Nov 11 04:05:49 2013 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 1020A11E816F; Mon, 11 Nov 2013 04:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50GmnOltnypG; Mon, 11 Nov 2013 04:05:42 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id E242411E8167; Mon, 11 Nov 2013 04:05:41 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 051C85EFE; Mon, 11 Nov 2013 04:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=wJHXwRWSXDO81it69X2f6 pu4z9M=; b=BX4pKUieb4XNYJIVkukH9yN9aHgsqXUDn4ZnkxHLcaOepKeTvP7Xb WxcXeaStu641+vgkDDge24HRj1uNjecj4FsU0YeVHzs6FGtdjG1FioOeaHpgQGFp U2ez7ARySn3do+d1gu7YdJ6cR/23Kp+1bWmEfwekJdU1khsfVzxDqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=MzyfYzOewr4xz/w AXImGdv7Q3e83lZ6VADJrCAvwnsohlCo2ctTIBn/OounCxm/KSOPiDuEqh78SDIX U/HVw2KoviWMBQJakkiGliKogLTO3YzxvNFTVqgXrMxQWDkUghI4fcZuKMEGUwma wNMdebzkQ2H7ygJCKHozl7lXgQp8= Received: from [10.16.0.73] (unknown [195.159.143.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 54CC25FCA; Mon, 11 Nov 2013 04:05:36 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_832C59E7-453F-49D9-BA01-EC49CE3C0C20"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Mon, 11 Nov 2013 13:05:33 +0100 Message-Id: <7ABAEBDE-3D30-41FD-903B-75AE4DB6DC59@employees.org> References: To: " Farrer" X-Mailer: Apple Mail (2.1822) Cc: Ian Farrer , Softwires , draft-ietf-softwire-map-dhcp@tools.ietf.org, draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org, "dhcwg@ietf.org WG" Subject: Re: [Softwires] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts 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, 11 Nov 2013 12:05:49 -0000 --Apple-Mail=_832C59E7-453F-49D9-BA01-EC49CE3C0C20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ian, > How about: >=20 > -- > The solution described in this document is suitable for provisioning = IPv4 > addressing and other configuration necessary for establishing softwire > connectivity using DHCPv6. This means that the lifetime of the IPv4 > configuration is bound to the lifetime of the DHCPv6 lease. For MAP-E = and > MAP-T, this is necessary due to the mapping between the IPv4 and the = IPv6 > address. Lightweight 4over6 allows for the de-coupling of the IPv4 and > IPv6 lease times. If this is required, then DHCPv4 over DHCPv6 > [ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address leasing. >=20 > Additional DHCPv4 options are not transported natively in DHCPv6. If = these > are required for client provisioning, then DHCPINFORM transported in > DHCPv4 over DHCPv6 should be used. > =8B >=20 > Does that cover it? yes, that appears good. I'll add that to the next revision if I don't = hear loud objections. cheers, Ole >=20 >> Ian, >>=20 >>> =46rom a discussion with Bernie and Tomeck earlier: To give some = clarity >>> about what the different 4o6 provisioning mechanisms are suitable = for, >>> can we add in some text to bound the scope of map-dhcp to = provisioning >>> static v4 configuration parameters (i.e. precluding dynamic v4 = leasing) >>> with no additional DHCPv4 options and add in an informative pointer = to >>> using DHCPv4 over DHCPv6 for dynamic/additional options? >>>=20 >>> Likewise, I=B9m putting a similar back pointer to MAP-DHCP in the >>> dhc-v4-configuration draft: >>>=20 >>> For the most simple IPv4 provisioning case, where the client only = needs >>> to receive a static IPv4 address range assignment (with no dynamic >>> address leasing or additional IPv4 configuration), DHCPv6 based >>> approaches [ietf-softwire-map-dhcp] may provide a suitable solution. >>>=20 >>> The DHCPv4oDHCPv6 doc should have a similar pointer to map-dhcp for >>> static as well. >>=20 >> could you propose some text? >> I'm not quite sure what bounding of scope you'd like to see. >> all the lifetimes of configuration information defined in MAP DHCP = are >> bounded by the lifetimes of the tunnel, >> i.e. the lifetime of the End-user IPv6 prefix. >>=20 >> the IPv4 address assignment will be as dynamic as the underlaying = IPv6 >> assignment is. >>=20 >> what using DHCPv4 address leases gets you, is separate lease times. = given >> that, this mode is incompatible with MAP-T and -E, >> I'm not quite sure what this document can say about it? >>=20 >> cheers, >> Ole >>=20 >=20 --Apple-Mail=_832C59E7-453F-49D9-BA01-EC49CE3C0C20 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSgMgNAAoJEFuJXizso86gqncH/AneKMGcj+OtANhAG70cbjnA YrIRqMINdq+YMKjU6rFBeuQN3IpfDkvoHYljVu5KUu50wRfjvdj2MWOmHInJKs+B +0wNssxZNlGZ/MjDX7DJML2iz8tMLxLqNA3aGr8t1toiTW6jfgjCl9flCwsiLFYr 58F1S2QxRZkfN0N9IWnSogkjuJOYX5HwGvpBn7ZOau4mQyuLkFFpbBYRmRvAqoVL HNXKj8rlzPR/dqmCf+lxrenBmoz5vng+bhm3amVx6dWxzqXkPNYuAKFFg8gpFh6p uMtrsOiC4npUHs8zNbsaMNKaCePzSE08m0T2lzDwE3/U/gXp5mYOn0ABnoW/hmE= =DKua -----END PGP SIGNATURE----- --Apple-Mail=_832C59E7-453F-49D9-BA01-EC49CE3C0C20-- From wdec@cisco.com Mon Nov 11 04:11:54 2013 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 EC27921E80EC; Mon, 11 Nov 2013 04:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yCMzp3tD7f0; Mon, 11 Nov 2013 04:11:48 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B374121E80A6; Mon, 11 Nov 2013 04:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4082; q=dns/txt; s=iport; t=1384171903; x=1385381503; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dSJN9l5elLvc4zr0owW07ygh3e0NVV7UcNPBQ2YqK3E=; b=cOqBBHYb5m4KiCzVwUaejZMz6XbPmtSfV5OopV2eQ1nLKdw3m9ahf5/4 N+9ujOJF3HYT9dx/2g1x/m70zJU/kpNCd0Iordz2b6+gev6kQ/9E2s5p/ 7iPi3h/mj5kKs5yjXITCAT2pa5JdinXeAzbMoUOhTo8RnrcMIP1chI1ix M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFADnIgFKtJXHA/2dsb2JhbABZgweBC4J0uAOEHBiBIBZ0giUBAQEEIxFABRIBCBgCAh8HAgQwFRABAQQBDQUbh2asAJI+gSmOCxgbB4JrgUUDmA+KRIdGgWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,677,1378857600"; d="scan'208";a="283249596" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 11 Nov 2013 12:11:42 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rABCBf8N025995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 12:11:41 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.196]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 06:11:41 -0600 From: "Wojciech Dec (wdec)" To: "ian.farrer@telekom.de" , "otroan@employees.org" , "ifarrer@me.com" Thread-Topic: ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts Thread-Index: Ac7e1L5mPJ6JmXHYTGG/XjGCLEur0QANLmEA Date: Mon, 11 Nov 2013 12:11:41 +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.3.7.130812 x-originating-ip: [10.61.111.80] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "softwires@ietf.org" , "dhcwg@ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" , "draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org" Subject: Re: [Softwires] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts 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, 11 Nov 2013 12:11:54 -0000 SGksDQoNCk9uIDExLzExLzIwMTMgMTI6NTQsICJpYW4uZmFycmVyQHRlbGVrb20uZGUiIDxpYW4u ZmFycmVyQHRlbGVrb20uZGU+IHdyb3RlOg0KDQo+SGkgT2xlLA0KPg0KPkhvdyBhYm91dDoNCj4N Cj4tLQ0KPlRoZSBzb2x1dGlvbiBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBzdWl0YWJs ZSBmb3IgcHJvdmlzaW9uaW5nIElQdjQNCj5hZGRyZXNzaW5nIGFuZCBvdGhlciBjb25maWd1cmF0 aW9uIG5lY2Vzc2FyeSBmb3IgZXN0YWJsaXNoaW5nIHNvZnR3aXJlDQo+Y29ubmVjdGl2aXR5IHVz aW5nIERIQ1B2Ni4gVGhpcyBtZWFucyB0aGF0IHRoZSBsaWZldGltZSBvZiB0aGUgSVB2NA0KPmNv bmZpZ3VyYXRpb24gaXMgYm91bmQgdG8gdGhlIGxpZmV0aW1lIG9mIHRoZSBESENQdjYgbGVhc2Uu IEZvciBNQVAtRSBhbmQNCj5NQVAtVCwgdGhpcyBpcyBuZWNlc3NhcnkgZHVlIHRvIHRoZSBtYXBw aW5nIGJldHdlZW4gdGhlIElQdjQgYW5kIHRoZSBJUHY2DQo+YWRkcmVzcy4gTGlnaHR3ZWlnaHQg NG92ZXI2IGFsbG93cyBmb3IgdGhlIGRlLWNvdXBsaW5nIG9mIHRoZSBJUHY0IGFuZA0KPklQdjYg bGVhc2UgdGltZXMuIElmIHRoaXMgaXMgcmVxdWlyZWQsIHRoZW4gREhDUHY0IG92ZXIgREhDUHY2 DQo+W2lldGYtZGhjLWRoY3B2NC1vdmVyLWRoY3B2Nl0gc2hvdWxkIGJlIHVzZWQgZm9yIElQdjQg YWRkcmVzcyBsZWFzaW5nLg0KDQpJdCdzIGNsb3NlLCBidXQgbm90IHF1aXRlIGFzIE1BUCBkb2Vz bid0IG1hbmRhdGUgc3RhZ2VmdWwgREhDUCBvZiBhbnkga2luZA0KKFNMQUFDIGNhbiBhbHNvIGJl IHVzZWQpLg0KDQo+DQo+QWRkaXRpb25hbCBESENQdjQgb3B0aW9ucyBhcmUgbm90IHRyYW5zcG9y dGVkIG5hdGl2ZWx5IGluIERIQ1B2Ni4gSWYgdGhlc2UNCj5hcmUgcmVxdWlyZWQgZm9yIGNsaWVu dCBwcm92aXNpb25pbmcsIHRoZW4gREhDUElORk9STSB0cmFuc3BvcnRlZCBpbg0KPkRIQ1B2NCBv dmVyIERIQ1B2NiBzaG91bGQgYmUgdXNlZC4NCg0KSSB3b3VsZCBwcm9wb3NlIHRoYXQgb25seSB0 aGUgYWJvdmUgcGFyYWdyYXBoIGJlIGFkZGVkLCByZXN0YXRlZCBhczoNCg0KQWRkaXRpb25hbCBE SENQdjQgb3B0aW9ucyBhcmUgbm90IHRyYW5zcG9ydGVkIG5hdGl2ZWx5IGluIERIQ1B2Ni4gSWYg dGhlc2UNCmFyZSByZXF1aXJlZCBmb3IgY2xpZW50IHByb3Zpc2lvbmluZywgdGhlbiBESENQSU5G T1JNIHRyYW5zcG9ydGVkIGluDQpESENQdjQgb3ZlciBESENQdjYgW2lldGYtZGhjLWRoY3B2NC1v dmVyLWRoY3B2Nl0gc2hvdWxkIGJlIHVzZWQuDQoNClRoYW5rcywNCldvY2plaWNoLg0KDQoNCg0K PuKAuQ0KPg0KPkRvZXMgdGhhdCBjb3ZlciBpdD8NCj4NCj5DaGVlcnMsDQo+SWFuDQo+DQo+DQo+ DQo+DQo+T24gMDgvMTEvMjAxMyAwMDoyNCwgIk9sZSBUcm9hbiIgPG90cm9hbkBlbXBsb3llZXMu b3JnPiB3cm90ZToNCj4NCj4+SWFuLA0KPj4NCj4+PiBGcm9tIGEgZGlzY3Vzc2lvbiB3aXRoIEJl cm5pZSBhbmQgVG9tZWNrIGVhcmxpZXI6IFRvIGdpdmUgc29tZSBjbGFyaXR5DQo+Pj5hYm91dCB3 aGF0IHRoZSBkaWZmZXJlbnQgNG82IHByb3Zpc2lvbmluZyBtZWNoYW5pc21zIGFyZSBzdWl0YWJs ZSBmb3IsDQo+Pj5jYW4gd2UgYWRkIGluIHNvbWUgdGV4dCB0byBib3VuZCB0aGUgc2NvcGUgb2Yg bWFwLWRoY3AgdG8gcHJvdmlzaW9uaW5nDQo+Pj5zdGF0aWMgdjQgY29uZmlndXJhdGlvbiBwYXJh bWV0ZXJzIChpLmUuIHByZWNsdWRpbmcgZHluYW1pYyB2NCBsZWFzaW5nKQ0KPj4+d2l0aCBubyBh ZGRpdGlvbmFsIERIQ1B2NCBvcHRpb25zIGFuZCBhZGQgaW4gYW4gaW5mb3JtYXRpdmUgcG9pbnRl ciB0bw0KPj4+dXNpbmcgREhDUHY0IG92ZXIgREhDUHY2IGZvciBkeW5hbWljL2FkZGl0aW9uYWwg b3B0aW9ucz8NCj4+PiANCj4+PiBMaWtld2lzZSwgScK5bSBwdXR0aW5nIGEgc2ltaWxhciBiYWNr IHBvaW50ZXIgdG8gTUFQLURIQ1AgaW4gdGhlDQo+Pj5kaGMtdjQtY29uZmlndXJhdGlvbiBkcmFm dDoNCj4+PiANCj4+PiBGb3IgdGhlIG1vc3Qgc2ltcGxlIElQdjQgcHJvdmlzaW9uaW5nIGNhc2Us IHdoZXJlIHRoZSBjbGllbnQgb25seSBuZWVkcw0KPj4+dG8gcmVjZWl2ZSBhIHN0YXRpYyBJUHY0 IGFkZHJlc3MgcmFuZ2UgYXNzaWdubWVudCAod2l0aCBubyBkeW5hbWljDQo+Pj5hZGRyZXNzIGxl YXNpbmcgb3IgYWRkaXRpb25hbCBJUHY0IGNvbmZpZ3VyYXRpb24pLCBESENQdjYgYmFzZWQNCj4+ PmFwcHJvYWNoZXMgW2lldGYtc29mdHdpcmUtbWFwLWRoY3BdIG1heSBwcm92aWRlIGEgc3VpdGFi bGUgc29sdXRpb24uDQo+Pj4gDQo+Pj4gVGhlIERIQ1B2NG9ESENQdjYgZG9jIHNob3VsZCBoYXZl IGEgc2ltaWxhciBwb2ludGVyIHRvIG1hcC1kaGNwIGZvcg0KPj4+c3RhdGljIGFzIHdlbGwuDQo+ Pg0KPj5jb3VsZCB5b3UgcHJvcG9zZSBzb21lIHRleHQ/DQo+PkknbSBub3QgcXVpdGUgc3VyZSB3 aGF0IGJvdW5kaW5nIG9mIHNjb3BlIHlvdSdkIGxpa2UgdG8gc2VlLg0KPj5hbGwgdGhlIGxpZmV0 aW1lcyBvZiBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGRlZmluZWQgaW4gTUFQIERIQ1AgYXJl DQo+PmJvdW5kZWQgYnkgdGhlIGxpZmV0aW1lcyBvZiB0aGUgdHVubmVsLA0KPj5pLmUuIHRoZSBs aWZldGltZSBvZiB0aGUgRW5kLXVzZXIgSVB2NiBwcmVmaXguDQo+Pg0KPj50aGUgSVB2NCBhZGRy ZXNzIGFzc2lnbm1lbnQgd2lsbCBiZSBhcyBkeW5hbWljIGFzIHRoZSB1bmRlcmxheWluZyBJUHY2 DQo+PmFzc2lnbm1lbnQgaXMuDQo+Pg0KPj53aGF0IHVzaW5nIERIQ1B2NCBhZGRyZXNzIGxlYXNl cyBnZXRzIHlvdSwgaXMgc2VwYXJhdGUgbGVhc2UgdGltZXMuIGdpdmVuDQo+PnRoYXQsIHRoaXMg bW9kZSBpcyBpbmNvbXBhdGlibGUgd2l0aCBNQVAtVCBhbmQgLUUsDQo+PkknbSBub3QgcXVpdGUg c3VyZSB3aGF0IHRoaXMgZG9jdW1lbnQgY2FuIHNheSBhYm91dCBpdD8NCj4+DQo+PmNoZWVycywN Cj4+T2xlDQo+Pg0KPg0KDQo= From gnocuil@gmail.com Mon Nov 11 04:27:19 2013 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 30C6021E811B; Mon, 11 Nov 2013 04:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1zo5NbvUwAI; Mon, 11 Nov 2013 04:27:18 -0800 (PST) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2E021E80CA; Mon, 11 Nov 2013 04:27:18 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id t7so1159646qeb.24 for ; Mon, 11 Nov 2013 04:27:17 -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=owtAlpw2w1ExEN66ARHdbaqfEN7tWSPf1F8TV0cQsjs=; b=vS7Vr7vNbkbZKrmJzHv9w/3VgoIvZp8sGxA0YsDUqO7AqS/18F4fY5faPrFqtH2n02 VhT+/KgCtTGJYYdDkuD3BVJgsEMZAS2G9FfbJwG+uHyJGTNnUZr90Ug8kDc2EY5dXha0 QkaYizwWV0Yq5FsblvnDeim+q8FK+bqJA/Oo8qQftxvxZ0iTdblLYwFpmGujUNhqRtp3 3i25vXjgXh+oopqwUVf/0kpQVE8Ss7YQrD5y/THPyhR34xFx1uzLK0V2kIeTZeAPJfWY D8pC7bL9PSl6Sj9iwdF2/QdDQevT8223juylKr5iamWXj6ppoLxQ2MUui3YvACPRoR03 xjmA== X-Received: by 10.49.86.35 with SMTP id m3mr46862951qez.7.1384172837839; Mon, 11 Nov 2013 04:27:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.185.33 with HTTP; Mon, 11 Nov 2013 04:26:57 -0800 (PST) In-Reply-To: References: From: Cong Liu Date: Mon, 11 Nov 2013 20:26:57 +0800 Message-ID: To: "Wojciech Dec (wdec)" Content-Type: multipart/alternative; boundary=047d7bdc7f8a4ea8fc04eae5daad Cc: "ifarrer@me.com" , "draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org" , "softwires@ietf.org" , "dhcwg@ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" Subject: Re: [Softwires] [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts 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, 11 Nov 2013 12:27:19 -0000 --047d7bdc7f8a4ea8fc04eae5daad Content-Type: text/plain; charset=ISO-8859-1 Hi Wocjeich, 2013/11/11 Wojciech Dec (wdec) > >The solution described in this document is suitable for provisioning IPv4 > >addressing and other configuration necessary for establishing softwire > >connectivity using DHCPv6. This means that the lifetime of the IPv4 > >configuration is bound to the lifetime of the DHCPv6 lease. For MAP-E and > >MAP-T, this is necessary due to the mapping between the IPv4 and the IPv6 > >address. Lightweight 4over6 allows for the de-coupling of the IPv4 and > >IPv6 lease times. If this is required, then DHCPv4 over DHCPv6 > >[ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address leasing. > > It's close, but not quite as MAP doesn't mandate stageful DHCP of any kind > (SLAAC can also be used). > I think this paragraph should be added. For your concern, I think the text can be modified to: "This means that the lifetime of the IPv4 configuration is bound to the lifetime of the IPv6 configuration." Best Regards, Cong --047d7bdc7f8a4ea8fc04eae5daad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Wocjeich,

2013/11/11 Wojciech Dec (wdec) <wdec@cisco.com>
=
>The solution described in this document is suitable f= or provisioning IPv4
>addressing and other configuration necessary for establishing softwire<= br> >connectivity using DHCPv6. This means that the lifetime of the IPv4
>configuration is bound to the lifetime of the DHCPv6 lease. For MAP-E a= nd
>MAP-T, this is necessary due to the mapping between the IPv4 and the IP= v6
>address. Lightweight 4over6 allows for the de-coupling of the IPv4 and<= br> >IPv6 lease times. If this is required, then DHCPv4 over DHCPv6
>[ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address leasing.<= br>
It's close, but not quite as MAP doesn't mandate stageful DHC= P of any kind
(SLAAC can also be used).

I think this = paragraph should be added.=A0
For your concern, I think= the text can be modified to:
=A0 "This means that the= lifetime of the IPv4 configuration is bound to the lifetime of the IPv6 co= nfiguration."

Best Regards,
Cong
--047d7bdc7f8a4ea8fc04eae5daad-- From wdec@cisco.com Mon Nov 11 04:38:58 2013 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 C43F311E8168; Mon, 11 Nov 2013 04:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad9NZXlLPZrG; Mon, 11 Nov 2013 04:38:31 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7E18511E80FA; Mon, 11 Nov 2013 04:38:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7853; q=dns/txt; s=iport; t=1384173511; x=1385383111; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=1novzavmifHP+HkfQjrmFYDcqt/8IOjF8v190QphoTI=; b=G2x5AZ4dKc5T3P3fdcau+2kyNhqQykoRBya+qFqQLnIBQGui+8hlDFkS iVdgC4M5YUh288+0zNBX2Vr5Uv/Ab/H4crMf3nw7fVIHns0VxVptJbYuI 6AvbF8jPtuWMGsbaAZcvtdgQKQiLdXZU1XfO5Pk3WE12Eis8NqkVzy+2z Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAEnOgFKtJV2a/2dsb2JhbABZgkNEgQu6d4QcgTkWdIIlAQIEdAUSAQgOAwMBAiQEKBEUCQgBAQQOBRuHVAMPtEcNiWuMdYJhEQeEMAOWJIFrikSCDoU4gWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,677,1378857600"; d="scan'208,217";a="283248393" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 11 Nov 2013 12:38:29 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rABCcSfC018762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 12:38:29 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.196]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 06:38:28 -0600 From: "Wojciech Dec (wdec)" To: Cong Liu Thread-Topic: [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts Thread-Index: Ac7e1L5mPJ6JmXHYTGG/XjGCLEur0QANLmEAAACIpYAAAGarAA== Date: Mon, 11 Nov 2013 12:38:27 +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.3.7.130812 x-originating-ip: [10.61.111.80] Content-Type: multipart/alternative; boundary="_000_CEA68D8DB4425wdecciscocom_" MIME-Version: 1.0 Cc: "ifarrer@me.com" , "draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org" , "softwires@ietf.org" , "dhcwg@ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" Subject: Re: [Softwires] [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts 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, 11 Nov 2013 12:39:15 -0000 --_000_CEA68D8DB4425wdecciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Cong Liu > Date: Monday, 11 November 2013 05:26 To: Wojciech Dec > Cc: "ian.farrer@telekom.de" >, "otroan@employees.org" >, "ifarre= r@me.com" >, "= softwires@ietf.org" >, "dhcwg@ietf.org" >, "draft-ietf-softwire-map-dhcp@tools.ietf.org" >, "= draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org" > Subject: Re: [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between = softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts Hi Wocjeich, 2013/11/11 Wojciech Dec (wdec) > >The solution described in this document is suitable for provisioning IPv4 >addressing and other configuration necessary for establishing softwire >connectivity using DHCPv6. This means that the lifetime of the IPv4 >configuration is bound to the lifetime of the DHCPv6 lease. For MAP-E and >MAP-T, this is necessary due to the mapping between the IPv4 and the IPv6 >address. Lightweight 4over6 allows for the de-coupling of the IPv4 and >IPv6 lease times. If this is required, then DHCPv4 over DHCPv6 >[ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address leasing. It's close, but not quite as MAP doesn't mandate stageful DHCP of any kind (SLAAC can also be used). I think this paragraph should be added. For your concern, I think the text can be modified to: "This means that the lifetime of the IPv4 configuration is bound to the l= ifetime of the IPv6 configuration." Well, not quite: The lifetime of the IPv4 configuration in MAP *can*, but d= oesn't have to be bound the IPv6 configuration. As I said before, I do not think that the above "explanatory" text is suita= ble for this specification. The essence is that if someone want to use DHCP= v4 (for DHCPv4 options, or DHCPv4 leases) then they should use DHCPv4 over = DHCPv6. -Wojciech. Best Regards, Cong --_000_CEA68D8DB4425wdecciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5A2E1FC08005FA479D2DE4880A745BBB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


From: Cong Liu <gnocuil@gmail.com>
Date: Monday, 11 November 2013 05:2= 6
To: Wojciech Dec <wdec@cisco.com>
Cc: "ian.farrer@telekom.de" <ian.farrer@telekom.de>, "otroan@employees.org" <otroan@employees.org>, "ifarrer@me.com" <ifarrer@me.com>, "softwires@ietf.org" <softwires@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>, "draft-ietf-softwir= e-map-dhcp@tools.ietf.org" <draft-ietf-softwire-map-dhcp@tools.ietf.org= >, "= draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org" <draft-ietf-dhc-dhcp= v4-over-dhcpv6@tools.ietf.org>
Subject: Re: [dhcwg] ***CAUTION_Inv= alid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-ov= er-dhcpv6 drafts

Hi Wocjeich,

2013/11/11 Wojciech Dec (wdec) <wdec@cisco.com= >
>The solution described in this document is suitable f= or provisioning IPv4
>addressing and other configuration necessary for establishing softwire<= br> >connectivity using DHCPv6. This means that the lifetime of the IPv4
>configuration is bound to the lifetime of the DHCPv6 lease. For MAP-E a= nd
>MAP-T, this is necessary due to the mapping between the IPv4 and the IP= v6
>address. Lightweight 4over6 allows for the de-coupling of the IPv4 and<= br> >IPv6 lease times. If this is required, then DHCPv4 over DHCPv6
>[ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address leasing.<= br>
It's close, but not quite as MAP doesn't mandate stageful DHCP of any kind<= br> (SLAAC can also be used).

I think this paragraph should be added. 
For your concern, I think the text can be modified to:
  "This means that the lifetime of the IPv4 confi= guration is bound to the lifetime of the IPv6 configuration."

Well, not quite: The lifetime of the IPv4 configuration in MAP *can*, = but doesn't have to be bound the IPv6 configuration.
As I said before, I do not think that the above "explanatory"= ; text is suitable for this specification. The essence is that if someone w= ant to use DHCPv4 (for DHCPv4 options, or DHCPv4 leases) then they should u= se DHCPv4 over DHCPv6. 

-Wojciech.


Best Regards,
Cong
 --_000_CEA68D8DB4425wdecciscocom_-- From ian.farrer@telekom.de Mon Nov 11 06:04:28 2013 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 AF3E721E80C7; Mon, 11 Nov 2013 06:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QKr+bzi+6uZ; Mon, 11 Nov 2013 06:04:23 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 3048121E81E0; Mon, 11 Nov 2013 06:04:13 -0800 (PST) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 11 Nov 2013 15:03:59 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.39]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 11 Nov 2013 15:03:59 +0100 From: To: , Date: Mon, 11 Nov 2013 15:03:56 +0100 Thread-Topic: [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts Thread-Index: Ac7e5tyu/9zNWzCkT8mxt7MNoViGlQ== Message-ID: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CEA69EED900C2ianfarrertelekomde_" MIME-Version: 1.0 Cc: ifarrer@me.com, draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org, softwires@ietf.org, dhcwg@ietf.org, draft-ietf-softwire-map-dhcp@tools.ietf.org Subject: Re: [Softwires] [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts 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, 11 Nov 2013 14:04:28 -0000 --_000_CEA69EED900C2ianfarrertelekomde_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Woj, I think that we need to have a pointer (see comments below). What about if = the text read: The solution described in this document is suitable for provisioning IPv4 a= ddressing and other configuration necessary for solely for establishing sof= twire connectivity using DHCPv6. This means that the lifetime of the IPv4 c= onfiguration is bound to the lifetime of the DHCPv6 lease. If de-coupling o= f IPv4 and IPv6 lease times is required, then DHCPv4 over DHCPv6 [ietf-dhc-= dhcpv4-over-dhcpv6] should be used, although extensions may be required to = provision the necessary parameters for all softwire mechanisms. Additional DHCPv4 options are not transported natively in DHCPv6. If these = are required for client provisioning, then DHCPINFORM transported in DHCPv4= over DHCPv6 should be used. Cheers Ian Hi Wocjeich, 2013/11/11 Wojciech Dec (wdec) > >The solution described in this document is suitable for provisioning IPv4 >addressing and other configuration necessary for establishing softwire >connectivity using DHCPv6. This means that the lifetime of the IPv4 >configuration is bound to the lifetime of the DHCPv6 lease. For MAP-E and >MAP-T, this is necessary due to the mapping between the IPv4 and the IPv6 >address. Lightweight 4over6 allows for the de-coupling of the IPv4 and >IPv6 lease times. If this is required, then DHCPv4 over DHCPv6 >[ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address leasing. It's close, but not quite as MAP doesn't mandate stageful DHCP of any kind (SLAAC can also be used). [ian] But the draft only describes MAP provisioning related to stateful DHC= P, so it doesn=92t make any requirements for how it would work if it was st= ateless. I think this paragraph should be added. For your concern, I think the text can be modified to: "This means that the lifetime of the IPv4 configuration is bound to the l= ifetime of the IPv6 configuration." Well, not quite: The lifetime of the IPv4 configuration in MAP *can*, but d= oesn't have to be bound the IPv6 configuration. [ian] The point here is that if you=92re provisioning any softwire over DHC= Pv6, then they=92re coupled. If you want to decouple, then it needs to be D= HCPv4 over DHCPv6. We could always open up the proposed wording so that it = is applicable to any softwire mechanism (I only put in the limitation at Ol= e=92s behest). As I said before, I do not think that the above "explanatory" text is suita= ble for this specification. The essence is that if someone want to use DHCP= v4 (for DHCPv4 options, or DHCPv4 leases) then they should use DHCPv4 over = DHCPv6. [ian] The reason that I requested it is that Bernie and Tomeck don=92t want= the map-dhcp draft to become a basis that people will then try and extend = with DHCPv4 options in the future. --_000_CEA69EED900C2ianfarrertelekomde_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Woj,

I think that we need to have a pointer (see comments= below). What about if the text read:

The solution described in= this document is suitable for provisioning IPv4 addressing and other confi= guration necessary for solely for establishing softwire connectivity using = DHCPv6. This means that the lifetime of the IPv4 configuration is bound to = the lifetime of the DHCPv6 lease. If de-coupling of IPv4 and IPv6 lease tim= es is required, then DHCPv4 over DHCPv6 [ietf-dhc-dhcpv4-over-dhcpv6] shoul= d be used, although extensions may be required to provision the necessary p= arameters for all softwire mechanisms.

Additional DHCPv4 options are not transported = natively in DHCPv6. If these are required for client provisioning, then DHC= PINFORM transported in DHCPv4 over DHCPv6 should be used.

Cheers
Ian


Hi Wocjeich,

2013/11/11 Wojcie= ch Dec (wdec) <wdec@cisco.com>
>The solution described in this document is suitable for provisi= oning IPv4
>addressing and other configuration necessary for establishing softwire<= br> >connectivity using DHCPv6. This means that the lifetime of the IPv4
>configuration is bound to the lifetime of the DHCPv6 lease. For MAP-E a= nd
>MAP-T, this is necessary due to the mapping between the IPv4 and the IP= v6
>address. Lightweight 4over6 allows for the de-coupling of the IPv4 and<= br> >IPv6 lease times. If this is required, then DHCPv4 over DHCPv6
>[ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address leasing.<= br>
It's close, but not quite as MAP doesn't mandate stageful DHCP of any kind<= br> (SLAAC can also be used).
=

[ian] But the draft only describes M= AP provisioning related to stateful DHCP, so it doesn=92t make any requirem= ents for how it would work if it was stateless.

I think this paragraph should be added. 
For your concern, I think the text can be modified = to:
  "This means that the lifetime of the I= Pv4 configuration is bound to the lifetime of the IPv6 configuration."=

Well, not qu= ite: The lifetime of the IPv4 configuration in MAP *can*, but doesn't have = to be bound the IPv6 configuration.

=
[ian] The point here is that if you=92re provisioning any softwire ove= r DHCPv6, then they=92re coupled. If you want to decouple, then it needs to= be DHCPv4 over DHCPv6. We could always open up the proposed wording so tha= t it is applicable to any softwire mechanism (I only put in the limitation = at Ole=92s behest).

<= div>
As I said before, I do not think that th= e above "explanatory" text is suitable for this specification. Th= e essence is that if someone want to use DHCPv4 (for DHCPv4 options, or DHC= Pv4 leases) then they should use DHCPv4 over DHCPv6. 

[ian] The reason that I requested it is that Be= rnie and Tomeck don=92t want the map-dhcp draft to become a basis that peop= le will then try and extend with DHCPv4 options in the future.

 --_000_CEA69EED900C2ianfarrertelekomde_-- From sunqi.csnet.thu@gmail.com Mon Nov 11 06:12:50 2013 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 65E4211E8172; Mon, 11 Nov 2013 06:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy9lqKy3dXEU; Mon, 11 Nov 2013 06:12:49 -0800 (PST) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id AE44611E80FA; Mon, 11 Nov 2013 06:12:49 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id xa7so5254350pbc.24 for ; Mon, 11 Nov 2013 06:12:49 -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; bh=ovN7qtmW4a+1MQOgvDnySzyUFbfr0neMmogrXmRDOBU=; b=lWY1YFdz2fplvnJmz65suA2vVdKTb2PdJWxy15wsZ0TqTbIU8yiHj8WOrReb/QEWHH YwblhXZ0WwI0DbfgTk8iVMkJqVBCWLnY8D81Z+/rSkADKx46X4cuyh2r2uucBqtFtftq 28Yi8gMuP61u5vonBCVjbyk5fRhmvKlqdHDpgr2t0jLCi+U9myLLzIFtexpV9heuCDha oMT0Dz1hN87rC8MUAcYrsO7/NMJ27mG9F3yoh4eJUTQ8SfxTIoUcMV7WkgMzkENfnQbi MGVX5RCOdru2clKnOET8ozw13OYREaJHBWibwR/kME7GUZlZObhWkR/QscyFgc8b4SnP 99kA== X-Received: by 10.68.232.3 with SMTP id tk3mr30535172pbc.121.1384179169539; Mon, 11 Nov 2013 06:12:49 -0800 (PST) Received: from [192.168.1.103] ([114.255.40.8]) by mx.google.com with ESMTPSA id hz10sm31119258pbc.36.2013.11.11.06.12.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Nov 2013 06:12:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-2--2455148 From: Qi Sun In-Reply-To: Date: Mon, 11 Nov 2013 22:12:34 +0800 Message-Id: <6310F23E-98B9-4C27-9CB3-AD36FE84F493@gmail.com> References: To: Wojciech Dec (wdec) X-Mailer: Apple Mail (2.1085) Cc: "ifarrer@me.com" , "draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org" , "softwires@ietf.org" , "dhcwg@ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" Subject: Re: [Softwires] [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts 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, 11 Nov 2013 14:12:50 -0000 --Apple-Mail-2--2455148 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Woj, >=20 > 2013/11/11 Wojciech Dec (wdec) >> >The solution described in this document is suitable for provisioning = IPv4 >> >addressing and other configuration necessary for establishing = softwire >> >connectivity using DHCPv6. This means that the lifetime of the IPv4 >> >configuration is bound to the lifetime of the DHCPv6 lease. For = MAP-E and >> >MAP-T, this is necessary due to the mapping between the IPv4 and the = IPv6 >> >address. Lightweight 4over6 allows for the de-coupling of the IPv4 = and >> >IPv6 lease times. If this is required, then DHCPv4 over DHCPv6 >> >[ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address = leasing. >>=20 >> It's close, but not quite as MAP doesn't mandate stageful DHCP of any = kind >> (SLAAC can also be used). >=20 > I think this paragraph should be added.=20 > For your concern, I think the text can be modified to: > "This means that the lifetime of the IPv4 configuration is bound to = the lifetime of the IPv6 configuration." >=20 > Well, not quite: The lifetime of the IPv4 configuration in MAP *can*, = but doesn't have to be bound the IPv6 configuration. [Qi] Could you please elaborate? This is what I found in = draft-ietf-softwire-map-08: The MAP provisioning parameters, and hence the IPv4 service itself, is tied to the End-user IPv6 prefix lease; thus, the MAP service is also tied to this in terms of authorization, accounting, etc. The MAP IPv4 address, prefix or shared IPv4 address and port set has the same lifetime as its associated End-user IPv6 prefix. > The essence is that if someone want to use DHCPv4 (for DHCPv4 options, = or DHCPv4 leases) then they should use DHCPv4 over DHCPv6.=20 [Qi] As I see, the text proposed reflects this essence (dynamic IPv4 = address leasing and DHCPv4 options). Best Regards, Qi --Apple-Mail-2--2455148 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Woj,


2013/11/11 Wojciech Dec (wdec) <wdec@cisco.com>
>The solution described in this document is suitable for provisioning IPv4
>addressing and other configuration necessary for establishing softwire
>connectivity using DHCPv6. This means that the lifetime of the IPv4
>configuration is bound to the lifetime of the DHCPv6 lease. For MAP-E and
>MAP-T, this is necessary due to the mapping between the IPv4 and the IPv6
>address. Lightweight 4over6 allows for the de-coupling of the IPv4 and
>IPv6 lease times. If this is required, then DHCPv4 over DHCPv6
>[ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address leasing.

It's close, but not quite as MAP doesn't mandate stageful DHCP of any kind
(SLAAC can also be used).

I think this paragraph should be added. 
For your concern, I think the text can be modified to:
  "This means that the lifetime of the IPv4 configuration is bound to the lifetime of the IPv6 configuration."

Well, not quite: The lifetime of the IPv4 configuration in MAP *can*, but doesn't have to be bound the IPv6 configuration.

[Qi] Could you please elaborate? This is what I found in draft-ietf-softwire-map-08:

   The MAP provisioning parameters, and hence the IPv4 service itself,
   is tied to the End-user IPv6 prefix lease; thus, the MAP service is
   also tied to this in terms of authorization, accounting, etc.  The
   MAP IPv4 address, prefix or shared IPv4 address and port set has the
   same lifetime as its associated End-user IPv6 prefix.


The essence is that if someone want to use DHCPv4 (for DHCPv4 options, or DHCPv4 leases) then they should use DHCPv4 over DHCPv6. 

[Qi] As I see, the text proposed reflects this essence (dynamic IPv4 address leasing  and DHCPv4 options).

Best Regards,
Qi

--Apple-Mail-2--2455148-- From otroan@employees.org Mon Nov 11 06:17:18 2013 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 CE1B521E81F1; Mon, 11 Nov 2013 06:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnAdMOifj+La; Mon, 11 Nov 2013 06:17:13 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7241B21E81E5; Mon, 11 Nov 2013 06:17:09 -0800 (PST) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 33DCA5FD0; Mon, 11 Nov 2013 06:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=mrhBiLrmeJi0nH77CWZg+ cynLmo=; b=RlKrPbIYK8b9j15GjdmIlDgKM+h5oAIKAluYSQII4Kxatamz8C1KM YGPjnnw5mk6nj+OaAFVWwEGq0ZmXDNwjfl6auQWRTA3w/5Iblwozdp7N2HZPYH9x DTFtlfjMcMPAlDJ643ntcYS5qxyA+jnyYHXMHP4VJHQWyR+AbKoNtc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=h1UNbkGZl3APQHF FcYRP0zR2d1kkdpEWio2MSakz++FblPeIAZtRplG7t6ytkmEtZAUPTPwhcGDfQTt /cQ8mOyEu3ELIHGx9q0PF2MZamQCRKtNndfUJ6BhW6ES90kJTsPBcGzfKsfcc/nS wLRYPIe5R0BsRQ2oLmW79z+dboV8= Received: from [10.16.0.73] (unknown [195.159.143.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 89A496005; Mon, 11 Nov 2013 06:17:03 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_5B554D24-3E6D-4654-A17C-D11AB7C93D75"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Mon, 11 Nov 2013 15:16:59 +0100 Message-Id: <91F0E749-0AC9-490A-BF76-820B94AFD411@employees.org> References: To: " Farrer" X-Mailer: Apple Mail (2.1822) Cc: Ian Farrer , draft-ietf-softwire-map-dhcp@tools.ietf.org, draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org, Softwires , "dhcwg@ietf.org WG" , "Wojciech Dec \(wdec\)" Subject: Re: [Softwires] [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts 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, 11 Nov 2013 14:17:19 -0000 --Apple-Mail=_5B554D24-3E6D-4654-A17C-D11AB7C93D75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ian, > I think that we need to have a pointer (see comments below). What = about if the text read: why do you think a pointer is required? what about simply: " This document describes DHCPv6 options that are used to provision IPv4 = over IPv6 softwires. The lifetime of the softwire and the derived configuration information (e.g. IPv4 shared address, = IPv4 address or prefix) is bound to the lifetime of the DHCPv6 lease. Other IPv4 configuration information must be provisioned using DHCPv4. " cheers, Ole > The solution described in this document is suitable for provisioning = IPv4 addressing and other configuration necessary for solely for = establishing softwire connectivity using DHCPv6. This means that the = lifetime of the IPv4 configuration is bound to the lifetime of the = DHCPv6 lease. If de-coupling of IPv4 and IPv6 lease times is required, = then DHCPv4 over DHCPv6 [ietf-dhc-dhcpv4-over-dhcpv6] should be used, = although extensions may be required to provision the necessary = parameters for all softwire mechanisms. >=20 > Additional DHCPv4 options are not transported natively in DHCPv6. If = these are required for client provisioning, then DHCPINFORM transported = in DHCPv4 over DHCPv6 should be used. >=20 > Cheers > Ian >=20 >=20 > Hi Wocjeich, >=20 > 2013/11/11 Wojciech Dec (wdec) >> >The solution described in this document is suitable for provisioning = IPv4 >> >addressing and other configuration necessary for establishing = softwire >> >connectivity using DHCPv6. This means that the lifetime of the IPv4 >> >configuration is bound to the lifetime of the DHCPv6 lease. For = MAP-E and >> >MAP-T, this is necessary due to the mapping between the IPv4 and the = IPv6 >> >address. Lightweight 4over6 allows for the de-coupling of the IPv4 = and >> >IPv6 lease times. If this is required, then DHCPv4 over DHCPv6 >> >[ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address = leasing. >>=20 >> It's close, but not quite as MAP doesn't mandate stageful DHCP of any = kind >> (SLAAC can also be used). >=20 > [ian] But the draft only describes MAP provisioning related to = stateful DHCP, so it doesn=92t make any requirements for how it would = work if it was stateless. >=20 > I think this paragraph should be added.=20 > For your concern, I think the text can be modified to: > "This means that the lifetime of the IPv4 configuration is bound to = the lifetime of the IPv6 configuration." >=20 > Well, not quite: The lifetime of the IPv4 configuration in MAP *can*, = but doesn't have to be bound the IPv6 configuration. >=20 > [ian] The point here is that if you=92re provisioning any softwire = over DHCPv6, then they=92re coupled. If you want to decouple, then it = needs to be DHCPv4 over DHCPv6. We could always open up the proposed = wording so that it is applicable to any softwire mechanism (I only put = in the limitation at Ole=92s behest). >=20 > As I said before, I do not think that the above "explanatory" text is = suitable for this specification. The essence is that if someone want to = use DHCPv4 (for DHCPv4 options, or DHCPv4 leases) then they should use = DHCPv4 over DHCPv6.=20 >=20 > [ian] The reason that I requested it is that Bernie and Tomeck don=92t = want the map-dhcp draft to become a basis that people will then try and = extend with DHCPv4 options in the future. >=20 --Apple-Mail=_5B554D24-3E6D-4654-A17C-D11AB7C93D75 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSgObbAAoJEFuJXizso86gwbIIAM/Z2xQ4E8fhoWljXdVC+QvV BLhDHAnOHJC0sg34r9lN/JTqTZuM8GqDCAcXxlbxfiVtDufUyJz6B7Mck04ub69g DQoGPwKvzL8sViq6syKU/2aNz1lqB2V4WFls/rwusqh7iE+iMIlvXRHzcFCl2rtF aX225GDOOHfPzEy7cyCBjEUUh4XTp6Z4MPpMJ0nJJTqV+aOS2tWeZgIgrVfgMCNh NOaeQd8sJgB/DgbLbGwDjnUh6Uy1p4aR5M4kbTeMSsFRGF98JQbJn6XILZCt40pq iuUolNQtM01DPFeA5EULGrtkX0C4npHiYNUhMvrO1xcQx0l0leaNEP1ypLgSnsI= =jN+I -----END PGP SIGNATURE----- --Apple-Mail=_5B554D24-3E6D-4654-A17C-D11AB7C93D75-- From wdec@cisco.com Mon Nov 11 06:29:12 2013 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 7642B21E81E1; Mon, 11 Nov 2013 06:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvESq1DDzFUW; Mon, 11 Nov 2013 06:29:06 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DB50721E815D; Mon, 11 Nov 2013 06:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11724; q=dns/txt; s=iport; t=1384180145; x=1385389745; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=ho/cagXUk8vGM8T6cXlFvvjz8AWP/CidNJmVsphm+Ng=; b=FMAQdrq8uFoIIfn5oaNYihF/YRCSYNaQvVFirOcGGo7BU7FLD0c/0FT5 DT7mPS5uXZoaZQeJiYReFSeIshTFCITtvBMl66evgZBR7eU601CxvhbMh viqv/3yzhbJPWGCDqVrkF+BLzJZWIq+27Y0BBAF1djlwsftd8RJjzOp/B k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAETpgFKtJV2c/2dsb2JhbABZgkNEgQu6doQggToWdIIlAQIEdAUSAQgRAQIBAiQEKBEUAwYIAgQOBRuHVAMPtGoNiRWMdYJhEQeEMAOWJIFrikSCDoU4gWiBPoIq X-IronPort-AV: E=Sophos;i="4.93,678,1378857600"; d="scan'208,217";a="283284855" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 11 Nov 2013 14:28:57 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rABESu3Q025427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 14:28:56 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.196]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 08:28:56 -0600 From: "Wojciech Dec (wdec)" To: Qi Sun Thread-Topic: [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts Thread-Index: AQHO3ughxYfCJGE8TUOS7KT4AGI6pZoge3iA Date: Mon, 11 Nov 2013 14:28:56 +0000 Message-ID: In-Reply-To: <6310F23E-98B9-4C27-9CB3-AD36FE84F493@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.61.109.36] Content-Type: multipart/alternative; boundary="_000_CEA6A523B4443wdecciscocom_" MIME-Version: 1.0 Cc: "ifarrer@me.com" , "draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org" , "softwires@ietf.org" , "dhcwg@ietf.org" , "draft-ietf-softwire-map-dhcp@tools.ietf.org" Subject: Re: [Softwires] [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts 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, 11 Nov 2013 14:29:12 -0000 --_000_CEA6A523B4443wdecciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The descriptive text that was proposed is not essential to the spec (about = a stateless DHCPv6 option), nor to comprehend it, (nor to comprehend MAP fo= r that matter). The essence really is that, "if you one need DHCPv4 leases,= use DHCPv4". This point has nothing to do with how MAP does or does not us= e stateful dhcp, etc. Re your questions, most of the answers point the way back to MAP 1:1 mode, = where whichever way it is done, the IPv4 address does NOT need to be couple= d to the IPv6 address. Thanks for bringing out the issue in draft-08, which ought to be fixed befo= re publishing: The MAP architecture requires an IPv6 prefix for the CE. It = does NOT dictate how that prefix is provisioned, and whether it is stateful= or not. An RA or DHCP-PD prefix, or static config are all fine here (thoug= h some may prefer dhcp say). Thanks, Wojciech. From: Qi Sun > Date: Monday, 11 November 2013 07:12 To: Wojciech Dec > Cc: Cong Liu >, "ian.farrer@tel= ekom.de" >, "otroan@employees.org" >, "ifarrer@me.com" >, "softwires@ietf.org<= mailto:softwires@ietf.org>" >= , "dhcwg@ietf.org" >, "draft-ietf-softwire-map-dhcp@tools.ietf.org" >, "draft-ietf-dhc-dhcp= v4-over-dhcpv6@tools.ietf.org" > Subject: Re: [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between = softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts Hi Woj, 2013/11/11 Wojciech Dec (wdec) > >The solution described in this document is suitable for provisioning IPv4 >addressing and other configuration necessary for establishing softwire >connectivity using DHCPv6. This means that the lifetime of the IPv4 >configuration is bound to the lifetime of the DHCPv6 lease. For MAP-E and >MAP-T, this is necessary due to the mapping between the IPv4 and the IPv6 >address. Lightweight 4over6 allows for the de-coupling of the IPv4 and >IPv6 lease times. If this is required, then DHCPv4 over DHCPv6 >[ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address leasing. It's close, but not quite as MAP doesn't mandate stageful DHCP of any kind (SLAAC can also be used). I think this paragraph should be added. For your concern, I think the text can be modified to: "This means that the lifetime of the IPv4 configuration is bound to the l= ifetime of the IPv6 configuration." Well, not quite: The lifetime of the IPv4 configuration in MAP *can*, but d= oesn't have to be bound the IPv6 configuration. [Qi] Could you please elaborate? This is what I found in draft-ietf-softwir= e-map-08: The MAP provisioning parameters, and hence the IPv4 service itself, is tied to the End-user IPv6 prefix lease; thus, the MAP service is also tied to this in terms of authorization, accounting, etc. The MAP IPv4 address, prefix or shared IPv4 address and port set has the same lifetime as its associated End-user IPv6 prefix. The essence is that if someone want to use DHCPv4 (for DHCPv4 options, or D= HCPv4 leases) then they should use DHCPv4 over DHCPv6. [Qi] As I see, the text proposed reflects this essence (dynamic IPv4 addres= s leasing and DHCPv4 options). Best Regards, Qi --_000_CEA6A523B4443wdecciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
The descriptive text that was proposed is not essential to the spec (a= bout a stateless DHCPv6 option), nor to comprehend it, (nor to comprehend M= AP for that matter). The essence really is that, "if you one need DHCP= v4 leases, use DHCPv4". This point has nothing to do with how MAP does or does not use stateful dhcp, etc.

Re your questions, most of the answers point the way back to MAP 1:1 m= ode, where whichever way it is done, the IPv4 address does NOT need to be c= oupled to the IPv6 address. 

Thanks for bringing out the issue in draft-08, which ought to be fixed= before publishing: The MAP architecture requires an IPv6 prefix for t= he CE. It does NOT dictate how that prefix is provisioned, and whether it i= s stateful or not. An RA or DHCP-PD prefix, or static config are all fine here (though some may prefer dhcp say). = ;

Thanks,
Wojciech.


Hi Woj,


2013/11/11 Wojciech Dec (wdec) <wdec@cisco.com= >
>The solution described in this document is suitable f= or provisioning IPv4
>addressing and other configuration necessary for establishing softwire<= br> >connectivity using DHCPv6. This means that the lifetime of the IPv4
>configuration is bound to the lifetime of the DHCPv6 lease. For MAP-E a= nd
>MAP-T, this is necessary due to the mapping between the IPv4 and the IP= v6
>address. Lightweight 4over6 allows for the de-coupling of the IPv4 and<= br> >IPv6 lease times. If this is required, then DHCPv4 over DHCPv6
>[ietf-dhc-dhcpv4-over-dhcpv6] should be used for IPv4 address leasing.<= br>
It's close, but not quite as MAP doesn't mandate stageful DHCP of any kind<= br> (SLAAC can also be used).

I think this paragraph should be added. 
For your concern, I think the text can be modified to:
  "This means that the lifetime of the IPv4 confi= guration is bound to the lifetime of the IPv6 configuration."

Well, not quite: The lifetime of the IPv4 configuration in MAP *can*, = but doesn't have to be bound the IPv6 configuration.

[Qi] Could you please elaborate? This is what I found in draft-ie= tf-softwire-map-08:

   The MAP provisioning parameters, and hence the IPv4 service itself=
,
   is tied to the End-user IPv6 prefix lease; thus, the MAP service is
   also tied to this in terms of authorization, accounting, etc.  The
   MAP IPv4 address, prefix or shared IPv4 address and port set has the
   same lifetime as its associated End-user IPv6 prefix.


The essence is that if someone want to use DHCPv4 (for DHCPv4 options,= or DHCPv4 leases) then they should use DHCPv4 over DHCPv6. 

[Qi] As I see, the text proposed reflects this essence (dynamic IPv4 a= ddress leasing  and DHCPv4 options).

Best Regards,
Qi

 --_000_CEA6A523B4443wdecciscocom_-- From wwwrun@rfc-editor.org Mon Nov 11 17:29:59 2013 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 44C8311E817D; Mon, 11 Nov 2013 17:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo9ZvJt9bBB4; Mon, 11 Nov 2013 17:29:58 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 77BD311E80F9; Mon, 11 Nov 2013 17:29:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2DF4B75E015; Mon, 11 Nov 2013 17:20:11 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131112012011.2DF4B75E015@rfc-editor.org> Date: Mon, 11 Nov 2013 17:20:11 -0800 (PST) Cc: softwires@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: [Softwires] RFC 7040 on Public IPv4-over-IPv6 Access Network 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, 12 Nov 2013 01:29:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7040 Title: Public IPv4-over-IPv6 Access Network Author: Y. Cui, J. Wu, P. Wu, O. Vautrin, Y. Lee Status: Informational Stream: IETF Date: November 2013 Mailbox: yong@csnet1.cs.tsinghua.edu.cn, jianping@cernet.edu.cn, pengwu.thu@gmail.com, Olivier@juniper.net, yiu_lee@cable.comcast.com Pages: 13 Characters: 27273 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-softwire-public-4over6-10.txt URL: http://www.rfc-editor.org/rfc/rfc7040.txt This document describes a mechanism called Public 4over6, which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses. Public 4over6 was developed in the IETF and is in use in some existing deployments but is not recommended for new deployments. Future deployments of similar scenarios should use Lightweight 4over6. Public 4over6 follows the Hub and Spoke softwire model and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over an IPv6 access network. The bidirectionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users and by maintaining IPv4-IPv6 address binding on the border relay. Public 4over6 aims to provide uninterrupted IPv4 services to users, like Internet Content Providers (ICPs), etc., while an operator makes the access network transition to an IPv6-only access network. This document is a product of the Softwires Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From gnocuil@gmail.com Tue Nov 12 04:27:17 2013 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 AED5E21E80BC; Tue, 12 Nov 2013 04:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYg7xWzUBXUk; Tue, 12 Nov 2013 04:27:05 -0800 (PST) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id AA1E911E8105; Tue, 12 Nov 2013 04:27:04 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id k4so2767896qaq.12 for ; Tue, 12 Nov 2013 04:27:04 -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=efV9DbVjhZJbDGa0Ixy/zLO2nZJfGsgHE9pdGaT3DSU=; b=Z68OcvcpJbPg4IHB/AygvG9GCVO73jpcjLj7yqIFm5SuWLSZtQNhjeZwlyABZaZSNe 79jlmL2fmN+g2xCVrc6zw54b8xns3anmLDBgLxYYWDElz6x3Yybv3g7ApNV8avZp1M+b Nnrrj7JKabdO+FOeLnW4YrioM+Cxr0pdbvEflpZm/TglXUImD2zherWU3gcCis4yZogP mLcvtDozpwvFOTFNJxiJnkOn6up1JTxwZoMR2HCM7iDEmqLZQOxIp/3bC/tWi1KAd7Mt ZBwfpWCp2llPjSJj8nBylVbBYfNWlzwPl7PMT/I67lGR9mKNQwCgIzGb+hm8dp0YJgEf /1Qg== X-Received: by 10.49.82.52 with SMTP id f20mr55785022qey.73.1384259224078; Tue, 12 Nov 2013 04:27:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.185.33 with HTTP; Tue, 12 Nov 2013 04:26:44 -0800 (PST) In-Reply-To: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> References: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> From: Cong Liu Date: Tue, 12 Nov 2013 20:26:44 +0800 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=047d7b5dbf4c54157d04eaf9f7eb Cc: Softwires , "dhcwg@ietf.org WG" , "ietf@ietf.org Discussion" Subject: Re: [Softwires] [dhcwg] We can change the world in a 1000 ways (IPv4 over IPv6) 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, 12 Nov 2013 12:27:17 -0000 --047d7b5dbf4c54157d04eaf9f7eb Content-Type: text/plain; charset=ISO-8859-1 Hi Ole, 2013/11/12 Ole Troan > This is a call for action to get to 14! > What's "14!" ? Do you want to make priorities for all existing IPv4 over IPv6 / provisioning mechanisms? Thanks! Cong --047d7b5dbf4c54157d04eaf9f7eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ole,

2013/11/12 Ole Troan= <otroan@employees.org>
This is a call for action to get t= o 14!

What's "14!&= quot; ? Do you want to make priorities for all existing IPv4 over IPv6 / pr= ovisioning mechanisms?

Thanks!
Cong
--047d7b5dbf4c54157d04eaf9f7eb-- From simon.perreault@viagenie.ca Tue Nov 12 07:07:05 2013 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 52D7521E8130; Tue, 12 Nov 2013 07:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7yVwiWuL9fp; Tue, 12 Nov 2013 07:07:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB4521E812B; Tue, 12 Nov 2013 07:06:39 -0800 (PST) Received: from porto.nomis80.org (h120.viagenie.ca [206.123.31.120]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4E619403E0; Tue, 12 Nov 2013 10:06:30 -0500 (EST) Message-ID: <528243F6.1040605@viagenie.ca> Date: Tue, 12 Nov 2013 10:06:30 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ole Troan , "ietf@ietf.org Discussion" References: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> In-Reply-To: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Softwires , "dhcwg@ietf.org WG" Subject: Re: [Softwires] We can change the world in a 1000 ways (IPv4 over IPv6) 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, 12 Nov 2013 15:07:05 -0000 Le 2013-11-12 06:33, Ole Troan a crit : > In the context of http://xkcd.com/927/ > > See attached drawing for the current state of IPv4 over IPv6 > standardisation. > > Count of IPv4 over IPv6 mechanisms (conservative): 9 > Number of ways to provision IPv4 addresses and other configuration > information: ~6 > (Number of ways to carry DHCPv4 packets over softwires: 3) > > This is a call for action to get to 14! I'm doing my part as we speak. I'm writing a new version of LW4o6 that uses translation instead of encapsulation. I'll call it LW4o6-T. (Am I joking? That is the question.) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Tue Nov 12 08:22:28 2013 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 A033A21E8210; Tue, 12 Nov 2013 08:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSY9LV2ugd86; Tue, 12 Nov 2013 08:22:22 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id C611921E80AA; Tue, 12 Nov 2013 08:22:21 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUoJVvUczWLR8I5/aFTE2xRU+Oknoog3Y@postini.com; Tue, 12 Nov 2013 08:22:21 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 659CA1B82D0; Tue, 12 Nov 2013 08:22:21 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-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 4581F19005D; Tue, 12 Nov 2013 08:22:21 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 08:22:21 -0800 From: Ted Lemon To: Michael Richardson Thread-Topic: We can change the world in a 1000 ways (IPv4 over IPv6) Thread-Index: AQHO35sV1lCZcft8K0C2M4xcE85DdJoiST4AgAAEYwA= Date: Tue, 12 Nov 2013 16:22:20 +0000 Message-ID: References: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> <30650.1384272400@sandelman.ca> In-Reply-To: <30650.1384272400@sandelman.ca> 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: <2B84F19D5B38F44AB78689F38E1755D0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires , "dhcwg@ietf.org WG" , "ietf@ietf.org Discussion" Subject: Re: [Softwires] We can change the world in a 1000 ways (IPv4 over IPv6) 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, 12 Nov 2013 16:22:28 -0000 On Nov 12, 2013, at 11:06 AM, Michael Richardson wr= ote: > It would be nice to convene a summit of operators (at RIPE or NANOG) and= =20 > describe the various mechanisms and rather than ask them which one they l= ike, > ask them which one they would *NEVER* consider. That might reduce the > field by half... I don't think that's practical=97they might all vote for a protocol that th= ey wind up not wanting to deploy. The models that are under consideration= actually have running code and some operational experience behind them. = So asking operators to decide based on a feature list or something of that = sort is not a good idea. What we really want is for operators who have re= alistic intentions of deploying this stuff to weigh in. And they are doin= g so, in the working group, so we don't really need to go to RIPE or NANOG = to get this feedback. From brian.e.carpenter@gmail.com Tue Nov 12 11:39:04 2013 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 B157D11E810B; Tue, 12 Nov 2013 11:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZvPI+Vi1eJf; Tue, 12 Nov 2013 11:39:03 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 77DA921F9FCE; Tue, 12 Nov 2013 11:38:42 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id p10so2829306pdj.12 for ; Tue, 12 Nov 2013 11:38:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5e7fCUoWdp3jNRqPX3PKlC0KZnBvPQ+948TKzn1xKZ8=; b=M8DhvaPxPA6z9aL6hkDw0r/tEN/qtzgaCCCKcn9gMlp8nsrt5XoM5LoSgcRLI8mzdM gIlivPHVZMf6UUKOfq4fGLboricIG87EV9xKsdREUG7ZXLIKYjYT/N960IF6uWK8J6mI fE03H33ZC5ZLzN1QQNYal2eRaEsejkt3EAMp3xv9/tnO9McVB98rmUp3rELnyn1ELaBs LFZ69MhcsojiE21DrnGjrnMv9PSli5CD7/eRfYB7KxXDg156sza0zWx1C9xvVei1AgHo s1aU9e7F66Eyf3mcKdLX2ihYf9g+UpvAFRr01Ne7jMhyY/gFntfJ8UoF5jpkp74rc5OT ghvg== X-Received: by 10.66.165.106 with SMTP id yx10mr9644203pab.159.1384285120834; Tue, 12 Nov 2013 11:38:40 -0800 (PST) Received: from [192.168.178.20] (94.200.69.111.dynamic.snap.net.nz. [111.69.200.94]) by mx.google.com with ESMTPSA id xn12sm45909126pac.12.2013.11.12.11.38.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Nov 2013 11:38:40 -0800 (PST) Message-ID: <528283C1.8050106@gmail.com> Date: Wed, 13 Nov 2013 08:38:41 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> <30650.1384272400@sandelman.ca> <24212.1384279979@sandelman.ca> In-Reply-To: <24212.1384279979@sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Softwires , "dhcwg@ietf.org WG" , "ietf@ietf.org Discussion" Subject: Re: [Softwires] We can change the world in a 1000 ways (IPv4 over IPv6) 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, 12 Nov 2013 19:39:04 -0000 On 13/11/2013 07:12, Michael Richardson wrote: ... > I don't really understand why we have so many mechanisms... Perhaps we could > have an IAB plenary presentation on it... or maybe someone could do an ISOC > video like Kathleen did for MILE. Because we've been playing a game of "my solution is better than your solution" in softwire for several years. We should stop. Now. Brian From randy@psg.com Tue Nov 12 12:02:31 2013 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 4C7BD21E8095; Tue, 12 Nov 2013 12:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUCMPBH1oFT4; Tue, 12 Nov 2013 12:02:30 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id B3EA711E80FC; Tue, 12 Nov 2013 12:02:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VgKA9-0001XX-D3; Tue, 12 Nov 2013 20:02:13 +0000 Date: Wed, 13 Nov 2013 05:02:11 +0900 Message-ID: From: Randy Bush To: Michael Richardson In-Reply-To: <30650.1384272400@sandelman.ca> References: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> <30650.1384272400@sandelman.ca> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: Softbrains , dhcwg@ietf.org, IETF Disgust Subject: Re: [Softwires] We can change the world in a 1000 ways (IPv4 over IPv6) 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, 12 Nov 2013 20:02:31 -0000 > It would be nice to convene a summit of operators (at RIPE or NANOG) > and describe the various mechanisms and rather than ask them which one > they like, ask them which one they would *NEVER* consider. That might > reduce the field by half... please please keep ds-lite. you get to fork-lift the cpe and it has nat in the core. what more could i wish on my competitors? randy From Ted.Lemon@nominum.com Tue Nov 12 13:50:04 2013 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 B8F6E21E80ED; Tue, 12 Nov 2013 13:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL3Z1dmy9Rwt; Tue, 12 Nov 2013 13:49:58 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id D222A21F9EAF; Tue, 12 Nov 2013 13:49:57 -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 DSNKUoKigoSsCMRatXPHiurpZ5bIVxE+kNKy@postini.com; Tue, 12 Nov 2013 13:49:57 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 7C1151B82E3; Tue, 12 Nov 2013 13:49:54 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 52BCB19005D; Tue, 12 Nov 2013 13:49:54 -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.03.0158.001; Tue, 12 Nov 2013 13:49:54 -0800 From: Ted Lemon To: Michael Richardson Thread-Topic: We can change the world in a 1000 ways (IPv4 over IPv6) Thread-Index: AQHO35sV1lCZcft8K0C2M4xcE85DdJoiST4AgAAEYwCAAB7ngIAAPJcA Date: Tue, 12 Nov 2013 21:49:53 +0000 Message-ID: <976F2DE5-9754-40BA-97D5-6D77F3CEEDA7@nominum.com> References: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> <30650.1384272400@sandelman.ca> <24212.1384279979@sandelman.ca> In-Reply-To: <24212.1384279979@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires , "dhcwg@ietf.org WG" , "ietf@ietf.org Discussion" Subject: Re: [Softwires] We can change the world in a 1000 ways (IPv4 over IPv6) 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, 12 Nov 2013 21:50:04 -0000 On Nov 12, 2013, at 1:12 PM, Michael Richardson wro= te: > I'll bet if we had a single IPv4 over IPv6 solution which had a clear > operating cost savings over Dual-Stack, and also over IPv4-only+CGN, that > we'd be at universal deployment of IPv6 already. And if we all had ponies, we could go for a ride together! Seriously, the= various solutions that have been proposed are all reasonable technical sol= utions. There's no strong technical reason to prefer one over another. = And the proponents of the solutions will not come to consensus on a single = solution. So your choices, really, are many solutions, or none, or let th= e IESG pick a winner, which I don't think would be a popular move. We could just stand pat with DS-Lite and Public 4over6, but there's demand = for port-sharing in locales with fewer IPv4 addresses to burn, and putting = all the NAT state in boxes in the data center is expensive. Also, "we'd be at universal deployment of IPv6 now?" Seriously? > I don't really understand why we have so many mechanisms... Perhaps we co= uld > have an IAB plenary presentation on it... or maybe someone could do an IS= OC > video like Kathleen did for MILE. This would just be more layer 9. I'd rather we published some specs and g= ot on with our lives. The IESG does not have limitless time to burn on tr= ivia, and I don't think the IAB does either. It's just not that interesti= ng to argue about it. These are transition technologies=97they'll be obso= lete in ten years. From kristian.poscic@alcatel-lucent.com Tue Nov 12 15:31:20 2013 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 76E5011E8163 for ; Tue, 12 Nov 2013 15:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJyvMMpcdLS1 for ; Tue, 12 Nov 2013 15:31:13 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id DA47A11E8109 for ; Tue, 12 Nov 2013 15:31:12 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rACNVBdT000394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 12 Nov 2013 17:31:11 -0600 (CST) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id rACNVB6i027371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Nov 2013 18:31:11 -0500 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.36]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 12 Nov 2013 18:31:11 -0500 From: "Poscic, Kristian (Kristian)" To: "softwires@ietf.org" Thread-Topic: port-forwards in MAP Thread-Index: Ac7f/qsBm+9ChNYxQNapxnMoIyOmoA== Date: Tue, 12 Nov 2013 23:31:10 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02ACA4740@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.17] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02ACA4740US70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [Softwires] port-forwards in MAP 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, 12 Nov 2013 23:31:20 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02ACA4740US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just wanted to confirm one thing for MAP-E in regards to static port forwar= ds. Can it be assumed that excluded port-range (0-1023 and possibly more depend= ing on the offset) will never be used in MAP? The port forwards will be all= ocated on the CPE in statefull NAT44 and the ports will be allocated accord= ing to the delegated PSID and not from the MAP excluded range (well-known p= orts for example). Thanks. --_000_7921F977B17D5B49B8DCC955A339D2F02ACA4740US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just wanted to confirm one thing for MAP-E in regard= s to static port forwards.

 

Can it be assumed that excluded port-range (0-1023 a= nd possibly more depending on the offset) will never be used in MAP? The po= rt forwards will be allocated on the CPE in statefull NAT44 and the ports w= ill be allocated according to the delegated PSID and not from the MAP excluded range (well-known ports for e= xample).

Thanks.

--_000_7921F977B17D5B49B8DCC955A339D2F02ACA4740US70UWXCHMBA05z_-- From otroan@employees.org Wed Nov 13 07:49:40 2013 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 67FEB21E80AE; Wed, 13 Nov 2013 07:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKbL++s0Thd1; Wed, 13 Nov 2013 07:49:34 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 931BB11E8100; Wed, 13 Nov 2013 07:49:34 -0800 (PST) Received: from dhcp-10-61-97-211.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 851A35EFE; Wed, 13 Nov 2013 07:49:29 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_2F487FC8-C236-4A20-BF94-EB3C4BC75553"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <4870BB66DFE30BBF780F30E6@JcK-HP8200.jck.com> Date: Wed, 13 Nov 2013 16:49:26 +0100 Message-Id: References: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> <30650.1384272400@sandelman.ca> <24212.1384279979@sandelman.ca> <4870BB66DFE30BBF780F30E6@JcK-HP8200.jck.com> To: John C Klensin X-Mailer: Apple Mail (2.1822) Cc: Softwires , "dhcwg@ietf.org WG" , "ietf@ietf.org Discussion" Subject: Re: [Softwires] We can change the world in a 1000 ways (IPv4 over IPv6) 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, 13 Nov 2013 15:49:40 -0000 --Apple-Mail=_2F487FC8-C236-4A20-BF94-EB3C4BC75553 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> ... >> I'll bet if we had a single IPv4 over IPv6 solution which had >> a clear operating cost savings over Dual-Stack, and also over >> IPv4-only+CGN, that we'd be at universal deployment of IPv6 >> already. >=20 > Since we are engaged in a counterfactual guessing / betting > game, I'd bet that would be true had we defined such a solution > a decade ago, that it were realistic, and that we had stuck to > it. At this stage, the cartoon is relevant -- not only would we > be likely to add another method to the list when existing ones > already have their advocates, but dropping two or three would > not be enough to make a significant difference. ngtrans et al, standardised somewhere in the area of 14 transition = mechanisms for IPv6 transition. the experience from that, was that it was really = hard to know a priori which mechanism would succeed (e.g. 6rd) and which would hinder IPv6 deployment (6to4, Teredo). we're in the same situation with the mechanisms for the IPv4 endgame, and all we can do is throw spaghetti on the wall. while standardising every possible solution, isn't quite standardising = at all in my book, I don't have any good proposals for what we can do better. is there a problem here, or should we just accept that sometimes the = IETF will generate ten sets of publications solving more or less the same = problem? cheers, Ole --Apple-Mail=_2F487FC8-C236-4A20-BF94-EB3C4BC75553 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSg5+GAAoJEFuJXizso86g7b8H/jcjzH6RTvCI2ig3ASzBJJmI ywEtAwRjN3KWgglwrYeX+ibD+BmUoo+81q/hMtjBARR7gYigMylP3HJWXOIhlSdT 5NfBdnaoWCfClaonmuSRUVfDm+/IHCxpQUVh91OeoZpez5OydulWEC1fMrVnKmJw ImWbwTW8yqPvKZMDstJjKuCg6arqpe38PmrmRsO3sE1ad/jMZ4xTHBzg7JqjvsT8 0/Q7/vk3NJTqGnCSKq36mnP0G61cH5NO52lJ/lH2aea9BsoT1Zw6bDMAByGpqzG5 Ph7CcFPlp3HRURCQps/+yyArhekZ/h/lk+rP5OJKKFb7C22Z3zEs9aPUQS6HlXg= =5vcR -----END PGP SIGNATURE----- --Apple-Mail=_2F487FC8-C236-4A20-BF94-EB3C4BC75553-- From Ted.Lemon@nominum.com Wed Nov 13 08:06:00 2013 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 D2E5E21E80F4; Wed, 13 Nov 2013 08:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6PyINR-mwh1; Wed, 13 Nov 2013 08:05:45 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE7B21E80AE; Wed, 13 Nov 2013 08:05:45 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUoOjWYy+6HuRTH+UVlwKCLb3n2qmWOb6@postini.com; Wed, 13 Nov 2013 08:05:45 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 149F81B82E4; Wed, 13 Nov 2013 08:05:45 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-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 EF19619005D; Wed, 13 Nov 2013 08:05:44 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Wed, 13 Nov 2013 08:05:44 -0800 From: Ted Lemon To: Ole Troan Thread-Topic: [dhcwg] We can change the world in a 1000 ways (IPv4 over IPv6) Thread-Index: AQHO35sV1lCZcft8K0C2M4xcE85DdJoiST4AgAAEYwCAAB7ngIABUbQAgAAYhgCAAASIgA== Date: Wed, 13 Nov 2013 16:05:44 +0000 Message-ID: References: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> <30650.1384272400@sandelman.ca> <24212.1384279979@sandelman.ca> <4870BB66DFE30BBF780F30E6@JcK-HP8200.jck.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <8E918545E167EF488525D883711B7608@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John C Klensin , Softwires , "ietf@ietf.org Discussion" , "dhcwg@ietf.org WG" Subject: Re: [Softwires] [dhcwg] We can change the world in a 1000 ways (IPv4 over IPv6) 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, 13 Nov 2013 16:06:00 -0000 On Nov 13, 2013, at 10:49 AM, Ole Troan wrote: > is there a problem here, or should we just accept that sometimes the IETF > will generate ten sets of publications solving more or less the same prob= lem? If I'd been area director earlier in the process I might have just shut the= working group when it became clear that the principals couldn't agree on a= proposal, and required that they come to agreement before a BoF would be a= pproved. But it's much too late in the process to do that now. And I do= n't even know if that would have produced a better outcome. I don't think we should accept that this has to happen every time, and I th= ink we should try to prevent it happening in the future. But there is no = sense crying over spilt milk. From cb.list6@gmail.com Wed Nov 13 09:23:42 2013 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 4C08111E81A8; Wed, 13 Nov 2013 09:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP+R+otEAvgy; Wed, 13 Nov 2013 09:23:41 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF7E11E8152; Wed, 13 Nov 2013 09:23:41 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id y10so728304wgg.33 for ; Wed, 13 Nov 2013 09:23:40 -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=p4osdx8e/iz8acLTJ8ARfuHoJIIbaA9+2Ks21aG8Cvk=; b=KfP+AhP7Q80MYfHWveLuguOIhrjjA1Mu4gfIkd0lyN3GnP81JmuZQfc5nzielZT1Zc +57Tk3UPEAke/orVHz0cTvBTyTNkZ0GnUDh1qHJTQQnGT57yqV91TmrgfndNpefxDASr xb9qRorz809OdvktT9v6NsyeVqHy/dFIZOJNaneWsOfOMXn7URBb7Q6vNC8qeXdGLoG5 05JjJIl3FghT3jGz6WMR6X46JQa1bX9V5pEpeCwS0qrM6aFCdWGMhqKj6vGQlX/1uW81 iCuaFl1pxsuAfb8vekoZK4xN8Jl5a/TSAwRPEc+9K+Nw/MyBsxNjVHnAtnfq08sHkFif r9Cg== MIME-Version: 1.0 X-Received: by 10.194.77.167 with SMTP id t7mr32481995wjw.27.1384363420318; Wed, 13 Nov 2013 09:23:40 -0800 (PST) Received: by 10.216.99.68 with HTTP; Wed, 13 Nov 2013 09:23:40 -0800 (PST) In-Reply-To: <20131113161737.8C58F18C0AA@mercury.lcs.mit.edu> References: <20131113161737.8C58F18C0AA@mercury.lcs.mit.edu> Date: Wed, 13 Nov 2013 09:23:40 -0800 Message-ID: From: "cb.list6" To: Noel Chiappa Content-Type: text/plain; charset=ISO-8859-1 Cc: "softwires@ietf.org" , dhcwg@ietf.org, IETF-Discussion Subject: Re: [Softwires] We can change the world in a 1000 ways (IPv4 over IPv6) 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, 13 Nov 2013 17:23:42 -0000 On Wed, Nov 13, 2013 at 8:17 AM, Noel Chiappa wrote: > On Nov 13, 2013, at 10:49 AM, Ole Troan wrote: > > > is there a problem here, or should we just accept that sometimes the > > IETF will generate ten sets of publications solving more or less the > > same problem? > > This has been a longstanding issue in the IETF (and its predecessors, I'd > have to check some of these dates) - going back to HEMS/SGMP, OSPF/IS-IS, > etc. > > My long-standing personal position is that the IETF is pretty good at > _producing and vetting_ designs, but less good at _chosing_ from similar > alternatives. I think it's better if, when we can't agree, to let the users > decide which works best for them. > > Yes, yes, I know, this is in some ways painful - resources get wasted on > duplicate efforts; some users wind up with investments in standards that > dead-end (think Betamax, etc); etc. But at the same time, making a choice can > produce lengthy, extensive painful politics and wrangling, too. So there are > down-sides both ways. > > My bottom line: we're not infinitely smart, and have only limited > foresight. Some things you can only learn by trying things. > +1. The IETF does not engineer the internet. The internet emerges from various independent actors greedily optimizing for themselves. The best the IETF can do is facilitate collaboration for these self-optimizing actors and document some of what is learned. CB > Noel From rajiva@cisco.com Wed Nov 13 10:13:04 2013 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 7C00811E81A7 for ; Wed, 13 Nov 2013 10:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGxg9S8slSSW for ; Wed, 13 Nov 2013 10:12:58 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D8FAC11E81A0 for ; Wed, 13 Nov 2013 10:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=741; q=dns/txt; s=iport; t=1384366379; x=1385575979; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=eAxiMaWWZRiZ8XLG6GLw6kLcr9SuVo3Yj/UdM3owA1w=; b=a54PCfDg0KeAroGPyupa2tnzKAeCZMGMijY0KrhOI6BkUxHQKz7FIRq7 VufS+kQ6yQmp4TjHens6DNqYfNYa/TiNuFO6ijAtjQXiPNGgKyS5nAG3W mUpItELfFpRz1lLNMB89qJHALZznU/nsQT/tj+PKrSvRm+j77iCtyKMwW 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAMjAg1KtJXG9/2dsb2JhbABbgweBC78rgSYWdIIlAQEBBDpLBgEIEQMBAh9CHQgBAQQBEogBwCWPNDIGhCsDmBCSC4Mogio X-IronPort-AV: E=Sophos;i="4.93,693,1378857600"; d="scan'208";a="284378055" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 13 Nov 2013 18:12:58 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rADICwrx025178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 18:12:58 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.147]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 12:12:58 -0600 From: "Rajiv Asati (rajiva)" To: "Poscic, Kristian (Kristian)" , "softwires@ietf.org" Thread-Topic: [Softwires] port-forwards in MAP Thread-Index: Ac7f/qsBm+9ChNYxQNapxnMoIyOmoAApa08A Date: Wed, 13 Nov 2013 18:12:57 +0000 Message-ID: In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02ACA4740@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.3.8.130913 x-originating-ip: [10.65.33.132] Content-Type: text/plain; charset="us-ascii" Content-ID: <957341B628766544BDF867FE85569035@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] port-forwards in MAP 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, 13 Nov 2013 18:13:04 -0000 Hi Kristian, Yes, that's correct. --=20 Cheers, Rajiv =20 -----Original Message----- From: , Kristian Poscic Date: Tuesday, November 12, 2013 6:31 PM To: Softwires-wg list Subject: [Softwires] port-forwards in MAP >Just wanted to confirm one thing for MAP-E in regards to static port >forwards. >=20 >Can it be assumed that excluded port-range (0-1023 and possibly more >depending on the offset) will never be used in MAP? The port forwards >will be allocated on the CPE in statefull NAT44 and the ports will be >allocated according to the > delegated PSID and not from the MAP excluded range (well-known ports for >example). >Thanks. > > From internet-drafts@ietf.org Wed Nov 13 17:46:08 2013 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 CEEE011E8121; Wed, 13 Nov 2013 17:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT4PL2tBHM3f; Wed, 13 Nov 2013 17:46:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F4111E8109; Wed, 13 Nov 2013 17:45:54 -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.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131114014554.30542.69145.idtracker@ietfa.amsl.com> Date: Wed, 13 Nov 2013 17:45:54 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 01:46:09 -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 : Lightweight 4over6: An Extension to the DS-Lite Architec= ture Author(s) : Yong Cui Qiong Sun Mohamed Boucadair Tina Tsou Yiu L. Lee Ian Farrer Filename : draft-ietf-softwire-lw4over6-03.txt Pages : 20 Date : 2013-11-13 Abstract: Dual-Stack Lite (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called Lightweight 4over6 which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 Address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wdec.ietf@gmail.com Thu Nov 14 01:48:21 2013 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 7D55421E8174 for ; Thu, 14 Nov 2013 01:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjF7IxE6oiwb for ; Thu, 14 Nov 2013 01:48:20 -0800 (PST) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id C70FB21E8092 for ; Thu, 14 Nov 2013 01:48:20 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb1so1862699pad.10 for ; Thu, 14 Nov 2013 01:48:20 -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=6rUcFi6Qh6w3Jfhb5gTpo9L/rdC90DKmDlTsNfQ3P0k=; b=QxXcTs43OztqRojSCcabdjhWM1J1bnCjFerXYTYwEV+cpZXFDKkxwm8DeUtepTIWao 4ri30LGwz2Try00JZhbV2QxMkoKhEdJZtDgNOE46IY7mSrphGGVnN9zR7hwvJoKP6beX U6iEoBDwr2dVij445IXvCq0jxmcrfqxBN7Yya1Uo5VTBUzyiFK4GkkrkW8NRQKXs6GD7 gTQX7+dyy8kMgDMNQUJM7/AFxEAM2ycVF2hwpj4xCrrQCK7zo4sO7tJVtU2Hn7H/w5+A oY6lNZg2oQhdUCnT7s0MGldhQWhDmrB4Nv0tnypH9Q8zN9SWWgt6sJ1NPrT23QSuDh28 gXaQ== MIME-Version: 1.0 X-Received: by 10.68.244.168 with SMTP id xh8mr492620pbc.3.1384422500396; Thu, 14 Nov 2013 01:48:20 -0800 (PST) Received: by 10.70.71.163 with HTTP; Thu, 14 Nov 2013 01:48:20 -0800 (PST) In-Reply-To: References: <7921F977B17D5B49B8DCC955A339D2F02ACA4740@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Thu, 14 Nov 2013 10:48:20 +0100 Message-ID: From: Wojciech Dec To: "Rajiv Asati (rajiva)" Content-Type: multipart/alternative; boundary=047d7b16348d5af68404eb1ffb83 Cc: "softwires@ietf.org" Subject: Re: [Softwires] port-forwards in MAP 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, 14 Nov 2013 09:48:21 -0000 --047d7b16348d5af68404eb1ffb83 Content-Type: text/plain; charset=ISO-8859-1 Well, never say "never" :-) MAP allows via the a-bits/offset-bits setting the range of "excluded ports" in a domain to be configured. Thus, while not set so as a default, ports <1024 can also be used. There is naturally the non-address-shared mode of MAP to consider (i.e. when PSID length =0). Here each MAP user has a full IPv4 address and of course also the corresponding full port range. Cheers, Wojciech On 13 November 2013 19:12, Rajiv Asati (rajiva) wrote: > Hi Kristian, > > Yes, that's correct. > > -- > Cheers, > Rajiv > > > > > -----Original Message----- > From: , Kristian Poscic > Date: Tuesday, November 12, 2013 6:31 PM > To: Softwires-wg list > Subject: [Softwires] port-forwards in MAP > > >Just wanted to confirm one thing for MAP-E in regards to static port > >forwards. > > > >Can it be assumed that excluded port-range (0-1023 and possibly more > >depending on the offset) will never be used in MAP? The port forwards > >will be allocated on the CPE in statefull NAT44 and the ports will be > >allocated according to the > > delegated PSID and not from the MAP excluded range (well-known ports for > >example). > >Thanks. > > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --047d7b16348d5af68404eb1ffb83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Well, never say "never" :-) = MAP allows via the a-bits/offset-bits setting the range of "excluded p= orts" in a domain
=A0to be configured. Thus, while not set so= as a default, ports <1024 can also be used.

There is naturally the non-address-shared mode of MAP to consider= (i.e. when PSID length =3D0). Here each MAP user has a full IPv4 address a= nd of course also the corresponding full port range.

Cheers,
Wojciech


On 13 November 2013 19:12, Rajiv Asati (rajiva) <rajiva@cisco.co= m> wrote:
Hi Kristian,

Yes, that's correct.

--
Cheers,
Rajiv




-----Original Message-----
From: <Poscic>, Kristian Poscic <kristian.poscic@alcatel-lucent.com>
Date: Tuesday, November 12, 2013 6:31 PM
To: Softwires-wg list <softwires@i= etf.org>
Subject: [Softwires] port-forwards in MAP

>Just wanted to confirm one thing for MAP-E in regards to static port >forwards.
>
>Can it be assumed that excluded port-range (0-1023 and possibly more >depending on the offset) will never be used in MAP? The port forwards >will be allocated on the CPE in statefull NAT44 and the ports will be >allocated according to the
> delegated PSID and not from the MAP excluded range (well-known ports f= or
>example).
>Thanks.
>
>

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

--047d7b16348d5af68404eb1ffb83-- From simon.perreault@viagenie.ca Thu Nov 14 12:26:53 2013 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 B5CF411E8119 for ; Thu, 14 Nov 2013 12:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBtcV+2CrGY6 for ; Thu, 14 Nov 2013 12:26:53 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DDD0911E810D for ; Thu, 14 Nov 2013 12:26:52 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d95c:254d:9b1e:dcab]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6879740204 for ; Thu, 14 Nov 2013 15:26:52 -0500 (EST) Message-ID: <5285320C.7030702@viagenie.ca> Date: Thu, 14 Nov 2013 15:26:52 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "softwires@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 14 Nov 2013 20:26:53 -0000 WG, Currently draft-ietf-softwire-map-dhcp-05 says that OPTION_S46_IPV4ADDRESS is mandatory. It has to be made at least optional so that DHCPv4oDHCPv6 or PCP can be used for IPv4 address provisioning. Can we go further? Can we just remove OPTION_S46_IPV4ADDRESS? The result would be that DHCPv4oDHCPv6 or PCP would become mandatory. Any opinion on this? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From joelja@bogus.com Thu Nov 14 12:27:41 2013 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 2261121E80F1; Thu, 14 Nov 2013 12:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g98OsUNtsdSs; Thu, 14 Nov 2013 12:27:40 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 645F911E8127; Thu, 14 Nov 2013 12:27:40 -0800 (PST) Received: from 00698a-hsutim.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id rAEKRcfT051144 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 14 Nov 2013 20:27:38 GMT (envelope-from joelja@bogus.com) Message-ID: <52853234.9030302@bogus.com> Date: Thu, 14 Nov 2013 12:27:32 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Thunderbird/25.0 MIME-Version: 1.0 To: Michael Richardson , Ole Troan References: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> <30650.1384272400@sandelman.ca> In-Reply-To: <30650.1384272400@sandelman.ca> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CQsvwe5JbwQHx6xptnfVQkO20HlTPfvUi" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 14 Nov 2013 20:27:39 +0000 (UTC) Cc: Softwires , "dhcwg@ietf.org WG" , "ietf@ietf.org Discussion" Subject: Re: [Softwires] We can change the world in a 1000 ways (IPv4 over IPv6) 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, 14 Nov 2013 20:27:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CQsvwe5JbwQHx6xptnfVQkO20HlTPfvUi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/12/13, 8:06 AM, Michael Richardson wrote: >=20 > Ole Troan wrote: > > In the context of http://xkcd.com/927/ >=20 > this comic part is pretty important context, but many might not have go= tten it. >=20 > > This is a call for action to get to 14! >=20 > So Ole is saying that we need a 14th specification/standard in order to= > bind the existing 13 (although I'm not sure how he got 13) >=20 > I'm also dismayed at the number of efforts. > It would be nice to convene a summit of operators (at RIPE or NANOG) an= d=20 > describe the various mechanisms and rather than ask them which one they= like, > ask them which one they would *NEVER* consider. That might reduce the > field by half... I'm pretty sure the "if we just get the right people in the room then we'll get the right one's" model isn't going to work... There's a market-place out there, that can pick one if it turns out to be necessary. The fact that to a large degree it hasn't, might mean, it's too early, none of extant ones are the right one, there isn't a market need for it, or something else. As an operator, albeit not of retail ISP networks, the fact of the matter is I don't need transition technologies of the encapsulation or translation variety to serve either my ipv4 or IPv6 customers, so asking me which I find more compelling is missing the point. > My gut is that until we have a unified story and some fielded product o= n > deploying v4 over v6, that for a number of ISPs, adding v6 is just adde= d cost > with no savings. >=20 --CQsvwe5JbwQHx6xptnfVQkO20HlTPfvUi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKFMjUACgkQ8AA1q7Z/VrK5ngCfdI2n6qe8teHv10vl6UfTk8pY FvIAnAoO4LynJkvdFKe34QJvkQni/5uw =Ep5i -----END PGP SIGNATURE----- --CQsvwe5JbwQHx6xptnfVQkO20HlTPfvUi-- From Ted.Lemon@nominum.com Thu Nov 14 12:41:29 2013 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 94A2721E80A8 for ; Thu, 14 Nov 2013 12:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ibu0WuUE7W1Z for ; Thu, 14 Nov 2013 12:41:23 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id D576621E8096 for ; Thu, 14 Nov 2013 12:41:22 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUoU1ci1ZALoOOmpLrhloAjNDJfKMz//a@postini.com; Thu, 14 Nov 2013 12:41:22 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 689BC1B82D0 for ; Thu, 14 Nov 2013 12:41:22 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-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 3AD4C190043; Thu, 14 Nov 2013 12:41:22 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 12:41:22 -0800 From: Ted Lemon To: Simon Perreault Thread-Topic: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS Thread-Index: AQHO4XfkxtkjsKyJgEmxLctVX9g+UZoltusA Date: Thu, 14 Nov 2013 20:41:21 +0000 Message-ID: <57966783-D308-48B8-8C64-33465312437C@nominum.com> References: <5285320C.7030702@viagenie.ca> In-Reply-To: <5285320C.7030702@viagenie.ca> 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="us-ascii" Content-ID: <7C2DB24D26B1B449A20652A9FFB95647@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 14 Nov 2013 20:41:29 -0000 On Nov 14, 2013, at 3:26 PM, Simon Perreault = wrote: > Can we go further? Can we just remove OPTION_S46_IPV4ADDRESS? The result = would be that DHCPv4oDHCPv6 or PCP would become mandatory. Doesn't MAP use OPTION_S46_IPV4ADDRESS? Anyway, I think that having a mechanism for configuring the whole thing wit= h DHCPv6 in the absence of a need for stateful or additional IPv4 configura= tion is probably good. From simon.perreault@viagenie.ca Thu Nov 14 12:49:43 2013 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 DC15D11E810D for ; Thu, 14 Nov 2013 12:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFyl8njEKuAt for ; Thu, 14 Nov 2013 12:49:43 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1C811E80FA for ; Thu, 14 Nov 2013 12:49:43 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d95c:254d:9b1e:dcab]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 39BB94039A; Thu, 14 Nov 2013 15:49:42 -0500 (EST) Message-ID: <52853765.6050700@viagenie.ca> Date: Thu, 14 Nov 2013 15:49:41 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ted Lemon References: <5285320C.7030702@viagenie.ca> <57966783-D308-48B8-8C64-33465312437C@nominum.com> In-Reply-To: <57966783-D308-48B8-8C64-33465312437C@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 14 Nov 2013 20:49:44 -0000 Le 2013-11-14 15:41, Ted Lemon a crit : >> Can we go further? Can we just remove OPTION_S46_IPV4ADDRESS? The result would be that DHCPv4oDHCPv6 or PCP would become mandatory. > > Doesn't MAP use OPTION_S46_IPV4ADDRESS? It does not. Its IPv4 configuration is in OPTION_S46_RULE. > Anyway, I think that having a mechanism for configuring the whole thing with DHCPv6 in the absence of a need for stateful or additional IPv4 configuration is probably good. Removing unneeded cruft is probably good too. I mean, if nobody is going to use it... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mark@townsley.net Thu Nov 14 15:35:31 2013 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 ED4EE21E808A for ; Thu, 14 Nov 2013 15:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKDpgLjRu3Wv for ; Thu, 14 Nov 2013 15:35:27 -0800 (PST) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id C864821E80B3 for ; Thu, 14 Nov 2013 15:35:26 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so1451978wgh.3 for ; Thu, 14 Nov 2013 15:35:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=g1ALuPIWQel9JEmWn5DMLvSPLOHwSToCe8M1ATmrqRY=; b=OhEgyu8ux8jCkFBkxW8jiQe7H9S3eie7I+4jJiHSS95cXTOSTlgJAdbxg9AAEjwAyK Nq0jFXWakANfvJVUWwHa6vNOcXxI2UlY2raLmBb/XR61J5A2rt+MfLBQr6pohgM31wwd eHt3zhHAxlHoOuux71yh7FzMK4qkPl656Kpzj0b8Etq46zAEIJIgn0TTbrvtO3zG4V9D fFoj6Oy315P4SIy1al5aPqOobjHnZ27jXJI3j6wx/4HNQOBaKlyQnB9SJGQ4yh14L8O+ 5wSMkJQ7PUAI6ZIi7EEnGpOIXL4TOFhylILDjXqioqe6/hrdcQBKskxoHKidFZD/o7/x 1F/Q== X-Gm-Message-State: ALoCoQl523mjZ0NhFM+rmrHMM0Nxb9Kt1UVDX8Dr5JzlpxspxJzd0S4x4N77BeC6gaLa1M3F05ft X-Received: by 10.180.108.82 with SMTP id hi18mr5068402wib.53.1384472122739; Thu, 14 Nov 2013 15:35:22 -0800 (PST) Received: from ams-townsley-8918.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id z2sm482786eee.7.2013.11.14.15.35.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 15:35:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Fri, 15 Nov 2013 00:35:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9FB85A23-0B64-4231-8C52-B6517174E622@townsley.net> References: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> <30650.1384272400@sandelman.ca> <24212.1384279979@sandelman.ca> <4870BB66DFE30BBF780F30E6@JcK-HP8200.jck.com> To: Ted Lemon X-Mailer: Apple Mail (2.1283) Cc: John C Klensin , Softwires , "ietf@ietf.org Discussion" , "dhcwg@ietf.org WG" Subject: Re: [Softwires] [dhcwg] We can change the world in a 1000 ways (IPv4 over IPv6) 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, 14 Nov 2013 23:35:32 -0000 On Nov 13, 2013, at 5:05 PM, Ted Lemon wrote: > On Nov 13, 2013, at 10:49 AM, Ole Troan wrote: >> is there a problem here, or should we just accept that sometimes the = IETF >> will generate ten sets of publications solving more or less the same = problem? >=20 > If I'd been area director earlier in the process You rang? > I might have just shut the working group when it became clear that the = principals couldn't agree on a proposal, and required that they come to = agreement before a BoF would be approved. Not chartering work doesn't always help as it can scatter people to the = winds to create their own parallel efforts. The 13+ IPv4 over IPv6 = solutions you see were born from the rubble of trying to keep DS-Lite as = the only chartered work softwires would look at for IPv4 over IPv6 with = some kind of built-in IPv4 address sharing. Ted, when we started softwires, I noted very clearly that I would reject = every transition protocol to come my way until the WG agreed on a finite = set of problem-spaces and associated solutions. Note I didn't say reject = _chartering_ the work or having a BoF, I said reject the proposals that = did not come via the WG (e.g., as an end-run to the chartered effort). = This gave people a common place to work, and at the start that's exactly = what it did. We held 3 interim meetings, and killed many more proposals = than we advanced. By the time my AD tenure was up, we had identified = L2TP for point-to-point stateful tunnels from hosts and such (largely = because it was already in so many places already). We had a second = solution for larger core networks (essentially a generalization of MPLS' = 6PE). The third was 6rd, building on 6to4 in a manner that was far more = palatable to an operator to deploy and had the obvious scaling = properties over L2TP. So, the happy medium for what were deployed as = largely IPv6 over IPv4 solutions ended up somewhere between = "one-size-fits-all" and "everything-goes".=20 To my memory the 4/6 mess kicked a bit later. The mess started not = because the WG allowed too much in its charter, but because it was = rejecting so much work outright that it didn't give people a trusted = place to come together and work towards a compromise sooner rather than = later.=20 My point is that sometimes we fail when we don't give people the right = environment to work together and make compromises early on in the hopes = of rising the tide for everyone. If groups remain in their respective = corners working on their own for too long, they are bound to create = their own parallel paths. The longer that is allowed to happen, the more = entrenched the solutions become, until the IETF has lost its ability to = do anything constructive beyond publishing everything. - Mark > But it's much too late in the process to do that now. And I don't = even know if that would have produced a better outcome. >=20 > I don't think we should accept that this has to happen every time, and = I think we should try to prevent it happening in the future. But there = is no sense crying over spilt milk. >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Ted.Lemon@nominum.com Thu Nov 14 19:53:19 2013 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 384A111E8177 for ; Thu, 14 Nov 2013 19:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XI8WeYhKuozg for ; Thu, 14 Nov 2013 19:53:12 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id CAD1D11E817E for ; Thu, 14 Nov 2013 19:53:08 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUoWao0Aycs5rCdAF7+5t/NsHI1EulUt6@postini.com; Thu, 14 Nov 2013 19:53:12 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 26AC81B82A4 for ; Thu, 14 Nov 2013 19:53:07 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 EE210190043; Thu, 14 Nov 2013 19:53:06 -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.03.0158.001; Thu, 14 Nov 2013 19:53:01 -0800 From: Ted Lemon To: Simon Perreault Thread-Topic: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS Thread-Index: AQHO4XfkxtkjsKyJgEmxLctVX9g+UZoltusAgAACVoCAAHZEgA== Date: Fri, 15 Nov 2013 03:53:00 +0000 Message-ID: <636C5CB8-1168-40FA-AA24-5827D55AA1DB@nominum.com> References: <5285320C.7030702@viagenie.ca> <57966783-D308-48B8-8C64-33465312437C@nominum.com> <52853765.6050700@viagenie.ca> In-Reply-To: <52853765.6050700@viagenie.ca> 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="iso-8859-1" Content-ID: <6EE993594AB1784DAF2E5273D5A35163@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 03:53:19 -0000 On Nov 14, 2013, at 3:49 PM, Simon Perreault = wrote: > Removing unneeded cruft is probably good too. I mean, if nobody is going = to use it... How sure are you that nobody is going to use it? Serious question. From Ted.Lemon@nominum.com Thu Nov 14 20:14:44 2013 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 D188411E817E; Thu, 14 Nov 2013 20:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104 X-Spam-Level: X-Spam-Status: No, score=-104 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoKqJyceOY+I; Thu, 14 Nov 2013 20:14:34 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 09D9D11E8177; Thu, 14 Nov 2013 20:14:33 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUoWfqaQEj2q5BSmhTXGkSLo+D2yVPXw/@postini.com; Thu, 14 Nov 2013 20:14:34 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 5BB9F1B82A4; Thu, 14 Nov 2013 20:14:33 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 52CBA190043; Thu, 14 Nov 2013 20:14:33 -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.03.0158.001; Thu, 14 Nov 2013 20:14:33 -0800 From: Ted Lemon To: Mark Townsley Thread-Topic: [Softwires] [dhcwg] We can change the world in a 1000 ways (IPv4 over IPv6) Thread-Index: AQHO35sV1lCZcft8K0C2M4xcE85DdJoiST4AgAAEYwCAAB7ngIABUbQAgAAYhgCAAASIgIACD/eAgABOAoA= Date: Fri, 15 Nov 2013 04:14:31 +0000 Message-ID: <3AF89E1B-F338-40C6-96E3-4D0D44B3A931@nominum.com> References: <5ABB4DF8-95F0-4B07-8D20-6A00B7631E11@employees.org> <30650.1384272400@sandelman.ca> <24212.1384279979@sandelman.ca> <4870BB66DFE30BBF780F30E6@JcK-HP8200.jck.com> <9FB85A23-0B64-4231-8C52-B6517174E622@townsley.net> In-Reply-To: <9FB85A23-0B64-4231-8C52-B6517174E622@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John C Klensin , Softwires , "ietf@ietf.org Discussion" , "dhcwg@ietf.org WG" Subject: Re: [Softwires] [dhcwg] We can change the world in a 1000 ways (IPv4 over IPv6) 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, 15 Nov 2013 04:14:45 -0000 On Nov 14, 2013, at 6:35 PM, Mark Townsley wrote: > You rang? Yeah. I meant to reply just to Ole, but basically I was saying the same t= hing you were, just from a less informed perspective. I might have done t= hings differently, but I don't know if it could have produced a better outc= ome. Your analysis matches the actual results pretty well, so if Ole is t= rying to pick between them, I recommend he pick yours. :) From gnocuil@gmail.com Thu Nov 14 22:05:52 2013 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 6D08E11E810A for ; Thu, 14 Nov 2013 22:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhD1sJ8D4LQc for ; Thu, 14 Nov 2013 22:05:51 -0800 (PST) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8A76111E8109 for ; Thu, 14 Nov 2013 22:05:51 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id k4so314684qaq.7 for ; Thu, 14 Nov 2013 22:05:51 -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=0MfSpDu3P/KxZ4Ce7PTWxxJuqCtq/htswJRrrrAQJMM=; b=c++1vpcsNyM7NDN2iLT7O7thkPFS/swPb6Lm6F6yEnh29AXAF0B6tnZwIFA30Lank0 RbOjASYqo6jUwynEgiCjIiww7JDUO7NLGq21tEDcIxhmmQ4oPq/vYUFJGIdS4/Nqw6YO S25+LOQX8y98Z7e78suOmEjOhABbJqZVjXaqKX2zUrjoXsRwPPe0MyYjLiXFIABOWrFs jBLsN6TLKtxtXCDAydyRezrqwWrw4slNUWU5oQ7dSF35uVJLjvgQWu+4OPDsZLMefK16 eUd8XzQq+1JzfQSvde+ghDmNFwOF712CoLo9HInsWbxdgMSKSJtoy44Ez7vD6veqecbZ Clmw== X-Received: by 10.224.25.8 with SMTP id x8mr8107681qab.77.1384495550956; Thu, 14 Nov 2013 22:05:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.185.33 with HTTP; Thu, 14 Nov 2013 22:05:30 -0800 (PST) In-Reply-To: <5285320C.7030702@viagenie.ca> References: <5285320C.7030702@viagenie.ca> From: Cong Liu Date: Fri, 15 Nov 2013 14:05:30 +0800 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c2dc3c82095004eb30fd1c Cc: "softwires@ietf.org" Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 06:05:52 -0000 --001a11c2dc3c82095004eb30fd1c Content-Type: text/plain; charset=ISO-8859-1 I support change it to "optional". The "mandatory" here means when using lw4o6_container, OPTION_S46_IPV4ADDRESS is mandatory => If OPTION_S46_IPV4ADDRESS is not used, do not use lw4o6_container. It means when using PCP or DHCPv4oDHCPv6, containers can never be used. So DHCPv6 can not be used to provision lwAFTR address (OPTION_S46_BR is a suboption inside containers). Best Regards, Cong 2013/11/15 Simon Perreault > WG, > > Currently draft-ietf-softwire-map-dhcp-05 says that > OPTION_S46_IPV4ADDRESS is mandatory. It has to be made at least optional so > that DHCPv4oDHCPv6 or PCP can be used for IPv4 address provisioning. > > Can we go further? Can we just remove OPTION_S46_IPV4ADDRESS? The result > would be that DHCPv4oDHCPv6 or PCP would become mandatory. > > Any opinion on this? > > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --001a11c2dc3c82095004eb30fd1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support change it to "optional".

The "mand= atory" here means when using lw4o6_container,=A0OPTION_S46_IPV4ADDRESS is mand= atory =3D> If=A0OPTION_S46_IPV4ADDRESS is not used, do not use lw4o6_container.<= /span>
= It means when using PCP or DHCPv4oDHCPv6, containers can never be used. So = DHCPv6 can not be used to provision lwAFTR address (OPTION_S46_BR is a suboption inside c= ontainers).

=

=
Best Regard= s,
Cong
=


2013/11= /15 Simon Perreault <simon.perreault@viagenie.ca><= br>
WG,

Currently draft-ietf-softwire-map-dhcp-05 says that OPTION_S46_IPV4A= DDRESS is mandatory. It has to be made at least optional so that DHCPv4oDHC= Pv6 or PCP can be used for IPv4 address provisioning.

Can we go further? Can we just remove OPTION_S46_IPV4ADDRESS? The result wo= uld be that DHCPv4oDHCPv6 or PCP would become mandatory.

Any opinion on this?

Thanks,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--001a11c2dc3c82095004eb30fd1c-- From ian.farrer@telekom.de Thu Nov 14 23:37:46 2013 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 19DF211E80DC for ; Thu, 14 Nov 2013 23:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vo5xqwU1fJOg for ; Thu, 14 Nov 2013 23:37:42 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id C7D8711E8101 for ; Thu, 14 Nov 2013 23:37:40 -0800 (PST) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 15 Nov 2013 08:37:38 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.39]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 15 Nov 2013 08:37:38 +0100 From: To: , Date: Fri, 15 Nov 2013 08:37:37 +0100 Thread-Topic: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS Thread-Index: Ac7h1Y+nmO5tA0wVTACEsSX3nRUS8Q== Message-ID: In-Reply-To: <5285320C.7030702@viagenie.ca> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 07:37:46 -0000 Hi Simon, Optional is fine. Removal gives us a hole in the solution. Currently, we=B9ve got lw4o6 deployed as a PoC using a fixed binding betwee= n v6 addr, v4 + ports. As a solution for this particular problem, it works and provisioning this over DHCPv6 would be much simpler than needing DHCPv4 over X (which we currently have to use as it=B9s the only defined an= d implemented lw4o6 provisioning DHCPv4 based mechanism). Removing OPTION_S46_IPV4ADDRESS effectively means that there needs to be mandatory support for something else. Adding in DHCPv4overDHCPv6 or PCP (if you don=B9t need it) increases the cruft. Cheers, Ian On 14/11/2013 21:26, "Simon Perreault" wrote: >WG, > >Currently draft-ietf-softwire-map-dhcp-05 says that >OPTION_S46_IPV4ADDRESS is mandatory. It has to be made at least optional >so that DHCPv4oDHCPv6 or PCP can be used for IPv4 address provisioning. > >Can we go further? Can we just remove OPTION_S46_IPV4ADDRESS? The result >would be that DHCPv4oDHCPv6 or PCP would become mandatory. > >Any opinion on this? > >Thanks, >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Fri Nov 15 01:24:45 2013 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 6550611E810C for ; Fri, 15 Nov 2013 01:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rO4Ago6hEx+t for ; Fri, 15 Nov 2013 01:24:39 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9A86811E810A for ; Fri, 15 Nov 2013 01:24:39 -0800 (PST) Received: from dhcp-10-61-97-205.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id D88A1605A; Fri, 15 Nov 2013 01:24:36 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_A3F1AA2F-C6A3-4172-9C40-4EB48C433F65"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Fri, 15 Nov 2013 10:24:33 +0100 Message-Id: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> References: To: " Farrer" X-Mailer: Apple Mail (2.1822) Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 09:24:45 -0000 --Apple-Mail=_A3F1AA2F-C6A3-4172-9C40-4EB48C433F65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Ian, > Optional is fine. Removal gives us a hole in the solution. >=20 > Currently, we=B9ve got lw4o6 deployed as a PoC using a fixed binding = between > v6 addr, v4 + ports. As a solution for this particular problem, it = works > and provisioning this over DHCPv6 would be much simpler than needing > DHCPv4 over X (which we currently have to use as it=B9s the only = defined and > implemented lw4o6 provisioning DHCPv4 based mechanism). >=20 > Removing OPTION_S46_IPV4ADDRESS effectively means that there needs to = be > mandatory support for something else. Adding in DHCPv4overDHCPv6 or = PCP > (if you don=B9t need it) increases the cruft. if optional, we have to think through the corner cases: - how does a CPE know when to initiate DHCPv4 (or PCP)? - can a CPE end up with an IPv4 address provisioned both with = OPTION_S46_IPV4ADDRESS and DHCPv4 (and PCP)? - what does the CPE do with IPv4 addresses with longer lifetimes than = the softwire? I'm sure there are more. keeping choice down makes for a simpler solution. cheers, Ole --Apple-Mail=_A3F1AA2F-C6A3-4172-9C40-4EB48C433F65 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJShehRAAoJEFuJXizso86ghkAH/ROkIAOLdPjbkbdiQeRsbHZf 52K6S8XT54PXUWPVlcDRzol5xmwzT5aU6A7gmcQsxMTROdOXK9BNTcAOxpgi73Np mUXjFyBgU1UjsjlUiTIJ8lZUMrT3O9vPOjkURy/sXAgXx0dC2UKr/C/F1SxMlBoa p7wYrA6wOhJ6QKUmYbBK9lxAwd0W+gynwz5teUjzEXMvSb4i2XzYt3JCb52TBRLN 68Z17HholgiH4AfdE4DiKzm37Nwzv48MqbfltasAnO5F4qKhY2r32nirpwIxG4x+ 6pSoux9FpKHY37vr8dAAJBR2Ngav6SdYWmHurgqoYw4nBMDGSSfwkws+KreAJbc= =BRVb -----END PGP SIGNATURE----- --Apple-Mail=_A3F1AA2F-C6A3-4172-9C40-4EB48C433F65-- From ian.farrer@telekom.de Fri Nov 15 04:23:43 2013 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 2D99011E81AF for ; Fri, 15 Nov 2013 04:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUgdNI5Ttium for ; Fri, 15 Nov 2013 04:23:38 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id BA52C11E8142 for ; Fri, 15 Nov 2013 04:23:37 -0800 (PST) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 15 Nov 2013 13:23:36 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.39]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 15 Nov 2013 13:23:32 +0100 From: To: Date: Fri, 15 Nov 2013 13:23:29 +0100 Thread-Topic: ***CAUTION_Invalid_Signature*** Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS Thread-Index: Ac7h/X+zAxG8h9B7Tc2z/gTMSWG4xg== Message-ID: In-Reply-To: <11073373.25817.1384507486387.JavaMail.trustmail@he111460> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires@ietf.org Subject: Re: [Softwires] ***CAUTION_Invalid_Signature*** Re: On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 12:23:43 -0000 Hi Ole, > >if optional, we have to think through the corner cases: > - how does a CPE know when to initiate DHCPv4 (or PCP)? [ian] Unified CPE is scoped to solve this. > - can a CPE end up with an IPv4 address provisioned both with >OPTION_S46_IPV4ADDRESS > and DHCPv4 (and PCP)? [ian] Again, unified CPE describes how to deal with this, if it=B9s possibl= e to happen. > - what does the CPE do with IPv4 addresses with longer lifetimes than >the softwire? [ian] lw4o6 states that if the v6 prefix changes, it re-runs whatever v4 provisioning, so it would be up to the v4 config server to decide if the same or new parameters were given out. > >I'm sure there are more. >keeping choice down makes for a simpler solution. [ian] the problem that we have here is that we=B9re trying to solve hybrid provisioning cases: If I get this parameter from DHCPv4 and this from DHCPv6, then how do I deal with it? The simple answer here is to say: don=B9t do hybrid provisioning. If option_s46_xx provides all the v4 conf you need, need, then use it. If it doesn=B9t, then use DHCPv4overDHCPv6. Thinking further about Simon=B9s original question, which sparked this discussion: if you=B9re implementing the OPTION_SW_CONT_LW46, then you have to implement all of the sub-options that it needs including the OPTION_S46_IPV4ADDRESS. Then it=B9s a self-contained softwire provisioning mechanism in it=B9s own right. Likewise, DHCPv4o6 and PCP need to provide self-contained softwire provisioning mechanisms in their own right. DHCPv6 may be used to switch them on, but all of the actual parameters that are necessary for provisioning the softwire come through DHCPv4o6 or PCP. If we go down this road, then adding the previously suggested priority field as a sub option into OPTION_S46_XX, OPTION_S46_DHCPV4OVERV6_ACTIVATE(?) and OPTION_S46_PCP_ACTIVATE(?) gives both the CPE a way of indicating what it can do, and for the operator to indicate what they would prefer without having to consider all 'Possible Parameters' x =8Cavailable configuration protocols=B9. Cheers, Ian From ian.farrer@telekom.de Fri Nov 15 04:35:12 2013 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 A4F1D11E814C for ; Fri, 15 Nov 2013 04:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Egjn7nO05okS for ; Fri, 15 Nov 2013 04:35:08 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id C4EC711E8151 for ; Fri, 15 Nov 2013 04:35:06 -0800 (PST) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 15 Nov 2013 13:35:04 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.39]) by HE113656.emea1.cds.t-internal.com ([10.134.99.16]) with mapi; Fri, 15 Nov 2013 13:35:03 +0100 From: To: , Date: Fri, 15 Nov 2013 13:35:02 +0100 Thread-Topic: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS Thread-Index: Ac7h/xvk2m8C860QR9CazHHTl8QRJw== Message-ID: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 12:35:12 -0000 SGkgU2ltb24sDQoNClRoaW5raW5nIGZ1cnRoZXIgb24gdGhpcyB0b3BpYywgSaGvdmUgY2hhbmdl ZCBteSBtaW5koaYNCg0KSWYgeW91IGFyZSBpbXBsZW1lbnRpbmcgT1BUSU9OX1M0Nl9DT05UX0xX NDYsIEkgc2F5IHlvdSBoYXZlIHRvIGltcGxlbWVudA0KYWxsIG9mIHRoZSBzdWItb3B0aW9ucyBu ZWNlc3NhcnkgdG8gcHJvdmlzaW9uIGl0LCBpbmNsdWRpbmcNCk9QVElPTl9TNDZfSVBWNEFERFJF U1MuDQoNCklmIHlvdSB3YW50IHRvIHVzZSBESENQVjRvREhDUHY2IG9yIFBDUCwgdGhlbiB5b3Ug ZG9uoa90IGhhdmUgdG8gaW1wbGVtZW50DQpPUFRJT05fUzQ2X1hYIGF0IGFsbC4NCg0KUmVhc29u aW5nOiANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zb2Z0d2lyZXMvY3Vy cmVudC9tc2cwNTcyOC5odG1sDQoNCkNoZWVycywNCklhbg0KDQoNCg0KT24gMTUvMTEvMjAxMyAw ODozNywgIkZhcnJlciwgSWFuIiA8aWFuLmZhcnJlckB0ZWxla29tLmRlPiB3cm90ZToNCg0KPkhp IFNpbW9uLA0KPg0KPk9wdGlvbmFsIGlzIGZpbmUuIFJlbW92YWwgZ2l2ZXMgdXMgYSBob2xlIGlu IHRoZSBzb2x1dGlvbi4NCj4NCj5DdXJyZW50bHksIHdlqfZ2ZSBnb3QgbHc0bzYgZGVwbG95ZWQg YXMgYSBQb0MgdXNpbmcgYSBmaXhlZCBiaW5kaW5nIGJldHdlZW4NCj52NiBhZGRyLCB2NCArIHBv cnRzLiBBcyBhIHNvbHV0aW9uIGZvciB0aGlzIHBhcnRpY3VsYXIgcHJvYmxlbSwgaXQgd29ya3MN Cj5hbmQgcHJvdmlzaW9uaW5nIHRoaXMgb3ZlciBESENQdjYgd291bGQgYmUgbXVjaCBzaW1wbGVy IHRoYW4gbmVlZGluZw0KPkRIQ1B2NCBvdmVyIFggKHdoaWNoIHdlIGN1cnJlbnRseSBoYXZlIHRv IHVzZSBhcyBpdKn2cyB0aGUgb25seSBkZWZpbmVkIGFuZA0KPmltcGxlbWVudGVkIGx3NG82IHBy b3Zpc2lvbmluZyBESENQdjQgYmFzZWQgbWVjaGFuaXNtKS4NCj4NCj5SZW1vdmluZyBPUFRJT05f UzQ2X0lQVjRBRERSRVNTIGVmZmVjdGl2ZWx5IG1lYW5zIHRoYXQgdGhlcmUgbmVlZHMgdG8gYmUN Cj5tYW5kYXRvcnkgc3VwcG9ydCBmb3Igc29tZXRoaW5nIGVsc2UuIEFkZGluZyBpbiBESENQdjRv dmVyREhDUHY2IG9yIFBDUA0KPihpZiB5b3UgZG9uqfZ0IG5lZWQgaXQpIGluY3JlYXNlcyB0aGUg Y3J1ZnQuDQo+DQo+Q2hlZXJzLA0KPklhbg0KPg0KPg0KPg0KPk9uIDE0LzExLzIwMTMgMjE6MjYs ICJTaW1vbiBQZXJyZWF1bHQiIDxzaW1vbi5wZXJyZWF1bHRAdmlhZ2VuaWUuY2E+DQo+d3JvdGU6 DQo+DQo+PldHLA0KPj4NCj4+Q3VycmVudGx5IGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLWRoY3At MDUgc2F5cyB0aGF0DQo+Pk9QVElPTl9TNDZfSVBWNEFERFJFU1MgaXMgbWFuZGF0b3J5LiBJdCBo YXMgdG8gYmUgbWFkZSBhdCBsZWFzdCBvcHRpb25hbA0KPj5zbyB0aGF0IERIQ1B2NG9ESENQdjYg b3IgUENQIGNhbiBiZSB1c2VkIGZvciBJUHY0IGFkZHJlc3MgcHJvdmlzaW9uaW5nLg0KPj4NCj4+ Q2FuIHdlIGdvIGZ1cnRoZXI/IENhbiB3ZSBqdXN0IHJlbW92ZSBPUFRJT05fUzQ2X0lQVjRBRERS RVNTPyBUaGUgcmVzdWx0DQo+PndvdWxkIGJlIHRoYXQgREhDUHY0b0RIQ1B2NiBvciBQQ1Agd291 bGQgYmVjb21lIG1hbmRhdG9yeS4NCj4+DQo+PkFueSBvcGluaW9uIG9uIHRoaXM/DQo+Pg0KPj5U aGFua3MsDQo+PlNpbW9uDQo+Pi0tIA0KPj5EVE4gbWFkZSBlYXN5LCBsZWFuLCBhbmQgc21hcnQg LS0+IGh0dHA6Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUuY2ENCj4+TkFUNjQvRE5TNjQgb3Blbi1z b3VyY2UgICAgICAgIC0tPiBodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYQ0KPj5TVFVOL1RVUk4g c2VydmVyICAgICAgICAgICAgICAgLS0+IGh0dHA6Ly9udW1iLnZpYWdlbmllLmNhDQo+Pl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PlNvZnR3aXJlcyBt YWlsaW5nIGxpc3QNCj4+U29mdHdpcmVzQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQo+DQoNCg== From otroan@employees.org Fri Nov 15 04:57:27 2013 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 1314C11E80F1 for ; Fri, 15 Nov 2013 04:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFSn1cW1Da9T for ; Fri, 15 Nov 2013 04:57:20 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5042E21F99E9 for ; Fri, 15 Nov 2013 04:57:20 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAO8ZhlKQ/khL/2dsb2JhbABZgwe8D4QfgScWdIIlAQEEAXkFCwtGVwYTG4dgBsEIj2kHgyCBEQOQMJImh0eBaoE/Ow X-IronPort-AV: E=Sophos;i="4.93,707,1378857600"; d="asc'?scan'208";a="88201441" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 15 Nov 2013 12:57:09 +0000 Received: from dhcp-10-61-97-205.cisco.com (dhcp-10-61-97-205.cisco.com [10.61.97.205]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAFCv5PT021649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Nov 2013 12:57:06 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_CF3BDDCD-E28B-45CD-8264-53C14D33CF3E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Fri, 15 Nov 2013 13:57:05 +0100 Message-Id: <3ED1A3E7-D5C0-471E-9EA5-54676D89BEDF@employees.org> References: To: " Farrer" X-Mailer: Apple Mail (2.1822) Cc: Softwires Subject: Re: [Softwires] ***CAUTION_Invalid_Signature*** Re: On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 12:57:27 -0000 --Apple-Mail=_CF3BDDCD-E28B-45CD-8264-53C14D33CF3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ian, confused, so please bear with me. I thought the OPTION_SW_CONT_LW46 was going to be used to provision the = softwire, regardless of how IPv4 was provisioned on top of it. you seem to indicate below, that is not the case? if so, there would be no reason to make OPTION_S46_IPV4ADDRESS optional. how would you then provision the softwires? I think we need a complete picture to ensure we have the right thing in = MAP DHCP. cheers, Ole On 15 Nov 2013, at 13:23 , = wrote: > Hi Ole, >=20 >=20 >>=20 >> if optional, we have to think through the corner cases: >> - how does a CPE know when to initiate DHCPv4 (or PCP)? >=20 > [ian] Unified CPE is scoped to solve this. >=20 >> - can a CPE end up with an IPv4 address provisioned both with >> OPTION_S46_IPV4ADDRESS >> and DHCPv4 (and PCP)? >=20 > [ian] Again, unified CPE describes how to deal with this, if it=B9s = possible > to happen. >=20 >> - what does the CPE do with IPv4 addresses with longer lifetimes than >> the softwire? >=20 > [ian] lw4o6 states that if the v6 prefix changes, it re-runs whatever = v4 > provisioning, so it would be up to the v4 config server to decide if = the > same or new parameters were given out. >>=20 >> I'm sure there are more. >> keeping choice down makes for a simpler solution. >=20 > [ian] the problem that we have here is that we=B9re trying to solve = hybrid > provisioning cases: If I get this parameter from DHCPv4 and this from > DHCPv6, then how do I deal with it? >=20 > The simple answer here is to say: don=B9t do hybrid provisioning. If > option_s46_xx provides all the v4 conf you need, need, then use it. If = it > doesn=B9t, then use DHCPv4overDHCPv6. >=20 > Thinking further about Simon=B9s original question, which sparked this > discussion: if you=B9re implementing the OPTION_SW_CONT_LW46, then you = have > to implement all of the sub-options that it needs including the > OPTION_S46_IPV4ADDRESS. Then it=B9s a self-contained softwire = provisioning > mechanism in it=B9s own right. >=20 > Likewise, DHCPv4o6 and PCP need to provide self-contained softwire > provisioning mechanisms in their own right. DHCPv6 may be used to = switch > them on, but all of the actual parameters that are necessary for > provisioning the softwire come through DHCPv4o6 or PCP. >=20 > If we go down this road, then adding the previously suggested priority > field as a sub option into OPTION_S46_XX, > OPTION_S46_DHCPV4OVERV6_ACTIVATE(?) and OPTION_S46_PCP_ACTIVATE(?) = gives > both the CPE a way of indicating what it can do, and for the operator = to > indicate what they would prefer without having to consider all = 'Possible > Parameters' x =8Cavailable configuration protocols=B9. >=20 > Cheers, > Ian >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_CF3BDDCD-E28B-45CD-8264-53C14D33CF3E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJShhohAAoJEFuJXizso86goIcIANHwXWvpFv9IafhjWMGamocV hbNxU4Z2NZMjubFYe9aSgdb+alYe6UDO+WPviQXjQOFPi8LBXxNZ8mRMHvslY0q3 jfjdRnYigTZsqZhsHEehlOplUjveKB1YxLStlmyYcc4cvWcr9KI2ntP/WLLazVoT ddMdBR3USfR/4mnEV5HwMH+peuhcveFXfP18GMmOLK2pohoPTHvCsj4BCX+vgQBd DUElPJIjem627wIyrldb6F6ggGJ8miN1qcb+laH4WEAQrnJ3bngk9jANbg90pm+I CiOI5NvVmj9sR+98rH4oDkPEPAM2bhhlUTHF5umhs/aeReC5dL3Lmr0au+IAsR8= =fl6c -----END PGP SIGNATURE----- --Apple-Mail=_CF3BDDCD-E28B-45CD-8264-53C14D33CF3E-- From sunqi.csnet.thu@gmail.com Fri Nov 15 05:11:00 2013 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 08BFD11E80F9 for ; Fri, 15 Nov 2013 05:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFbddq+QnyP1 for ; Fri, 15 Nov 2013 05:10:59 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 90EDF11E80F1 for ; Fri, 15 Nov 2013 05:10:59 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id y10so3465613pdj.33 for ; Fri, 15 Nov 2013 05:10:59 -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; bh=UOgebO6tlup9GyQOF244IQjHq/lyAo6THy2hSBtj4Gk=; b=oQrtuXqp18/CFIA11t3xX0DS2TR05vmrWboj8C+3sq9R0p6Y7zoYGI671ZHgALH6RY sh5BmttdQW1kZRptmABhx+WE3fNObrC6k3kjbVCiHxsVjzduFxffnsZzpdh+koQveT5R BuEvzziHowGsP/7ou9ot8HZ+ZUvCpsqC+09j7aZkDcW/USF5fuJdeuntU+o+Nz3fgB4d 8sgevTc8iV1LvLi0Q1IA54KqfCDJbnSfA0/Z1sZ1cNrlMu71HFh2m/jsbeDeESzTBeLZ x2k8cliGr5Mvz7bexNuldRSc6E2fxiHey2EKLUN4upx4Inwjidbb5ejogQbnOTffLjyo aDSQ== X-Received: by 10.66.132.69 with SMTP id os5mr6635797pab.114.1384521059327; Fri, 15 Nov 2013 05:10:59 -0800 (PST) Received: from [192.168.199.122] ([166.111.68.231]) by mx.google.com with ESMTPSA id gf5sm4471401pbc.22.2013.11.15.05.10.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 05:10:58 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> Date: Fri, 15 Nov 2013 21:10:46 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1085) Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 13:11:00 -0000 Ole, On 2013-11-15, at =E4=B8=8B=E5=8D=885:24, Ole Troan wrote: > if optional, we have to think through the corner cases: > - how does a CPE know when to initiate DHCPv4 (or PCP)? [Qi] An enable option (DHCPv6 option) would indicate the CPE to use = DHCPv4 (or PCP), like the DHCPv4oDHCPv6 Enable Option in DHCPv4oDHCPv6. Best Regards, Qi > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Fri Nov 15 05:36:09 2013 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 D604C11E8188 for ; Fri, 15 Nov 2013 05:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz5pdZ7mssED for ; Fri, 15 Nov 2013 05:36:04 -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 D827F11E8185 for ; Fri, 15 Nov 2013 05:35:58 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAGkihlKQ/khL/2dsb2JhbABZgwfALoEmFnSCJQEBBAF5EAtGVwaIDgbBCo9pB4MggREDkDCSJodHgyk7 X-IronPort-AV: E=Sophos;i="4.93,708,1378857600"; d="asc'?scan'208";a="19077955" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 15 Nov 2013 13:35:57 +0000 Received: from dhcp-10-61-109-168.cisco.com (dhcp-10-61-109-168.cisco.com [10.61.109.168]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAFDZrmm030835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Nov 2013 13:35:54 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_4B24909F-3B5B-4614-BF47-149BF682BF98"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Fri, 15 Nov 2013 14:35:52 +0100 Message-Id: References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> To: Qi Sun X-Mailer: Apple Mail (2.1822) Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 13:36:10 -0000 --Apple-Mail=_4B24909F-3B5B-4614-BF47-149BF682BF98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Qi, >> if optional, we have to think through the corner cases: >> - how does a CPE know when to initiate DHCPv4 (or PCP)? >=20 > [Qi] An enable option (DHCPv6 option) would indicate the CPE to use = DHCPv4 (or PCP), like the DHCPv4oDHCPv6 Enable Option in DHCPv4oDHCPv6. let me see if I understand your proposal. provision the softwire with the LW46 container option. the container options then contains one of: - the IPv4 address option - enable DHCPv4 option - or enable PCP option ? cheers, Ole --Apple-Mail=_4B24909F-3B5B-4614-BF47-149BF682BF98 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJShiM5AAoJEFuJXizso86g1AUIAIrQo+UYmNjDGO2N4uaT+9zx q3Wd95gI9qVGkT2H8Ba4KRZhbipXngNxRVMHnV8VZ/TkOLnQzc6zRRQUFJrZTzwf tWle9r2kIpFNz7L6z29+t5aaWZ68hdcSmpMUBvCGaWmkAXeIE7PV0NWSYVTFe6gU nyEVNLkxFwckB52Q6KZTnNW3NEXAxZCpiSeeMLBItttcSgPMAi79RsTYdNcXKl7p 95EhPHp+ZH557hYZLuy7ubVh1Xu8FLMkq6SNg4CJm1kGaZYoD2J1CdkdFC4jntaK HoUgG5+KdwkZDfzRDJVmzawzyPX215fwdxlvyjKrB30PUGZjAbjP3MEaPT0uMMQ= =kDGG -----END PGP SIGNATURE----- --Apple-Mail=_4B24909F-3B5B-4614-BF47-149BF682BF98-- From sunqi.csnet.thu@gmail.com Fri Nov 15 05:44:01 2013 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 70A3211E8188 for ; Fri, 15 Nov 2013 05:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le7uIitHT3oN for ; Fri, 15 Nov 2013 05:44:01 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 16B3E11E81A9 for ; Fri, 15 Nov 2013 05:43:59 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id bj1so3594067pad.35 for ; Fri, 15 Nov 2013 05:43:58 -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; bh=2h0aBfk9uJgkLsHxajjHogH/Wyt2OrtRxEpsMfM/z98=; b=idehPTHB97d4c+jDBSyvjvPMBIzxq3c3/21CRh3KBFAQbX1j9/noY9sHcgjjysF1XV ladMbu/mVKTXl+JwVkL8+QGQDqO0efu6oOvbTjtEhhyzgkMMx+OoofVGtauVPSoFgpwp q6VJ1FhNDCApIE6wRKcZIqrpW1mm6MYgktlFsxLO87H1F8+Rsl4iQUNElyhqHsEEbV2G WNjyROwzqMt38PsfmkdAbwCe+H5I60Olv3Gzw/zBItz8EB4ihRjXQ2evzuPJE4Us2v37 Uj0xOtfbR/VAvOwbTazTHLlTzmyGLvOrABdBnavzn7kQhSvSnM1dUCkwVlvBsR9Gz5Sl qf3w== X-Received: by 10.66.121.234 with SMTP id ln10mr6864606pab.20.1384523038837; Fri, 15 Nov 2013 05:43:58 -0800 (PST) Received: from [192.168.199.122] ([166.111.68.231]) by mx.google.com with ESMTPSA id dq3sm4634018pbc.35.2013.11.15.05.43.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 05:43:58 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Fri, 15 Nov 2013 21:43:46 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1085) Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 13:44:01 -0000 Ole On 2013-11-15, at =E4=B8=8B=E5=8D=889:35, Ole Troan wrote: > Qi, >=20 >>> if optional, we have to think through the corner cases: >>> - how does a CPE know when to initiate DHCPv4 (or PCP)? >>=20 >> [Qi] An enable option (DHCPv6 option) would indicate the CPE to use = DHCPv4 (or PCP), like the DHCPv4oDHCPv6 Enable Option in DHCPv4oDHCPv6. >=20 > let me see if I understand your proposal. > provision the softwire with the LW46 container option. >=20 > the container options then contains one of: > - the IPv4 address option > - enable DHCPv4 option > - or enable PCP option >=20 > ? I'm thinking of this combination in the container option: - the BR IPv6 address option - DHCPv4oDHCPv6 Enable option - or enable PCP option Does it make sense? Best Regards, Qi From ian.farrer@telekom.de Fri Nov 15 05:47:17 2013 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 0BDC611E81A2 for ; Fri, 15 Nov 2013 05:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmZpmJCF0uYX for ; Fri, 15 Nov 2013 05:47:03 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 10DBC11E8188 for ; Fri, 15 Nov 2013 05:46:51 -0800 (PST) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 15 Nov 2013 14:46:49 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.39]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 15 Nov 2013 14:46:49 +0100 From: To: Date: Fri, 15 Nov 2013 14:46:47 +0100 Thread-Topic: ***CAUTION_Invalid_Signature*** Re: ***CAUTION_Invalid_Signature*** Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS Thread-Index: Ac7iCSJApgm+IXPXRHyBl6nOpvyfuQ== Message-ID: In-Reply-To: <1878368.27593.1384520242511.JavaMail.trustmail@he111460> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: softwires@ietf.org Subject: Re: [Softwires] ***CAUTION_Invalid_Signature*** Re: ***CAUTION_Invalid_Signature*** Re: On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 13:47:17 -0000 SGkgT2xlLA0KDQpRaSBiZWF0IG1lIHRvIGl0IQ0KDQpUaGUgb3B0aW9u4oCZcyBhbHJlYWR5IGRl ZmluZWQgaW4gdGhlIERIQ1B2NG92ZXJESENQdjYgZHJhZnQuIFdoYXQgd2UgbmVlZA0KdG8gZG8g aGVyZSBpcyB0byBlbnN1cmUgdGhhdCB0aGUgVW5pZmllZCBtZWNoYW5pc20gY292ZXJzIHRoaXMg YXMgd2VsbC4NCg0KQXMgZm9yIGEgY29tcGxldGUgcGljdHVyZSAod2VsbCBhIHRodW1ibmFpbCBz a2V0Y2gpOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0NCkRIQ1B2NiAoT1BUSU9OX1M0Nl9YWCkgcHJv dmlzaW9ucyBzb2Z0d2lyZSBJUHY0IGJhc2ljIGNvbmZpZyBvbmx5Lg0KU2VwYXJhdGUgY29udGFp bmVyIG9wdGlvbnMgZm9yIE1BUC1FLCBNQVAtVCAmIGx3NG82Lg0KVGhlc2UgYXJlOiBPUFRJT05f UzQ2X0NPTlRfTUFQRSwgT1BUSU9OX1M0Nl9DT05UX01BUEUsIE9QVElPTl9TNDZfQ09OVF9MVy4N Cg0KREhDUHY0b3ZlckRIQ1B2NiBkb2VzIGR5bmFtaWMgSVB2NCBsZWFzaW5nIHBsdXMgYW55IG90 aGVyIERIQ1B2NCBvcHRpb25zIC0NCml0IG5lZWRzIGV4dGVuZGluZyB0byBkZWFsIHdpdGggc2hh cmVkIGFkZHJlc3NpbmcsIGJ1dCB3b3JrIG9uIHRoaXMgaXMgYQ0KbGl0dGxlIHN0YWxsZWQgd2Fp dGluZyBmb3IgdGhlIG91dGNvbWUgb2YgdGhlIOKAmGhvdyB0byBwcm92aXNpb24gREhDUHY0IGlu DQp2NiBvbmx5IG5ldHdvcmtzP+KAmSBkaXNjdXNzaW9uIGluIERIQy4NCkEgREhDUHY2IGZsYWcg aW5kaWNhdGVzIHN1cHBvcnQgYnkgdGhlIGNsaWVudCBhbmQsIGlmIHJldHVybmVkLCBpbmRpY2F0 ZXMNCnRoYXQgdGhlIGNsaWVudCBhdHRlbXB0cyB2NCBjb25maWd1cmF0aW9uIHVzaW5nIG5vcm1h bCBJUHY0IERIQ1BESVNDT1ZFUi4NClRoaXMgaXMgb3B0aW9uIGlzIGNhbGxlZCBPUFRJT05fREhD UDRfT19ESENQNl9FTkFCTEUuDQoNClBDUCAodGhpcyBpcyBub3QgbXkgYXJlYSwgc28gdGhpcyBp cyBzcGVjdWxhdGlvbiBhYm91dCBob3cgSSB0aGluayBpdA0KbWlnaHQgd29yaykgLSB0aGlzIHdv dWxkIGJlIHNpbWlsYXIgdG8gREhDUHY0b0RIQ1B2NiAtIEkuZS4gQ2FwYWJpbGl0eSBhbmQNCmNv bmZpZ3VyYXRpb24gaW5kaWNhdGVkIGJ5IGEgREhDUHY2IG9wdGlvbi4gTm90IGRlZmluZWQsIGJ1 dCBsZXTigJlzIGNhbGwNCnRoaXM6IE9QVElPTl9TNDZfUENQX0VOQUJMRS4NCg0KVG8gcm9sbCB0 aGlzIHRvZ2V0aGVyIChJLmUuIFRoZSBiYXNpcyBmb3IgYSB1bmlmaWVkIENQRSksIGlzIHRoYXQg YQ0K4oCYcHJpb3JpdGllc+KAmSBzdWItb3B0aW9uIGdldHMgYWRkZWQgdG8gdGhlIG9wdGlvbnMg ZGVmaW5lZCBhYm92ZS4gVGhpcw0KYWxsb3cgYW4gb3BlcmF0b3IgdG8gc2lnbmFsIHRvIGEgZGV2 aWNlIHdoaWNoIG9uZSBoZSB3b3VsZCBwcmVmZXIgdGhlbSB0bw0KdXNlIHdpdGhvdXQgaGF2aW5n IGEgbG9hZCBvZiBzZXJ2ZXIgc2lkZSBsb2dpYyBzYXlpbmcg4oCYaWYgeW91IHN1cHBvcnQNCnRo ZXNlIHRoZW4gcHJvdmlzaW9uIHRoYXQgZXRjLuKAmS4gQSBjbGllbnQgc2lnbmFscyBldmVyeXRo aW5nIGl0IGNhbiBkbw0Kd2l0aCB0aGUgT1JPIGFuZCB0aGUgc2VydmVyIHJlcGxpZXMgd2l0aCBh IHByaW9yaXR5LiBUaGUgY2xpZW50IGNvbmZpZ3VyZXMNCml04oCZcyBzb2Z0d2lyZSB3aXRoIHVz aW5nIHRoZSBjb25maWcgbWVjaGFuaXNtIHJlY2VpdmVkIHdpdGggdGhlIGhpZ2hlc3QNCnByaW9y aXR5Lg0KDQpBbm90aGVyIHBvaW50IHRoYXQgaGFzbuKAmXQgYmVlbiBkaXNjdXNzZWQgaXMgaG93 IHRoaXMgd291bGQgYWxsIHdvcmsgd2l0aA0KRFMtTGl0ZS4gTXkgc3VnZ2VzdGlvbiBoZXJlIGlz IHRoYXQgRFMtbGl0ZSBoYXMgYW4gaW1wbGljaXQgcHJpb3JpdHkgaW4NCnRoZSBtaWRkbGUgb2Yg dGhlIHByaW9yaXR5IHJhbmdlLiBUaGlzIHdheSB5b3UgY2FuIHByaW9yaXRpc2UgaXQgb3INCmRl LXByaW9yaXRpc2UgaXQgYW5kIHRoZXJlIGRvZXNu4oCZdCBuZWVkIHRvIGJlIGFueSBjaGFuZ2Vz IHRvIGV4aXN0aW5nDQpEUy1MaXRlIGltcGxlbWVudGF0aW9ucy4NCg0KT25lIGFkZGl0aW9uYWwg cG9pbnQ6DQoNCkEgY2xpZW50IHVzaW5nIERIQ1B2NiBmb3Igc29mdHdpcmUgSVB2NCBjb25maWcg Y291bGQgdXNlIERIQ1BJTkZPUk0gb3Zlcg0KREhDUHY0b3ZlckRIQ1B2NiB0byBnZXQgYWRkaXRp b25hbCB2NCBvcHRpb25zLg0KV2UgY291bGQgcG9zc2libHkgdXNlIGEgREhDUHY2IGZsYWcgdG8g dHVybiB0aGlzIG9uIChhcyBhYm92ZSwgYnV0IG9ubHkNCmZvciBESENQSU5GT1JNKSAtICB0aGlz IGhhc27igJl0IGJlZW4gZGlzY3Vzc2VkIHNvIGZhci4gSG93IHRoaXMgc2l0cyBpbg0Kd2l0aCB0 aGUgcHJpb3JpdGlzYXRpb24gd291bGQgbmVlZCB0byBiZSB3b3JrZWQgdGhyb3VnaCAocG9zc2li bHkgbWFrZSBpdA0Kb25seSBhbGxvd2FibGUgaW4gdXNlIHdpdGggdGhlIE9QVElPTl9TNDZfQ09O VF9YWFggb3B0aW9uKXMuDQrigJTigJTigJTigJTigJTigJTigJTigJTigJQNCg0KVGhhdOKAmXMg aG93IEkgc2VlIGl0IGFsbCB3b3JraW5nLCB0b2RheSBhdCBsZWFzdDotKQ0KDQpDaGVlcnMsDQoN Cklhbg0KDQoNCg0KDQoNCk9uIDE1LzExLzIwMTMgMTM6NTcsICJPbGUgVHJvYW4iIDxvdHJvYW5A ZW1wbG95ZWVzLm9yZz4gd3JvdGU6DQoNCj5JYW4sDQo+DQo+Y29uZnVzZWQsIHNvIHBsZWFzZSBi ZWFyIHdpdGggbWUuDQo+DQo+SSB0aG91Z2h0IHRoZSBPUFRJT05fU1dfQ09OVF9MVzQ2IHdhcyBn b2luZyB0byBiZSB1c2VkIHRvIHByb3Zpc2lvbiB0aGUNCj5zb2Z0d2lyZSwNCj5yZWdhcmRsZXNz IG9mIGhvdyBJUHY0IHdhcyBwcm92aXNpb25lZCBvbiB0b3Agb2YgaXQuDQo+eW91IHNlZW0gdG8g aW5kaWNhdGUgYmVsb3csIHRoYXQgaXMgbm90IHRoZSBjYXNlPw0KPmlmIHNvLCB0aGVyZSB3b3Vs ZCBiZSBubyByZWFzb24gdG8gbWFrZSBPUFRJT05fUzQ2X0lQVjRBRERSRVNTIG9wdGlvbmFsLg0K Pg0KPmhvdyB3b3VsZCB5b3UgdGhlbiBwcm92aXNpb24gdGhlIHNvZnR3aXJlcz8NCj5JIHRoaW5r IHdlIG5lZWQgYSBjb21wbGV0ZSBwaWN0dXJlIHRvIGVuc3VyZSB3ZSBoYXZlIHRoZSByaWdodCB0 aGluZyBpbg0KPk1BUCBESENQLg0KPg0KPmNoZWVycywNCj5PbGUNCj4NCj4NCj5PbiAxNSBOb3Yg MjAxMywgYXQgMTM6MjMgLCA8aWFuLmZhcnJlckB0ZWxla29tLmRlPg0KPjxpYW4uZmFycmVyQHRl bGVrb20uZGU+IHdyb3RlOg0KPg0KPj4gSGkgT2xlLA0KPj4gDQo+PiANCj4+PiANCj4+PiBpZiBv cHRpb25hbCwgd2UgaGF2ZSB0byB0aGluayB0aHJvdWdoIHRoZSBjb3JuZXIgY2FzZXM6DQo+Pj4g LSBob3cgZG9lcyBhIENQRSBrbm93IHdoZW4gdG8gaW5pdGlhdGUgREhDUHY0IChvciBQQ1ApPw0K Pj4gDQo+PiBbaWFuXSBVbmlmaWVkIENQRSBpcyBzY29wZWQgdG8gc29sdmUgdGhpcy4NCj4+IA0K Pj4+IC0gY2FuIGEgQ1BFIGVuZCB1cCB3aXRoIGFuIElQdjQgYWRkcmVzcyBwcm92aXNpb25lZCBi b3RoIHdpdGgNCj4+PiBPUFRJT05fUzQ2X0lQVjRBRERSRVNTDQo+Pj4gIGFuZCBESENQdjQgKGFu ZCBQQ1ApPw0KPj4gDQo+PiBbaWFuXSBBZ2FpbiwgdW5pZmllZCBDUEUgZGVzY3JpYmVzIGhvdyB0 byBkZWFsIHdpdGggdGhpcywgaWYgaXTCuXMNCj4+cG9zc2libGUNCj4+IHRvIGhhcHBlbi4NCj4+ IA0KPj4+IC0gd2hhdCBkb2VzIHRoZSBDUEUgZG8gd2l0aCBJUHY0IGFkZHJlc3NlcyB3aXRoIGxv bmdlciBsaWZldGltZXMgdGhhbg0KPj4+IHRoZSBzb2Z0d2lyZT8NCj4+IA0KPj4gW2lhbl0gbHc0 bzYgc3RhdGVzIHRoYXQgaWYgdGhlIHY2IHByZWZpeCBjaGFuZ2VzLCBpdCByZS1ydW5zIHdoYXRl dmVyIHY0DQo+PiBwcm92aXNpb25pbmcsIHNvIGl0IHdvdWxkIGJlIHVwIHRvIHRoZSB2NCBjb25m aWcgc2VydmVyIHRvIGRlY2lkZSBpZiB0aGUNCj4+IHNhbWUgb3IgbmV3IHBhcmFtZXRlcnMgd2Vy ZSBnaXZlbiBvdXQuDQo+Pj4gDQo+Pj4gSSdtIHN1cmUgdGhlcmUgYXJlIG1vcmUuDQo+Pj4ga2Vl cGluZyBjaG9pY2UgZG93biBtYWtlcyBmb3IgYSBzaW1wbGVyIHNvbHV0aW9uLg0KPj4gDQo+PiBb aWFuXSB0aGUgcHJvYmxlbSB0aGF0IHdlIGhhdmUgaGVyZSBpcyB0aGF0IHdlwrlyZSB0cnlpbmcg dG8gc29sdmUgaHlicmlkDQo+PiBwcm92aXNpb25pbmcgY2FzZXM6IElmIEkgZ2V0IHRoaXMgcGFy YW1ldGVyIGZyb20gREhDUHY0IGFuZCB0aGlzIGZyb20NCj4+IERIQ1B2NiwgdGhlbiBob3cgZG8g SSBkZWFsIHdpdGggaXQ/DQo+PiANCj4+IFRoZSBzaW1wbGUgYW5zd2VyIGhlcmUgaXMgdG8gc2F5 OiBkb27CuXQgZG8gaHlicmlkIHByb3Zpc2lvbmluZy4gSWYNCj4+IG9wdGlvbl9zNDZfeHggcHJv dmlkZXMgYWxsIHRoZSB2NCBjb25mIHlvdSBuZWVkLCBuZWVkLCB0aGVuIHVzZSBpdC4gSWYNCj4+ aXQNCj4+IGRvZXNuwrl0LCB0aGVuIHVzZSBESENQdjRvdmVyREhDUHY2Lg0KPj4gDQo+PiBUaGlu a2luZyBmdXJ0aGVyIGFib3V0IFNpbW9uwrlzIG9yaWdpbmFsIHF1ZXN0aW9uLCB3aGljaCBzcGFy a2VkIHRoaXMNCj4+IGRpc2N1c3Npb246IGlmIHlvdcK5cmUgaW1wbGVtZW50aW5nIHRoZSBPUFRJ T05fU1dfQ09OVF9MVzQ2LCB0aGVuIHlvdQ0KPj5oYXZlDQo+PiB0byBpbXBsZW1lbnQgYWxsIG9m IHRoZSBzdWItb3B0aW9ucyB0aGF0IGl0IG5lZWRzIGluY2x1ZGluZyB0aGUNCj4+IE9QVElPTl9T NDZfSVBWNEFERFJFU1MuIFRoZW4gaXTCuXMgYSBzZWxmLWNvbnRhaW5lZCBzb2Z0d2lyZSBwcm92 aXNpb25pbmcNCj4+IG1lY2hhbmlzbSBpbiBpdMK5cyBvd24gcmlnaHQuDQo+PiANCj4+IExpa2V3 aXNlLCBESENQdjRvNiBhbmQgUENQIG5lZWQgdG8gcHJvdmlkZSBzZWxmLWNvbnRhaW5lZCBzb2Z0 d2lyZQ0KPj4gcHJvdmlzaW9uaW5nIG1lY2hhbmlzbXMgaW4gdGhlaXIgb3duIHJpZ2h0LiBESENQ djYgbWF5IGJlIHVzZWQgdG8gc3dpdGNoDQo+PiB0aGVtIG9uLCBidXQgYWxsIG9mIHRoZSBhY3R1 YWwgcGFyYW1ldGVycyB0aGF0IGFyZSBuZWNlc3NhcnkgZm9yDQo+PiBwcm92aXNpb25pbmcgdGhl IHNvZnR3aXJlIGNvbWUgdGhyb3VnaCBESENQdjRvNiBvciBQQ1AuDQo+PiANCj4+IElmIHdlIGdv IGRvd24gdGhpcyByb2FkLCB0aGVuIGFkZGluZyB0aGUgcHJldmlvdXNseSBzdWdnZXN0ZWQgcHJp b3JpdHkNCj4+IGZpZWxkIGFzIGEgc3ViIG9wdGlvbiBpbnRvIE9QVElPTl9TNDZfWFgsDQo+PiBP UFRJT05fUzQ2X0RIQ1BWNE9WRVJWNl9BQ1RJVkFURSg/KSBhbmQgT1BUSU9OX1M0Nl9QQ1BfQUNU SVZBVEUoPykgZ2l2ZXMNCj4+IGJvdGggdGhlIENQRSBhIHdheSBvZiBpbmRpY2F0aW5nIHdoYXQg aXQgY2FuIGRvLCBhbmQgZm9yIHRoZSBvcGVyYXRvciB0bw0KPj4gaW5kaWNhdGUgd2hhdCB0aGV5 IHdvdWxkIHByZWZlciB3aXRob3V0IGhhdmluZyB0byBjb25zaWRlciBhbGwgJ1Bvc3NpYmxlDQo+ PiBQYXJhbWV0ZXJzJyB4IMWSYXZhaWxhYmxlIGNvbmZpZ3VyYXRpb24gcHJvdG9jb2xzwrkuDQo+ PiANCj4+IENoZWVycywNCj4+IElhbg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4g DQo+PiANCj4NCg0K From gnocuil@gmail.com Fri Nov 15 05:50:16 2013 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 C92A111E818C for ; Fri, 15 Nov 2013 05:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xL-ReXGMLbww for ; Fri, 15 Nov 2013 05:50:16 -0800 (PST) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1851511E8188 for ; Fri, 15 Nov 2013 05:50:16 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id f11so539775qae.10 for ; Fri, 15 Nov 2013 05:50:15 -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=5G2+R7GS4LbWS9rakG5GsoQTTADySKPVxu5D4owdzs4=; b=VIcaVscURXMkH2DtbGH+BPebbs0QsnTfKJ2MMFt7MoojxtWvrwJlfSIknf7wJcdtBZ Sgz0OK+woU4wJOj7BMdiZXuvjNUlBe56rApaWSldqSBOF5WcJtanBqqyiseAbdNtlqoB X6Xl918RbPHkExIkWkU6pvhv9S0ba/1/BglC/dUHbsiTM0m7Nz3vjIOC9rG3UP18wDml NgHx8exKJTJx2HjQ685QuJoF5Zd7JMmOmBr2QFcTEModDU6Ad5eKyGcbAaEnS+MBTwcv wVekN1U9IiuE6d61zTynqdVuzmzO7Jv8xD4TIKurcccxFrppZGjWT9yzOWrgXs0sJjzE uBEg== X-Received: by 10.224.40.138 with SMTP id k10mr10547624qae.67.1384523415479; Fri, 15 Nov 2013 05:50:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.185.33 with HTTP; Fri, 15 Nov 2013 05:49:55 -0800 (PST) In-Reply-To: References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> From: Cong Liu Date: Fri, 15 Nov 2013 21:49:55 +0800 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=047d7bdc89fa5ced3e04eb377a04 Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 13:50:16 -0000 --047d7bdc89fa5ced3e04eb377a04 Content-Type: text/plain; charset=ISO-8859-1 DHCPv4/PCP enable options will be outside containers, because containers contains sub-options. Cong 2013/11/15 Ole Troan > Qi, > > >> if optional, we have to think through the corner cases: > >> - how does a CPE know when to initiate DHCPv4 (or PCP)? > > > > [Qi] An enable option (DHCPv6 option) would indicate the CPE to use > DHCPv4 (or PCP), like the DHCPv4oDHCPv6 Enable Option in DHCPv4oDHCPv6. > > let me see if I understand your proposal. > provision the softwire with the LW46 container option. > > the container options then contains one of: > - the IPv4 address option > - enable DHCPv4 option > - or enable PCP option > > ? > > cheers, > Ole > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --047d7bdc89fa5ced3e04eb377a04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
DHCPv4/PCP enable options will be outside containers, beca= use containers contains sub-options.

Cong

2013/11= /15 Ole Troan <otroan@employees.org>
Qi,

>> if optional, we have to think through the corner cases:
>> - how does a CPE know when to initiate DHCPv4 (or PCP)?
>
> [Qi] An enable option (DHCPv6 option) would indicate the CPE to use DH= CPv4 (or PCP), like the DHCPv4oDHCPv6 Enable Option in DHCPv4oDHCPv6.

let me see if I understand your proposal.
provision the softwire with the LW46 container option.

the container options then contains one of:
=A0- the IPv4 address option
=A0- enable DHCPv4 option
=A0- or enable PCP option

?

cheers,
Ole

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


--047d7bdc89fa5ced3e04eb377a04-- From simon.perreault@viagenie.ca Fri Nov 15 05:53:14 2013 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 34C7C11E81AD for ; Fri, 15 Nov 2013 05:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciN7BBWJ0J-p for ; Fri, 15 Nov 2013 05:53:13 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B20E11E81AB for ; Fri, 15 Nov 2013 05:53:13 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d95c:254d:9b1e:dcab]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EA19D40398; Fri, 15 Nov 2013 08:53:12 -0500 (EST) Message-ID: <52862748.8000604@viagenie.ca> Date: Fri, 15 Nov 2013 08:53:12 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ole Troan , " Farrer" References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> In-Reply-To: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 13:53:14 -0000 Le 2013-11-15 04:24, Ole Troan a crit : > if optional, we have to think through the corner cases: > - how does a CPE know when to initiate DHCPv4 (or PCP)? I would propose: when OPTION_S46_IPV4ADDRESS is absent. DHCPv4 or PCP? Whichever one the CPE wants to try, or even both. We don't need to signal this. > - can a CPE end up with an IPv4 address provisioned both with OPTION_S46_IPV4ADDRESS > and DHCPv4 (and PCP)? Proposal: no. When OPTION_S46_IPV4ADDRESS is present, you shall not do DHCPv4. PCP is still OK, since it doesn't technically assign an address to the interface, it merely informs the CPE of an existing stateless mapping (which may be the same as the one provisioned with OPTION_S46_IPV4ADDRESS). > - what does the CPE do with IPv4 addresses with longer lifetimes than the softwire? Shouldn't happen with my proposal above. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Nov 15 05:55:14 2013 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 F15DC11E81A7 for ; Fri, 15 Nov 2013 05:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-zj8rMYk50g for ; Fri, 15 Nov 2013 05:55:14 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE0011E81A5 for ; Fri, 15 Nov 2013 05:55:14 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d95c:254d:9b1e:dcab]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DA66140398; Fri, 15 Nov 2013 08:55:13 -0500 (EST) Message-ID: <528627C1.30805@viagenie.ca> Date: Fri, 15 Nov 2013 08:55:13 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: ian.farrer@telekom.de, softwires@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 13:55:15 -0000 Le 2013-11-15 07:35, ian.farrer@telekom.de a écrit : > If you are implementing OPTION_S46_CONT_LW46, I say you have to implement > all of the sub-options necessary to provision it, including > OPTION_S46_IPV4ADDRESS. > > If you want to use DHCPV4oDHCPv6 or PCP, then you don’t have to implement > OPTION_S46_XX at all. > > Reasoning: > http://www.ietf.org/mail-archive/web/softwires/current/msg05728.html I'm sorry, I don't understand this at all. Can you explain it like I'm a two year old? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From otroan@employees.org Fri Nov 15 05:55:30 2013 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 E664211E81B3 for ; Fri, 15 Nov 2013 05:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91SgdtZ8SNmP for ; Fri, 15 Nov 2013 05:55:25 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id A75EA11E81A5 for ; Fri, 15 Nov 2013 05:55:24 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAEYnhlKQ/khL/2dsb2JhbABZgwc4vytLgSYWdIIlAQEBAwEBAQFrCwULCw44JzAGE4d7Bg3AeASPaQeDIIERA5AwkiaHR4MpOw X-IronPort-AV: E=Sophos;i="4.93,708,1378857600"; d="asc'?scan'208";a="19553179" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 15 Nov 2013 13:55:22 +0000 Received: from dhcp-10-61-109-168.cisco.com (dhcp-10-61-109-168.cisco.com [10.61.109.168]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAFDtI2h003323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Nov 2013 13:55:19 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_B2ED729A-DB01-43B5-95DF-7F277326D9A0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Fri, 15 Nov 2013 14:55:18 +0100 Message-Id: References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> To: Cong Liu X-Mailer: Apple Mail (2.1822) Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 13:55:30 -0000 --Apple-Mail=_B2ED729A-DB01-43B5-95DF-7F277326D9A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Cong, > DHCPv4/PCP enable options will be outside containers, because = containers contains sub-options. I don't think that will work. DHCPv6 server sends two containers MAP_E and LW46. the client must be able to associate the "enable options" to one of = them. I see Simon is suggesting that we don't need those options anyway, = something I concur with. cheers, Ole >=20 > Cong >=20 > 2013/11/15 Ole Troan > Qi, >=20 > >> if optional, we have to think through the corner cases: > >> - how does a CPE know when to initiate DHCPv4 (or PCP)? > > > > [Qi] An enable option (DHCPv6 option) would indicate the CPE to use = DHCPv4 (or PCP), like the DHCPv4oDHCPv6 Enable Option in DHCPv4oDHCPv6. >=20 > let me see if I understand your proposal. > provision the softwire with the LW46 container option. >=20 > the container options then contains one of: > - the IPv4 address option > - enable DHCPv4 option > - or enable PCP option >=20 > ? >=20 > cheers, > Ole >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 --Apple-Mail=_B2ED729A-DB01-43B5-95DF-7F277326D9A0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJShifGAAoJEFuJXizso86g7AEH/0bsftJ5QSAxmvdN9deGaLgP CauDtPJRcXFHL7B8sGAgDc9VY/N6fyGe8yMN7cbOr95L03YtCND+8S4DM8LoBBnT mc6AWNz1gO7BKuwI2qKQInWqcVMQh454FGJkJUN0JdAeHvO34YL+BCet9/oPZzou m1O8ZMuk3dQ8zcM/Pxsc7XFCRN0XQau2+Fx+COYlIgQUorFG59tINixzXqNk/Bvv +ap8ma7VGL8uj5nBQg1IRvAijYFJTstqN9Q/PvfcwIelIg7GRw3m7DEzz46vlcHI xDz02X+bUY0Xj7EaOef91U7Y+/MvKRyr3LREIaNgMRSEraXGQiNavpV8L6uX6T0= =eWc2 -----END PGP SIGNATURE----- --Apple-Mail=_B2ED729A-DB01-43B5-95DF-7F277326D9A0-- From simon.perreault@viagenie.ca Fri Nov 15 06:00:00 2013 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 515C111E8145 for ; Fri, 15 Nov 2013 06:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlZvIg2EBWCq for ; Fri, 15 Nov 2013 05:59:59 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B78FD11E814B for ; Fri, 15 Nov 2013 05:59:59 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d95c:254d:9b1e:dcab]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4BD7940398 for ; Fri, 15 Nov 2013 08:59:59 -0500 (EST) Message-ID: <528628DF.5010900@viagenie.ca> Date: Fri, 15 Nov 2013 08:59:59 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: softwires@ietf.org References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 14:00:00 -0000 Le 2013-11-15 08:55, Ole Troan a crit : > Cong, > >> DHCPv4/PCP enable options will be outside containers, because containers contains sub-options. > > I don't think that will work. > DHCPv6 server sends two containers MAP_E and LW46. > the client must be able to associate the "enable options" to one of them. > I see Simon is suggesting that we don't need those options anyway, something I concur with. Right. I think that the utility of enable options still needs to be demonstrated. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From otroan@employees.org Fri Nov 15 06:01:47 2013 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 263D911E81B7 for ; Fri, 15 Nov 2013 06:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKOqY4LziiWy for ; Fri, 15 Nov 2013 06:01:41 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9D511E81B8 for ; Fri, 15 Nov 2013 06:01:29 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAP8nhlKQ/khR/2dsb2JhbABZgwfALoEmFnSCJQEBBAF5EAtGVwaIDgbAfY9pB4MggREDkDCSJodHgyk7 X-IronPort-AV: E=Sophos;i="4.93,708,1378857600"; d="asc'?scan'208";a="88202746" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 15 Nov 2013 14:01:28 +0000 Received: from dhcp-10-61-109-168.cisco.com (dhcp-10-61-109-168.cisco.com [10.61.109.168]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAFE1NQI022205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Nov 2013 14:01:24 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_2781CB21-DD33-4D9A-8E02-E9337C173853"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <52862748.8000604@viagenie.ca> Date: Fri, 15 Nov 2013 15:01:23 +0100 Message-Id: <25288B61-E9AB-4DF3-9C9B-DA7FCE64921D@employees.org> References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> <52862748.8000604@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1822) Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 14:01:47 -0000 --Apple-Mail=_2781CB21-DD33-4D9A-8E02-E9337C173853 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Simon, >> if optional, we have to think through the corner cases: >> - how does a CPE know when to initiate DHCPv4 (or PCP)? >=20 > I would propose: when OPTION_S46_IPV4ADDRESS is absent. >=20 > DHCPv4 or PCP? Whichever one the CPE wants to try, or even both. We = don't need to signal this. >=20 >> - can a CPE end up with an IPv4 address provisioned both with = OPTION_S46_IPV4ADDRESS >> and DHCPv4 (and PCP)? >=20 > Proposal: no. When OPTION_S46_IPV4ADDRESS is present, you shall not do = DHCPv4. PCP is still OK, since it doesn't technically assign an address = to the interface, it merely informs the CPE of an existing stateless = mapping (which may be the same as the one provisioned with = OPTION_S46_IPV4ADDRESS). >=20 >> - what does the CPE do with IPv4 addresses with longer lifetimes = than the softwire? >=20 > Shouldn't happen with my proposal above. yes, I think this makes a lot of sense. paraphrasing: - one of the containers are _always_ used to provision the softwire - the absence of IPv4 address option in the LW46 container triggers = DHCPv4 - we can ignore PCP for now if the client requires other configuration information it can do DHCPv4 = as it wish. the only change required is to make the IPv4 address option in MAP-DHCP = optional. (assuming there isn't consensus to drop it altogether.) cheers, Ole --Apple-Mail=_2781CB21-DD33-4D9A-8E02-E9337C173853 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJShikzAAoJEFuJXizso86gkscIAMLYrqHLg4KwLu9macJsEwAl EjrBAFjGgmNboUEhsiG+KR7OQEh2+J38pl+c+Wy//NSMJe1IbHjxQprS88wp8HwV CnsThRg3uoqHI/i/TOQ5z0UcJFEv+Jm3MI0JItk9oo/kH9vFyS3sTkErjfFUii/y cpokllAGacqqbIh+WzuqW7XED0DRaKHfPLYkuM3YWWToG3MXILmoof3LSxuIHcZc EeDcRNr3IgdU75pbtWaBOmRqPEw5NCCmuZK161NkzMCzmB2juyxDJcJM3tv0ZqcO w8axE/oRQnxFBEuqaf+RZS/P4cmqIvdw6n/J0fS58NMq2bVzswMk476++luGTfU= =WdVN -----END PGP SIGNATURE----- --Apple-Mail=_2781CB21-DD33-4D9A-8E02-E9337C173853-- From simon.perreault@viagenie.ca Fri Nov 15 06:04:14 2013 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 654A311E81B8 for ; Fri, 15 Nov 2013 06:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPtWGmZw3-di for ; Fri, 15 Nov 2013 06:04:13 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B40FD11E81A4 for ; Fri, 15 Nov 2013 06:04:06 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d95c:254d:9b1e:dcab]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4383040398; Fri, 15 Nov 2013 09:04:06 -0500 (EST) Message-ID: <528629D5.3000809@viagenie.ca> Date: Fri, 15 Nov 2013 09:04:05 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ted Lemon References: <5285320C.7030702@viagenie.ca> <57966783-D308-48B8-8C64-33465312437C@nominum.com> <52853765.6050700@viagenie.ca> <636C5CB8-1168-40FA-AA24-5827D55AA1DB@nominum.com> In-Reply-To: <636C5CB8-1168-40FA-AA24-5827D55AA1DB@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 14:04:14 -0000 Le 2013-11-14 22:53, Ted Lemon a crit : >> Removing unneeded cruft is probably good too. I mean, if nobody is going to use it... > > How sure are you that nobody is going to use it? Serious question. IMHO, if nobody comes to the WG with a need for it, then we should remove it. If anyone comes up with a need for it in the future, it can be defined in an extension RFC. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From gnocuil@gmail.com Fri Nov 15 06:06:04 2013 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 AF76D11E81A9 for ; Fri, 15 Nov 2013 06:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aa2Xgukvsi3f for ; Fri, 15 Nov 2013 06:06:04 -0800 (PST) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C838011E81A4 for ; Fri, 15 Nov 2013 06:06:03 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id x12so2100929qcv.34 for ; Fri, 15 Nov 2013 06:06:03 -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=4cZtNmj+uoikFOVXYUBap26zuNChn3CGJsJ9Gj2CgbY=; b=sPI7MSyuZ8TRTMdoCDMGR0PTWX7KZOP0zkCK5PTHiluAkPaGnDCYNo6NG4lMNWVr9q o+E9SaO2mCYXUX4DJU/gDYBDqGrGqcwsC/8g72xnrp/PmY4sULWzYUcvYyROroqUqDF/ 1rJ9nGueahvjaF89PgpWN7NsrmUJfimTpbDwvKsel2bJknHH85Ch0mRvPM0hRb9suS2B C29UIlbvlu/9wQ2NCTmQF4bxDu9SnlHGn3ugkbrC2jQ2xo5urIXemlPOpyYcDZbwQ92S jZcwflQKaepmkbPY4QDX6deyA49OhoNepEUgr6Q2PAC0dHekvLcyrD7TIF4Usk4qCfN9 rhGA== X-Received: by 10.224.124.134 with SMTP id u6mr10739215qar.79.1384524363236; Fri, 15 Nov 2013 06:06:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.185.33 with HTTP; Fri, 15 Nov 2013 06:05:43 -0800 (PST) In-Reply-To: References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> From: Cong Liu Date: Fri, 15 Nov 2013 22:05:43 +0800 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=001a11c29e9cda8c8104eb37b200 Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 14:06:04 -0000 --001a11c29e9cda8c8104eb37b200 Content-Type: text/plain; charset=ISO-8859-1 Hi Ole, It's another problem that confused me: do containers contain options or sub-options. In map-dhcp-05. Section 4 says they are suboptions, but section 10 requires DHCPv6 option codes. Best Regards, Cong 2013/11/15 Ole Troan > Cong, > > > DHCPv4/PCP enable options will be outside containers, because containers > contains sub-options. > > I don't think that will work. > DHCPv6 server sends two containers MAP_E and LW46. > the client must be able to associate the "enable options" to one of them. > I see Simon is suggesting that we don't need those options anyway, > something I concur with. > > cheers, > Ole > > > > > > Cong > > > > 2013/11/15 Ole Troan > > Qi, > > > > >> if optional, we have to think through the corner cases: > > >> - how does a CPE know when to initiate DHCPv4 (or PCP)? > > > > > > [Qi] An enable option (DHCPv6 option) would indicate the CPE to use > DHCPv4 (or PCP), like the DHCPv4oDHCPv6 Enable Option in DHCPv4oDHCPv6. > > > > let me see if I understand your proposal. > > provision the softwire with the LW46 container option. > > > > the container options then contains one of: > > - the IPv4 address option > > - enable DHCPv4 option > > - or enable PCP option > > > > ? > > > > cheers, > > Ole > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > > > > > --001a11c29e9cda8c8104eb37b200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ole,

It's another problem that c= onfused me: do containers contain options or sub-options.
In map-= dhcp-05. Section 4 says they are suboptions, but section 10 requires DHCPv6= option codes.

Best Regards,
Cong


2013/11= /15 Ole Troan <otroan@employees.org>
Cong,

> DHCPv4/PCP enable options will be outside containers, because containe= rs contains sub-options.

I don't think that will work.
DHCPv6 server sends two containers MAP_E and LW46.
the client must be able to associate the "enable options" to one = of them.
I see Simon is suggesting that we don't need those options anyway, some= thing I concur with.

cheers,
Ole


>
> Cong
>
> 2013/11/15 Ole Troan <otroa= n@employees.org>
> Qi,
>
> >> if optional, we have to think through the corner cases:
> >> - how does a CPE know when to initiate DHCPv4 (or PCP)?
> >
> > [Qi] An enable option (DHCPv6 option) would indicate the CPE to u= se DHCPv4 (or PCP), like the DHCPv4oDHCPv6 Enable Option in DHCPv4oDHCPv6.<= br> >
> let me see if I understand your proposal.
> provision the softwire with the LW46 container option.
>
> the container options then contains one of:
> =A0- the IPv4 address option
> =A0- enable DHCPv4 option
> =A0- or enable PCP option
>
> ?
>
> cheers,
> Ole
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
>
>


--001a11c29e9cda8c8104eb37b200-- From simon.perreault@viagenie.ca Fri Nov 15 06:09:59 2013 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 136E911E81B7 for ; Fri, 15 Nov 2013 06:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVCSLV1zX1cj for ; Fri, 15 Nov 2013 06:09:58 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4B11E81A4 for ; Fri, 15 Nov 2013 06:09:58 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d95c:254d:9b1e:dcab]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 84B3240398; Fri, 15 Nov 2013 09:09:57 -0500 (EST) Message-ID: <52862B35.7040000@viagenie.ca> Date: Fri, 15 Nov 2013 09:09:57 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ole Troan References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> <52862748.8000604@viagenie.ca> <25288B61-E9AB-4DF3-9C9B-DA7FCE64921D@employees.org> In-Reply-To: <25288B61-E9AB-4DF3-9C9B-DA7FCE64921D@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 14:09:59 -0000 Le 2013-11-15 09:01, Ole Troan a crit : >>> if optional, we have to think through the corner cases: >>> - how does a CPE know when to initiate DHCPv4 (or PCP)? >> >> I would propose: when OPTION_S46_IPV4ADDRESS is absent. >> >> DHCPv4 or PCP? Whichever one the CPE wants to try, or even both. We don't need to signal this. >> >>> - can a CPE end up with an IPv4 address provisioned both with OPTION_S46_IPV4ADDRESS >>> and DHCPv4 (and PCP)? >> >> Proposal: no. When OPTION_S46_IPV4ADDRESS is present, you shall not do DHCPv4. PCP is still OK, since it doesn't technically assign an address to the interface, it merely informs the CPE of an existing stateless mapping (which may be the same as the one provisioned with OPTION_S46_IPV4ADDRESS). >> >>> - what does the CPE do with IPv4 addresses with longer lifetimes than the softwire? >> >> Shouldn't happen with my proposal above. > > yes, I think this makes a lot of sense. > paraphrasing: > > - one of the containers are _always_ used to provision the softwire > - the absence of IPv4 address option in the LW46 container triggers DHCPv4 > - we can ignore PCP for now Nah, PCP is too easy to ignore. :) PCP can always be tried on any interface. Doesn't matter if this is LW4o6 or whatever else. PCP is PCP, just try it and see if you get anything back. > if the client requires other configuration information it can do DHCPv4 as it wish. Right. If I was implementing a CPE I would unconditionally do DHCPv4oDHCPv6. If I have to implement the code anyway, why not always exercise it? Thus my question: do we really need OPTION_S46_IPV4ADDRESS? If CPEs do DHCPv4oDHCPv6 all the time anyway, we don't really need it. > the only change required is to make the IPv4 address option in MAP-DHCP optional. > (assuming there isn't consensus to drop it altogether.) Yup. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From otroan@employees.org Fri Nov 15 06:13:52 2013 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 A987211E81C0 for ; Fri, 15 Nov 2013 06:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEwssEYX5UKl for ; Fri, 15 Nov 2013 06:13:46 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2F01911E81BF for ; Fri, 15 Nov 2013 06:13:34 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAHcrhlKQ/khN/2dsb2JhbABZgwfALoEnFnSCJQEBBAF5BQsLDjhXBogOBsEBj2kHgyCBEQOQMJImh0eDKTs X-IronPort-AV: E=Sophos;i="4.93,708,1378857600"; d="asc'?scan'208";a="88203162" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 15 Nov 2013 14:13:33 +0000 Received: from dhcp-10-61-109-168.cisco.com (dhcp-10-61-109-168.cisco.com [10.61.109.168]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAFEDTwS000385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Nov 2013 14:13:29 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_A9C78E58-33D1-487B-8E95-0CD4B74BB9D6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Fri, 15 Nov 2013 15:13:28 +0100 Message-Id: <5F9BD539-2BD6-4ED9-BB70-9C5B324B19AE@employees.org> References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> To: Cong Liu X-Mailer: Apple Mail (2.1822) Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 14:13:52 -0000 --Apple-Mail=_A9C78E58-33D1-487B-8E95-0CD4B74BB9D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Cong, > It's another problem that confused me: do containers contain options = or sub-options. > In map-dhcp-05. Section 4 says they are suboptions, but section 10 = requires DHCPv6 option codes. sub-options do come out of the DHCPv6 option name space. and could be used as first level options in other contexts for that = matter. cheers, Ole --Apple-Mail=_A9C78E58-33D1-487B-8E95-0CD4B74BB9D6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJShiwIAAoJEFuJXizso86gU94H/i8G+knw0sUlmORTJAsTL7No aEx6ywsrK1x6U15vWKKHQJS7wlymQbv0z+GRdhyKlXZgrrMpHBtwe80LfKeHnhTK OWmUmm5sLidRnSqwH5AJBLypfmQe4rm8lbg2O54/dG0eZA5bZM8oPEP7/sl4bVaf XZQlXg6hsEBUb/TeEyY/U7MBb5VtJmPYBq5kquu3MiHUS5ZASv1paOQJn8qLoP+v jOX6J5wH58pe8HzSV0GzeQSnss9HjsIdGLMZetuqNmbmPcM/cVo7PwjYFep5mQdT cVbWFreAwQlWzlvBmBobWF4Ox+EVuKVpZFAe8jeMDeXuOZOeNyWKDGVTyWO37wQ= =Fyo8 -----END PGP SIGNATURE----- --Apple-Mail=_A9C78E58-33D1-487B-8E95-0CD4B74BB9D6-- From sunqi.csnet.thu@gmail.com Fri Nov 15 09:17:49 2013 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 E479E11E81B2 for ; Fri, 15 Nov 2013 09:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HThsmGO+lgFS for ; Fri, 15 Nov 2013 09:17:47 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 961FF11E81A4 for ; Fri, 15 Nov 2013 09:17:31 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id q10so3741057pdj.15 for ; Fri, 15 Nov 2013 09:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=joYDLpecP0zzBWLg+wxGosB4Aq+S8TmIEGtmtyS7RV4=; b=XSUH326qB4g6BDkUeRcHh74kcU7uuZLbxM92AvtpSLDexifWFwFODLF8BqcXvKaKlp Ii2x9+mLtCFz6lquOLup+9EDixKiLE2clv5sdTXeUBovwDYRVsP+MqkiKXhhjJYLhGwb BTguV1YWhgkzfzx8dHT9WMy1OPdy7ARyUvoo0tvawy+cnxkDiRulOoFfDaPn6F+Adky0 csBWMIzrXWXuPQVrlIIudmblGd5wj2Ggux3NK2+pbzWcKlOkih43hVzCxOPK6kQfOkJC ROWU2xGpc0DUyrH+72qfoZL9CUc86QUPzt7X75+ogmvGTYta9sBkxPMOiQ80OPkmp9kf wP4Q== X-Received: by 10.68.171.5 with SMTP id aq5mr7647028pbc.21.1384535836429; Fri, 15 Nov 2013 09:17:16 -0800 (PST) Received: from [10.5.28.22] ([219.141.159.37]) by mx.google.com with ESMTPSA id nj9sm5727386pbc.13.2013.11.15.09.17.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 09:17:15 -0800 (PST) References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> <52862748.8000604@viagenie.ca> <25288B61-E9AB-4DF3-9C9B-DA7FCE64921D@employees.org> Mime-Version: 1.0 (1.0) In-Reply-To: <25288B61-E9AB-4DF3-9C9B-DA7FCE64921D@employees.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3376EC50-295D-4B76-BA34-EB334E5ECB55@gmail.com> X-Mailer: iPhone Mail (10A551) From: Qi Sun Date: Sat, 16 Nov 2013 01:17:05 +0800 To: Ole Troan Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 17:17:49 -0000 Ole, On 2013-11-15, at 22:01, Ole Troan wrote: > Simon, >=20 >>> if optional, we have to think through the corner cases: >>> - how does a CPE know when to initiate DHCPv4 (or PCP)? >>=20 >> I would propose: when OPTION_S46_IPV4ADDRESS is absent. >>=20 >> DHCPv4 or PCP? Whichever one the CPE wants to try, or even both. We don't= need to signal this. >>=20 >>> - can a CPE end up with an IPv4 address provisioned both with OPTION_S46= _IPV4ADDRESS >>> and DHCPv4 (and PCP)? >>=20 >> Proposal: no. When OPTION_S46_IPV4ADDRESS is present, you shall not do DH= CPv4. PCP is still OK, since it doesn't technically assign an address to the= interface, it merely informs the CPE of an existing stateless mapping (whic= h may be the same as the one provisioned with OPTION_S46_IPV4ADDRESS). >>=20 >>> - what does the CPE do with IPv4 addresses with longer lifetimes than th= e softwire? >>=20 >> Shouldn't happen with my proposal above. >=20 > yes, I think this makes a lot of sense. > paraphrasing: >=20 > - one of the containers are _always_ used to provision the softwire [Qi] When you say "provisioning the softwire", do you mean convey the v6 add= ress of BR/lwAFTR to the clien? > - the absence of IPv4 address option in the LW46 container triggers DHCPv4= [Qi] There have been a Enable option for DHCPv4oDHCPv6, I think we can lever= age it. Best Regards, Qi > - we can ignore PCP for now >=20 > if the client requires other configuration information it can do DHCPv4 as= it wish. >=20 > the only change required is to make the IPv4 address option in MAP-DHCP op= tional. > (assuming there isn't consensus to drop it altogether.) >=20 > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From Ted.Lemon@nominum.com Fri Nov 15 10:55:46 2013 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 C800611E81BD for ; Fri, 15 Nov 2013 10:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.733 X-Spam-Level: X-Spam-Status: No, score=-105.733 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXVEgwAhMpOd for ; Fri, 15 Nov 2013 10:55:37 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF6E11E81AF for ; Fri, 15 Nov 2013 10:55:27 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUoZuHQecaEPjsuaV1Gc1oXNGhbgmtoYj@postini.com; Fri, 15 Nov 2013 10:55:27 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 97D741B8244 for ; Fri, 15 Nov 2013 10:55:24 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 91966190043; Fri, 15 Nov 2013 10:55:24 -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.03.0158.001; Fri, 15 Nov 2013 10:55:18 -0800 From: Ted Lemon To: Simon Perreault Thread-Topic: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS Thread-Index: AQHO4XfkxtkjsKyJgEmxLctVX9g+UZombkiAgAAd4YCAAD80AIAABwMAgAAD7YCAAAGBAIAAAU+AgABSgQA= Date: Fri, 15 Nov 2013 18:55:17 +0000 Message-ID: References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> <528628DF.5010900@viagenie.ca> In-Reply-To: <528628DF.5010900@viagenie.ca> 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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 18:55:47 -0000 On Nov 15, 2013, at 8:59 AM, Simon Perreault = wrote: > Right. I think that the utility of enable options still needs to be demon= strated. Bear in mind that DHCPv4overDHCPv6 is intended to be a broad solution, not = a softwires-only solution. So it makes some sense to have an enable optio= n for it, which should be independent of the softwires DHCP options. As for PCP, how do you feel about DHCPv4 clients blabbing forever on IPv6-o= nly links? Now, how about PCP clients on non-PCP links? No problem? W= hy is PCP different? From simon.perreault@viagenie.ca Fri Nov 15 11:06:28 2013 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 032D321F9CE9 for ; Fri, 15 Nov 2013 11:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE0io4qwUdz7 for ; Fri, 15 Nov 2013 11:06:27 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB5021F9C69 for ; Fri, 15 Nov 2013 11:06:27 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C4721403CB; Fri, 15 Nov 2013 14:06:23 -0500 (EST) Message-ID: <528670AF.20400@viagenie.ca> Date: Fri, 15 Nov 2013 14:06:23 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ted Lemon References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> <528628DF.5010900@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 19:06:28 -0000 Le 2013-11-15 13:55, Ted Lemon a crit : > On Nov 15, 2013, at 8:59 AM, Simon Perreault wrote: >> Right. I think that the utility of enable options still needs to be demonstrated. > > Bear in mind that DHCPv4overDHCPv6 is intended to be a broad solution, not a softwires-only solution. So it makes some sense to have an enable option for it, which should be independent of the softwires DHCP options. Right, I had forgotten about that. You're right. > As for PCP, how do you feel about DHCPv4 clients blabbing forever on IPv6-only links? Now, how about PCP clients on non-PCP links? No problem? Why is PCP different? Good question, but it needs to be scoped to "PCP requests for IPv4 external ports". PCP requests for IPv6 external ports still make sense in an IPv6-only world. You're right, it seems to me that we have the same problem with PCP requests for IPv4 external ports as we have with DHCPv4. *gasp* I will for sure be thinking about this, and how it impacts sunset4. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Fri Nov 15 11:26:31 2013 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 F1E2011E814F for ; Fri, 15 Nov 2013 11:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.363 X-Spam-Level: X-Spam-Status: No, score=-106.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxEzPl7HeSUt for ; Fri, 15 Nov 2013 11:26:24 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id DDA6911E8132 for ; Fri, 15 Nov 2013 11:25:52 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKUoZ1QGh8x+E/T/dlwqrqPFGydPUr9+rp@postini.com; Fri, 15 Nov 2013 11:25:52 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 2531D1B82E1 for ; Fri, 15 Nov 2013 11:25:52 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 1CBE0190043; Fri, 15 Nov 2013 11:25:52 -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.03.0158.001; Fri, 15 Nov 2013 11:25:45 -0800 From: Ted Lemon To: Simon Perreault Thread-Topic: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS Thread-Index: AQHO4XfkxtkjsKyJgEmxLctVX9g+UZombkiAgAAd4YCAAD80AIAABwMAgAAD7YCAAAGBAIAAAU+AgABSgQCAAAMbgIAABWUA Date: Fri, 15 Nov 2013 19:25:44 +0000 Message-ID: <87748E4B-5EE7-4D83-B5D5-EB6C55D1F33B@nominum.com> References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> <528628DF.5010900@viagenie.ca> <528670AF.20400@viagenie.ca> In-Reply-To: <528670AF.20400@viagenie.ca> 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="iso-8859-1" Content-ID: <2F2F099FC47AAC45A225DBE53879F5BC@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 19:26:31 -0000 On Nov 15, 2013, at 2:06 PM, Simon Perreault = wrote: > Good question, but it needs to be scoped to "PCP requests for IPv4 extern= al ports". PCP requests for IPv6 external ports still make sense in an IPv6= -only world. Yes, I think the PCP option actually needs to be a softwires-specific optio= n, and its semantics need to be carefully thought out. > You're right, it seems to me that we have the same problem with PCP reque= sts for IPv4 external ports as we have with DHCPv4. *gasp* I will for sure = be thinking about this, and how it impacts sunset4. Yup. From ot@cisco.com Fri Nov 15 14:16:24 2013 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 0CECD11E8117 for ; Fri, 15 Nov 2013 14:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkFXV+5uVcvC for ; Fri, 15 Nov 2013 14:16:23 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id A847F11E8105 for ; Fri, 15 Nov 2013 14:16:23 -0800 (PST) Received: from dhcp-10-61-98-161.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 793B15FBA; Fri, 15 Nov 2013 14:16:20 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_1A056AC0-2C75-4C58-B456-B8E4DD3E0E27"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Fri, 15 Nov 2013 23:16:18 +0100 Message-Id: <7B03A1AA-1D40-4587-8720-6EFFDFB1E3D7@cisco.com> References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> <528628DF.5010900@viagenie.ca> To: Ted Lemon X-Mailer: Apple Mail (2.1822) Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 15 Nov 2013 22:16:24 -0000 --Apple-Mail=_1A056AC0-2C75-4C58-B456-B8E4DD3E0E27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Right. I think that the utility of enable options still needs to be = demonstrated. >=20 > Bear in mind that DHCPv4overDHCPv6 is intended to be a broad solution, = not a softwires-only solution. So it makes some sense to have an = enable option for it, which should be independent of the softwires DHCP = options. firstly it would still have to be inside the container. secondly as Simon pointed out it isn't needed, as the absence of the = IPv4 address should suffice. thirdly we shouldn't be making broad solutions for IPv4. is there any use case of this outside of softwires? cheers, Ole --Apple-Mail=_1A056AC0-2C75-4C58-B456-B8E4DD3E0E27 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJShp0yAAoJEP0up8EdT99JavkH/3X3GLm4id1gJPKS96zlTst7 niZ1JJSESK4pe094TKuA54CTIsnNNdLScB+WMwXLnFmKcTqJUf+Rj2Tg4nNEZuOv stWW1Vs14zb7Qan66Pl4BgutoZT3PKRp0UKWwd1Lf26SuiXQSwSnmEs2IdXRsNvU Cm4iT2rUpzClH3crCv1CmvwEHUCtdJyU+oa21jEGwG+7PkXvVXiCibN4RNxXbl2t Dk06u0VkXEVaZCU9vV/97odOmm//i/4xvBIhonQfT/+cd7klGBWMngYvqvbBPouo 9HX91W45pm4Bmu1FqubJNNuAc0xjQyJm1/xRwnpJT9MNuxYC4MR2Na4VRyjnrj4= =7JMt -----END PGP SIGNATURE----- --Apple-Mail=_1A056AC0-2C75-4C58-B456-B8E4DD3E0E27-- From Ted.Lemon@nominum.com Fri Nov 15 22:09:49 2013 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 C16A911E8125 for ; Fri, 15 Nov 2013 22:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yr-lu9TtvndC for ; Fri, 15 Nov 2013 22:09:43 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 3B77111E8104 for ; Fri, 15 Nov 2013 22:09:40 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUocMI/Tpyssp200452C1e+EDn7Nu79Zk@postini.com; Fri, 15 Nov 2013 22:09:40 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 BA8CC1B826F for ; Fri, 15 Nov 2013 22:09:39 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-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 8E03B190043; Fri, 15 Nov 2013 22:09:39 -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.03.0158.001; Fri, 15 Nov 2013 22:09:39 -0800 From: Ted Lemon To: Ole Troan Thread-Topic: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS Thread-Index: AQHO4XfkxtkjsKyJgEmxLctVX9g+UZombkiAgAAd4YCAAD80AIAABwMAgAAD7YCAAAGBAIAAAU+AgABSgQCAADgrAIAAhD8A Date: Sat, 16 Nov 2013 06:09:38 +0000 Message-ID: <3E9CD6EB-0F3A-4017-B939-60B1B9773BAE@nominum.com> References: <6BBC4E77-FD99-4C87-8D9A-22B4EFC898D3@employees.org> <528628DF.5010900@viagenie.ca> <7B03A1AA-1D40-4587-8720-6EFFDFB1E3D7@cisco.com> In-Reply-To: <7B03A1AA-1D40-4587-8720-6EFFDFB1E3D7@cisco.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="us-ascii" Content-ID: <5D9306BB11628647B9C940F41E129465@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] On the topic of OPTION_S46_IPV4ADDRESS 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, 16 Nov 2013 06:09:49 -0000 On Nov 15, 2013, at 5:16 PM, Ole Troan wrote: > firstly it would still have to be inside the container. > secondly as Simon pointed out it isn't needed, as the absence of the IPv4= address should suffice. >=20 > thirdly we shouldn't be making broad solutions for IPv4. > is there any use case of this outside of softwires? This discussion is not in scope for the softwires working group. If you w= ant to have this discussion, please raise the issue on the dhcwg mailing li= st. From internet-drafts@ietf.org Tue Nov 19 04:08:04 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270D71ADF61; Tue, 19 Nov 2013 04:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_74=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SErPnBLNxrT; Tue, 19 Nov 2013 04:08:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EABE81ADF5D; Tue, 19 Nov 2013 04:08: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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131119120802.12864.97991.idtracker@ietfa.amsl.com> Date: Tue, 19 Nov 2013 04:08:02 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-dhcp-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 12:08: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 : DHCPv6 Options for configuration of Softwire Address and= Port Mapped Clients Author(s) : Tomasz Mrugalski Ole Troan Wojciech Dec Congxiao Bao Leaf Y. Yeh Xiaohong Deng Filename : draft-ietf-softwire-map-dhcp-06.txt Pages : 16 Date : 2013-11-19 Abstract: This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address+Port (A+P) for providing IPv4 connectivity across an IPv6 network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-dhcp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-dhcp-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Wed Nov 20 11:54:29 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909291ADFF0 for ; Wed, 20 Nov 2013 11:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwKWrE29n1na for ; Wed, 20 Nov 2013 11:54:27 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CAF671AE071 for ; Wed, 20 Nov 2013 11:54:27 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E248E401FE for ; Wed, 20 Nov 2013 14:54:20 -0500 (EST) Message-ID: <528D136C.60803@viagenie.ca> Date: Wed, 20 Nov 2013 14:54:20 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "softwires@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] MAP compatibility with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 19:54:29 -0000 WG, draft-ietf-softwire-map-08 contains this: 7.3. Backwards compatibility A MAP-E CE provisioned with only the IPv6 address of the BR, and with no IPv4 address and port range configured by other means, MUST disable its NAT44 functionality. This characteristic makes a MAP CE compatible with DS-Lite [RFC6333] AFTRs, whose addresses are configured as the MAP BR. In view of the recent discussions on provisioning, this functionality strikes me as useless. There would be no reason for an ISP to use such provisioning. A unified CPE would just do DS-Lite if that's what's available. I suggest to remove that section. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ot@cisco.com Wed Nov 20 13:32:42 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547571AE547 for ; Wed, 20 Nov 2013 13:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljEiMtVpNCKY for ; Wed, 20 Nov 2013 13:32:40 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 553881AE181 for ; Wed, 20 Nov 2013 13:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1727; q=dns/txt; s=iport; t=1384983154; x=1386192754; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=w5uhaJARXh55Yidl7lOmqRrViM2k4jqxTbsaLSoZGN8=; b=kzlgp/yqga22y81BTQ1zl0HQEj5yGiQus9hunBpLqq9PkSEcHzz0GWwv +wYk4NogkZDimIrupxvsyj6aUWdYKwut1dWe9mO5nCdA5P2Bzl9T45l3a 7x7Hkpe/0PeF8T0TYbRPG8VplN7dZ7jB4P2VGCq/SPZpGsuzCxl0F7UVP k=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFACEqjVKQ/khM/2dsb2JhbABZgwe/BYEaFnSCJQEBAQMBeQULC0ZXBogOBsB9F49rB4MggRIDkDCHYpINgyk7 X-IronPort-AV: E=Sophos;i="4.93,739,1378857600"; d="asc'?scan'208";a="301291" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 20 Nov 2013 21:32:33 +0000 Received: from dhcp-10-61-108-226.cisco.com (dhcp-10-61-108-226.cisco.com [10.61.108.226]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAKLWPqF029261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Nov 2013 21:32:27 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_E3A63F79-C733-4C36-AB44-2E519528C17A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: <528D136C.60803@viagenie.ca> Date: Wed, 20 Nov 2013 22:32:23 +0100 Message-Id: <4005A5DD-2904-46AA-A295-971AFD1509B9@cisco.com> References: <528D136C.60803@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1822) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP compatibility with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 21:32:42 -0000 --Apple-Mail=_E3A63F79-C733-4C36-AB44-2E519528C17A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Simon, > draft-ietf-softwire-map-08 contains this: >=20 > 7.3. Backwards compatibility >=20 > A MAP-E CE provisioned with only the IPv6 address of the BR, and = with > no IPv4 address and port range configured by other means, MUST > disable its NAT44 functionality. This characteristic makes a MAP CE > compatible with DS-Lite [RFC6333] AFTRs, whose addresses are > configured as the MAP BR. >=20 > In view of the recent discussions on provisioning, this functionality = strikes me as useless. There would be no reason for an ISP to use such = provisioning. A unified CPE would just do DS-Lite if that's what's = available. >=20 > I suggest to remove that section. I tend to agree with that. cheers, Ole --Apple-Mail=_E3A63F79-C733-4C36-AB44-2E519528C17A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSjSpoAAoJEP0up8EdT99J84UH/jfApGSRVs6H6O9ZCAzuYhFs R8Au+HXOaGdXvGFkEBnEsVq4Gy7n98MJcvu7O1gXdkVlAmvA7evmS8qI2gJz0BR8 rNymUoHTn8hldAaWMrRdZvi9pjVSD+EViWK6pGqX0Z+q9f1s58RolihcpbDCWanT +/lIEFqgUGrbdldYlYprzKSEPX10Q80MahlUgREQ/ho1tbqPxFtGFvPE1qwJPFTd 83DVKp+evstXrp3OJNPec7Kib7KIWTXDgXmf4hnwhZ2pmmO4tgicDfe1qglzsVih 8+IsJyBQ+DlgnzkHKRFCVNX+LshMo25EL43LrsACuyRcbX+XWMTLFEgJZy75R2s= =RQsC -----END PGP SIGNATURE----- --Apple-Mail=_E3A63F79-C733-4C36-AB44-2E519528C17A-- From suresh.krishnan@ericsson.com Wed Nov 20 21:06:07 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA80F1AE099 for ; Wed, 20 Nov 2013 21:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDN-Zk23jY4i for ; Wed, 20 Nov 2013 21:06:06 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0A13E1AE095 for ; Wed, 20 Nov 2013 21:06:05 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-06-528d94b45dfc Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 88.DF.23183.4B49D825; Thu, 21 Nov 2013 06:05:56 +0100 (CET) Received: from [164.48.125.52] (147.117.188.134) by smtps-am.internal.ericsson.com (147.117.188.81) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 21 Nov 2013 00:05:56 -0500 Message-ID: <528D94AD.7000104@ericsson.com> Date: Thu, 21 Nov 2013 00:05:49 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Softwires WG X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.134] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42KZXLonUHfLlN4gg68XVCx+bEm2OLxsK5PF 1u5YB2aPJUt+Mnm8PjCf1eP457fMAcxRXDYpqTmZZalF+nYJXBlLf55kLPjAWnHg+x3GBsaP LF2MnBwSAiYSH75PZ4WwxSQu3FvP1sXIxSEkcIRR4v+HPawQznZGibbzZ5lBqngFtCUWz9kP lODgYBFQlfjysQokzAY0aMPOz0wgtqhAiMTCVcfZIcoFJU7OfAK2TASo/MnOB2wgNrOAp8SK Dd8YQcYIC9hLPDgfBWJKCIhL9DQGQVToSUy52sIIYctLbH87B+wAIQFNia1rvkOdrCzx790K lgmMgrOQLJuFpH0WkvYFjMyrGDlKi1PLctONDDYxAgP0mASb7g7GPS8tDzFKc7AoifN+eesc JCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRLTHsfZa/pscLvj75mxGfb3w88lXod7HmhA9+ pT9M977Ze+5Nzdzq7MMvdnHd6nddtGdr6o0FV1dc+B6/MtGppehyptaf/ttznml/Z+qrqrPn X9z5/+hc51i+q091/jRufXrhNoN8UVnH5EcHeef8KGn88tb/olbfznd+/2YtDxQMWsp7sMfR SImlOCPRUIu5qDgRAOj+EugeAgAA Cc: Yong Cui Subject: [Softwires] Working group last call for draft-ietf-softwire-map-08 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 05:06:07 -0000 Hi all, This message starts a one week (second) softwire working group last call on advancing the draft about providing Mapping of Address and Port with Encapsulation as a Standards Track RFC. The authors believe that this version has addressed all the issues raised on the document during the first WGLC on -05. The latest version of the draft is available at http://www.ietf.org/id/draft-ietf-softwire-map-08.txt http://tools.ietf.org/html/draft-ietf-softwire-map-08 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. This last call will conclude on November 28, 2013. Regards, Suresh & Yong From tom.taylor.stds@gmail.com Thu Nov 21 17:54:15 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE5E1AD6A4 for ; Thu, 21 Nov 2013 17:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJq7qwWug2g9 for ; Thu, 21 Nov 2013 17:54:14 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 019EC1AC7F1 for ; Thu, 21 Nov 2013 17:54:13 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id tp5so1043835ieb.25 for ; Thu, 21 Nov 2013 17:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=oUh6S/8CJ91JOqDlwdkpfO9IIQP5AR9QfN6awAinPDI=; b=sG7SCfG2tDS0VU/SnM9eGjtxzBdilX96D8nHx6BDnmS5GqrSc3wsvLK1wexGTunXT6 P2tonDi2zJVBVmwaKZyQ0YhotiHKKsYlT4wSfyI5MMWM7ExNlA1GHGSB7hrp065p7rHS UUCGTdobRx5mxPLrmjuJh2ikvb7cNG7E0j1r1f+cYFgsXvHvDPBDuQIoQrVcZK5n+dFc LeHOSz8Vse2LLADDcEOReByGlBXsukeBQYPxExJZvqp168EFwyTDA81SpSuHDtHmNXbn W6rh50piSl0bkA33efpUuGW9b46n/dZ8tcVollnUa5dC8c/lLPW+Y2joBmxLQ9HKXR/J rKUg== X-Received: by 10.42.215.80 with SMTP id hd16mr6228365icb.17.1385085247092; Thu, 21 Nov 2013 17:54:07 -0800 (PST) Received: from [192.168.1.69] ([64.56.250.4]) by mx.google.com with ESMTPSA id x6sm6116648igb.3.2013.11.21.17.54.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 17:54:06 -0800 (PST) Message-ID: <528EB93A.5040700@gmail.com> Date: Thu, 21 Nov 2013 20:54:02 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] Unclear text re port parameters in draft-ietf-softwire-map-dhcp-06 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 01:54:16 -0000 The text describing client validation of OPTION_S46_PORTPARAMS in the second-last paragraph of Section 4.5 currently reads as follows: When receiving the Port Parameters option with an explicit PSID, the client MUST use this explicit PSID in configuring its MAP interface. If the conveyed IPv4 address is not 32 bit-long. The formula for this check is "prefix4-len + ea-len = 32" and serves to ensure that the explicit PSID is only applied to configurations with a completely formed IPv4 address. I don't think the sentence fragment "If the conveyed IPv4 address ..." should be there. In the subsequent sentence, I believe the check must be: "prefix4-len + ea-len > 32" Otherwise no port values are conveyed by the option. See Section 5.2 of the MAP document, particularly Figure 6 and associated text. I would also add "shared and" before "completely formed" at the end of the paragraph. Tom Taylor From tom.taylor.stds@gmail.com Thu Nov 21 18:00:29 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD111AE255 for ; Thu, 21 Nov 2013 18:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84OE6PCRSUvL for ; Thu, 21 Nov 2013 18:00:28 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 17F8C1AD986 for ; Thu, 21 Nov 2013 18:00:27 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id x13so1074331ief.20 for ; Thu, 21 Nov 2013 18:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XrIn1ufNIAAFR4X5rXallLVlrvD4pVQBJrgwYk8cisY=; b=B29DGJs0a00/jVMBdWim3NE8/Y7dHZP7H1ZzGod8/7o+CVrWpyQzJXQCZU8e/f2qtX 3dzL6k+jM5c3/lbFv95n4QuywR8RNXprXA4M5SsSfyCD+7EcFeKQKL6C+kpID5dQiX3j OpK66ZimHuktBBzOBeXxUZCJR5f8BtGpAN76HbWpsBDjysZpFQuk8wiAhQEpnIQ32o79 6uHlSucZ/9YfJebRR+CfDAdsfnGVKO4dox0A5wLFrdsm0A8q9mlvf4pZUq018KmV9z12 loIG97TDdv4YxQEiXErXcVuOwIFTPpHwXAWu6S2402+KmCQNeShWr68zC7zqLQ1kIz8Y mSYQ== X-Received: by 10.50.82.10 with SMTP id e10mr428820igy.58.1385085621102; Thu, 21 Nov 2013 18:00:21 -0800 (PST) Received: from [192.168.1.69] ([64.56.250.4]) by mx.google.com with ESMTPSA id y10sm6142089igl.4.2013.11.21.18.00.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 18:00:20 -0800 (PST) Message-ID: <528EBAB0.7010007@gmail.com> Date: Thu, 21 Nov 2013 21:00:16 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Softwires References: <528EB93A.5040700@gmail.com> In-Reply-To: <528EB93A.5040700@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Softwires] Oops: Re: Unclear text re port parameters in draft-ietf-softwire-map-dhcp-06 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 02:00:29 -0000 Just realized that the option will be provided only if no EA bits were present in the BMR. Hence the test as it stands is correct. The sentence fragment still needs expansion or deletion. Wonder if we need text saying what to do if prefix4-len + ea-len > 32 and the option is also present? Tom On 21/11/2013 8:54 PM, Tom Taylor wrote: > The text describing client validation of OPTION_S46_PORTPARAMS in the > second-last paragraph of Section 4.5 currently reads as follows: > > When receiving the Port Parameters option with an explicit PSID, the > client MUST use this explicit PSID in configuring its MAP interface. > If the conveyed IPv4 address is not 32 bit-long. The formula for > this check is "prefix4-len + ea-len = 32" and serves to ensure > that the explicit PSID is only applied to configurations with a > completely formed IPv4 address. > > I don't think the sentence fragment "If the conveyed IPv4 address ..." > should be there. In the subsequent sentence, I believe the check must be: > > "prefix4-len + ea-len > 32" > > Otherwise no port values are conveyed by the option. See Section 5.2 of > the MAP document, particularly Figure 6 and associated text. > > I would also add "shared and" before "completely formed" at the end of > the paragraph. > > Tom Taylor From wdec.ietf@gmail.com Fri Nov 22 02:30:38 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144481AD7C2 for ; Fri, 22 Nov 2013 02:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9iHtWuXeYzO for ; Fri, 22 Nov 2013 02:30:35 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C24641AC829 for ; Fri, 22 Nov 2013 02:30:35 -0800 (PST) Received: by mail-pa0-f53.google.com with SMTP id hz1so1134677pad.12 for ; Fri, 22 Nov 2013 02:30:28 -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=bwjkOKhXhAwSBGXWbMYmcT9DRJZa4vP8dCyeZrvTAmo=; b=ulXAMgyvidbWMRRYmvvYmi1TMnC0SrwPMfvWZF8eWuW5FL0c8z780GsrTgn9t3NyAE 1HtLjVqigXoJuvbLcew+BVg+FzNWlFNmzCvXpRgxmUuXdoHsZ47Jo3/eJ496fThl4iAk VoAGx+2tYyHFxzlNONx5Bec6EY0dUawtGIbct38lHWlYqSlrwli7z2d/yDzyaeAS3eyr iAMqV9M/Rb++Hk42juoV/A8yT1cKQPUPvrLm9CvR+ysp+3auNsJxc47cfD+EfFmJW54L Ik2f+jlls7/xXBxof+ogdO4ayqChd/f0kIWD5tds0HkkFOJDizXuN/HguQpaBJxAPs+f s9vA== MIME-Version: 1.0 X-Received: by 10.69.29.107 with SMTP id jv11mr2013495pbd.147.1385116228802; Fri, 22 Nov 2013 02:30:28 -0800 (PST) Received: by 10.70.71.163 with HTTP; Fri, 22 Nov 2013 02:30:28 -0800 (PST) In-Reply-To: <528D136C.60803@viagenie.ca> References: <528D136C.60803@viagenie.ca> Date: Fri, 22 Nov 2013 11:30:28 +0100 Message-ID: From: Wojciech Dec To: Simon Perreault Content-Type: multipart/alternative; boundary=001a1136952aca5eb304ebc18051 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP compatibility with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 10:30:38 -0000 --001a1136952aca5eb304ebc18051 Content-Type: text/plain; charset=ISO-8859-1 On 20 November 2013 20:54, Simon Perreault wrote: > WG, > > draft-ietf-softwire-map-08 contains this: > > 7.3. Backwards compatibility > > A MAP-E CE provisioned with only the IPv6 address of the BR, and with > no IPv4 address and port range configured by other means, MUST > disable its NAT44 functionality. This characteristic makes a MAP CE > compatible with DS-Lite [RFC6333] AFTRs, whose addresses are > configured as the MAP BR. > > In view of the recent discussions on provisioning, this functionality > strikes me as useless. There would be no reason for an ISP to use such > provisioning. A unified CPE would just do DS-Lite if that's what's > available. > > I suggest to remove that section. > You seem to equate ds-lite to being only there if it uses ds-lite dhcpv6 extensions, which is not correct. Consider the case where a MAP deployment has a need (for whatever reason) to direct some CPEs to an AFTR (stateful NAT). Instead of rolling out Ds-lite DHCP extensions all over, it is trivially simple to achieve the desired effect with the above MAP CE behaviour in place. This does not mean that those who want to use DS-lite dhcp extensions cannot do so, if available. But it does mean that those who deploy MAP, don't have to take care of mandating ds-lite dhcp extensions "just in case" all over the shop. As such, the functionality is IMO useful, and almost trivial to achieve in an implementation. -Wojciech. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --001a1136952aca5eb304ebc18051 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 20 November 2013 20:54, Simon Perreault <simon.perrea= ult@viagenie.ca> wrote:
WG,

draft-ietf-softwire-map-08 contains this:

7.3. Backwards compatibility

=A0 =A0A MAP-E CE provisioned with only the IPv6 address of the BR, and wit= h
=A0 =A0no IPv4 address and port range configured by other means, MUST
=A0 =A0disable its NAT44 functionality. =A0This characteristic makes a MAP = CE
=A0 =A0compatible with DS-Lite [RFC6333] AFTRs, whose addresses are
=A0 =A0configured as the MAP BR.

In view of the recent discussions on provisioning, this functionality strik= es me as useless. There would be no reason for an ISP to use such provision= ing. A unified CPE would just do DS-Lite if that's what's available= .

I suggest to remove that section.

You seem to equate ds-lite to = being only there if it uses ds-lite dhcpv6 extensions, which is not correct= .
Consider the case where a MAP deployment has a need (for whatever reason) t= o direct some CPEs to an AFTR (stateful NAT). Instead of rolling out Ds-lit= e DHCP extensions all over, it is trivially simple to achieve the desired e= ffect with the above MAP CE behaviour in place.
This does not mean that those who want to use DS-lite dhcp exten= sions cannot do so, if available. But it does mean that those who deploy MA= P, don't have to take care of mandating ds-lite dhcp extensions "j= ust in case" all over the shop.
As such, the functionality is IMO useful, and almost trivial to = achieve in an implementation.

-Wojciech.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--001a1136952aca5eb304ebc18051-- From wdec.ietf@gmail.com Fri Nov 22 02:40:38 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96DE1AD738 for ; Fri, 22 Nov 2013 02:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-15kjVj658Z for ; Fri, 22 Nov 2013 02:40:36 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id ABC741ACCF6 for ; Fri, 22 Nov 2013 02:40:36 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id kl14so1130051pab.5 for ; Fri, 22 Nov 2013 02:40:29 -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=YquGID5mDAtNJzbCQie/auvfwoT3MpX1PRz4ocKAH4o=; b=T4dyXhyfd8EYWQmSJyuAWPWjYv/F/TbJcJR0il6QM7CkvcJircHeePgUNM3fzPmKrz w/KOCWmTemRzoI9S7evWs3upT10FdLGua2DTP2VqyEeHXy8SnAF8zD+jTwgA+8xlxacS sODYd/rMHDJ9EOx2hb2DzUpLhx1kfhEGj/z8CS6qs9N/0+hCcpR7WwB5VHcupLsS6tJZ nO/FlYFnnuBefy4g2ghiyWc/Al561j802m2OORlsfqClK5B3ytc9i0+t/5ZV+6+QUqUK /LfWZ5zkbNiV9/Uaeq9mxBH5jXzikjmhW71x3LcDadxcHegJI1OaWVfMTF6utb8siMCK P/pw== MIME-Version: 1.0 X-Received: by 10.66.179.143 with SMTP id dg15mr11577429pac.52.1385116829810; Fri, 22 Nov 2013 02:40:29 -0800 (PST) Received: by 10.70.71.163 with HTTP; Fri, 22 Nov 2013 02:40:29 -0800 (PST) In-Reply-To: <528EBAB0.7010007@gmail.com> References: <528EB93A.5040700@gmail.com> <528EBAB0.7010007@gmail.com> Date: Fri, 22 Nov 2013 11:40:29 +0100 Message-ID: From: Wojciech Dec To: Tom Taylor Content-Type: multipart/alternative; boundary=047d7bea3f649d060d04ebc1a455 Cc: Softwires Subject: Re: [Softwires] Oops: Re: Unclear text re port parameters in draft-ietf-softwire-map-dhcp-06 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 10:40:38 -0000 --047d7bea3f649d060d04ebc1a455 Content-Type: text/plain; charset=ISO-8859-1 Seems like an editing error resulted in this dangling sentence. The corresponding text in draft -04 read as shown below, and I suggest we reinstate the "discard the option" behaviour: The MAP algorithm, as per Section 5.1 [I-D.ietf-softwire-map ], allows the port-indexing algorithm to be parametrized in terms of an excluded port range (a-bits) and an explicit Port Set ID (PSID) value, which can be conveyed via the S46 Port Parameters Option . The following behaviour is expected when processing this option by MAP clients: A client receiving a S46 Port parameters Option in an OPTION_S46_BRULE or OPTION_S46_FRULE whose derived IPv4 address is not 32 bit-long MUST discard the option. The formula for this check is "prefix4-len + ea-len == 32". This is to ensure that the explicit PSID is only applied to configurations with a completely formed IPv4 address. On 22 November 2013 03:00, Tom Taylor wrote: > Just realized that the option will be provided only if no EA bits were > present in the BMR. Hence the test as it stands is correct. The sentence > fragment still needs expansion or deletion. Wonder if we need text saying > what to do if prefix4-len + ea-len > 32 and the option is also present? > > Tom > > On 21/11/2013 8:54 PM, Tom Taylor wrote: > >> The text describing client validation of OPTION_S46_PORTPARAMS in the >> second-last paragraph of Section 4.5 currently reads as follows: >> >> When receiving the Port Parameters option with an explicit PSID, the >> client MUST use this explicit PSID in configuring its MAP interface. >> If the conveyed IPv4 address is not 32 bit-long. The formula for >> this check is "prefix4-len + ea-len = 32" and serves to ensure >> that the explicit PSID is only applied to configurations with a >> completely formed IPv4 address. >> >> I don't think the sentence fragment "If the conveyed IPv4 address ..." >> should be there. In the subsequent sentence, I believe the check must be: >> >> "prefix4-len + ea-len > 32" >> >> Otherwise no port values are conveyed by the option. See Section 5.2 of >> the MAP document, particularly Figure 6 and associated text. >> >> I would also add "shared and" before "completely formed" at the end of >> the paragraph. >> >> Tom Taylor >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --047d7bea3f649d060d04ebc1a455 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Seems like an editing error resulted in this dangling sent= ence. The corresponding text in draft -04 read as shown below, and I sugges= t we reinstate the "discard the option" behaviour:

   The MAP algorithm, as per Section 5.1 [I-D.ietf-softwire-map], allows
   the port-indexing algorithm to be parametrized in terms of an
   excluded port range (a-bits) and an explicit Port Set ID (PSID)
   value, which can be conveyed via the S46 Port Parameters Option .
   The following behaviour is expected when processing this option by
   MAP clients: A client receiving a S46 Port parameters Option in an
   OPTION_S46_BRULE or OPTION_S46_FRULE whose derived IPv4 address is
   not 32 bit-long MUST discard the option.  The formula for this check
   is "prefix4-len + ea-len =3D=3D 32".  This is to ensure that t=
he explicit
   PSID is only applied to configurations with a completely formed IPv4
   address.



On 22 November 2013 03:00, Tom Taylor <<= a href=3D"mailto:tom.taylor.stds@gmail.com" target=3D"_blank">tom.taylor.st= ds@gmail.com> wrote:
Just realized that the option will be provid= ed only if no EA bits were present in the BMR. Hence the test as it stands = is correct. The sentence fragment still needs expansion or deletion. Wonder= if we need text saying what to do if prefix4-len + ea-len > 32 and the = option is also present?

Tom

On 21/11/2013 8:54 PM, Tom Taylor wrote:
The text describing client validation of OPTION_S46_PORTPARAMS in the
second-last paragraph of Section 4.5 currently reads as follows:

=A0 =A0 When receiving the Port Parameters option with an explicit PSID, th= e
=A0 =A0 client MUST use this explicit PSID in configuring its MAP interface= .
=A0 =A0 If the conveyed IPv4 address is not 32 bit-long. =A0The formula for=
=A0 =A0 this check is "prefix4-len + ea-len =3D 32" and serves to= ensure
=A0 =A0 that the explicit PSID is only applied to configurations with a
=A0 =A0 completely formed IPv4 address.

I don't think the sentence fragment "If the conveyed IPv4 address = ..."
should be there. In the subsequent sentence, I believe the check must be:
=A0 =A0 =A0"prefix4-len + ea-len > 32"

Otherwise no port values are conveyed by the option. See Section 5.2 of
the MAP document, particularly Figure 6 and associated text.

I would also add "shared and" before "completely formed"= ; at the end of
the paragraph.

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

--047d7bea3f649d060d04ebc1a455-- From xing@cernet.edu.cn Fri Nov 22 05:46:45 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4DD1AE0B7 for ; Fri, 22 Nov 2013 05:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJhDlI8zxnKv for ; Fri, 22 Nov 2013 05:46:42 -0800 (PST) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 508CE1AE07C for ; Fri, 22 Nov 2013 05:46:41 -0800 (PST) Received: from [127.0.0.1] (unknown [125.34.52.106]) by centos (Coremail) with SMTP id AQAAf3C7ZgWfX49STwYwAA--.7436S5; Fri, 22 Nov 2013 21:44:02 +0800 (CST) Message-ID: <528F602F.1000009@cernet.edu.cn> Date: Fri, 22 Nov 2013 21:46:23 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Wojciech Dec References: <528D136C.60803@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3C7ZgWfX49STwYwAA--.7436S5 X-Coremail-Antispam: 1UD129KBjvJXoW7Kr45CFW8KF1DurW5GFWfKrg_yoW8KF1UpF 4ftF13Kr4UJF1xJ34kXr109r1jvrWDt34xJ345tw10yFW5AF4vqF1kt3WrJrW8JryrGF1U JF4j9r1UWanxZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUqGb7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I8E87Iv6xkF7I0E14v26F4UJV W0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0 I7IYx2IY67AKxVWUXVWUAwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r 4UM4x0Y48IcVAKI48JMxkIecxEwVAFwVW5GwCF04k20xvY0x0EwIxGrwC20s026c02F40E 14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIx kGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAF wI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r 4j6F4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07jr wIDUUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP compatibility with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 13:46:45 -0000 Wojciech Dec 写道: > > > > On 20 November 2013 20:54, Simon Perreault > > wrote: > > WG, > > draft-ietf-softwire-map-08 contains this: > > 7.3. Backwards compatibility > > A MAP-E CE provisioned with only the IPv6 address of the BR, and with > no IPv4 address and port range configured by other means, MUST > disable its NAT44 functionality. This characteristic makes a MAP CE > compatible with DS-Lite [RFC6333] AFTRs, whose addresses are > configured as the MAP BR. > > In view of the recent discussions on provisioning, this > functionality strikes me as useless. There would be no reason for > an ISP to use such provisioning. A unified CPE would just do > DS-Lite if that's what's available. > > I suggest to remove that section. > > > You seem to equate ds-lite to being only there if it uses ds-lite > dhcpv6 extensions, which is not correct. > Consider the case where a MAP deployment has a need (for whatever > reason) to direct some CPEs to an AFTR (stateful NAT). Instead of > rolling out Ds-lite DHCP extensions all over, it is trivially simple > to achieve the desired effect with the above MAP CE behaviour in place. > This does not mean that those who want to use DS-lite dhcp extensions > cannot do so, if available. But it does mean that those who deploy > MAP, don't have to take care of mandating ds-lite dhcp extensions > "just in case" all over the shop. > As such, the functionality is IMO useful, and almost trivial to > achieve in an implementation. Agree with Woj and an exmaple is demostrated in Section 4.1 of http://www.ietf.org/id/draft-xli-softwire-map-testing-02.txt Regards, xing > > -Wojciech. > > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > ------------------------------------------------------------------------ > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From simon.perreault@viagenie.ca Fri Nov 22 06:39:16 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6AC1AE126 for ; Fri, 22 Nov 2013 06:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93a-JsD8iyGJ for ; Fri, 22 Nov 2013 06:39:12 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 261A51AE0DB for ; Fri, 22 Nov 2013 06:39:12 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [206.123.31.67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C7E584690B; Fri, 22 Nov 2013 09:39:04 -0500 (EST) Message-ID: <528F6C88.1060508@viagenie.ca> Date: Fri, 22 Nov 2013 09:39:04 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Wojciech Dec References: <528D136C.60803@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP compatibility with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 14:39:16 -0000 Le 2013-11-22 05:30, Wojciech Dec a crit : > Consider the case where a MAP deployment has a need (for whatever > reason) to direct some CPEs to an AFTR (stateful NAT). Instead of > rolling out Ds-lite DHCP extensions all over ...or only to the CPEs in question... > it is trivially simple to > achieve the desired effect with the above MAP CE behaviour in place. > This does not mean that those who want to use DS-lite dhcp extensions > cannot do so, if available. But it does mean that those who deploy MAP, > don't have to take care of mandating ds-lite dhcp extensions "just in > case" all over the shop. s/all over the shop/to the CPEs in question/ Even if there is any efficiency gain over just sending the DHCPv6 option, it must be so small that I don't think we should standardize this hack. When we can, we need to focus on one way of doing things. DHCP is well understood and liked by operators. It's fine if you implement the hack, but there's no need for it in the RFC. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From wdec.ietf@gmail.com Fri Nov 22 09:03:05 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3E51ADFC6 for ; Fri, 22 Nov 2013 09:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6bA5JrOpsF5 for ; Fri, 22 Nov 2013 09:03:02 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D81B71ADFF6 for ; Fri, 22 Nov 2013 09:03:02 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id um1so1555501pbc.34 for ; Fri, 22 Nov 2013 09:02:55 -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=LfeS56d7Aptb996nOTmvzx/REK0fYxhDr7FWvsnpptw=; b=KHq1etofqzMU6JhGRP2bJd7qncuPicrW28AkavzMSjqmlfVR9oG2ThqxyfZAWnS/1k R3FwHStM5s/9ObuLFDoguEJytHMJ+rrwtrAi2pNKlXFBkSwEUmqz8IFbEnqSZJrr//X/ mfaVpBu1sn5wJ+9kZd2sTrUwNYIgXaAV6sR6YHHWGD4vDopGAu0oW8XK99nrii/0ZHlR pF3cgzREK7ZlCYev45cSxrkDaSEw2Wl8Cl9oZ5wHYhCo2ZJFqZIJbRdBkFXgbye1t7LK 95r0YEcwmN50FfJmR9iBRVLRqE6mBjfJ2+8xU3FUATantgJe4n4C5f0Ksc03UDG2wjBq 9N6g== MIME-Version: 1.0 X-Received: by 10.67.1.101 with SMTP id bf5mr13074223pad.50.1385139775803; Fri, 22 Nov 2013 09:02:55 -0800 (PST) Received: by 10.70.71.163 with HTTP; Fri, 22 Nov 2013 09:02:55 -0800 (PST) In-Reply-To: <528F6C88.1060508@viagenie.ca> References: <528D136C.60803@viagenie.ca> <528F6C88.1060508@viagenie.ca> Date: Fri, 22 Nov 2013 18:02:55 +0100 Message-ID: From: Wojciech Dec To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b15ac234d165b04ebc6fcc2 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP compatibility with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 17:03:05 -0000 --047d7b15ac234d165b04ebc6fcc2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is hardly a hack, it's a functional requirement of a CPE, specifying how the CPE behaves with a case of NOT having an IPv4 address =3D no NAT44, in this case. It's not about overflow. Besides that very obvious case to handle, I provided an explanation of the value the described behaviour brings, which has also been demonstrated (per Xing's mail). So far you have not substantiated what is the down-side of having this functionality on a MAP CPE, other than considering it not useful. Could you do that? Re: your substitution: No, an SP can hardly predict which CPEs in question need to have DS-Lite capabilities (as in support ds-lite options, et al) On 22 November 2013 15:39, Simon Perreault wro= te: > Le 2013-11-22 05:30, Wojciech Dec a =E9crit : > > Consider the case where a MAP deployment has a need (for whatever >> reason) to direct some CPEs to an AFTR (stateful NAT). Instead of >> rolling out Ds-lite DHCP extensions all over >> > > ...or only to the CPEs in question... > > > it is trivially simple to >> achieve the desired effect with the above MAP CE behaviour in place. >> This does not mean that those who want to use DS-lite dhcp extensions >> cannot do so, if available. But it does mean that those who deploy MAP, >> don't have to take care of mandating ds-lite dhcp extensions "just in >> case" all over the shop. >> > > s/all over the shop/to the CPEs in question/ > > Even if there is any efficiency gain over just sending the DHCPv6 option, > it must be so small that I don't think we should standardize this hack. > When we can, we need to focus on one way of doing things. DHCP is well > understood and liked by operators. > > It's fine if you implement the hack, but there's no need for it in the RF= C. > > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > --047d7b15ac234d165b04ebc6fcc2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is hardly a hack, it's a functional req= uirement of a CPE, specifying how the CPE behaves with a case of NOT having= an IPv4 address =3D no NAT44, in this case. It's not about overflow.
Besides that very obvious case to handle, I provided an explanation of = the value the described behaviour brings, which has also been demonstrated = (per Xing's mail). So far you have not substantiated what is the down-s= ide of having this functionality on a MAP CPE, other than considering it no= t useful. Could you do that?

Re: your substitution: No, an SP can hardly predict which CP= Es in question need to have DS-Lite capabilities (as in support ds-lite opt= ions, et al)




On 22 November 2013 15:39, Simon Perreault &= lt;simon.p= erreault@viagenie.ca> wrote:
Le 2013-11-22 05:30, Wojciech Dec a =E9crit = :

Consider the case where a MAP deployment has a need (for whatever
reason) to direct some CPEs to an AFTR (stateful NAT). Instead of
rolling out Ds-lite DHCP extensions all over

...or only to the CPEs in question...


it is trivially simple to
achieve the desired effect with the above MAP CE behaviour in place.
This does not mean that those who want to use DS-lite dhcp extensions
cannot do so, if available. But it does mean that those who deploy MAP,
don't have to take care of mandating ds-lite dhcp extensions "just= in
case" all over the shop.

s/all over the shop/to the CPEs in question/

Even if there is any efficiency gain over just sending the DHCPv6 option, i= t must be so small that I don't think we should standardize this hack. = When we can, we need to focus on one way of doing things. DHCP is well unde= rstood and liked by operators.

It's fine if you implement the hack, but there's no need for it in = the RFC.


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

--047d7b15ac234d165b04ebc6fcc2-- From otroan@employees.org Sat Nov 23 10:13:34 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA8A1AE1A7 for ; Sat, 23 Nov 2013 10:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg9E7SdYJhCX for ; Sat, 23 Nov 2013 10:13:33 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9371AE06F for ; Sat, 23 Nov 2013 10:13:32 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFANPukFKQ/khR/2dsb2JhbABZgwe9KYEZFnSCJQEBBAF5BQsLDjhXBogOBr5pF442AQFPB4MggRMDkDGZdYMpO4E1 X-IronPort-AV: E=Sophos;i="4.93,759,1378857600"; d="asc'?scan'208";a="1125066" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 23 Nov 2013 18:13:24 +0000 Received: from dhcp-10-61-102-60.cisco.com (dhcp-10-61-102-60.cisco.com [10.61.102.60]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rANIDJN6030854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Nov 2013 18:13:20 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_E3AD2907-36E4-45E6-886C-EBC92CA24924"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Sat, 23 Nov 2013 19:13:17 +0100 Message-Id: References: <528D136C.60803@viagenie.ca> <528F6C88.1060508@viagenie.ca> To: Wojciech Dec X-Mailer: Apple Mail (2.1822) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP compatibility with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 18:13:34 -0000 --Apple-Mail=_E3AD2907-36E4-45E6-886C-EBC92CA24924 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > This is hardly a hack, it's a functional requirement of a CPE, = specifying how the CPE behaves with a case of NOT having an IPv4 address = =3D no NAT44, in this case. It's not about overflow. >=20 > Besides that very obvious case to handle, I provided an explanation of = the value the described behaviour brings, which has also been = demonstrated (per Xing's mail). So far you have not substantiated what = is the down-side of having this functionality on a MAP CPE, other than = considering it not useful. Could you do that? >=20 > Re: your substitution: No, an SP can hardly predict which CPEs in = question need to have DS-Lite capabilities (as in support ds-lite = options, et al) to take the overflow case, then you'd still need to provision this as = two MAP domains. does it make much difference if you provision it as one MAP domain and = one 6334 option? I'm in favour of having these mechanisms as ships in the night. given that we already have a way to provision DS-lite (6334), I wouldn't = really be in favour of adding another one. I think CPE implementors have enough combinations already. ;-) cheers, Ole --Apple-Mail=_E3AD2907-36E4-45E6-886C-EBC92CA24924 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSkPA9AAoJEFuJXizso86gUVsH/3qPwVffH031HedkfrJiylOf RZCSDX+z5XT+TzwZvb78FdfPzft4tPTr7gtcVl6cudC6n803IowAv6+RDsG5F4Ii J/RA6xZBehWmnHpikScHRjqgjUfg+CeCb0XFzrWKPSTkzLSlpBmUz39IG7jCtuhe pXwg3SWWt0X46QPO5aPRL4ZerrvMCe+xYby0L+R0jQO/BRSPU/FG2skr8k7w+a8L OvmBdxMCi9MYrPcQhSz7KnHmbQNqUC3F5XFDvxRKNmIKLwrSuUIqmHdd7l7d1uVZ KIrjwxSUv1R4fxq+mGUjhDrMB8VrNhiLo2ZV/CYeHT+9ieWhVep9g3Meza038us= =fW/R -----END PGP SIGNATURE----- --Apple-Mail=_E3AD2907-36E4-45E6-886C-EBC92CA24924-- From otroan@employees.org Sun Nov 24 11:10:18 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391511AE1A7 for ; Sun, 24 Nov 2013 11:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQBKczd9-4Hq for ; Sun, 24 Nov 2013 11:10:16 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 884CF1AE06F for ; Sun, 24 Nov 2013 11:10:16 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAMZOklKQ/khR/2dsb2JhbABZgwc4vCFOgR0WdIIlAQEBAwEBAQFrCwULCw4KLiEGMAYTh28DCQYNs3QNiCcTBIx4gStkB4MggRMDkDGFeI5FhTiBaoE/O4EsAh4G X-IronPort-AV: E=Sophos;i="4.93,763,1378857600"; d="asc'?scan'208";a="1164739" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 24 Nov 2013 19:10:07 +0000 Received: from dhcp-10-61-102-204.cisco.com (dhcp-10-61-102-204.cisco.com [10.61.102.204]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAOJA2kO027716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 24 Nov 2013 19:10:04 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_6E0D8F66-F27B-4959-A99E-0EE15D14D4F4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Sun, 24 Nov 2013 20:10:02 +0100 Message-Id: References: <528EB93A.5040700@gmail.com> <528EBAB0.7010007@gmail.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1822) Cc: Softwires Subject: Re: [Softwires] Oops: Re: Unclear text re port parameters in draft-ietf-softwire-map-dhcp-06 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 19:10:18 -0000 --Apple-Mail=_6E0D8F66-F27B-4959-A99E-0EE15D14D4F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Tom, Wojciech, thanks, fixed. Best regards, Ole On 22 Nov 2013, at 11:40 , Wojciech Dec wrote: > Seems like an editing error resulted in this dangling sentence. The = corresponding text in draft -04 read as shown below, and I suggest we = reinstate the "discard the option" behaviour: >=20 > The MAP algorithm, as per Section 5.1 [I-D.ietf-softwire-map > ], allows > the port-indexing algorithm to be parametrized in terms of an > excluded port range (a-bits) and an explicit Port Set ID (PSID) > value, which can be conveyed via the S46 Port Parameters Option . > The following behaviour is expected when processing this option by > MAP clients: A client receiving a S46 Port parameters Option in an > OPTION_S46_BRULE or OPTION_S46_FRULE whose derived IPv4 address is > not 32 bit-long MUST discard the option. The formula for this = check > is "prefix4-len + ea-len =3D=3D 32". This is to ensure that the = explicit > PSID is only applied to configurations with a completely formed = IPv4 > address. >=20 >=20 >=20 >=20 > On 22 November 2013 03:00, Tom Taylor = wrote: > Just realized that the option will be provided only if no EA bits were = present in the BMR. Hence the test as it stands is correct. The sentence = fragment still needs expansion or deletion. Wonder if we need text = saying what to do if prefix4-len + ea-len > 32 and the option is also = present? >=20 > Tom >=20 > On 21/11/2013 8:54 PM, Tom Taylor wrote: > The text describing client validation of OPTION_S46_PORTPARAMS in the > second-last paragraph of Section 4.5 currently reads as follows: >=20 > When receiving the Port Parameters option with an explicit PSID, = the > client MUST use this explicit PSID in configuring its MAP = interface. > If the conveyed IPv4 address is not 32 bit-long. The formula for > this check is "prefix4-len + ea-len =3D 32" and serves to ensure > that the explicit PSID is only applied to configurations with a > completely formed IPv4 address. >=20 > I don't think the sentence fragment "If the conveyed IPv4 address ..." > should be there. In the subsequent sentence, I believe the check must = be: >=20 > "prefix4-len + ea-len > 32" >=20 > Otherwise no port values are conveyed by the option. See Section 5.2 = of > the MAP document, particularly Figure 6 and associated text. >=20 > I would also add "shared and" before "completely formed" at the end of > the paragraph. >=20 > Tom Taylor > _______________________________________________ > 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 --Apple-Mail=_6E0D8F66-F27B-4959-A99E-0EE15D14D4F4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSkk8KAAoJEFuJXizso86glz4IAMuryPQyAZVI+b9S8zBA7E8v gdC5FFflL/0ZqoYDIMV/Ff7IMsfecXc4lwnLluTosn4CrQePkzJlPEFmragPSHf9 I6FrPZZ7k0Y4nCGepznqj663Y0G2izJ4P4tp2YQv6ul6ID1ftY8RKnkXixfP3im0 MrqAHKjGOFkziI2c2+IWbLECvAQrowb2GJIXXxkuWpGngt39AATNoUxe/44Zb8Pb uvWvOWSWZaJNsyr2trHAvYFTB/ubfqNxxSBz3gJVfuqPzU4t+YgKw5wvSVgMrr3h 9WEXTAT6cBbPeKv5tG9cUt/qujU4CSYZZecucI8ezcbH4Enz9kogZtZvoeQh124= =au8t -----END PGP SIGNATURE----- --Apple-Mail=_6E0D8F66-F27B-4959-A99E-0EE15D14D4F4-- From wdec.ietf@gmail.com Mon Nov 25 01:39:12 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDCD1ACCE3 for ; Mon, 25 Nov 2013 01:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44FAFfNkenii for ; Mon, 25 Nov 2013 01:39:10 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4578B1ACCDF for ; Mon, 25 Nov 2013 01:39:10 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id v10so5145229pde.28 for ; Mon, 25 Nov 2013 01:39: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=MjT8hd2b1IkGSIyB2QfIQd5bv9oVHUe168zPqZc7bUM=; b=iPF5FaolYkJHMHQ+BN5wNEI3wBi5UevEOD7y9JqR0NTnYyXHFh+Qedn9TIHjHwcTNV e4h18S3VBJ8xriO35ZJc/Bl29v0xvOruX+CEYUO5Imxz6iV60vfRDK16umCBbNFmH1Zo bXr31YywxloLk786vNGFrJNrG/cGmiqgQGdU+dgANjuYZAf1XYoHYlX1Q1KdkneGi6Bg 21Kg18kGw8gUg57vFzt79kgDOj2vFtehfk6ml9lrEKnxFjjtwoORB0fN2syFa9lbgQFK /+KAubId9EKTayULElHZLpm8W7M/0lqyMofeOjEQfdgnKQYrMCz46yXjMHwQz+xtaA/a BeNg== MIME-Version: 1.0 X-Received: by 10.66.255.39 with SMTP id an7mr26306802pad.7.1385372349550; Mon, 25 Nov 2013 01:39:09 -0800 (PST) Received: by 10.70.57.163 with HTTP; Mon, 25 Nov 2013 01:39:09 -0800 (PST) In-Reply-To: References: <528D136C.60803@viagenie.ca> <528F6C88.1060508@viagenie.ca> Date: Mon, 25 Nov 2013 10:39:09 +0100 Message-ID: From: Wojciech Dec To: Ole Troan Content-Type: multipart/alternative; boundary=047d7b15b25fc6d54304ebfd22bc Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP compatibility with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 09:39:12 -0000 --047d7b15b25fc6d54304ebfd22bc Content-Type: text/plain; charset=ISO-8859-1 You're apparently missing some key points: 1. It's a functional requirement of a CPE, specifying how the CPE behaves with a case of NOT having an IPv4 address. What is the to be the bahviour of a MAP CPE without one? 2. This is NOT about configuring a ds-lite CPE Throughout, its still not been answered what is the downside of having this functionality of a *MAP CPE*? On 23 November 2013 19:13, Ole Troan wrote: > > This is hardly a hack, it's a functional requirement of a CPE, > specifying how the CPE behaves with a case of NOT having an IPv4 address = > no NAT44, in this case. It's not about overflow. > > > > Besides that very obvious case to handle, I provided an explanation of > the value the described behaviour brings, which has also been demonstrated > (per Xing's mail). So far you have not substantiated what is the down-side > of having this functionality on a MAP CPE, other than considering it not > useful. Could you do that? > > > > Re: your substitution: No, an SP can hardly predict which CPEs in > question need to have DS-Lite capabilities (as in support ds-lite options, > et al) > > to take the overflow case, then you'd still need to provision this as two > MAP domains. > does it make much difference if you provision it as one MAP domain and one > 6334 option? > > I'm in favour of having these mechanisms as ships in the night. > > given that we already have a way to provision DS-lite (6334), I wouldn't > really be in favour of adding another one. > I think CPE implementors have enough combinations already. ;-) > > cheers, > Ole > --047d7b15b25fc6d54304ebfd22bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You're apparently missing some key points: <= br>
1.=A0 It's a functional requirement of a CPE, specifying how the= CPE behaves with a case of NOT having an IPv4 address. What is the to be t= he bahviour of a MAP CPE without one?
2.=A0 This is NOT about configuring a ds-lite CPE

<= /div>
Throughout, its still not been answered what is the downside of h= aving this functionality of a *MAP CPE*?




On 23 Novembe= r 2013 19:13, Ole Troan <otroan@employees.org> wrote:
=
> This is hardly a hack, it's a functional require= ment of a CPE, specifying how the CPE behaves with a case of NOT having an = IPv4 address =3D no NAT44, in this case. It's not about overflow.
>
> Besides that very obvious case to handle, I provided an explanation of= the value the described behaviour brings, which has also been demonstrated= (per Xing's mail). So far you have not substantiated what is the down-= side of having this functionality on a MAP CPE, other than considering it n= ot useful. Could you do that?
>
> Re: your substitution: No, an SP can hardly predict which CPEs in ques= tion need to have DS-Lite capabilities (as in support ds-lite options, et a= l)

to take the overflow case, then you'd still need to provision thi= s as two MAP domains.
does it make much difference if you provision it as one MAP domain and one = 6334 option?

I'm in favour of having these mechanisms as ships in the night.

given that we already have a way to provision DS-lite (6334), I wouldn'= t really be in favour of adding another one.
I think CPE implementors have enough combinations already. ;-)

cheers,
Ole

--047d7b15b25fc6d54304ebfd22bc-- From otroan@employees.org Mon Nov 25 04:39:53 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26F71AD8EF for ; Mon, 25 Nov 2013 04:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A22LA4krYdYo for ; Mon, 25 Nov 2013 04:39:52 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 809F11ACCF6 for ; Mon, 25 Nov 2013 04:39:52 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAMZDk1KQ/khM/2dsb2JhbABZgwe9MoErFnSCJQEBBAF5BQsLDjhXBogOBr1sF48HB4MggRMDkDGZdYMpOw X-IronPort-AV: E=Sophos;i="4.93,767,1378857600"; d="asc'?scan'208";a="591002" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 25 Nov 2013 12:39:52 +0000 Received: from dhcp-10-61-109-79.cisco.com (dhcp-10-61-109-79.cisco.com [10.61.109.79]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAPCdmlN001245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Nov 2013 12:39:48 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_80EBD19E-BD1C-4449-B407-F6482B588620"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ole Troan In-Reply-To: Date: Mon, 25 Nov 2013 13:39:47 +0100 Message-Id: <6275CE5E-E0AD-4C0F-8661-443785C966DF@employees.org> References: <528D136C.60803@viagenie.ca> <528F6C88.1060508@viagenie.ca> To: Wojciech Dec X-Mailer: Apple Mail (2.1822) Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP compatibility with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 12:39:54 -0000 --Apple-Mail=_80EBD19E-BD1C-4449-B407-F6482B588620 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Wojciech, > You're apparently missing some key points:=20 that's not uncommon. ;-) > 1. It's a functional requirement of a CPE, specifying how the CPE = behaves with a case of NOT having an IPv4 address. What is the to be the = bahviour of a MAP CPE without one? just like if it didn't get an IPv4 address on native Ethernet. > 2. This is NOT about configuring a ds-lite CPE my understanding was that the CPE had to be provisioned for this mode, possibly as a separate MAP domain. and that the BR must also act as a = CGN. > Throughout, its still not been answered what is the downside of having = this functionality of a *MAP CPE*? it adds yet another variant. what's wrong with provisioning the DS-lite option when you want this = behaviour? or if you want overflow from MAP to DS-lite? I don't get the benefit of what you are suggesting. cheers, Ole --Apple-Mail=_80EBD19E-BD1C-4449-B407-F6482B588620 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSk0UTAAoJEFuJXizso86gmOYH/Au7zTXndLXQyfT0OCuHhOkC ++VFOp+48iis05v8dr3LzUxUQENC/mCICeTJLw5JhHeoBCU37GWED4FZ6b99nUuV 4okKfVJ7UT9BusTYIJpEvUPAgyNSP7SxqbbFgw0zsN4/+jJ3dn8YKl+8B894+s92 6BlkUKAW8yyDIG8PUhOUY0bsMldpcnV2Cde6agirxt49+RWlLwlF1uaCBSrAVm1I ORzNDB8kzasmKoQwWG4Nh/MdKeYwyV3D9kohs/qr1qgkpq5aEW1D8naI0T+7nVSx i6fdryoLR3B1WCcbYz7IuCxeRnJ5I35Y1DvpFQOMQ7LWFVo9wpzDg6jqSesPs9A= =NLzE -----END PGP SIGNATURE----- --Apple-Mail=_80EBD19E-BD1C-4449-B407-F6482B588620-- From simon.perreault@viagenie.ca Mon Nov 25 10:13:56 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715BD1AE01B for ; Mon, 25 Nov 2013 10:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVJeLAe80Bur for ; Mon, 25 Nov 2013 10:13:55 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 81BC81ADF27 for ; Mon, 25 Nov 2013 10:13:55 -0800 (PST) Received: from balaise.nomis80.org (unknown [IPv6:2620:0:230:2001::100d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 84E9F468F0; Mon, 25 Nov 2013 13:13:54 -0500 (EST) Message-ID: <52939361.2070207@viagenie.ca> Date: Mon, 25 Nov 2013 13:13:53 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Wojciech Dec , Ole Troan References: <528D136C.60803@viagenie.ca> <528F6C88.1060508@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP compatibility with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 18:13:56 -0000 Le 25/11/2013 04:39, Wojciech Dec a crit : > Throughout, its still not been answered what is the downside of having > this functionality of a *MAP CPE*? We've been told many times that operators don't want a zillion different ways of doing the same thing. This WG in particular has often been the target of such comments. We need to do something about it. IMHO this is one instance of duplication that can easily be eliminated. Simon From rajiva@cisco.com Mon Nov 25 10:15:04 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2611AE01B for ; Mon, 25 Nov 2013 10:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDbMPFptk7xk for ; Mon, 25 Nov 2013 10:15:03 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED781AE01C for ; Mon, 25 Nov 2013 10:15:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1905; q=dns/txt; s=iport; t=1385403303; x=1386612903; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yjrRgD/7kXcD83IiPgTX8BviMcjjj2zcwD1DNVEoVm8=; b=GjoUVZU8cGH96zFKtwVG8tcP0SOSrgrqtqNoEP6uuyptzAoknXiRJOa7 5HJU79nPGcSJ8drMBTO4SVNjBmDXvIqVTKnd/K886ko25n0HMVgtMy9+1 iy4crWJRI+WG6t83jyrfEv3uddcd7fAelR1WyFpNHlEv1UzSbCt1u6uGn s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAP2Sk1KtJV2a/2dsb2JhbABZgwc4U7taToEqFnSCJQEBAQQBAQE3NAsMBgEIDgMDAQIBHjEGCx0IAQEEDgWHbwMPDbYLDYgJEwSMeIFkKwcGhC0DlimBa4xahTiDKIIq X-IronPort-AV: E=Sophos;i="4.93,769,1378857600"; d="scan'208";a="2098309" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 25 Nov 2013 18:15:03 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAPIF2Wi028225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 18:15:02 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.147]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 25 Nov 2013 12:15:02 -0600 From: "Rajiv Asati (rajiva)" To: Wojciech Dec Thread-Topic: [Softwires] port-forwards in MAP Thread-Index: Ac7f/qsBm+9ChNYxQNapxnMoIyOmoAApa08AACsmOwACMGt8AA== Date: Mon, 25 Nov 2013 18:15:01 +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.3.8.130913 x-originating-ip: [10.65.34.84] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org" Subject: Re: [Softwires] port-forwards in MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 18:15:05 -0000 Good point, Woj. What I described was indeed the default behavior. --=20 Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: Wojciech Dec Date: Thursday, November 14, 2013 4:48 AM To: Rajiv Asati Cc: Kristian Poscic , Softwires-wg list Subject: Re: [Softwires] port-forwards in MAP >Well, never say "never" :-) MAP allows via the a-bits/offset-bits setting >the range of "excluded ports" in a domain > > to be configured. Thus, while not set so as a default, ports <1024 can >also be used. > > >There is naturally the non-address-shared mode of MAP to consider (i.e. >when PSID length =3D0). Here each MAP user has a full IPv4 address and of >course also the corresponding full port range. > > >Cheers, > >Wojciech > > > >On 13 November 2013 19:12, Rajiv Asati (rajiva) > wrote: > >Hi Kristian, > >Yes, that's correct. > >-- >Cheers, >Rajiv > > > > >-----Original Message----- >From: , Kristian Poscic >Date: Tuesday, November 12, 2013 6:31 PM >To: Softwires-wg list >Subject: [Softwires] port-forwards in MAP > >>Just wanted to confirm one thing for MAP-E in regards to static port >>forwards. >> >>Can it be assumed that excluded port-range (0-1023 and possibly more >>depending on the offset) will never be used in MAP? The port forwards >>will be allocated on the CPE in statefull NAT44 and the ports will be >>allocated according to the >> delegated PSID and not from the MAP excluded range (well-known ports for >>example). >>Thanks. >> >> > > > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires > > > > > From wdec.ietf@gmail.com Wed Nov 27 11:41:52 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4661ADD02 for ; Wed, 27 Nov 2013 11:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-AmMjZJBUuo for ; Wed, 27 Nov 2013 11:41:50 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 919E51ADFE3 for ; Wed, 27 Nov 2013 11:37:32 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id uo5so11051503pbc.15 for ; Wed, 27 Nov 2013 11:37:32 -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=Ta+MVQH65a0gY5COBn26W2FuqzGqSpjaA3fbT0rdTDg=; b=yE33mzdjAmIXOA3nvYJGpmfMYyqHbCgucqFdKt4bP7EEvNbFwmaTBWrG4QYI56agoC yUSbBYO88J0XgQdtJHL4zljjvVPO6PF77KcXpcntTNKofF96RUMpFVfcKq2d7L1YrRSv WHsdOgrD2ozyWT74rMwpvEv+IJM6x4yHH34y9oRkaFD0LlsmPoDRUhc8xi3Cbesiu/jy +bY08gZ9rBozzl/rInKLQ8ClL2naVXhF+OxIpGCKgzalNRgHI+4QM4MrLa9espWjEW4u UMTHqyBkd+SCDUhXCdiTXinV76mYPW6jjjL0gg3RqidqnW/0jPH8YpaykoVc90L9L2Wm ip1w== MIME-Version: 1.0 X-Received: by 10.66.161.194 with SMTP id xu2mr23476662pab.120.1385581052156; Wed, 27 Nov 2013 11:37:32 -0800 (PST) Received: by 10.70.57.163 with HTTP; Wed, 27 Nov 2013 11:37:32 -0800 (PST) In-Reply-To: <52939361.2070207@viagenie.ca> References: <528D136C.60803@viagenie.ca> <528F6C88.1060508@viagenie.ca> <52939361.2070207@viagenie.ca> Date: Wed, 27 Nov 2013 20:37:32 +0100 Message-ID: From: Wojciech Dec To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b86eaae6be04804ec2dbab6 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP compatibility with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 19:41:52 -0000 --047d7b86eaae6be04804ec2dbab6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 25 November 2013 19:13, Simon Perreault wro= te: > Le 25/11/2013 04:39, Wojciech Dec a =E9crit : > > Throughout, its still not been answered what is the downside of having >> this functionality of a *MAP CPE*? >> > > We've been told many times that operators don't want a zillion different > ways of doing the same thing. This WG in particular has often been the > target of such comments. We need to do something about it. IMHO this is o= ne > instance of duplication that can easily be eliminated. > How is describing the behaviour of a MAP CPE that has the IPv6 address of a BR, but not an IPv4 address the duplication of anything? Could you perhaps also stick to non-rhetorical answers. Wojciech. > > Simon > --047d7b86eaae6be04804ec2dbab6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 25 November 2013 19:13, Simon Perreault <simon.perrea= ult@viagenie.ca> wrote:
Le 25/11/2013 04:39, Wojc= iech Dec a =E9crit :

Throughout, its still not been answered what is the downside of having
this functionality of a *MAP CPE*?

We've been told many times that operators don't want a zillion diff= erent ways of doing the same thing. This WG in particular has often been th= e target of such comments. We need to do something about it. IMHO this is o= ne instance of duplication that can easily be eliminated.<= font color=3D"#888888">

How is describing the behavi= our of a MAP CPE that has the IPv6 address of a BR, but not an IPv4 address= the duplication of anything?
Could you perhaps also stick to non-rheto= rical answers.

Wojciech.

Simon

--047d7b86eaae6be04804ec2dbab6-- From wdec.ietf@gmail.com Wed Nov 27 12:15:50 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83981AE29C for ; Wed, 27 Nov 2013 12:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfAa8duF-hqW for ; Wed, 27 Nov 2013 12:15:49 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id BF9DD1AE172 for ; Wed, 27 Nov 2013 12:10:38 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id md12so11108665pbc.35 for ; Wed, 27 Nov 2013 12:10:38 -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=s7ch7wY0jt8q+0KlJzgTq5rf+2iUGKSEENr/Bxe9Z1U=; b=X9Qp7PwY1yvxN/pKB9RenVsgv2mugzPRtDW6g9UPQZaA3+na7A3LDsstUgi/yv49Hf PBK56F89Vpi7iQFtIwomXPA0O4iMWAYABKZKOueW65+mZVHPm2Fpd+A0z6Cbm7MEH75a mONT+ui/9ub9znx9CuUEkrECBiE3VmIdpcU3yMZ1eL9PMp45+EOBI/kEk31QPMzFxKLu shWrXrKSX6vLLxlOEAuKGqtqpe2BcaZv/X3/jixV6fNEQB0r+m61wEkAVDR6PlNUVoHK 24Fw842+DLfWevbuaqyd5yexGEGXIWi1dww1Q86ntVomHzLScSEnmQaoxgF/OOJieU8g 4qnQ== MIME-Version: 1.0 X-Received: by 10.66.145.40 with SMTP id sr8mr43711453pab.60.1385583038265; Wed, 27 Nov 2013 12:10:38 -0800 (PST) Received: by 10.70.57.163 with HTTP; Wed, 27 Nov 2013 12:10:38 -0800 (PST) In-Reply-To: <6275CE5E-E0AD-4C0F-8661-443785C966DF@employees.org> References: <528D136C.60803@viagenie.ca> <528F6C88.1060508@viagenie.ca> <6275CE5E-E0AD-4C0F-8661-443785C966DF@employees.org> Date: Wed, 27 Nov 2013 21:10:38 +0100 Message-ID: From: Wojciech Dec To: Ole Troan Content-Type: multipart/alternative; boundary=047d7b6da6f2cd7fc104ec2e3092 Cc: "softwires@ietf.org" Subject: Re: [Softwires] MAP compatibility with DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 20:15:51 -0000 --047d7b6da6f2cd7fc104ec2e3092 Content-Type: text/plain; charset=ISO-8859-1 Now, how about this to move things forward: We replace the quoted text/section with the following added into section 5.4 "A MAP-E CE provisioned with only the IPv6 address of the BR MUST disable its NAT44 functionality and treat the point-point tunnel interface as active for IPv4 forwarding." In case we want to proceed with the argument, it is continued inline... On 25 November 2013 13:39, Ole Troan wrote: > Wojciech, > > > You're apparently missing some key points: > > that's not uncommon. ;-) > > > 1. It's a functional requirement of a CPE, specifying how the CPE > behaves with a case of NOT having an IPv4 address. What is the to be the > bahviour of a MAP CPE without one? > > just like if it didn't get an IPv4 address on native Ethernet. > Now, the way MAP's forwarding rules have been modelled, the IPv4 default route follows the IPv6 BR address. Hence, the presence of the IPv6 address equates to the presence of a v4 default route, accessible via the tunnel to the BR. In none of the v4 auto tunneling technology in use here is it a requirement for the tunneling router to have some operator assigned IPv4 address on an interface to be able to forward packets on it. > > > 2. This is NOT about configuring a ds-lite CPE > > my understanding was that the CPE had to be provisioned for this mode, > possibly as a separate MAP domain. and that the BR must also act as a CGN. > One doesn't need a DS-Lite CPE to be able to send IPv4inIPv6. > > > Throughout, its still not been answered what is the downside of having > this functionality of a *MAP CPE*? > > it adds yet another variant. > what's wrong with provisioning the DS-lite option when you want this > behaviour? > Is DS-Lite required to configure a MAP CPE, or to enable IPv4inIPv6 on a router? > or if you want overflow from MAP to DS-lite? > I didn't bring up overflow - not sure why you added it. > > I don't get the benefit of what you are suggesting. > Clearly, but there are multiple as mentioned (not least, the ability for the operator to actually turn off NAT44 on the user's CPE for t'shooting purposes). Cheers, Wojciech. > cheers, > Ole > --047d7b6da6f2cd7fc104ec2e3092 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Now, how about this to move= things forward: We replace the quoted text/section with the following adde= d into section 5.4

"A MAP-E CE provisioned with only the IPv6 a= ddress of the BR MUST
=A0 =A0disable its NAT44 functionality and treat the point-point tunnel int= erface as active for IPv4 forwarding."
=A0
In case we want to proceed with the argument, it is continued i= nline...

On 25 Novem= ber 2013 13:39, Ole Troan <otroan@employees.org> wrote:
Wojciech,

> You're apparently missing some key points:

that's not uncommon. ;-)

> 1. =A0It's a functional requirement of a CPE, specifying how the C= PE behaves with a case of NOT having an IPv4 address. What is the to be the= bahviour of a MAP CPE without one?

just like if it didn't get an IPv4 address on native Ethernet.

Now, the way MAP's forwarding rules have been modelle= d, the IPv4 default route follows the IPv6 BR address. Hence, the presence = of the IPv6 address equates to the presence of a v4 default route, accessib= le via the tunnel to the BR. In none of the v4 auto tunneling technology in= use here is it a requirement for the tunneling router to have some operato= r assigned IPv4 address on an interface to be able to forward packets on it= .

=A0

> 2. =A0This is NOT about configuring a ds-lite CPE

my understanding was that the CPE had to be provisioned for this mode= ,
possibly as a separate MAP domain. and that the BR must also act as a CGN.<= br>

One doesn't need a DS-Lite CPE to b= e able to send IPv4inIPv6.

> Throughout, its still not been answered what is the downside of having= this functionality of a *MAP CPE*?

it adds yet another variant.
what's wrong with provisioning the DS-lite option when you want this be= haviour?

Is DS-Lite required to configu= re a MAP CPE, or to enable IPv4inIPv6 on a router?
=A0
or if you want overflow from MAP to DS-lite?

I didn't bring up overflow - not sure why you added it.
=
=A0

I don't get the benefit of what you are suggesting.

Clearly, but there are multiple as mentioned (not least, t= he ability for the operator to actually turn off NAT44=A0 on the user's= CPE for t'shooting purposes).

Cheers,
Wojciech.


cheers,
Ole

--047d7b6da6f2cd7fc104ec2e3092--