Subject: [nemo] comments on draft-wakikawa-nemo-basic-00.txt

From: Alexandru Petrescu<[email-masked]>
Date: Mon, 24 Feb 2003 12:17:01 +0100

Hello to authors of draft-wakikawa-nemo-basic-00.txt.  I understand
the draft is up for discussion, so here are comments.  Please take
them as constructive, I do like the draft but I'm trying to figure it
out better, thank you.

First, thank you for providing this detailed description.  Its novel
aspects show that there are indeed many new potential solutions for
the NEMO problem space, even if only within the basic sub-space.

Overall, I understand that the main new aspects to be considered are
three: assigning the HoA to the MR's ingress interface (not the
egress), the two-step search in the binding cache by HA, and the
assumption of delegation of prefixes from HA to MR.  There might be
more, but those are what I understood.

In general, I have many positive remarks to many aspects of the
description but I won't mention because I agree.  I'll mention the
points I find questionable, but feel free to disagree and educate me.

    "1. MR acquisition of Mobile Network Prefix:  At the beginning, MR
        MUST have a mobile network prefix delegated from its HA.Dynamic
        HA discovery can be used to discover the HA address by MR. MR
        can also have a statically configured HA before starting any
        operations."

To me, the word "delegation", is "prefix delegation" as in DHCPv6
prefix delegation.  In that case, the DHCPv6 server delegates and that
server might be different than the HA.  Of course "delegation" may
mean something else, like a result of zerouter-bof.

The statement above links HA discovery to HA prefix delegation, in a
"use" manner, which I do not think should be the case: HA discovery
and prefix-delegation/assignment should be independent operations.

     "6. HA tunneling packets addressed to Mobile Network:  The HA
         intercepts and tunnels all packets destined to the MR's mobile
         network prefix by IP-in-IP encapsulation."

I think more attention should be paid to the way HA intercepts packets
addressed to all nodes behind MR (when HA uses prefixes in its bc).
The idea is that currently, a Mobile IPv6 HA for hosts takes the home
address in the bc and does a periodic NA for it, putting its own L2
address.  With a prefix, it would mean taking all addresses within
that prefix and dooo NAAA forrr eachhh addressss.  Or am I wrong?

Later in the draft:
    "While MR is away from HA link, HA intercepts packets destined to
     the registered mobile network prefix."

Maybe you have a more detailed view on how HA intercepts packets
destined to the registered mobile network prefix.  Is it something
like HA snoops at those packets?  Or is it more like HA uses
unsolicited broadcasted NA to pretend having MNN's L3 address?

      "1 HA searches a binding cache database with 128-bit prefix
       length as Mobile IPv6.

      "2 HA searches a binding cache database with a registered prefix
         length in a prefix binding only if a prefix length is
         available (i.e.  the binding is a prefix binding)."

I think more detailed info should be given about this search.  Or
maybe an Annex.  For example, what happens if search 1 finds
something, will the 2nd search be performed.  Also, the logic of
"longest-prefix match" means that a /128 search will be performed
anyways by step2, so why splitting it in two.  I might be wrong, but
the description is necessary to go into more detail.

Section 5.4 "Types of tunnelled packets to HA":
     "-  Routing Messages of Mobile Network Prefix
         MR MAY tunnel any routing messages of its mobile network
         prefix.

      -  Multicast Routing Message
         MR MUST tunnel all control messages of multicast routing
         protocols [9] [17] to HA."

There is a sort of potential redundancy, or inconsistency or
incoherency here.  Most routing messages in IPv6 (say a RIPng update)
are mostly multicasted.  So, if all multicast routing messages MUST be
tunneled, then the first item in the list above becomes irrelevant.

It is true that not all messages are multicasted.  For example, an
"advertising" type of message will be multicasted, while a a more
"request" type of message will be directly unicasted.  So, if
"advertising" messages are tunneled but not the "request" messages (a
freedom given by the MAY) then the routing protocol might not work as
before.

    "When MR is attached to a HA link, on the other hand, the HA SHOULD
     route packets to the mobile network according to general IP
     routing."

Agree, but see below, there's a potential contradiction.

    "The HA MAY NOT have exact routing entries for the mobile network
     prefix, but it knows the next-hop address of the mobile network
     prefix from the registered prefix binding.  If the MR-CoA is
     configured by one of the HA's prefix, the MR-CoA becomes on-link
     at HA link.  The HA should route packets to the next-hop address
     (MR-CoA) of the registered prefix binding."

It is acknowledged above above that "general IP routing" is used
between HA and MR when MR is at home.  It is also acknowledged
somewhere in the draft that when MR is at home, there won't be tunnels
between MR and HA.  However, the paragraph right above indicates that
routing between MR and HA when MR at home happens according to an
entry that is the prefix binding, in the binding cache, i.e. Mobile
IPv6, i.e. not "general IP routing".

