Subject: Re: [mobile-ip] Mobile Routers support without optimization

From: James Kempf <[email-masked]>
Date: Fri, 17 Aug 2001 09:23:33 -0700 (PDT)

Hi Erik,

Thanx for your reply. I'm trying to wrap my mind around this problem
by looking at the simplest case. The general case seems to
escalate somewhat rapidly in complexity.

>A PAN is an IP link. There is an IP router between the PAN and the rest
>of the network.
>Thus the devices on the PAN (other than the router) never connect directly
>to any other link - they always go through the router.
>
>If that is what you are saying then, from my IP centric view of the world,
>I think that is a very reasonable view of a PAN. In fact it is the view
>I'd prefer.
>

Right, but what I was trying to say is that there is another interface,
either wireless (like 802.11 or wCDMA) connecting the device to
the wired network. So the device acts either as a multihomed host
or a router, with the PAN/Bluetooth interface on one side and
the WLAN/WAN interface it the Internet on the other. 

The point I think I was trying to make is that the PAN network
is strictly a leaf, i.e.  there is no other router somewhere
routing out of the PAN network into the Internet.

>> In that case, as Mattias suggested, a NAT on the PAN side would work
>> just fine (yes, I know NATs are evil, but they are a practical,
>> short term solution that should be discussed).
>
>Whoa - what a can of worms. Should we really dive into that one?
>

Well, maybe not. :-) But I think we need to look at it just for
the sake of argument. I'm not advocating that it be accepted,
just that we examine the case.

>NAT has nothing inherently to do with PANs - this argument is no
>different than NAT being useful in a home environment.

If the PAN network is a leaf network and the devices are client
only (as you point out below), then maybe it's a possible solution.

>And NAT assumes that the devices on the PAN are client-only i.e. they
>only initiate communication.
>I for sure want the model to allow devices on the PAN to be able to
>do peer-to-peer communication with other devices elsewhere in the network
>i.e. allowing other nodes to connect to the devices in my PAN.
>

That is a concern.

An advantage of a NAT-like solution (I'm playing devil's advocate here)
is that it allows the devices behind the PAN to keep their CoA while
the multihomed host/mobile router moves. Additonally, the NAT can do route 
optimization with CNs, and traffic from the PAN network is routable directly to 
the CN (i.e. not back through the home network), so no triangle routing. The 
disadvantage, as you point out, is you can't do push without special hacks,
if then.

A simple alternative, if I understood your previous email correctly, is to have 
the PAN addresses globally routable through the home subnet but don't do route 
optimization to the CN. That would require a tunnel back through the 
HA for packets to the PAN because the PAN network prefix wouldn't be in the 
visited subnet routing tables and therefore packets with PAN network prefixes 
may be subject to ingress filtering. Similarly, incoming
packets to the PAN would need to be routed through the home network,
resulting in quadralateral routing. The advantage is that push
would be possible without special hacks. Packets to the WAN/WLAN interface, 
presuming the device is a multihomed host, could still benefit from route 
optimization however.

Are there any other advantages/disadvantages that I am missing?
Perhaps there is another solution? 

It helped me alot in this simple case to think of the mobile device
as a multihomed host instead of a router (actually, I think that
may be more accurate anyway if the device is a cell phone with a Bluetooth
interface) because it allowed me to avoid having to think about the
effects on the routing protocols in the visited network.

		jak

---

From: Alexandru Petrescu <[email-masked]>
Date: 17 Aug 2001 19:31:59 +0200

James Kempf <[email-masked]> writes:
> An advantage of a NAT-like solution (I'm playing devil's advocate
> here) is that it allows the devices behind the PAN to keep their CoA
> while the multihomed host/mobile router moves.

You say "keep" so it might mean the Home Address, not the CoA?

NAT would disallow not only traffic from CN to MNN but also from HA to
MNN, right?  Or you see traffic from HA to MNN as being tunnelled
(through MR)?

> Additonally, the NAT can do route optimization with CNs, and traffic
> from the PAN network is routable directly to the CN (i.e. not back
> through the home network), so no triangle routing.

What if the CN is itself behind an MR-NAT?

> as a multihomed host instead of a router (actually, I think that may
> be more accurate anyway if the device is a cell phone with a
> Bluetooth interface) because it allowed me to avoid having to think
> about the effects on the routing protocols in the visited network.

Right, there are many names under which this moving devices could be
called and that would put less requirements on its behaviour, than
calling it router.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Aug 2001 10:36:14 +0200 (CEST)

> routing out of the PAN network into the Internet.

Good point. I expect that everybody assumes that the mobile network
is a leaf - it might be a multihomed leaf in some cases (with multiple
routers towards the rest of the Internet) but it makes no sense for the
mobile network to be a transit for other packets.

> A simple alternative, if I understood your previous email correctly, is to
> have  the PAN addresses globally routable through the home subnet but don't
> do route  optimization to the CN. That would require a tunnel back through
> the  HA for packets to the PAN because the PAN network prefix wouldn't be in
> the  visited subnet routing tables and therefore packets with PAN network
> prefixes  may be subject to ingress filtering. Similarly, incoming

I think the design space is quite large.
One case is when the MNNs are statitionary with respect to the MR
and don't observe that the MR is moving. In those cases I suspect
that there are limits to the amount of route optimization possible
since, depending on the actual model for securing BUs, it might be hard
or impossible for a 3rd party like the MR to send BUs for its MNNs.

