[radext] Shepherd review of draft-ietf-radext-ip-port-radius-06

<lionel.morand@orange.com> Tue, 01 March 2016 17:23 UTC

Return-Path: <lionel.morand@orange.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5B81B3023; Tue, 1 Mar 2016 09:23:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.299
X-Spam-Level:
X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D0p0unLwpkn; Tue, 1 Mar 2016 09:23:34 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909B81B3019; Tue, 1 Mar 2016 09:23:30 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id D04873B43B9; Tue, 1 Mar 2016 18:23:28 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.19]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id A3C494C072; Tue, 1 Mar 2016 18:23:28 +0100 (CET)
Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%19]) with mapi id 14.03.0279.002; Tue, 1 Mar 2016 18:23:28 +0100
From: lionel.morand@orange.com
To: "radext@ietf.org" <radext@ietf.org>
Thread-Topic: Shepherd review of draft-ietf-radext-ip-port-radius-06
Thread-Index: AdFz3tToJiztomTRTPeDnJJtYoXTSg==
Date: Tue, 01 Mar 2016 17:23:27 +0000
Message-ID: <20738_1456853008_56D5D010_20738_615_14_6B7134B31289DC4FAF731D844122B36E01DE61F7@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.8.153315
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/p0sP9Ha8UAmmjlYPwqugPJvSLh0>
Cc: Stefan Winter <stefan.winter@restena.lu>, Alan DeKok <aland@freeradius.org>, "draft-ietf-radext-ip-port-radius-ext.authors@ietf.org" <draft-ietf-radext-ip-port-radius-ext.authors@ietf.org>
Subject: [radext] Shepherd review of draft-ietf-radext-ip-port-radius-06
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Mar 2016 17:23:38 -0000

Hi,

Acting as Shepherd of the document draft-ietf-radext-ip-port-radius-ext-06, I have the following comments on the draft.
Most of the comments can be simply addressed with a new version of the draft before IESG submission.

The main comments to take into consideration are the following:
- Attributes can be pre-allocate as Extended-Type-1  attributes
- Sub-attribute type must be defined by encapsulating attributes. There is therefore no unique type. See comment on IANA section.

Please see hereafter further details on the changes .

Regards,

Lionel

***************

Abstract

   This document defines three new RADIUS attributes.  For devices that
   implementing IP port ranges, these attributes are used to communicate
   with a RADIUS server in order to configure and report TCP/UDP ports
   and ICMP identifiers, as well as mapping behavior for specific hosts.
   This mechanism can be used in various deployment scenarios such as
   CGN (Carrier Grade NAT), NAT64, Provider WLAN Gateway, etc.

Usually, we need to limit the use of acronym in the abstract when not required.
A proposal would be:

s/CGN (Carrier Grade NAT)/Carrier-Grade NAT
s/NAT64/IPv6/IPv4 gateway

******

1.  Introduction

   "In a broadband network, customer information is usually stored on a
   RADIUS server [RFC2865] and at the time when a user initiates an IP
   connection request, the RADIUS server will populate the user's
   configuration information to the Network Access Server (NAS), which
   is usually co-located with the Border Network Gateway (BNG), after
   the connection request is granted." 


In a broadband network --> In broadband access network
Border Network Gateway (BNG) --> Broadband Network Gateway (BNG)

comment: In Broadband access network, the BNG acts as a NAS ( not collocated with)

Porposed modificiation:

   In a broadband network, customer information is usually stored on a
   RADIUS server [RFC2865] and at the time when a user initiates an IP
   connection request and this request is authorized, the RADIUS server 
   will populate the user's configuration information to the Network 
   Access Server (NAS), which is often referred to as a Broadband 
   Network Gateway (BNG) in broadband access networks. 

Comment: check the consistency all acrossthe document regarding NAS/BNG

*******

   "The Carrier Grade NAT (CGN)
   function may also be implemented on the BNG, and therefore the CGN
   TCP/UDP port (or ICMP identifier) mapping(s) behavior(s) can be
   configured on the RADIUS server as part of the user profile, and
   populated to the NAS in the same manner."

