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

<> Tue, 12 February 2019 14:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0022912D827 for <>; Tue, 12 Feb 2019 06:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BhPjInB5NPYc for <>; Tue, 12 Feb 2019 06:07:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AB301288BD for <>; Tue, 12 Feb 2019 06:07:52 -0800 (PST)
Received: from (unknown [xx.xx.xx.65]) by (ESMTP service) with ESMTP id 43zPck2Sq2z4wR4; Tue, 12 Feb 2019 15:07:50 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by (ESMTP service) with ESMTP id 43zPcj4vMkzDq7R; Tue, 12 Feb 2019 15:07:49 +0100 (CET)
Received: from OPEXCAUBM6F.corporate.adroot.infra.ftgroup ( by OPEXCLILM32.corporate.adroot.infra.ftgroup ( with Microsoft SMTP Server (TLS) id 14.3.435.0; Tue, 12 Feb 2019 15:07:49 +0100
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6F.corporate.adroot.infra.ftgroup ([fe80::c489:b768:686a:545b%23]) with mapi id 14.03.0435.000; Tue, 12 Feb 2019 15:07:49 +0100
From: <>
To: Yu Tianpeng <>
CC: "" <>
Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt
Thread-Index: AQHUwton9b6WuO6R4EagdxdNShVyc6XcMgVA
Date: Tue, 12 Feb 2019 14:07:49 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA1DCED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <> <> <787AE7BB302AE849A7480A190F8B93302EA1D478@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA1DCEDOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Feb 2019 14:08:02 -0000

Hi Yu,

The answer to your question is: Yes.


De : Yu Tianpeng []
Envoyé : mardi 12 février 2019 14:52
Cc :
Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt

Thanks a lot Mohamed.
It answers my questions.
Inline below.
On Mon, 11 Feb 2019, 12:42 <<> wrote:
Hi Yu,

Please see inline.


De : Softwires [<>] De la part de Yu Tianpeng
Envoyé : lundi 11 février 2019 12:27
À :<>
Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-map-radius-19.txt

Dear authors,
Thanks for the new version.
I had a quick read on latest version. I find some nits and also some questions along the way as we meet a scenario when deploying MAP that need s46 radius attributes.

Section 7.1 should be referring section 3.x not 4.x
[Med] Thank you for catching the bug in Section 7.1.

1. How is the status of this document? This draft has last called long time ago, but still not standard yet. What is the reason? Any plans to move further? As I mentioned we meet requirement when deploying map, we may need to make a decision if we follow this draft or define a vendor specific one.

[Med] The document passed the WGLC + addressed the reviews from radext wg. We do think that the document is ready to be sent to the IESG.
 [Tim] glad to know. Thanks
2. This draft seems haven't consider conflicts between subscribers. E.g.  EA length conflict between subscribers with in one MAP domain? And EA length from radius conflict with BNG within same MAP domain?
As this draft enables the capability to maintain MAP rule logic in radius, conflict mechanisn should be investigated in my POV.

[Med] Which conflict mechanism do you have in mind?

I’m afraid this is deployment and implementation-specific. FWIW, the draft includes the following to warrant that some consistency checks is needed:

   In some deployments, the DHCP server may use the Accounting-Request
   to report to a AAA server the softwire configuration returned to a
   requesting host.  It is the responsibility of the DHCP server to
   ensure the consistency of the configuration provided to requesting
 [Tim] yes, it solves one of the scenario I mentioned.
I believe if dhcp server use access request to get s46 info from AAA, then AAA server is response to enrue the consistency I suppose. Am I right?

Appreciate your feedback.
Thanks in advance
On Mon, 11 Feb 2019, 08:26 <<> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Softwires WG of the IETF.

        Title           : RADIUS Attributes for Address plus Port (A+P) based Softwire Mechanisms
        Authors         : Sheng Jiang
                          Yu Fu
                          Bing Liu
                          Peter Deacon
                          Chongfeng Xie
                          Tianxiang Li
                          Mohamed Boucadair
        Filename        : draft-ietf-softwire-map-radius-19.txt
        Pages           : 39
        Date            : 2019-02-11

   IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity
   services over IPv6 native networks during the IPv4/IPv6 co-existence
   period.  DHCPv6 options have been defined for configuring clients for
   Lightweight 4over6, Mapping of Address and Port with Encapsulation,
   and Mapping of Address and Port using Translation unicast softwire
   mechanisms, and also multicast softwires.  However, in many networks,
   configuration information is stored in an Authentication,
   Authorization, and Accounting server which utilizes the RADIUS
   protocol to provide centralized management for users.  When a new
   transition mechanism is developed, new RADIUS attributes need to be
   defined correspondingly.

   This document defines new RADIUS attributes to carry Address plus
   Port based softwire configuration parameters from an Authentication,
   Authorization, and Accounting server to a Broadband Network Gateway.
   Both unicast and multicast attributes are covered.

The IETF datatracker status page for this draft is:

There are also htmlized versions 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<>