Subject: [nemo] about draft-ietf-nemo-requirements-00.txt

From: marcelo bagnulo <[email-masked]>
Date: 09 Mar 2003 12:24:59 +0100

Hi,

I have some comments/questions about draft-ietf-nemo-requirements-00.txt

1- About security features required to the basic solution and the
extended solution:
In section 4, General Purpose Guidelines... it is stated that "the
following issues have to be addressed"

Question: shouldn't a MUST be included in the above statement? (i.e.
something like "the following security features MUST be provided")

The issues included are: authentication, authorization, confidentiality,
and location privacy.

Later, requirement 12 of section 5. One-liner req... states that the
basic solution MUST provide: authentication, authorization, anti-replay
and that encryption SHOULD be provided.

Question: I find that the both sets of requirements do not completely
match. I mean, how is the location privacy requirement imposed to the
basic solution? is it included in the encryption requirement? if this is
so, why this is a SHOULD? 
The other difference is about anti-replay protection requirement, that
it is not included in the general requirements but it is required for
the basic solution, shouldn't this be required for all the solutions?

2- About multi-homing support

In section 5. One-liner req... it is stated that the solution MUST
function for multi-homed networks, more precisely: "R13.3: The solution
must support MR with multiple global addresses on an egress interface." 
However, draft-ernst-nemo-terminology only includes the following cases:
         - a MR has multiple egress interfaces on the same link, or
         - a MR has multiple egress interfaces on distinct link, or
         - there are more than one MR in the mobile network

IMHO, the case where multiple global addresses are configured to a
mobile router  egress interface should not be included. In this case,
the MR has only one attachment point to the Internet, so the mobile
network is not multi-homed. However, if the multiple addresses
configured to the egress interface of the MR have different global
prefixes  (i.e. PA addresses that have been assigned by different
ISPs),this means that the home network is multi-homed, not that the
mobile network is multi-homed. In this case, it is my opinion that the
communication between the HA and the MRR can be established using any of
the global addresses available and using one or the other does not
present benefits for the communication between the HA and the MR. I
mean, if the communication fails using one address it will fail using
the other one, since they are configured to the same interface. The
difference between using one address or the other is related to which
ISP will be used when exiting the home network. However, this issue is
related to the multi-homing solution configured in the home network, and
not to the multi-homing solution of the mobile network. For these
reasons, IMO, the case of multiple addresses configured to a single
interface should not be considered, since it should be solved by the
multi-homing solution of the home network.

3- Multi-homing capabilities.

I haven't found any requirements about the capabilities of the mobile
network multi-homing solution. It is stated that the solution must
function for multi-homed mobile networks, but it is not specified what
benefits are expected. IMO a fault tolerance requirement should be
included. I mean, suppose that a mobile network has two MRs, and
suddenly one MR (MR1) becomes unavailable (MR1 crashes or the
communication between MR1 and the HA is unavailable). I would say that
all the connections that were being coursed through MR1 have to be
preserved during the outage  meaning that they have to be re-routed
through the alternative MR, providing fault-tolerance capabilities. The
same case can be applied to the case of a MR with multiple interfaces
and one of them fails. Note that fault tolerance capabilities required
to the multi-homing solution of the mobile network are limited to the
communication between the MRs and the HA, and are not related to the
multi-homing capabilities of the solution of the home network.  
   
4- Other comments
- IMO, at least some basic RFCs could be included in the Backward
compatibility bullet in section 4.
- I guess that the scalability bullet of section 4 attempts to highlight
that scalability is important, but perhaps it is bit unspecific for a
MUST requirements , i mean, What is a large number of mobile networks?

5- Editorial

Numbering of one-liner requirements from number 12 till the end.

Regards, marcelo
-- 
marcelo bagnulo <[email-masked]>
uc3m

---

From: Alexandru Petrescu<[email-masked]>
Date: Mon, 10 Mar 2003 00:37:22 +0100

Hola Marcelo,

marcelo bagnulo wrote:
> Later, requirement 12 of section 5. One-liner req... states that 
> the basic solution MUST provide: authentication, authorization, 
> anti-replay and that encryption SHOULD be provided.
> 
> Question: I find that the both sets of requirements do not 
> completely match.

I agree it's incoherent from this security point of view.  Maybe we
can make it more coherent.

> ... and location privacy.

"Location privacy" hasn't been touched until now on the NEMO list, but
now that you do, please allow me to reply.

First, I think that Thierry has a good explanation for that
requirement, we discussed a bit about that and I can't remember the
conclusion.

Off-topic out-of-scope digression from here on:

As it prefigures now, "Location privacy" is a feature that can be
provided by Mobile IPv6 itself and not by a NEMO protocol.  To the
extent that Mobile IPv6 does location privacy, then NEMO will
implicitely use that Mobile IPv6 location privacy, but not develop a
new scheme for location privacy here.  For example, if Mobile IPv6
provides a means to hide (more or less) the MR CoA to CN, such that CN
has difficulty in actually localizing MR, then that is enough for
NEMO, I believe.

If there's a "location privacy" problem very specific NEMO to be
solved in the NEMO context, it is probably to hide the location
knowledge inside a nested aggregation of mobile networks.  I.e.
consider three MRs nesting one under the other.  The top-level MR must
not have have access to knowledge indicating in which way are nested
the two MRs below it.  It could be that problem, as well as it couldn't.

In all cases, "location privacy" is so very much loosely defined (to
my knowledge and as far as I know) that it really deserves more work
before knowing whether we can require it or not.

Also, care must be taken with "location privacy" from too many
perspectives.  One is this: if the CN doesn't know the CoA of MR, how
can it talk to MR at all.  A CN that doesn't know the location of a
fixed node is what happens with NAT mechanisms: host browses cnn.com,
but cnn.com doesn't know host's address because host is behind NAT.
And at the same time, CN can not contact host directly.  Which it
probably doesn't need. But when CN is a host that wants to "call" the
other host, then it's exactly "location privacy" that you do _not_
want.  I can't just tell you "call me later" w/o giving you my phone
number.  And once I give you that, you have a lot of information of
where I am.

An alternative (in the existing art): a CN must know a little bit of
MR's location information, prove itself to MR that it's someone who
behaves (have certificate) and then CN can know more.  A two-step like
this can probably work.  However, there's a chicken-and-egg problem
here (to borrow from SEND terminology).  How can CN know even the
"approximate" location of MR without MR first informing it about that
approximate position?  The only possible answer to this is that CN
first writes to HA, which replies to CN with the approximate address,
that is the address of an entity like an anchor point.  So now we have
a HA and and an entity between CN and MR that do so much more than
simply forwarding packets: they encapsulate, do rounds of messages of
security checks and sometimes even literally translate addresses
(substitute address x for y).  Which can be acceptable up to a point.
  Suppose CN is an NTP server and host is an NTP client: updating
host's clock is a highly engineered message exchange, which allows a
high precision of synchronicity over today's Internet.  With such a
"location privacy" scheme I described above that involves so many
additional exchanges, an NTP client will have to choose between either
keeping its location private or actually synchronizing its clock.

A last aspect is this: Mobile IP has a "NAT traversal" action point in
its agenda.  That will eventually give a host the opportunity to be
behind a NAT and still be reachable.  Then "location privacy" will
indicate that is not good because the caller can know where a callee
is.  So we can develop a new NAT2 over NAT traversal such that we can
later block again the traversal of NAT, which will not be good enough,
and later on make a NAT2-traversal.

It's like firewalls: firewall, then splash a p2p ssh tunnel through
the firewalls, then do p2p routing algorithms, then block those
annoying p2p connections, then traverse those blockings and so
on...one wonders what's left of that IP simplicity, I'm lost sometimes :-)