Proposed modification:

   The Carrier-Grade NAT (CGN)
   function may also be implemented on the BNG. In such a case, the CGN
   TCP/UDP port (or ICMP identifier) mapping(s) behavior(s) can be
   part of the configuration information sent from the RADIUS server to the
   NAS/BNG.

*******

   "In addition, during the
   operation, the CGN can also convey port/identifier mapping behavior
   specific to a user to the RADIUS server, as part of the normal RADIUS
   accounting process."

Comment: the NAS/BNG is ont that exhanges withthe server, not the CGN.

Proposed modification:


   "The NAS/BNG may also report to the RADIUS Server the port/identifier mapping 
   behavior applied by the CGN to a user session to the RADIUS server, as part of the 
   accounting information sent from the NAS/BNG to a RADIUS server."

*******

   "The CGN device that communicates with a RADIUS server using RADIUS
   extensions defined in this document may perform NAT44 [RFC3022],
   NAT64 [RFC6146], or Dual-Stack Lite AFTR [RFC6333] function."

Comment: the CGN does not communicate with the RADIUS server. And not sure that it is needed to speak about that here.

proposed modification:

    The CGN may perform NAT44 [RFC3022], NAT64 [RFC6146], or Dual-Stack 
    Lite AFTR [RFC6333] function.

comment: difficult to see the link between this text and what is before and after. Is it required here?

*******

   "For the CGN case, when IP packets traverse a CGN device, it would
   perform TCP/UDP source port mapping or ICMP identifier mapping as
   required."

Proposed simplification:

   When IP packets traverse the CGN, it performs TCP/UDP source port 
   mapping or ICMP identifier mapping as required.
 
********

   "This is required for identification purposes (see TR-146 [TR-146] for
   example)."

"for more details" would be more appropriate.


********


   "1.  IP-Port-Limit: This attribute may be carried in RADIUS Acces-
       Accept, Access-Request, Accounting-Request or CoA-Request packet.
       The purpose of this attribute is to limit the total number of
       TCP/UDP ports and/or ICMP identifiers that an IP subscriber can
       use, associated with one or more IPv4 addresses."

s/RADIUS Acces-Accept/RADIUS Access-Accept

s/IP subscriber/user ???

********

   "2.  IP-Port-Range: This attribute may be carried in RADIUS
       Accounting-Request packet.  The purpose of this attribute is to
       report by an address sharing device (e.g., a CGN) to the RADIUS
       server the range of TCP/UDP ports and/or ICMP identifiers that
       have been allocated or deallocated associated with a given IPv4
       address for a subscriber."

s/subscriber/user ???

*******

   "3.  IP-Port-Forwarding-Map: This attribute may be carried in RADIUS
       Access-Accept, Access-Request, Accounting-Request or CoA-Request
       packet.  The purpose of this attribute is to specify how a TCP/
       UDP port (or an ICMP identifier) mapping to another TCP/UDP port
       (or an ICMP identifier), and each is associated with its
       respective IPv4 address."


the last sentence is not clear.

Proposed change (to check/clarify):

       The purpose of this attribute is to specify how a TCP/
       UDP port (or an ICMP identifier) is mapped to another TCP/UDP port
       (or an ICMP identifier), and how each mapping is associated with its
       respective IPv4 address.

********

   "This document leverages the protocol defined in [RFC7012] by
   proposing a mapping between type field of RADIUS TLV and Element ID
   of IPFIX.  It also proposes a few new IPFIX Elements as required by
   this document (see Section 3)."

The protocol is defined in RFC7011. The RFC7012 defines the information model.
What does "leverage" mean here?
And you should explain why the link between RADIUS and IPFIX is required.

Here is a proposal:

   IPFIX Elements [RFC7011] can be used for IP flow identification and 
   representation over RADIUS. This document provides a mapping between
   RADIUS TLV and IPFIX ElementIDs. As a consequence, new IPFIX Elements
   are defined by this document (see Section 3).

*******

   "This document was constructed using the [RFC2629]."
can be removed.

******

2.  Terminology

   This document makes use if the following terms:

s/makes use if/makes use of

