Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-06.txt

Ian Farrer <> Fri, 01 July 2016 13:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26F4212D507; Fri, 1 Jul 2016 06:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vkYsO8ieDa3U; Fri, 1 Jul 2016 06:02:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F419912D5C3; Fri, 1 Jul 2016 06:02:23 -0700 (PDT)
Received: from ians-mbp.lan ([]) by (mrgmx001) with ESMTPSA (Nemesis) id 0MTBLi-1aqp5l02QI-00S5hr; Fri, 01 Jul 2016 15:02:15 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_9E0BD5AA-C72F-4D14-9896-0EDA198DB7B0"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ian Farrer <>
In-Reply-To: <008301d1c87f$4c985af0$e5c910d0$@cn>
Date: Fri, 1 Jul 2016 15:02:14 +0200
Message-Id: <>
References: <008301d1c87f$4c985af0$e5c910d0$@cn>
To: Yu Fu <>,
X-Mailer: Apple Mail (2.3124)
X-Provags-ID: V03:K0:ku5AihoDztVsAFP3rG00xw16nM9jktdRV9YDQveA+tMvjcO3B4M RTZF8rOjzRUeyyi+jYJyC/6fzpSZftU1vVChkF45IDTC1/DVXxlxci/XgyoYRfWrc2540eH SCA4bKjZ+lqj+WSMwW4CqBxim6tcglvQg4aGIz8LAJhG9Rway+7bNGX6b02MxMAkMlm2oA+ 8XPukAC8+qOw70ssphxoA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:iF9Se5tK82c=:9C6VhJyMC3THp1Jx2+/OT+ GHG3Y1uw5LFtOFnOc7M4vuOZ0wfafPJdJuxbgkdjHCkhy9diiKeepPnHWaL4NuhOD4M7PRWxs KZKveVCmtZneU4PBntj1YuN5WdbwRyge6PxzkOw4Anv3V+RHmR28pFsYL/1bpcc+wlFWQRPMA ipua5OnsFgUy7N7sLWY2rjGyHuZlySXGz6xHBcnNhxPQTKGtmybPkXPWnL0ou0uqfvPnpsdP/ 2GGEAqfbKu7LP6dWVDKBpnnYUZgBsxNZlnM2f3ASKSa8BWQej2S+Dy8rfe7tnnWaVPBQ02tpD Za4BmWdDO0BOxNpC3vscXAGscNsH7wGeELTSYuNRaCW+exmWg12Zf/m5dTXKQ4/RNMfuKiIkN tIK8hULwIoWDVmJhQ5XA1pi/Cr0Qc5jDUfeojRP+bwbxqLP7gUFBd57WKxB2BAeBa/WFwQI0z yzP3EII1lfm06DBNLHjbDDTPVBPvUdRAwAbAQJD9YzalJg0QCq0mFhQLDFOvtSmrrc2Br3zsa nZVpeW1ltJjSeZvzfFWHPFXugHqMSPz/QByRfhZ+wuqaNPwH0WdGuD/JEqQwOpQeAjbLp60vL S/pl7PmBlWI3K1PMeFbYHSsgULzIr5rdEsI7Z1tZEXAwjmqkfzO4v7RxtSi560qSmew/sVeWz d4rIOlEbWdomiORBLJIlTWpW8jzaLBkOQ4xlC1pIkHR2MpQwZg7QlOK9atljpS5Q20yf6JYai 0gmz/l039g9/zTXHx3MO4fC9edj6tBCq0UUx4lmbH2lE3vlRv5k2XZLN6YQGntPv4qmrZg41S XHLEgS5
Archived-At: <>
Cc: softwires <>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-06.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Jul 2016 13:02:27 -0000


Thanks for making this update. Here is a review of this version.



The grammar/spelling and readability of the document throughout need to be checked and cleaned up.

The terms MAP and S46 are used interchangeably throughout the document. It would be clearer if the term ‘S46’ was used for the general case of referring to all mechanisms and MAP (or MAP-E/MAP-T as appropriate) is used specifically when referring to the MAP mechanisms.