And "location privacy" here is entirely different from the privacy
concerns of users with browsers that browse sites (forbidden by a
higher authority) and don't want to let that higher authority, neither
the web sites, to really be able to localize them.  Some
privacy-concerned persons where telnetting through several
intermediate servers before reaching the target, hoping that nobody
can find where they came from (which in fact depends on how decided is
an admin to corelate logs by time).  New processes actually automate
this "circling around before reaching target" with random things, and
in the process introduce new entities between end user and server.

"Location privacy" in mobility context is different than the above,
but it has the same level of "elusiveness"...

-- 
Message Classification: GBU

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 10 Mar 2003 16:00:26 +0900 (JST)

Hi Marcelo,

Thank you for your comments. Reply below.

> and that encryption SHOULD be provided.

Probably I didn't explain it enough, but section 4 lists a number of
higher level requirements, not the actual requirements. That's why I
entitled the section "guidelines" and not requirements. I mean,
section 4 presents our "wishes". Location privacy is one of them. So,
in section 4 I deliberately removed words "MUST" or "SHOULD" to keep
it as open as possible. 

In section 5 are listed actual requirements which are derived from the
conclusion of the discussions of the point listed under section 4.

> so, why this is a SHOULD? 

Yes, and the reason why is "this is tricky". Since the basic solution
is to set up a tunnel and no routing optimization, location privacy to
the CN is enforced from a Mobility point of view: the MR's CoA will
never be present in packets sent to the CN. But, from a general point
of view, the permanent address still tells that the MNN is in the home
network, which does not strickly speaking provide the MNN with full
privacy. Does it ?

e.g CN knows that my prefix p_car/60 belongs to network "home/48" but
it doesn't that p_car/60 is now in network road/48.

If you can draft us some words that would allow to explain this
clearly, in a sentence, that would be welcome.

> the basic solution, shouldn't this be required for all the solutions?

Because anti-replay is an actual means to guarantee an acceptable
level of security.

I would not focus too much attention on section 4, but rather on
section 5. Is there anything else we need to include in section 5 ?

> multi-homing solution of the home network.

Interesting observation. Probably I wrote this too quickly. Does
anyone disagree with what Marcelo is saying right here ?

> multi-homing capabilities of the solution of the home network.  

I'm not sure that the draft should mention the purpose of
multihoming. If it did, it could only serve as an example; it's hard
to envision today what all the benefit of multihoming could be. So, I
don't think we should mention anything about fault tolerance (but I
agree it's one of the benefit).

Comments from other ?
    
> compatibility bullet in section 4.

We didn't do this on purpose. What RFCs should be listed ? We cannot
list all. If we list some, it might be assumed that a non-listed one
is not to be backward compatible. 

But, if you consider it's important, we should extablish an exhaustive
list of RFCs. 

Comments ?

> MUST requirements , i mean, What is a large number of mobile networks?

What would a number bring here ? The debate "large" vs "thousands"
already occured. The purpose of this bullet is awareness that
signalling should be minimised as much as possible. That's the reason
why it is listed under section 4.

> Numbering of one-liner requirements from number 12 till the end.

Thanks, someone already pointed this out. Sorry about that.

Thanks for your interesting comments again, Marcelo. I hope I will be
able to address your concerns clearly enough in the next revision of
the draft.

Thierry

---

From: Takeshi TANAKA <[email-masked]>
Date: Mon, 10 Mar 2003 19:10:31 +0900

Hi Therry and Marcelo,

On Mon, 10 Mar 2003 16:00:26 +0900 (JST) 
Thierry Ernst <[email-masked]> wrote :

...
> anyone disagree with what Marcelo is saying right here ?
I understand. That is the case where home link is multihomed and not
specific to NEMO, isn't that?

> > and one of them fails. 

> > Note that fault tolerance capabilities required
I think some NEMO specific capability are required for multihoming NEMO
to get fault tolerance from multihoming.  For example, the mechanism he
mentioned is not included in the current (experimental) multi-homing
difinition;
> through the alternative MR,
A router on a multi-homed link does not preserve connection that were
being coursed through it if egress link of the router is disconnected.

So I think fault tolerance should be described in the draft somehow as
one of the benefits if the basic solution will provide a mechanism to
get the benefit, but other people may think different.

Regards,
Takeshi

---

From: Alexandru Petrescu<[email-masked]>
Date: Mon, 10 Mar 2003 13:45:49 +0100

Salut Thierry,

Thierry Ernst wrote:
> I mean, section 4 presents our "wishes". Location privacy is one of
>  them.

I think it is good to say that location privacy is one wish, but I
also think that we should detail more what kind of location privacy we
want.  And also see whether Mobile IPv6 will probably provide an
inherent location privacy and so no need to develop new location
privacy in NEMO.

> Since the basic solution is to set up a tunnel and no routing 
> optimization, location privacy to the CN is enforced from a 
> Mobility point of view: the MR's CoA will never be present in 
> packets sent to the CN.

Yes, exactly.

> But, from a general point of view, the permanent address still 
> tells that the MNN is in the home network, which does not strickly
>  speaking provide the MNN with full privacy. Does it ?
> 
> e.g CN knows that my prefix p_car/60 belongs to network "home/48" 
> but it doesn't that p_car/60 is now in network road/48.

Yes, exactly.  So do you think we should worry about CN knowing that
p_car/60 belongs to network home/48?

> clearly, in a sentence, that would be welcome.

I think that text should clearly answer this:
-is Mobile IPv6 going to provide location privacy to MR?  If yes, how
  will NEMO use it?
-what entity tries to hide its location, is it MR?  Is it LFN?
-what is the "location" information that that entity tries to hide?
  Is it an address?  Is it a prefix?  Is it a corelation HoA-CoA?
-what is the entity that must not get knowledge of that location
  information?  Is it CN?  Is it HA?  Is it an attacker listening?

For example, I've seen the following description: attackers that might
intercept packets containing both HoA and CoA, so attacker can know
that that HoA is at that CoA.  In this specific case, the entity
trying to hide its location is MH, the information to hide is both HoA
and CoA and the attacker is someone intercepting packets (not
necessarily CN).

What you seem to describe above is: entity hiding its location is MR,
location info to be protected is the corelation (MR's prefix - MR's
home  prefix) and the attacker is CN.

---

From: marcelo bagnulo <[email-masked]>
Date: 10 Mar 2003 16:10:28 +0100

Hi Alexander, Thierry

Really interesting comments, and also unexpected.

When i read the draft, my interpretation of location privacy was that
the MR wanted to hide its location from an unauthorized listener in the
path between the HA and the MR. As you see it is really different from
what Thierry meant.

I think that the approach proposed by Alexander is very good.

Let's try to answer these questions. I think we should change the order,
though :-)

I guess that we could start by clarifying who is not supposed to know
the location of the MR. So, I would say that location privacy
capabilities prevent unauthorized parties to have knowledge about the
actual location of a mobile network. Since a mobile network is
permanently identified by the mobile network prefix and/or its MR Home
Address, and the mobile network current location is identified by the
CoA assigned to the MR, location privacy is obtained by avoiding the
disclosure of the information about the current binding between the
mobile prefix (and/or the MR HoA) and MR CoA. 

Potential unauthorized parties include the CNs of communications
maintained by the MNNs and any other party along the communication path
between the MNN and the CN that can eavesdrop the communication.

In the basic solution, CN is never aware of the current location of the
MNN since all traffic is coursed through the HA which is fixed in the
home network. The only location privacy concerns remaining refer to the
eavesdroping of packets exchanged by the HA and the MR. A mobile network
solution should provide the functions needed to conceal location
information contained in these packets. This requirement is included in
the requirement R13.4.