But if the MNNs are made aware that the MR is moving then they can use
the regular BU mechanism for route optimization.
This would more complex than MIPv6 today. For example, such MNNs would need
3 different addresses as  far as I can tell:
 - Home Address
 - Long-term stable CoA associated with the MR's home prefix
   This only changes when the MNN moves between MRs.
   Traffic sent to this address will go through the MR's home agent.
 - Temporary CoA associated with the MR's CoA prefix (which the MR acquires as
   it moves).

Depending on movement rate and traffic patterns the MNN can then choose
which correspondents to update with the temporary CoA, the stable CoA,
or not update at all.

> effects on the routing protocols in the visited network.

IMHO the current 3G model for devices connected through a cell phone
are quite limited - makes the cell phone into some form
of PPP relay.
A router is the IETF model for devices that connect between dissimilar L2
technologies (and also in many cases between the same L2 technologies).

So let's not get distracted my the limits of what folks might be currently
building while trying to understand the size and shape of the design space.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 20 Aug 2001 12:43:12 +0200

Erik Nordmark <[email-masked]> writes:
> is a leaf - it might be a multihomed leaf in some cases (with
> multiple routers towards the rest of the Internet) but it makes no
> sense for the mobile network to be a transit for other packets.

Yes, leaf, no need for mobile network to transit other packets.
However, the "mobile network" should not mean only "PAN" but also
"LAN": the aircraft case, more than 3-4 hosts behind MMH, probably
with a simple router linking the cockpit with first class passengers
(one prefix) and second class passengers (another prefix, same length
as first, longer than cockpit's).

> I think the design space is quite large.  One case is when the MNNs
> are statitionary with respect to the MR and don't observe that the
> MR is moving.

Yes, this case is the most probable, should be treated first.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: 20 Aug 2001 15:28:41 +0200

Erik Nordmark <[email-masked]> writes:
> since, depending on the actual model for securing BUs, it might be
> hard or impossible for a 3rd party like the MR to send BUs for its
> MNNs.

A 3rd party like MR _could_ verifiably send BUs for its MNN's, as a
prefix: the CN could ensure the prefix belongs to MR by verifying
special requirements on the HA address, the MR home address and the
MNN home address.

> But if the MNNs are made aware that the MR is moving then they can
> use the regular BU mechanism for route optimization.

Provided that you require MNN's to send BU's only for CN's for route
optimization, and not to HA, this can still fit the original
motivation behind MR: send only one BU for the whole prefix (to HA
only in this case).

> which correspondents to update with the temporary CoA, the stable CoA,

Interesting, this should be checked.

These features would probably fall under a stronger requirement than
the initial.  Here the MNN's can detach and reattach somewhere else.
It's even stronger than your previous paragraph in which MNN's were
only aware of mobility of the subnet.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Aug 2001 15:35:10 +0200 (CEST)

> special requirements on the HA address, the MR home address and the

I have not seen a draft specify how this can be done securely.
Do you have a pointer to a draft?

> motivation behind MR: send only one BU for the whole prefix (to HA

Sure, as I've said in other emails, the authorization issues for
the MR to HA communication can be solved - this is essentially a pre-configured
relationship in any case.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 20 Aug 2001 17:52:54 +0200

> Do you have a pointer to a draft?

I was not referring a specific draft.  I just wanted to say that if we
put strong aggregation requirements on the HA address, the MR home
address and the MNN address, I think the legitimate prefix can be
deduced at the CN.  Part of this has been mentionned previously in the
thread.

Of course there are limits to this.  For example, if I impose that the
HA address and the MR home address differ on the first bit following
that legitimate subnet prefix-1 then stateless autoconfiguration would
fall appart.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Aug 2001 18:43:00 +0200 (CEST)

> deduced at the CN.  Part of this has been mentionned previously in the

I know this has been mentioned and hand-waved around before.
However, I've seen nothing of substance on how this is doable in a secure
fashion under reasonable trust models.

Are you assuming that any CN would (for instance) accept a BU for a /64 prefix
from anybody? How can the CN verify the authority for such a BU?

  Erik

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 20 Aug 2001 20:36:52 -0700

Hello Erik,

> mobile network to be a transit for other packets.

While I am willing to agree with the probable result of your
statement, I don't agree with the statement itself.

It _does_ make sense for a mobile network to be a transit
network.

On the other hand, we don't have to solve that problem in
this working group.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: 21 Aug 2001 10:46:25 +0200

Charlie Perkins <[email-masked]> writes:

> It _does_ make sense for a mobile network to be a transit network.

Could you, please, give an example of it?  I can only imagine that the
moving subnet has other sub-subnets under it and it would transit
packets to those sub-subnets.  Those would still be leafs.

> On the other hand, we don't have to solve that problem in this
> working group.

Yes, is there another better adapted place where one could discuss
about this?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: 20 Aug 2001 19:31:29 +0200

Erik Nordmark <[email-masked]> writes:
> Are you assuming that any CN would (for instance) accept a BU for a
> /64 prefix from anybody? How can the CN verify the authority for
> such a BU?

Let me give it a try, thanks for reading it.

MNN-away from home sends packet to CN; MR-away-from-home intercepts
and sends BU to CN containing that MNN's home address, MR's home
address and probably others.  Upon receipt of BU, CN sends request
packets to MR's home address and MNN's home address that are
intercepted by HA.  HA replies to CN ok.

The requirement is to have MR's home address and MNN's home address
match their first /64 bits and differ on later bits.  The position of
first differing bit (say the 65th bit) gives the length of prefix that
MR can claim.  The MR can claim /65.

In other words, when receiving a prefix BU, a CN should accept it only
if (1) it has answers from HA for MNN's home address and for MR's home
address and (2) if MNN's home address and MR's home address respect
the above requirement.

I hope it's not too naïve,

Alex