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 14:04 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 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: <ian.farrer@telekom.de>
To: <wdec@cisco.com>, <gnocuil@gmail.com>
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: <CEA69EED.900C2%ian.farrer@telekom.de>
In-Reply-To: <CEA68D8D.B4425%wdec@cisco.com>
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: [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 14:04:28 -0000

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 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.

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) <wdec@cisco.com<mailto: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).

[ian] But the draft only describes MAP provisioning related to stateful DHCP, so it doesn’t make any requirements 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 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.

[ian] The point here is that if you’re provisioning any softwire over DHCPv6, then they’re 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’s behest).

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.

[ian] The reason that I requested it is that Bernie and Tomeck don’t want the map-dhcp draft to become a basis that people will then try and extend with DHCPv4 options in the future.