ietf
[Top] [All Lists]

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

2009-05-18 13:34:03
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

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>