Subject: Re: [nemo] Re: BU adds routes

From: Mattias Pettersson <[email-masked]>
Date: Thu, 07 Nov 2002 16:19:11 +0100

Hi Motorola people (and a little to Nokia as well, see below),

I took the freedom to read your mrha-00.txt I-D. I appreciate that you
have done some very much needed deep analysis of different solutions and
also all traffic scenarios.

Your I-D includes a lot of the ideas of draft-kniveton-mobrtr.txt, but
you seem to have made an interpretation of the main concept that I
disagree on. Maybe I'm mistaken, but anyway, here's my point:

When MR is home, BR, HA and MR all are attached to the same link.
  HA------BR
      |
      MR

When MR is away, MR is attached to HA through a link of type IP-in-IP
encapsulation.
  HA------BR
  ||
  MR

What is interesting is that draft-kniveton-mobrtr.txt says that MR
actually leaves the home link as a router, while you say that it is
still there (covered for by the HA). An important difference is that
when running routing protocols between all routers on the home link
(including BR, HA and MR), draft-kniveton-mobrtr.txt causes MR to change
its attachment from the home link and move to another link behind the
HA. BR will learn that the mobile network prefix is not reachable
through MR any more, but instead through HA. And the number of hops to
reach it increases by one.

There are pros and cons with both approaches. To me
draft-kniveton-mobrtr.txt seems simpler. This will a number of things in
your I-D.

General comment: I think HA should participate in routing protocols.
Maybe with some intelligence, as you say.

Below are some comments to the I-D:

>    10. FN sends packet to LFN, mobile network visits, HA separated BR
> 
> 
>      ----    ----                           /
>     | FN |  | HA |                         /             
>      ----    ----               ----------/          
>        |       |       ----    |          |          
>    -------------------| BR |---| Internet |          
>          home link     ----    |          |                          
>                                 ----------\                          
>                                            \                         
>                                             \   ----  Visited link   
>                                              --| AR |------          
>                                                 ----     |           
>                                                          |           
>                                                        ----    ----- 
>                                                       | MR |  | LFN |
>                                                        ----    ----- 
>                                                          |       |   
>                                                          ---------   
>                                                          mobile net
> 
> 
>    -FN scans its routing table for LFN's address, and finds default
>     route towards BR.
>    -FN sends NS for L2 address of BR.
>    -BR replies NA.
>    -FN sends packet to BR.
>    -BR scans its routing table for LFN's address, and finds route
>     through MR;
>    -BR sends NS for MR.
>    -HA replies NA with its L2 address (on behalf of MR).
>    -BR forwards packet to HA and sends ICMP Redirect to FN such that
>     subsequent packets from FN to LFN go straight through MR and not
>     through BR.  BR also sends ICMP Redirect to HA, such that HA knows
>     a route through MR.  The logic of this last ICMP Redirect is
>     described in section 6.1.
>    -HA scans its routing table for LFN's address, and finds through MR;
>    -HA scans binding cache and finds 'through MRHA tunnel';
>    -HA encapsulates and sends packet to MR.
>    -MR decapsulates and forwards to LFN.
> 
> 
>    The problem in the above case is how to inform the HA about the
>    route towards MR.  When MR at home, and HA being a host, normally

HA is a router. Always. Don't you think?

>    HA doesn't have a route towards MR.  See discussion in section 6.1.
> 
> 

> 5.3 MR Redirects to BR
> 
>    Also, consider the scenario where the FN has a default route
>    towards the MR instead of the BR, and sending packets to a CN on
>    the Internet.  This might very well happen when the MR is at home
> 
> Petrescu et al.           Expires April 2003                  [Page 15]
> 
> INTERNET-DRAFT        Mobile Networks with MRHA            October 2002
> 
>    and sending RAs, in addition to the RAs sent by the BR.  FN might
>    configure a default route through the MR instead of the BR.  If MR
>    is at home, MR will redirect the FN towards the BR.  So, even if
>    this looks like a wrong configuration on the FN (its default route
>    should point to BR and not MR), packets will still travel correctly
>    when MR is at home.  This should be maintained when the MR is not
>    at home.  There are two possibilities: either the HA (replacing the
>    MR) redirects the FN towards the BR, or it is the MR itself that
>    sends the respective ICMP redirect message to the FN (through the
>    MRHA tunnel).  The first case supposes that HA maintains a routing
>    table, which contains routes towards the mobile network.  This is
>    less desirable if the HA is not co-located with BR, and where we
>    prefer not to have routing interactions with the HA.  The latter

