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

Alexandru Petrescu <> Wed, 14 September 2011 09:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D679021F8C60 for <>; Wed, 14 Sep 2011 02:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.389
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cw3N6tlBScvl for <>; Wed, 14 Sep 2011 02:13:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B038021F8B67 for <>; Wed, 14 Sep 2011 02:13:32 -0700 (PDT)
Received: from ( []) by (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 ( []) by (8.14.4/8.14.4) with ESMTP id p8E9Fb8s012287; Wed, 14 Sep 2011 11:15:37 +0200 (envelope-from
Received: from [] ([]) by (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: <>
Date: Wed, 14 Sep 2011 11:15:33 +0200
From: Alexandru Petrescu <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>, <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Sep 2011 09:13:33 -0000

Le 14/09/2011 08:08, 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?


> Best regards,
> Teemu