Subject: Re: [MOBILE-IP] draft-malinen-mobileip-regreg6-00.txt

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Wed, 26 Jul 2000 05:18:56 +1000

Hello Jari,

Please find below my response to your comparison with our draft.
I will send another mail with some comments on your draft.

Regards,
Hesham

> Hi Jari and Charlie,
>   I have some questions on this I-D:
> The method is based on advertizing regional care-of addresses to MNs
> that can do a regional BU taking one of them as its alternate care-of
address
> and thereafter using this address
> in the visited domain. This means that the data is continously tunneled
> from GMA to MN as long as MN stays in the
> domain (sounds like HAWAII in which MN is given an IPv4 address in the
> domain, doesn't it?).
> So address autoconfiguration at each access router and its associated BU
> traffic are compromised with MIPv4 like tunneling.
> This same idea can also be found in the I-D by Karim.
> Can you provide some clarification on this?

This IPv6-specifc design uses the general idea of IPv4 regional
registrations
with a stationary care-of-address, but with the following distinctions to
the
designs of HAWAII or Karim's I-D:

-  HA does not need to be regional-aware (or MAP-aware) as in Karim's
    I-D. The first packets from CN via HA to MN are re-capsulated at GMA
    via possible lower regional routers down to MN's autoconfigured on-link
CoA.
    MN can recognize it needs to send a BU to CN from an encapsulated packet
    from CN, encapsulator being the access router.

=> That is an inaccurate observation. That's not the reason the HA has to
add a routing header (if that's what you mean by regional-aware).
The HA has to do that when it forwards packets that were addressed to an MN
address that was not registered with the MAP.
I might be wrong but I don't think you've addressed this problem in your
draft. Therefore according to your proposal, other home addresses that
the regional router is not aware of, will not be received by the MN as they
will be dropped by the regional router.

After MN sent a BU with
    alternate CoA to CN, this can start sending route-optimized packets to
MN
    via GMA. Inner packet AH is not touched in intermediate routers.
    Packets are forwarded locally in the visited domain and not from HA.
    We can thus do without using an additional routing header with
tunneling.

=> I don't really understand how that affects our decision of adding a
routing header.
AH is not affected in our proposal either, end to end security is
maintained.
What you mention above is not related to adding a routing header from the
HA.
The routing header from the CN is mandatory according to MIPv6.

- In our design, most of the data packets are neither tunneled nor
   host-routed (note also that signaling is not tunneled).
   Route-optimized packets towards the MN are forwarded in a special
   way based only on the regional binding cache.

=> If I understand that special way you refer to correctly, it is done by
changing the destination address in the packet. I think it is dangerous
to allow intermediate nodes to modify packets. I think tunnelling
is a better way to go here.

Normal processing of
   source-routed packets is skipped if there is a regional binding cache
   entry for the route-optimized home address in the regional CoA router
   receiving the packet. Only IPhdr destination is changed, AH prevails.
   The packet is then just forwarded to the lower CoA as seen in the
   regional binding cache.  Thus, no extra routing state is needed.
   This is much simpler than in Karim's proposal and is quite different
   from IPv4-solutions. Universal route optimization as provided in basic
   Mobile IPv6 is not compromized. Such route optimization is not
   even possible in IPv4 due to its legacy CNs.

=> I don't understand why you chose not to process the routing header.
This breaks RFC 2460 (IPv6 spec) for no reason.

- When MN changes link and gets a new address by autoconfiguration
   it performs a regional binding update. This updates the lower CoA as
   seen by GMA or a lower crossover router. The regional binding cache
   can thus direct packets to the new direction, i.e. MN's ability to move
is
   not compromized despite the use of address autoconfiguration.
   Those packets that were able to get past the crossover after MN started
   moving and before the crossover received a new regional BU can sometimes
   go to the MN via the simultaneous connection through the old on-link CoA.
   This amounts to no duplication of data packets (bicasting), just a
careful
   switching of MN's default route from the old access router to the new
one.
   Or, data packets can be buffered by the old router when no simultaneous
   connection is possible, e.g. in "hard handoff" conditions.

- Buffering was provided as one component of the handoff framework where
   our Mobile IPv6 regional registrations is another. Thus, this draft
separates
   the problem of location update localization from the handoff state
transition
   management.

=>I'll keep my comments here for the other two drafts you refer to below.

The smooth handoff framework design, as described by the documents at

http://www.iprg.nokia.com/~charliep/txt/regreg6/regreg6.txt
http://www.iprg.nokia.com/~charliep/txt/smoothv6/smoothv6.txt
http://www.iprg.nokia.com/~charliep/txt/mobilebuf/buffer6.txt
http://www.iprg.nokia.com/~charliep/txt/rohc/hc-ho-draft.txt

> Has this I-D been submitted to IETF?

Yes, with the same procedure & boilerplate as
draft-haverinen-reg-paging-00.txt,
Fri Jul/14/00. Curiously, no I-D-Action message resulted.

> Regards,
> --
> Behcet

Best Regards,

-Jari

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 26 Jul 2000 00:34:13 -0700

Hello, Hesham,

Thanks for your comments, please find my remarks to them embedded below.

> >     via possible lower regional routers down to MN's autoconfigured on-link CoA.

Note that I commented your design in the first sentence and thereafter explained
ours to clarify Bechet's questions thereof. WRT your design I only wanted to note
that the HA inserts this routing header thus making it different from a plain
Mobile IPv6 HA. By regional-awareness I only refer to the fact that you need
to alter the HA for MAP to operate correctly in some cases (explained later).

> will be dropped by the regional router.

Let me explain. In our design, other home addresses will not be dropped when no
regional entry exists. Note that in such a case, the GMA behaves like a normal
router. If the packet is targeted to the on-link CoA of the MN, this leads to
basic Mobile IPv6 behavior where gateway router is just like any other intermediate
router between HA and MN. If the HA tries to send to a regional CoA, the
entry is still in the GMA. It is the responsibility of the MN to make
sure that a regional binding cache entry in the GMA has a large enough
lifetime. And it is also the responsibility of the MN to register with
the GMA before traffic starts to arrive from remote nodes where MN registers
with a regional CoA. Furthermore, MN uses either regional or non-regional
CoA but not both simultaneously when sending binding updates out of the visited
domain.

> > After MN sent a BU with
> >     alternate CoA to CN, this can start sending route-optimized packets to MN
> >     We can thus do without using an additional routing header with tunneling.
>
> routing header. AH is not affected in our proposal either, end to end security is
> maintained. What you mention above is not related to adding a routing header from the
> HA. The routing header from the CN is mandatory according to MIPv6.

Again, I explain our design here. I only refer to MAP in how you describe
HA operation in your section 13. You use a routing entry to find home address.

Our forwarding only uses the binding cache, after which the destination
address is that of a lower CoA which is in its topologically correct place,
i.e. no mobility-specific additional routing entries are needed. Why have
extra routing state for home addresses when we have the binding cache entry,
in both designs, anyway?

> is a better way to go here.

If you look at RFC2460, the pseudo-code on page 16 explains how source
routing (consumption of routing headers in intermediate routers) changes
the destination IP address in the process (swap the IPv6 Destination Address
and Address[i]). In fact, this is a precedence for changing IPhdr destination
address in intermediate routers. We don't break this, we simply don't use it
for a very special kind of a routing header, that sent by users of basic
Mobile IPv6 route optimization and this only in regional-aware routers.

We use a different kind of forwarding (a regional binding cache based next
hop routing) which does not do anything more to the packet that source
routing would, it does less . When we can skip routing header processing this
even speeds up the IP forwarding. And we avoid the tunnelling overhead for
route-optimized packets which form the vast majority of data packets.

> This breaks RFC 2460 (IPv6 spec) for no reason.

First, a normal routing header processing would assume local knowledge
of home address routing. This would need the extra routing entry for the
home address when you process the routing header normally.

In our design, for the routing headers (from CNs or HAs) or even
for recapsulation, all we do is a regional binding cache lookup based
on home address which is used for all regional forwarding.

I do not consider our design choice a breach,
it is something new as was the introduction of binding cache -based
forwarding to HA in the basic Mobile IPv6. That "breaks" 2460 in that
it does not forward packets to the home link but to another address
based on MN's home binding. Our approach is analogous. For a special
mobility routing case we skip a part of 2460 to be more efficient in
header overhead and forwarding processing. Furthermore, we this way
localize this forwarding to a visited domain router.

Your HA Operation chapter 13 implies that this routing state exists and
for the cases that you explain,
"HA MUST include a routing header .. to enable the MAP to find the right
routing entry for the MN", which is what I meant by non-local forwarding
support (from the HA) for your visited-domain routing to operate correctly.

Additionally, as described in the AH RFC, IPhdr dstaddr is mutable but
predictable when a type 0 routing header is present. The check is done
for packet as seen after reception, that is, after applying routing header
in the final destination. With our design, we have the home address in
the DST field just like with basic Mobile IPv6.

Your design ends with the same, but with a bit more complicated routing
as described above. Our designs have similarities, but are not the same.
Having a convergence of some sort would be nice.. Would this call for
a framework for many regional/micro-mobility protocols or a simpler
common approach, what do you think?

It would be nice to continue discussing the options in Pittsburgh?

Best Regards,

-Jari

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 26 Jul 2000 03:18:39 -0700

Hi, Hesham,

> Hi Jari,
>
> I agree with Claude's comments regarding the sending of BUs.

Since I am not sure which of Claude's comments you refer to, I'll address both.

About sending BUs directly to the GMA, with a local model we distribute
the load down to the hierarchy as explained at end of this mail.

About autoconfiguration of GCoA,
if we compare HMIPv6 and ours, both use a link-address to for
local communication. HMIPv6 calls this PCoA. This takes one autoconfiguration.

In addition to that, HMIPv6 favors another autoconfiguration for the GCoA.

But with the regional binding cache -based forwarding, our regional
CoA can be static. We save the second autoconfiguration overhead with its
DAD operation etc. Our regional CoA can be re-used by many MNs since it is not
a real address on MN's link but an address in a GMA. This address is defended
against re-use by GMA. Inbound packets to MNs' home addresses are forwarded
with the lower CoAs to the correct MN. No address deletion from advertisements
thus no housekeeping for this is needed. In fact, we can do with only one constant
regional CoA in the advertisement re-used by all MNs. If MN-based selection is
desired, several regional CoAs can be advertised.

Can you explain more why we need the second autoconfiguration.

> Here are some more comments on your reply below
>
> Hesham
>
> > In HMIP, since the GCoA is build by concatening the MS prefix and EUI64, address
> > collision is very unlikely (but the MS verifies the unicity of the address by
> > performing a DaD on its link). Why don't you use the nice IPv6
> > autoconfiguration capability?
> >
> > This is for efficiency reasons, if the GCoA does not usually need to be
> > configured
> > at all, no delay occurs. However, your comment brings to mind that
> > renumbering
> > should cause reconfiguration of access router advertisements.
> > At this moment we limited hierarchy reconfiguration (dynamic knowledge of
> > regional
> > care-of-addresses, children, and father) out of scope, however. This can be done
> > with a separate protocol extension for these hopefully infrequent events, including
> > renumbering.

> =>I don't really see a need for new protocols to handle renumbering. In our
> proposal (and I blieve in Claude's one too) the renumbering is handled
> automatically because the rtr adv will announce new MAP addresses (in our
> case) or new prefixes (in Claude's draft).
> I think the basic IPv6 functionality in this case is certainly enough
> and provides very flexible and generic mechanisms without introducing
> more protocols. The less complexity, the better IMO.

In fact, I did not find specific description in MAP about what happens in
renumbering, how exactly is the knowledge of this distributed to the routers
advertising MAP? Since MAP is a specific sub-option to the router advertisement,
IPv6 will not automatically provide this. In this sense I do not think we have
very different approach..

> > > I have another question: why does a mobile host  send its regionalized BU
> > > to the access router instead of sending it directly to the closed Regional
> > > MA as we do (the RMA address could be advertised in the router adv.)?
> > > This would  provide more flexibility in the deployement of the Regional-aware
> > > routers (they don't have to be on a tree anymore)...
>
> > A region is naturally a hierarchy and in our model the network decides on the
> > crossover router (the highest guy changing its binding cache and answering
> > to this BU) thus distributing the signalling load down to the hierarchy.
>
> =>I don't see how the signalling load is distributed from a router's
> point of view. Every router in the heirarchy will still receive a BU.
> So the only difference is in our case (and again Claude's draft),
> is that the MN is aware who's receiving the BU. Which is what MIPv6 says,
> and I think that is a cleaner way to do it and less complex.

Not every BU goes to all routers in our model. If MN moves between adjacent
branches in a subtree, that BU propagates only to the crossover, not up to the
GMA. If you move frequently between these two only, signaling load is distributed
down from the GMA to the crossover. Tunneling directly to the MAP behaves like a
shallow (2-level) hierarchy. Our design provides optimization from the depth of
hierarchy even without changing the GMA.

Best Regards,

-Jari

---

From: Claude Castelluccia <[email-masked]>
Date: Wed, 26 Jul 2000 15:06:55 +0200

Hello Jari,

here follows some comments...

"Jari T. Malinen" wrote:

> DAD operation etc.

I don't follow you! If you really think that there is a high overhead due to
autoconfiguration
you should  also (and mainly) try to avoid the first autoconfiguration (for the PCoA)...
The GCoA autoconfiguration happens only once when the MH moves into a new domain while
the PCoA autoconfig. happens at each movement which is without doubt much  more costly...

> Our regional CoA can be re-used by many MNs since it is not

mainly if MN-based selection is desired. You then do not have to send  a list of addresses
in the Rt. adv.
And I see may good reasons to attribute a different GCoA per MH.

1- the MAP is merely a HA (it uses the same proxy mechanisms...no more no less). It is
very easy to implement.
2- Since the MAP get the PCoA only by looking at the destination address of incoming
packets, all packets will be forwarded to the MH without
having to look for the HomeAddress inside the packets   (As a result even an ICMP packets
that could
be generated for a packet with the source address set to a GCoA will be directly
encapsulated to the MH's PCoA...).. this is much simpler.
3- In our IPv6 implementation (the one from F.Dupont INRIA) a DaD is performed even if the
address is not autoconfigured (i.e.
obtained via a router advertissement). We therefore cannot attribute the same GCoA to 2
different MHs on the same link without
hacking the kernel...
4- The Source Address field (that can be set to the GCoA) could be used by other protocols
to perform some traffic shaping, policing,
control, billing, etc...it is therefore useful to be able to assign different GCoA to the
different MHs...

> very different approach..

In our HMIPv6 (INRIA one), we use a protocol between the MS (MAP) and the access routers
to distribute/update the MAP address ....

regards,

Claude.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 26 Jul 2000 13:39:20 -0700

Hello, Claude,

Some comments still..
Maybe the discussion could be continued in Pittsburgh, over dinner,
for example, in trying to figure out tradeoffs / missing pieces,
convergence possiblities, in a very small group looking at the IPv6
regional / hierarchical mobility problem?

> the PCoA autoconfig. happens at each movement which is without doubt much  more costly...

Agreed that the elimination of PCoA autoconfig would win more. I am not sure
if any of the three discussed designs completely achieves that since you seem
to use it for intra-visited-domain CN communication at least. But you have a
point here, this would be nice.

> mainly if MN-based selection is desired. You then do not have to send  a list of
> addresses in the Rt. adv. And I see may good reasons to attribute a different
> GCoA per MH.

> 1- the MAP is merely a HA (it uses the same proxy mechanisms...no more no less). It is

Ours can do with even less than that since we don't need the proxying, the
GCoA is already statically there. We also otherwise exploit the HA functionality.

> encapsulated to the MH's PCoA...).. this is much simpler.

Note also that packets coming from MN have the on-link CoA as source causing
the ICMP most likely to have a target different from the GCoA. Our lookup is really
nothing much more a routing engine would do (IPdst for tunneled, routing header IP for
optimized packets).

> different MHs on the same link without hacking the kernel...
>

Source address field in our model is distinct at GMA, it only overlaps in the
hierarchy. For traffic control one might also consider outgoing address, with mobility
and billing, a registration identity (e.g. a NAI) rather than the source IP.

Best Regards,

-Jari