Re: [mif] (long, 3GPP) Comments on draft-mouton-mif-dhcpv6-drlo-00

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 30 September 2011 16:34 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 AD44C21F8B67 for <mif@ietfa.amsl.com>; Fri, 30 Sep 2011 09:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.437
X-Spam-Level:
X-Spam-Status: No, score=-4.437 tagged_above=-999 required=5 tests=[AWL=1.812, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 CtjzSau+Tkh6 for <mif@ietfa.amsl.com>; Fri, 30 Sep 2011 09:34:55 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id A113F21F8B5E for <mif@ietf.org>; Fri, 30 Sep 2011 09:34:54 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p8UGblNQ015470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Sep 2011 18:37:47 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8UGbkrw015104; Fri, 30 Sep 2011 18:37:46 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8UGbham017551; Fri, 30 Sep 2011 18:37:46 +0200
Message-ID: <4E85F057.8060603@gmail.com>
Date: Fri, 30 Sep 2011 18:37:43 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: teemu.savolainen@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>
In-Reply-To: <916CE6CF87173740BC8A2CE44309696202573B89@008-AM1MPN1-032.mgdnok.nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: mif@ietf.org
Subject: Re: [mif] (long, 3GPP) 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, 30 Sep 2011 16:34:56 -0000

This is about text in document 23401-a50 V10.5.0 of 3GPP 2011-09,
section 5.3.1.2.6.

Le 14/09/2011 12:26, teemu.savolainen@nokia.com a écrit :
>> 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.

Teemu, let me bring back this text again.

"unique" is not the same as "default".  Each one such word has a
specific meaning.  Each is implemented differently.

>> 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.

I can hear the similar use of 'allocate' in PtP ppp rfc.

But
The use of the word "allocate" in this doc is ambiguous.

There exist IETF docs SLAAC non-PPP methods which _do_ allocate
prefixes, this makes think an MTC-inclined reader to confuse even further.

The terminology in this spec should be clarified to say "advertized"
instead of "allocated".

The same with section's use of "assigned".

>> 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.

An "address pool" (a set of distinct /128 addresses) is not the same as
a "prefix".  Prefix Delegation can not be used to obtain address pools,
but prefixes.

> 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").

How?

>> 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.

Ok that not implementing NEMO then not MR.

But an UE which is a Router (DHC Requesting Router, forwards between 3g
and wifi ifaces, etc.) should be called something more powerful than
just "User Equipment".  It's something that offers Internet access to
other User Equipments.

>> 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.

Maybe better could be done.  An implementer optimizing the amount of
complexity on terminal would use just DHCPv6 (if available) for
address/prefix/defaultroute, (not RA) - easier to administer in some cases.

> 3GPP UE always uses SLAAC to number its cellular WAN interface
> (unnumbered model is not supported), including getting default route
>  pointing to cellular interface.

Well, in IPv4 some 3G+ implementations, the driver setting up the
interface does not forcefully assign neither address nor default route
on that in interface - it just tells them so some other smart middleware
can.

Recent ISC DHCPv6 Client implementations do the same on Ethernet: they
don't forcefully assign addresses/prefixes/dr that are extracted from
the received DHCP messages... they just tell them so other smart
middleware can assign it.

In a MIF device one would't want the network to forcefully impose where
the default route should go.

> After SLAAC, UE acting as router MAY use DHCPv6 PD to get prefixes
> for advertisement in "southbound" local area networks.

SLAAC could be used _only_ to do some things which DHCP doesn't: MTU,
HopLimit, on-link or off/link prefix - that's about it.  No need to do
more than that when DHCP can (address, default route, prefix for further
advertisement, dns, more).

This makes it easier to control the assignment of prefixes and routes in
central DHCP conf files in the network.

> 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.

It is doubtful in a MIF terminal to have the network impose the default
one way or another.  It is good to have as much alternatives as possible
for the default route: SLAAC, DHCP, more.

> As always, things may change in the future and that's one reason why
>  I'm ok for defining default route option for DHCPv6.

I agree with you.

Section 5.3.1.2.6 of 3GPP doc 23401-a50 text which bothers:
> Optionally a single network prefix shorter than the default /64
> prefix may be assigned to a PDN connection.

Ok, so a /56 is assigned to a PDN connection.

> In this case, the /64 default prefix used for IPv6 stateless
> autoconfiguration will be allocated from this network prefix;

Ok, so a /64 is extracted from that /56, and used by SLAAC, supposedly
advertised to the PDN connection.  But earlier, the _/56_ was 'assigned'
to that PDN connection.  Did the text really mean that the /56 was
'assigned' to a PDN connection?  Or was it just preventive setting aside
of a /56 for a PDN connection yet to materialize, in the same way as the
'provisioned' used later in the text?  Better just use one.

> the remaining address space from the network prefix can be delegated
> to the PDN connection using prefix delegation

Ok, it is about the remaining address space left after the /56 was
extracted a /64.   I believe that to be 254 other /64s or so.

Does it mean that the UE may do DHCP Prefix Delegation to request these
prefixes?  If yes, then UE will not use them on the PDN connection, but
on another connection (you name it 'southbound' elsewhere).

In this sense this remaining address space is _not_ delegated to the PDN
connection but to the UE to use on other connections.

> after the default bearer establishment

Again - what is 'default' in 'default bearer establishment' - is it
'default bearer' or 'default establishment'?  In both cases I see it has
no relationship with 'default router' nor 'default route'.

> and IPv6 prefix allocation via IPv6 stateless address
> autoconfiguration as defined in clause 5.3.1.2.2.

IPv6 stateless address autoconfiguration does not do IPv6 prefix
allocation.  This sentence is purely wrong and should be corrected.

> When PLMN based parameter configuration is used, the PDN GW provides
> the requested IPv6 prefix from a locally provisioned pool.

Is this 'provisioned' pool containing a set of prefixes or of addresses?

Is that 'provisioned' word the same as the initial 'assigned' /56 above
("Optionally a single network prefix shorter than the default /64 prefix
may be _assigned_ to a PDN connection").

> When external PDN based IPv6 prefix allocation is used, the PDN GW
> obtains the prefix from the external PDN. [*]

How does the PDN GW obtain the prefix from the external PDN?  Is it by
using DHCPv6 Prefix Delegation?  I am asking because there exist no
other way to automatically (no human intervention) request and obtain
prefixes.

I assume DHCPv6-PD is meant by the above.  IF so it should say so.

> Note: Allocation of IPv6 prefixes with flexible prefix length can
> leverage e.g. local configuration on the PDN GW or interaction with
> the AAA server.

I do not quite understand this.

In general, I agree a network should offer a router more than just a
/64, in particular if that router had Ethernet interfaces (no PPP) and
used SLAAC (not DHCP).  Break any of these two conditions and one is
free to use /64 to end user.

E.g. use DHCP with Ethernet, or use SLAAC with PPP, or use DHCP with PPP
- for each those there's no need to allocate shorter-than-/64 prefixes
to UE-which-are-Routers.

I also agree that local configuration is easier to do for operator if
centralized conf files are used, with DHCP, rather than distributed
files with RA.

But 'IPv6 prefixes with flexible length' doesn't really mean much to me
(no offence :-)

SLAAC doesn't allocate prefixes, so this statement can only request DHCP.

DHCP-PD already allocates prefixes with any length.

I do not understand why this Note is there.

> The address space provided is maintained as an IPv6 address space
                     'provided'? (not 'provisioned', not 'assigned')
> pool available to the PDN connection for DHCPv6 IPv6 prefix requests
                         ^^^^^^^^^^^^^^
This should rather be UE-Router, rather than 'PDN connection', because
the PDN connection does not do any prefix request (the UE-Router does).
  Moreover, the prefixes delegated by DHCP this way are not used at all
on that PDN connection.

> with the exclusion of the IPv6 prefix that is allocated to the PDN
> connection during default bearer establishment as defined in clause
> 5.3.1.2.2.

So, the /64 is 'allocated' to the PDN connection and the other 254 /64s
are 'provided' to the same PDN connection?  This is unclear.

In implementation, the way these prefixes are 'assigned', 'requested',
'advertised' have very precise meanings, and they relate to the ways the
routing tables are constructed (triplets of "prefix-nexthop-interface").
  Rather use these terms from implementation if one wants to avoid
confusion and be understandable.

> The total IPv6 address space available for the PDN connection (UE
> default bearer prefix

'default bearer prefix'?  Earlier it was 'default bearer establishment'.
  So 'default' relates to 'default bearer', not 'default prefix'.  But
before that occurence, on the first phrase, it said 'default /64 prefix'!

Overall we have:
default bearer establishment
default bearer prefix
default /64 prefix

None appears in RFCs I look at.

> and UE PDN connection IPv6 address space pool) shall be possible to
> aggregate into one IPv6 prefix that will represent all IPv6 addresses
> that the UE may use.

What does it mean to 'aggregate'?

Earlier it said "Optionally a single network prefix shorter than the
default /64 prefix may be assigned to a PDN connection [...] the /64
default prefix will be allocated from this network prefix; the remaining
address space from the network prefix can be delegated"

I believe this aggregation happens all the time, no need to request it
with a "shall be possible". It is always automatically possible given
the initial 'shorter prefix, remaining prefix'.

Besides, I believe that if one tries to really understand that word
'aggregation' one may have surprises.

For example, a UE-Router with two 'southbound' interfaces and one 3GPP
interface may need to request two prefixes: one for each southbound
interface.  These two prefixes don't necessarily need to be 'aggregated'
into each other (differ at the 4th leftmost bit!) and they don't even
need to be aggregated with the prefix of the address of the 3GPP
interface (differ at the 4th leftmost bit again).

In one way, all distinct prefixes are aggregated into one another
because they have the same 3 leftmost bit.  In another way two distinct
/64 prefixes can never be aggregated one into another because they
differ at the leftmost 65th bit.

> The UE uses DHCPv6 to request additional IPv6 prefixes (i.e.
> prefixes in addition to the default prefix)

Again - what is a 'default prefix'?  It doesn't appear in relevant RFCs.

> The UE acts as a "Requesting Router"
[...]
> The PDN GW acts as the DHCP server and fulfils the role of a
> "Delegating Router"

But could PDN GW act as a DHCP Relay as well?  It is useful option for
deployments to use a multiplicity of Relays (one per PDN GW?) and one
central DHCP Server rather than a DHCP Server for each PDN GW.

Besides, if we assume that PDN GW obtains its prefixes also using
DHCPv6-PD (implied by the earlier 'PDN GW  obtains the prefix from the
external PDN'), is PDN GW be a Requesting Router as well?

> The PDN GW delegates a prefix excluding the default prefix

How does it 'exclude'?  draft pd-exclude doesn't tell how.

There are many ways to 'exclude' especially when it's not told how.

Excluding a /64 from a /48 results in several prefix_es_ and hence the
above statement is wrong to say PDN GW delegates _a_ prefix.

Given 2001:db8:1:1::/64
and   2001:db8:1::/48,
the 'exclusion' of the former from the latter may result in:

2001:db8:1:0000::/64
2001:db8:1:0002::/64
2001:db8:1:0003::/64
...
2001:db8:1:ffff::/64

or it may result in:
2001:db8:1::/63 if we ignore 0.

> Prefix exclusion procedures shall follow
> draft-ietf-dhc-pd-exclude-00

Sorry it doesn't tell to my reading.

That draft only tells:
> the requesting router has earlier been assigned a
> 2001:db8:dead:beef::/64 prefix by the delegating router, and the
> delegated prefix in the OPTION_IAPREFIX is 2001:db8:dead:bee0::/59.
> In this case, 2001:db8: dead:beef::/64 is a valid prefix to be used
> in the OPTION_PD_EXCLUDE option.

Certainly yes, 2001:db8:dead:beef::/64 is a valid prefix to be used in
the EXCLUDE option, because 'the RR has earlier been assigned a
2001:db8:dead:beef::/64' - it's said right above.  This is always true.

But, what an implementer is interested in is: what prefixes (or single
prefix?) result when 'excluding' 2001:db8:dead:beef::/64 from
2001:db8:dead:bee0::/59?  This draft doesn't tell.

Friendly yours,

Alex

>
> Best regards,
>
> Teemu