IETF Logo Mail Archive

Re: [mif] Route option for DHCPv6 - next steps?

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 04 April 2012 16:28 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 19E2B21F8722 for <mif@ietfa.amsl.com>; Wed, 4 Apr 2012 09:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 Ddx3UVv2-+pr for <mif@ietfa.amsl.com>; Wed, 4 Apr 2012 09:28:50 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2C221F8720 for <mif@ietf.org>; Wed, 4 Apr 2012 09:28:50 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q34GSmRv016265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <mif@ietf.org>; Wed, 4 Apr 2012 18:28:48 +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 q34GSmvF018396 for <mif@ietf.org>; Wed, 4 Apr 2012 18:28:48 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q34GSjdQ023724 for <mif@ietf.org>; Wed, 4 Apr 2012 18:28:48 +0200
Message-ID: <4F7C76BD.1020003@gmail.com>
Date: Wed, 04 Apr 2012 18:28:45 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: mif@ietf.org
References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <DD1241D5-B794-49C3-A3A2-4294248DDD10@gmail.com> <4F719186.3060507@gmail.com> <CAKD1Yr3tSoDPcheriWdZEeKyhqpDANCP7Co0wVVqK5+mXc7e5A@mail.gmail.com> <4F72CD22.3080604@gmail.com> <CAKD1Yr3RUUthiawKrmxjSNqzEbJcOLpHvDGb9XLtdiU-tfEYyw@mail.gmail.com> <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com> <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com> <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D47A7@mbx-01.win.nominum.com> <CAAedzxpMtu_7jWuES5=EKK4oqsFsvt4tPpu0J4fy3Uz4-TEt6Q@mail.gmail.com> <905A7517-B173-48FE-9E7A-DEDC709E7B83@nominum.com>
In-Reply-To: <905A7517-B173-48FE-9E7A-DEDC709E7B83@nominum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [mif] Route option for DHCPv6 - next steps?
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, 04 Apr 2012 16:28:51 -0000

Le 04/04/2012 17:52, Ted Lemon a écrit :
> On Apr 3, 2012, at 9:53 PM, Erik Kline <ek@google.com
> <mailto:ek@google.com>> wrote:
>> Is RADIUS suitable for this? At one point it was the general
>> non-client provisioning protocol of choice, I thought. I have not
>> been following any of the evolving diameter work, but would a RADIUS
>> option suffice?
>
> RADIUS could potentially be used for configuring unicast RAs on routers.
> But since we don't have a clear description of the use cases we're
> trying to address, it's hard to evaluate.

I am not sure I understand between which entities would RADIUS be used 
and to configure what in particular?

In the case of connecting a mobile router (a router that moves) to an 
LTE infrastructure, I am not sure where would RADIUS fit?

Alex

>
>
>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif

v2.23.0 | Report a Bug | By Email