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

Alexandru Petrescu <> Sat, 17 September 2011 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C752121F886F for <>; Sat, 17 Sep 2011 07:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.639
X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id envHIc2S6HFT for <>; Sat, 17 Sep 2011 07:46:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B553921F87FC for <>; Sat, 17 Sep 2011 07:46:58 -0700 (PDT)
Received: by wwf22 with SMTP id 22so4253006wwf.13 for <>; Sat, 17 Sep 2011 07:49:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3lgQl657WHZfJ9p8Kkv6Syoi1RsYQSYcRgG0r9Y9Ssc=; b=fkOE17KYQWui/GlBrueFKRZ/4DVfJv1bWJa/Htk/PB6WlBOMd/j30ftnZlIbBcXmGt odXCVtrXFrXkmY5sp01u6PKNCYg0T17Z6L41jI5ONAY3qMFlVXQsXLU7zq7/N6LtWLYf eGgxgAeIVcKJJ1Gr00OgyxkoMCWOu0aYJJh8s=
Received: by with SMTP id q43mr659474wep.22.1316270955778; Sat, 17 Sep 2011 07:49:15 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id fr18sm17299852wbb.9.2011. (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 07:49:14 -0700 (PDT)
Message-ID: <>
Date: Sat, 17 Sep 2011 16:49:07 +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: Sat, 17 Sep 2011 14:46:59 -0000

Le 14/09/2011 12:26, a écrit :
>> 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).
> It refers to unique /64 prefix allocated for a PDN connection.

Hm.. I agree, it may be only me who confuses 3GPP "default prefix" with
"IP default route".

>> 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.
> Maybe the terminology is not clearest, but it means /64 prefix is
> advertised to the PDN connection. It is different topic then where
> the PDN GW got the addresses (statically allocated pool or by DHCPv6
> or whatever means).
> The "allocate" text probably comes from the view that it is P-t-P
> connection between UE and PDN GW and hence there is just single UE
> that "gets" the whole /64 "allocated" for its use.

If it is "allocated" for PtP connection for like-PPP then yes (although
I am not sure what the PPPv6 spec uses "allocate"), but that should be
"advertised" when used with RA.

Allocation of a prefix may happen in a number of ways like DHCP, manual,
router renumbering, but never RA.

>> 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.
> In my understanding the PDN GW can use DHCPv6 Prefix Delegation to
> get an address pool from where to "advertise" /64s for different UEs
> PDN connections.
> Additionally, in rel-10, also UE connected to PDN GW can use DHCPv6
> Prefix Delegation to get prefixes for advertisement on local area
> networks (such as "MiFi hotspot").

Hmmm... but I don't understand how a UE can be a Requesting Router at
the same time as the PDN-GW being a RR.

If the MiFi hotspot router requests a /64 prefix from a PDN-GW which has
only /64 prefixes then the number of routing entries in the PDN-GW may

Second, if the MiFi hotspot router is a RR then I suppose the PDN-GW
must be a delegating router for it (DR); the spec doesn't say, it says
just it's a RR. (if I read correctly).

>> 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".
> UE acts as requesting router in order to behave as a router. I
> understand not using term Mobile Router there, as the UE does not
> necessarily implement any "IP Mobility" solutions (e.g. DSMIP6). UE
> just acts as a 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.
> It could, but as of now it is not specified to be possible. 3GPP UE
> always uses SLAAC to number its cellular WAN interface (unnumbered
> model is not supported), including getting default route pointing to
> cellular interface. After SLAAC, UE acting as router MAY use DHCPv6
> PD to get prefixes for advertisement in "southbound" local area
> networks.
> Because SLAAC is always used and UE gets its IPv6 default route that
> way, there is currently no need to use DHCPv6 to specify default
> routes.
> As always, things may change in the future and that's one reason why
> I'm ok for defining default route option for DHCPv6.

Yes, me too,


> Best regards,
> Teemu