[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [netlmm] New Version Notification for draft-ietf-netlmm-pmip6-ipv4-support-17 (fwd)

Hello,

I have reviewed the last version of this draft. Below are my comments.

3.1.2.1.  Processing Proxy Binding Updates

   o  If there is an IPv4 Home Address Request option 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, either the IPv4 Home Address Request option or
      the Home Network Prefix option, MUST be present.  If there is not
      a single 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].

Reword into: If there is an IPv4 Home Address Request option but no Home Network Prefix option [RFC-5213] in the received Proxy Binding Update message, 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, either the IPv4 Home Address Request option or the Home Network Prefix option, MUST be present.  If there is not a single 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 there is at least one instance of Home Network Prefix option
      [RFC-5213] present in the received Proxy Binding Update message,
      but either if it is known from the mobile node's policy profile
      that the mobile node is not authorized for IPv6 service or if IPv6
      routing not enabled in the home network, the local mobility anchor
      MUST reject the request and send a Proxy Binding Acknowledgement
      message with the Status field set to
      NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not
      authorized for IPv6 mobility service).

Reword into: If there is at least one instance of Home Network Prefix option [RFC-5213] present in the received Proxy Binding Update message but it is known from the mobile node's policy profile that the mobile node is not authorized for IPv6 service, or IPv6 routing is not enabled in the home network, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not authorized for IPv6 mobility service).

   o  If there is an IPv4 Home Address Request option present in the
      received Proxy Binding Update message, but either if it is known
      from the mobile node's policy profile that the mobile node is not
      authorized for IPv4 service or if IPv4 routing not enabled in the
      home network, the local mobility anchor MUST reject the request
      and send a Proxy Binding Acknowledgement message with the Status
      field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (mobile node
      not authorized for IPv4 mobility service).

Reword into: If there is an IPv4 Home Address Request option present in the received Proxy Binding Update message but it is known from the mobile node's policy profile that the mobile node is not authorized for IPv4 service, or IPv4 routing is not enabled in the home network, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (mobile node not authorized for IPv4 mobility service).

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

Reword into: If there exists a Binding Cache entry that can be associated with the request and if is determined that the request is a re-registration request for extending 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.2.2.  Initial Binding Registration (New Mobility Session)

   o  If there is an IPv4 Home Address Request option with the IPv4
      address in the option set to a NON_ZERO value, the local mobility
      anchor before accepting the request MUST ensure the address is
      topologically anchored on the local mobility anchor and
      furthermore the mobile node is authorized to use that address.  If
      the mobile node is not authorized for that specific address, the
      local mobility anchor MUST reject the request and send a Proxy
      Binding Acknowledgement message with the Status field set to
      NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized
      for the requesting IPv4 address).  It MUST also include the IPv4
      Home Address Reply option in the reply with the status field value
      in the option set to 129 (Administratively prohibited).

Reword into: If there is an IPv4 Home Address Request option with the IPv4 address in the option set to a NON_ZERO value, before accepting the request, the local mobility anchor MUST ensure 1) that the address is topologically anchored at the local mobility anchor and 2) that the mobile node is authorized to use that address.  If the mobile node is not authorized for that specific address, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized for the requesting IPv4 address).  It MUST also include the IPv4 Home Address Reply option in the reply with the status field value in the option set to 129 (Administratively prohibited).

Question: What does the LMA do if the address is not topologically anchored at the LMA? What's the status code?

   o  Upon accepting the request, the local mobility anchor MUST create
      a Binding Cache entry for this mobility session.  However, if the
      request also contains one or more Home Network Prefix options
      [RFC-5213], there should still be only one Binding Cache entry
      that should be created for this mobility session.  The created
      Binding Cache entry MUST be used for managing both IPv4 and IPv6
      home address bindings.  The fields in the Binding Cache entry MUST
      be updated with the accepted values for that session.

I found that bullet a bit confusing, especially "however... there should still be". How about: Upon accepting the request, if there exists a Binding Cache entry that can be associated with the Home Network Prefix option(s) [RFC-5213] present in the request
and it is determined that the request is a re-registration request for extending IPv4 home address mobility support to the existing IPv6-only mobility session, the local mobility anchor MUST update the fields in the Binding Cache entry with the accepted values for that session. If there exists no such Binding Cache entry, the local mobility anchor MUST create a new Binding Cache entry for this mobility session.  This ensures that a single
Binding Cache entry is used to manage both IPv4 and IPv6 bindings.

   o  The local mobility anchor MUST establish a bi-directional tunnel
      to the mobile access gateway and with the encapsulation mode set
      to the negotiated mode for carrying the IPv4 payload traffic.
      When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6-
      over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6
      packet).  When using IPv4 transport, the encapsulation mode is as
      specified in Section 4.0.

