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

Ole Troan <otroan@employees.org> Mon, 11 November 2013 14:17 UTC

Return-Path: <otroan@employees.org>
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 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 <otroan@employees.org>
In-Reply-To: <CEA69EED.900C2%ian.farrer@telekom.de>
Date: Mon, 11 Nov 2013 15:16:59 +0100
Message-Id: <91F0E749-0AC9-490A-BF76-820B94AFD411@employees.org>
References: <CEA69EED.900C2%ian.farrer@telekom.de>
To: "<ian.farrer@telekom.de> Farrer" <ian.farrer@telekom.de>
X-Mailer: Apple Mail (2.1822)
Cc: Ian Farrer <ifarrer@me.com>, draft-ietf-softwire-map-dhcp@tools.ietf.org, draft-ietf-dhc-dhcpv4-over-dhcpv6@tools.ietf.org, Softwires <softwires@ietf.org>, "dhcwg@ietf.org WG" <dhcwg@ietf.org>, "Wojciech Dec \(wdec\)" <wdec@cisco.com>
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:17:19 -0000

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