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

[Jari Arkko <[e-mail]>]

Spencer,

Thanks for your review! Sri, Ryuji -- any comments? I have also inserted 
few comments inline.

> 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...

Yes...

>      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)

Yes.

>      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.

Perhaps it would help if the statement about requiring at least one of 
the options was separate from the description of what to do when these 
options are present.

>      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.

Yes, please.

> 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.

I agree.

>   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. 

That's right.

> 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.

While adding rules about when taking a SHOULD is useful, I do not think 
it is an absolute rule. Generally speaking, SHOULD says that you can 
disobey it but only if you fully understand the implications.

>
> ...
>
>   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?

Yes, seems so.

>
>         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"?

Yes.

>
>      *  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.
>
>
>
Jari