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

Hui Deng <denghui02@gmail.com> Fri, 16 September 2011 05:40 UTC

Return-Path: <denghui02@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 F265A21F8B8C for <mif@ietfa.amsl.com>; Thu, 15 Sep 2011 22:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.494
X-Spam-Level:
X-Spam-Status: No, score=-103.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 rgSwMIVtloWO for <mif@ietfa.amsl.com>; Thu, 15 Sep 2011 22:40:15 -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 6D9C321F8B8A for <mif@ietf.org>; Thu, 15 Sep 2011 22:40:15 -0700 (PDT)
Received: by wwf22 with SMTP id 22so3162069wwf.13 for <mif@ietf.org>; Thu, 15 Sep 2011 22:42:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bNSQ+9/e+Re+MzREsDLtjjkCiHPL6/xTgUqgAAUxtPA=; b=KrHqnW78GphGQ+cWE1Xr+nZzMD0EIlCN5/cxnSfAmpRFIQCdIWlTzJw8ymk8uPfCDD CGU1WJ9I/PJiWMZi2eXzJxt9N9HxNMi8xQW9PZJ6JsJytOmlwTyrr2aL/XPnyu/JZXYf 1yCBjwzNKpZJ/6DBjxHFrGGzJTAVyPsNwPBX8=
MIME-Version: 1.0
Received: by 10.216.6.211 with SMTP id 61mr1912824wen.94.1316151747345; Thu, 15 Sep 2011 22:42:27 -0700 (PDT)
Received: by 10.216.186.13 with HTTP; Thu, 15 Sep 2011 22:42:27 -0700 (PDT)
In-Reply-To: <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.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>
Date: Fri, 16 Sep 2011 13:42:27 +0800
Message-ID: <CANF0JMCqi7TjJp6_okKznC_JmOv_FbBsuSvjquwkeSWn3dN7YQ@mail.gmail.com>
From: Hui Deng <denghui02@gmail.com>
To: teemu.savolainen@nokia.com
Content-Type: multipart/alternative; boundary=0016364c77655efdd104ad08759c
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: Fri, 16 Sep 2011 05:40:17 -0000

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.
So whether we would like to have different option for default route option
have to wait for future evolution opportunity.

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

Thanks for this detail discussion

-Hui

2011/9/14 <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
> https://www.ietf.org/mailman/listinfo/mif
>
>