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

From: "T.J. Kniveton" <[email-masked]>
Date: Fri, 10 Aug 2001 10:30:49 +0100

During the London meeting, Thierry Ernst talked about support for Mobile
Networks under IPv6. There was some concern about how to properly
authenticate authorization for the ability to change subnet routing
information. For instance, it seems to be trickier to know when to allow
a binding for a /4 prefix than for a /128 prefix (host) on a
correspondent node. This opens up a nasty redirection attack on any
correspondent node supporting mobile routers.

Putting aside route optimization and the processing of prefix scope
binding updates on the CN, the problem is greatly reduced. At the home
agent, there is already some configuration presumed, and deciding which
prefixes are assigned to which MRs (and hence, which PSBAs to accept) is
more feasible. In the worst case, if a HA does not discriminate in
accepting these bindings, the /4 hijacked prefix would only be forwarded
to the MN for packets generated internally by the HA (while acting as a
CN); however, packets will never show up on the home link destined for
the MN, since the upstream aggregation routers will not forward these
packets to the home link, but rather to the correct part of the network
where the /4 prefix really lives.

A side effect of this is that prefixes used by MRs will have to be
topologically correct, in that they must in the usual case be routed to
the home link. This seems like a good feature, since the CN can rely on
the prefix ownership authorization that is implicit in the topology and
router configurations.

-TJ

---

From: Alexis Olivereau <[email-masked]>
Date: Fri, 10 Aug 2001 12:28:35 +0200

Hello TJ,

Actually Binding Updates for prefixes do not disable route optimization
feature. Clearly, the authorization process is trickier. It can however
be performed provided that it makes use of the knowledge the HA has
about the binding 'Mobile Prefix' / 'Mobile Router'. HA can then be
asked by the CN before CN updates its Binding Cache upon receiption of a
prefix BU.
In draft-ernst-mobileip-v6-network-02.txt, we study a light enhancement
to BAKE that allows to use it to authorize a prefix BU.

Regards,
Alexis.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Aug 2001 14:39:01 +0200 (CEST)

> where the /4 prefix really lives.

I think you can solve the above without any prefixes in the BUs.

The scenario I'm thinking about is something like a personal area network
with a router at its edge - I carry the whole PAN including the router
with me when I walk.

When I'm at home the PAN router has adjancencies with other routers attached
to the home link which it uses to exchange routing information about the
subnet prefixes assigned to my PAN.

When I move away from home it is sufficient for the PAN router to
 - send a binding update for its own address (which the other routers
   have as the nexthop in the routing tables). This BU will
   have the R-bit set so that NUD works.
 - tunnel all traffic from the PAN back to the home network.

Thus the PAN router will continue to exchange reachability information
with the routers on home network using the routing protocol (e.g. OSPF).
All packets will be tunneled in both directions. The nodes in my PAN
will not notice that they are moving.

At least the above provides a basic level of support for this scenario.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Aug 2001 14:39:05 +0200 (CEST)

> asked by the CN before CN updates its Binding Cache upon receiption of a

I don't understand how the CN checking with the HA solves the trust issue
for using BUs to redirect whole prefixes.

Example:  I run a MN and a HA . My MN sends a BU for a /3 to a CN
the fact that my MN says "yes" when the CN asks if the binding is ok.

The redirection of a prefix must be related to the routing for that whole
prefix going to the HA. In general you can't verify that this is the case
for a prefix without actually sending packets to all IP addresses in the
prefix and seeing that you get a response back from the HA.

But, what problem are we really trying to solve by being able to send
a BU for a whole prefix?
This seems like optimizing something which is close to a non-problem.

  Erik

---

From: Mattias Pettersson <[email-masked]>
Date: Mon, 13 Aug 2001 16:26:25 +0200

Hi Erik,

>  - tunnel all traffic from the PAN back to the home network.

This is exactly what I pointed out to Thierry a while ago. If routing is
consistent and transparent with regards to this home link, I also think
that this is the ideal solution.

However, Mobile IPv6 fails to be fully transparent when it comes to
link-local addresses.

Unfortunately, we couldn't make an agreement on how nodes would
function. It is obviously implementation dependent whether the home
agent will do binding cache lookup and routing table lookup in the
correct order to allow this.

I pointed out that a BSD home agent could probably work like described
above, but Thierry shows in the draft that INRIA's MIPv6 code would not.

> will not notice that they are moving.

