Re: [netext] Request for review: draft-ietf-netext-radius-pmip6

["Damic, Damjan" <[e-mail]>]

Hello Avi,

First of all, we apologize for the much overdue response.
The upcoming I-D revision is being finalized and your review comments have been taken into account.
The comments were valuable and we really appreciate the effort.

Please find below replies to the more significant issues:
---------------------------
Sections 2 & 3 (Solution Overview)
Q: About the assumed PMIPv6 functional model and integration / dislocation of the MAG & Authenticator?
A: The collocated mode (all functions in the MAG) is implied by the RFC5213, however deployments already exist that make use of the split model. The I-D is not intending to make the explict normative statement about one or the other. It is assumed these entites form a logical block and they have proper means to communicate. The text has been updated to reflect this viewpoint.
On a related note... the network access authentication and mobility boostrapping are assumed to be a conjoined process, and performed by the same AAA query.
--------------------------
In Section 4 (Attribute definitions)
Q) It was proposed to reduce the number of AVP allocations by blending the v4 & v6 attribute versions.
A) We considered it, but believe it's better to keep separate AVPs for the sake of more performant processing. 
Scenarios may occur when both v4 and v6 parameters are provided together, so the length-based AVP parsing may become tedious.

Q) corrections to the MIP6-Feature-Vector
A) Updated. Actually, we plan to add an additional bit here to allow unambiguous mobility mode indication (v4-only, v6-only or DS-flavored PMIPv6 may be authorized).

Q) Can AAA authorize PMIP6-Home-LMA-IPv6-Address and PMIP6-Visited-LMA-IPv6-Address simultaneously (same for the LMA-v4 variant)?
A) Good catch. It SHOULD NOT. The HAAA may be informed/suggested of the visited LMA anchor as part of the Access-Request (i.e., PMIP6-Visited-LMA-IPv6-Address included in the incoming A-R) and the HAAA has sufficient means to decide on the LMA placement. The outgoing Access-Accept should be carrying AVPs only for the authorized anchor. I-D text is updated accordingly.

Q) Order of Prefix-Len and Reserved fields in the AVPs PMIP6-Visited-IPv4-HoA & PMIP6-Home-IPv4-HoA.
A) Actually, this AVP format was directly taken over from the IPv4 HoA mobility option defined in the RFC5844. Anyhow we changed the AVP format as was proposed.

Other attributes were modified as proposed.
-------------------------------
In Sections 5 & 6 (MAG-AAA & LMA-AAA interface definitions)
- The attribute tables are now listing the other relevant and standardly required RADIUS attributes.


Thanks once again.
Damjan (for the author group)




-----Original Message-----
From: Avi Lior [mailto:[e-mail]] 
Sent: Thursday, April 07, 2011 9:08 PM
Subject: Re: Request for review: draft-ietf-netext-radius-pmip6

Here is my review:


1.  Introduction

 SNIP

   MN and is authorized to send mobility management signaling messages
   on behalf of the MN.  Before the MAG initiates mobility management
   procedures, at minium it needs to know the IP address of the Local
   Mobility Anchor (LMA), and the MN Identifier (MN-ID).  The individual
   per MN Policy Profile (PP) information is stored in a Policy Store
   (PS), which may be local to the MAG or remotely accessible, for
   example, through the authentication, authorization and accounting
   (AAA) infrastructure.

<<<
Spelling
1. Introduction first par: minium to minimum
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

<<<
1.0 Introduction

Issue:

Most common configuration is not to have the policy stored in the MAG.  I
would suggest the following rewrite:

From:

   The individual
   per MN Policy Profile (PP) information is stored in a Policy Store
   (PS), which may be local to the MAG or remotely accessible, for
   example, through the authentication, authorization and accounting
   (AAA) infrastructure.

To:

   The individual per MN Policy Profile (PP) information is typically
stored
   in a Policy Store (PS) that is remotely accessible for example, through
   the authentication, authorization and accounting (AAA) infrastructure.
The PS
   may be local to the MAG.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

   This document defines the RADIUS-based [RFC2865] profile and
   corresponding attributes to be used on the AAA interface between the
   MAG and the RADIUS server.  This interface is used to retrieve the
   per MN Policy Profile from the remote Policy Store to the MAG.
   Furthermore, this document also defines the RADIUS-based interface
   between the LMA and the AAA RADIUS server for authorization of the
   received Proxy Binding Update (PBU) messages.  The AAA procedures
   defined in this document cover two deployment models: the PMIPv6
   scenario where MN connects via the Visited access network, and
   scenario where MN directly attaches in its Home network.




2.  Terminology


   Network Access Server (NAS):

      A device that provides the access service for a user to a network.
      The NAS device contains the RADIUS Client that communicates with
      the AAA RADIUS Server.  In the context of this document the NAS
      function may be integrated with the MAG.

<<<
2. Terminology NAS:

Issue:  In the context of this document the NAS is in the MAG.
Issue:  In the context of this document the NAS is also in the LMA.

From:

In the context of this document the NAS
      function may be integrated with the MAG.

