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

Ian Farrer <> Thu, 17 April 2014 15:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DC4BE1A0101 for <>; Thu, 17 Apr 2014 08:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3kAQC-RpHt4s for <>; Thu, 17 Apr 2014 08:11:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A5CF11A0138 for <>; Thu, 17 Apr 2014 08:11:04 -0700 (PDT)
Received: from ians-mbp.lan ([]) by (mrgmx002) with ESMTPSA (Nemesis) id 0MfVU3-1WKWG6381L-00P7tp; Thu, 17 Apr 2014 17:10:53 +0200
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ian Farrer <>
In-Reply-To: <>
Date: Thu, 17 Apr 2014 17:10:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Suresh Krishnan <>
X-Mailer: Apple Mail (2.1874)
X-Provags-ID: V03:K0:73NQ969ovtuexcu28PRx9AllZ7nmpkWaKG/QGodd+0z7PkAYPEv nNN5DNbAXoqBzFX+h8KtejRNNqy9dznzb3JMx1ikCVzU84pNVyz+QguJWyDIju68G1w7k9n JmAC57ewL+qEFcOyMzFEg8XgnkV3sj8aLDvbpbDrWQemMk4LKB0DGpWscUpxZdZsYEv8HoY 6mU0/P/pUJS9k2aIxJsng==
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: Thu, 17 Apr 2014 15:11:11 -0000


I have one question about the draft as it stands at the moment:

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.

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.

And two comments on section 4.5:
This section is entirely MAP specific, although the sub-option is generally applicable to all of the containers.
The default value of 6 for the ‘offset’ field either shouldn’t be specified here, or should have ‘6’ for MAP and ‘0’ for lw4o6.


On 7 Apr 2014, at 06:37, Suresh Krishnan <> wrote:

> Hi all,
>  This message starts a two week softwire working group last call on advancing the draft about the DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients as a Standards Track RFC. The authors believe that this version has addressed all the issues raised on the document. The latest version of the draft is available at
> Substantive comments and statements of support/opposition for advancing this document should be directed to the mailing list. Editorial suggestions can be sent directly to the authors. This last call will conclude on April 21 2014.
> Regards,
> Suresh & Yong
> _______________________________________________
> Softwires mailing list