Why not?

>    case is more plausible, keeping the default routing behaviour to
>    the MR.

> 6.2 Static route method
> 
>    This is proposed by [4] and [13], where operator statically
>    introduces a route in the HA, for MR's prefix, towards MR's
>    address, or towards the specific MRHA tunnel.
> 
>    The first approach proposed in [4] suggests to configure a new
>    static tunnel on the MR's HA towards MR_HoA.  This static tunnel,
>    that we call here MR_HoA_tunnel, is to be used as output interface
>    of a new static entry added in the routing table of HA for MR's
>    prefix: MR prefix -> MR_HoA_tunnel.  Upon reception of a data
>    packet from CN addressed to a LFN, MR's HA will consult its routing
>    table and find a match for that packet for this static route since
>    LFN address matches MR's prefix.  As a results it will encapsulate
>    the packet with an additional header that will have MR's HA as
>    source address and MR_HoA as destination address.  In order to
>    forward this packet, now addressed to MR's Home Address, the MR
>    will first consult its binding cache and discover MR's Care-of
>    address.  It will thus send the packet through the MRHA tunnel
>    towards MR's current location.  It is worth mentionning that this
>    approach introduces a double encapsulation of an incoming packet to
>    be forwarded to the MR: the first is due to the MR_HoA_tunnel, the
>    second to the MRHA tunnel.
> 
>    The second approach proposed in [13] suggests a similar method but
>    avoids the overhead introduced by the two tunnels.  It consists in
>    configuring a static route in MR's HA routing table for MR's prefix
>    towards MR's Home Address: MR prefix -> MR_HoA.  Upon reception of
>    a data packet from CN addressed to a LFN, MR's HA will consult its
>    routing table and, again, find a match for that packet for this
>    static route since LFN address matches MR's prefix. This indicates
>    the MR's HA that the packet should be routed towards MR_HoA.  From
>    its binding cache it discovers MR's CoA and as a consequence
>    forwards the incoming packet for CN directly through the MRHA

draft-kniveton-mobrtr.txt seems a bit vague on this. Sometimes MR_HoA is
a global home address, but at other times link-local is assumed. As
described at the end of this mail, I think this is overdoing it.

The comment here though is that first a route lookup is performed where
MR_HoA is found and that address is used as input for the binding cache
lookup. I don't think it is logical to search the binding cache for
something that is not specified in any field of the packet being
forwarded.

>    tunnel.  This approach reduces the overhad of the MR_HoA_tunnel but
>    requires a suitable coordination of the routing table and binding
>    cache on the HA.

> 7.1 Link-local addresses
> 
>    When the MR is at home, and if it runs a dynamic routing protocol,
>    it exchanges routing information with BR, by using its link-local
>    address and BR's link-local address.  When the MR is not at home,
>    and HA defends the MR's home address, the HA is normally doing this
>    for any type of addresses except link-locals.  The immediate
>    necessity would be for the HA to defend a link-local address of the
>    MR, instead of a global-scoped home address.  However, this is in
>    conflict with the necessity of dynamic routing protocols to use
>    link-local addresses only.

Yes, HA will have to defend the link-local address of MR. And all other
addresses (global etc.) of MR by default.

Please see draft-kniveton-mobrtr.txt. When the MR is away, it is not
participating directly with the home link by routing protocols.
Everything is propagated through HA.

> 
>    If Mobile IPv6 spec is to be followed, then the HA will not allow
>    re-direction of traffic of a Home Address towards a CoA, when that
>    Home Address is link-local.
> 
>    Another issue concerning link local addresses: the MR has routes to
>    the BR using BR's link local address.  When the MR is away from
>    home: how does the MR reach BR's link local address?

Now HA is an adjacent router of MR. BR is one additional hop away. In
other words, MR doesn't have to know BR, only how to reach HA (which is
through the tunnel).

