[Gen-art] Gen-ART Last Call review for draft-ietf-netlmm-pmip6-ipv4-support-12

["Spencer Dawkins" <[e-mail]>]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-netlmm-pmip6-ipv4-support-12
Reviewer: Spencer Dawkins
Review Date: 2009-05-18
IETF LC End Date: 2009-05-18
IESG Telechat date: 2009-05-21

Summary: This draft is almost ready for publication as a Proposed Standard. 
There are a small number of minor comments listed below, most of which are 
either about text clarity or 2119 language.

I have also included a small number of nits, for the convenience of the 
editor. These nits are not part of the Gen-ART review.

1.1.  Stated Assumptions

   The following are the configuration requirements from the mobility
   entities in the Proxy Mobile IPv6 domain for supporting the
   extensions defined in this document.

   o  The local mobility anchor and the mobile access gateway are both
      IPv4 and IPv6 enabled.  Irrespective of the type of transport

Spencer (nit): is this saying "BOTH the local mobility and the mobile
access gateway are enabled for BOTH IPv4 and IPv6"? If so, this might be
said more clearly...

      network (IPv4 or IPv6) separating these two entities, the mobility
      signaling is always based on Proxy Mobile IPv6 [RFC-5213].


2.2.  Terminology

   Selective De-registration

      It is a procedure for partial de-registration of all the addresses

Spencer (nit): s/It is a/A/ (just reads oddly to me in a technical
specification)

      that belong to one address family, i.e., de-registration of either
      IPv4 home address, or all of the IPv6 home network prefixes.

3.1.2.1.  Processing Proxy Binding Updates

   The processing rules specified in Section 5.3 of [RFC-5213] are
   applied for processing the received Proxy Binding Update message.
   However, if the received Proxy Binding Update message has an IPv4
   Home Address option [ID-DSMIP6], the following considerations MUST be
   applied additionally.

   o  If there is an IPv4 Home Address option [ID-DSMIP6] present in the
      received Proxy Binding Update message, but if there is no Home
      Network Prefix option [RFC-5213] present in the request, the local
      mobility anchor MUST NOT reject the request as specified in
      Section 5.3.1 of [RFC-5213].  At least one instance of any of
      these two options MUST be present.  If there is not a single

Spencer (minor): I'm confused by "these two options" - this MUST (and the
next MUST) are already in text that's conditional on an IPv4 Home Address
option being present, and the only other option that's named is Home Network
Prefix option. I'm not sure which "two options" are being discussed.
Should this text appear somewhere else (like, outside the "If there is an
IPv4 Home Address option present")? If it's in the right place, s/any of
these two options/either the IPv4 Home Address option or the Home Network
Prefix option/ would be clearer - but I'm not sure if I'm understanding the
intent here.

      instance of any of these two options present in the request, the
      local mobility anchor MUST reject the request and send a Proxy
      Binding Acknowledgement message with Status field set to
      MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home
      network prefix option) [RFC-5213].

   o  If the prefix request(P) flag in the IPv4 Home Address option is
      set to a value of 1, then the local mobility anchor MUST reject

Spencer (nit): it would help readers if you also included an expansion of
"value of 1" in parentheses, as you do for other "magic numbers" elsewhere
in this draft. I don't see "prefix request flag" elsewhere in this
document - if that's true, it would also be lovely if you provided a
reference to the document where it is defined, but that's less important if
you provide the expansion.

      the request and send a Proxy Binding Acknowledgement message with
      the Status field set to IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED (IPv4
      prefix assignment not supported).

   o  If there exists a Binding Cache entry that can be associated with
      the request, the local mobility anchor MUST apply considerations
      from Section 5.3.1 of [RFC-5213], (point 13), to determine if the
      request is re-registration or a de-registration request and the
      respective considerations from the below sections MUST be applied.

Spencer (nit): it would help readers if you could point to specific sections
below (because there are a lot to choose from!), as you do in similar text 
elsewhere in the document.

   o  If there exists a Binding Cache entry that can be associated with
      the request and if it is determined that the request is a re-
      registration request and with the request to extend IPv4 home
      address mobility support to the existing IPv6-only mobility
      session, considerations from Section 3.1.2.2 MUST be applied with
      respect to IPv4 support.

3.1.3.  Routing Considerations for the Local Mobility Anchor

   Intercepting Packets Sent to the Mobile Node's IPv4 home address:

   o  When the local mobility anchor is serving a mobile node, it MUST
      be able to receive packets that are sent to the mobile node's IPv4
      home address.  In order for it to receive those packets, it MUST
      advertise a connected route in to the Routing Infrastructure for
      the mobile node's IPv4 home address or for its home subnet.  This

Spencer (minor): The first MUST doesn't seem to be a 2119 MUST - I think
it's stating a goal that the second MUST achieves. Perhaps "When the local
mobility anchor is serving a mobile node, it MUST advertise a connected
route in to the Routing Infrastructure for the mobile node's IPv4 home
address or for its home subnet, in order to receive packets that are sent to
the mobile node's IPv4 home address."?

      essentially enables IPv4 routers in that network to detect the
      local mobility anchor as the last-hop router for that subnet.

3.2.3.2.  Receiving Proxy Binding Acknowledgement

   All the considerations from section 6.9.1.2 of [RFC-5213] MUST be
   applied with the following exceptions.