******

   o  IP Port Range: specifies a set of contiguous IP ports, indicated
      by the smallest numerical number and the largest numerical number,
      inclusively.

s/smallest/lowest
s/largest/highest

******


   o  Internal IP Address: refers to the IP address that is used as a
      source IP address in an outbound IP packet sent towards a device
      supporting port ranges in the internal realm.  In the IPv4 case,
      it is typically a private address [RFC1918].

When defining "Internal IP Address", is the last sentence really required?
Otherwise, you would have to describe the otehr possible cases, that it is not needed at this stage.


******

   o  External IP Address: refers to the IP address that is used as a
      source IP address in an outbound IP packet after traversing a
      device supporting port ranges in the external realm.  In the IPv4
      case, it is typically a global routable IP address.

same comment

******

   o  External realm: refers to the networking segment where IPv4 public
      addresses are used in respective of the device supporting port
      ranges.

s/where IPv4 public addresses/where external IP addresses

   o  Internal realm: refers to the networking segment that is behind a
      device supporting port ranges and where IPv4 private addresses are
      used.

S/where IPv4 private addresses/where internal IP addresses

*******

   Note the terms "internal IP address", "internal port", "internal
   realm", "external IP address", "external port", "external realm", and
   "mapping" and their semantics are the same as in [RFC6887], and
   [RFC6888].

proposed change (for clarity):

   Note the definitions of "internal IP address", "internal port", "internal
   realm", "external IP address", "external port", "external realm", and
   "mapping" are the same as defined in Port Control Protocol (PCP) [RFC6887], and
   the Common Requirements for Carrier-Grade NATs (CGNs)[RFC6888].


*****

3.  Extensions of RADIUS Attributes and TLVs

 [...]

I propose to add here the following text.

   In all the figures describing the RADIUS attribute and TLV formats in the 
   following sections, the fields are transmitted from left to right.

With this text in the introduciton, no need to repeat it in all the other sections.
And it was actually missing in some of them.

*****

3.1.1.  IP-Port-Limit Attribute

   This attribute is RADIUS Extended-Type, and contains a set of
   embedded TLVs defined in Section 3.2.1 (IP-Port-Type TLV),
   Section 3.2.2 (IP-Port-Limit TLV), and Section 3.2.3 (IP-Port-Ext-
   IPv4-Addr TLV).

proposed change:

   This attribute is of type "TLV" as defined in the 
   RADIUS Protocol Extensions [RFC6929]. It contains the following sub-attributes:
   - an IP-Port-Type TLV (see section 3.2.1), 
   - an IP-Port-Limit TLV (see Section 3.2.2),
   - an optional IP-Port-Ext-IPv4-Addr TLV (see section 3.2.3).


*****

   Note that when IP-Port-Ext-IPv4-Addr TLV is not included as part of
   the IP-Port-Limit Attribute, the port limit is applied to all the
   IPv4 addresses managed by the port device, e.g., a CGN or NAT64
   device.

s/the port limit is applied to/the port limit applies to

*****

   The IP-Port-Limit Attribute MAY appear in an Access-Accept packet.
   It MAY also appear in an Access-Request packet as a hint by the
   device supporting port ranges, which is co-allocated with the NAS, to
   the RADIUS server as a preference, although the server is not
   required to honor such a hint.

Proposed change:

   It MAY also appear in an Access-Request packet as a preferred maximum 
   number of IP ports indicated by the device supporting port ranges 
   co-allocated with the NAS e.g. a CGN or NAT64. However, the RADIUS 
   server is not required to honor such a preference.

*****

   The IP-Port-Limit Attribute MUST NOT appear in any other RADIUS
   packets.

s/any other RADIUS packets/any other RADIUS packet

*******

   Type:

      TBA1.

proposed change:

   Type:

      241 (To be confirmed by IANA).

*******

   IP-Port-Limit attribute is associated with the following identifier:
   Type(TBA1).Extended-Type(TBA2).[IP-Port-Limit TLV (TBA6),IP-Port-Type
   TLV(TBA5), {IP-Port-Ext-IPv4-Addr TLV(TBA7)}].

What is defined is a new type space. therefore the text should be only:

  IP-Port-Limit attribute is associated with the following identifier:
  241.TBA2.