> 
> Petrescu et al.           Expires April 2003                  [Page 18]
> 
> INTERNET-DRAFT        Mobile Networks with MRHA            October 2002
> 
>    How does it tell the difference between a link local address on the
>    home link and a link local address on the visited link?
> 
> 7.2 MR as an MN
> 
>    If the MR is at home and it has an address configured on the moving
>    interface other than a link-local address, then the MR can act as
>    an MH too, and send normal Mobile IPv6 BUs, binding that Home
>    Address to a newly configured CoA; thus allowing the MR to be an MH
>    for itself only, ignoring the LFNs.  If the MR at home doesn't have
>    other addresses than link-local on the mobile interface then the MR
>    can not send normal Mobile IPv6 BUs and can not be an MH.  It can
>    however be an MR for the hosts on the mobile network.

Not necessarily true. MR can have a global address on its ingress
interface and use that for its host functions. I.e. MR is also an LFN.

From http://www.nal.motlabs.com/nemo/drafts/draft-kniveton-mobrtr.txt:

> 6.1. Processing the Tunneled Routing Messages
> 
> When the HA_MR receives the routing information from the mobile router
> through the bidirectional tunnel, it adds the corresponding routes to
> its routing table with the next hop set to the mobile router's address,
> in case of IPv6 MR's link local address.  This next hop address is
> obtained from the source address of the inner packet.  The HA_MR in
> turn propagates this information when it sends routing updates to other
> routers on the mobile router's home link.

Yes. But:
> 
> The HA_MR also needs a binding cache entry for that address which is
> the next hop address for the MR's subnet.  In the case of IPv4 this
> is created when the MR sends a registration request [?] for its home
> address when it moves away from its home link.  In the case of IPv6
> HA_MR needs a binding cache entry to the mobile router's link local
> address.  This is because the next hop address in the routing table
> entry returns the mobile router's link local address.  And to forward
> packets to the mobile router's link local address, a binding cache entry
> is needed.  A binding cache entry is not created unless HA_MR receives a
> binding update from the mobile router.  Therefore the mobile router MUST
> send a binding update for its link local address in addition to its home
> address.  This is optional in the current Mobile IPv6 [5] specification.

I don't see why this is needed. The HA_MR already has a route for MR's
subnet pointing to MR's link-local address _and_ the tunnel interface
towards MR. A route lookup's primary function is to provide the outgoing
interface, which in this case is the tunnel to MR.

> 
> 6.2. Forwarding Packets to MR's subnet
> 
> Since HA_MR advertised routing reachability information for MR's
> subnet, it receives the packets meant for the nodes in the MR's subnet.
> Route lookup on HA_MR returns the address of the mobile router as the
> next hop address.  By making use of the binding cache entry for the
> mobile router's address (link local address in case of IPv6) and the
> bi-directional tunnel with the mobile router, HA_MR starts forwarding
> packets throught the tunnel to the mobile router.  The mobile router in
> turn decapsulates the packet and fowards it on its subnet.
> 
See comment above for the first I-D.

Also, should the HA have a BC entry for the link-local address of MR
according to MIPv6 I-D?

Thanks for your attention.

/Mattias

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 07 Nov 2002 16:24:14 -0800

Hi,

> When MR is away, MR is attached to HA through a link of type IP-in-IP

we have an implementation of this. it works just fine.

> General comment: I think HA should participate in routing protocols.

strongly agree.

> HA is a router. Always. Don't you think?

it _is_ always. from 
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-19.txt

      home agent
                A router on a mobile node's home link with
which the
                mobile node has registered its current
care-of address.
                While the mobile node is away from home, the
home agent
                intercepts packets on the home link destined
to the
                mobile node's home address, encapsulates
them, and
                tunnels them to the mobile node's registered
care-of
                address.

it is a router on the home link.

> described at the end of this mail, I think this is overdoing it.

it is deliberate :-) when the HA and MR are running a
routing 
protocol through the bi-directional tunnel interface, the
routing 
updates from the MR have MR's link local address. so the
next hop 
automatically becomes the link local address. when the route
is 
created through the binding update, the next hop becomes the
MR_HoA. 
but it does not matter. both should ultimately point to the
tunnel 
interface (HA, MR_CoA). 

by the way, the MR can register both its home address and
link 
local address with just one binding update by setting the
'L'
bit to 1. this is new in MIPv6 spec. it is not there in 
draft-kniveton-mobrtr yet. however the MR (or an MN) cannot
send a binding update for its link local address alone.

> Also, should the HA have a BC entry for the link-local address of MR

not unless if the 'L' bit was set in the BU.

regards
Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 07 Nov 2002 16:33:33 -0800

resending. something went wrong with the earlier mail. the format
got screwed up. some text was also missing.

Mattias Pettersson wrote:
> disagree on. 