Spencer (minor): not sure why the next two bullets are SHOULD NOTs - we
usually provide at least one example of why an implementation would choose
not to perform SHOULD NOTs, for background.

   o  If the received Proxy Binding Acknowledgement message has the
      Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The
      mobile node is not authorized for IPv4 home address), the mobile
      access gateway SHOULD NOT send a Proxy Binding Update message
      including the IPv4 Home Address option [ID-DSMIP6] till an
      administrative action is taken.

   o  If the received Proxy Binding Acknowledgement message has the
      Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The
      mobile node is not authorized for the requesting IPv4 home
      address), the mobile access gateway SHOULD NOT request for the
      same address again, but MAY request the local mobility anchor to
      do the assignment of address by including exactly one instance of
      IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address
      and the prefix length fields in the option set to ALL_ZERO value.

...

   o  If there is an IPv4 DHCP Support Mode option present in the
      received Proxy Binding Acknowledgement message and if the (S) flag
      in the option is set to a value of 1, then the mobile access

Spencer (nit): again, I'd suggest providing an expansion in paretheses
wherever you have a "value of (magic number)" in the text, just to help the
reader. Most of the time, you already provide these.

      gateway MUST function as a DHCP server for the mobile node.  If
      either the (S) flag in the option is set to a value of 0, or if
      the option is not present in the request, then the mobile access
      gateway MUST function as a DHCP Relay for the mobile node.

3.3.1.  IPv4 Default-Router Address Option

   A new option, IPv4 Default-Router Address Option is defined for using
   it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the
   local mobility anchor to the mobile access gateway.  This option can
   be used for sending the mobile node's IPv4 default-router address.

   The IPv4 Default-Router Address option has an alignment requirement
   of 4n.  Its format is as follows:


       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 (R)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  IPv4 Default-Router Address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 3: IPv4 Default-Router Address Option

      Reserved (R)

         This 8-bit field is unused for now.  The value MUST be

Spencer (minor): in the figure, it's a 16-bit field, isn't it?

         initialized to 0 by the sender and MUST be ignored by the
         receiver.

3.4.1.  DHCP Server co-located with the Mobile Access Gateway

   This section explains the operational sequence of home address
   assignment operation when the DHCP server is co-located with the
   mobile access gateway.


   MN   MAG(DHCP-S)  LMA
    |------>|        |    1. DHCPDISCOVER
    |       |------->|    2. Proxy Binding Update
    |       |<-------|    3. Proxy Binding Acknowledgement (IPv4 HoA)
    |       |========|    4. Tunnel/Route Setup
    |<------|        |    5. DHCPOFFER  (IPv4 HoA)
    |------>|        |    6. DHCPREQUEST (IPv4 HoA)
    |<------|        |    7. DHCPACK
    |       |        |
    * DHCPDISCOVER (Step-1) and Proxy Mobile IPv6 signaling
    * (Step-2 to Step-4) may happen in parallel and in no specific order

Spencer (minor): Isn't this "Step-2 AND Step-4"? The text says you can get 
the ACK (Step-3) before you send the Proxy Binding Update (Step-2) ... :-) 
Similar text appears in other ladder diagrams below.

    * Tunnel/Route setup(Step-4) and the subsequent steps will happen in
    * in the specified order.


    Figure 5: Overview of DHCP Server located at Mobile Access Gateway


3.4.2.  DHCP Relay Agent co-located with the Mobile Access Gateway

   o  Any time the mobile access gateway detects that the mobile node
      has released its IPv4 address, it can send a Proxy Binding Update
      to the local mobility anchor and de-register the IPv4 mobility
      session.

Spencer (nit): in the next section, similar text about releasing its IPv4 
address includes this phrase: "by sending the DHCPRELEASE message 
[RFC-2131]", and explains how the mobile access gateway detects the release. 
Is it worth having the same phrase here?

4.1.3.2.  Constructing the Proxy Binding Acknowledgement Message

   o  If the mobile access gateway and the local mobility anchor are
      using globally routable IPv4 addresses and if there is a security
      association that is based of IPv4 addresses, then the encapsulated

Spencer (nit): s/based of/based on/

      IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement)
      MUST be protected using IPsec ESP [RFC-4301] mode.  There is no
      need to apply IPsec ESP header to the IPv6 packet.  In all other
      cases, the Proxy Binding Acknowledgement message MUST be protected
      using IPsec prior to the IPv4 or IPv4-UDP encapsulation.

      *  The encapsulation mode for the bi-directional tunnel MUST be
         set to IPv4.  However, if the value of the configuration
         variable, UseIPv4UDPEncapForSignalingMessages, is set to 1,
         then the following considerations MUST be applied.

Spencer (nit): would it be clearer to the reader if the previous paragraph 
was un-indented one level, so the following paragraphs are more clearly 
"following"?

      *  If there is a NAT Detection option [ID-DSMIP6] in the received
         Proxy Binding Acknowledgement message and if the value of the
         configuration flag, UseIPv4UDPEncapForSignalingMessages, is set
         to value of 1, then the encapsulation mode for the tunnel MUST
         be set to IPv4-UDP.  Otherwise the encapsulation mode MUST be
         set to IPv4.

      *  If the (T) flag in the Proxy Binding Acknowledgement message is
         set to value of 1, then the encapsulation mode MUST be set to
         IPv4-UDP-TLV.