s/and with/with/
s/negotiated mode for carrying/mode negotiated to carry/

   o  The local mobility anchor MUST create an IPv4 host route (or a
      platform specific equivalent function that sets up the forwarding)
      for tunneling the packets received for the mobile node's home
      address associated with this mobility session.

Reword into: The local mobility anchor MUST create an IPv4 host route towards
the mobile node's home address that points to the tunnel associated with this mobility session.

3.1.2.4.  Binding Lifetime Extension (After handoff)

   o  If there is no Home Network Prefix option(s) [RFC-5213] present in
      the request, but if the Binding Cache entry associated [...]

Reword into: If there is no Home Network Prefix option(s) [RFC-5213] present in the request but the Binding Cache entry associated [...]

   o  The local mobility anchor MUST remove the previously created IPv4
      host route (or the forwarding state) and the dynamically created
      bi-directional tunnel for carrying the IPv4 payload traffic (if
      there are no other mobile nodes for which the tunnel is being
      used).  This will remove the routing state towards the mobile
      access gateway where the mobile node was anchored prior to the
      handoff.

Reword into:  The local mobility anchor MUST remove the previously created IPv4 host route. If there are no other mobile nodes for which the tunnel is being used, the local mobility anchor MUST remove the dynamically created bi-directional tunnel for carrying the IPv4 payload traffic. This will remove the routing state towards the mobile access gateway where the mobile node was anchored prior to the handoff.

   o  The local mobility anchor MUST create a bi-directional tunnel to
      the mobile access gateway that sent the request (if there is no
      existing bi-directional tunnel) and with the encapsulation mode
      set to the negotiated mode for carrying the IPv4 payload traffic.
      An IPv4 host route for tunneling the packets received for the
      mobile node's IPv4 home address MUST also be added.

Reword into: If there is no existing bi-directional tunnel to the mobile access gateway that sent the request, the local mobility anchor MUST create one with the encapsulation mode set to the negotiated mode for carrying the IPv4 payload traffic. An IPv4 host route for tunneling the packets received for the mobile node's IPv4 home address MUST also be added.

3.1.2.5.  Binding De-Registration

   All the considerations from Section 5.3.5 of [RFC-5213] MUST be
   applied.  Additionally, for removing the IPv4 state as part of the
   Binding Cache entry deletion, the IPv4 host route and the dynamically
   created bi-directional tunnel for carrying the IPv4 payload traffic
   (if there are no other mobile nodes for which the tunnel is being
   used) MUST be removed. [...]

Reword into: All the considerations from Section 5.3.5 of [RFC-5213] MUST be applied.  Additionally, for removing the IPv4 state as part of the Binding Cache entry deletion, the IPv4 host route MUST be removed, and the dynamically created bi-directional tunnel for carrying the IPv4 payload traffic MUST be removed if there are no other mobile nodes for which the tunnel is being used. [...]

3.1.2.6.  Constructing the Proxy Binding Acknowledgement Message

   o  Section 5.3.6 of [RFC-5213] requires the local mobility anchor to
      include at least one instance of Home Network Prefix option [RFC-
      5213] in the Proxy Binding Acknowledgement message that it sends
      to the mobile access gateway.  However, if the received Proxy
      Binding Update message has only the IPv4 Home Address Request
      option and did not contain the Home Network Prefix option(s), then
      the local mobility anchor MUST NOT include any Home Network Prefix
      option(s) in the reply.  However, there MUST be at least one
      instance of either the Home Network Prefix option [RFC-5213] or
      the IPv4 Home Address Reply option present in the Proxy Binding
      Acknowledgement message.

There's two 'however' above. Suggest to reword into: Section 5.3.6 of [RFC-5213] requires the local mobility anchor to include at least one instance of Home Network Prefix option [RFC-5213] in the Proxy Binding Acknowledgement message that it sends to the mobile access gateway.  However, if the received Proxy Binding Update message has the IPv4 Home Address Request option and does not contain the Home Network Prefix option(s), then the local mobility anchor MUST NOT include any Home Network Prefix options in the reply. There MUST be at least one instance of either the Home Network Prefix option [RFC-5213] or the IPv4 Home Address Reply option present in the Proxy Binding Acknowledgement message.

   o  The IPv4 Home Address Reply option MUST be present in the Proxy
      Binding Acknowledgement message.

