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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Sat, 17 September 2011 14:46 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 C752121F886F for <mif@ietfa.amsl.com>; Sat, 17 Sep 2011 07:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.639
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id envHIc2S6HFT for <mif@ietfa.amsl.com>; Sat, 17 Sep 2011 07:46:59 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B553921F87FC for <mif@ietf.org>; Sat, 17 Sep 2011 07:46:58 -0700 (PDT)
Received: by wwf22 with SMTP id 22so4253006wwf.13 for <mif@ietf.org>; Sat, 17 Sep 2011 07:49:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.216.221.65 with SMTP id q43mr659474wep.22.1316270955778; Sat, 17 Sep 2011 07:49:15 -0700 (PDT)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id fr18sm17299852wbb.9.2011.09.17.07.49.14 (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 07:49:14 -0700 (PDT)
Message-ID: <4E74B363.7000402@gmail.com>
Date: Sat, 17 Sep 2011 16:49:07 +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> <4E7070B5.6080900@gmail.com> <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.nokia.com>
In-Reply-To: <916CE6CF87173740BC8A2CE44309696202573B89@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: Sat, 17 Sep 2011 14:46:59 -0000

Le 14/09/2011 12:26, teemu.savolainen@nokia.com 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
double.

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,

Alex

>
> Best regards,
>
> Teemu