******

3.1.2.  IP-Port-Range Attribute

   This attribute is RADIUS Extended-Type, and contains a set of
   embedded TLVs defined in Section 3.2.1 (IP-Port-Type TLV), Section
   3.2.9 (IP-Port-Range-Start TLV), Section 3.2.10 (IP-Port-Range-End
   TLV), Section 3.2.8 (IP-Port-Alloc TLV), Section 3.2.3 (IP-Port-Ext-
   IPv4-Addr TLV), and Section 3.2.11 (IP-Port-Local-Id TLV).

Proposed change:

   This attribute is of type "TLV" as defined in the 
   RADIUS Protocol Extensions [RFC6929]. It contains the following sub-attributes:
   - an IP-Port-Type TLV (see section 3.2.1),
   - an IP-Port-Range-Start TLV (see section 3.2.9),
   - an IP-Port-Range-End TLV (see section 3.2.10),
   - an IP-Port-Alloc TLV (see section 3.2.8),
   - an optional IP-Port-Ext-IPv4-Addr TLV (see section 3.2.3),
   - an optonal IP-Port-Local-Id TLV (see section 3.2.11).

******

   This attribute contains a range of contiguous IP ports of a specific
   port type and associated with an IPv4 address that are either
   allocated or deallocated by a device for a given subscriber, and the
   information is intended to send to RADIUS server.

s/is intended to send/is intended to be sent

*******

   The IP-Port-Range Attribute MUST NOT appear in any other RADIUS
   packets.

s/any other RADIUS packets/any other RADIUS packet

*******

   Type:

      TBA1.

Proposed change:

   Type:

      241 (To be confirmed by IANA).


*******

   The IP-Port-Range attribute is associated with the following
   identifier: Type(TBA1).Extended-Type(TBA3).[IP-Port-Alloc TLV
   (TBA12), IP-Port-Type TLV(TBA5), {IP-Port-Range-Start TLV(TBA13), IP-
   Port-Range-End TLV(TBA14)}, {IP-Port-Ext-IPv4-Addr TLV (TBA7)}, {IP-
   Port-Local-Id TLV (TBA15)}].

same comment as baove regarding type space:

   The IP-Port-Range attribute is associated with the following
   identifier: 241.TBA3.

******

3.1.3.  IP-Port-Forwarding-Map Attribute

   This attribute is RADIUS Extended-Type, and contains a set of
   embedded TLVs defined in Section 3.2.1(IP-Port-Type TLV), Section
   3.2.6(IP-Port-Int-Port TLV), Section 3.2.7(IP-Port-Ext-Port TLV),
   Section 3.2.4(IP-Port-Int-IPv4-Addr TLV) or Section 3.2.5(IP-Port-
   Int-IPv6-Addr TLV), Section 3.2.11(IP-Port-Local-Id TLV) and
   Section 3.2.3 (IP-Port-Ext-IP-Addr TLV).

"IP-Port-Ext-IP-Addr TLV" should be "IP-Port-Ext-IPv4-Addr TLV" if I'm correct

Proposed change:

   This attribute is of type "TLV" as defined in the 
   RADIUS Protocol Extensions [RFC6929]. It contains the following sub-attributes:
   - an IP-Port-Type TLV (see section 3.2.1),
   - an IP-Port-Int-Port TLV (see section 3.2.6),
   - an IP-Port-Ext-Port TLV (see section 3.2.7),
   - either an IP-Port-Int-IPv4-Addr TLV (see section 3.2.4) or an 
     IP-Port-Local-Id TLV (see section 3.2.11), 
   - either an IP-Port-Int-IPv6-Addr TLV (see section 3.2.5) or an 
     an IP-Port-Local-Id TLV (see section 3.2.11),
   - an IP-Port-Ext-IPv4-Addr TLV (see section 3.2.3).

*******

   The attribute MUST NOT appear in any other RADIUS packet.


s/The attribute MUST NOT/The IP-Port-Forwarding-Map Attribute

*******

   Type:

      TBA1.

Proposed change:

   Type:

      241 (To be confirmed by IANA).