Insert: "as per the requirements below" before the period.

   o  The IPv4 Default-Router Address option MUST be present, if the
      Status field value in the Proxy Binding Acknowledgement message is
      set to 0 (Proxy Binding Update Accepted).  Otherwise, the option
      MUST NOT be present.  If the option is present, the default router
      address in the option MUST be set to the mobile node's default
      router address.

Shouldn't the IPv4 Default-Router Address option present only if the IPv4 Home Address Reply option is present as well?

3.1.2.7.  Binding Cache Entry Lookup Considerations

   The Binding Cache entry lookup considerations specified in section
   5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213]
   as the key parameter for identifying the Binding Cache entry.
   However, when there is not a single Home Network Prefix option with a
   NON_ZERO value present in the request, but if there is an IPv4 Home
   Address option with a NON_ZERO value present in the request, then the
   following considerations MUST be applied.

Reword the second sentence into: "However, when the request contains an IPv4 Home Address option but no Home Network Prefix option with a NON_ZERO value, then the following considerations MUST be applied."

   o  These rules specified in section 5.4.1.1 of [RFC-5213], assume the
      presence of one or more IPv6 home network prefixes in the received
      request and also in the Binding Cache entry.  But, when using the
      IPv4 home address as the search key, these considerations MUST
      always assume just one single IPv4 home address, both in the
      request and also in the Binding Cache entry.

s/These rules/The rules/

Reword into "The rules specified in section 5.4.1.1 of [RFC-5213] assume the presence of one or more IPv6 home network prefixes in both the received request and the Binding Cache entry.  However, when using the IPv4 home address as the search key, these considerations MUST assume that a single IPv4 home address is present in both the received request and the Binding Cache entry."

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
      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.  This essentially enables IPv4 routers in that
      network to detect the local mobility anchor as the last-hop router
      for that subnet.

s/in to/into/

   o  All the reverse tunneled packets that the local mobility anchor
      receives from the mobile access gateway, after removing the tunnel
      header MUST be routed to the destination specified in the inner
      IPv4 packet header.  These routed packets will have the source
      address field set to the mobile node's IPv4 home address.

Reword into: "All the reverse tunneled packets that the local mobility anchor receives from the mobile access gateway MUST be forwarded to the destination specified in the inner IPv4 packet header after removal of the outer tunnel header. These packets will have the source address field set to the mobile node's IPv4 home address."


3.2.3.1.  Mobile Node Attachment and Initial Binding Registration

      *  The mobile access gateway MAY also ask the local mobility
         anchor for dynamic IPv4 home address allocation.  It can
         include exactly one instance of the IPv4 Home Address option
         with the IPv4 home address and the prefix length fields in the
         option set to ALL_ZERO value.  Furthermore, the (P) flag in the
         option MUST be set to 0.  This essentially serves as a request
         to the local mobility anchor for the IPv4 home address
         allocation.

Removes "essentially", or list what this does besides requesting IPv4 address allocation.

3.2.3.2.  Receiving Proxy Binding Acknowledgement

   o  If the received Proxy Binding Acknowledgement message has the
      Status field value set to 0 (Proxy Binding Update accepted), the
      mobile access gateway MUST update a Binding Update List entry for
      that mobile node.  The entry MUST be updated with the assigned
      IPv4 home address and other accepted registration values

   o  If the received Proxy Binding Acknowledgement message has the
      Status field value set to 0 (Proxy Binding Update accepted) and
      has the IPv4 Home Address Reply option set to a value that
      indicates that the request was accepted by the local mobility
      anchor, the mobile access gateway MUST establish a bi-directional
      tunnel to the local mobility anchor (if there is no existing bi-
      directional tunnel to that local mobility anchor) and with the
      encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6
      packet carried as a payload of an IPv6 packet).  Considerations
      from Section 5.6.1 of [RFC-5213] MUST be applied for managing the
      dynamically created bi-directional tunnel.  However, when using
      IPv4 transport, the encapsulation mode MUST be set to the
      negotiated encapsulation mode, as specified in Section 4 of this
      specification.

   o  The mobile access gateway MUST set up the route for forwarding the
      IPv4 packets received from the mobile node (using its IPv4 home
      address) through the bi-directional tunnel set up for that mobile
      node.

   o  The default router address MUST be obtained from the IPv4 Default-
      Router Address option present in the received Proxy Binding
      Acknowledgement message.  The mobile access gateway SHOULD
      configure this address on its interface and respond to any ARP
      requests sent by the mobile node for resolving the hardware
      address of the default router.  However, since the link between
      the mobile access gateway and the mobile node is a point-to-point
      link, implementations will be able receive any packets sent to the
      default router address without having to explicitly configure the
      default router address on its interface.  The mobile access
      gateway MAY also use the default router address as the source
      address for any datagrams sent to the mobile node and originated
      by the mobile access gateway itself.  It MUST also use this
      address in the DHCP Router option [RFC-2132] in the DHCP messages.

