Subject: RE: [mobile-ip] Routing headers: design team recommendation (CONC LUSION)

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 28 Jan 2002 14:07:07 +0100

=> I agree with the analysis and recommendation, but 
would prefer to use a new RH type, than a DO. For 
the same reasons that Francis mentioned. RH type
or IP_NO_SRC, I'm neutral, whatever takes less time. 

Cheers,
Hesham

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Jan 2002 16:47:23 +0200 (EET)

> or IP_NO_SRC, I'm neutral, whatever takes less time. 

A note on new RH type: if we go this direction, I think the best semantic 
to specify is that it must be Home Address of the node.  Simple and 
elegant.

Another note: make sure that old RH (for traffic engineering)  and new RH
(CoA, HA mapping): that is, new RH must be after old RH in the header 
chain.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 29 Jan 2002 11:36:59 -0800

Hello Pekka,

> (CoA, HA mapping): that is, new RH must be after old RH in the header

This would break applications where the mobile node is only one
intermediate point in the source routing list.

In fact, whatever solution you would pick, you have to make
it work exactly like source routing in all circumstances.

But I don't claim that fact should NECESSARILY indicate staying
with the existing routing header.  We can obviously have redundant
features.

Regards,
Charlie P.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Jan 2002 22:41:04 +0200 (EET)

> intermediate point in the source routing list.

You mean applications where MN forwards the packet out of the node, or 
something else?
 
> with the existing routing header.  We can obviously have redundant

In case I wasn't being explicit enough, let me clarify.

When sending at the source:

src=some_node
dst=intermediate_te_router
classic routing header=MN CoA, segments left=1
new routing header=MN Home Address, segments left=1
[payload]

(Note: we would need to define that not both are processed on the same 
node)

after being processed at intermediate_te_router, the packet would look 
like:

src=some_node
dst=MN CoA
classic routing header=intermediate_te_router, segments left=0
new routing header=MN Home Address, segments left=1
[payload]

when MN receives the packet, it skips over the classic routing header 
(because segments left == 0), and processes the second one normally.

Did I misunderstand what you meant?

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 29 Jan 2002 13:32:53 -0800

> You mean applications where MN forwards the packet out of the node, or

I meant the former -- but anyway, where the mobile node is supposed to
forward the packet to another subsequent routing point.  Nevertheless,
the point remains the same if the mobile node is itself the last of
multiple other routing points in a list, and the care-of address needs
to be injected into the list.

> new routing header=MN Home Address, segments left=1

Again, I reckon this would work.

