Subject: [netlmm] Review of draft-ietf-netlmm-pmip6-ipv4-support-17

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 8 Oct 2009 17:50:49 -0400

Hello folks,
 
I have reviewd the ID and the following are my comments.
 
Regards,
 
-Rajeev
 
High-level comments:
 
1. I think NAT on the path between MAG and LMA needs better
justification. 
Whereas it may be there, I did not find any specific arguments for
requiring this feature.
It would be better to separate the NAT part out into a separate ID; this
would simplify the protocol considerably.
 
2. Default router: At one place MAG is stated to be the MN's IPv4
default router. Elsewhere, this is provided by the LMA
   in PBA. This is confusing. Please explain who is the default router
and why there is signaling, if any.
 
3. DHCP interworking: This is a tricky issue. I don't see a
straightforward solution. I think the default (DHCP-Relay at MAG)
    should be mentioned in the beginning of the DHCP considerations
section (3.4).
 
4. LMA - MAG tunnel: there are implict assumptions that the tunnel may
be shared. This come out in bullets that describe
    processing of messages/packets. This should be at a higher level in
the section.
 
5.  There are multiple places where there is a requirement to create
host routes (followed by the choice of "other implementation-specific
     mechanisms). There should not be any normative text on host routes
per se; instead "forwarding entry" suffices.
 
6. There is dual use of prefix-len and subnet mask. I suggest sticking
to one.
 
7. There is an assumption (in 3.1.2.7) that IPv4 HoA is unique. This
need not be the case with overlapping private IPv4 addresses.
    So, the key indexing into BCE would have to be something else (e.g.,
NAI) plus IPv4 HoA. This should be clarified. 
 
More in-lined comments below:
 
Abstract:
 
   The scope of IPv4 protocol support is
   two-fold: 1) enable IPv4 home address mobility support to the mobile
   node. 2) allowing the mobility entities in the Proxy Mobile IPv6
                 ^^^^ allow 
 
Overview:
 
 Thus, it is reasonable to assume that a
   mobile node in a Proxy Mobile IPv6 domain may operate in an
   IPv4-only, IPv6-only or in dual-stack mode. [xx and] Additionally the
network
   between the mobile access gateway and a local mobility anchor may be
an IPv4
   or an IPv6 network.
 
1.1
 
   o  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]. 
RKo> If so, please revise the first sentence.

   o  The mobile node's IPv4 home subnet is typically a shared address
      space.  It is not for the exclusive use of any one mobile node.
      There can be multiple mobile nodes that are assigned IPv4
      addresses from the same subnet.
 
RKo> What is the intent of above bullet? Are you saying that the MN
cannot be a mobile router (that owns a subnet prefix)?
 
1.2

   If a given home agent [RFC-3775] implementation has support for both
   Dual-stack Mobile IPv6 [RFC-5555] and local mobility anchor function
   [RFC-5213], when extending IPv4 support as specified in this document
   the above common functions and the related considerations have to be
   reused for Proxy Mobile IPv6 signaling flows.
 
RKo> "..above common functions and the related considerations have to be
   reused..". 
   'Re-using related considerations' is pretty vague. If we could not
live with the common functions, please revise the sentence.
 
3.1.1
 
   o  The IPv4 home address assigned to the mobile node's interface and
      registered by the mobile access gateway.  The IPv4 home address
      entry also includes the corresponding subnet mask.  It is to be
      noted that this parameter is defined in the [RFC-5555] and is
      presented here for completeness.
 
RKo> Wouldn't you need the IPv4-Proxy-CoA in the BCE? You probably
mean it by "..registered by the MAG", but this needs to be explicit.

   o  The IPv4 default router address assigned to the mobile node.
RKo> Please state why
 
3.1.2.1
 
   o  If there is at least one instance of Home Network Prefix option
      [RFC-5213] present in the received Proxy Binding Update message,
      but either if it is known from the mobile node's policy profile
      that the mobile node is not authorized for IPv6 service or if IPv6
      routing not enabled in the home network, the local mobility anchor
      MUST reject the request and send a Proxy Binding Acknowledgement
      message with the Status field set to
      NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not
      authorized for IPv6 mobility service).
 
