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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Wed, 26 Jul 2000 07:10:53 +1000

Hi Jari,

I agree with Claude's comments regarding the sending of BUs.
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.

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

The
communication path per mobile at a time is usually a tree because the root
is
anchored, anyway, however, the global structure can be more generic, once
you
use many GMAs and MN-controlled selection.

Agreed. But that doesn't mean things should be transparent to the MN IMO.

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 26 Jul 2000 04:31:45 -0700

Hello, Hesham,

Thanks again for your comments,

> Hello Jari and Charlie,
>
> After reading your draft on regional registration for IPv6, I
> came up with the following comments.
>
> General comment:
>
>
> I believe mandating hop by hop encapsulation-decapsulation between
> regional routers will have the following effects:
>
> - We end up with a reserved path in the network, hence you lose
> the inherent redundancy that we get with IP routing. ie. if one
> of the regional aware routers crash, the MN won't receive anything.

This path maintains soft state so it recovers after timeout.. If access
router fails, there is not much difference from basic Mobile IPv6 in failure
behavior. Actually, the design is as flexible as basic Mobile IPv6.
On the other hand, maintaining redundant home address -based tunnels or
host routes would require a routing protocol.

Additionally, using direct access from MAP to
access routers reduces us to a shallow hierarchy case of Mobile IPv6
regional registrations. MN-specific route- or hierarchy configuration
maintenance wuold need to be a separate protocol, ours describes the
mobility transport in a given hierarchy. Separating these problems
might lead to an EMA-style hierarchy/mesh management with an efficient
mobility transport part, perhaps..

> - Encapsulation-decapsulation at each node adds extra and unnecessary
> delays.

Note that only very few first packets are recapsulated, most of data
packets are route-optimized. See my earlier mail explaining how we
have an efficient forwarding in that case. Recapsulation is perhaps not
optimal, but adding an IPv6 header is straightforward and even fast
if done based on the regional binding cache. Even MAP recapsulates at
the root of hierarchy.

> BTW our draft allows the same scenario, but it also allows the MN
> to receive directly from the MAP. So there is a choice and it
> depends on the MNs preferences / configuration.

This is what you basically get with a shallow (access routers and a
GMA) hierarchy. Configurable in our solution, too. Adjacent regional
routers can have non-regional routers between which reduces the
solutions quite the same wrt. this issue.

> Other comments:
>
> - I believe propagating the BU  in the hierarchy breaks the basic
> design of MIPv6. Furthermore, it is not clear from the draft
> how you can maintain the SA between the MN and each regional router
> if the MN doesn't know they exist. As I understood it, the destination
> address of the BU is the access router on the same link as the MN.
> I assume from ch 7 that you will do some sort of key distribution
> protocol. I still can't see how that would work and more importanly
> don't see the need for it.
> It seems this would add extra complexity / protocols, for no apparent
> benefit.
> Please elaborate if I missed something here.

Reasoning:
Hiding a deep hierarchy allows for short advertisement (e.g. only 1 RCoA),
maintaining stateless network-controlled crossover selection leads to
scalability down the hierarchy without changing the RCoA. This leads to
the hop-by-hop forwarding. With right security association generation it
is doable. Adding AAA brings a key distribution component,
having a group key in the visited domain provides initial association
for intra-domain key propagation and subsequently BU propagation. MN
initiates the propagation and with a session key shared by potential
recipients the SA is predictable, network-controlled crossover selection
can be made with signaling security.

> - It is unclear to me how the regional BAck is processed. The draft assumes
> there is only one sent back. Is it propagated down the hierarchy ?
> If so then how would the SA work ?
> If not then what happens if one router fails and the others succeed?

It must go the same path down, with MN-visted-domain association the
SA exists there, AHs are different on different hops.

> - By not processing the routing header in the regional router, you
> are breaking the extension header processing rules in RFC 2460.
> I also don't see why this is necessary.

See my comments in a previous mail on our regional-aware data
forwarding.

> - I have some concerns about the way the inbound packets are routed
> within the hierarchy. You mention encapsulation in the draft, but
> when it is described it doesn't actually say the same thing. It seems
> that the destination address is modified in the original packet.
> I know that end to end AH will still work, but this is not a normal
> IPv6 stack behaviour and I don't see why it is necessary.

This also with motivation in the previous mail. Recapsulation for tunneled
packets, regional forwarding for route-optimized packets.

> - If the MN decides to register its alt-COA with the HA. I believe
> any Site-local packets forwarded by the HA to the MNs COA will be
> dropped by the regional router (ie. the owner of the COA).
> That's one of the reasons we attach a routing header between the HA
> and the MAP.

With our regional binding cache -based forwarding we can forward those
addresses we like. Site-local addresses must be registered
separately. If these are in regional binding cache then our implementation
does forwarding, lower RCoAs are not that address so real routing engine
does not drop these, delivery occurs locally from last CoA (on-link on MN)
to the site-local address. Proxying addresses from below works for our
benefit here.

> Regards,

Best Regards,

-Jari