********

   The IP-Port-Forwarding-Map attribute is associated with the following
   identifier: Type(TBA1).Extended-Type(TBA4).  [IP-Port-Int-Port
   TLV(TBA10), IP-Port-Ext-Port TLV(TBA11), IP-Port-Type TLV(TBA5), {IP-
   Port-Int-IPv4-Addr TLV(TBA8) | IP-Port-Int-IPv6-Addr TLV(TBA9)}, {IP-
   Port-Ext-IPv4-Addr TLV(TBA7)}].

same comment as baove regarding type space:

   The IP-Port-Forwarding-Map attribute is associated with the following
   identifier: 241.TBA4.

*******

3.2.1.  IP-Port-Type TLV

   This TLV (Figure 4) uses the format defined in [RFC6929].  Its Type
   field contains a value that uniquely refers to IPFIX Element
   transportType (TBAx1), and its Value field contains IPFIX Element
   transportType, which indicates the type of IP transport type as
   follows:

s/Its Type field/Its "Type" field
s/its Value field/its "Value" field
s/refers to IPFIX Element transportType (TBAx1)/refers to IPFIX Information Element "transportType" (TBAx1)
s/contains IPFIX Element transportType/contains the values defined for the IPFIX Information Element "transportType"

comment: the same applies for the TLV defined in this document. (section 3.2.1 to 3.2.11) 

s/indicates the type of IP transport type/indicates the type of IP transport

******

Just before figure 4, Add:

   IP-Port-Type TLV is included as part of the IP-Port-
   Limit Attribute (refer to Section 3.1.1), IP-Port-Range Attribute
   (refer to Section 3.1.2), and IP-Port-Forwarding-Map Attribute (refer
   to Section 3.1.3).


******
   Type:

      TBA5:This uniquely refers to IPFIX Element ID TBA0.

proposed change:

   Type:

      The value depends on the encapsulating attribute (see IANA section). This Must uniquely refer to IPFIX ElementID TBA0.

comment: same comment for all the TLV

******

   transportType:

      Integer.  This field contains the data (unsigned8) of
      transportType (TBX1) defined in IPFIX, right justified, and the
      unused bits in this field must be set to zero.

must be --> MUST be ?

*****

3.2.2.  IP-Port-Limit TLV

   This TLV (Figure 5) uses the format defined in [RFC6929].  Its Type
   field contains a value that uniquely refers to IPFIX Element
   natTransportLimit (TBAx2), and its Value field contains IPFIX Element
   natTransportLimit, which indicates the maximum number of ports of a
   specified IP-Port-Type and associated with a given IPv4 address
   assigned to a subscriber.

Should the last sentence be reversed?

"...which indicates the maximum number of ports for a given IPv4 address assigned
to a subscriber for a specified IP-Port-Type."


******

Just before figure 5, Add:

   IP-Port-Limit TLV is included as part of the IP-Port-
   Limit Attribute (refer to Section 3.1.1).


******


   natTransportLimit:

      Integer.  This field contains the data (unsigned16) of
      natTransportLimit (TBX2) defined in IPFIX, right justified, and
      the unused bits in this field must be set to zero.

must be --> MUST be?

*****

3.2.3.  IP-Port-Ext-IPv4-Addr TLV

   [...]

   IP-Port-Ext-IPv4-Addr TLV can be included as part of the IP-Port-
   Limit Attribute (refer to Section 3.1.1), IP-Port-Range Attribute
   (refer to Section 3.1.2), and IP-Port-Forwarding-Map Attribute (refer
   to Section 3.1.3).

Can --> MAY as it refers to a normative optionality.

*****

3.2.4.  IP-Port-Int-IPv4-Addr TLV

   [...]

   IP-Port-Int-IPv4-Addr TLV can be included as part of the IP-Port-
   Forwarding-Map Attribute (refer to Section 3.1.3).

Can --> MAY as it refers to a normative optionality.

*****

3.2.5.  IP-Port-Int-IPv6-Addr TLV

   [...].

   IP-Port-Int-IPv6-Addr TLV can be included as part of the IP-Port-
   Forwarding-Map Attribute (refer to Section 3.1.3).