RKo> Shouldn't the above bullet be in 5213? Why is IPv6 HNP option
processing defined here? (Duplication leads to inconsistency)
 
3.1.2.4

   o  The local mobility anchor MUST remove the previously created IPv4
      host route (or the forwarding state) and the dynamically created
      bi-directional tunnel for carrying the IPv4 payload traffic (if
      there are no other mobile nodes for which the tunnel is being
      used). 
RKo>  sharing the tunnel should be implementation-specific. Here,
there is a requirement to remove the tunnel assuming that it may be
shared. In the previous section, there is no mention of a shared
tunnel in:
 
  " o  The local mobility anchor MUST establish a bi-directional tunnel
      to the mobile access gateway and with the encapsulation mode set
      to the negotiated mode for carrying the IPv4 payload traffic... "

   o  The local mobility anchor MUST create a bi-directional tunnel to
      the mobile access gateway that sent the request (if there is no
      existing bi-directional tunnel) and with the encapsulation mode
      set to the negotiated mode for carrying the IPv4 payload traffic.
      An IPv4 host route for tunneling the packets received for the
      mobile node's IPv4 home address MUST also be added.
 
RKo> Why is there emphasis on host routes? Wouldn't it suffice to say
"create a forwarding entry for the IPv4 HoA"? Same comment applies
elsewhere..
 
3.1.2.5.  Binding De-Registration
 
   All the considerations from Section 5.3.5 of [RFC-5213] MUST be
   applied.  Additionally, for removing the IPv4 state as part of the
   Binding Cache entry deletion, the IPv4 host route and the dynamically
   created bi-directional tunnel for carrying the IPv4 payload traffic
   (if there are no other mobile nodes for which the tunnel is being
   used) MUST be removed.  However, if the request is for a selective
   de-registration (IPv4 home address only, or all the IPv6 home network
   prefixes), the Binding Cache entry MUST NOT be deleted, only the
   respective states with respect to those addresses MUST be deleted.
 
RKo> It would be useful to reference the section where Selective
De-registration is specified.

3.1.2.6

      1.  If the Status field is set to a value greater than or equal to
          (128), i.e., if the Proxy Binding Update is rejected, then
          there MUST be an IPv4 Home Address Reply option corresponding
          to the IPv4 Home Address Request option present in the request
          and with the IPv4 address value and the prefix length fields
          in the option set to the corresponding values in the request.
 
RKo> Suggest breaking the last sentence into two:
 
          "If the Status field is set to a value greater than or equal
to
          (128), i.e., if the Proxy Binding Update is rejected, then
          there MUST be an IPv4 Home Address Reply option corresponding
          to the IPv4 Home Address Request option present in the
          request. The IPv4 address value and the prefix length fields
          in the IPv4 Home Address Reply option MUST be copied from
          the corresponding values in the IPv4 Home Address Request
          option."
 
(Why is there prefix-len vs. subnet mask?)
 
3.1.2.7
 
 o  The search rules specified in section 5.4.1.1 of [RFC-5213], which
      primarily uses IPv6 home network prefix set as the search key, are
      equally valid when using a single IPv4 home address as the key.
      When applying those considerations, instead of the IPv6 home
      network prefix(es), the IPv4 home address from the IPv4 Home
      Address option present in the request MUST be used as the search
      key.
 
RK> this assumes that IPv4 HoA is unique. This is not the case when
using private IPv4 addresses. 

3.1.3
 
   o  The format of the tunneled packet when payload protection is not
      enabled:

        IPv6 header (src= LMAA, dst= Proxy-CoA       /* Tunnel Header */
           IPv4 header (src= CN, dst= IPv4-MN-HOA )  /* Packet Header */
              Upper layer protocols                  /* Packet Content*/

                   Figure 2: Tunneled Packets from LMA to MAG
 
RKo>  This Figure is somewhat out of place. Also, it assumes that the
outer header is IPv6. Suggest removing it.

  Forwarding Packets Sent by the Mobile Node:
 
   o  All the reverse tunneled packets that the local mobility anchor
      receives from the mobile access gateway, after removing the tunnel
      header MUST be routed to the destination specified in the inner
      IPv4 packet header.  These routed packets will have the source
      address field set to the mobile node's IPv4 home address.
 
RKo> If I remember right, this started with MIP4 :-) 
(I mean I did not see why this is not redundant here)
 
