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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Sat, 17 September 2011 14:35 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 37AC421F8B0E for <mif@ietfa.amsl.com>; Sat, 17 Sep 2011 07:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.593
X-Spam-Level:
X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=1.006, 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 zTcuQmev6K3i for <mif@ietfa.amsl.com>; Sat, 17 Sep 2011 07:35:03 -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 090E921F8B05 for <mif@ietf.org>; Sat, 17 Sep 2011 07:35:02 -0700 (PDT)
Received: by wwf22 with SMTP id 22so4247874wwf.13 for <mif@ietf.org>; Sat, 17 Sep 2011 07:37:20 -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=JcnLakLXaZlXZE5AvhsYJ84fsMxw/R2hzAXAcid/4jU=; b=tMaWHj9Wkjv4+QobWAHLfY68Cs4JJuuDy4OsJH/QeV+2wdEDKS/jD/CQJqj2JSqeSD TN6cVEMthCNXM5kpoNP7ynI2CxElb+gxOZZZy4wiKJ+WKxldIWgLbIvQZkVm7bGFdywa bZ9uc74DF5v0m6QMNj7ePWfUm3DxsOnFQCEpA=
Received: by 10.227.198.143 with SMTP id eo15mr682850wbb.2.1316270238206; Sat, 17 Sep 2011 07:37:18 -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 n39sm17262390wbp.7.2011.09.17.07.37.14 (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 07:37:16 -0700 (PDT)
Message-ID: <4E74B094.70001@gmail.com>
Date: Sat, 17 Sep 2011 16:37:08 +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: Hui Deng <denghui02@gmail.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> <CANF0JMCqi7TjJp6_okKznC_JmOv_FbBsuSvjquwkeSWn3dN7YQ@mail.gmail.com>
In-Reply-To: <CANF0JMCqi7TjJp6_okKznC_JmOv_FbBsuSvjquwkeSWn3dN7YQ@mail.gmail.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:35:04 -0000

Hello Hui,

Thank you for summarising the discussion.  Allow me to comment.

Le 16/09/2011 07:42, Hui Deng a écrit :
> Hello all Observations from the mailing list discussion about this
> draft is: the Scenario author proposed related to 3GPP is not valid
> based on current specification. 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.

Indeed currently 3GPP specs imply that SLAAC is used for default route
(and not DHCP, although DHCP is used for other aspects such as Prefix
Delegation and stateless parameters).

> So whether we would like to have different option for default route
> option have to wait for future evolution opportunity.

For 3GPP yes, maybe future evolution will involve default route with
DHCP, or maybe not.

> could I summarize the discussion like Whether we need to specify
> future purpose option at this moment?

If we take only current 3GPP, and only 3GPP overall, into account then
no, there is seemingly no need to specify a specific option for default
route.

On another hand.  A unique DHCP default route option that could apply to
non-3GPP, and maybe to future 3GPP, would be useful, considering that IP
runs over non-3GPP and over 3GPP in same manner.

Additionally, consider that the current MIP draft-ietf route option does
specify a means to offer default route as a particular case of normal
route.

Do you think it is possible to specify default route in draft-ietf-
route option (as currently it does) and still specify it in another way
in a future document?

(a default route is more special than a typical route.  It has a
number of other parameters that need to be present differently.  For
example: (1) the associated lifetime must be present in the ND default
router list (whereas the other routes don't), (2) MAC address is useful
(whereas for the other routes maybe the next hop may not be on the same
link).  Not to mention that a failing default route disconnects the Host
from a potentially large part of the Internet.)

Alex


> Thanks for this detail discussion -Hui
>
> 2011/9/14 <teemu.savolainen@nokia.com
> <mailto:teemu.savolainen@nokia.com>>
>
>> 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.
>
>> 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.
>
>> 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").
>
>> 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.
>
> Best regards,
>
> Teemu
>
> _______________________________________________ mif mailing list
> mif@ietf.org <mailto:mif@ietf.org>
> https://www.ietf.org/mailman/listinfo/mif
>
>