In the extended solution, MNNs are capable to interact directly with CNs
without including the HA in the communication, exposing its location to
the CN. However, the usage of route optimization should always be the
MNN choice. In this case, unknown CN always reach the MNN through the
HA, using the MNN permanent address. Once the communication is in place
and that the MNN is aware of the CN, the MNN may choose to make use of
the Route Optimization capabilities provided by the extended solution.
In this case, the MNN is benefiting from more optimal path but it is
also disclosing its location to the CN. 
Other location privacy concerns refer to the disclosure of location
information to eavesdroppers along the communication path. As long that
the communication flows through the HA, the basic scenario applies. In
the case that RO is being used, the conceal of location information
implies the usage of encryption between the MNN and the CN. I do not
know if we want to go there.  

I have tried to summarize the previous exchange, do you think this is
it?

Regards, marcelo

---

From: marcelo bagnulo <[email-masked]>
Date: 10 Mar 2003 16:30:58 +0100

Hi Takeshi,

> specific to NEMO, isn't that?

If a site has multiple provider and PA addressing is used, nodes within
the multi-homed site will obtain multiple addresses per interface in
order to be reachable through the multiple providers. So if the home
network of a mobile network is multi-homed it is possible that MNN will
have multiple addresses per interface associated to the multiple
providers. However this is not a NEMO specific issue, and in this case,
the mobile network is not multi-homed, but its home network is. So i
think this case should not be considered in the NEMO solution space.

> A router on a multi-homed link 

Sorry what do you mean by multi-homed link?

Regards, marcelo
> does not preserve connection that were

---

From: marcelo bagnulo <[email-masked]>
Date: 10 Mar 2003 16:47:24 +0100

Hello Thierry,

Thanks for your reply, some more comments below...

> in section 4 I deliberately removed words "MUST" or "SHOULD" to keep

So, MUST and SHOULDS of the section 4 will be removed?

I think that the set of guidelines it is OK and they have to be
considered when evaluating a solution, specially for the extended
solution. Probably changing to lower case must and shoulds it's a good
idea.

> Yes, and the reason why is "this is tricky". 

It is clear now, i follow this in the privacy location thread.
[...]

> agree it's one of the benefit).

If no specific benefit is obtained through multi-homing, what does it
means that the solution MUST function with multi-homed networks?

I guess that at least we are expecting that if multiple routers exist,
all can be used to course traffic, for instance. I would say that it is
also expected that if one router fails, new communications are
established using the alternative one which is available. We could also
discuss about established communications preservation.

I mean, some basic benefits could be included in the section 4 at least
as guidelines of what is expected from multi-homing solutions.

> But, if you consider it's important, we should extablish an exhaustive

I see your point.

BTW, FMIPv6 is still an ID, is it ok to include it in here? 

> signalling should be minimised as much as possible. 

Perhaps rephrasing it this way may be clearer, but if you already
discussed this, i do not want to reopen the discussion anyway.

Thanks, marcelo

> That's the reason

---

From: Alexandru Petrescu<[email-masked]>
Date: Mon, 10 Mar 2003 19:16:17 +0100

Hola Marcelo,

marcelo bagnulo wrote:
> Let's try to answer these questions. I think we should change the 
> order, though :-)

 From your description I understand that the location privacy is highly
relevant to the Extended mode, and very little relevant to the Basic mode.

> location privacy capabilities prevent unauthorized parties to have 
> knowledge about the actual location of a mobile network. [location 
> is a triplet: home prefix, CoA of MR and HoA of MR]
> 
> unauthorized parties include the CNs of communications maintained 
> by the MNNs and any other party along the communication path 

Ok, so the above is a generic description of the the "location
privacy" problem...

> In the basic solution, CN is never aware of the current location of
>  the MNN since all traffic is coursed through the HA which is fixed
>  in the home network. The only location privacy concerns remaining
>  refer to the eavesdroping of packets exchanged by the HA and the 
> MR. A mobile network solution should provide the functions needed 
> to conceal location information contained in these packets.

One second here.  Eavesdropping between MR and HA can be avoided by
Mobile IPv6 using an ESP header or something like that between MR and
HA.  That ESP header is for other reasons, but it implicitely achieves
location privacy as we defined it above.  Any attacker between MR and
HA will not be able to obtaine the entire location triplet, it will
only get the MR_CoA.

> This requirement is included in the requirement R13.4.

If my explanation above is relevant, then requirement R13.4 is not
needed, right?

> In the extended solution, MNNs are capable to interact directly 
> with CNs without including the HA in the communication, exposing 
> its location to the CN. However, the usage of route optimization 
> should always be the MNN choice. In this case, unknown CN always 
> reach the MNN through the HA, using the MNN permanent address. Once
>  the communication is in place and that the MNN is aware of the CN,
>  the MNN may choose to make use of the Route Optimization 
> capabilities provided by the extended solution. In this case, the 
> MNN is benefiting from more optimal path but it is also disclosing
>  its location to the CN. Other location privacy concerns refer to 
> the disclosure of location information to eavesdroppers along the 
> communication path. As long that the communication flows through 
> the HA, the basic scenario applies. In the case that RO is being 
> used, the conceal of location information implies the usage of 
> encryption between the MNN and the CN.

So, in the Extended solution, the entity trying to hide is MNN (is it
an LFN or a VMN?), the location info to hide is MNN's CoA, and
the entity that must not know that info is CN and any party in the
communication path.  This is still very vague; any party in the comm
path is any router; forbid this router to see the CoA and basic
communication stops.  So maybe the RO location privacy requirement can
be loosen.

Anyways, as you seem to imply, extended mode with RO should probably
further dissect the location privacy issue.

> I have tried to summarize the previous exchange, do you think this
>  is it?

You forgot the first question "is Mobile IPv6 going to provide
location privacy and NEMO use it?" needs a sort of answer, I
don't get it from your message.  There was discussion on the
mipcharter list recently.  My personal oppinion is that if Mobile IPv6
does location privacy then NEMO just uses it.  If Mobile IPv6 doesn't
do it, maybe it's not for NEMO to do it; just an oppinion.

Alexander :-)

---

From: Greg Daley <[email-masked]>
Date: Tue, 11 Mar 2003 10:48:18 +1100

BuonGiorno Alex,

Some comments below.

> relevant to the Extended mode, and very little relevant to the Basic mode.