Routing protocols use link-local addresses, so this would fail (at least
with today's specification of Mobile IPv6 and routing protocols).

Maybe Mobile IPv6 should be changed to tunnel *all* packets.

> At least the above provides a basic level of support for this scenario.

/Mattias

---

From: Michael Thomas <[email-masked]>
Date: Mon, 13 Aug 2001 07:58:10 -0700 (PDT)

> will not notice that they are moving.

   Sure. All you've done is managed to avoid the hard
   problem which is route optimization :-) Maybe this 
   inevitable since the problem is obviously not a 
   trivial one, but there are issues of reliabilty
   and robustness which need to be considered. The
   MR's home agent provides an additional single point
   of failure, so the fate sharing is wrong. For MIPv6,
   this is supposed to be a transient single point of
   failure (on the average case), so that seems like
   an acceptible design tradeoff. However, if we relegate
   MR's (which potentially subtend very large subnets for,
   oh say, planes or ships) to dog leg routing, we're 
   actually *increasing* the desire for robust and
   optimal routing. As you add more layers of mobility,
   the path becomes more and more fragile which doesn't
   seem very satisfying. In fact, it starts to resemble
   the PSTN...

	Mike

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Aug 2001 19:37:25 +0200 (CEST)

> However, Mobile IPv6 fails to be fully transparent when it comes to

Are you concerned about the link-local addresses used e.g. by OSPF to
communicate with the routers on the home link, or some other use of
link locals?

Given the current specification, which says that the HA must not tunnel
link locals to the MN, I think the only solution is
to make the MR, when away from home, have a router adjacency with the HA
i.e. it will be two hops away from the other routers on the home link.
This might mean that when moving to or from the home link all
the adjacencies will be torn down and new ones created.
Or it could choose to always maintain a tunneled adjacency with the HA - even
when at home.

> Maybe Mobile IPv6 should be changed to tunnel *all* packets.

But that means that the MN will see e.g. all mulicast ND packets which might 
not be that good use of bandwidth. From an architectural perspective this
would make the HA an L2 bridge instead of a L3 router.
If there are different links the thing that connects them is a router
and link-locals don't cross between links.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Aug 2001 19:51:28 +0200 (CEST)

>    problem which is route optimization :-)

I think my note had "basic" in there :-)

If you want something more signifant to think about then there is
the train case with different adminstrations and a different HA for
the MR (HA1) and a for a particular MN on the train (HA2).

In order to illustrate the route optimization choices let's look at
a possible way to approach this problem:

Without route optimization that case works as follows:
MR updates HA1 with its current topological location as the train
moves.
When MN arrives on the train it uses addrconf to get an address under MR's 
prefix. Create co-located COA. It updates HA2 with this as the COA.

CN looks up MN in DNS. Sends packet to that are intercepted by HA2.
HA2 tunnels packets towards MR thuse the packets are routed towards HA1.
HA1 in turn tunnels the packets to MR's COA.

MR decapsulated and sends the singly-tunneled packets to MN's COA.

