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

"Wojciech Dec (wdec)" <> Mon, 11 November 2013 12:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC27921E80EC; Mon, 11 Nov 2013 04:11:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9yCMzp3tD7f0; Mon, 11 Nov 2013 04:11:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B374121E80A6; Mon, 11 Nov 2013 04:11:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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-AV: E=Sophos;i="4.93,677,1378857600"; d="scan'208";a="283249596"
Received: from ([]) by with ESMTP; 11 Nov 2013 12:11:42 +0000
Received: from ( []) by (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 ([]) by ([fe80::200:5efe:]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 06:11:41 -0600
From: "Wojciech Dec (wdec)" <>
To: "" <>, "" <>, "" <>
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
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [dhcwg] ***CAUTION_Invalid_Signature*** Re: Alignment between softwire-map-dhcp and dhc-dhcpv4-over-dhcpv6 drafts
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Nov 2013 12:11:54 -0000


On 11/11/2013 12:54, "" <> wrote:

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

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

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

I would propose that only the above paragraph be added, restated as:

Additional DHCPv4 options are not transported natively in DHCPv6. If these
are required for client provisioning, then DHCPINFORM transported in
DHCPv4 over DHCPv6 [ietf-dhc-dhcpv4-over-dhcpv6] should be used.


>Does that cover it?
>On 08/11/2013 00:24, "Ole Troan" <> wrote:
>>> 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?