To:
In the context of this document the NAS
      function is integrated with the MAG and the LMA.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


SNIP


3.  Solution Overview

<<<
3. Solution Overview

Issue:
Is the underlining assumption in this document that the MAG and the
Authenticator that is performing the Access Authentication are collocated.

Or is the intent that they don¹t have to be collocated.

This is not captured crisply enough and needs to be.  There are two
scenario here:
THe interaction between the MAG and VAAA HAAA is standalone or it is in
conjunction
with the network access authentication

This point is as important as Home and Visited scenarios.


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

   This document defines the RADIUS-based AAA interactions on two PMIPv6
   interfaces:
   o  between the MAG and the AAA RADIUS Server, and
   o  between the LMA and the AAA RADIUS Server.

<<<
3.  Solution Overview

From: The Policy Profile is retrieved from the corresponding RADIUS server
   to the MAG during the MN attachment to the PMIPv6 domain.

To: The Policy Profile is retrieved from the  RADIUS server
   to the MAG during the MN attachment to the PMIPv6 domain.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

   The Policy Profile is retrieved from the corresponding RADIUS server
   to the MAG during the MN attachment to the PMIPv6 domain.  The LMA
   asks for authorization from the RADIUS server upon receiving the
   Proxy Binding Update (PBU) messages for the mobility service session.
   The concerning AAA procedures use the RADIUS protocol.

   When a MN attaches to a PMIPv6 Domain, a network access
   authentication procedure is started.  The choice of the
   authentication mechanism is specific to the access network
   deployment, however it is commonly based on the Extensible
   Authentication Protocol (EAP) [RFC3748].  During the network access
   authentication, the MAG acting as a NAS queries the HAAA through the
   AAA infrastructure.  If the HAAA detects that the subscriber is
   authorized for PMIPv6 services, the RADIUS Access-Accept shall return
   to the MAG the Policy Profile including PMIPv6-specific information.

<<<
3.  Solution Overview
Issue: get rid of the shall here.

From:

If the HAAA detects that the subscriber is
   authorized for PMIPv6 services, the RADIUS Access-Accept shall return
   to the MAG the Policy Profile including PMIPv6-specific information.

To:
If the HAAA detects that the subscriber is
   authorized for PMIPv6 services, the RADIUS Access-Accept returns
   to the MAG the Policy Profile including PMIPv6-specific information.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

   After successfully authenticating the MN, the MAG sends a PBU to the
   LMA based on MN's policy profile information.  Upon receiving the
   PBU, the LMA interacts with the HAAA, and fetches the relevant Policy
   Profile and authorization information for the MN's mobility service
   session.




Xia, et al.            Expires September 15, 2011               [Page 5]

Internet-Draft                RADIUS-PMIPv6                   March 2011


   This document adds support for three distinct PMIPv6 mobility use
   cases, taking into account the administrative domains to which the
   attended MAG and the LMA belong to.  The observed network topologies
   are identified by following conditions:
   1.  the MAG and LMA are both in the home network,
   2.  the MAG and LMA are both in the visited network, or
   3.  the MAG is in the visited network while the LMA is in the home
       network.

<<<
3.  Solution Overview

Editorial:  Add a space between the par ending with ³.... by following
conditions:² and the numbered list.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

SNIP


4.  Attribute definitions


<<<
4.  Attribute definitions

General comment.

PMIP6-Home-LMA-IPv6-Address
PMIP6-Home-LMA-IPv4-Address

Could have been done by a single attribute. The receiver would be able to
differentiate which type of address is being carried by the length of the
attribute.
Similarly for the Visited LMA IP Address.

There is also no discussion of whether or not we can send both of these
attributes at the same time.  This is a general comment because there is no
discussion or consideration on when to send certain attribute or not to
send certain attributes and on how to resolve which to use when there is
more then one option.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

4.1.  MIP6-Feature-Vector

   Diameter [RFC3588] reserves AVP Code space 1-255 as RADIUS attribute
   compatibility space.  The MIP6-Feature-Vector AVP (AVP Code 124)
   defined in [RFC5447] is of type Unsigned64 and contains a 64-bit
   flags field of supported mobility capabilities.  This document
   reserves a new capability bit according to the rules in [RFC5447],
   and reuses the PMIPv6 capability bits defined by [RFC5779].  The
   following capability flag bits are used or defined in this document:

   PMIP6_SUPPORTED (0x0000010000000000)

      This capability bit is used as defined in [RFC5779].






Xia, et al.            Expires September 15, 2011               [Page 8]