I disagree too.

> Maybe I'm mistaken, but anyway, here's my point:
> 

strongly agree.

it _is_ always. from 

      home agent
                A router on a mobile node's home link with which the
                mobile node has registered its current care-of address.
                While the mobile node is away from home, the home agent
                intercepts packets on the home link destined to the
                mobile node's home address, encapsulates them, and
                tunnels them to the mobile node's registered care-of
                address.

> described at the end of this mail, I think this is overdoing it.

it is deliberate :-) when the HA and MR are running a routing 
protocol through the bi-directional tunnel interface, the routing 
updates from the MR have MR's link local address. so the next hop 
automatically becomes the link local address. when the route is 
created through the binding update, the next hop becomes the MR_HoA. 
but it does not matter. both should ultimately point to the tunnel 
interface (HA, MR_CoA). 

by the way, the MR can register both its home address and link 
local address with just one binding update by setting the 'L'
bit to 1. this is new in MIPv6 spec. it is not there in 
draft-kniveton-mobrtr yet. however the MR (or an MN) cannot
send a binding update for its link local address alone.

regards
Vijay

---

From: Christophe Janneteau<[email-masked]>
Date: Fri, 08 Nov 2002 10:00:24 +0100

Hi Mattias and All,

First of all, thanks a lot for your very interesting comparison between
the two drafts. We definitively need such discussion to better
understand issues.

For now, I would like to comment only on one part of your email which
raises a very important point that we should clarify (at least for me
:).

> HA is a router. Always. Don't you think?

This is a very good question indeed and, as you said, our draft-petrescu
does not make such an assumption.

What about a regular MIPv6 HA?

draft-ietf-mobileip-ipv6-19.txt seems to assume that the HA is a router
(at least it describes typical behaviors that a HA router must have,
e.g. setting the 'R' bit in Prefix Information option of Router
Advertisement it sends, this for the Dynamic Home Agent Discovery
process). However, I have the feeling this is only an assumption since I
did not find any requirements "HA MUST be a router" in the draft. So my
personal understanding is that nothing in the current Mobile IPv6
specification prevents a HA from being a simple host and not a router.
Please let me know if this assumption is not correct and why, I can
imagine this has been already discuss on mobile-ip mailing list BTW...

Assuming regular MIPv6 HA can be a host, a don't see any good reason why
NEMO should mandate MR's HA to be a router. In fact, I can even identify
good reasons why NEMO, as a standard group, should not impose this. Here
are two of them:

o Management reasons: Let's assume a home network equipped with a host
HA to support Mobile Nodes wants to upgrade to support also mobile
networks. It would then have to deploy a second HA (router)...since it
could not use its existing one that is a host. This would introduce
duplication of functions...

o Business reasons: If HA can be a host, A company X who is NOT shipping
routers could still make business by selling (host) HA. If there is no
good technical reasons to prevent HA to be a host, then NEMO should not
impose this....since it may introduce unfairness in the business space
which is something a standard organism should try to avoid.

Please let me know your opinion on this...
Thanks,
Christophe

---

From: Alexandru Petrescu<[email-masked]>
Date: 08 Nov 2002 12:45:49 +0100

> also all traffic scenarios.

Hi Mattias, and thank you for reading through the drafts.

> still there (covered for by the HA).

Yes, and there are many intermediary degrees.  For example, MR could
instruct HA to participate on the routing protocols exchanges on its
behalf, when the MR is not at home.

> Maybe with some intelligence, as you say.

If HA a host (see below), then it might look redundant for HA to
maintain many routes towards all fixed subnets attached to the home
link.  The only routing need for HA is to maintain the routes towards
the prefixes of the mobile links.  The information related to all the
fixed links attached to the home link can be obtained by ICMP Redirect
from each BR that attaches to those fixed links.  IMO.

> HA is a router. Always. Don't you think?

I will bite even if I know the hook hurts :-)

Instead of calling HA a host, I should have called it a one-interface
machine, HA for Mobility only, HAM.  The only routing information it
maintains is related to mobility of hosts and routers, and it doesn't
maintain routing information related to the fixed hosts or routers
(other than static routes and/or dynamically obtained routes from ICMP
Redirects sent by BRs).

An HA like this could be an advantage in deployment of mobility in the
existing fixed environments, where BRs exist.  Instead of modifying
BRs, one could just deploy a new HAM PC and modify only the MHs that
move and MRs that move.