Section 3

Figure 1 would be clearer if the different messages in fig 1 were numbered and the supporting text was structured as a numbered list relating to each of the messages.

Figure 1 and Figure 2 are essentially the same with the exception of the DHCP solicit/request messages being removed from Fig 2. The intended purpose (from the context) of fig. 2 is to illustrate how the process works without RADIUS authentication. Fig. 2 doesn’t show this. Either fig 2 should show what the differences are to Fig 1, or Fig 2 can be removed and Fig 1 can be referenced.

The idea of pre-configured, or caching of RADIUS learnt MAP (S46) configuration: In this situation, how is it possible to propagate updates to client provision made in the RADIUS server to the clients? As softwire mechanism rely on consistency between the BR configuration and client provisioning infrastructure, this makes it more likely that differences will occur which will relate to service outages. I’m also not clear on what the benefit of this caching is.

Section 4 

RFC7598 provides a table in Section 6 showing the valid combinations of options to be supplied for each softwire mechanism. A similar table for the corresponding RADIUS attributes would be useful.

Section 4.3.2
There MUST be at least one S46-BR Sub option…..
This is only true for MAP-E and lw4o6 provisioning. MAP-T requires the S46-DMR option.

The fields in the diagram and the descriptions below don’t match.

The table needs to be updated in line with the new attributes defined in this version.

Needs to be updated  in line with the new attributes defined in this version.

7. (personal opinion) - I’m not sure that I would define the operator’s ‘closed network’ is inherently safer than other network environments.

> On 17 Jun 2016, at 12:02, Yu Fu <> wrote:
> Hi all, 
> As I had a presentation on IETF 94 meeting for draft-ietf-softwire-map-radius-05, the softwire WG had a conclusion that this draft should have the radius configuration solutions for MAP-E, MAP-T, Lightweight4o6 all together in one draft as DHCP does. Please refer to the minutes of the IETF 94 meeting as below: 
> <>
> So we had a discussion with the authors of the draft-sun-softwire-lw4over6-radext-01. We have merged draft-ietf-softwire-map-radius-05 and draft-sun-softwire-lw4over6-radext-01 into draft-ietf-softwire-map-radius-06.
> Your comments are appreciated for us.
> Thanks 
> Yu
> -------------------------------------------
> Yu Fu
> <>
> -----Original Message-----
> From: [] On Behalf Of
> Sent: Friday, June 17, 2016 5:39 PM
> To:
> Cc:
> Subject: [Softwires] I-D Action: draft-ietf-softwire-map-radius-06.txt
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Softwires of the IETF.
>         Title           : RADIUS Attribute for MAP
>         Authors         : Sheng Jiang
>                           Yu Fu
>                           Bing Liu
>                           Peter Deacon
>                           Chongfeng Xie
>                           Tianxiang Li
>          Filename        : draft-ietf-softwire-map-radius-06.txt
>          Pages           : 20
>          Date            : 2016-06-17
> Abstract:
>    IPv4-over-IPv6 transition mechanisms provide both IPv4 and IPv6
>    connectivity services simultaneously during the IPv4/IPv6 co-existing
>    period.  The Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
>    options have been defined to configure Customer Edge (CE) in MAP-E,
>    MAP-T, and Lightweight 4over6.  However, in many networks, the
>    configuration information may be stored in Authentication
>    Authorization and Accounting (AAA) servers while user configuration
>    is mainly from Broadband Network Gateway (BNG) through DHCPv6
>    protocol.  This document defines a Remote Authentication Dial In User
>    Service (RADIUS) attribute that carries CE configuration information
>    from AAA server to BNG.
> The IETF datatracker status page for this draft is:
> <>
> There's also a htmlized version available at:
> <>
> A diff from the previous version is available at:
> <>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> <>
> _______________________________________________
> Softwires mailing list
> <>
> <>
> _______________________________________________
> Softwires mailing list
> <>
> <>