[netlmm] Review of Rev 17 of I-D:

[<Basavaraj.Patil at nokia.com>]

Review comments:

General comment:

- Use the acronym MN for mobile node or PMIP6 instead of Proxy Mobile
IPv6 or HoA etc. across the document. It is enough to expand the
acronym only the first time it is used. It is quite painful to read
the I-D the way it is written now.

>      IPv4 Home Address Mobility Support: A mobile node that has an IPv4
>      stack enabled will be able to obtain an IPv4 address and be able
>      to use that address from any of the access networks in that Proxy
>      Mobile IPv6 domain.  The mobile node is not required to be
>      allocated or assigned an IPv6 address to enable IPv4 home address
>      support.

Rephrase as: A mobile node which is dual-stack or IPv4 only capable
should be able to obtain an IPv4 home-address from the LMA in a PMIP6
domain and use the assigned address from any access networks in that
PMIP6 domain to which the MN may attach. The MN is not required to be
allocated an IPv6 home-address in order to obtain an IPv4
home-address.

>      IPv4 Transport Network Support: The mobility entities in the Proxy
>      Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6
>      signaling messages over an IPv4 transport and furthermore the
>      mobile access gateway may be using an IPv4 private address and
>      with NAT [RFC-3022] translation devices on the path to the local
>      mobility anchor.

Rephrase as: The MAG and LMA entities in a PMIP6 domain MUST be able
to exchange signaling messages over an IPv4 transport network.

- The case for private IPv4 addresses on the MAG is debatable. It
  would be simpler to not worry about NAT traversal issues in this
  specification. There is no good use case which requires private IPv4
  address being assigned to the MAG.

- If private IPv4 addresses are not expected to be assigned to MAGs,
  the figure (1) can be simplified further by removing NATs which are
  shown there

- Is it assumed that all the mobility nodes in a PMIP6 domain would
  support IPv4 and IPv6? Or can there be some nodes which are IPv4 or
  IPv6 only?

>      The local mobility anchor and the mobile access gateway MUST be
>      configured with IPv6 globally unique addresses.  Or, they must be
>      at least unique within that Proxy Mobile IPv6 domain.  These
>      addresses can be of the type, Unique Local IPv6 Unicast Address
>      [RFC-4193], IPv6 Global Unicast Address [RFC-3587], or IPv4-mapped
>      IPv6 address [RFC-4291].

Badly phrased sentence. It would be better to simply state that the
LMA and MAG MUST be configured with a global IPv6 address.
And get rid of all the other IPv6 address types that may be assigned
to the MAG/LMA.

- In the assumptions section, it should be mentioned that the MN may
  be assigned an IPv4 home-address from the RFC1918 address space.

>   o  The NAT traversal logic specified in [RFC-5555] for detecting the
>      on-path NAT devices is valid for this specification as well.

Would be better to avoid NAT traversal in the PMIP6 case. It makes
sense to deal with NATs in the case of DSMIP6 because it is the MN
itself which is assigned the COA whereas in the PMIP6 case it is the
MAG. And number of MAGs are not the same as number of MNs.

>      However, if the configured address is a private IPv4
>      address and with a NAT device in the path to the local mobility
>      anchor, the care-of address as seen by the local mobility anchor
>      will be the address allocated by the NAT device for that flow.

Again, the issue of private addresses and NATs makes the specification
unnecessarily complex. There is no harm done by getting rid of NAT
traversal and private IPv4 support.

In the document it would be good to clarify that the IPv4 address
assigned to the LMA is always a globally routable unique IPv4 address
(i.e not RFC1918 address). If we have only public addresses assigned
to MAGs and LMAs we do not need all these details.

- Include in the terminology for "Mobile Node's IPv4 Home Address
  (IPv4-MN-HoA)" that the MN MAY be assigned a private IPv4 address
  and this IPv4 address is unique within the scope of a single LMA (or
  maybe PMIP6 domain).

>      A procedure for partial de-registration of all the addresses that
>      belong to one address family, i.e., de-registration of either IPv4
>      home address, or all of the IPv6 home network prefixes.

Rephrase as: A procedure for partial de-registration of all the addresses
that
      belong to one address family, i.e. de-registration of either the IPv4
      home address, or one or more of the assigned IPv6 home network
      prefixes.

>   The IPv4 home address mobility support essentially enables a mobile
>   node in a Proxy Mobile IPv6 domain to obtain IPv4 home address
>   configuration for its attached interfaces and be able to retain that
>   address configuration even after performing an handoff anywhere
>   within that Proxy Mobile IPv6 domain.

Rephrase as: The IPv4 home address mobility support enables an MN in a
PMIP6 domain to be assigned an IPv4 HoA by an LMA in a PMIP6 domain
and continue to maintain the assigned IPv4 HoA even as the MN moves
and attaches to different MAGs within the PMIP6 domain.

>   Additionally, If the mobile node connects to the Proxy Mobile IPv6
>   domain, through multiple interfaces and simultaneously through
>   different access networks, each of the connected interfaces will
>   obtain an IPv4 home address from different subnets.  In such
>   scenario, there will be multiple Binding Cache entries for the mobile
>   node on the local mobility anchor.

Q: All the MAGs are expected to indicate the same LLA. So how does the
MN know that it is attached to different access routers when connected via
different interfaces? Or maybe it does not matter whether it is connected to
the same MAG or to a different MAG.

>  o  The mobile node may release its IPv4 home address at any time by
>      sending the DHCPRELEASE message [RFC-2131].  When the mobile
>      access gateway detects the DHCPRELEASE message sent by the mobile
>      node, it should consider this as a trigger for de-registering the
>      mobile node's IPv4 home address.  It will apply the considerations
>      specified in section 3.2.3.3 for performing the de-registration
>      procedure.  However, this operation MUST NOT release any IPv6 home
>      network prefix(es) assigned to the mobile node.

The above text does not specify how deregistration is handled in
different scenarios, i.e when the DHCP server is co-located with the
MAG or when the MAG is acting as a DHCP relay only.

>   o  The mobile access gateway can be potentially in a private IPv4
>      network behind a NAT [RFC-3022] device, with a private IPv4
>      address configured on its egress interface.  But, the local
>      mobility anchor must not be behind a NAT and must be using a
>      globally routable IPv4 address.  However, both the local mobility
>      anchor and the mobile access gateway can be in the same private
>      IPv4 routing domain, i.e., when both are configured with private
>      IPv4 addresses and with no need for NAT translation between them.

Why is this scenario required? The I-D would be much simpler without
having to deal with private PCoA addresses.

>4.1.3.3.  NAT Presence Detection

Better to get rid of this feature by requiring only globally routable
IPv4 addresses assigned as PCoA to the MAGs.

- The I-D does not specify clearly the security requirements. It would
  be good to at least state that the same security requirements of
  RFC5213 apply here as well.

-Raj