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

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 12 Aug 2008 16:02:03 -0700

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
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 13 Aug 2008 15:20:42 +0900

Hello Charlie,

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

>  presence of NAT on its IPv4 path to the LMA?

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

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

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

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

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

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 13 Aug 2008 00:30:54 -0700 (PDT)

Hi Charlie,

Thanks for reviewing the document. Adding to Ryuji's comments ...

>  presence of NAT on its IPv4 path to the LMA?

NAT detection check is generally a perpetual operation. If
enabled, the LMA will always perform the check (address
comparison) and is not an expensive operation. If the LMA inserts
the NAT Detection option in the PBA, the MAG would detect this.

> using UDP for _every_ PBU for _every_ mobile node.

The message must always be sent over UDP, when using IPv4 transport.

> ... what if there is no NAT?

NAT detection is for the data plane, the signaling messages are always
sent in UDP.

Will fix the other editorial issues.

Regards
Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 13 Aug 2008 10:12:46 -0700

Hello Sri,

> The message must always be sent over UDP, when using IPv4 transport.

Could you explain why, and perhaps suggest some text that
would go into the draft to document the explanation?

It seems to me if there is no NAT, then UDP isn't needed.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 13 Aug 2008 10:34:28 -0700

Hello Ryuji,

> Is it DHCP server and mobile node?

I was thinking about between the MAG and the (LMA==DHCP Server)

> cannot skip some of DHCP sequences.

Right -- at least from the point of view of the mobile node.  However, what
happens between LMA and MAG to carry out DHCPv4 operations might
be considered a reasonable design point for improving performance.

> OK, we will follow the RFC3775 style and run the replace command!

Well, I hope the "replace" command doesn't go all the way
to eliminating ALL occurrences of the spelled-out names of
the functional components.  Usually, a few instances of the
fully-spelled out names in the introduction and/or overview
is sufficient to get people grounded.  In this case, even less
may be needed because it is probably assumed that people
are familiar with RFC 5123, but then at minimum the acronyms
should be explained as terminology.

> Some folks suggested not to support MAG behind NAT because of complexity.

I can understand that, and some text along those lines should go
into the draft somehow.  However, I don't think that the
specified configuration options are exactly congruous with your
stated intentions, although they are very closely related of course.

For "RequestIPv4UDPEncapsulationSupport", if the MAG does
not support NATs, then it won't use UDP encapsulation.
No configuration flag is needed... right?  And, one has to wonder
why a network administrator would install such a MAG behind
a NAT in the first place.  If that happened, no help would be
provided by making the configuration flag available.

Similarly, for "AcceptIPv4UDPEncapsulationRequest", if the
LMA does not support NATs, then the configuration parameter
isn't going to solve any problems.

I tried to think of a use for "RequestIPv4UDPEncapsulationSupport",
and all I could imagine were quite humorous scenarios.  For instance,
one could have a MAG in a NATted network with the flag disabled.
Then, when a mobile node arrives, the MAG could check the value
of the flag and ... do nothing.  Or, try to allocate a globally reachable
address from ... ?where? ... but why didn't it do that anyway already?

I would like to find some customers that were satisfied with such
equipment.  Please let me know where they are.  Or else maybe
I'm really missing the point!

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 13 Aug 2008 11:11:00 -0700 (PDT)

Hi Charlie,

> would go into the draft to document the explanation?

The use of encapsulating PMIP messages in IPv4-UDP will ensure the
delivery of the packets to the Mobile IPv6 process on the host.
If we encapaulate them in raw IPv4 packets, there needs to be
additional tunneling mechanism (IPv6-over-IPv4) to be configured
on the host and it is not enabled by default on any of the operating
systems, including Linux or NetBSD. After decap, re-routing the IPv6
packet will ensure delivery to the MIP system, but it comes with
the requirement of pre-configured tunnel.

This also follows the DSMIP precedence.

Regards
Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 13 Aug 2008 19:28:07 -0400

Sri,

The check for NAT should only be done for the first PBU between a MAG
and the LMA. I don't see why the MAG should use UDP encapsulation for a
re-refresh PBU if the first PBU/PBAck exchange indicated no presence of
a NAT.  

Vijay

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sri Gundavelli
> Sent: Wednesday, August 13, 2008 12:31 AM
> To: Charles E. Perkins
> Cc: [email-masked]
> Subject: Re: [netlmm] Comments on 
> draft-ietf-netlmm-pmip6-ipv4-support-04.txt
> 
> Hi Charlie,
>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 13 Aug 2008 17:28:46 -0700 (PDT)

Hi Vijay,

> re-refresh PBU if the first PBU/PBAck exchange indicated no presence of

When using IPv4 transport, encapsulating PMIP6 messages in IPv4 UDP
will ensure the packets are routed to the LMA process on the host on
the DSMIP port. Else, we would have to configure IPv6-over-IPv4
tunneling mode on the host, note that its not a normal routing mode
on the host.

We want message format consistency. Its not worth saving few bytes
and defining different option requirement in different messages and
endup with different processing logic for each message.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 13 Aug 2008 21:15:16 -0400

> tunneling mode on the host, note that its not a normal routing mode

We are talking about the MAG and the LMA here. Why can't you support
IPv6-over-IPv4 tunneling on the MAG and the LMA? What "host" are you
talking about? 

> endup with different processing logic for each message.

The processing logic for the Proxy BU contents is not going to change.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 13 Aug 2008 18:20:58 -0700 (PDT)

Vijay,

