Subject: Re: [nemo] MR definition

From: "Pekka Pääkkönen" <[email-masked]>
Date: Tue, 10 Dec 2002 12:26:07 +0200

-----Original Message-----
From: T.J. Kniveton <[email-masked]>
To: Pekka Pääkkönen <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: 9. joulukuuta 2002 22:10
Subject: Re: [nemo] MR definition

>> Pekka Pddkkvnen wrote:
>>
>> Hi all,
>>
>> Please correct me if I have understood the definition of MR wrong.
>>
>> MR is :
>>
>> A router as defined in RFC 2460 : "a node that forwards IPv6 packets not
>> explicitly addressed to itself."
>
>Yes, this is the strict definition. There is a very fine line between a
router
>and host when you look at it this way -- by changing one bit in my kernel
>sysctl variables, I can change my "host" into a "router".
>
>Most people also consider other factors, such as whether the node runs
routing
>protocols, whether it is administratively responsible for certain prefixes,
>whether it is considered by other routers as the next hop to get to a
prefix,
>etc.
>
>
>> In addition to this MR's relation to Neighbor Discovery (ND) is (RFC
2461):
>>
>> - MR has host specific Neighbor Discovery behaviour in one or more
interfaces
>> as defined in RFC 2461. (MR's egress interfaces)
>> - MR has router specific Neighbor Discovery behaviour in one or more
>> interfaces as defined in RFC 2461. (MR's ingress interfaces)
>
>The second statement is certainly true.
>
>The first statement may or may not be true. In the Tunneled Mobile Router
draft
>(draft-kniveton-mobrtr), there are two cases defined: Consumer and
>Fully-Enabled. In the consumer case, the MR may not be a trusted entity in
the
>visited domain. In that case, it has no choice but to act like a host
(lowest
>common denominator) in the visited domain to cooperate with the policies
there,
>and use its COA to create a virtual link to its Home Agent, so that it can
have
>the privelege of routing "upstream" through its home network.
>
>In the Fully-Enabled case, the MR is considered as a full-fledged router
>(beyond the ability to simply forward packets from one interface to
another),
>and thus it would behave just like any other router in most respects,
including
>neighbor discovery.

Doesn't the MR also need a global COA in the Fully-Enabled mode in order to
create
a bidirectional tunnel with its HA? To create a COA, MR has to have
host-like
ND procedures in order to create a COA on the egress interface, because
router-like ND procedures
on the egress interface do not create a COA based on received Router
Advertisements.

>>
>> This would mean that MR would have different ND behaviour depending on
the
>> interface.
>
>May be true. A MR has to be versatile enough to use Mobile IP, and
tunneling,
>to create a virtual link to its home network. That intelligence might
include
>using host-like ND procedures.
>
>-TJ
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 Dec 2002 08:36:28 -0000

> 
> Hi, Pascal,
> 
> On Thu, 2002-12-19 at 15:34, Pascal Thubert (pthubert) wrote:
> > > The more pratical deployment scenario I see is that MR will
> > > use backend AAA protocols to check credentials of hosts with 
> > > AAA databases located at the home domain (possibly at the 
> > > other side of the Internet, hence a need for Internet-wide 
> > > protocols such as Diameter/Radius).
> > 
> > There may be a little more to it. I may be useful to have a 
> local AAA 
> > database in a MR for the local nodes, and a remote (accessed via 
> > Diameter, Radius, LDAP, tbd) for visiting nodes. The local database 
> > may be a cache. But in any case, it's needed to allow L2 
> access when 
> > the home connection is not available...
> > 
> > Pascal
> 
> Agree, if you want to authenticate the local nodes.
> By the way, you replied only to me.  Is it intentional? :)
> 
> /br
> /cwng
> 
> 

Oups! :)