For the forward path there are two HAs that can be optimized out.
Depending on traffic patterns and relative movement speed at the
two attachment points (MN attaching to MR, and MR attaching to some
access router along the train track) all 4 possibilities of optimization might
make sense
 - optimize out both HAs
 - optimize out HA2 (if MN stays on the train for a long time)
 - optimize out HA1 (as long as MR doesn't get handed off too often)
 - optimize out none

So just like in the simple mobile node case there are tradeoffs between
the signalling involved in doing route optimizations and savings from
more efficient routing, but in the MR case there are more variants
on what to optimize.

  Erik

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 14 Aug 2001 11:50:07 +0200

[Dropped T.J. from CC list since I believe he's on mobile-ip anyway]

> communicate with the routers on the home link, or some other use of

That's right. Routing protocols such as OSPF or RIP uses link-local
addresses, both for communication and of course identifies adjacent
routers by their link-local addresses.

> Or it could choose to always maintain a tunneled adjacency with the HA - even

Both sounds reasonable. But home agents are routers, and if you want
redundancy or load sharing by using multiple home agents on the home
link, you would anyway end up with multiple routers adjacent to the MR.
Unless you explicitly choose one of the HAs, also when you are at home.

Regarding your first proposal to have MR adjacent to all routers on the
home link when it is home, and then make it reachable behind the HA when
not at home: how fast can routing protocols reflect this change? If the
other routers are not updated quickly when the MR moves away, they will
keep sending packets to MR's link-local address (according to routing
protocol). The HA has sent proxy NA for MR's link-local address, and the
packets will end up at the HA, which will tunnel them to the MR. This
way will work.

Soon after MR has moved away it will now send routing protocol updates
through the bi-directional tunnel to the HA. Routers on the home link
will know the mobile network is behind HA. They will now send packets to
the HA's link-local address.

When the MR returns home, MR will de-register with HA. Still, the
routers have the HA's link-local address as gateway for the mobile
network, until the MR sends new routing protocol updates on the link.
During this interval, packets will be lost. The HA itself doesn't know
where to send the packets that the routers keep sending to it.

Either, synchronize the BUs with the routing protocol updates, or use a
tunnel to the HA, also when the MR is at home.

> and link-locals don't cross between links.

Ok.

Or maybe ND packets can be filtered out.

/Mattias

---

From: Alexandru Petrescu <[email-masked]>
Date: 13 Aug 2001 16:26:18 +0200

Erik Nordmark <[email-masked]> writes:
[...]
> But, what problem are we really trying to solve by being able to
> send a BU for a whole prefix?  This seems like optimizing something
> which is close to a non-problem.

Yes, I would also like to see it more clearly.  As I understand it
from Thierry's works:
-avoid that every MN sends a BU when the entire subnet changes the
 attachment point.  Send only one BU covering all MN's.
-avoid maintaining "per-host tunnels" in the HA for every MN in the
 mobile subnet.  Use routing features instead, only one entry in the
 HA's binding cache for all MN's in the mobile subnet.
-the MN's in the mobile network are not aware of mobility.

We should probably evaluate how much of the above items are
non-problems and how much of them are true problems.

Cheers,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: 13 Aug 2001 16:46:57 +0200

>  - tunnel all traffic from the PAN back to the home network.

There's at least one thing that won't work in this scenario: when HA
defends MR's Home Address it has an entry in the Binding Cache
containing MR's CoA and MR's Home Address, but not the MNN's Home
Address.  Thus it can't relate an incoming packet for that MNN to that
MNN's Home Address.  Unless more clarification is added to how the
Binding Cache is searched.

Quoting from -13:

         "-  The home address of the mobile node for which this is the
             Binding Cache entry.  This field is used as the key for
             searching the Binding Cache for the destination address of
             a packet being sent.  If the destination address of the
             packet matches the home address in the Binding Cache entry,
             this entry SHOULD be used in routing that packet."

         "-  The care-of address for the mobile node indicated by
             the home address field in this Binding Cache entry.  If
             the destination address of a packet being routed by a
             node matches the home address in this entry, the packet
             SHOULD be routed to this care-of address, as described in
             Section 8.9, for packets originated by this node, or in
             Section 9.6, if this node is the mobile node's home agent
             and the packet was intercepted by it on the home link."

Having said this, I know there'll be change on how and where this
subject will be treated, I'll adapt accordingly later.

Alex

---

From: Alexis Olivereau <[email-masked]>
Date: Mon, 13 Aug 2001 16:33:48 +0200

> the fact that my MN says "yes" when the CN asks if the binding is ok.

First I think you mean " HA says 'yes' " (?) A part of your text seem to
have disappeared here...
In my understanding you have a malicious Mobile Router _and_ a malicious
Home Agent, the former counting on the latter to validate faked Binding
Updates. 
Now when CN sends a 'question message' to MR's Home Address, malicious
HA should not discard the message but continue the process. Well... but
the question is: why would the home address be routed towards your
attacking Home Agent? Do you mean you have also managed to remotely
configure routing tables of the target Home Network? Then you are not
limited to a faked BU attack and can envision large scale DoS against
the Home Network...

> prefix and seeing that you get a response back from the HA.
Correct me if I am wrong: you mean that BAKE is secure in the sense that
the reachability of the MN is verfied. For a MR we should then verify
the reachability of all nodes the MR serves. I do not think it is the
only means. In the solution we propose, we use the same process to make
sure that we can reach the MR via its Home Address (so should be each
node below, provided that MR does not lie). BUT in addition to that
basic verification, HA is required to check the prefix the MR sent a BU
for (check the binding [MR H@ / Mobile prefix]). Thus we guarantee that
any node served by MR will be reachable through the new MR Care-of
Address.

Alexis.

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 14 Aug 2001 14:18:26 +0200

> that this is the ideal solution.

I am not sure.  I may have missed something here.  I agree with you in
the simplest case where the "Mobile Network Prefix" is the same as the
"home link prefix" with a longer prefix, otherwise I am kind of
sceptical.

> above, but Thierry shows in the draft that INRIA's MIPv6 code would not.

INRIA MIPv6 is actually FreeBSD.
If distinct implementations lead to distinct results, this means that
the MIPv6 specification needs a word about it.  It is not clear if the
HA is able to tunnel packets intended to the other devices behind the
mobile router.  The processing of the R-bit by the HA needs
clarification. 

> with today's specification of Mobile IPv6 and routing protocols).

Exact...
 
> Maybe Mobile IPv6 should be changed to tunnel *all* packets.
... and this would  introduce other issues.

What I am saying here is that things get more complicated for a mobile
node which is also router.   There are many issues to care about, and
this cannot be solved as easily as one would think.

Thierry

--
* mailto:[email-masked]  Tel +33 (0) 4 76 61 52 69 
* INRIA Rhone-Alpes Projet PLANETE       (fax 52 52) 
* and MOTOROLA Labs Paris
* http://www.inrialpes.fr/planete/people/ernst/Welcome.html

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 14 Aug 2001 14:22:44 +0200 (CEST)

> First I think you mean " HA says 'yes' " (?) A part of your text seem to

Yes that was what I meant to say.

> Home Agent, the former counting on the latter to validate faked Binding

Correct.

> limited to a faked BU attack and can envision large scale DoS against

No - no attack is needed on the routing system.

I have a home address (X/128) which is routed towards my HA.
That part is legimtimate.

But this doesn't mean I have authority to affect routing for e.g. 
the X/3 prefix.
How can a CN tell whether a given HA+MR is allowed to affect routing
for a given prefix? That is the core of the authorization issue.

> any node served by MR will be reachable through the new MR Care-of

So how do you handle the case I'm trying to explain above?

   Erik

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 14 Aug 2001 14:34:51 +0200

> I think my note had "basic" in there :-)
By basic, you mean "no routing optimization".  I advocate that providing
routing optimization is a requirement.  You also demonstrate a need to
support VMNs; at the same time this also highlights an even more
important need for routing optimization.

