Subject: [netlmm] Additional comments on draft-ietf-netlmm-pmip6-ipv4-support-05.txt

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 23 Oct 2008 20:10:38 -0400

A few more comments.

There is an inconsistency with the binding ack status flags. Section 
3.2.3.2 describes two status values - 
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS_SUPPORT and 
NOT_AUTHORIZED_FOR_REQ_IPV4_HOME_ADDRESS. Section 3.3.2 and the IANA 
section mention - NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS. All three are 
different.

The document introduces something called "selective de-registration". My 
understanding is that this is used to selectively de-register the IPv4 
home address, but keep the binding cache entry that corresponds to the 
IPv6 HNP. Is it allowed to remove the binding for the IPv6 HNP, but keep 
the IPv4 home address binding? I guess not. If so, this should be 
explicitly stated. I couldn't find any text that states this.

>    o  If there is an IPv4 Home Address option [ID-DSMIP6] 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
>       owned by the local mobility anchor and furthermore the mobile node
>       is authorized to use that address.  

The IPv4 address does not have to be "owned" by the LMA. Suggest 
re-wording it to

    o  If there is an IPv4 Home Address option [ID-DSMIP6] 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 can
       be served by it and the mobile node is authorized to use that
       address.

>    o  The local mobility anchor MUST create an IPv4 host route for
>       tunneling the packets received for the mobile node's home address
>       associated with this mobility session.

This is implementation specific. Whether the LMA uses a host route or 
some other mechanism to tunnel the packets meant for the mobile node's 
home address shouldn't be specified in the document.

>    o  The local mobility anchor MUST remove the previously created 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).  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.

This is again implementation specific. It shouldn't matter whether the 
LMA deletes the old host route and tunnel and creates a new host route 
and tunnel or it just updates the existing route and the tunnel state.

In section 4.1.2

>    To support the IPv4 Transport Support feature the mobile node's
>    policy profile, specified in Section 6.2 of [RFC-5213] MUST be
>    extended with the following additional fields.  This are mandatory
>    fields of the policy profile required for supporting this feature.
> 
>    o  A flag indicating whether or not IPv4 transport should be used.
>       The value of this flag can vary at different mobile access
>       gateways.  The specific details on how this flag is maintained on
>       a per mobile access gateway basis is outside the scope of this
>       document.

Why should this be MN-specific? The fact that IPv4 transport is used 
between a MAG and the LMA should be specific to a mobile node, right?

In section 4.1.3.1

>    o  If the received Proxy Binding Update message (encapsulated in IPv4
>       or IPv4-UDP header) is protected using IPsec ESP header, then the
>       message MUST be authenticated as described in Section 4 of [RFC-
>       5213].  However, if the IPv4 packet is not protected using IPsec
>       ESP header, then the message MUST be authenticated after removing
>       the outer encapsulation (IPv4 or IPv4-UDP) header.

This is not at all clear.

RFC 5213 only describes one mode.

   IPv6 hdr (src=MAG, dst=LMA)
   ESP hdr
   Mobility Hdr
     Proxy Binding Update

For this document, we can either have

(1)
   IPv4 hdr (src=MAG-v4, LMA-v4)
   IPv6 hdr (src=MAG, dst=LMA)
   ESP hdr
   Mobility Hdr
     Proxy Binding Update

or

(2)
   IPv4 hdr (src=MAG-v4, LMA-v4)
   ESP hdr
   IPv6 hdr (src=MAG, dst=LMA)
   Mobility Hdr
     Proxy Binding Update

The text in the paragraph above seems to refer to both. But is not clear 
which sentence applies to which. I assume the following sentence applies 
to case (1) above.

       However, if the IPv4 packet is not protected using IPsec
       ESP header, then the message MUST be authenticated after removing
       the outer encapsulation (IPv4 or IPv4-UDP) header.

Does the first sentence apply to (2)?

    o  If the received Proxy Binding Update message (encapsulated in IPv4
       or IPv4-UDP header) is protected using IPsec ESP header, then the
       message MUST be authenticated as described in Section 4 of [RFC-
       5213].

If yes, it doesn't make sense. RFC 5213 does not talk about an ESP 
header between IPv4 and IPv6 headers. There are other instances of such 
text.

Vijay

_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 23 Oct 2008 20:16:37 -0400

One minor correction.

>>       gateways.  The specific details on how this flag is maintained
>>       on a per mobile access gateway basis is outside the scope of
>>       this document.
> 

I meant it should not be specific to a mobile node and hence shouldn't
be stored in the MN's policy profile.

Vijay

---

From: "Frank Xia" <[email-masked]>
Date: Thu, 23 Oct 2008 22:03:33 -0500

Hi folks

We just submitted the draft
 http://tools.ietf.org/id/draft-xia-netlmm-lma-discovery-00.txt.

abstract:
    This draft defines a DHCP-based scheme to enable dynamic discovery of
   a Local Mobility Anchor (LMA) in Proxy Mobile IPv6.  Existing Dynamic
   Host Configuration Protocol (DHCP) options are used allowing a Mobile
   Access Gateway (MAG) to request the LMA's IP address, Fully Qualified
   Domain Name (FQDN), or home network prefix via the DHCP response

Comments are very welcome.

BR
Frank