Internet-Draft                RADIUS-PMIPv6                   March 2011


   IP4_HOA_SUPPORTED (0x0000020000000000)

      This capability bit is used as defined in [RFC5779].  Assignment
      of the IPv4-HoA is defined by [RFC5844].

   LOCAL_MAG_ROUTING_SUPPORTED (0x0000040000000000)

      This capability bit is used as defined in [RFC5779].

   IP4_TRANSPORT_SUPPORTED (0x0000080000000000)

      This capability bit is used for negotiation of the IPv4 transport
      support between the MAG and AAA.  When the MAG sets this flag bit
      in the MIP6-Feature-Vector, it indicates ability of the MAG to
      provide IPv4 transport (i.e., IPv4-based encapsulation) for
      carrying IP traffic between the MAG and the LMA.  If this flag bit
      is unset in the returned MIP6-Feature-Vector AVP, the AAA does not
      authorize the use IPv4 transport on the MAG-to-LMA tunnel.


   The MIP6-Feature-Vector attribute is also used on the LMA to the
   RADIUS AAA interface.  This capability announcement attribute enables
   direct capability negotiation between the LMA and the AAA.  The
   capabilities that are announced by both parties in the MIP6-Feature-
   Vector are known to be mutually supported.  The LMA may use this
   mechanism during authorization of the received PBU against the AAA to
   check individual PMIPv6 feature permissions for a particular MN.

<<<
4.1.  MIP6-Feature-Vector

Issue:  The  MIP6-Feature-Vector is missing.  RADIUS does not have a type
of  64-bit unsigned

In this case an 8 octet OctetString is used in network byte order.

But this is not your problem.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

4.2.  Mobile-Node-Identifier

   The Mobile-Node-Identifier attribute (AVP Code TBD) is of type String
   and contains the mobile node identifier (MN-Identifier) see
   [RFC5213]) in a form of a NAI [RFC4282] format.  This AVP is used on
   the interface between MAG and the AAA server.  The Mobile-Node-
   Identifier attribute is designed for deployments where the MAG does
   not have means to find out the MN identity that could be used in
   subsequent PBU/PBA exchanges (e.g., due to identity hiding during the
   network access authentication) or when the HAAA wants to assign
   periodically changing identities to the MN.

<<<
4.2.  Mobile-Node-Identifier

Issue:  The most common case for having a Mobile-Node-Identifier is to
decouple the identifier used for Network Access Authentication from the
identity used for Mobile IP.

From:
The Mobile-Node-
   Identifier attribute is designed for deployments where the MAG does
   not have means to find out the MN identity that could be used in
   subsequent PBU/PBA exchanges (e.g., due to identity hiding during the
   network access authentication) or when the HAAA wants to assign
   periodically changing identities to the MN.

To:

The Mobile-Node-
   Identifier attribute is designed for deployments where the identity
used during
Access Authentication and the Identity used for Mobility is decoupled.
It may also be the case where the MAG does
   not have means to find out the MN identity that could be used in
   subsequent PBU/PBA exchanges (e.g., due to identity hiding during the
   network access authentication) or when the HAAA wants to assign
   periodically changing identities to the MN.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


<<<
4.2.  Mobile-Node-Identifier

Issue:  need more formal language.

From:
The Mobile-Node-Identifier attribute is returned by HAAA in the
   RADIUS Access-Accept message that completes a successful ...
To:
The Mobile-Node-Identifier attribute MAY be returned by HAAA in the
   RADIUS Access-Accept message that completes a successful ...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

   The Mobile-Node-Identifier attribute is returned by HAAA in the
   RADIUS Access-Accept message that completes a successful
   authentication and authorization exchange between the MAG and the
   HAAA (if HAAA is able to provide the MN-Identifier in the first
   place).  If the MAG has not acquired a valid MN-Identifier by other
   means, it MUST use the received MN-Identifier.

<<<
4.2.  Mobile-Node-Identifier

Issue:  I am not sure I understand what is the intent of the following:
(if HAAA is able to provide the MN-Identifier in the first
   place)

If this is not important then I suggest removing this.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


SNIP


4.3.  PMIP6-Home-LMA-IPv6-Address

   This attribute (AVP Code TBD) is used to deliver the IPv6 address of
   the LMA located in the Home network.
   Before the MAG can engage in Proxy Mobile IPv6 signaling it must be
   aware of the LMA's IP address either by means of pre-configuration or
   through dynamic discovery.  After the MN has been successfully
   authenticated, the MAG retrieves the IPv6 address of the LMA by
   fetching MN's policy profile information from the AAA.

<<<
4.3.  PMIP6-Home-LMA-IPv6-Address

Issue:  The following line implies that there is a separate dip by the MAG
to retrieve the Home LMA IP address.  This does not seem to be consistent
with other text that would imply that the MAG gets this information during
access authentication for example see how the MAG gets the Mobile Node
identifier.

After the MN has been successfully
   authenticated, the MAG retrieves the IPv6 address of the LMA by
   fetching MN's policy profile information from the AAA.


Remedy:  You can simply delete the offending sentence.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>



SNIP



4.4.  PMIP6-Visited-LMA-IPv6-Address

   This attribute (AVP Code TBD) is used to deliver the IPv6 address of
   the LMA located in the Visited network.  When the MN is attaching in
   the visited network, the MAG interacts with the HAAA through the
   visited AAA.  The LMA in the visited network may be assigned by the
   visited AAA as the result of retrieved Policy Profile.

<<<
4.4.  PMIP6-Visited-LMA-IPv6-Address