For example, assume that MR stays at home for an extended while.  Then
it will not change its CoA, thus won't send BU's, thus the prefix
entry in the binding cache expires, thus unreachable.  We most
certainly don't want this.

Of course, this again might revolve around binding cache and routing
table concepts, and what is where and so on.

Section 6.3. Types of Tunneled Packets to MR:
       "HA MAY tunnel any routing information obtained by routing
        protocols.  While away from HA link, MR MUST NOT accept any
        routing messages tunneled by the HA. "

Wouldn't this prohibit running any dynamic routing protocol between MR
and its home domain, when MR is away from home?  Is this the intended
meaning?

       "Also, the MR SHOULD NOT accept any routing messages to update
        its routing table except for default routes at a visiting link.

This would imply that MR MAY accept routing messages to update its
routing table with default routes, those messages being received from
the visited link, thus routing interactions with the visited domain?

Or is it that HA sends route updates to MR, MR is away from home, and
HA tells the MR which are the default routes in the visited link?

Thank you for the security overview, it looks reasonable, with quirks
(what exactly is prefix delegation? what are the threats? how are
these threats prevented?)

Thanks again for the draft.

-- 
Message Classification: GBU

---

From: Cedric Westphal <[email-masked]>
Date: Mon, 24 Feb 2003 15:27:04 -0800

Sorry if you receive multiple copies of this.

Here is the call for papers for ASWN 2003, that might

interest some of the people on this list. Bern is very scenic

in the summer, fwiw, and close (1h drive) to France, Germany,

and 2h to Italy.

ASWN 2003 is the third workshop on Applications and Services in
Wireless Networks. The
first two events were held in France, and in 2003 the workshop will
take place in the capital of
Switzerland. ASWN 2003 aims at investigating new developments in wireless
networks focusing on applications and services. The workshop will provide
three-day presentations of invited and regular papers from manufacturers,
academia, and services providers. Authors are invited to submit full technical
papers on both theoretical and practical aspects of the ambit of the workshop.Tutorial
proposals are also requested.

Topics

Specific areas of interest in Applications and Services on Wireless Networks
include, but are not limited to, the following topics:

Media Distribution over Wireless Networks

New Data Services for Wireless Network

Audio-visual Applications for Home and Business

Inter Domain and Inter System Mobility

QoS Profiling and Pricing, end-to-end QoS

Security and AAA Aspects

Nomadic Services, Interface Management

Mobile ad-hoc Networks, Multihop Wireless Networks

Wireless Local Loop Technologies

Wireless Personal Area Networks

Software Radios

Enabling Technologies and Architectures, 3G and beyond

Service Development, Validation & Test

Service Creation and Discovery

Location-based Services

Middleware for Mobile Applications and Services

Mobile Multimedia

Performance of Mobile/Wireless Networks and Systems

Mobile Service Interworking

Context and Ambient Awareness

Cooperative Networks

Papers

Prospective authors are invited to submit for review, papers that neither
have been previously published nor are under review by another conference
or journal. Priority will be given for original contributions describing
recent and innovative research results or developments in the scope of the
workshop.

Papers must be written in English in two-column format, using font no
smaller than 10 points and not exceed 10 pages. Only PDF and PostScript
formats will be accepted, and all submissions will be handled electronically.
Further details on submission procedures will be described soon on the
workshop main page as Instructions
for submission

Tutorials

Proposals for tutorials including content description and CV of the presenter
should be sent to the Local Arrangements Chair.

Publications

Accepted papers will be published in the conference proceedings. Additionally,
the best papers of the workshop will be considered for publication in a
special issue of Elsevier's
Computer Communications Journal.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 25 Feb 2003 17:14:16 +0900

Hello Alex.

> mean something else, like a result of zerouter-bof.

I do not assume any protocol for delegating prefix.  Of course, DHCPv6
can be a protocol for this, but I did not consider this part enough to
discuss in the draft. 

The point is that HA MUST know the information about set of MR and the
delegated prefix. My explanation may not be appropriate at this text.

> and prefix-delegation/assignment should be independent operations.

I agree on this. I want to say MR may be able to use a HA address
which is obtained during HA discovery operation for trigger of
prefix-delegation operation. (sending some request to the address)
Other example: If MR uses DHCPv6 for prefix-delegation, MR may know HA
address (HA discovery) during prefix-delegation operation.

> unsolicited broadcasted NA to pretend having MNN's L3 address?

Since HA is an end-router for the prefix on the Internet
(i.e. advertising mobile network prefix by routing protocol), HA will
receive all packets destined to a mobile network prefix. During IP
forwarding procedure, HA looks up binding cache and finds a prefix
binding. Therefore, HA can tunnel all these packets to MR.

> the description is necessary to go into more detail.

If HA serves multiple mobile network prefixes (one is a:b::/64, and
another is a::/48), then this HA first search binding cache with 128-bit length(search-1).
After that, HA may do "search-2" twice time for 64 and then for 48.

