Re: [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts

<ian.farrer@telekom.de> Mon, 11 November 2013 11:54 UTC

Return-Path: <ian.farrer@telekom.de>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@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: <ian.farrer@telekom.de>
To: <otroan@employees.org>, <ifarrer@me.com>
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: <CEA683DF.90032%ian.farrer@telekom.de>
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: [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=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.
‹

Does that cover it?

Cheers,
Ian




On 08/11/2013 00:24, "Ole Troan" <otroan@employees.org> 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?
>> 
>> Likewise, I¹m putting a similar back pointer to MAP-DHCP in the
>>dhc-v4-configuration draft:
>> 
>> 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.
>> 
>> 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
>