Why are the four bullets above separate? In particular, can the first bullet happens but not the second? It seems to me they should happen together and should be merged. Also, the part on setting up the bidirectional tunnel is using parenthesis while their content is not parenthetical. I suggest to reword "the mobile access gateway MUST establish a bi-directional tunnel to the local mobility anchor (if there is no existing bi-directional tunnel to that local mobility anchor) and with the encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 packet)" into "the mobile access gateway MUST establish a bi-directional tunnel to the local mobility anchor with the encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 packet) if there is no existing bi-directional tunnel to that local mobility anchor"

3.2.4.  Routing Considerations for the Mobile Access Gateway

   o  The mobile access gateway SHOULD use Proxy ARP [RFC-925] to reply
      to ARP Requests that it receives from the mobile node seeking
      address resolutions for the destinations on the mobile node's home
      subnet.  When receiving an ARP Request, the local mobility anchor
      SHOULD examine the target IP address of the Request, and if this
      IP address matches the mobile node's IPv4 home subnet, it SHOULD
      transmit a Proxy ARP Reply.  However, on certain types of links,
      the mobile node does not use ARP for address resolutions, instead
      it forwards all the packets to the mobile access gateway.  On such
      types of links, the mobile access gateway is not required to
      support Proxy ARP function.  At the same time, implementations not
      supporting the Proxy ARP function on links where the mobile node
      uses ARP for seeking address resolutions for the destinations on
      the mobile node's home subnet will result in communication
      failure.

Hmm. I had completely overlooked the proxy ARP function in earlier revisions of this draft... this is introducing multilink subnet issues to the IPv4 support for PMIPv6. Do we want to call them out explicitly and reference RFC 4903?


3.4.  Supporting DHCP-Based Address Configuration

      *  If the mobile node attaches to the Proxy Mobile IPv6 domain
         through multiple physical interfaces, the DHCP server will
         uniquely identify each of those interfaces and will perform
         address assignment.  The DHCP server will identify the
         interface as specified in RFC 2131.  The mobile node SHOULD
         generate and use the "Client-identifier" for each physical
         interface according to [RFC-4361]. [...]

This is placing a requirement on a mobile node. Since our charter had the "no host change" clause, are we sure that this is something we want to do? In other words, will the protocol break without RFC 4361 styled client IDs?


      *  If the mobile node is capable of performing handoff between
         interfaces, as per [RFC-5213], a "Client-identifier" value MUST
         be used for the attachment point that is not tied to any of the
         physical interfaces.  The identifier MUST be generated
         according to [RFC-4361], which guarantees that the identifier
         is stable and unique across all "Client-identifier" values in
         use in the Proxy Mobile IPv6 domain.

That one also seems problematic in light of the "no host change" clause. I thought inter-access handoffs were out of scope...

4.  IPv4 Transport Support

   o  The local mobility anchor and the mobile access gateway are both
      configured and reachable using an IPv4 address.  Additionally,
      both entities are also IPv6 enabled and have configured IPv6
      addresses on their interfaces, as specified in [RFC-5213], but are
      reachable only over an IPv4 transport network.

How about 's/but are reachable only/ but can only communicate together/' ?

   o  The mobile access gateway can be potentially in a private IPv4
      network behind a NAT [RFC-3022] device, with a private IPv4
      address configured on its egress interface.  But, the local
      mobility anchor must not be behind a NAT and must be using a
      globally routable IPv4 address.  However, both the local mobility
      anchor and the mobile access gateway can be in the same private
      IPv4 routing domain, i.e., when both are configured with private
      IPv4 addresses and with no need for NAT translation between them.

