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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Sat, 17 September 2011 14:49 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 EF95821F8A35 for <mif@ietfa.amsl.com>; Sat, 17 Sep 2011 07:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.681
X-Spam-Level:
X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=0.918, 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 nCjp-IPzdVPB for <mif@ietfa.amsl.com>; Sat, 17 Sep 2011 07:49:09 -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 B9FAA21F886F for <mif@ietf.org>; Sat, 17 Sep 2011 07:49:08 -0700 (PDT)
Received: by wwf22 with SMTP id 22so4253951wwf.13 for <mif@ietf.org>; Sat, 17 Sep 2011 07:51:25 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=q9/JHRnq7WAToG6R1bLe/UCbVb+W5qavjDHxJbutXmI=; b=qGlGZOHXzK4z9xwAEONHG+ORayek9RyLJxvub9DJjgKHl312vcmWER//sY5xaYcTyw DS5e+tAhx2qW6Qqho0acBCb53NisUNnZBlhrCoQp9vkU8KTFKk9DTTm9LR5pmq71wITi 7bWkoYCSrhzQTtqKKMywuAk9vD4THYHHte0Sc=
Received: by 10.216.8.5 with SMTP id 5mr603821weq.68.1316271085802; Sat, 17 Sep 2011 07:51:25 -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 gd6sm17325439wbb.1.2011.09.17.07.51.24 (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 07:51:24 -0700 (PDT)
Message-ID: <4E74B3E6.6020701@gmail.com>
Date: Sat, 17 Sep 2011 16:51:18 +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: mif@ietf.org
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> <4E74B094.70001@gmail.com>
In-Reply-To: <4E74B094.70001@gmail.com>
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-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:49:10 -0000

(small typo below "MIF" instead of "MIP")

Alex

Le 17/09/2011 16:37, Alexandru Petrescu a écrit :
> 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
                             sorry I meant MIF

Alex

> 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
>>
>>
>
> _______________________________________________ mif mailing list
> mif@ietf.org https://www.ietf.org/mailman/listinfo/mif