Indeed, the principle issue in extended mode is route optimization.
For Basic solutions, even snooping traffic from the MNN's home
network will only reveal which NEMO the MN is present on.   Further
work would be required (snooping traffic from that NEMO's home network)
to try to determine the CoA of the NEMO.

We're not talking about casual snooping here.

>> knowledge about the actual location of a mobile network. [location is 
>> a triplet: home prefix, CoA of MR and HoA of MR]
>>
>> unauthorized parties include the CNs of communications maintained by 
>> the MNNs and any other party along the communication path between the 
>> MNN and the CN that can eavesdrop the communication.
> 
> 
>>  refer to the eavesdroping of packets exchanged by the HA and the MR. 
>> A mobile network solution should provide the functions needed to 
>> conceal location information contained in these packets.
> 
> 

I think that even if the MR and HA have an ESP tunnel there are still
ways to narrow down the set of locations that the NEMO could be at by
inspecting the outer destination address of the encrypted packets.
There may only be a few absent NEMOs handled by a home agent, therefore
only a few addresses to investigate.

Also, if the MNN advertises the NEMO which it is using with a BU to
a visited CoA on the NEMO, it is easy enough to identify the HA to
snoop.  This can be used recursively to determine the CoA of the
root-MR.

I'm not sure that this is so important anyway,  Since this sort
of analysis probably requires access to fixed routing infrastructure
to identify the NEMO's CoA and the MNN's location (except if the
MNN advertises it in a BU).

People who have access to the fixed routing infrastructure are
likely to get what they want in other ways.

MNNs which advertise their location with BU's don't need privacy.

The real issue with location privacy is when the MNN uses route
optimization to get an address in the NEMO's visited fixed network.
If it uses that address in a MIPv6 BU, then the location of that node
(and possibly other devices co-located with it on the NEMO) is
revealed to an untrusted CN or third party.

This is an extended requirement, as you say, but any MNN which is
concerned about location privacy can opt-out of route-optimization.
The two are largely incompatible when talking to untrusted hosts.
This means reverse tunnelling all packets to the MIPv6 HA, or
using RFC3041 addresses for short term route optimized
communications, which shouldn't reveal the host's permanent identity.

> If my explanation above is relevant, then requirement R13.4 is not

You're right that using ESP on the NEMO's HA helps prevent
identification of the NEMO's CoA, although when a router
only has a few NEMOs it's possible to narrow down the
location. (if the attacker can watch packets going out).

>> In the extended solution, MNNs are capable to interact directly with 
>> CNs without including the HA in the communication, exposing its 
>> location to the CN. However, the usage of route optimization should 
>> always be the MNN choice. In this case, unknown CN always reach the 
>> MNN through the HA, using the MNN permanent address. Once
>>  the MNN may choose to make use of the Route Optimization capabilities 
>> provided by the extended solution. In this case, the MNN is benefiting 
>> from more optimal path but it is also disclosing
>>  its location to the CN. Other location privacy concerns refer to the 
>> disclosure of location information to eavesdroppers along the 
>> communication path. As long that the communication flows through the 
>> HA, the basic scenario applies. In the case that RO is being used, the 
>> conceal of location information implies the usage of encryption 
>> between the MNN and the CN.
> 
> 
I'm pretty sure that in most cases, location privacy will
be usable by the NEMO MNN's in the same fashion that MIPv6
privacy will be used.

The CoA available from the NEMO for the MNN will be a CoA
similar to MIPv6 (possibly with different assumptions though).
The basic form of extended NEMO privacy will probably still be
to tunnel back via the MNN's HA.

Greg

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 11 Mar 2003 15:57:27 +0900 (JST)

Hi,

From: marcelo bagnulo <[email-masked]>
> path between the HA and the MR. As you see it is really different from

Probably because you saw the words "location privacy" in the context
of "basic support" only (although the words "location privacy" are not
explicitly stated in section 5) ?

> information contained in these packets. This requirement is included in

I agree with your summary.
 
> know if we want to go there.  

Provided you have an idea in mind how route optimization should be
performed. IMHO, it's a bit early to do that kind of assumption.

> I have tried to summarize the previous exchange, do you think this is

If we leave up the technical details of related to extended support,
yes. So, my question is "is there a need to change the text in the
draft" and if yes, what text would you propose ? 

Thierry

---

From: Takeshi TANAKA <[email-masked]>
Date: Tue, 11 Mar 2003 16:03:26 +0900

Hi Marcelo,

On Mon, 10 Mar 2003 16:30:58 +0100 

> think this case should not be considered in the NEMO solution space.
I agree.
The case where a mobile router has multiple mobile network prefixes 
from a single home link, is not NEMO specific.

I hope we could discuss whether scenarios described in
draft-ng-nemo-multihoming-issues are in NEMO solution space.

> Sorry what do you mean by multi-homed link?
The link where there are multiple default-router-capable routers and
they are advertising different prefixes.

       |       |
     Router  Router
prefix1|       |prefix2
-------+-------+-------   <---

# which term should I use for the link like above?

Regards,
Takeshi

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 11 Mar 2003 16:16:07 +0900 (JST)

Hi Marcelo,

> So, MUST and SHOULDS of the section 4 will be removed?

Basically, I wanted to remove such words from section 4. 
 
> solution. Probably changing to lower case must and shoulds it's a good

Will do.

> means that the solution MUST function with multi-homed networks?

I didn't say there isn't benefit, I just said I don't think the draft
should list the benefits. This is a requirement for some scenarios. 

> as guidelines of what is expected from multi-homing solutions.

But in this case we should also include benefits for all other
bullets. I think most are common sense and thus don't need
justification. The bullets in section 4 are justification for section
5, I don't think we should also justify the bullets in section 4.

> BTW, FMIPv6 is still an ID, is it ok to include it in here? 

Good point. My personal answer is that FMIPv6 should not be listed
explicitly.

The reason why FMIPv6 and other protocols like DHCP and ICMP are
listed in the draft is because a few people point for a need to ensure
NEMO support is compabible with them.

So, there is an issue here: shall we list no protocols at all, a few
examples, the few we have identified as necessary, or an exhaustive
list ?

> discussed this, i do not want to reopen the discussion anyway.

Any proposition ? To be honest, I don't know how to rephrase this to
make it clearer.  

Generally speaking, I think that, at this point, we need concrete
sentences if anyone is not really happy with the text. 

Thierry

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 11 Mar 2003 16:40:37 +0900 (JST)

Hi Alex,

From: Alexandru Petrescu <[email-masked]>
> If my explanation above is relevant, then requirement R13.4 is not

Why ? The fact that it might not be a problem to enforce by simply
using MIPv6 doesn't mean it shouldn't be listed as a requirement.

> do it, maybe it's not for NEMO to do it; just an oppinion.

Of course. See NEMO charter: "The WG will investigate reusing the
existing Mobile IPv6 mechanisms for the tunnel management, or extend
it if deemed necessary." Which doesn't prevent us for listing the
requirements. 

Thierry

---

From: Alexandru Petrescu<[email-masked]>
Date: Tue, 11 Mar 2003 11:37:58 +0100

Thierry Ernst wrote:
> existing Mobile IPv6 mechanisms for the tunnel management, or 
> extend it if deemed necessary." Which doesn't prevent us for 
> listing the requirements.

Ah yes, I see what you mean, which seems to be right.  There's a
difference, see below.

One of the premium requirements that is listed very early in the
draft, is "mobile network nodes (MNNs) to remain connected to the
Internet and continuously reachable at all times".  This is also a
requirement towards which NEMO will not work, but _use_ what Mobile
IPv6 provides as a tool.

There is however a very important difference between that requirement
and the location privacy requirement.  The "reachability" requirement
has a tool behind it that is the existing Mobile IPv6, draft21.
Location privacy has no such tool behind it.  Moreover, discussions up
to now evidence (in my interpretation) that the location privacy
problem itself is not very clear, at this moment.

That says, there will be some time before mipcharter (nsim, next steps
in IP mobility BoF) decides to work on location privacy, define a
clear problem statement, and provide a solution (for NEMO to use :-).
  That's why i'm inclined to believe that location privacy is probably
too early to be put in the reqs, what do you think.

Of course, it is nice to say "we do location privacy", just as it is
nice to say "we do access control".  But for the former we don't yet
have an idea what we want.  Or do you think I'm wrong on this?

---

From: Alexandru Petrescu<[email-masked]>
Date: Tue, 11 Mar 2003 11:53:35 +0100

Thierry Ernst wrote:
> If we leave up the technical details of related to extended 
> support, yes. So, my question is "is there a need to change the 
> text in the draft" and if yes, what text would you propose ?

My first proposal is very simple and involves very little effort from
editor: search replace "location privacy" with "".

However, in order to leave the door open to "location privacy"
aspects, I would suggest to first do the step above followed by:

   "Location privacy is a new security aspect in IP mobility contexts.
    It might be desirable for communicating parties to be able to hide
    their location to peers.  However, a problem statement for location
    privacy was not clearly defined at the time of writing.  It might
    be possible that, in the future, Mobile IPv6 will provide location
    privacy tools; NEMO will reuse those tools; NEMO protocols are not
    required to work on location privacy problem definition, nor to
    design new location privacy tools."

What do you think?  Does that catch our discussions?

---

From: marcelo bagnulo <[email-masked]>
Date: 11 Mar 2003 12:30:16 +0100

Hi Alexander,

> relevant to the Extended mode, and very little relevant to the Basic mode.

I do not know... I would say that it depends on the case. Note that the
part of the path between the MR and the HA is probably wireless, and it
may insecure. OTOH you may trust the CNs...

I wouldn't assume much about which one is more relevant, but perhaps i
am missing something?   

> Ok, so the above is a generic description of the the "location

right
> HA will not be able to obtaine the entire location triplet, it will

Correct.
But you are already talking about solutions here :-)