Reword into: "The mobile access gateway can potentially be in a private IPv4 network behind a NAT [RFC-3022] device and be assigned with a private IPv4 address [RFC-1918] on the interface towards the LMA. In that case, the local mobility anchor must not be behind a NAT and must be using a global unicast IPv4 address.  However, both the local mobility anchor and the mobile access gateway can be in the same private IPv4 routing domain and both be assigned with private IPv4 addresses [RFC-1918] as long as there's no NAT box between them.

   o  The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and
      the IPv4 transport support specified in this section is agnostic
      to the type of address mobility enabled for that mobile node.

s/IPv6, IPv4 or a dual IPv4/IPv6 node/IPv6, IPv4, or a dual stack IPv4/IPv6 node/

4.1.3.1.  Processing Proxy Binding Updates

   o  Upon accepting the request, the local mobility anchor MUST set up
      an IPv4 bi-directional tunnel to the mobile access gateway.  The
      tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA.
      The encapsulation mode MUST be determined by applying the
      following considerations:

I thought a tunnel is created only in case there's not one already. The text above contradicts that.


   o  The local mobility anchor MUST send the Proxy Binding
      Acknowledgement message with the Status field value set to (0)
      (Proxy Binding Update Accepted).  The message MUST be constructed
      as specified in Section 4.1.3.2.

I'm not sure about this. It reads like the LMA always sends a PBAck with status field set to success. I don't think that is really the case...

4.1.3.2.  Constructing the Proxy Binding Acknowledgement Message

   o  The Proxy Binding Acknowledgement message MUST be encapsulated in
      an IPv4 packet.  However, if the received Proxy Binding Update
      message was sent encapsulated in an IPv4-UDP packet, then the
      Proxy Binding Acknowledgement message MUST be encapsulated in the
      UDP header of an IPv4 packet.

How about "The Proxy Binding Acknowledgement message MUST be encapsulated as the Binding Update message triggering it, i.e., in an IPv4 packet, or an IPv4-UDP packet."

   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 on IPv4 addresses, then the encapsulated
      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.

In "using IPsec ESP [RFC-4301] mode", are we missing "tunnel" or "transport" before "mode"? Also it seems the reference to 4301 should come at the end of the sentence... If the last sentence means IPsec is applied to the inner IPv6 header, maybe it's better to say so, as well as to specify the mode, presumably transport.

4.2.2. Signaling considerations

   o  If the received Proxy Binding Acknowledgement message is
      encapsulated in IPv4 or IPv4 UDP packet, the message MUST be
      authenticated after removing the outer IPv4 or IPv4-UDP header.
      Considerations from Section 4 of [RFC-5213] MUST be applied for
      authenticating and authorizing the message.

The paragraph above seems to be in contradiction with the one I quoted above which said in some situations there can be an IPv4 SA. I guess this has to be corrected. Also s/IPv4 UDP/IPv4-UDP"?

   o  If the Status field indicates Success, the mobile access gateway
      MUST setup a bi-directional tunnel to the local mobility anchor.

   o  Upon accepting the request, the mobile access gateway MUST set up
      an IPv4 bi-directional tunnel to the local mobility anchor.  The
      tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA.
      The encapsulation mode MUST be determined from the below
      considerations.

These two are redundant aren't they? Also, the tunnel only needs to be setup when it's not present already. That should be covered.

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

      *  If there is a NAT Detection option [RFC-5555] 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.

The "if UseIPv4UDPEncapForSignalingMessages is set to (1)" is redundant in the two paragraphs above...

4.2.2.1.  Constructing the Proxy Binding Update Message

   o  The Proxy Binding Update message MUST be protected using IPsec ESP
      [RFC-4301], as specified in [RFC-5213].  The protection MUST be
      applied on the IPv6 packet of the Proxy Binding Update message,
      prior to the IPv4 encapsulation.

Same as earlier: somewhere it is said that an IPv4 SA can be applied, which isn't covered here.

4.3.  IPsec Considerations

4.3.1.  PBU and PBA

   The following section describes how IPsec is used for protecting the
   signaling messages and data packets between the local mobility anchor
   and mobile access gateway when using IPv4 transport.

   The following are the SPD example entries to protect PBU and PBA on
   the local mobility anchor and mobile access gateway.

           MAG SPD-S:
             - IF local_address = Proxy-CoA_1 &
                  remote_address = LMAA_1 & proto = MH &
                  local_mh_type = PBU & remote_mh_type = PBAck
               Then use SA ESP transport mode

           LMA SPD-S:
             - IF local_address = LMAA_1 &
                  remote_address = Proxy-CoA_1 & proto = MH &
                  local_mh_type = PBAck & remote_mh_type = PBU
               Then use SA ESP transport mode

