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

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 10 Apr 2007 19:02:47 -0700

Hi Jari,

Thanks for reviewing the document and appreciate your
time on this. Please see my comments below.

Some high-level comments:

1. DSMIP6 

The additional fields in the conceptual data structures,
such as IPv4-HoA related fields/flags ..etc, should be
in the DSMIP spec. But, the DSMIP6 spec does not define
those fields. We went ahead and used them for clarity
and for implementation guidance, taking that out is the
right thing, and is not a big effort. There is some
cleanup work left and these comments will be certainly
fixed as part of those efforts. 

2. Containing IPv4 support to a specific section:

The PMIP6 protocol when supporting IPv4/IPv6 addressing
and transport requires some text around the terminal's
capability, MN-AR link properties, signaling messages,
tunneling setup, routing setup ...etc. Attempting to 
contain all of this to a specific section will be
difficult. If we attempt to scope it to one place, that
section will bloat significantly. For clarity and
readability, if in the various sections, the explanation
for IPv4 or IPv6, where ever relevant, if provided will
be more useful, IMHO. As an implementer, I find this
approach a bit better.

3. Over specification

There are details presented for clarity and for better
protocol explanation. Few words on how the DHCP relay
agent sets the link-address option with the mobile node's
home network prefix is not exactly for defining a new
mechanism or an operation, but is a pointer to the
original spec and with context specific help. More along
the lines of how the 3971 (SEND) specification reviews
the original messages from 2461. Just to make the
explanation self contained.

Bottom line
-----------
The document requires some editing and that's planned.
One or two spins, all of these minor issues will be
resolved. If we are *challenged* with the same type of 
review comments, a month down the road, that will be some
thing and we certainly don't expect that. But, so far the
document evolved systematically from version to version.
The next 2 revs will evolve to the form of completion.
That's given !

Other comments inline...

Regards
Sri

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Tuesday, April 10, 2007 1:25 PM
> To: Sri Gundavelli
> Cc: [email-masked]
> Subject: some comments on the IPv4 parts of draft-sgundave
> 
> 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
> 

DSMIP uses the term "home address" and we have no issue using those
terms. But, after some discussions we had to change those terms,
our preference is for the original MIP6 or DSMIP6 terminology. We
would love to introduce them back.

>       Destination: Proxy-CoA   or    IPv4 Proxy-CoA
> 
> Same goes for IPv4 LMAA.

When explaining the tranport or on where the BU needs to be sent,
a qualifier such as the address type for the LMAA or Proxy-COA,
will be usefull and will be less ambiguous.

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

True. It should be in DSMIP6. But, DSMIP6 is missing this info. 
We will more than happy to take this out.

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

This is not exactly specifying any thing. The idea is to provide some
guidance to the implementors. Non-normative text.

> 5.3.  (Routing Considerations)
> ====================
> 
> Again, isn't there duplication with DSMIP when you explain the
> tunnel encaps/decaps procedures?
> 

For the sake of clarity, certain explanations are required. 3963
does a talk a bit about encap/decaps and not just fall back to
3775. But, we can remove all of this and reduce the text, if that
is the feedback.

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

True. Ok.

> 5.7.  (IPv4 Transport Support)
> ====================
> 
> Looks good.
> 
> 6.2.  (Conceptual Data Structures)
> =======================
> 
> This has similar issues as the corresponding LMA data structure
> section.
> 

We will fix it.

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

Yes. Since, the IPv4 router is the home agent, the node's
onlink determination technique, by the way of ARP query, and
with the MAG proxying the ARP reply, should work fine.
We need some text. DNAv4 was never defined to be in the scope
of this work and there was never a single discussion or a comment
on this thread either from the past/present chairs or from any
of the WG members. However, we can add the required text.

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

Agreed. We will fix it.

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

Ok. Overall review from start to end, will fix it in one spin.
Few days of work. That's all to it. 

> 
> 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 over specifying 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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Apr 2007 08:26:06 +0300

Sri,

> fixed as part of those efforts. 

Good. Please work with the DSMIP authors to make sure they
have everything that needs to be in their document.

> be more useful, IMHO. As an implementer, I find this

Yes, that's the other side of it. The one section will have some
substructure, and needs to explain a number of things.

I see your point of view as well -- but I'm just reporting on
the impression that I got as a reader.

> explanation self contained.
The DHCP relay text, for instance, is very good. We do need to
explain how the system works.

I was mainly referring to overspecification in the context of
saying things that DSMIP should already cover. It seems that
we agree on that, so lets work on that...

> Bottom line

OK -- but you will need more review, particularly from experts outside
the WG.

> would love to introduce them back.

Oh. What was the argument in those discussions?

> will be usefull and will be less ambiguous.

Maybe -- you need to look at this on a case by case basis. For instance,
when I search for "IPv4 Proxy-CoA", the only references that I find to
this term are either in the statements of the form quoted above,
or in text that appears to duplicate something that DSMIP should
already be saying about encapsulation.

It would also be possible that you place a generic statement after the
relevant terms, indicating that the term can be either an IPv4 or IPv6
address, and that where the distinction is significant the text makes
it clear which one is meant.

> We will more than happy to take this out.

Yes -- but talk to the editors of DSMIP and make sure the
content is moving there. Traditionally all the Mobile IPv6
specifications have described the fields in the conceptual
data structures, so lets keep doing that in DSMIP too.

> guidance to the implementors. Non-normative text.
But it is hard for me to distinguish normative from non-normative.
There was nothing in the text that told me there was a difference.
As an implementer, I would be wondering whether I need to touch
my DSMIP code i.e. is this somehow different from DSMIP.

But I do understand the need to explain how the system works.
Sometimes this means that explaining things that other
specifications have already explained.

One way to make it clearer that you are not adding new things
is to use references. For instance: "The tunnel encapsulation
mode can be ..., as specified in RFC XXXX and RFC YYYY."

> 3775. But, we can remove all of this and reduce the text, if that
The feedback from my side is to make it clear what you are specifying here
and what you are just importing by reference. Removing text is one
option, but I don't want to say that you should remove everything that
is not described here. As I said earlier, some amount of explanation of
how the system works is going to be useful. However, use your judgment,
and if you do explain something, make sure text the is clear that you
are merely explaining it (e.g., by using a reference).

>> is the part about "further" an extension of that, or an explanation?

Ack.

>> policy for  IPv4 and IPv6 and network-based mobility are independent

Thanks.

> Few days of work. That's all to it. 

Great!

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 10 Apr 2007 23:29:54 -0700

> Oh. What was the argument in those discussions?

There were a lot of discussions related to terminology,
more specifically on what to call the address the mobile node
is allocated. DS-MIPv6 does call it IPv4 home address. But since
we are talking about a local mobility management protocol here,
this IPv4 address is only valid as long as the mobile node is
inside the NETLMM domain.

> data structures, so lets keep doing that in DSMIP too.

Actually DS-MIPv6 does talk about creating a binding cache entry
for the IPv4 home address in addition to the binding cache entry
for the IPv6 home address. How it is actually implemented,
whether using one binding cache entry for both IPv4 and IPv6 home
addresses or using more than binding cache entry is up to the
implementation.

So storing the IPv4 home address of the mobile node in the binding
cache entry is already there in the DS-MIPv6 spec. Regarding
storing the IPv4 address of the LMA, does it need to be stored in
the binding cache entry for the mobile node? Isn't it the same for
all mobile nodes?

Vijay