I think that this discussion might lead to a requirement.  This
requirement might sound like this:

   "In NEMO, and from a router/host standpoint, the HA forwards
    packets and is thus a router.  Also, the HA should be a treated as
    router or as a host like Mobile IP treats it, not different.  If
    Mobile IP allows for HA to be a one-interface machine that doesn't
    participate in dynamic routing, then NEMO should allow it as
    well."

The other flavor would be:

   "In NEMO, and from a router/host standpoint, the HA is a router as
    in rfc2460."

Another one:

    "The HA must participate in all existing routing protocol
     exchanges at home."

This probably not well formulated, but I'm sure a good requirement can
come up from the router/host discussion.

> >    prefer not to have routing interactions with the HA.
> 
> Why not?

Why not what? :-)

If HA must participate in all dynamic routing interactions then yes,
the HA will send the respective Redirect, I agree with your question.

> something that is not specified in any field of the packet being

Yes, order of search is important here.

Thanks again Mattias for reading through the drafts,

Alex

---

From: Alexandru Petrescu<[email-masked]>
Date: 08 Nov 2002 14:22:58 +0100

> > you seem to have made an interpretation of the main concept that I

So you Vijay disagree on the same interpretation of the main concept
that Mattias disagrees on, or you disagree on another interpretation
of the main concept?  Or you just disagree too? :-)

> > General comment: I think HA should participate in routing protocols.

Generally agree.  I think HA must participate into routing related to
mobility and may participate in routing related to fixedness.

> bit to 1. this is new in MIPv6 spec.

Aha, this is new indeed thank you for letting us know.  That L bit
might prove very useful for NEMO.

It should be clarified though.  If I understand it correctly, that L
bit is there for DAD reasons only.  If I understand it correctly, its
semantics will not allow for an MR to have the IID of the ll different
than the IID of the home address.

I'm saying this because I'm struck by the following paragraph from the
same draft:

   "However, packets addressed to the mobile node's link-local address
    MUST NOT be tunneled to the mobile node.  Instead, such a packet MUST
    be discarded, and the home agent SHOULD return an ICMP Destination
    Unreachable, Code 3, message to the packet's Source Address (unless
    this Source Address is a multicast address)."

I was thinking that when MR uses RIP through the MRHA tunnel, it will
absolutely need to get packets addressed to its ll through that
tunnel.

> send a binding update for its link local address alone.

Exactly, that's what I understood too.

Thanks,

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Nov 2002 10:21:19 -0800

hi Christophe,

please. it is weird that NEMO would call HA a host when MIPv6
calls HA a router. when the terminology section in MIPv6 says 
HA is a router, do you need another statement which says HA 
MUST be a router.

and, if a node does IP forwarding, I thought it was a router.

anyway coming back to the topic, it simplifies the solution to
a large extent if you assume HA is a router. lets go with it.

> did not find any requirements "HA MUST be a router" in the draft. So my

look in the terminology section.

regards
Vijay

---

From: Michael Thomas <[email-masked]>
Date: Fri, 8 Nov 2002 10:33:09 -0800 (PST)

> a large extent if you assume HA is a router. lets go with it.

   Yet... a router is a host too :) I think it's generally
   more useful to talk about which direction a packet gets
   steered (stack, interface) once it's arrived.

	   Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Nov 2002 10:38:55 -0800

> of the main concept?  Or you just disagree too? :-)

:-). sorry. I should have been verbose.

I disagree with your interpretation of the main concept (or in short,
agree with Mattias).

> than the IID of the home address.

right. but L bit is not for DAD. the MN sets the L bit to 1 if it 
wants its link local address to be defended in addition to its 
home address.

> absolutely need to get packets addressed to its ll through that

right. MIPv6 deals only with hosts. NEMO should overide this as part
of mobile router support. if the HA knows that a particular MN is an
MR, it starts tunneling routing updates, even though the source address
is a link local address. requiring routing protocols to use global
addresses instead of link local addresses should not be our goal (IMO). 
that would need changes to routing protocols.

regards
Vijay

---

From: Alexandru Petrescu<[email-masked]>
Date: 08 Nov 2002 21:02:14 +0100