Can --> MAY as it refers to a normative optionality.

*****

3.2.11.  IP-Port-Local-Id TLV

   [...]

   IP-Port-Local-Id TLV can be included as part of the IP-Port-Range
   Attribute (refer to Section 3.1.2) and IP-Port-Forwarding-Map
   Attribute (refer to Section 3.1.3).

Can --> MAY as it refers to a normative optionality.

*****

4.1.  Managing CGN Port Behavior using RADIUS

   In a broadband network, customer information is usually stored on a
   RADIUS server, and the BNG hosts the NAS. 

s/BNG hosts the NAS/BNG acts as a NAS

*****

   A CGN function in a broadband network would most likely reside on a
   BNG.  

s/likely reside/likely collocated

*****

4.1.1.  Configure IP Port Limit for a User

   In the face of IPv4 address shortage, there are currently proposals
   to multiplex multiple subscribers' connections over a smaller number
   of shared IPv4 addresses, such as Carrier Grade NAT [RFC6888], Dual-
   Stack Lite [RFC6333], NAT64 [RFC6146], etc.  As a result, a single
   IPv4 public address may be shared by hundreds or even thousands of
   subscribers.  As indicated in [RFC6269], it is therefore necessary to
   impose limits on the total number of ports available to an individual
   subscriber to ensure that the shared resource, i.e., the IPv4 address
   remains available in some capacity to all the subscribers using it,
   and port limiting is also documented in [RFC6888] as a requirement.

s/resource, i.e., the IPv4 address/resource, i.e., the IPv4 address,

s/using it, and port limiting is also documented in [RFC6888] as a requirement/
using it. The support of IP port limit is also documented in [RFC6888] as a requirement for CGN.

*****

   The per-subscriber based IP port limit is configured on a RADIUS
   server, along with other user information such as credentials.  The
   value of these IP port limit is based on service agreement and its
   specification is out of the scope of this document.

s/The value of these IP port limit/he value of this IP port limit

*****

   When a subscriber signs in to the Internet service successfully, the
   IP port limit for the subscriber is passed to the BNG based NAS,
   where CGN also locates, using a new RADIUS attribute called IP-Port-
   Limit (defined in Section 3.1.1), along with other configuration
   parameters.

proposed change:

   When a subscriber signs in to the Internet service successfully, the
   IP port limit for the subscriber is passed by the RADIUS server to the BNG,
   acting as a NAS and collocated with the CGN, using a new RADIUS attribute 
   called IP-Port-Limit (defined in Section 3.1.1), along with other configuration
   parameters.

******

Figure 17/18/19: use NAT44 or only NAT in the fugures for consistency


*****

5.  Table of Attributes

   This document proposes three new RADIUS attributes and their formats
   are as follows:

   o  IP-Port-Limit: TBA1.TBA2.[TBA6, TBA5, {TBA7}]

   o  IP-Port-Range: TBA1.TBA3.[TBA12, TBA5, {TBA13, TBA14}, {TBA7},
      {TBA15}].

   o  IP-Port-Forwarding-Map: TBA1.TBA4.[TBA10, TBA11, TBA5, {TBA8 |
      TBA9}, {TBA7}]

proposed change(see IANA section):

5.  Table of Attributes

   This document proposes three new RADIUS attributes and their formats
   are as follows:

   o  IP-Port-Limit: 241.TBA2

   o  IP-Port-Range: 241.TBA3

   o  IP-Port-Forwarding-Map: 241.TBA4

Note to IANA: it is assumed that Extended-Type-1 "241" will be used for theses attributes

********


6.  Security Considerations

   This document does not introduce any security issue than what has
   been identified in [RFC2865].

proposed change:

   This document does not introduce any security issue other than the 
   ones already identified in RADIUS [RFC2865].

*******

7.1.  IANA Considerations on New IPFIX Elements

s/IPFIX Elements/IPFIX Information Elements

********

   The following are code point assignments for new IPFIX Elements as
   requested by this document:

s/for new IPFIX Elements/for new IPFIX Information Elements