3.2.1
 
   o  The IPv4 home address assigned to the mobile node's attached
      interface.  This IPv4 home address may have been statically
      configured in the mobile node's policy profile, or, may have been
      dynamically allocated by the local mobility anchor.  The IPv4 home
      address entry also includes the corresponding subnet mask.
 
RKo> SO, here there is subnet mask, but elsewhere it is prefix-len.
     Isn't subnet mask appropriate throughout?
 
   o  The IPv4 default router address of the mobile node.  This is
      acquired from the mobile node's local mobility anchor through the
      received Proxy Binding Acknowledgment message.
 
RKo> Please state why this is to be maintained.
 
3.2.3.2

   o  If there is no IPv4 Home Address Reply option present in the
      received Proxy Binding Acknowledgement message, the mobile access
      gateway MUST NOT enable IPv4 support for the mobile node and the
      rest of the considerations from this section can be skipped.
 
RKo> Why isn't this bullet the first bullet?
 
  o  If the received Proxy Binding Acknowledgement message has the
      Status field value set to 0 (Proxy Binding Update accepted) and
      has the IPv4 Home Address Reply option set to a value that
      indicates that the request was accepted by the local mobility
      anchor, the mobile access gateway MUST establish a bi-directional
      tunnel to the local mobility anchor (if there is no existing bi-
      directional tunnel to that local mobility anchor) and with the
      encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6
      packet carried as a payload of an IPv6 packet).  Considerations
      from Section 5.6.1 of [RFC-5213] MUST be applied for managing the
      dynamically created bi-directional tunnel.  However, when using
      IPv4 transport, the encapsulation mode MUST be set to the
      negotiated encapsulation mode, as specified in Section 4 of this
      specification.
 
RKo> Does this document assume that the default encapsulation mode is
*-over-IPv6? Reading the above bullet could lead to such an
interpretation. Perhaps it is best to capture this at a high level in
the Introduction, OR move all transport considerations to Section 4.
 
   o  The default router address MUST be obtained from the IPv4 Default-
      Router Address option present in the received Proxy Binding
      Acknowledgement message.  The mobile access gateway SHOULD
      configure this address on its interface and respond to any ARP
      requests sent by the mobile node for resolving the hardware
      address of the default router.  However, since the link between
      the mobile access gateway and the mobile node is a point-to-point
      link, implementations will be able receive any packets sent to the
      default router address without having to explicitly configure the
      default router address on its interface.  The mobile access
      gateway MAY also use the default router address as the source
      address for any datagrams sent to the mobile node and originated
      by the mobile access gateway itself.  It MUST also use this
      address in the DHCP Router option [RFC-2132] in the DHCP messages.
 
RKo> Isn't the MAG itself the default router? The reasons for getting
a default router address in PBA are not clear..
 
3.2.4
 
   o  When forwarding the packet through the bi-directional tunnel, the
      encapsulation considerations specified in section 3.1.3 MUST be
      applied.  However, before forwarding the packet, the mobile access
      gateway MUST ensure the source address in the received packet is
      the address allocated for that mobile node and that there is an
      active binding on the local mobility anchor for that mobile
      node.
 
RKo> MAG can only make sure that _it_ has a binding for the MN. It
cannot be sure that LMA has an active binding - LMA may have rebooted
recently
that the MAG is unaware of (as an example). So, the above MUST for
ensuring that there is an active binding at LMA, despite the intent,
is not accurate.  

   o  The mobile access gateway SHOULD use Proxy ARP [RFC-925] to reply
      to ARP Requests that it receives from the mobile node seeking
      address resolutions for the destinations on the mobile node's home
      subnet.  When receiving an ARP Request, the local mobility anchor
RKo>
^^^^^^^^^^^^
      is it the LMA or the MAG?

3.4
 Any time the mobile node
         performs an handoff of a physical interface to a different
         mobile access gateway, using the same interface, the DHCP
         server will always be able to identify the binding using the
