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

<> Wed, 14 September 2011 06:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E9C021F8CA2 for <>; Tue, 13 Sep 2011 23:08:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.679
X-Spam-Status: No, score=-2.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WTLow8MincKM for <>; Tue, 13 Sep 2011 23:08:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 774DA21F8C9F for <>; Tue, 13 Sep 2011 23:08:56 -0700 (PDT)
Received: from ( []) by (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8E6B1l8003616; Wed, 14 Sep 2011 09:11:02 +0300
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 09:10:38 +0300
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 14 Sep 2011 08:10:38 +0200
Received: from ([]) by ([]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 08:08:11 +0200
From: <>
To: <>
Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
Thread-Index: AQHMclXvmeatSbe770ilB6P1NUlbCpVL1DV4///urQCAAJ4CcA==
Date: Wed, 14 Sep 2011 06:08:11 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>, <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Company Confidential; Project=None;
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IuZuBXX/gTPnV8RRCmXgbNBLv+s+z8dze93E2y5N3eQswSwwwxgghs89TU1NiT1JcwoYrWJF1mZc/NrOJDhIyVOXH9EPAg712fNqHrpoDEsvuRlOS1hSiwqJBl/y+vrUMbNcSOiAMcMwyx351Sa6Z/IFSlHIhsBMoR40FyewYK3KCsi7Yxw68v+kP9DvNAmUZxPlsGYqXedFJIa5k15Bm0XdsxKvBnVcmuxqzTj4b4GDU4EfHLLHaH9VmYnqNFtQ0A==
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00DB_01CC72BD.D1FE4870"
MIME-Version: 1.0
X-OriginalArrivalTime: 14 Sep 2011 06:10:38.0796 (UTC) FILETIME=[064FB8C0:01CC72A5]
X-Nokia-AV: Clean
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: Wed, 14 Sep 2011 06:08:57 -0000

> 3G+ just as 3G is a market to end user label means of advertising more
> speed.  Similar to what WiFi is to 802.11.

Ok, so referring to 3GPP technologies I assume (not WiMAX for example).

> In some situations I experienced DHCPv6 may provide routing configuration
> via WiFi to a Windows Phone also connected on 3G+.  That routing
> configuration would need to tell the Windows Phone its IPv6 default route
> via the 3G+ access.

Do you mean the WiFi access would explicitly spell out 3G as the default
route for a node, or indirectly by the WiFi access telling it is low
priority default route (ref RFC4191) - and hence suggesting using some other
interfaces by default instead?

> Not sure about it.  I agree that PD may be in the 3GPP spec, but I am
> sure DHCPv6 is also specified by 3GPP as an alternative means to configure
> Client, alternate to IPv6 stateless autoconfig.

I am absolutely sure 3GPP as of today does not specify Stateful DHCPv6 as an
option to configure client's WAN interface addresses on cellular interface.
There is only Prefix Delegation in Release-10, but even in Rel-10 case
client's WAN interface address is always configured with SLAAC. (Ref 3GPP
23.060 and 23.401 for more details). I have to say I don't recall
immediately what 3GPP specs says about client configuration on trusted WLANs
(but I would except also only SLAAC there as well, otherwise things like
netext's logical interface might be even bigger challenges to get working).

> If 3GPP uses DHCPv6 to configure addresses to Clients then it may be used
> configure the default route as well, for more efficiency.

It is true that DHCPv6 can be used to configure additional information
(stateless DHCPv6). Hence yes, specific routes and even maybe default route
could be configured via DHCPv6... but I don't see why default route would
be, as the Router Advertisements used by SLAAC already provide default route

Best regards,