****

   o  transportType (refer to Section 3.2.1): The identifier of this
      IPFIX Element is TBAx1.  The data type of this IPFIX Element is
      unsigned8, and the Element's value indicates TCP/UDP ports and
      ICMP Identifiers (1), TCP/UDP ports (2), TCP ports (3), UDP ports
      (4) or ICMP identifiers (5).

s/this IPFIX Element/this IPFIX Information Element 

*****

   o  natTransportLimit (refer to Section 3.2.2): The identifier of this
      IPFIX Element is TBAx2.  The data type of this IPFIX Element is
      unsigned16, and the Element's value is the max number of IP
      transport ports to be assigned to an end user associated with one
      or more IPv4 addresses.

s/this IPFIX Element/this IPFIX Information Element 

*****

   o  localID (refer to Section 3.2.11): The identifier of this IPFIX
      Element is TBAx3.  The data type of this IPFIX Element is string,
      and the Element's value is an IPv4 or IPv6 address, a MAC address,
      a VLAN ID, etc.

s/this IPFIX Element/this IPFIX Information Element 

******

Proposed change for IANA (see below for nested TLVs):

7.2.  IANA Considerations on New RADIUS Attributes

   The authors request that Attribute Types and Attribute Values defined
   in this document be registered by the Internet Assigned Numbers
   Authority (IANA) from the RADIUS namespaces as described in the "IANA
   Considerations" section of [RFC3575], in accordance with BCP 26
   [RFC5226].  For RADIUS packets, attributes and registries created by
   this document IANA is requested to place them at
   http://www.iana.org/assignments/radius-types.

   In particular, this document defines three new RADIUS attributes,
   entitled "IP-Port-Limit" (see Section 3.1.1), "IP-Port-Range" 
   (see Section 3.1.2) and "IP-Port-Forwarding-Map" (see Section 3.1.3),
   with assigned values of 241.TBD2, 241.TBD3 and 241.TBD4 from the 
   Short Extended Space of [RFC6929]:


   Type       Name                   Meaning
   ----       ----                   -------
   241.TBD2   IP-Port-Limit          see Section 3.1.1
   241.TBD3   IP-Port-Range          see Section 3.1.2
   241.TBD4   IP-Port-Forwarding-Map see Section 3.1.3


******

Comment: The TLVs are defined within a given extended-Type attribute space.

proposed modification:

7.3.  IANA Considerations on New RADIUS Nested Attributes

   This specification requests allocation of the following TLVs
   within the attribute IP-Port-Limit 241.TBD2:

   Type            Name                  Meaning
   ----            ----                  -------
   241.TBD2.1      IP-Port-Type          see Section 3.2.1
   241.TBD2.2      IP-Port-Limit         see Section 3.2.2
   241.TBD2.2      IP-Port-Ext-IPv4-Addr see Section 3.2.3

   This specification requests allocation of the following TLVs
   within the attribute IP-Port-Range 241.TBD3:

   Type            Name                  Meaning
   ----            ----                  -------
   241.TBD3.1      IP-Port-Type          see Section 3.2.1
   241.TBD3.2      IP-Port-Ext-IPv4-Addr see Section 3.2.3
   241.TBD3.3      IP-Port-Alloc         see Section 3.2.8
   241.TBD3.4	   IP-Port-Range-Start   see Section 3.2.9
   241.TBD3.5      IP-Port-Range-End     see Section 3.2.10

   This specification requests allocation of the following TLVs
   within the attribute IP-Port-Forwarding-Map 241.TBD4:

   Type            Name                  Meaning
   ----            ----                  -------
   241.TBD4.1      IP-Port-Type          see Section 3.2.1
   241.TBD4.2      IP-Port-Ext-IPv4-Addr see Section 3.2.3
   241.TBD4.3      IP-Port-Int-IPv4-Addr see Section 3.2.4
   241.TBD4.4      IP-Port-Int-IPv6-Addr see Section 3.2.5
   241.TBD4.5      IP-Port-Int-Port      see Section 3.2.6
   241.TBD4.6      IP-Port-Ext-Port      see Section 3.2.7
   241.TBD4.7      IP-Port-Local-Id      see Section 3.2.11

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.