> (Note: we would need to define that not both are processed on the same

This is equally necessary or unnecessary as making the same restriction
with "classic" routing header.

> new routing header=MN Home Address, segments left=1

Right.

> (because segments left == 0), and processes the second one normally.

Here, "normally" means according to exactly the same semantics
as routing header type 0?

> Did I misunderstand what you meant?

I can't tell about that, but it seems to me that the existing routing
header can do everything you want, already.  But that shouldn't be
taken to mean that I am opposed to having a new routing header.  Indeed,
if that's the magic wand that will mysteriously make the aforementioned
firewall vendors suddenly feel better, then it must be pretty good, and
so it's just fine with me.

Regards,
Charlie P.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 29 Jan 2002 23:39:04 +0200 (EET)

> with "classic" routing header.

True.. I think it's currently unspecified (but unused)..

> as routing header type 0?

No (IMO) -- there would be little point in defining new type if it was 
solely like this.  Additional requirements could be placed, and should be 
placed. (below)
 
> so it's just fine with me.

The significant difference here would be that we could define that with
routing header type=2, the final destination MUST be Home Address or else
the packet is discarded (or dealt with somehow).  Additional requirements
could also be placed, those that could not be added for type=0 (e.g.  
segments left must be 1).  This makes the behaviour much more controlled,
and easier for the administrators to handle.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jan 2002 22:57:40 +0100 (CET)

Charlie,

> intermediate point in the source routing list.

Do you have examples of such applications or such use of source routing?

> it work exactly like source routing in all circumstances.

That statement must be based on some unstated assumptions about the
applications you refer to above.

   Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 29 Jan 2002 13:50:09 -0800

Hello Pekka,

> and easier for the administrators to handle.

But then we have to make another Routing Header which does exactly
the same thing, but without this restriction, when the mobile node
is itself an intermediate node, like a mobile router.

Furthermore, I don't see why a firewall vendor would trust a device
to do the right thing just because it's another routing header type.
Already, IPv6 nodes are "supposed" to do the right thing with routing
headers, and not blindly forward them.  If we make new laws, they
can be equally well mistrusted by firewall vendors.  If we enforce
the existing laws, they can be equally well trusted by firewall
vendors.  I think you're trying to compensate for bugs, and the
bug space is so huge that we would never get done, and never have
a consistent set of design guidelines.

And yet I am in favor of any not totally broken solution that will
get us done, even if it is only because of having been endowed with
that certain magic that makes firewall vendors happy.  Not that
I would be able to make predictions about how to do that, so I will
have to trust the convictions of others.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jan 2002 23:08:08 +0100 (CET)

Charlie,

> to be injected into the list.

I'm having a hard time understanding a specific use of this type of
routing header.

One use of routing header that has been discussed is for some level of
policy control.
For example A is sending packets to B and A has three ISPs to choose between.
If each ISP has an anycast address for their border routers then A can
source route via that anycast address to reach B.

Combining this with mobile-ip route optimization might make sense
when B is a MN moving out on the Internet. But B would not forward
the packets onward.
But when the MN comes to visit A's site the optimized routing isn't very
optimal any more - the routing header makes the packets leave A's site since
they are source routed through one of A's ISPs.

Should A be a MN in the above case things make even less sense - once A
has travelled to a different part of the Internet it doesn't make sense
to source route packets back through one of A's ISPs.

So it seems like in general the combination of the more explicit 
routing possible using routing headers with MIP route optization is
a bit at odds.
And in any case it doesn't require a MN to be in the middle of a source route.

  Erik

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 29 Jan 2002 15:33:20 -0800

Hello Erik,

> I'm having a hard time understanding a specific use of this type of

I guess you mean "any specific use".  However, I didn't think we were
supposed to be working on particular specific uses.  I pretty much
understand what function the routing header is supposed to perform,
and I think that it is valid (or even highly recommended) to ensure that
those functions remain workable even when the intermediate routing
points are themselves mobile.

> One use of routing header that has been discussed is for some level of

If we define policy control sufficiently generally, I think that all
uses would be for some level of policy control.

> source route via that anycast address to reach B.

True, and I expect you are NOT meaning to imply that only anycast
addresses should be present in a Routing Header.

> they are source routed through one of A's ISPs.

Identifying the correct algorithms for route optimization in the presence
of multi-hop Routing Headers inserted for _other_ policy reasons is so
far beyond the current state of discussion, that I can't imagine it's the
right arena for making progress with the current discussion.

> to source route packets back through one of A's ISPs.

It could make sense for a lot of reasons, and nobody can know all of them.
Maybe there is some bizarre packet monitoring function that depends on
some special feature we don't know about.  But I didn't think the task was
to outline all possible uses of routing headers!  That would take a long time.
I thought our task was to solve whatever problems had been identified
for use of the existing routing header.  Neither making another routing header
that does exactly the same thing, nor aborting future use of the existing
routing header, seems to me to be good engineering practice.  Nevertheless,
I'm totally happy to take whatever it is that pleases the mystical firewall
gods.  Or whatever other powers that be relevant in the pantheon I don't
understand.

> And in any case it doesn't require a MN to be in the middle of a source route.

Nobody requires this.  I only suggested that we not disable it.  And I
also suggest that mobile nodes are likely to turn up in the most unusual
places, well within the lifetime of Mobile IPv6, unless we intentionally
make the protocol short-sighted.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jan 2002 00:58:08 +0100 (CET)

Charlie,

You are arguing that there needs to be the capability to construct something
that has 
 - zero or more source routing hops,
 - followed by a CoA hop
 - followed by one or more source routing hops
 - and then reaching the HoA

My question is merely trying to understand what problem this is solving.
All I need is one credible example of real usage.

If you have an actual example with source routing through routers that are
themselves mobile that would satisfy my curiosity.

> addresses should be present in a Routing Header.

"One use .." and "For example ..." presumably make this clear already.

> right arena for making progress with the current discussion.

Correct. But since you didn't provide concrete examples I thought I'd try
to be imaginative. But use of my imagination didn't result in coming up
with a useful case where source routing and mobile must be combined
in the way you claim is a requirement.

> it work exactly like source routing in all circumstances.

That sure reads like you are stating a requirement.

  Erik

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 29 Jan 2002 16:19:44 -0800

Hello Erik,

>  - and then reaching the HoA

No, I didn't say that.  I would suggest the following:
 - zero or more source routing hops,
 - followed by a CoA hop
 - immediately followed by the HoA
 - followed by zero or more source routing hops

I'm happy to stipulate that Mobile IPv6 policy requires that
the home address MUST immediately follow the care-of address.
In fact, I think such a statement is already in there.

> All I need is one credible example of real usage.

Do you still require it for my actual formulation?  Anyway, I'm not
trying to make requirements.  I've already stated multiple times
that I'm happy to do whatever y'all say for retyping the routing
header.  I think the reasons do not bear up under serious discussion,
but that doesn't mean I would oppose the action anyway.

> "One use .." and "For example ..." presumably make this clear already.

Perhaps that formed the underlying basis of my expectation.  My reason
for overtly stating it was just to make sure that I understood what I
thought was your obvious intention.

> That sure reads like you are stating a requirement.

O.K.  It's not a requirement except if we wanted to enable what
I thought was the well-understood meaning of source routing.

Or perhaps to be more explicit:

a - b - c - ... - i - k - ... - x - y - z

Suppose that is the source route, and k is mobile.  Suppose k
moves to care-of address 'j'.  Then the new source route should be:

a - b - c - ... - i - j - k - ... - x - y - z

That seems so obvious, that I didn't think there was a need for
some specific application.  The further points that I also thought
were obvious are:

1. The first source route was built using signaling that we don't
    know about, but that we can surmise provided sufficient assurance
    that the routing operations were authorized, and

2. The recipient of the revised source route, since it owns IP address 'j',
    will assuredly follow the policy by which it authorized the other
    endpoint to amend the source route -- namely, that 'j' MUST be
    followed by 'k' (here, the node's home address).  That's the Mobile IPv6
    policy for source routing, and it's a mobile node that will enforce it.

But none of this discussion should be interpreted as opposition to
a new routing header type.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jan 2002 11:19:10 +0100 (CET)

> I thought was the well-understood meaning of source routing.

Yes, but we are talking about the meaning of source routing combined
with mobile-ip, and I don't think there is a well-understood idea
of what that could be used for hence it isn't clear whether it is needed
or not.
 
> some specific application. 

Let me try to restate the above.
1. Assume that the delivery of packets on the CoA to HoA "hop" should work
   like source routing.
2. Show that the delivery of packets on this "hop" must work like source
   routing.
I agree it's obvious because it is a circular argument.

The above example shows a node forwarding packets with an explicit route
(what many would consider a router) where the explicit route is constructed
using a routing header. Then the node in the middle of the explicit route
moves. My question is what would this be used for?
Even if explicit routing is used, the above doesn't make any sense to me - why
would a router in an explicit route move (using mobile-ip) and expect the 
explicit route to follow its movement?

It sounds completely esoteric doing something like that.
So a non-circular argument is needed.

> The further points that I also thought
> were obvious are:

Yes, but this follows the assumption that the CoA to HoA "hop" is
constructed using source routing and why that's needed/useful/good
is the piece I'm trying to understand.

> a new routing header type.

Understood.

What is your opinion of the other different ways of "encoding" things ?
(new destination option, IPV6_NO_SRC tunneling, new extension header, ...)

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Wed, 30 Jan 2002 09:23:03 +0200 (EET)

>  - followed by zero or more source routing hops

In the case that finally there are more than zero source routing hops,
"MN" is a router, and for routers, different policies might apply.

Note that in this kind of scenario, the sender which is creating the 
packet with extra hops after HoA must know the type of destination 
topology .. and could very well use the "normal" routing header too.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Jan 2002 16:38:17 +0100

=> there is no reason to do another thing (:-)!

=> multiple RHs have a very simple semantic: they are processed in order,
i.e. a RH can be processed only when all previous RHs have zero left
segments (this is why the "segments left" field is common to all types).

Regards

[email-masked]

PS; we are smashing in open doors (:-).

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 30 Jan 2002 08:25:47 -0800

Hello Erik,

> of what that could be used for hence it isn't clear whether it is needed

There is a well-understood meaning of what it means to provide
a "next" intermediate routing address, and that's what source
routing can do.  It's also clear that this can be used perfectly
in the case of Mobile IP.  On the other hand, we obviously do not
know ALL uses of source routing.  I claim that does not matter
here.  And, of course, it is not NEEDED in any strict sense of the
word.  Neither is IPv6.  The human race existed for a long time
before RFC 1881.  It's a tool.

And that's the strange thing about this discussion.  I think
almost everyone can see that source routing is a tool which can
be used to do this job.  You point out that it can be used to do
other jobs.  You question whether the uses are compatible.  I claim
they are, and have tried to demonstrate it.  It seems to be
devolving to navel gazing, and the esoterics of tool usage.

Any of a dozen other tools can be shaped to work also.  So I do
not object!  I just think it's a waste of time and effort, but
if we are already doomed to spend the time and effort, then go for it.

> I agree it's obvious because it is a circular argument.

Ah, but I didn't make this argument.  I made the following _different_
argument:

1. The delivery of packets on the CoA to HoA "hop" --> CAN! <-- work
   like source routing.
2. The delivery of packets on this "hop" must not interfere with the
   other uses of source routing.

I do NOT claim that only source routing can be used for this (see above).

> moves. My question is what would this be used for?

Eventually (and -- the point -- within the lifetime of IPv6), we will
get used to nodes moving.  Even routers.

We can make Mobile IPv6 work (most likely!) in those future scenarios.
I don't claim to have perfect vision here!  But at least it is very, very
cheap to make the effort.  We just have to do the "obvious" thing --
which, I think you agreed, was already obvious mechanically.  Policy,
on the other hand, is never obvious.  That's why I can't go there with
you.  I can only offer you my conviction (perhaps meaningless to you)
that it will work as designed.

But other designs can also be made to work.  I agree!

> explicit route to follow its movement?

An explicit route, let's say, is a route through an explicit node.
That node could be made explicit for any of a thousand reasons.
I don't have time to design more than one of them to perfection.
It could be monitoring.  It could be a security gateway.  It could
be transformation into pi-mesons in a way not amenable to aggregation
into a routing table.  I do not know.  I didn't spend a lot of time
figuring out why, so this is a necessarily "silly" set of reasons.

I have only concentrated on the single case of Mobile IPv6.
If you don't like this tool, or if it makes you uncomfortable,
then you will make another tool.  That's the breaks.  I can
only speculate (but still without much time to do so) about why.

> So a non-circular argument is needed.

The tool is not circular, nor is my reasoning.  However, a lot
of round straw men can be set up as targets.
 
> is the piece I'm trying to understand.

It's only useful/good because it works perfectly.  It is not needed!
Other ways can be made to work perfectly, at the evident cost of time
and effort.

> (new destination option, IPV6_NO_SRC tunneling, new extension header, ...)

By now you can predict!  They will all work, no problem, and it will
be a lot of fun and engineering effort to get the bugs out.  Then we
can have more interoperability testing.  Maybe someone else will find
a reason why the new tool has a rough edge.  That will also provide
many hours of discussion and further elucidation on the nature of the
tool building and utilization.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jan 2002 18:17:35 +0100 (CET)

> before RFC 1881.  It's a tool.

We are obviously failing to communicate.

You seem to be arguing that because there is a desire to do
IPv6 source routing and there is a need to carry both a CoA and a HoA
that it is natural/desirable/whatever for them to use the same mechanism.

This seems to be like saying because we need to put in screws as well as nails
we need an underlying mechanism that is a combination of a hammer
and a screw driver.

I'm trying to make the point that let's first see if there is a case where
it makes sense either
 - hitting the screw with the hammer while at the same time turning it

Hence my question for an indication that combining source routing and HoA/CoA
in the packet the way to describe would solve some problem or at least
be useful.

> if we are already doomed to spend the time and effort, then go for it.

The reason I haven't stopped arguing is that your emails are basically saying
 - source routing makes the most sense 
 - I don't understand why Erik doesn't see that
 - but you'll (grudgingly?) accept another solution

I think we should have a technical discussion (and perhaps agree that we
disagree) and get away from the 3rd bullet above.

> it work exactly like source routing in all circumstances.

That is the part I disagree with - I don't see any need for
such a requirement or desire.

   Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 30 Jan 2002 09:37:36 -0800

Hello again Erik,

> We are obviously failing to communicate.

That's a problem that we can fix.

> that it is natural/desirable/whatever for them to use the same mechanism.

No, I am not arguing that.

I am arguing that we have source routing, and that it works for the
job that is needed.  And that we've already done the design.  And that
it works.  And it's not because of a "desire" to do IPv6 source routing.
Just because it works.

I'll leave natural/desirable/whatever for someone else.

> we need an underlying mechanism that is a combination of a hammer

I hope that by now you will agree that I am not saying any such thing.

>  - hitting the screw with the hammer while at the same time turning it

Do you mean to suggest that we need to do the compatibility analysis?

> in the packet the way to describe would solve some problem or at least

That's an additional design question.  I personally do not see the need,
but you do.  I don't think it's useful in the case of Mobile IPv6, because
the mobile node "obviously" knows what to do already.

>  - but you'll (grudgingly?) accept another solution

I'm not trying to be "grudging"(*).  And I don't say that source routing
makes the "most" sense!  I only say that:
- it DOES make sense
- it DOES work
- it HAS been tested.

I don't even ask why you don't understand my point of view.

> disagree) and get away from the 3rd bullet above.

I'm already away from it.  But what do you want me to do?
NOT agree to an alternative solution?  I think it would be
better for me to agree to accept whatever workable solution
you devise, even if I may bemoan the additional time and effort
required to devise it.  Or maybe you just meant that I should
stop saying that I would be agreeable?

> > it work exactly like source routing in all circumstances.

Well, as far as I can see, it does already work like source routing.
And, either you have to cause the IPv6 source routing header to suddenly
become illegal, or you have to make this whatever new thing work with
it.  And I claim that in doing so, you will have to make it work
exactly like source routing works, but only with one additional policy
implication that's already obvious at the receiving end.

> such a requirement or desire.

Which part of my last paragraph do you disagree with?

Regards,
Charlie P.

(*) Why do I need to make such disclaimers?  It doesn't seem very fair.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 31 Jan 2002 10:09:13 +0100 (CET)

> it works.  And it's not because of a "desire" to do IPv6 source routing.

Ah - got it. (You've made other points that added confusion to this.)

I guess what would be helpful is to create a list with pros and cons
for the different ways do separate MIPv6 from RH type 0
(and the above is definitely one of the pros for RH type 1).

> I hope that by now you will agree that I am not saying any such thing.

At least not so far in this most recent email :-)
 
> Do you mean to suggest that we need to do the compatibility analysis?

This was in response to what I interpreted as you stating as desirable
to be able to construct RH paths that include a CoA/HoA pair in the
middle to create some combination of source routing and MIPv6.
Since you are no longer claiming that this is desirable there is no
need to do any further analysis of the need for such a combination.

> I don't even ask why you don't understand my point of view.

I think it's because of the other statements you've made in this email
thread talking about the requirement and later desire that things
work exactly like source routing.
That didn't help to make your point clear.

> Well, as far as I can see, it does already work like source routing.

Here we go again ... :-)

