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

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Sat, 29 Jul 2000 00:03:10 +1000

Hi Jari,

Sorry for the late reply, email problems !
Here are some more comments.
I'm sure we will continue this in Pittsburgh.

Regards,
Hesham

> I agree with Claude's comment 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.

=> The comment was on the transparency of the BUs to the MN.
I think it's better that the MN knows its regional address(es).
This would comply with the MIPv6 design and will save a lot of
complications with security which are not solved in your proposal
as you mentioned in ch 7.

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.

=>Which HMIPv6 ;) ?
In our proposal we don't need autoconfig or DAD. We use a COA that
belongs to a MAP interface. Similar to yours. But the difference is that
the MN knows all its addresses which makes things very simple.

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

=> Well there is no difference to normal IPv6 operation. If the MAP address
changes due to renumbering then the information in the MAP option
will change and the MN will register with the new address. The information
can be distributed to routers using the MAP discovery mechanism in the
draft.

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

=> No, there is no assumption of a 2-level hierarchy at all.
The exact same outcome as in your proposal can be obtained but
the difference is that the MN is aware of its regional addresses.

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

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

=>You have to change something in the HA. Otherwise Site-local packets
addressed to the MN will be dropped by the regional routers or delivered
to the wrong MN. You don't address this issue in your draft and that's
why I think it is not complete.

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

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.

=>Please refer to my comment above.

 Furthermore, MN uses either regional or non-regional
CoA but not both simultaneously when sending binding updates out of the
visited
domain.

=> Why ? how can that be controlled. I think the MN should be able to use
any of its COAs (on link and regional). I don't see a need to limit that.
Furthermore, it can't really be policed even if you want to restrict it.

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

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?

=>We don't add the Routing header in the HA all the time, only for addresses
that were
not registered. eg. a Site-local home address.

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

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.

=>There is a fundamental difference. RFC 2460 states that you can
use the contents of the packet to change the packet. That is not
the same as simply changing the packet.

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

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.

=> Ok how do you look up an entry in the Binding Cache ? I guess the key
is the Home address. Where do you get it from in the packet received from
the CN ?

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.

=>I really can't see the analogy here. The breach is that you ignore
the routing header and RFC 2460 says you shouldn't.

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.

=> I think the answer to your question is in the ".." area ;)
basically Site-local addresses is the answer.

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.

=>Yes it adds a fraction more complexity in the rare case of forwarding
Site-local packets, but it guarantees that nothing is lost. your proposal
doesn't guarantee that.

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?

=>I agree that there are some good ideas in all proposals and I look
forward to discussing this in Pittsburgh.

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

=> Definitely.

---

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 28 Jul 2000 20:43:09 -0700

Hi, Hesham,

Since the discussion of these issues with many proposals was encouraged,
and despite the recent message flood, let me briefly comment on your remarks below,

- Our MN _knows_ its regional addresses, but what it really does not know
  is who answers to the RBU. And it needs not to know. We unlike you are using
  network controlled crossover selection. And, if the MN prefers, it can
  even add an alternate CoA sub-option for the RBU for diverting data out
  of the strict tree if this is really wanted. But, we might want a network
  policy to forbid this. These usages apply basic Mobile IPv6 on our design.
  But we prefer in our design the network-controlled case.

  The advantage comes when you can hide your network topology from MN and keep
  advertisements small even with large hierarchies.

- On alleged breaking of the 2460 semantics: We indirectly use contents of
  the packet (the home address in the routing header) for changing the packet's
  "lower" IP destination. If you consider the home address as the actual
  destination, we do not change that. This is close to actual source routing.
  The RBC entries should (with proper AAA-driven security brought in) even
  be authorized by the HA, what is so bad here?

  An advantage to your design comes from the saving of bandwidth on most
  packets (route optimized regional forwarding vs. mostly tunneled regional data
  forwarding) and in state saving. And, we control forwarding semantics a bit more
  (below)

- On the Site-local address forwarding, if the site-local address comes
  from some parameterized info on the route advertisements, these will go to
  the visited domain tunneled from the HA, thus the GMA could learn the same
  information from there. Since we control the forwarding semantics in our
  model, our GMA could e.g. monitor broadcast packets to get the available L3
  info for each home agent on their home links. If GMA can do the mapping
  the regional forwarding takes place, and the packet is not dropped.
  I am not sure if it even is so useful for HA to defend all these addresses
  not explicitly registered by MN (such as site local) unless their mapping
  to homeaddr is simple. We do not address the problem the same way as you do,
  but is that needed?

  The advantage comes from not altering the HA for any regional purposes.

- That we keep transport and security apart does not mean no security. For
  data, all works as before, for signalling, the only thing different is
  the authorizations for the visited domain. We need to distribute session keys
  anyway. The visited domain and the MN will then have a dynamic security association
  so even the crossover is not known to the MN they do end up having a security
  association for authentication. That we do not access this using the
  the IP source but using the home address, is something that should not
  be surprising when discussing mobile routing. We have "lower" routing (CoAs)
  vs. endpoint addresses (Haddr, CN, seen in the sockets) which make the mobile
  case a bit different from the fixed case for the "end-to-end" entities.

But, more on these in Pittsburgh,

Best Regards,

-Jari

See above.

they

Here was a mistake, we do not need to limit them either.

to MN
tunneling.
security is
header from the

Comment collected above.

See above.

basic

The routing header of route-optimized packets from CN contains the home
address.

=> Definitely.