I was pointing the problem. The solution can be as simple as you pointed
out, but i would say that problems should be pointed out so that
solutions can address them.

> If my explanation above is relevant, then requirement R13.4 is not

Not so sure. Thinking it over, i would say that R13.4 is a different
requirement. It talks about encryption of *signaling* messages, so it
addresses, in particular, location privacy issues related with this
messages. However, other packets that do not carry signaling but just
user traffic, also present location privacy issues, since they carry
both the CoA and the permanent address of the MNN. 
Summarizing, R13.4 addresses part of the location privacy issue
(restricted to signaling messages) but issues related to location
privacy of user packets are not considered.

The question is if they should be considered...   

> an LFN or a VMN?)

Is there any difference?

> , the location info to hide is MNN's CoA,

Actually, the CoA- permanent address binding.

>  and
> communication stops.

No, they do not have to be aware of the binding CoA permanent address.
Clearly the must be able to see the CoA, contained in the esterior
header. Location privacy is achieved by concealing the inner permanent
address.

>   So maybe the RO location privacy requirement can
> be loosen.

> do it, maybe it's not for NEMO to do it; just an oppinion.
Agree

Regards, marcelo

---

From: marcelo bagnulo <[email-masked]>
Date: 11 Mar 2003 14:59:58 +0100

Hi Thierry, Alexander

> What do you think?  Does that catch our discussions?

I am not sure...
After this message exchange, i think the the group has a pretty good
idea about what location privacy is.
I also think that it is more than trivial to understand what location
privacy means in the NEMO context, and that including a definition and
how does the concept applies to NEMO is clarifying for the reader has
missed this thread. 
However, what i still do not know is the impact of the location privacy
may have in solutions, i mean perhaps there is no extended solution that
can provide location privacy. 
About the MIPv6 support, i think that we should re-use existing
standards, but if they do not exist, or some issues like location
privacy are not currently addressed, we should try to solve if we think
it is relevant.
So, summarizing i would include a definition of the problem and its
application to NEMO in the guidelines section 4, just as it is included.
Perhaps i would add a sentence to clarify some issues like actual
location and third parties, something like this:

Location Privacy: means to hide the actual location of MNNS to third
parties other than the HA if desired. In the NEMO context, location
information is provided by the binding between the permanent address
assigned to MNN and the CoA assigned to the MR. Third parties may
include the CNs of communications maintained by the MNNs and any other
party along the communication path between the MNN and the CN that can
eavesdrop the communication.

What do think?

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Mar 2003 16:08:06 +0100 (CET)

> multi-homing solution of the home network.

I *think* the statement should be about the Nemo solution not *preventing*
any form of multihoming, including when there are multiple home prefixes.
It would be a bug is Nemo had to do something special to enable any form
of multihoming - it just shouldn't prevent them from being used.

> multi-homing capabilities of the solution of the home network.  

I understand the desire to state such requirements but I think this
is orthogonal to the Nemo aspects of the solution.
The fact that the Ethernet in my office has two routers connecting it
to the rest of the network has exactly the same issues.
Thus I think this is an issue of how Nemo and IGP routing interact; not
about Nemo itself.

  Erik

---

From: marcelo bagnulo <[email-masked]>
Date: 11 Mar 2003 18:02:12 +0100

Hi Takeshi,

> draft-ng-nemo-multihoming-issues are in NEMO solution space.

I will try to read it ASAP

> --+--+--   <--

The term is ok, i just didn't understand which configuration you were
considering.

I am not so sure that i understand the impact of the two prefixes here.
The two prefixes are available for the home link, right? but the mobile
network has only one prefix, right?
If this is the case, i don't see what difference does it makes whether
there are one or multiple prefixes.

I do see that there is a difference when multiple routers are available
at the home link. However, i think this is more similar to the case
where multiple HAs are available. Perhaps the case where multiple HAs
are available can be considered something like multi-homing, since the
MR will have multiple "links" (i.e. tunnels) to the home network. In
this case, some of the multi-homing benefits can be achieved, for
instance fault tolerance when one of the HA is down.
At least i think the multi-homing mechanisms will probably be useful
when dealing with multiple HAs configurations.
 
Regards, marcelo

-- 

uc3m

---

From: marcelo bagnulo <[email-masked]>
Date: 11 Mar 2003 18:02:18 +0100

Hi Thierry

On Tue, 2003-03-11 at 08:16, Thierry Ernst wrote: 
[...]
> bullets. 

Probably benefits was not the right word here, sorry for that.
What i meant is that i do not fully understand what is the scope of the
words "support" in R12.
I mean, R12.1: The solution MUST support mobile networks with multiple
MRs. What does support mean? 
For instance, suppose the case where a mobile network has 2 MRs (MR1 and
MR2). A given solution just selects one MR (MR1) randomly and use it as
MR. The other MR (MR2) is just a normal MNN behind the selected MR. The 
link between MR2 and the home network is never used, even if the link
between MR1 and the Home network is not available. Does this solution
supports multi-homing? If supporting means that the solution does not
malfunction when two MR exist, then we could say that it is supported.
Bu i do not think this what it is expected from the multi-homing
support.

Following your wish expressed in the last sentence (about concrete
sentences) i would include the following sentences in R12

R12: The solution MUST function for multi-homed mobile networks.
        More precisely:

        R13.1: The solution MUST support mobile networks with multiple MRs. 
               In particular, if the path through one MR becomes unavailable, the solution MUST be 
               able to establish new communications between MNNs and CNs using an alternative available path through another MR.
               Additionally, if the path through one MR becomes unavailable, the solution SHOULD (or MAY?) 
               preserve established communications by re-routing the packets of such communication 
               through an alternative available MR.

        R13.2: The solution MUST support MR with multiple interfaces,
               In particular, if the path through one of the MR interfaces becomes unavailable, 
               the solution MUST be able to establish new communications between MNNs and CNs using    
               an alternative available interface of the MR.
               Additionally, if the path through one MR interfaces becomes unavailable, the solution
               MUST (or SHOULD?) preserve established communications by coursing  packets of such communication 
               through an alternative available interface of the MR.
What do you think?

> I think most are common sense and thus don't need
> justification.
>  The bullets in section 4 are justification for section
I would say the the third option i.e. the few we have identified as
necessary. I think so because some people in the wg probably have some
ideas about what protocols are critical, (such as you said about FMIP).
I think this is valuable knowledge that should be included in the doc
and besides it gives a hint to solutions designers about what issues
were detected as relevant or tricky by the group.

> Any proposition ? To be honest, I don't know how to rephrase this to

