Re: [Softwires] Working group last call for draft-ietf-softwire-map-dhcp-07

Ole Troan <> Tue, 22 April 2014 13:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B18F1A0418 for <>; Tue, 22 Apr 2014 06:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.773
X-Spam-Status: No, score=-9.773 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.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TTwrcGHBJ35N for <>; Tue, 22 Apr 2014 06:06:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8C0611A020E for <>; Tue, 22 Apr 2014 06:06:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2572; q=dns/txt; s=iport; t=1398172001; x=1399381601; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=ZU/F9YuN4rgbVdpkI2XQJSozjWQQo2721ZA1MkAWPKM=; b=RMJU6CnVRndRDGbWYkdUPIZXUEPrYZ9h/wDTf8W1tURVT8ea4KspuN4s rWcdeFFbtyWTcoYZDpjN7MHBA4CiG37fx8oYhEbTAq7EyRa0wk0x4SnPn 4HVulicPRWB/c7/Wn5h/wpcgaVfHFzvjAl4zKt/zEY58kdihxhId7+C4n U=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.97,904,1389744000"; d="asc'?scan'208"; a="23928805"
Received: from ([]) by with ESMTP; 22 Apr 2014 13:06:40 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s3MD6dpB001482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Apr 2014 13:06:39 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_388E2E22-6689-4338-9FEA-816C1F37EB9D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ole Troan <>
In-Reply-To: <>
Date: Tue, 22 Apr 2014 15:07:10 +0200
Message-Id: <>
References: <> <>
To: Ian Farrer <>
X-Mailer: Apple Mail (2.1874)
Cc: Softwires WG <>, Yong Cui <>
Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-dhcp-07
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: Tue, 22 Apr 2014 13:07:04 -0000


> Currently, OPTION_S46_BR is limited to only be a sub-option carried within one of the S46 container options (described in section 3). However, other softwire provisioning mechanisms also need this configuration parameter, for example if you’re using DHCPv4 over DHCPv6.
> To re-use this parameter for DHCPv4o6 as it stands within the container would be very messy: A client needs to indicate its support for OPTION_S46_CONT_LW and DHCPv4o6 in the ORO, it then gets the parameter from one end of the softwire from DHCPv6 and the other end of the softwire using DHCPv4o6.

is the complete flow and options of how LW46 is provisioned with DHCPv4 described anywhere? half and half with DHCPv6 options and DHCPv4 options?

> Two solutions spring to mind:
> 1, Loosen the restriction in this draft so that OPTION_S46_BR can be used outside of one of the S46 Containers. This would then allow the possibility of the client including the option within an ORO option in the DHCPV4-QUERY/RESPONSE messages in the DHCPv4o6 message flow.
> 2, Keep the restriction in the map-dhcp draft and create a new option for provisioning the BR specifically for softwire clients using DHCPv4o6.
> The outcome of this may also have a knock on effect of what’s going to be possible if we ever resurrect the unified-cpe work.

if you need the OPTION_S46_BR option in particular, perhaps something else as well? I think the cleanest would be to specify a new container option for this "mode".