Issue:  this attribute is used for two purposes.  One to suggest an LMA in
the visited network; and to authorize an LMA in the visited network.

The first sentence does not reflect this dual use.

From:
³This attribute (AVP Code TBD) is used to deliver the IPv6 address of
   the LMA located in the Visited network.²
To:
This attribute (AVP Code TBD) is used to propose a particular LMA in the
visited network and to authorize the use of
   the LMA in the Visited network.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

   This attribute MAY be sent by the MAG to the VAAA in the RADIUS
   Access-Request packet as a proposal to allocate the particular LMA
   for the MN.  When included by VAAA in the RADIUS Access-Accept sent
   to the MAG, the attribute SHALL carry the IPv6 address of the visited
   LMA being assigned for the particular MN.

<<<
4.4.  PMIP6-Visited-LMA-IPv6-Address

Issue:  The notion of Authorization performed by the HAAA is not really
captured by the sentence.

From:
When included by VAAA in the RADIUS Access-Accept sent
   to the MAG, the attribute SHALL carry the IPv6 address of the visited
   LMA being assigned for the particular MN.

To:

If included by VAAA in the RADIUS Access-Accept sent
   to the MAG, the use of the LMA in the visited network is authorized and
the attribute SHALL carry the IPv6 address of the visited
   LMA being assigned for the particular MN.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

<<<
4.4.  PMIP6-Visited-LMA-IPv6-Address

Issue:  It is possible for the HAAA to authorize an LMA in the home and an
LMA in the visited network.

This is not addressed.  Either we prohibit this by saying one or the other
SHOULD/MUST provided or specify that
they both may be present and how the selection is handled -- probably out
of scope.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>



SNIP



4.5.  PMIP6-Home-LMA-IPv4-Address

   The PMIP6-Home-LMA-IPv4-Address attribute (AVP Code TBD) contains the
   IPv4 address of the LMA assigned by the HAAA.  The [RFC5844] supports
   Proxy Mobile IPv6 signaling exchange between MAG and LMA using the
   IPv4 transport.  That is, scenario is supported where LMA and MAG
   employ IPv4 addresses to source the PMIPv6 signaling messages and to
   establish the IPv4-based transport path for the MN's payload.

<<<
4.5.  PMIP6-Home-LMA-IPv4-Address

Editorial:

The following needs to be reworded or deleted (deletion is okay since I
don¹t think we need clarification)

That is, scenario is supported where LMA and MAG
   employ IPv4 addresses to source the PMIPv6 signaling messages and to
   establish the IPv4-based transport path for the MN's payload.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>



SNIP


4.6.  PMIP6-Visited-LMA-IPv4-Address

<<<
4.6.  PMIP6-Visited-LMA-IPv4-Address

Issue: several of the comments for PMIP6-Visited-LMA-IPv6-Address (4.4)
apply to the text here.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


SNIP


4.7.  PMIP6-Home-LMA-Identifier

SNIP



4.8.  PMIP6-Visited-LMA-Identifer

SNIP

4.9.  PMIP6-Home-HN-Prefix

SNIP

4.10.  PMIP6-Visited-HN-Prefix

   When the LMA is assigned from the visited network, PMIP6-Visited-HN-
   Prefix attribute (AVP Code TBD) is used to deliver the concerning MN-
   HNP from the VAAA to the MAG.

   The PMIP6-Visited-HN-Prefix attribute is also used on the LMA to VAAA
   interface containing the IPv6 prefix assigned to the MN.  If the LMA
   delegates the assignment of the MN-HNP to the VAAA, the AVP MUST
   contain all zeroes address (i.e., 0::0) in the RADIUS Access-Reques.
   The attribute MUST be present in Access-Accept if the prior request
   already included one, and SHOULD carry the MN-HNP the VAAA assigned
   to the MN.


<<<
4.10  PMIP6-Visited-HN-Prefix

Editorial:
From: ³...in the RADIUS Access-Reques.²
To: ³....in the RADIUS Access-Request.²
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>



SNIP

4.11.  PMIP6-Home-Interface-ID

   For Proxy Mobile IPv6 the Home Network Prefixes assigned to the
   mobile node have to be maintained on a per-interface basis.  When the
   LMA is located in the home network, PMIP6-Home-Interface-ID attribute
   conveys 64 bits interface identifier representing a particular MN's
   interface.  The attribute is assigned by the HAAA to the MAG for
   derivation of the MN-HoA.

   This attribute MAY be sent by the LMA or the MAG to the HAAA in the
   RADIUS Access-Request packet as a proposal.  This attribute MAY be
   sent by HAAA to the LMA in an Access-Accept packet, however MUST be
   present if the prior request already included one.


<<<
4.11.  PMIP6-Home-Interface-ID

Editorial:
From: ³..however MUST be
   present if the prior request already included one.²
To: ³...however it MUST be
   present if the prior request already included one.²

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>






Xia, et al.            Expires September 15, 2011              [Page 17]