Ok. tried to do it and see your point :-(

> sentences if anyone is not really happy with the text. 
I fully agree with this. I'll try to. (already started above :-)

Regards, marcelo

-- 

uc3m

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 09:08:24 -0800

> too early to be put in the reqs, what do you think.

I think it would be much quicker if the MIPv6 work were to break into two
groups, one core and one extensions. The extensions group could spin up an
activity on location privacy right away. If that split is not made, I fear the
group will once again get bogged down in something related to the core.

            jak

---

From: Christophe Janneteau<[email-masked]>
Date: Tue, 11 Mar 2003 19:22:52 +0100

Hi Marcelo,

> privacy of user packets are not considered.

Good point.

> The question is if they should be considered...

We may simply extend R14.4 with R14.4-bis to cover the case of user
traffic (encapsulated by MR) disclosing MNN location. I would however
recommand a MAY in that case, in order to align with MIPv6 draft
(draft-ietf-mobileip-ipv6-21.txt, section 15.7,  p153): "Home agents and
mobile nodes may use IPsec ESP to protect payload packets tunneled
between themselves.  This is useful to protect communications against
attackers on the path of the tunnel."

Christophe.

---

From: marcelo bagnulo <[email-masked]>
Date: 11 Mar 2003 21:04:35 +0100

Hi Erik,

[...]
> of multihoming - it just shouldn't prevent them from being used.

I like this requirement.
The problem is that currently there are no multi-homing solutions for
IPv6 available, so we wouldn't know what features shouldn't be prevented
:-(

> Thus I think this is an issue of how Nemo and IGP routing interact; not

I think that one difference between NEMO and an ethernet with multiple
routers attached to it, it is the role of the HA. NEMO Multi-homing is
essentially two paths to the HA (in the case of a single HA). So, I
think that there may be some NEMO specific issues in multi-homing. For
instance, suppose that a MR has two interfaces. A possible solution is
to set up two tunnels with the HA. However, what information is
contained in the binding cache? The mobile network prefix has two
entries in the cache? and  if one path becomes unavailable the
correspondent entry is deleted?. The other option is that only one
tunnel is established and when it becomes unavailable a new BU to that
mobile network prefix is issued binding the prefix to the alternative
CoA. I think that this kind of issues are NEMO specific and are related
to multi-homing support. Perhaps this is what you meant by NEMO-IGP
interaction. However, this interaction impact it the multi-homing
support of the solution, so IMO we should include what level of support
it is expected from multi-homing NEMO.

Regards, marcelo

---

From: Alexandru Petrescu<[email-masked]>
Date: Wed, 12 Mar 2003 03:30:22 +0100

marcelo bagnulo wrote:
>> I *think* the statement should be about the Nemo solution not 
>> *preventing* any form of multihoming, including when there are 
>> multiple home prefixes. It would be a bug is Nemo had to do 
>> something special to enable any form of multihoming - it just 
>> shouldn't prevent them from being used.
>> 
> I like this requirement. The problem is that currently there are no
>  multi-homing solutions for IPv6 available, so we wouldn't know 
> what features shouldn't be prevented :-(

Are there solutions for IPv4 multi-homing?  If yes, then they might
exist for IPv6 too.

> So, I think that there may be some NEMO specific issues in 
> multi-homing. For instance, suppose that a MR has two interfaces.

Isn't this like an MH (mobile host) that has two interfaces?  Can
Mobile IPv6 handle this?  Have you noticed any problem in having two
active interfaces on MH and getting RAs on both?  With the
implementation I played there was no problem: I had two interfaces up
on the MH and one communication stream between MH and CN, no RO.  Each
time that interface received an RA, it sent a BU to HA.  The
communication was continuously switched from one interface to the
other.  Do you think I can call this behaviour as multi-homing support
for MH?  If yes, then I suppose I can call it multi-homing support for
an MR too.

> A possible solution is to set up two tunnels with the HA.

Yes, there are probably two tunnels if two egress interfaces of MR are
up.  Just like when there were two MHs belonging to the same HA.

> However, what information is contained in the binding cache? The 
> mobile network prefix has two entries in the cache? and  if one 
> path becomes unavailable the correspondent entry is deleted?.

Yes, simply put, if one interface goes down then it won't reply to
BReqs from HA, so the BC entry times out.

I would say that if we assume (for a moment) that there is no prefix
entry in the Binding Cache and have in the Binding Cache an entry for
one HoA of one egress interface of MR and another entry for the other
egress interface of MR, then everything will work fine for MR.  When
both entries are in the BC, we'll pick the first.  When only one is
present, well, we still pick the first.

> The other option is that only one tunnel is established and when it
>  becomes unavailable a new BU to that mobile network prefix is 
> issued binding the prefix to the alternative CoA. I think that this
>  kind of issues are NEMO specific and are related to multi-homing 
> support.

[Alternative CoA sounds too much like Alternate CoA which is not.]

Assume a multi-homed fixed host with two interfaces.  How does it
choose between those two interfaces?  Let's say it does so based on
the destination address: if the destination address is site-local and
one interface has a site-local address on it then use that interface,
otherwise use the second interface.  This is an example and is nothing
new, it's in "default address selection".

Assume now a multi-homed mobile host with two interfaces.  If the
destination is site local and one interface has a home address that is
site local, then use that interface as _the_ tunnel.  This is clearly
Mobile IPv6-specific, and not NEMO specific.

Assume now a multi-homed mobile router with two interfaces.  If the
destination is site local and one interface has a home address that is
site local, then use that interface as _the_ tunnel.  This is exactly
like Mobile IPv6 for hosts, nothing new.

In most other cases that I've seen discussed, it was an application
(not the IP stack) decides to use interface 1, instead of interface 2.
  Then again, with a mobile router, an application on MR will decide to
use interface 1 instead of 2, again nothing new.

I mentioned "applications" because there are potentially too many
additional types of indices a host will use to distinguish one 
interface instead of the other:
-if the respective technology is available (e.g. receive WLAN beacon)
  and the other isn't.
-if one interface gives higher bandwidth than the other.
-if one interface gives cheaper bandwidth than the other.
-if one interface gives more secure bandwidth than the other.
-if one interface gives more private bandwidth than the other.
-DiVX file on one interface and an MP3 on the other interface,
  simultaneously.
-any mixture of the above.

Imagine that we engage in designing a MR that uses all the above as a
criterion to prefer one interface to the other. That's an enormous
amount of work, involving coordination with a large number of groups.

The alternative would be that we just make sure that MR works fine
even if there are two active egress interfaces, or that the mobile
network works fine even if it has two MR's connecting it to the
Internet.  "Works fine" means that the MNNs are reachable all the time
at a permanent home address and that their communication with CNs is
not interrupted when MRs change their CoA.  So we can try to make sure
  it works fine.

---

From: Takeshi TANAKA <[email-masked]>
Date: Wed, 12 Mar 2003 23:47:31 +0900

On Tue, 11 Mar 2003 16:08:06 +0100 (CET) 

> Thus I think this is an issue of how Nemo and IGP routing interact; not
Please correct me if the following is wrong.

I think this is both multi-homed link and NEMO issue, and interaction
with IGP routing may not be helpful.

Suppose 2 routers(router_A, router_B) are on the multi-homed link, and
prefix_A, prefix_B are assigned to them for each ingress link, and these
routers are connected to ISP_A, ISP_B to connect to the Internet.

When egress link of router_A goes down, then address derived from
prefix_A can not be reachable from/to the Internet since the multi-homed link
does not have connection to ISP_A.

Router_A may be configured to set lifetime=0 in RA it advertises, or
router_A is configured to reply ICMP reidrect to point out router_B and
stop to include prefix_A in RA it advertises, when egress link of
router_A goes down to let nodes on the multi-homed link know egress link
down.

Anyway, application session on the nodes on the multi-homed link has to
switch source address. 

Now suppose router_A and router_B are replaced by MR_A and MR_B.
In NEMO, egress link of MR_A, MR_B may go down frequently, and MR_A/MR_B
may have to switch route frequently.
Everytime MR_A/MR_B goes down, application session on the nodes on the
multi-homed link has to switch source address...

I'm not saying solution of this issue must be provided, but one of the
issues of NEMO with multiple mobile network prefixes that should be
considered.

Regards,
Takeshi

---

From: Marcelo Bagnulo <[email-masked]>
Date: Wed, 12 Mar 2003 16:41:00 +0100

Hi Alexander,

Alexandru Petrescu wrote:

>>  multi-homing solutions for IPv6 available, so we wouldn't know what 
>> features shouldn't be prevented :-(
> 
> 

IPv4 end-site multi-homing is usually achieved by announcing the site 
prefix through all its providers, so that they announce it as well and 
the site becomes reachable through all its ISPs. This configuration 
provide the expected benefits. However, there are big scalability issues 
with this approach, esentially because each multi-homed site is visible 
in the Default Free Zone.
The initial idea was that this will not be allowed for end sites in 
IPv6. So multi6 was created to find solutions for IPv6 thgat exhibited 
better scalability properties.(For more references, see the multi6 charter)
However, this problem is proving to be extremely difficult to solve and 
no solution seem to be accepted (there are several proposals, though)
So at this time, i think we can say that there are no accepted 
multi-homing solutions for IPv6.

>> multi-homing. For instance, suppose that a MR has two interfaces.
I would like to first clarify what my initial point was: I was not 
trying to propose a multi-homing solution for NEMO in this mail. I was 
just trying to understand whether there were some NEMO specific issues 
in mobile network multi-homing, or not. In order to do that, i've 
considered a concrete example, to see some issues involved in NEMO 
multi-homing.
So the question that Erik made is: Do you think that there are some NEMO 
specific issues in mobile networks multi-homing or it can simply be 
solved by routing protocols as any fixed network with several routers 
attached to it? Is there any difference between the two cases? My 
initial guess was that there are some specific NEMO issues but ...

I will come back to you later about the rest of the message if it is OK 
for you (i will try to read the multi-homing draft in order to avoid 
re-inventing the wheel)

Regards, marcelo

>> mobile network prefix has two entries in the cache? and  if one path 
>> becomes unavailable the correspondent entry is deleted?.
> 
> 
>>  becomes unavailable a new BU to that mobile network prefix is issued 
>> binding the prefix to the alternative CoA. I think that this

---

From: Alexandru Petrescu<[email-masked]>
Date: Wed, 12 Mar 2003 17:05:37 +0100

Hi Marcelo,

Marcelo Bagnulo wrote:
>>>>  *preventing* any form of multihoming, including when there 
>>>> are multiple home prefixes. It would be a bug is Nemo had to 
>>>> do something special to enable any form of multihoming - it 
>>>> just shouldn't prevent them from being used.
>>>> 
>>> I like this requirement. The problem is that currently there 
>>> are no multi-homing solutions for IPv6 available, so we 
>>> wouldn't know what features shouldn't be prevented :-(
>> 
>> Are there solutions for IPv4 multi-homing?  If yes, then they 
>> might exist for IPv6 too.
> 
> IPv4 end-site multi-homing is usually achieved by announcing the 
> site prefix through all its providers, so that they announce it as 
> well and the site becomes reachable through all its ISPs. This 
> configuration provide the expected benefits. However, there are big
>  scalability issues with this approach, esentially because each 
> multi-homed site is visible in the Default Free Zone.

I guess the differences between our views lie in that I tend to see MR
as a simple little multihomed MH and you might try to see it more like
a big router connecting a site to two ISPs.  At one moment I wanted to
think that way and I realized I lack so much info to go any further
that I switched back to see MR as a little small MR (it's not only
because multi-homing but IGP too).  Which doesn't prevent the group to
develop common concepts on whether there's specific multihoming issues
for MR.

> trying to propose a multi-homing solution for NEMO in this mail. I 
> was just trying to understand whether there were some NEMO specific
> issues in mobile network multi-homing, or not.

Which is perfectly ok.

> I will come back to you later about the rest of the message if it 
> is OK for you (i will try to read the multi-homing draft in order 
> to avoid re-inventing the wheel)

It is perfectly ok and multihoming discussion is perfectly relevant
and the issue should be clarified, thank you for your contribution.

Alexander

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Mar 2003 21:01:01 +0100 (CET)

> IPv6 available, so we wouldn't know what features shouldn't be prevented

You must be using the term "multihoming" to only mean "infinitely scalable 
site multihoming" - that particular aspect of multihoming doesn't have any
easy solutions. 

But the use we are talking about in Nemo is about connecting a mobile network
(whether one link or multiple) to different places in the Internet.
This isn't that much different than attaching the Ethernet in my office to
two parallel campus backbones for redundancy.
And this works just fine in IPv4 and IPv6 - the IGP routing protocol
takes care of it all.

The same techniques could be applied in the Nemo context.
For instance in figure 2.2 and 2.3 in draft-ng-nemo-multihoming-issues-00.txt
when the two HAs are in the same IGP domain, there could be a single
prefix assigned to the link (instead of 2 in the picture) and the
MR(s) would inject routes for that prefix to both HAs and life is good.

> it is expected from multi-homing NEMO.

[I'll use the case of two MRs since it is easier to write about - since I
don't have to say "both MR CoAs" but can instead say "both MRs"]

If the MRs are not injecting routes over the tunnel there are
several choices in addition to what you outline above.
But there are actually two separable pieces:
the MRs themself having a binding cache entry at their HA for their HoA,
and the binding cache entry/routing entry for the prefix(es) assigned to
the mobile links.
One could have both MRs binding imply a route for the prefix thus this would
be regular multipath routing. When one of the paths/tunnels fail you'd like
both ends (the HA and MR side) to notice relatively soon.
I guess that could be caused by the binding timing out on the HA and the MR
noticing that it can't refresh its binding.
But it might also make sense to have a separate tunnel quality protocol - that
would look very much the IGP Hello protocol.

If you don't have two routes for the mobile prefix(es) then it will probably 
take longer to fail over. First you have to detect that one tunnel has failed
and then (the added time of) creating the route fro the other tunnel.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Mar 2003 21:08:13 +0100 (CET)

> routers are connected to ISP_A, ISP_B to connect to the Internet.

There are two different cases you might be thinking about and I can;t
tell which one. One case is that the mobile network itself
has a single (home) prefix i.e. the Home Agents for it are part of the same
"site" and they want it to have a single prefix.
The other case is that the mobile network has two separate (home) prefixes
because it is attached to HAs in two different sites.

Note that this is independent of who hands out the CoAs to the MRs - could
be from ISP_C and ISP_D.

So I'm confused.

  Erik

---

From: Takeshi TANAKA <[email-masked]>
Date: Thu, 13 Mar 2003 10:39:16 +0900

On Wed, 12 Mar 2003 21:08:13 +0100 (CET) 

> because it is attached to HAs in two different sites.

The latter case.

Prefix_A given from ISP_A via router_A, prefix_B given from ISP_B via
router_B.

> Note that this is independent of who hands out the CoAs to the MRs - could

Yes.
The case described first is general(?) ipv6 multihoming (multi-homed
link) case. If each egress link is replaced by each tunneling to each 
(different) home agent, the case becomes multi-homed NEMO case(multiple
MRs on a mobile network, and these MRs are managed by different HAs).

Regards,
Takeshi

---

From: Takeshi TANAKA <[email-masked]>
Date: Thu, 13 Mar 2003 12:02:51 +0900

On Tue, 11 Mar 2003 18:02:18 +0100 
"marcelo bagnulo" <[email-masked]> wrote :

[...]
>                through an alternative available interface of the MR.

I'm not Thierry but I agree with what these requirements means.
I was thinking just "support mobile network with multiple MRs" does not
say how much basic solution will work on clearly.

There should be 2 steps of multi-homing support when multiple MRs on
mobile network.

1. The solution enables MNNs to use these MRs for communication

Current ipv6 multihoming should be able to support this, however 

2. The solution enables to preserve established communication through
   cursed MR.

this may not be what ipv6 multihoming can support.
(especially when each MNP is provided from different home network)

I think requirements should represent how much NEMO basic solution will
wotk on multihoming issue 
(and how much benefit NEMO basic solution will provide)

> I fully agree with this. I'll try to. (already started above :-)

Sorry to bother again about requirements...and I'll try, too.

Regards,
Takeshi

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Mar 2003 21:01:01 +0100 (CET)

Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 13 Mar 2003 09:44:23 +0100 (CET)

> > Note that this is independent of who hands out the CoAs to the MRs - could

But the fact that you use "A" and "B" instead of "C" and "D"
is confusing.
So let me try to generalize what I think is your "mobile site multihoming"
configuration.

There are two mobile routers: MR_A and MR_B
They have separate home agents (HA_A and HA_B) that belong to two different
sites (A/48 and B/48 for example).

As a result of this the mobile network has two prefixes: A:x/64 and B:y/64.

The MRs attach either to the same ISP or different ISP. For maximum expansion
assume they are different. Thus the CoA for the MRs is C:1 and D:1
respectively.

The first concern in this type of setup is how does routing work for the
LMNs - is there or is there not an assumption that the MR selection
(the 1st hop default router the LMNs use) needs to be tied to the
source address they use or not?

Thus would it work if the LMN sends a packet with source A:x:987 to first hop
router MR_B?

In the IPv4 and IPv6 models of a host the source address selection
is a function of what interface the host is sending on, but not which
1st hop router it is using.
So unless folks are proposing to change this the host should be able to
use source A:x:987 while using router MR_B.
Making this work requires some coordination between site A and B (to accept
either source address). This is part of the general *site* multihoming issues
when each host gets an address from each site's prefix.
But the point is assuming independence between site A and B (and indirectly
the HAs and MRs) is a non-starter.

> MRs on a mobile network, and these MRs are managed by different HAs).

In both of my cases above there can be different HAs for the two MRs.
But the issue is whether they use a single prefix for the mobile link
or not. Using a single prefix requires coordination between the 
HAs, but as I've shown above using two prefixes also requires coordination
between the HAs.

   Erik

---

From: marcelo bagnulo <[email-masked]>
Date: 13 Mar 2003 14:02:22 +0100

Hi Erik, Takeshi

On Thu, 2003-03-13 at 09:44, Erik Nordmark wrote:
[...]
> HAs,

An additional issue in this configuration would be the following, i
guess. 
If both ISPs are in different sites, and a single prefix is used, how is
the traffic routed to both sites. This implies that the mobile prefix is
announced though multiple ISPs which is not compatible with current
current address provider agggregation. So i am not sure that when
multiple HA in different site with different ISPs are used, a single
prefix can be used within the mobile network. I guess that multiple
prefixes will be needed or additional mechanisms. However, i am not sure
that these issues are NEMO specific, specially since this is basically
the site multihoming problem  

>  but as I've shown above using two prefixes also requires coordination
> between the HAs.

Or additional mechanisms to support multi-homing 

I think that an important question is if those mechanisms are NEMO
specific or general site multi-homing mechanisms?
I would say that these can depend on the configuration considered.
Perhaps a good approach is to consider the different configurations and
evaluate which one presents NEMO specific issues and which one is
efficiently addressed by general mechanisms (such IGP routing) where
there is no need for a special optimization for the NEMO case. Do you
think this is useful approach?

Regards, marcelo

---

From: marcelo bagnulo <[email-masked]>
Date: 13 Mar 2003 16:15:22 +0100

> site multihoming" - that particular aspect of multihoming doesn't have any

I think i misunderstood your initial statement where you said that "I
*think* the statement should be about the Nemo solution not *preventing*
any form of multihoming, including when there are multiple home
prefixes..."

I thought that we were considering the case of a multi-homed home
network i.e. the site that contains the HA is multihomed, so the mobile
network is just another network within the site and the NEMO solution
should not prevent that the site multi-homing solution adopted works
properly. 
(My answer to that is that i agree but there are no solutions for site
multi-homing available right now)

The other interpretation to your sentence refers to the mobile network
multi-homing. i.e. there are some mechanisms to allow that a network has
multiple routers attached (IGPs). So a NEMO solution should be
compatible with these mechanisms. This seems a good approach. However, i
think that there may be some NEMO specific issues to be considered,
which is what is being currently discussed in other mail exchanges.

Do i understand this correctly this time?  

Regards, marcelo

---

From: Ryuji Wakikawa<[email-masked]>
Date: Fri, 14 Mar 2003 12:03:40 +0900

Hello Alex.

I want to add one comment.

At Wed, 12 Mar 2003 03:30:22 +0100,
> for MH?  If yes, then I suppose I can call it multi-homing support for

I am not quite sure how multi-homing is defined in NEMO, but if
multi-homing indicates MR uses multiple interfaces to acquire internet
connectivity "simultaneously", please go ahead to read below texts:)

If MN has multiple HoAs for each interface, it works.  But if MN only
has single HoA for all interfaces, it may not work as multihoming MN,
because MIP does not allow to register multiple CoAs which are
bindined to single HoA.

When an interface goes down, MN still has another active interface.

In the first case, communication flow can not reach to MN even if MN
switches to an active interface, since HoA is changed. But MN can use
all interfaces simultaneously.

The second case can provide seamless connectivity when MN switches
active interface.  MN always register the active CoA to HA, but not
all CoAs. (i.e. MN can not use multiple interfaces simultaneously) I
am not sure if we can call the second case as multihoming MN.
Although MN has multiple interfaces, MN just utilizes single interface
by switching interface. This MN should be treated as normal MN.

In NEMO case, is it acceptable that MR has multiple prefixes for all
interfaces which installed in MR? Otherwise, MR may not utilize
multiple network interfaces simultaneously. 
This may become a possible issue.

I recently submitted the draft how to register multiple binding for
single home address in MIP6 WG. (draft-wakikawa-mip6-multiplecoa-00.txt)

If you look at the draft, we explain current problem and propose a
simple solution for this.

Regards,
ryuji

---

From: Alexandru Petrescu<[email-masked]>
Date: Fri, 14 Mar 2003 15:15:31 +0100

Hi Ryuji, thanks for reply.

Ryuji Wakikawa wrote:
> If MN has multiple HoAs for each interface, it works.  But if MN 
> only has single HoA for all interfaces, it may not work as 
> multihoming MN, because MIP does not allow to register multiple 
> CoAs which are bindined to single HoA.

Yes, one HoA with 2 CoAs don't work, and the "alternate CoA" field is
there but for other reasons.

One should take care with this reasoning.  Until now it went like
this: one fixed HoA, but at different subsequent locations, so invent
the CoA concept.  It is risky to go on with this reasoning and arrive
at a conclusion like this: one HoA with many CareOf-CoAs and with many
many CoAs.

One can't just say: permanent HoA, variable CareOf-CoA, hyper-variable
CoA.

Because, if we say so, then what is that permamentest entity to which
you will assign the CareOf-CoA?  It clearly is not an interface
because you can have two interfaces of a machine (hence multi-homing).
  Is it a processor? No, because there are multi-processor machines, so
if one processor goes down, then the other processor comes up, so
you'll need CareOf-CareOf-CoAs.  Whatever we say now that is permanent
fixed an unique then we will need one day to duplicate it.

What we can do for multi-homing is to have two HoAs each one with its
own CoA, simple and comprehensible (to me, but remark that there
others for whom even this is a radical departure).

> When an interface goes down, MN still has another active interface.
This is the essence of all we're discussing here and is the motivation
not only of "multi-homing" but of many other concepts.

> In the first case, communication flow can not reach to MN even if 
> MN switches to an active interface, since HoA is changed.

Hence a problem.  But I don't see this as a Mobile IPv6 problem.

Have one fixed host with two IP addresses on it, not mobile, not
multi-homed.  But have two IP addresses on it.  Start a connection and
then change choose the other address.  Everything breaks.  This has
been so for centuries, right? :-)

Again, put the MN at home, don't move it and assign two HoAs to it. 
Launch an application, change the HoA and everything breaks.  You 
don't need to move for that to break, it just breaks.  If it broked 
when the host moved, then it would have been a Mobile IPv6 problem.

>  single home address in MIP6 WG.

Ok, I need to read it, thanks for your message.

-- 
Message Classification: MIUO