RKo>                 ^^^^^^^^^^^^^^
         This assumes that the DHCP server is not in the MAG? Or, the
new MAG somehow gets the DHCP state.
 
3.4.1
 
      The DHCPOFFER
      message will also have the subnet mask option [RFC-2132] and
      router option [RFC-2132], with the values in those options set to
      the mobile node's IPv4 home subnet mask and default router address
RKo> Here it is assumed that IPv4 HoA returned by the LMA has subnet
mask (and not prefix-len) 
 
 Additionally, the Server Identifier option will be
      included and with the value in the option set to the default
      router address.
RKo> So, this default router address is the MAG's address or what is
provided by the LMA in PBA?

   o  Any time the mobile node goes into the DHCP RENEWING state [RFC-
 
RKo> RENEW or RENEWING?

 However, if
      the mobile access gateway is unable to complete the Proxy Mobile
      IPv6 signaling or is unable to acquire the same IPv4 address as
      requested by the mobile node, it will send a DHCPNACK message
      [RFC-2131] to the mobile node, as shown in Figure 8-1).
RKo> Add a sentence that session continuity cannot be provided.
 
3.4.3
 
   o  When a mobile node sends a DHCPDISCOVER message [RFC-2131], the
      DHCP server or the relay agent co-located with the mobile access
      gateway will trigger the mobile access gateway to complete the
      Proxy Mobile IPv6 signaling.  This is the required interaction
      between these two protocols. 
RKo> However, all the figures above state that PMIP6 signaling is
independent of DHCP signaling!

   o  The mobile node needs to be identified by the MN-Identifier, as
      specified in Section 6.6 of [RFC-5213].  This identity should be
      associated to the DHCP messages sent by the mobile node.
RKo> What does the last sentence mean?
 
4 IPv4 Transport
   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.
 
RKo> Inclusion of NAT between LMA and MAG needs some justification.
I think the protocol can be simpler without NAT considerations. (This
does not mean that there is no support for private IPv4 HoA)
 
4.1.1
 
   o  The IPv4 NAT translated address of the mobile access gateway.  If
      the mobile access gateway is not behind a NAT [RFC-3022], this
      address will be the same as the address configured on the egress
      interface of the mobile access gateway.  This address can be
      obtained from the IPv4 header of the received Proxy Binding Update
      message.  However, if the received Proxy Binding Update message is
      not sent as an IPv4 packet, this field in the Binding Cache entry
      MUST be set to ALL_ZERO value.
 
RKo> Why is there a requirement to maintain this address regardless of
the presence of the NAT? When there is no NAT, you will be maintaining
the same address twice? 
 
4.1.3.3.  NAT Presence Detection
 
   When the transport network between the local mobility anchor and the
   mobile access gateway is an IPv4 network and if the received Proxy
   Binding Update message was sent encapsulated in IPv4 UDP header, the
   local mobility anchor performs the NAT Presence Detection as
   specified below.
 
   On receiving the Proxy Binding Update message encapsulated in an IPv4
   UDP packet, the local mobility anchor, if it detects a NAT on the
RKo>                                      ^^^^^^^^^^^^^^^^^^^
    The last sentence in the previous paragraph states how LMA does
NAT Presence Detection. This sentence states "if it detects NAT". So,
where can I find NAT presence detection text?

4.1.4.1

   o  Forwarding Packets Sent by the Mobile Node:
 
      *  All the reverse tunneled packets (IPv4 and IPv6) that the local
         mobility anchor receives from the mobile access gateway, after
         removing the tunnel header (i.e., the outer IPv4 header along
         with the UDP and TLV header, if negotiated) MUST be routed to
         the destination specified in the inner packet header.  These
         routed packets will have the source address field set to the
         mobile node's home address.
 
RKo> Why isn't there a Figure for this? (Not that I would require it,
but symmetry would be nice!)
 
4.2.2.2
 
   o  Forwarding Packets received from the bi-directional tunnel:
 
   o  On receiving a packet from the bi-directional tunnel established
      with the mobile node's local mobility anchor, the mobile access
      gateway MUST remove the outer header before forwarding the packet
      to the mobile node.
 
RKo> The above bullet needs to be "tabbed"