Internet-Draft                RADIUS-PMIPv6                   March 2011


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      |  Home Interface Identifier
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Home Interface Identifier
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Home Interface Identifier     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:
      PMIP6-Home-Interface-ID to be defined by IANA.

   Length:
      = 10 octets.

   Home Interface Identifier:
      The home interface identifier field is 8 octets.


4.12.  PMIP6-Visited-Interface-ID

   For Proxy Mobile IPv6 the visited Home Network Prefixes assigned to
   the mobile node have to be maintained on a per-interface basis.  When
   the LMA is located in the visited network, the attribute conveys 64
   bits interface identifier representing a particular MN's interface.
   The attribute is assigned by the VAAA to MAG for the derivation of
   MN-HoA.

   This attribute MAY be sent by the LMA or the MAG to the VAAA in an
   Access-Request packet as a proposal.  This attribute MAY be sent by
   HAAA to the LMA in an Access-Accept packet, however MUST be present
   if the prior request already included one.

<<<
4.11.  PMIP6-Visited-Interface-ID

Editorial:
From: ³..however MUST be
   present if the prior request already included one.²
To: ³...however it MUST be
   present if the prior request already included one.²

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


SNIP

4.13.  PMIP6-Home-IPv4-HoA

   [RFC5844] specifies extensions to Proxy Mobile IPv6 protocol which
   enable IPv4 home address mobility support to the MN.  The PMIP6-Home-
   IPv4-HoA attribute (AVP Code TBD) is of type Address and contains the
   IPv4 Home Address of the MN.  The primary use of this attribute is to
   deliver the assigned IPv4-HoA from HAAA to the MAG.

   The PMIP6-Home-IPv4-HoA is also used on the LMA-to-HAAA interface.
   If the LMA in the home network delegates the assignment of the IPv4-
   HoA to the HAAA, the attribute MUST contain all zeroes address in the
   request message.  The attibute MUST be included in by HAAA in the
   response if the previous request included it, and it contains the
   IPv4-HoA assigned to the MN.




Xia, et al.            Expires September 15, 2011              [Page 19]

Internet-Draft                RADIUS-PMIPv6                   March 2011


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Length      |Prefix-Len |     Reserved      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Home IPv4 HoA                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<<<
4.13.  PMIP6-Home-IPv4-HoA

Issue:  in this attribute the prefix-len comes before the reserved bit.  I
think this would make it awkward.
for parsing.

Having the Reserved before the Prefix-Len should make it easier for the
RADIUS server to parse.  This is also consistent with other definitions.
See 3218 and also in this document.  Was there a particular reason to do
this?

The other attributes above have it the other way around.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Type:
   PMIP6-Home-IPv4-HoA to be defined by IANA.

Length:
   = 8 octets

Prefix-Len
   The 6-bit unsigned integer indicating the prefix length of the trailing
IPv4 HoA

Reserved
   The 10-bit field reserved for future use. Value MUST beinitialized to
   zero by sender, and MUST be ignored by the receiver.

Home IPv4 HoA:
   This field is of type Address and contains the IPv4 home
   address of the MN in the home network.


4.14.  PMIP6-Visited-IPv4-HoA

   When both MAG and the LMA are in the visited network, the PMIP6-
   Visited-IPv4-HoA attribute (AVP Code TBD) is used to exchange
   information between the VAAA and the MAG on the assignment of the
   IPv4 Home Address to the MN being present in the Visited network.

   The PMIP6-Visited-IPv4-HoA is also used on the LMA-to-VAAA interface.
   If the LMA delegates the assignment of the IPv4-HoA to the VAAA, the
   attribute MUST contain all zeroes address in the RADIUS Access-
   Request.  The Access-Accept message MUST have the attribute present
   if the prior request to VAAA already included one.












Xia, et al.            Expires September 15, 2011              [Page 20]

Internet-Draft                RADIUS-PMIPv6                   March 2011


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Length      |Prefix-Len |     Reserved      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Visited IPv4 HoA                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<<<
4.14.  PMIP6-Visited-IPv4-HoA

See the same issue regarding Prefix-Len and Reserved ordering in 4.13
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


SNIP

4.15.  PMIP6-Home-DHCP4-Server-Address

   The PMIP6-Home-DHCP4-Server-Address (AVP Code TBD) contains the IPv4
   address of the DHCPv4 server in the home network.  The particular
   DHCP server address is indicated to the MAG that serves the
   concerning MN.  The HAAA MAY assign a DHCP server to the MAG in
   deployments where the MAG acts as a DHCP Relay, as defined in
   [RFC5844].
















Xia, et al.            Expires September 15, 2011              [Page 21]

Internet-Draft                RADIUS-PMIPv6                   March 2011


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Length      |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Home DHCPv4 server address                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<<<
4.15.  PMIP6-Home-DHCP4-Server-Address

Issue:  is there any reason to have the Reserved field? If not then get
rid of it.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Type:
  PMIP6-Home-DHCP4-Server-Address to be defined by IANA.

Length:
   = 8 octets.

Reserved:
   Reserved for future use. The bits MUST be set to zero by the
   sender, and MUST be ignored by the receiver.