How is it done it DSMIP6 ? Is it only the initial BU that is
encapped in UDP ?

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 13 Aug 2008 21:32:11 -0400

> From: Sri Gundavelli [mailto:[email-masked]] 

> How is it done it DSMIP6 ? Is it only the initial BU that is

The DS-MIPv6 does say every BU, even those sent to refresh an existing
binding, is UDP-encapsulated. FWIW, I think it is unnecessary even for
DS-MIPv6. It is sufficient if UDP encapsulation is required for the
initial BU and the BU sent after every subnet change.

But that does not justify doing the same for PMIPv6 too. Things are not
going to change on the MAG-LMA path between two Proxy Binding Updates. 

Another related comment. It is unlikely that there are going to be NATs
between the MAG and the LMA in 3GPP deployments. UDP encapsulation for
the Proxy BU might never be required in such deployments. I don't
understand why we are mandating UDP encapsulation for every Proxy BU. I
also think we should add a configuration variable for the MAG in
draft-ietf-netlmm-pmip6-ipv4-support to not use UDP encapsulation if it
is known that there is not going to be a NAT between the MAG and the
LMA.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 13 Aug 2008 18:40:44 -0700 (PDT)

> going to change on the MAG-LMA path between two Proxy Binding Updates.

May be we should fix that draft first. There is a good reason why
that draft chose to use IPv4 encap for all BU/BA's. You can
convince your co-authors and then we can open the discussion on this
topic.

> is known that there is not going to be a NAT between the MAG and the

Does not matter, as I said before, we dont where MAG funciton might
be enabled. It might be in  a CPE device as well. Lets be bit more
open to this thought.

With out UDP encap, we need to enable the host to accept 6 over 4 mode.
Ensuring packet delivery to DSMIP port is simpler. Like I said, we also
want consistency in signaling.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 13 Aug 2008 20:29:58 -0700

Sri,

I am not convinced by your arguments.

> convince your co-authors and then we can open the discussion on this

Here you are saying we should enforce UDP encapsulation for the Proxy BU
always because DS-MIPv6 enforces it for BU. They are not the same as I
explained in my previous email. I hope you can give a better reason than
that. :)
 
> want consistency in signaling.

Here you are saying you want "consistency in signaling". But if you read my
above paragraph again, I was proposing adding a new MAG configuration flag
to the IPv4 support document that would allow the MAG to not use UDP
encapsulation at all if it is known that there is no NAT on the path between
the MAG and the LMA.

If the MAG is a CPE, as you describe above, you just need to set the
configuration flag to use UDP encapsulation always for the first PBU.

You keep referring to "enabling IPv6-over-IPv4" on the "host". What host?
The MAG and the LMA have to support IPv6-over-IPv4 anyway. Are you saying
you want to enable MAG/LMA implementations that cannot support
IPv6-over-IPv4 tunneling by forcing everyone to use UDP encapsulation all
the time? It is not clear.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 14 Aug 2008 12:08:53 -0700 (PDT)

Vijay,

> I am not convinced by your arguments.

Ditto

> explained in my previous email. I hope you can give a better reason than

Is this your response in your prev mail ?

"The DS-MIPv6 does say every BU, even those sent to refresh an existing
binding, is UDP-encapsulated. FWIW, I think it is unnecessary even for
DS-MIPv6. It is sufficient if UDP encapsulation is required for the
initial BU and the BU sent after every subnet change."

If it in unnecessary, we should fix that draft. The question still
remains, if NAT is not detected in the path during initial registration,
it is not needed for reregs as well. So, this is not different for CMIP.
If you can explain that will help. I believe the DSMIP draft is doing
the right thing of always using UDP encap mode for *signaling* messages
when using IPv4 transport.

Other than the presence of NAT, there could be firewall or what ever
reasons, we want consistency in signaling message formats. We dont
want to specify different formats and end up with different processing
behavior.

Also note that the NAT traversal (IP-UDP encap) is enabled for the data
traffic only when needed. If NAT is not there, the peers negotiate
IPv6 over IPv4 encap mode. However, for signaling we require the messages
to be encapped in IPv4-UDP and be sent to DSMIP port. As I said earlier,
if the messages are sent in IPv4 packets with no UDP header, there needs
to be additional tunneling mechanism on the LMA to handle that needs to
be enabled, its not a default behavior for a receiver to handle such
packets. Do not equate this to a dynamically created tunnel with the
IPv6-in-IPv4 encap mode, which comes up after the signaling.

While we clearly support encap of traffic in IPv4 packet (no UDP), I dont
see value in enabling that for control messages, that is the approach of
DSMIP as well.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 14 Aug 2008 16:37:43 -0400

Sri,

Ok, lets agree to disagree on the "PBU message consistency". 

However, I would still like to see the MAG configuration option to not
use UDP tunneling for the PBU messages specified, if it is known that
there is no NAT on the path. With this configuration option, you would
either use IPv6-over-IPv4 or with IPv6-in-UDP-over-IPv4 consistently.

> While we clearly support encap of traffic in IPv4 packet (no 
> UDP), 

We were not discussing that at all. You are making it appear as if you
are conceding something. :)

> I dont

This I completely disagree with. If there is not going to be NAT between
the MAG and the LMA in many of the PMIPv6 deployments, we should not be
mandating UDP encapsulation for the PBU/PBAck messages. It should be
possible to have the MAG and the LMA use plain IPv6-over-IPv4
encapsulation for all the PMIPv6 control messages. 

Vijay