> I disagree with your interpretation of the main concept (or in short,

That's what I didn't understand from Mattias about "interpretation of
the main concept".

Should I understand from both of you that the main concept of
draft-kniveton is badly interpreted by us?  Or that the generic mobile
router concept is badly interpreted by us?

If the former I could try to push for removal of as much concept as
possible that comes from other documents.

> that would need changes to routing protocols.

Correct, changes to routing protocols is what we wish to avoid as much
as possible.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 08 Nov 2002 12:40:06 -0800

hi Alexandru,

> router concept is badly interpreted by us?

there is nothing bad about how you interpreted it. Mattias's point
was that things become much simpler if you assume that, when the MR
is away from home, it is reachable through the bi-directional
tunnel with the home agent and does not appear to be still on the
home link. the routing table of any router on the home link should
also reflect that the MR is now one extra hop away.

to put in another way, a router on the home link has a route to
the mobile network in which the next hop is the link local address
of MR. when the MR is away from home, the next hop should be the
home agent.

regards
Vijay

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 09 Nov 2002 17:05:59 +0100

Hi Christophe,

> What about a regular MIPv6 HA?

It is a router, just as Vijay explained in another mail.

> duplication of functions...

The first HA is a router.

> which is something a standard organism should try to avoid.

Change business... :-)

And for the definition of what is a router (from RFC 2460):
   router      - a node that forwards IPv6 packets not explicitly
                 addressed to itself.

We're not talking about an expensive rack of hardware specially designed
for routing. A router is a function. If the input function processing of
the stack doesn't drop packets that have a destination address other
than those belonding to the node itself, it is a router by definition.

It is possible for a router to have only one physical interface.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 09 Nov 2002 17:21:07 +0100

Hi Alex,

> from each BR that attaches to those fixed links.  IMO.

The HA doesn't have to store all routes to fixed subnets on the home
link although it participates in routing protocols. As long as it keeps
a default route to BR, it can reach them all. We both agree.

The problem is that BR will send ICMP redirects for packets that HA send
with destinations that belong to subnets below BR. So HA end up having
to save these routes anyway (now in the form of host routes rather than
prefix routes, which consumes even more routing entries).

> (other than static routes and/or dynamically obtained routes from ICMP

If you see this as an optmization, you're free to do so.

> BRs, one could just deploy a new HAM PC and modify only the MHs that

Of course. No need to modify the BRs. I think HA should be decoupled
from BR. How would you otherwise implement a home link with redundant
HAs where you can run DHAAD?

>     participate in dynamic routing, then NEMO should allow it as

Yes, apart from the word host.

>    "In NEMO, and from a router/host standpoint, the HA is a router as

Very true.

>     "The HA must participate in all existing routing protocol

This is what I think is wise to do, but it doesn't have to be a MUST.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 09 Nov 2002 17:33:25 +0100

Hi,

> that would need changes to routing protocols.

I think this part of the MIPv6 spec should be made a bit clearer. If it
is done in the right way, it doesn't stop the approach I'm talking
about:

I assume that HA and MR have a bi-directional tunnel between each other
when MR is away. This tunnel is a link, and they will exchange routing
information with each other over this tunnel. HA will not relay packets
with source/destination = link-local between this tunnel and the home
link. The routing information will get propagated anyway, because the
routing daemon on HA will sit in the middle.

So what the MIPv6 spec should say is: "HA must not forward packets from
the home link into the tunnel if the destination address is MN's
link-local address". HA itself should be free to send such packets into
the tunnel, provided that HA itself initiated them.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Sat, 09 Nov 2002 17:38:03 +0100

Hi Alex and Vijay,

> of MR. when the MR is away from home, the next hop should be the

Alex, yes, please try to reflect the different views you have. I think
it is good that you quote draft-kniveton, but I would like you to more
clearly put it onto the map and explain your own view and how they
differ. Draft-kniveton has a smaller scope. mrha-00 tries to cover as
much as possible.

/Mattias

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 11 Nov 2002 10:13:06 -0800

hi Mattias,

> the tunnel, provided that HA itself initiated them.

what if NEMO just says, "If the packet is a routing protocol update, 
the packet is forwarded into the tunnel interface by the HA, even
though the source and destination address of the packet is link local.
Every other packet with source or destination address as link local
is is not forwarded through the tunnel as specified in [MIPv6]".

wouldnt this be enough, instead of asking MIPv6 WG to relax their
requirement of not tunneling packets with link local addresses?

regards
Vijay

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 12 Nov 2002 12:00:17 +0100

Hi Vijay,

> is is not forwarded through the tunnel as specified in [MIPv6]".

That would require looking into the packet.

> requirement of not tunneling packets with link local addresses?

I didn't mean to relax MIPv6 spec. I meant to clarify it. IMO, the MIPv6
spec's intention is that the HA must not forward link-local packets
(initiated by others). What I fear is that people read into the MIPv6
spec that link-local packets must not go over the tunnel (including
those that the HA initiated itself - the kind that I want to use for
route updates).

/Mattias

---

From: Alexandru Petrescu<[email-masked]>
Date: 12 Nov 2002 17:21:16 +0100

> > > When MR is away, MR is attached to HA through a link of type IP-in-IP

Yes, this is right, I'm only starting to understand what you meant.

> prefix routes, which consumes even more routing entries).