> the MR (HA1) and a for a particular MN on the train (HA2).

Nested mobility.
 
> MR updates HA1 with its current topological location as the train

What do you mean by "current topological location" ?  You probably want
to say "its current COA".

> MR decapsulated and sends the singly-tunneled packets to MN's COA.

Double dog-leg routing, and double encapsulation on the wireless link.  
Something we should definitely avoid.

> more efficient routing, but in the MR case there are more variants

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 14 Aug 2001 14:45:19 +0200

> for a given prefix? That is the core of the authorization issue.

A /3 is not a really a  good instance of a prefix.  I would rather say a
/48.

What we need:
- first, the MR must "own" the prefix /P.  This means that whatever
prefix longer than P belongs to MR.
- second, a means to certify that prefix /P is effectively owned by MR.
 
> So how do you handle the case I'm trying to explain above?
draft-ernst-mobileip-v6-network-02.txt section 5.

Thierry

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 14 Aug 2001 14:51:28 +0200

> But, what problem are we really trying to solve by being able to send

Routing optimization.

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 14 Aug 2001 15:12:54 +0200

> Binding Cache is searched.

We had a discussion on this earlier this year. Anyway, the I-Ds are not
explicit about packet handling, mostly because it is up to the
implementor. This is also a source of misunderstanding.

I proposed (and Erik means the same, I think) to do a mapping between
the MR's home address and its CoA in the HA. A binding for the mobile
prefix (that MNNs belong to) is not needed, since the HA _should already
have_ one in its routing table. This entry is created from routing
protocols between the MR and the home link routers, including the HA.
That entry simply tells the HA to route traffic to the mobile prefix to
the gateway address of the MR.

[Ok, this introduces another problem. The gateway address should be a
link-local address, since routing protocols use that. Mobile IPv6 does
not suggest forwarding of packets destined to a link-local addresses,
but the destination in the packets are e.g. global, since its the MNN.
However, the HA will first have to do a lookup on the destination
address (MNN), and it will see that it should use MR's link-local
address. Next, it should consult its Binding Cache to find that this
packet should be forwarded to the MR's CoA by using a tunnel. The
special order in which routing table and binding cache lookups needs to
be done is far from common practice, and I don't think this will work
smoothly with all implementations out there.]

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 14 Aug 2001 15:36:11 +0200

> "home link prefix" with a longer prefix, otherwise I am kind of

But the Mobile Network Prefix can't be a subset of the home link prefix.
They should be parallel and both have /64. Or am I wrong? Don't you want
ordinary hosts on the home link as well?

> INRIA MIPv6 is actually FreeBSD.

I know. My feeling with the example in your draft is to support your
prefix BU. Perhaps INRIA's implementation could be made to work like I
described, without use of of prefix BU. Not without modification, but
anyway.

> mobile router.  The processing of the R-bit by the HA needs

Good point.

> this cannot be solved as easily as one would think.

I agree. This is not so easy at all. Mobile IP as a general vision could
probably seem to work fine for both hosts and routers. But with all work
currently done with MIPv6, ND and so on is to support mobile hosts only.
In the detailed design work, only hosts have been considered. Nobody
really thought on the routers, until now.

/Mattias

---

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

> the gateway address of the MR.

