Subject: [netlmm] some comments on the IPv4 parts of draft-sgundave

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Apr 2007 23:25:11 +0300

In the context of the document organization debate, I reviewed
the IPv4 parts of draft-sgundave, and also got a preview of
the to-be-WG draft. Please find some comments below:

Section 2.2 (Terminology)
=================

I wonder if there's a real need to define an IPv4 variant of some
of the terms. For instance, "IPv4 MN-HoA" which DSMIP simply
calls "IPv4 home address". Or "IPv4 Proxy CoA". Particularly
when a lot of the text in the draft has statements of the form

      Destination: Proxy-CoA   or    IPv4 Proxy-CoA

Same goes for IPv4 LMAA.

5.1.  (Extensions to Binding Cache Conceptual Data Structure)
=========================================

>    o  A flag indicating if IPv4 HoA mobility binding is accepted.  If
>       this flag is set, the relevant IPv4 fields in this data structure
>       have to be set to the configured values.
>
>    o  A flag indicating if IPv6 HoA mobility is accepted.  If this flag
>       is set, the relevant IPv6 HoA fields in this data structure have
>       to be set to the configured values.  If this flag.
What's a "HoA mobility binding"? A binding cache entry with
home registration flag set to 1?

More interestingly, why is this specification here and not in DSMIP?
Presumably, DSMIP needs to be able to distinguish IPv4 and IPv6
bindings from each other...

>    o  The IPv4 home address of the mobile node, if IPv4 home address
>       mobility is enabled and if the mobile has obtained an address.
>
>    o  The IPv4 default-router address of the mobile node, if IPv4 home
>       address mobility is enabled.  This is the IPv4 LMAA.
See above -- why are these here and not in DSMIP? Or if they are
in DSMIP, why copy them here?

5.2.  (Bi-Directional Tunnel Management)
===========================

>    The one end point of the tunnel is the address configured on the
>    interface of the local mobility anchor, LMAA or IPv4 LMAA.  The other
>    end point of the tunnel is the address configured on the interface of
>    the mobile access gateway, Proxy-CoA or IPv4 Proxy-CoA.  The tunnel
>    encapsulation mode can be either IPv6/IPv6, IPv6/IPv4, IPv6/IPv4-UDP,
>    IPv4/IPv6, IPv4/IPv4-UDP, based on the transport mode and the
>    presence of NAT translation devices on the path.
How about

   The one end point of the tunnel is the address configured on the
   interface of the local mobility anchor, LMAA.  The other
   end point of the tunnel is the address configured on the interface of
   the mobile access gateway, Proxy-CoA.  The tunnel
   encapsulation mode can be either as specified in RFC 3775 or in
   [DSMIP], based on the transport mode and the
   presence of NAT translation devices on the path.

which would avoid duplicating specification from DSMIP.

5.3.  (Routing Considerations)
====================

Again, isn't there duplication with DSMIP when you explain the
tunnel encaps/decaps procedures?

5.6.  (IPv4 Home Address Mobility Support)
============================

This section looks fine, except for:

>    Upon receiving the Proxy
>    Binding Update Message with this IPv4 Home Address option, the local
>    mobility anchor is required to apply the processing rules as
>    specified in DSMIP6 draft.  Further, if the received option has a
>    value set to 0.0.0.0, the local mobility anchor needs to consider
>    this as a request for an IPv4 Home Address allocation and must return
>    the allocated value in the IPv4 Home Address option carried in the
>    Proxy Binding Acknowledgement.
I think the DSMIP draft already specifies the 0.0.0.0 procedures. So
is the part about "further" an extension of that, or an explanation?

5.7.  (IPv4 Transport Support)
====================

Looks good.

6.2.  (Conceptual Data Structures)
=======================

This has similar issues as the corresponding LMA data structure
section.

6.6, 6.7, and 6.9
==========

Similar issues appear here as in the LMA sections.

6.13.  (Mobile Access Gateway Operation Summary)
==================================

>    o  If IPv4 home address is supported for a given mobile node, the
>       mobile access gateway must act as a proxy for the mobile node's
>       IPv4 default-router and that is the address of the local mobility
>       anchor.  The mobile access gateway must be able receive all the
>       IPv4 packets from the mobile node.  The mobile access gateway MUST
>       respond to any ARP request message from the mobile node attempting
>       to resolve the MAC address of its default-router.  The ARP reply
>       must contain the MAC address of the mobile access gateway.

Does this work with DNAv4? (RFC 4436)

7.  (Mobile Node Operation)
==================
>    The mobile node can be operating in an IPv4-only mode, IPv6-only mode
>    or in dual IPv4/IPv6 mode.  Typically, the configured policy in the
>    network determines the type of home address(es) i.e.  MN-HoA, IPv4
>    MN-HoA or both, that the network mobility is supported for.  If the
>    configured policy for a mobile node is for IPv6-only home address

The terminology is a bit confusing. When you say "the configured policy
for a mobile node", you still mean policy configured in the NETWORK,
but for THAT particularly mobile node, right?
>    mobility, the mobile node will be able to obtain its MN-HoA, any
>    where in that proxy mobile IPv6 domain and if policy allows only
>    IPv4-only home address mobility, the mobile node will be able to
>    obtain its IPv4 MN-HoA, any where in that domain.  Similarly, if the
>    policy permits both the IPv4 and IPv6 home address mobility, the
>    mobile node will be able to obtain its MN-HoA and IPv4 MN-HoA and
>    move anywhere in the network.  However, if the mobile node is
>    configured for IPv6-only mobility and if the mobile node attempts to
>    obtain an IPv4 address configuration via DHCP mechanism, the obtained
>    address configuration will not have any mobility properties, i.e. the
>    obtained address will be from a local prefix and not from a prefix
>    that is topologically anchored at the local mobility anchor and hence
>    the mobile will loose that address as it moves to a different link.

This seems like a complicated way of saying that the configured
policy for  IPv4 and IPv6 and network-based mobility are independent
from each other.

>    If the mobile node is IPv4 enabled or IPv4-only enabled, the mobile
>    node after the access authentication, will be able to obtain the IPv4
>    address configuration for the connected interface by using DHCPv4.

You may have said this earlier already.

Summary:

Overall, I did not see big issues -- definitely more review is needed
outside the WG, however. DHCP and DNAv4 interactions worry me
a bit, so those are one area for review.

However, organization-wise I would have found the entire document
easier to read if the IPv4 parts were concentrated in one place as
opposed to being spread around the document. I also felt that the
document was overspecifying things in certain cases where a
reference to the actual original specification (DSMIP) should have
been used instead.

Jari

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