Aha, I see the inconvenient of too many routes.

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 13 Nov 2002 17:33:35 +0900 (JST)

Why should we make the things more complicated that it is already ?
Let's stick to the definition of HA as stated in MIPv6 so we don't
need to state in NEMO requirements whether it is a host or a
router. Conceptually, a HA is a router, and this is what MIPv6 is all
about.

Thierry

---

From: Christophe Janneteau<[email-masked]>
Date: Tue, 19 Nov 2002 10:38:23 +0100

Hi Mattias and All,

[Sorry for this very late follow-up of your email, I am just catching up
with NEMO emails... Please ignore if already discussed in the latest
discussions...]

Mattias Pettersson wrote:
> [...]

According to your description of draft-kniveton-mobrtr.txt, MR_HA is
required to run a routing protocols if MR and BR do, otherwise the
proposal will not work. This is a very strong requirement and an
important move from a regular MIPv6 HA. I agree that having the HA
running a routing protocol may help in handling MR's mobility however we
should carefully evaluate alternative before taking this requirement for
granted in my opinion...imposing HA to run a routing protocol again
makes the "HA box" more complex, so we should have good reason to impose
this.

> something that is not specified in any field of the packet being

I do not see any reason why this should not be done...similar thing is
already done when parsing the Neighbor Cache: A Host make look for the
Ethernet address of the next hop router in its Neighbor Cache whilke the
packet is not directly addressed to this next hop router but for a host
far away in the Internet...
I don't see why we should not allow similar behavior for the binding
cache.

Thanks,
Christophe

---

From: Christophe Janneteau<[email-masked]>
Date: Tue, 19 Nov 2002 12:17:55 +0100

[Again sorry for the late posting...please ignore if not appropriate]

> It is possible for a router to have only one physical interface.

You're right, I fully agree that HA is a router according to the
definition of RFC2460.
I should have been clearer in my email and talk about functions instead
of host/router.
Actually my point was that a router can run many functions in addition
to the simple definition of RFC2460 such as sending Router
Advertisements, running a routing protocol etc...
Although a regular MIPv6's HA is a router, it is not required to run a
routing protocol (of course)...I think it would be nice to have a NEMO
approach that also preserve this characteristic...

Christophe.

---

From: Alexandru Petrescu<[email-masked]>
Date: 19 Nov 2002 12:43:09 +0100

> Advertisements, running a routing protocol etc...

Exactly, I entirely I agree with this.  And in addition to the issues
you mention, there are more issues (some are in the draft) that have
been probably raised already.  For example, "is MR a host or a
router?"  As a host it will autoconfigure a CoA and a default route
based on the received RA, but as a router it will not.

Alex

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 19 Nov 2002 14:28:20 +0100

> based on the received RA, but as a router it will not.

MR can be seen as a host on the egress interface and as a router on the
ingress and tunnel interfaces.

/Mattias

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 19 Nov 2002 14:43:41 +0100

Hi Christophe,

> I don't see why we should not allow similar behavior for the binding

I understand that this is a sometimes desired behaviour, but it doesn't
match my mind model of how routing is performed.

Anyway, ordinary routing is performed in two steps: first outgoing
interface is determined, then next-hop determination is done for that
interface. I want a just as good model for how a binding cache and a
routing table interact.

To me I see any node implementing a binding cache would try to match the
destination address of the packet with what's in the binding cache. Now
we want to change this. Maybe it could work, but we have to explicitly
specify how.

/Mattias

---

From: Alexandru Petrescu<[email-masked]>
Date: 19 Nov 2002 14:54:35 +0100

> ingress and tunnel interfaces.