Whenever HA finds a binding, it stops search.

> tunneled, then the first item in the list above becomes irrelevant.

Multicast Routing Message indicates messages of "mrouted" (IP
multicast routing, PIM etc), but not messages of IP routing (OSPF, RIPng).

MR MAY tunnel any RIPng messages regardless of multicasting.
MR MUST tunnel any PIM messages regardless of multicasting.

> freedom given by the MAY) then the routing protocol might not work as

This is true though....

> certainly don't want this.

In this protocol, there is no notion of deregistered BU. MR MUST
always sends BU to HA even if MR is at home. MR also sends BU
periodically not to expire the registered binding at HA.

> and its home domain, when MR is away from home?  Is this the intended

This "MUST NOT" is typo...This must change to "MAY".
Thanks for pointing out.

> the visited link, thus routing interactions with the visited domain?

When MR attach to the visiting domain, MR behaves as a node. Get RA
from a router and configure IP address and default route.  This
expression is also unappropriate. MR does not acquire the default route
by routing protocol. I will fix this in next version.

Thanks a lot!

Best Regards,
ryuji

ps. Here is our current status of this protocol.
We have already implemented core parts of this protocol. 
It works fine as a prototype :-)
Nested mobility (VMN at NEMO) is also working.
We are going to demonstrate this systems on March 12 at our campus.
If somebody is interested in this demo, please contact me.
sorry for _local_ announcement at this ML.

---

From: Takeshi TANAKA <[email-masked]>
Date: Tue, 25 Feb 2003 17:26:59 +0900

Hi Wakikawa-san et al. authors, 

Thank you for the detailed draft.
I also felt even basic NEMO solution has many poteltial solution,
and have some comments on the draft.

On Mon, 24 Feb 2003 12:17:01 +0100 

> that prefix and dooo NAAA forrr eachhh addressss.  Or am I wrong?

I think this part "how packets to mobile router are relayed to a 
home agent", is one of the most important part in the NEMO basic support.
As Alexandru said, packets addressed to mobile router is relayed to HA
from border router since HA is proxying ND for the mobile router, but
packets addressed to mobile router can not be relayed to MNN.

I think this has been discussed before, and in the discussion, 
one of the approach is "manually configure a border router on 
the home link to make a routing entry to relay packets to mobile 
network prefix to home address of mobile router".

> tunneled, then the first item in the list above becomes irrelevant.
And RIPng messages uses link-local address for its source address.

Regards,
Takeshi

---

From: Alexandru Petrescu<[email-masked]>
Date: Tue, 25 Feb 2003 13:33:51 +0100

Hi Ryuji,

Ryuji Wakikawa wrote:
>> destined to the registered mobile network prefix.  Is it 
>> something like HA snoops at those packets?  Or is it more like HA
>>  uses unsolicited broadcasted NA to pretend having MNN's L3 
>> address?
> 
> Since HA is an end-router for the prefix on the Internet (i.e. 
> advertising mobile network prefix by routing protocol), HA will 

Aha, I see.  In that case, yes, it will work.  But this reasoning
practically eliminates the possibility of having an HA on the same
link, different than the BR.  I'm not saying HA MUST be separated
from BR; I'm just saying that this is the consequence.

Another thing that I'm not sure it will work with this forced BR/HA
reasoning is whether another fixed router attached to the home link
can talk to the MR when MR is not at home.  Call this router FR.

An FR is not connecting the home link to the Internet, it connects the
home link to another link in the home domain.  When FR talks to MR and
MR is at home, FR uses some routing entries in its routing table to
reach the MR.  When FR talks to MR and MR is not at home, the traffic
from FR will not go to the egress interface of the BR, but directly to
MR.  So, if the BR/HA does not do unsolicited NA for MR, it will not
get a chance to intercept packets addressed to MR, so then FR can not
reach MR.

But on another hand, of course, an administrator can manually play
with entries on FR to reach the egress interface of BR/HA and your
"snooping" scheme would work.  But yet on another hand, firewalling on
BR would probably block some things.

Overall, I guess I'm proposing to continue using "intercepting" based
on unsolicited NAs and consider less "snooping" at packets that go
through HA and that have not dst=HA.  What do you think.

>> For example, assume that MR stays at home for an extended while.
>>  Then it will not change its CoA, thus won't send BU's, thus the
>>  prefix entry in the binding cache expires, thus unreachable.  We
>>  most certainly don't want this.
> 

So we're right to conclude that MR periodically sends BU to HA even
when MR is at home.  Now, do you know of a routing protocol that
periodically sends updates to neighboring routers when MR is at home?
  I guess some do?

>> Wouldn't this prohibit running any dynamic routing protocol 
>> between MR and its home domain, when MR is away from home?  Is 
>> this the intended meaning?
> 
> 
> This "MUST NOT" is typo...This must change to "MAY". Thanks for 
> pointing out.

Ah yes, that makes sense.