Home DHCPv4 server address:
   This field is of type Address and contains a 4-octet IPv4 address of
the DHCP server.


4.16.  PMIP6-Visited-DHCP4-Server-Address

   When both MAG and the LMA are in the visited network, the VAAA uses
   PMIP6-Visited-DHCP4-Server-Address attribute (AVP Code TBD) to
   deliver the IPv4 address of the DHCPv4 server from the visited
   network to the MAG.  The VAAA MAY assign a DHCPv4 server to the MAG
   in deployments where the MAG acts as a DHCP Relay, as defined in
   [RFC5844].




















Xia, et al.            Expires September 15, 2011              [Page 22]

Internet-Draft                RADIUS-PMIPv6                   March 2011


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Length      |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Visited DHCPv4 server address                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<<<
4.16.  PMIP6-Visited-DHCP4-Server-Address

Issue:  is there any reason to have the Reserved field? If not then get
rid of it.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Type:
   PMIP6-Visited-DHCP4-Server-Address to be defined by IANA.

Length:
   = 8 octets

Reserved:
   Reserved for future use.  The bits MUST be set to zero by the
   sender, and MUST be ignored by the receiver.

Visited DHCPv4 server address:
   This field is of type Address and contains a 4-octet IPv4 address of
the DHCPv4
   server


4.17.  PMIP6-Home-DHCP6-Server-Address

   The PMIP6-Home-DHCP6-Server-Address (AVP Code TBD) contains the IPv6
   address of the DHCPv6 server in the home network indicated by HAAA to
   the MAG that serves the concerning MN.  The HAAA MAY assign a DHCPv6
   server to the MAG in deployments where the MAG acts as a DHCP Relay,
   as defined in [RFC5213].


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Length      |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                  Home DHCPv6 server address                   .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<<<
4.17.  PMIP6-Home-DHCP6-Server-Address

Issue:  is there any reason to have the Reserved field? If not then get
rid of it.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Type:
  PMIP6-Home-DHCP6-Server-Address to be defined by IANA.

Length:
   = 20 octets

Reserved:
   Reserved for future use.  The bits MUST be set to zero by the
   sender, and MUST be ignored by the receiver.

Home DHCPv6 server address:
   This field is of type Address and contains 16-octet IPv6 address of the
DHCPv6 server.


4.18.  PMIP6-Visited-DHCP6-Server-Address

   When both MAG and the LMA are located in the visited network, the
   PMIP6-Visited-DHCP6-Server-Address attribute (AVP Code TBD) is used
   to deliver the IPv6 address of the DHCPv6 server from the visited
   network to the MAG that serves the MN.  The VAAA MAY assign a DHCPv6
   server to the MAG in deployments where the MAG acts as a DHCP Relay,
   as defined in [RFC5213].


















Xia, et al.            Expires September 15, 2011              [Page 24]

Internet-Draft                RADIUS-PMIPv6                   March 2011


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Length      |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
.                  Visited DHCPv6 server address                .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<<<
4.18.  PMIP6-Visited-DHCP6-Server-Address

Issue:  is there any reason to have the Reserved field? If not then get
rid of it.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Type:
  PMIP6-Visited-DHCP6-Server-Address to be defined by IANA.

Length:
   = 20 octets

Reserved:
   Reserved for future use.  The bits MUST be set to zero by the
   sender, and MUST be ignored by the receiver.

Visited DHCPv6 server address:
   This field is of type Address and contains the 16-octet IPv6 address of
the DHCPv6 server.


4.19.  Service-Selection

<<<<<<<<<<<<<
Typo:   particual -> particular
>>>>>>>>>>>>>>>
   The Service-Selection attribute (AVP Code TBD) contains the name of
   the service or the external network that the mobility service for the
   particual MN SHOULD be associated with.  The identifier MUST be
   unique within the PMIPv6 Domain.

SNIP


Xia, et al.            Expires September 15, 2011              [Page 25]

Internet-Draft                RADIUS-PMIPv6                   March 2011


  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |      Type     |   Length      |    Service Identifier...      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Type:
    Service-Selection to be defined by IANA.

 Length:
    >= 3 octets

 Service Identifier:
    This field is of type UTF8String and contains the Service Identifier
    the MN is associated with.

<<<
4.19.  Service-Selection

Issue: the correct way to specify this is to use RADIUS type of TEXT:

From:

 Service Identifier:
    This field is of type UTF8String and contains the Service Identifier
    the MN is associated with.
To:

Text:
     This field is of type UTF8String and contains the Service Identifier
    the MN is associated with.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


4.20.  Calling-Station-Id

   The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String and
   contains a link-layer identifier of the MN.  This identifier
   corresponds to the link-layer identifier as defined in [RFC5213],
   Sections 2.2 and 8.6.  The Link-Layer Identifier is encoded in ASCII
   format (upper case only), with octet values separated by a "-".
   Example: "00-23-32-C9-79-38".  The encoding is actually the same as
   the MAC address encoding in Section 3.21 of [RFC3580].



