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

Hello Charlie,

Thanks for your detailed comments!
Please find my comments inline.

On 2008/08/13, at 8:02, Charles E. Perkins wrote:

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

If same LMA is used, MAG should run that NAT check once.

> - Wouldn't it be better to avoid multiple round trips to
>  handle the DHCP configuration of the home address.

Can you elaborate on "Round trips between who"?
Is it DHCP server and mobile node?
If so, the DHCP protocol requires handshakes to complete address  
assignments.
As a design principle, we try not to modify the DHCP protocol and  
cannot skip some of DHCP sequences.

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

:-)
OK, we will follow the RFC3775 style and run the replace command!

Thanks for a lot of comments.
The editorial suggestion will be applied to the next revision.

One quick clarification.

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

We had discussion whether we really need NAT support for MAG.
Some folks suggested not to support MAG behind NAT because of  
complexity.
At the end, we agreed to keep the NAT support as an OPTION.
These flags are used to verify whether NAT support is available  on  
MAG and LMA or not.

regards,
ryuji

> 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