Is HA necessarily located in the BR (Thierry's border router)?  Is HA
necessarily running a routing protocol?  Is HA necessarily
participating in route exchanges if it's not a router?  I need to
understand this.

> not suggest forwarding of packets destined to a link-local
> addresses...

I agree with the link-local reasoning.  In fact I also pointed it to
Thierry late last year.  Hopefully it will make it into future
versions of the draft.

> address.

This works fine if HA has a route to MR's subnet.

> Next, it should consult its Binding Cache to find that this packet
> should be forwarded to the MR's CoA by using a tunnel. The special
> order in which routing table and binding cache lookups needs to be
> done is far from common practice, and I don't think this will work

An alternative to coupled binding cache/route table lookups would be
to extend the binding cache entry with a third address: the network
prefix behind the respective home address.  This way the HA is not
required to participate in route maintenance (route maintenance is
done not only for subnets behind MR's but also all other fixed routers
on same home link).

This alternative is different from Thierry's draft as well as from the
short lived -14.

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 14 Aug 2001 16:13:34 +0200

> ordinary hosts on the home link as well?

Indeed, I wouldn't exclude this case. 

What do you mean by "If routing is consistent and transparent with
regards to this home link, I also think that this is the ideal solution.
" in a previous mail ?  You just want to say that MR does not need to
carry the Mobile Network Prefix in order to register with the HA ?

> described, without use of of prefix BU. Not without modification, but

I could only agree with you as far as you don't want routing
optimization.  But an important aim of my draft is to allow optimal
routing, and the prefix is needed for that.  This is the justification. 
Do you disagree with that ?
 
> really thought on the routers, until now.

Yes. Then, the conclusion would be that we should add something like the
following in the MIPv6 spec:
"MIPv6 is a solution to support mobile nodes.  It does not support nodes
behind a mobile router".  Dot.  I don't remember who, but someone said
that we have to insure that what is in the mipv6 draft does not pretend
to support mobile networks.  Then, mobile networks will be addressed in
an other spec.

I think that we had consensus on this at last MIP WG meeting.

Thierry.

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 14 Aug 2001 16:37:29 +0200

Alexandru Petrescu wrote:
> Is HA necessarily located in the BR (Thierry's border router)?  

No.

> Is HA

As I see it, HA is a router since it forwards traffic that is not
destined to itself. It can have one physical interface (but maybe one
additional virtual tunnel interface for each MN it serves).

> done not only for subnets behind MR's but also all other fixed routers

Yeah, maybe. But I feel that we should try to make Mobile IPv6 with
minimal inpact on other protocols.

If HA is a standard router as well, should it have special handling of
routes to some adjacent routers (i.e. MRs)? What if the MR is at home -
should it now exchange routing info with the HA as a normal router would
do?

Or maybe we need restrictions on how home links are configured and what
nodes we put there.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 14 Aug 2001 16:55:56 +0200

> carry the Mobile Network Prefix in order to register with the HA ?

First, I still can accept that we use prefix scoped BUs. For another
reason, that is not part of this particular discussion, I suggested that
each MNN takes care of its own home registration. It has pros and cons,
but at least we don't need to check authorization of prefixes.

The HA, when acting as a CN (i.e. initiating traffic itself), *then* it
would need a prefix scoped BU. But when it is only intercepting and
forwarding packets initiated by others, a standard entry in the binding
cache plus a routing entry for the mobile network prefix would be
sufficient.

Back to your first question: I get the feeling that some original design
ideas behind Mobile IP was to emulate that the MN is at home, even when
it isn't. To do this, we need a helping hand (the HA), but we should
make as little impact as possible. But with current Mobile IPv6 spec,
somewhere a line is drawn which says that functions on one side is
emulated so that everyone using these functions towards the MN thinks
the MN is always at home, while a few other functions can't be hidden.
Example of latter are: link-local addresses, ND, home address address
assignment (especially stateful), mobile routers... 

Since we have decided not to forward link-local addresses, we will have
to take the consequences of that. This short-cut or optimization was
good for one thing (not wasting bandwidth) but is bad when we (I) want
to make MRs work like they were always at home.

> Do you disagree with that ?

I want route optimization too. I just feel that maybe forwarding and CN
part of HA can be separated, and you are doing to much to make it work.
The forwarding part would work anyway, without prefix scoped BU. But the
CN part needs it. Please see above.

> to support mobile networks.  Then, mobile networks will be addressed in

Yes.

/Mattias

---

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

Alexandru Petrescu wrote:
> > Is HA necessarily running a routing protocol?  Is HA necessarily

Mattias Pettersson <[email-masked]> writes:
> destined to itself. 

HA indeed "forwards" traffic but not at IP level, thus it's not a
router.  HA builds tunnells to its MN's, in something some call the
"Mobile IP plane", different than the "IP routing plane".

> minimal inpact on other protocols.

Fair enough.

But I thought we talk here Mobile Networks and not Mobile IPv6.  My
approach is to stay independent of the searches in the routing table.
I see this as having minimal impact on other things.  Or what did you
mean by "other protocols"?

> should it now exchange routing info with the HA as a normal router would

HA _software_ could run on the same machine that runs routing
_software_ but I think the two should be as independent as possible.
The question you pose above being related to routing software it
should have no impact on HA.

You stated previously you wish minimal impact on other protocols.  I
understand this as "don't modify routing protocols" and "least modify
Mobile IP".

Alex

---

From: Michael Thomas <[email-masked]>
Date: Tue, 14 Aug 2001 14:15:29 -0700 (PDT)

> prefix and seeing that you get a response back from the HA.

In fact, it's not necessarily the HA. It's the
topologically closest router to the CN which
advertises that prefix. For a /3 (wow, where'd you
get one of those??) that's probably going to be a
core router which wants the Yea or Nay vote on
that, not the HA or anything else.

Another thing to consider is that the HA can
be evil and in collusion with the MR.

	Mike

 > This seems like optimizing something which is close to a non-problem.

Er, if I could smooth the triangular routing for,
say, an aircraft carrier through it's MR's home
agent, that sounds like a pretty big win to me.
In fact, it's arguable that the larger the prefix,
the larger the motivation to optimize (hence
renumbering too.)

			Mike

---

From: Mattias Pettersson <[email-masked]>
Date: Wed, 15 Aug 2001 16:09:47 +0200

> "Mobile IP plane", different than the "IP routing plane".

Ok. That's your terminology and your point of view. I explained mine. I
think implementations will vary just like that.

> mean by "other protocols"?

For instance, RIP and OSPF.

> understand this as "don't modify routing protocols" and "least modify

Because if Mobile IPv6 (or Mobile Network Support) must have a protocol
hack or its own proprietary for each other L3 protocol, I am getting
scared. I hope we don't have to do that.

Still, how should the MR function when it is at home? Then Mobile IPv6
shouldn't do anything, should it? Who would take care of routing updates
then?

Personally, I would like to get away from that old behaviour (that a MN
at home is just like any other node) and go for more homeless mobile
nodes.

/Mattias

---

From: Alexandru Petrescu <[email-masked]>
Date: 16 Aug 2001 12:55:45 +0200

> think implementations will vary just like that.

You're absolutely right.  Sorry for making too much of a strong
statement, it's indeed my humble way of seeing things.

> For instance, RIP and OSPF.

I asked also, why not RIP or OSPF?  Several reasons, _IMHO_.  Same
scalability issues that applied when designing Mobile IP will apply to
Mobile Networks.  How fast routes get updated?  How many routes change
at how many routers? Also, in my understanding, off-the-shelf RIP
would not suffice, one needs Triggered RIP.  Also, RIP's bad news
don't propagate quickly, so don't rely on it to tell CN's that MR's
are no longer there.

I completely agree that one could look into routing protocols when
designing a mobile networks solution, but what would be the goal?
Proper setting of RIP/OSPF?  Or a modification of RIP/OSPF?

> Because if Mobile IPv6 (or Mobile Network Support) must have a
> protocol hack or its own proprietary for each other L3 protocol, I
> am getting scared. I hope we don't have to do that.

This is what I believe too.  This is why I'm also proposing not to
tightly couple searches into binding cache with searches into routing
table.

> Still, how should the MR function when it is at home? Then Mobile
> IPv6 shouldn't do anything, should it? Who would take care of
> routing updates then?

The questions are very valid, IMHO.

Regarding the last question only, why would a router of a small PAN
have to deal with routing updates?  I was thinking it could only have
one (or a few) static routes to its subnet and a default route towards
the AR (this would be discovered with ND, no routing updates).

> Personally, I would like to get away from that old behaviour (that a
> MN at home is just like any other node) and go for more homeless
> mobile nodes.

Wasn't there a draft "homeless Mobile IP" somewhere?

Alex

PS: I start to think that I would have liked to see the short lived
    -14 to advance and not get trimmed of those prefix sections.

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 16 Aug 2001 13:32:13 +0200

> don't propagate quickly, so don't rely on it to tell CN's that MR's

Sorry, I can't see what CN this would affect.

Also, your argument is an indicator to that Mobile IPv6 should hide the
fact that the MR is moving. In other words, not show that to RIP.

Erik talked about tunnelling between the MR and HA, also when the MR is
home.

> tightly couple searches into binding cache with searches into routing

Ok. You want the same thing, only we see different problems here.

> the AR (this would be discovered with ND, no routing updates).

Outbound traffic from the MR's subnet is more of default route type. But
still, a router should not be listening to RAs (or a router enabled
interface). Or have I got this all wrong?

Anyway, inbound traffic to the MR's subnet is more problematic. You
suggest static routes. In some cases this is ok, I suppose. But an ISP
with a lot of MRs would likely prefer some automation here. A new
protocol?

> Wasn't there a draft "homeless Mobile IP" somewhere?

Yes, draft-nikander-mobileip-homelessv6-01.txt.

/Mattias

---

From: Alexandru Petrescu <[email-masked]>
Date: 16 Aug 2001 15:14:58 +0200

> Sorry, I can't see what CN this would affect.

Right, I meant CN's TCP will retransmit because MN unreachable.

> Also, your argument is an indicator to that Mobile IPv6 should hide
> the fact that the MR is moving. In other words, not show that to
> RIP.

Right, kind of.  I think a solution can be designed where tunnelling
is used between HA and MR-not-at-home (without tunnelling route
adjacency, looks complex) and routing is used only between HA and
MR-at-home.

> Erik talked about tunnelling between the MR and HA, also when the MR
> is home.

YEs, I reread his messages.  Thanks for pointing it out.

> Outbound traffic from the MR's subnet is more of default route
> type. But still, a router should not be listening to RAs (or a
> router enabled interface). Or have I got this all wrong?

Oops, _I_ might have it all wrong.  Shame.

So how do MR's get a CoA?

> suggest static routes. In some cases this is ok, I suppose. But an
> ISP with a lot of MRs would likely prefer some automation here. A
> new protocol?

You enlarge the _number of MR's_, I was saying that the _number of
hosts_ in a PAN is small and thus MR has probably only a very few
prefixes (read 1) it knows to route.

But I'll go back read that route adjacency thread.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Aug 2001 15:52:08 +0200 (CEST)

> important need for routing optimization.

Thierry,

By "basic" I meant to imply that while the current MIPv6 spec (through
the R bit in the BU) has some basic support in this general direction -
that's all.

I guage from the discussion that there is interest in doing more
than this. The best way for this to proceed is to initially try to get
shared understanding on a problem statement, terminology, and
how this relates to different scenarious that folks want to deploy.

But please folks (on the mailing list in general), 
don't think that authorization and other security issues
can be left until later - those need to be a fundamental part of the
thinking from the start.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Aug 2001 16:03:06 +0200 (CEST)

> draft-ernst-mobileip-v6-network-02.txt section 5.

I didn't see anything in that section saying how a random CN 
can trust the prefix privided by the MR in the BU
except bythe CN blindly trusting the HA.

Also, section 5 doesn't even appear to be concerned with the threat
I've brought up (which is that an MR specify a shorter prefix
length than it is authorized to route with the cooperation of the
MR's HA).

The only threat explicitly listed is that an MN served by the MR send
a BU for the prefix, which clearly the HA+MR can reject as pointed out
in that section.

Is there a need for a threat analysis?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Aug 2001 16:10:46 +0200 (CEST)

> to support mobile networks.  Then, mobile networks will be addressed in

If the WG decides to go that path, which is definitely an option,
to be constitent with the above wording the WG needs to remove 
the "R (Router)" bit from the binding update option.

If the WG instead likes to keep that bit the above note needs be written 
to take into account that the R bit can be used to support some very 
limited form of MRs.

Just to be consistent,
  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Aug 2001 16:20:11 +0200 (CEST)

> but at least we don't need to check authorization of prefixes.

Perhaps I've missed a subtle point in the discussion.
Let me try to clarify.
I think it is intractable for a CN to verify the authorization for
BUs for prefixes.
However, a home agent could do this by manual configuration.
In the precense of such manual configuration there might not
need to be a prefix in the BU. The prefix could be implicit
in the prestablished setup between the HA and MR.
Thus when the MR does a binding with its HA the HA would automatically
associate the appropriate prefix route with that prefix.

[However, it would be interesting to compare the resiliency against HA failures
between such a simple scheme and a scheme where the MR establishes effectively
a tunnel to multiple routers on the home link and uses a routing protocol over
those tunnels. Such a scheme would create routing traffic but would be able to
recover from HA failures more rapidly.]

> cache plus a routing entry for the mobile network prefix would be

Presumably one can make both the originating and forwarding aspects of
a HA take the prefix into account - the authorization issue is
indepedent of this.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Aug 2001 16:23:34 +0200 (CEST)

> "Mobile IP plane", different than the "IP routing plane".

The only concise definition of "router" I know of is captured in RFC 2460:
   router      - a node that forwards IPv6 packets not explicitly
                 addressed to itself.  

By this definition a HA is a router.
Which is your definition of a router?
The HA needs to decrement ttl when forwarding the packets and as far as I
know that is part of the "IP level".

   Erik

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 16 Aug 2001 17:31:17 +0200

> Right, I meant CN's TCP will retransmit because MN unreachable.

Yes, if we go for a solution where routing protocols will reflect in
some manner that the MR is away, then they have to be fast (which is
unlikely) or the HA must cover up for the MR.

Of course we don't want CN to get destination unreachable icmp error.

> adjacency, looks complex) and routing is used only between HA and

Ok, if possible.

> So how do MR's get a CoA?

This is a paradox, I'm afraid. Routers should not autoconfigure.

Sometimes routers shouldn't even have a global address, but only a
link-local.

I believe we need to do work in this area, because ND spec is not
covering this.

> prefixes (read 1) it knows to route.

All true, but I meant that there could possibly be a large number of MRs
belonging on the home link, each with one (or multiple) mobile subnets.

/Mattias

---

From: Alexandru Petrescu <[email-masked]>
Date: 16 Aug 2001 18:00:07 +0200

I made the distinction HA - router mainly to stress that HA can be
physically separated of the AR and that it is not likely to
participate in route maintenance protocols.  But I might have it all
wrong, thanks for helping me understanding these issues.  I recognize
my ignorance in my first appreciation.

> By this definition a HA is a router.

Indeed.

> Which is your definition of a router?

Why isn't Mobile IPv6 spec requiring the HA to join all-routers mc
address?

Why isn't Mobile IPv6 spec requiring the HA to send router
advertisements? [*]

Alex

[*] Well the -13 doesn't require it in 7.3. Requirements for IPv6
    Home Agents, but it does talk about it in 4.1. Basic Operation:

  "This list of home agents is maintained by each home agent on the
   home link through use of the Home Agent (H) bit in each home
   agent's periodic unsolicited multicast Router Advertisements."

---

From: Alexandru Petrescu <[email-masked]>
Date: 16 Aug 2001 18:22:48 +0200

> Why isn't Mobile IPv6 spec requiring the HA to send router

Sorry, I had it wrong again.

Alex

---

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

Erik Nordmark <[email-masked]> writes:
> If the WG decides to go that path, which is definitely an option, to
> be constitent with the above wording the WG needs to remove the "R
> (Router)" bit from the binding update option.

I'm not sure how easy this will be since it's used in the binding
cache too and from there into the modified Router Advertisement.

The latter should be kept, I think, being used by other things than
the R bit from cache.

Alex

---

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

"T.J. Kniveton" <[email-masked]> writes:
> There was some concern about how to properly authenticate
> authorization for the ability to change subnet routing
> information. For instance, it seems to be trickier to know when to
> allow a binding for a /4 prefix than for a /128 prefix (host) on a

MNN-away-from-home sends packet to CN through MR.  MR decides it
should send a BU to CN and it sends a BW (B Warning) providing its
MR-CoA, the MR-subnet prefix, the MR Home Address and the MNN home
address (must fit into MR-subnet prefix).  The CN then sends a sort of
request to MNN home address that gets to the true HA and that says
"yes, MNN home address is under the MR; yes, MR-subnet prefix is his".
At that moment only CN updates its cache.

Alex

---

From: Alexis Olivereau <[email-masked]>
Date: Fri, 17 Aug 2001 14:35:23 +0200

> except bythe CN blindly trusting the HA.

You are right, thank you for pointing out that possible attack. Section
5 will be updated soon to provide a security context that will no longer
be dependent on HA certification.
Note however that the authorization problem you raised here does not
necessarily lead to "sending packets to all IP addresses in the prefix
and seeing that you get a response back from the HA".
We are currently checking two other solutions that should be fittable to
solve the problem without extra messaging.

Alexis.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 17 Aug 2001 11:05:12 +0200 (CEST)

> cache too and from there into the modified Router Advertisement.

It's use in the binding cache is solely to be able to set the R bit
in the Neighbor Advertisements to non-zero, which is only needed
when the MN is a MR.

The modifications to the RA (section 6.2) has a unrelated  'R' bit
which has nothing to do with the 'R' bit in the BU.
The former is just a way to indicate that the prefix info option,
often in addition to containing a prefix, also contains a full
(global or site-local) address of the sending router.

  Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: 17 Aug 2001 11:24:48 +0200

> which has nothing to do with the 'R' bit in the BU. 

I was thinking that HA should respond to RS's with R bit set if the MN
is away and is a router.  That RA's R bit would come from R of binding
cache.  It's not specified, but I thought that should be specified.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 17 Aug 2001 09:40:43 +0200 (CEST)

> my ignorance in my first appreciation.

Yes but running routing protocols is not required by all routers.
And I agree that HA and AR are likely to be different - in some cases
they might be placed in very different parts of the network.

> Why isn't Mobile IPv6 spec requiring the HA to join all-routers mc

Good questions.

Perhaps it should for consistency.
Joining all-routers would definitely be required if the router was to

> Why isn't Mobile IPv6 spec requiring the HA to send router

I don't think this needs to be mandatory for routers in general.
For instance, for routers which are only attached to links with other routers
(and not hosts) there is no use in sending RAs.
Also, RFC 2461 was written to allow there be routers on the link
which do not send RAs but instead are only used by the hosts as a result
of another router sending redirects.

If a HA is only connected to one "physical" link (in addition to whatever 
tunnels it has to the served MNs) then its routing cabability
will not be very useful for other hosts attched to the physical link.
Thus it might not be that useful for it to send RAs on that link.

But when the HA is attached to multiple physical links it can very
well serve as a "normal" router between those links in addition to
its home agent functionality. Thus in such a case it makes more sense
for it to send RAs.

Correct.

But the router can still "hide" i.e. not be used as a default router
by setting the router lifetime to zero. Thus the above logic for
when it makes sense to be a default router or not still applies.

  Erik

---

From: Mattias Pettersson <[email-masked]>
Date: Fri, 17 Aug 2001 13:13:49 +0200

> my ignorance in my first appreciation.

The HA can very well be separated from the AR (or the gateway router or
border router whatever it means). Each link can have any number of
routers. One or more of them connects it to the internet. The HA doesn't
have to be one of them. A node can have one interface and still be a
router.

An important aspect of routers is that they can't get their routes by ND
autoconfiguration, such as hosts do. They need manual configuration or
routing protocols for that. And as concluded earlier, the HA is a
router.

Sorry, just want to make things clear.

/Mattias