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

<teemu.savolainen@nokia.com> Wed, 14 September 2011 10:24 UTC

Return-Path: <teemu.savolainen@nokia.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 7E01E21F8C47 for <mif@ietfa.amsl.com>; Wed, 14 Sep 2011 03:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.675
X-Spam-Level:
X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599]
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 VIeAHMoZhKak for <mif@ietfa.amsl.com>; Wed, 14 Sep 2011 03:24:13 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 81BF021F8C46 for <mif@ietf.org>; Wed, 14 Sep 2011 03:24:13 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EAQHNO020367; Wed, 14 Sep 2011 13:26:19 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 13:26:13 +0300
Received: from 008-AM1MMR1-001.mgdnok.nokia.com (65.54.30.56) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 12:26:13 +0200
Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 12:26:12 +0200
From: <teemu.savolainen@nokia.com>
To: <alexandru.petrescu@gmail.com>
Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
Thread-Index: AQHMclXvmeatSbe770ilB6P1NUlbCpVL1DV4///urQCAAJ4CcIAAFp+AgAAwtvA=
Date: Wed, 14 Sep 2011 10:26:11 +0000
Message-ID: <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>
In-Reply-To: <4E7070B5.6080900@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Company Confidential; Project=None;
x-titus-version: 3.3.8.1
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IuZuBXX/gTPnV8RRCmXgbNBLv+s+z8dze93E2y5N3eQswSwwwxgghs89TU1NiT1JcwoYrWJF1mZc/NrOJDhIyVOXH9EPAg712fNqHrpoDEsvuRlOS1hSiwqJBl/y+vrUMbNcSOiAMcMwyx351Sa6Z/IFSlHIhsBMoR40FyewYK3KCsi7Yxw68v+kP9DvNAmUZxPlsGYqXedFJIa5k15Bm0XdsxKvBnVcmuxqzTj4b4GDU4EfHLLHaH9VmYnqNFtQ0A==
x-originating-ip: [10.162.78.119]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_012F_01CC72E1.DE149280"
MIME-Version: 1.0
X-OriginalArrivalTime: 14 Sep 2011 10:26:13.0399 (UTC) FILETIME=[BA727270:01CC72C8]
X-Nokia-AV: Clean
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: Wed, 14 Sep 2011 10:24:14 -0000

> 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