[netlmm] Comments on draft-ietf-netlmm-pmip6-ipv4-support-04.txt

Hello Ryuji and Sri,

I've read through the draft.  It seems to be basically very
complete and well-written.  I found a number of typos and
have a few questions about the draft.  Two questions
overall:
- Doesn't MAG basically only have to check once for the
   presence of NAT on its IPv4 path to the LMA?
- Wouldn't it be better to avoid multiple round trips to
   handle the DHCP configuration of the home address.
As a general editorial comment, I found that the document
seems to go to extremes to avoid using the acronyms
LMA and MAG.  While I am a big fan of avoiding too
much alphabet soup, acronyms are often useful to
immediately denote something that is so frequently
encountered in the text.  On a scale from 0 to 10,
the document currently scores approximately 0 for
use of those two acronyms.  Maybe a score of about
6-7 would be more reasonable :-)

Herewith are my more detailed comments:

Abstract:
- "For extending"  -- delete "For", use lower case
- "For allowing"  -- delete "For", use lower case

Section 1.  Overview
- "further the mobile" --> "furthermore the mobile"

Figure 1:

This figure is designed to illustrate the features
mentioned in the preceding two bullet points.
However, one has to be clever and observant to
figure this out, and to determine what the acronyms
probably mean.  For instance, my guess is that we
are shown two dual-homed mobile nodes, and that
we should assumke all unqualified interface addresses
are IPv6 addresses.  Maybe it would be easier to
put in a short paragraph below the figure to make
it clearer to those not interested in puzzle-solving.
Or, more radically, to determine whether the figure
really adds value to the document in the first place.

Later in the document, there is additional explanation
for the terminology in the Figure.  If the figure is
maintained, it would be better to locate these
explanations closer to the placement of the figure,
perhaps by moving the figure itself.

Section 1.1.  Stated Assumptions
- "Following" --> "The following"

- pg.6:
  "Its is not for the exclusive use" -->
    "It is not for the exclusive use"

But, I do not see why this assumption is important for the
rest of the specification.

- pg.9:
   "IPv4-over-IPv4-UDP" -- this term does not appear
        elsewhere in the document

   "IPv4-over-IPv4-UDP-TLV" -- this term does not appear
        elsewhere in the document

However, related terms do appear.  They are defined in place
as needed (e.g., pg. 29).  I think that is more appropriate
anyway, so it would probably be better to delete the list
on page 9, or replace it with a short description of the
kinds of encapsulation specified later in the document.

Section 3.1.1.  Extensions to Binding Cache Entry
- "For supporting" --> "To support"  <also appears elsewhere>
- ?Which feature?  (answer: IPv4 home Addresses)

Section 3.1.2.1.  Processing Proxy Binding Updates
- "IPv4 Home Address option"
    This is the first instance of the option in
    the specification.  A citation is definitely
    required for at least this instance, and
    preferably some other instances as well.
    I spent a long time trying to find it --
    especially because the citation itself was
    malformed in the References section.

Section 3.1.2.3.  Binding Lifetime Extension (No handoff)
   "All the consideration" --> "All the considerations"

Section 3.1.2.5.  Binding De-Registration
   "All the consideration" --> "All the considerations"

Section 3.1.2.7.  Binding Cache Entry Lookup Considerations

   "is for using"  -->  "requires"

Section 3.2.2.  Extensions to Mobile Node's Policy Profile
- The following is not a sentence:
                                                "If the mobile access
      gateway should enable support for IPv4, IPv6 or IPv4/IPv6 home
      address mobility support."

Section 3.2.3.1.  Mobile Node Attachment and Initial Binding Registration
- "choose to request"  -->  "ask"        (2 occurrences)

Section 3.3.1.  IPv4 Default-Router Address Option
- The caption, "Figure 3: IPv4 Default-Router Address Option",
    should precede the field definitions.

Section 3.3.2.  Status Codes
- Unfortunate and confusing pagination should be repaired.

Section 3.4.  Supporting DHCP Based Address Configuration

- The following sentence is missing the word "be":
                                               This address can either
      the IPv4 Proxy Care-of Address or the mobile node's default-router
      address provided by the local mobility anchor.

- It should be clarified that the following recommendation is only
  needed for multihomed mobile nodes:
                                                            Thus, it is
      recommended that the DHCP client in the mobile node is configured
      to use a stable client identifier that does not change during the
      active life of that DHCP session.

- Again, unfortunate pagination at the bottom of pg. 23 should be fixed.

- "At an" --> "If at any" in:
   o  At an point the mobile access gateway fails ...

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

- Since the second possibility is an example of the first one, replace:
                                                              "or is co-
   located with the local mobility anchor."
by:
                                                              "(e.g., is
   co-located with the local mobility anchor)."

- "DHCPDISCOVERY" --> "DHCPDISCOVER"    (multiple occurrences)

- "Figure 6 are the sequence"  -->  "Figure 6 shows the sequence"

- The outlined procedure will require an additional round-trip and
  exhibit more error cases for the common scenario where the LMA
  is also the DHCP Server.  The MAG _could_ check to see whether its
  configured LMA address is the same as the configured DHCP server
  address.  If so, with a small bit of additional design these two
  functions could be coalesced.  Likely as not, this has already been
  discussed.  I'll try to make some time to search the archives and
  follow up on previous discussion if it is there.

- "(No Hanover)"  -->  "(No Handover)"

- "cost of packets monitoring"  -->  "cost of monitoring packets"