<<<
4.20.  Calling-Station-Id

Issue:
The above definition contradicts the definition used by RFC 2865.

In this specification you can narrow the definition if you want.

In RFC 2865 the definition is String (binary string) which means it can
carry anything.
Here if you want it to be more specific then you need to say that.

From:
The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String and
   contains a link-layer identifier of the MN.  This identifier
   corresponds to the link-layer identifier as defined in [RFC5213],...

To:
The Calling-Station-Id AVP (AVP Code 31) is of type String and when used
for PMIPv-6
   contains a link-layer identifier of the MN as defined in [RFC5213], ....

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


4.21.  Chargeable-User-Identity

SNIP

5.  MAG to RADIUS AAA interface


5.1.  Interface operations

   The MAG to the AAA RADIUS server interface is used for retrieval of
   the Policy Profile (i.e., for bootstrapping of the Proxy Mobile IPv6
   mobility service session) when a MN tries to attach, authenticate and
   authorize to a PMIPv6 domain.  Depending on the policies and network
   capabilities the MAG may retrieve different sets of PMIPv6-session
   related parameters:
   o  Configuration attributes for Home- or Visited Network access
      scenario, depending on the location and attachment point of the
      MN,
   o  The IPv6 or IPv4 address of the designated LMA, depending on the
      access network's actual IP topology,
   o  The IPv6 or IPv4 configuration parameters for the MN, depending on
      the utilized IP configuration method and individual MN's service
      Policy,
   o  The DHCP Relay support attributes (IPv4 or IPv6) in case such
      functionality is supported in the network.

<<<
5.1.  Interface operations

Issue:  What is the following saying?

³In addition to the particular PMIPv6 RADIUS attributes, other common
   AVPs are also concerened.²
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

   In addition to the particular PMIPv6 RADIUS attributes, other common
   AVPs are also concerened.  Whenever the MAG sends a RADIUS Access-
   Request message to the AAA server, the User-Name attribute (1) SHOULD
   contain the MN identity.  At minimum, the home realm of the MN MUST
   be available at the MAG when the network access authentication takes
   place.  Otherwise the MAG will not be able to route the RADIUS
   Access-Request messages towards the correct AAA server.  The MN
   identity MUST be in Network Access Identifier (NAI) [RFC4282] format.

5.2.  Table of Attributes

   The following table provides a guide to attributes that may be found
   in authentication and authorization RADIUS messages.


<<<
5.2.  Table of Attributes


Issue:
Other missing attributes that would be required.  It may not be enough to
say that these are in addition to the attributes in 2865 etc....

Normally (for example in WiMAX we assume) that the PMIP attributes are
carried along with the other RADIUS attributes used during authentication.

If we assume that the MAG is doing its own dip to the AAA server then we
need to include other attributes as well.  You dont necessarily need to
document them
but you should show them.

Certainly the LMA is doing its own dip.

I have included them with a description.

          1      User-Name           Required  from MAG and from LMA
          4      NAS-IP-Address      Either this or   31 is required
          5      NAS-Port
          6      Service-Type        Should be there and set to
Authorize-Only
         24      State
         25      Class               Optional but if present in
Access-Request MUST be included in Accounting

         27      Session-Timeout     Optional Controls how long the
authorization for PMIP session is allowed.  PMIP may not have that concept

         29      Termination-Action   Probably not needed.  This describes
what to do when the Session-Timeout expires. Two options: drop or
reauthenticate... in this case reauthorize.

         31      Calling-Station-Id   You got that
         32      NAS-Identifier       Either this or NAS-IP-Address 4 is
required
         33      Proxy-State          Needs to be supported if we have
proxies and we do

         61      NAS-Port-Type        We need this as well -- IANA has a
allocations for this. Need this so we know we are talking to MAG/LMA vs
other type of NAS.

         80      Message-Authenticator  MUST have this attribute in
Access-Requests.  Without this attribute (since you dont have the Password
attributes) there is no way to
cryptographically integrity protect the RADIUS exchanges etc...


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


   Request   Accept   Reject   Challenge   #    Attribute
   0         0-1      0        0           TBD  PMIP6-Home-LMA-IPv6-Address
   0-1       0-1      0        0           TBD
PMIP6-Visited-LMA-IPv6-Address
   0         0-1      0        0           TBD  PMIP6-Home-LMA-IPv4-Address
   0-1       0-1      0        0           TBD
PMIP6-Visited-LMA-IPv4-Address
   0         0-1      0        0           TBD  PMIP6-Home-LMA-Identifier
   0-1       0-1      0        0           TBD
PMIP6-Visited-LMA-Identifier
   0         0-1      0        0           TBD  PMIP6-Home-HN-Prefix
   0         0-1      0        0           TBD  PMIP6-Visited-HN-Prefix
   0         0-1      0        0           TBD  PMIP6-Home-Interface-ID
   0         0-1      0        0           TBD  PMIP6-Visited-Interface-ID
   0         0-1      0        0           TBD  PMIP6-Home-IPv4-HoA
   0         0-1      0        0           TBD  PMIP6-Visited-IPv4-HoA
   0         0-1      0        0           TBD
