User-Agent: Microsoft-Entourage/12.26.0.100708
Date: Fri, 10 Sep 2010 19:30:48 +1000
Subject: Re: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix
 Delegation for NEMO) to Proposed Standard
From: Hesham Soliman <hesham@elevatemobile.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Message-ID: <C8B037E8.14F97%hesham@elevatemobile.com>
Thread-Topic: [MEXT] Last Call: draft-ietf-mext-nemo-pd (DHCPv6 Prefix
 Delegation for NEMO) to Proposed Standard
Thread-Index: ActQytntixh/K1hhd0KnhVE82gXL3Q==
In-Reply-To: <4C887E8E.8010809@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Cc: IETF Discussion <ietf@ietf.org>, mext <mext@ietf.org>
Precedence: list

On 9/09/10 4:28 PM, "Alexandru Petrescu" <alexandru.petrescu@gmail.com>
wrote:

> Le 09/09/2010 08:01, Hesham Soliman a =E9crit :
>>=20
>>=20
>>=20
>> On 9/09/10 3:54 PM, "Wassim Haddad"<wassim.haddad@ericsson.com>
>> wrote:
>>=20
>>> On Sep 8, 2010, at 7:58 AM, Alexandru Petrescu wrote:
>>>=20
>>>> I agree mainly with the document draft-ietf-mext-nemo-pd.
>>>>=20
>>>> It is good and needed to dynamically assign a Mobile Network
>>>> Prefix to the NEMO-enabled Mobile Router.
>>>>=20
>>>> However, here are a couple of missing points.
>>>>=20
>>>> One missing point is about how will the Mobile Router configure
>>>> its default route on the home link?  I thought Prefix Delegation
>>>>  would bring DHCP in the picture and would allow MR to synthesize
>>>>  a default route even though RAs are absent.  But I now realize
>>>> that a DHCPv6-PD implementation (and std?) does not allow a
>>>> router (MR) to synthesize its default route (neither RA does, nor
>>>> DHCPv6-nonPD does).
>>=20
>> =3D>  I think the MR can easily act as a host on its egress interface
>> and configure its default/next hop router that way. Of course the
>> other alternative is to use routing protocols, but I think using ND
>> should be sufficient.
>=20
> Hesham - when at home, the MR acts  as a router (ip_forward=3D=3D1,
> join all-routers group), as such ND is insufficient to obtain the
> default route - it's a Router.
>=20
> When at home, and using DHCPv-PD, the MR also acquires its Home Address
> with DHCPv6.  If so, then it doesn't use SLAAC to auto-configure neither
> a Home Address nor a default route.
>=20
> In implementation it is of course possible to dynamically change MR
> behaviour from Host to Router: be at home, first act as host (fwd=3D=3D0) to
> acquire the Home Address and default route, then set fwd=3D1 and use
> DHCPv6-PD to acquire a prefix (but not the Home Address) and take
> advantage of the default route acquired previously as a Host.  This is
> one way of solving the issue.

=3D> Exactly.=20

 However it is not specified.

=3D> Who cares, specify it in your product description. The IETF doesn't
specify how to build products. If you want to solve this with protocols the=
n
use routing protocols. Of course you need to solve the security issues when
the MR moves.=20

I am not
> sure how clean is it anyways to disregard that 'M' bit of RA anyways.
>=20
> The alternative to using routing protocols (OSPF?) to communicate a
> default route to the MR - I am not sure how this could work, never seen
> it in practice.

=3D> For  a good reason! You need to work out trust across domains.

Hesham

>=20
> Alex
>=20
>=20
>>=20
>> Hesham
>>=20
>>=20
>>=20
>>=20
>>=20
>=20
>=20