Same here. There's no example for the IPv4 IPsec SA....

   MAG's IPsec module
    :
    :     IPv6 header (src=Proxy-CoA, dst=LMAA)
    :     ESP header in transport mode
    :     Mobility header
    :        PBU (p flag)
    :           Home Network Prefix option
    :           IPv4 Home Address Request option
    :           IPv4 Care-of Address option
    :    : * After adding the ESP header, the PBU is returned to the PMIP
    :   module and is encapsulated into the UDP and IPv4 headers.
    :   This requires a Proxy Mobile IPv6 specific IPsec implementation,
    :   which knows that the packet needs to be passed back to the PMIP
    :   module, instead of sending it out via the normal forwarding

I'm not sure about this statement. If the IPv4-UDP tunnel appears as a tunnel interface, and a routing table entry makes the destination IPv6 LMA address available at the other end of that tunnel things might work just well with a native or bump in the stack IPsec implementation.


   LMA (received at DSMIPv6 port)
    :
    :     IPv6 header (src=Proxy-CoA, dst=LMAA)
    :     ESP header in transport mode
    :     Mobility header
    :        PBU (p flag)
    :           Home Network Prefix option
    :           IPv4 Home Address Request option
    :           IPv4 Care-of Address option
    :
    :  *In addition, IPv4-Proxy-CoA and the sport (Z) needs to
    :  be passed along with the packet to ensure correct processing.
   \:/
   LMA's IPsec module
    :
    :     IPv6 header (src=Proxy-CoA, dst=LMAA)
    :     Mobility header
    :        PBU (p flag)
    :           Home Network Prefix option
    :           IPv4 Home Address Request option
    :           IPv4 Care-of Address option
    :
    :  *In addition, IPv4-Proxy-CoA and the sport (Z) need to
    :  be passed with the packet to ensure correct processing.
   \:/
   LMA's PMIP module

Here, I am not sure I agree with the two (*) above that says the IPv4-Proxy-CoA and the sport (Z) have to be passed along with the packet. The LMA PMIP module could store that information when the packet is received at the DSMIPv6 port and match it back to the decapsulated packet after IPsec processing, no?

The same comments applies to sending/receiving the PBA so I'm not going to repeat myself.

--julien









> -----Original Message-----
> From: netlmm-bounces at ietf.org [mailto:netlmm-bounces at ietf.org] On
> Behalf Of Sri Gundavelli
> Sent: Saturday, September 12, 2009 8:17 AM
> To: netlmm at ietf.org
> Subject: [netlmm] New Version Notification for draft-ietf-netlmm-pmip6-
> ipv4-support-17 (fwd)
>
>
>
> This resolves all the IESG comments.
>
> - Added 4361 ref, on DHCP client identifiers and some nits
>    that got in the prev version. Minor textual change on
>    how RFC-2131 identies the DHCP bindings, as suggested
>    by Ralph.
> - Addresses Pekka savola's comments.
>
> Regards
> Sri
>
>
>
>
>
> ---------- Forwarded message ----------
> Date: Sat, 12 Sep 2009 08:09:13 -0700 (PDT)
> From: IETF I-D Submission Tool <idsubmission at ietf.org>
> To: sgundave at cisco.com
> Cc: ryuji at us.toyota-itc.com
> Subject: New Version Notification for
>      draft-ietf-netlmm-pmip6-ipv4-support-17
>
>
> A new version of I-D, draft-ietf-netlmm-pmip6-ipv4-support-17.txt has
> been successfuly submitted by Sri Gundavelli and posted to the IETF
> repository.
>
> Filename:      draft-ietf-netlmm-pmip6-ipv4-support
> Revision:      17
> Title:                 IPv4 Support for Proxy Mobile IPv6
> Creation_date:         2009-09-12
> WG ID:                 netlmm
> Number_of_pages: 62
>
> Abstract:
> This document specifies extensions to Proxy Mobile IPv6 protocol for
> adding IPv4 protocol support.  The scope of IPv4 protocol support is
> two-fold: 1) enable IPv4 home address mobility support to the mobile
> node. 2) allowing the mobility entities in the Proxy Mobile IPv6
> domain to exchange signaling messages over an IPv4 transport network.
>
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> netlmm mailing list
> netlmm at ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm