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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF95821F8A35 for <>; Sat, 17 Sep 2011 07:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.681
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nCjp-IPzdVPB for <>; Sat, 17 Sep 2011 07:49:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B9FAA21F886F for <>; Sat, 17 Sep 2011 07:49:08 -0700 (PDT)
Received: by wwf22 with SMTP id 22so4253951wwf.13 for <>; Sat, 17 Sep 2011 07:51:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id 5mr603821weq.68.1316271085802; Sat, 17 Sep 2011 07:51:25 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id gd6sm17325439wbb.1.2011. (version=SSLv3 cipher=OTHER); Sat, 17 Sep 2011 07:51:24 -0700 (PDT)
Message-ID: <>
Date: Sat, 17 Sep 2011 16:51:18 +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:49:10 -0000

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


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


> 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 <
>> <>>
>>> 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 mailing list