Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 14 September 2011 09:13 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D679021F8C60 for <mif@ietfa.amsl.com>; Wed, 14 Sep 2011 02:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.389
X-Spam-Level:
X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cw3N6tlBScvl for <mif@ietfa.amsl.com>; Wed, 14 Sep 2011 02:13:33 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id B038021F8B67 for <mif@ietf.org>; Wed, 14 Sep 2011 02:13:32 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p8E9Fer9017648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Sep 2011 11:15:40 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8E9Fb8s012287; Wed, 14 Sep 2011 11:15:37 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8E9FXaU027532; Wed, 14 Sep 2011 11:15:37 +0200
Message-ID: <4E7070B5.6080900@gmail.com>
Date: Wed, 14 Sep 2011 11:15:33 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: teemu.savolainen@nokia.com
References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <CFDF82EE-052B-4A61-AE1B-152337822B6E@nominum.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <B987CA14-569C-428C-8D8A-C97A0E42EF48@nominum.com> <4E6FA64E.7020801@gmail.com> <82337D11-0A39-4A10-AA0E-1E81B09DBA4F@nominum.com> <4E6FACF6.5000007@viagenie.ca>, <4E6FC0AE.5000108@gmail.com> <916CE6CF87173740BC8A2CE4430969620257327E@008-AM1MPN1-032.mgdnok.nokia.com> <4E6FD930.7040401@gmail.com> <916CE6CF87173740BC8A2CE443096962025734A7@008-AM1MPN1-032.mgdnok.nokia.com>
In-Reply-To: <916CE6CF87173740BC8A2CE443096962025734A7@008-AM1MPN1-032.mgdnok.nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: mif@ietf.org
Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Sep 2011 09:13:33 -0000

Le 14/09/2011 08:08, teemu.savolainen@nokia.com a écrit :
>> 3G+ just as 3G is a market to end user label means of advertising
>> more speed.  Similar to what WiFi is to 802.11.
>
> Ok, so referring to 3GPP technologies I assume (not WiMAX for
> example).
>
>> In some situations I experienced DHCPv6 may provide routing
>> configuration via WiFi to a Windows Phone also connected on 3G+.
>> That routing configuration would need to tell the Windows Phone its
>> IPv6 default route via the 3G+ access.
>
> Do you mean the WiFi access would explicitly spell out 3G as the
> default route for a node, or indirectly by the WiFi access telling it
> is low priority default route (ref RFC4191) - and hence suggesting
> using some other interfaces by default instead?

YEs, in this way.

>> Not sure about it.  I agree that PD may be in the 3GPP spec, but I
>>  am almost sure DHCPv6 is also specified by 3GPP as an alternative
>>  means to configure a Client, alternate to IPv6 stateless
>> autoconfig.
>
> I am absolutely sure 3GPP as of today does not specify Stateful
> DHCPv6 as an option to configure client's WAN interface addresses on
>  cellular interface.

Hmm... in a sense I agree with you - currently in 3GPP specs 23401-a40
and 24301-a30 there is DHCPv6 only as PD and as Stateless DHCPv6, not as
stateful DHCPv6.  I have limited knowledge of these documents.

However, I have remarks.

In many places the term "default prefix" is used.  For example like this:
> IPv6 Prefix Delegation via DHCPv6 Optionally a single network prefix
> shorter than the default /64 prefix may be assigned to a PDN
> connection. In this case, the /64 default prefix used for IPv6
> stateless autoconfiguration will be allocated from this network
> prefix

This is difficult to understand because SLAAC has no "default prefix"
(grep rfc4862).

24.301-a30 says often GW allocates via RA like this:
> The PDN GW allocates a globally unique /64 IPv6 prefix via Router
> Advertisement to a given UE.

But this is so difficult for me to understand because RA RFC text never
says an RA "allocates" some prefix.  This allocation action is typically
a DHCP action, not RA.  The RA simply advertises an allocation already
done by DHCP or administrator or ospf.

In a number of other places the 3GPP spec is incoherent with respect to
who is the "Requesting Router" - the UE or the PDN GW (at a moment the
GW is a DHCP client requesting a prefix, at another moment it is the UE
being a requesting router).  For me it is not clear how a Requesting
Router below another Requesting Router can work.

Another remark is that Stateless DHCP _could_ be used to communicate
default routes to Clients because the data about default route is not
state which should be maintained at server.  It is possible for a 3G
client to simply receive a DHCP Advertise which may be empty and still
set a correct default route.

> There is only Prefix Delegation in Release-10, but even in Rel-10
> case client's WAN interface address is always configured with SLAAC.

Hmmm... I would not rely on 3GPP specs to make a terminal run ok on
WiFi.  I would guess a 3GPP spec about WiFi is just FYI(?) no offense.

------------

May I try to interpret further the DHCP text in 3GPP specs, IMHO.

It is unclear to me why the 23401 3GPP spec says that "The UE acts as a
"Requesting Router"" requesting a Prefix.  An entire Prefix (in addition
to the onlink prefixes) is useful only if that UE is a Mobile Router,
giving addresses further to some LFNs.  Otherwise it is not clear why do
Prefix Delegation to a UE Requesting Router.  Yet the spec never says
"Mobile Router".

If it makes sense for this UE to actually be a MR, and to run DHCPv6-PD
then it could make sense to use DHCPv6 for address and default route
configuration as well, instead of DHCPv6+SLAAC - simply the number of
messages is reduced, and configuration of addresses/routes/prefixes is
centralizely managed.

But this is just personal opinion, motivating the use of DHCPv6 for
default route in 3GPP.

> (Ref 3GPP 23.060 and 23.401 for more details).

Thanks for ref 23.060.

> I have to say I don't recall immediately what 3GPP specs says about
> client configuration on trusted WLANs (but I would except also only
> SLAAC there as well, otherwise things like netext's logical interface
> might be even bigger challenges to get working).

Hmmm... in a sense the netext logical interface is to me still unclear.

>> If 3GPP uses DHCPv6 to configure addresses to Clients then it may
>> be used to configure the default route as well, for more
>> efficiency.
>
> It is true that DHCPv6 can be used to configure additional
> information (stateless DHCPv6). Hence yes, specific routes and even
> maybe default route could be configured via DHCPv6... but I don't see
> why default route would be, as the Router Advertisements used by
> SLAAC already provide default route information.

_If_ the UE is a Mobile Router and uses DHCPv6-PD to request its prefix
(DHCPv6-PD is the only way it can get a prefix for its LFNs) then it may
make sense to use same DHCP software to request routes and addresses.

What do you think?

Alex

>
> Best regards,
>
> Teemu