- "by indicating the error codes"  -->  "as indicated by the error codes"

- "XXXX":
    Aren't DHCP clients likely to handle this correctly?
    Do the XXXXs indicate some problem with the text here?

Section 4.  IPv4 Transport Support

- "using only an IPv4 address"  -->  "using an IPv4 address"

- "Additionally, both these entities are also"  -->  "Both entities are 
also"

- "on its interfaces, as"  -->  "on their interfaces, as"

Regarding the following restriction:
    "are reachable only over an IPv4 transport."
This is unnecessary.  It could be that one of them is reachable
via IPv6, but just not by the other entity.  It could also be
that for some reason the IPv4 addressability is more useful to
the network operator -- who knows why?

Replace:
                                                   However, the local
      mobility anchor must not be behind a NAT and must be using a
      globally routable IPv4 address
by:
                                                   However, the local
      mobility anchor must be using a globally routable IPv4 address

- At the top of pg. 28, is UDP required even when there is no NAT?

- "is agnostic to" -->  "does not depend on".  Also, this bullet item
  should be made into two sentences, deleting "and".

Citations are also required for these two support encapsulation types:
      *  IPv4

      *  IPv4-UDP (Payload packet carried in an IPv4 packet with UDP
         header)

Missing parenthesis in:
      *  IPv4-UDP-ESP (Payload packet carried in an IPv4 packet with UDP
         and ESP headers.  Refer to [RFC-3948].

Regarding:
                However, if the received Proxy Binding Update message is
      not sent as an IPv4 packet, this field MUST be set to ALL_ZERO
      value.

This is somewhat confusing.  Does it mean if the PBU is not encapsulated
using one of the supported IPv4 encapsulation types?   Also, the first
two sentences of the paragraph clash.  It would be better to say something
like "If NAT ..., then the NAT translated address is needed".

- "indicating if" --> "indicating whether or not"

- "be different at different mobile access gateway" -->
    "vary at different mobile access gateways"

Regarding:
   o  All the considerations from Section 5.3.1 of [RFC-5213] MUST be
      applied on the encapsulated Proxy Binding Update message, after
      removing the outer IPv4 UDP header.
... What if IP4-in-IPv4 encapsulation is used?

- "detecting the NAT in the path"  -->  "detecting any NAT in the path"

Replace:
      *  If the NAT is detected on the path, then the encapsulation mode
         for the tunnel MUST be set to IPv4-UDP.  Otherwise the
         encapsulation mode MUST be set to IPv4.  However, if the (F)
         flag in the received Proxy Binding Update message is set to
         value of 1 and even if NAT is not detected, then the
         encapsulation mode MUST be set to IPv4-UDP.
by:
      *  If a NAT is detected on the path, or if the (F) flag in the
         received Proxy Binding Update message is set to the value of 1,
         then the encapsulation mode MUST be set to IPv4-UDP.  Otherwise
         the encapsulation mode MUST be set to IPv4.

Section 4.1.3.2.  Constructing the Proxy Binding Acknowledgement Message

Since the acronym PBA will be used shortly, replace:
   The local mobility anchor when sending the Proxy Binding
   Acknowledgement message to the mobile access gateway MUST construct
by:
   The local mobility anchor, when sending the Proxy Binding
   Acknowledgement (PBA) message to the mobile access gateway, MUST 
construct

Replace:
      IPv4 packet (containing the IPv6 PBA) MUST be protected using
      IPsec ESP [RFC-4301] mode and additionally there is no need to
      apply IPsec ESP header on the IPv6 packet.
by:
      IPv4 packet (containing the IPv6 PBA) MUST be protected using
      IPsec ESP [RFC-4301] mode.  There is no need to apply IPsec
      ESP header to the IPv6 packet.
Furthermore, doesn't this bullet apply even for IPv4-within-IPv4
encapsulation?

Section 4.1.3.3.  NAT Presence Detection

- "related logic is described"  -->  "related logic are described"

Section 4.1.3.3.  NAT Presence Detection

Regarding:
   When the transport network between the local mobility anchor and the
   mobile access gateway is an IPv4 network, the mobile access gateway
   will send the Proxy Binding Update messages encapsulated in the IPv4-
   UDP packet.

This only has to be done one time per (MAG,LMA) pair, right?  But,
the way this sentence is worded, an implementation might end up
using UDP for _every_ PBU for _every_ mobile node.

Section 4.2.2.  Signaling Considerations

Similarly, regarding:
   o  The Proxy Binding Update message MUST be encapsulated in an UDP
      header of an IPv4 packet.
... what if there is no NAT?

Regarding:
   o  The IPv4 Care-of Address option [ID-DSMIP6] MUST be present.
... Ahhh!  Finally, I see the citation :-)

Section 4.2.2.1.  Constructing the Proxy Binding Update Message

-  "message MUST be enabled"  -->  "message MUST be set to 1"

Section 5.1.  Local Mobility Anchor - Configuration Variables

Regarding:
   AcceptIPv4UDPEncapsulationRequest
... I can't imagine why this is needed...  Could you put
some explanation into the text?

Likewise in section 5.2, for
   RequestIPv4UDPEncapsulationSupport
... why is this needed?

Section 10.1.  Normative References
- draft-ietf-mip6-mext-nemo-v4traversal-05.txt -->
         draft-ietf-mext-nemo-v4traversal-05.txt

Regards,
Charlie P.

_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www.ietf.org/mailman/listinfo/netlmm