Yes.  A minor exception is that MR will not send RAs on all the
interfaces on which it is seen as a router.  Or will it send RAs on
the tunnel interfaces to be advertised on the home network?  Or will
it ask its HA to send those RAs on its behalf?

Alex

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 19 Nov 2002 15:03:47 +0100

> it ask its HA to send those RAs on its behalf?

No need for the MR or HA to send RAs on a link (read: tunnel) where
there are no hosts to autoconfigure. What interfaces a router transmits
RAs on is configurable, IMO.

The MR is not a default router of the home link, especially not when it
is away, so it should not send RAs onto the home link, not even by the
help of HA.

/Mattias

---

From: Alexandru Petrescu<[email-masked]>
Date: 19 Nov 2002 15:31:34 +0100

> RAs on is configurable, IMO.

Yes indeed it is configurable.

The link (tunnel) is more like a PtP link, with only two machines on
it.

Yet, the MR should be able to be renumbered when it is away from home;
and router renumbering works with routers that join multicast groups.
I don't know whether the MR can subscribe to those router multicast
groups, when it is away from home, and through the multicast-incapable
link which is the MRHA tunnel, or how this could be done.

> is away, so it should not send RAs onto the home link, not even by the

Right, but should the RA's sent by the HA be distributed to MR?  I
think this also boils down to that MRHA link tunnel not being
multicast-capable.

Alex

---

From: Alexandru Petrescu<[email-masked]>
Date: 19 Nov 2002 15:43:55 +0100

> think this also boils down to that MRHA link tunnel not being

Sorry, that is the BR (not the HA) sending RAs to MR, and it's not RAs
but Mobile Prefix Adevertisements, through the PtP non-mc link you
say.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Nov 2002 16:49:32 +0100 (CET)

> interface. I want a just as good model for how a binding cache and a

This doesn't match my notion of how forwarding is done.

Conceptually a packet arrives and there is a single lookup that finds both
the next-hop and the outgoing interface. Implementations might of course do
things differently, but they still have the externally visible behavior
of a single routing table lookup.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 19 Nov 2002 16:51:01 +0100 (CET)

> link which is the MRHA tunnel, or how this could be done.

All pt-pt links including tunnels are trvially multicast capable.
Sending multicast on out such interfaces consist of sending it to
the other end.

  Erik

---

From: Christophe Janneteau<[email-masked]>
Date: Tue, 19 Nov 2002 17:17:46 +0100

Hi Matthias,

> interface. I want a just as good model for how a binding cache and a

Thanks for this very comprehensive description. I also think we should
try to preserve this model on the HA when it comes to route packets
towards MNNs.

I think a key point around MR_HA behaviour is how to "coordinate" the
parsing of the routing table with the parsing of the binding cache. The
complexity here also is that this is really tighted to implementation
rather than pure protocol: the MIPv6 draft describes what a binding
cache is but actually does not say how it should be implemented (feel
free to correct me if wrong)...e.g. one may implement a binding cache in
the routing table using host routes (I think some implementations do
that...)...

Anyway, I agree that ordinary routing process as you described should be
the rule on the MR_HA. This drives me to the conclusion that the Binding
Cache could in fact not be used for the purpose of routing packets to
MNN. Let me try to expain this in the following scenario considering the
case where no routing protocol is used:

1) MR goes away from home and sends a BU to HA
2) HA authenticate BU and add an entry in its BC, then it creates a
routing table entry for the mobile network thanks to the "MR_HoA to
MR_prefix" database. This entry could be:

Prefix          Next-Hop          Ifc
MR_prefix       ::                MR_HA_tunnel

Note there is no need to specify a next hop in the route (unspecified
address) since the MR_HA tunnel is point-to-point. With this route
packets addressed to MNNs will be forwarded directly through the
tunnel..no need to recover MR_HoA->MR_CoA entry from the BC...

Christophe

---

From: Christophe Janneteau<[email-masked]>
Date: Tue, 19 Nov 2002 18:01:21 +0100

Hi Erik,

In my understanding Matthias comment was not contradicting the fact that
both the next-hop and outgoing-interface are recovered in a single
routing table lookup. I understood the comment as how, once recovered,
those two informations are used to route the packet: The
outgoing-interface must be known prior considering the next-hop since
this is the interface through which Neighbour Solicitation for that
Next-Hop (usually link local address) must be sent....

Am I wrong here?

Chirstophe