PMIP6-Home-DHCP4-Server-Address
   0-1       0-1      0        0           TBD
PMIP6-Visited-DHCP4-Server-Address
   0         0-1      0        0           TBD
PMIP6-Home-DHCP6-Server-Address
   0-1       0-1      0        0           TBD
PMIP6-Visited-DHCP6-Server-Address
   0         1        0        0           TBD  Mobile-Node-Identifier
   0-1       0-1      0        0           124  MIP6-Feature-Vector
   0-1       0-1      0        0           TBD  Service-Selection
   0-1       0        0        0           31   Calling-Station-Id
   0-1       0-1      0        0           89   Chargeable-User-Identity



6.  LMA to RADIUS AAA interface

6.1.  Interface operations

   The LMA-to-HAAA interface may be used for multiple purposes.  These
   include the authorization of the incoming PBU, updating the LMA
   address to the HAAA, accounting and PMIPv6 session management.

6.2.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in authentication and authorization process.

<<<
6.2.  Table of Attributes

Same as comment against 5.2

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Internet-Draft                RADIUS-PMIPv6                   March 2011


   Request   Accept   Reject   Challenge   #    Attribute
   0-1       0-1      0        0           TBD  PMIP6-Home-HN-Prefix
   0-1       0-1      0        0           TBD  PMIP6-Home-IPv4-HoA
   0         0-1      0        0           TBD  PMIP6-Home-Interface-ID
   0-1       0        0        0           TBD  PMIP6-Home-LMA-Identifier
   0-1       0        0        0           TBD
PMIP6-Visited-LMA-Identifier
   0         0-1      0        0           TBD  PMIP6-Visited-Interface-ID
   1         0        0        0           TBD  Mobile-Node-Identifier
   0-1       0-1      0        0           124  MIP6-Feature-Vector
   0-1       0-1      0        0           TBD  Service-Selection
   0-1       0        0        0           31   Calling-Station-Id
   0-1       0-1      0        0           89   Chargeable-User-Identity



7.  Accounting

7.1.  Accounting at LMA

   The accounting at the LMA to AAA server interface is based on
   [RFC2865] and [RFC2866].  This interface must support the transfer of
   accounting records needed for service control and charging.  These
   records should include (but may not be limited to): time of binding
   cache entry creation and deletion, number of the octets sent and
   received by the MN over the bi-directional tunnel, etc.

7.2.  Accounting at MAG

   The accounting at the MAG to AAA server interface is based on
   [RFC2865] and [RFC2866].  The interface must also support the
   transfer of accounting records which should include: time of binding
   cache entry creation and deletion, number of the octets sent and
   received by the MN over tge bi-directional tunnel, etc.

<<<
7.2.  Accounting at MAG

Typo:  tge > the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

   If there is data traffic between a visiting MN and a correspondent
   node that is locally attached to an access link connected to the same
   MAG, the mobile access gateway MAY optimize on the delivery efforts
   by locally routing the packets instead of using reverse tunneling to
   the mobile node's LMA.  In this case, the local data traffic too MUST
   be reported to AAA Accounting servers by means of RADIUS protocol.

7.3.  Table of Attributes

   The following table provides a list of attributes that may be
   included in the RADIUS Accounting messages.

<<<
7.3.  Table of Attributes

Issue:  missing some standard RADIUS attributes...

25 Class SHOULD Be present if present in Access-Accept


Remedy:  To explicitly state that these are over and above those
attributes that are required by RFC 2866 and 2869 etc...

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


         Request   Interim  Stop     Attribute
         0-1       0        0-1      PMIP6-Home-LMA-IPv6-Address
         0-1       0        0-1      PMIP6-Visited-LMA-IPv6-Address
         0-1       0        0-1      PMIP6-Home-LMA-IPv4-Address
         0-1       0        0-1      PMIP6-Visited-LMA-IPv4-Address
         0-1       0        0-1      PMIP6-Home-HN-Prefix
         0-1       0        0-1      PMIP6-Visited-HN-Prefix
         0-1       0        0-1      PMIP6-Home-IPv4-HoA
         0-1       0        0-1      PMIP6-Visited-IPv4-HoA
         0-1       0        0-1      Service-Selection
         0-1       0        0-1      MIP6-Feature-Vector
         0-1       0-1      0-1      Mobile-Node-Identifier
         0-1       0        0-1      Calling-Station-Id
         0-1       0-1      0-1      Chargeable-User-Identity



SNIP


10.  Acknowledgements

   The authors would like to thank Glen Zorn, Avi Lior and Alan DeKok
   for reviewing the document.  The authors would also like to thank the
   authors of [RFC5779] as this document re-uses some procedural ideas
   of the mentioned specification.

<<<
10 Acknowledgement

Most of this has been implemented by WiMAX before anyone else has done
this.  IMHO the document should acknowledge that.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


SNIP


-- Avi Lior
--Bridgewater Systems


>