That could either be used as an artifact/side-effect of currently using 
RH as the mechansim.
Or it could be viewed a fundamental part of MIPv6 architecture
and/or a requirement for on whatever mechanism is used.

I personally think it is just a side effect.
I don't know what you think - side-effect or architecture?

> implication that's already obvious at the receiving end.

Why does it need to work "exactly like source routing"?

The required thing needed for MIPv6 is that packets sent to a MN
contain what is in essence two destination addresses: one
that identifies the current toplogical location (the CoA) and one
that identifies a stable location used to identify higher layer
things like TCP conenctions (the HoA).

We further have an existance proof that it doesn't need to have all the
behavior of RH because the packets sent through the HA are tunneled
(IP-in-IP encapsulation to the MN) which does not have the semantics
and composability implicit in "work exactly like source routing".

> Which part of my last paragraph do you disagree with?

"work exactly like source routing"

> (*) Why do I need to make such disclaimers?  It doesn't seem very fair.

Perhaps I was reading too much between your lines but it seemed like
your emails had an undertone like that in "do whatever you please but it
doesn't make sense to me".
My apologies for jumping to that conclusion.

  Erik

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 1 Feb 2002 02:00:59 +0200

> it work exactly like source routing in all circumstances.

Hmm.... I think not. The MIPv6 usage requires a specific forwarding
to the nodes internal processing, when the address matches the
home address of the node. RH in general offers a wider functionality,
including forwarding the stuff somewhere else.

So, in a sense you are right by saying that it's the same functionality.
But Erik is also right in saying that it is not, because it is a subset.
Since we have issues with the security of the non-MIPv6 part of
the functionality, we fear RH might get dropped by firewalls. The
MIPv6-specific mechanism, however, will not have the same dangers
since we cut away the extra part, and hence it is not likely to be dropped.

Jari