IETF Logo Mail Archive

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

Sri Gundavelli <sgundave@cisco.com> Mon, 09 April 2012 23:01 UTC

Return-Path: <sgundave@cisco.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 EC7B921F87F3 for <mif@ietfa.amsl.com>; Mon, 9 Apr 2012 16:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 zV2CYuQ6773w for <mif@ietfa.amsl.com>; Mon, 9 Apr 2012 16:01:06 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9E021F87CD for <mif@ietf.org>; Mon, 9 Apr 2012 16:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1204; q=dns/txt; s=iport; t=1334012466; x=1335222066; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=M38i5aA7dHajpan0CVEdVheJUHRNWHJizD0WholMCbY=; b=Bk/JEPjPg47Ol66TP0cq+tC6mEmYQODtp4xGxTQnKGzyLR5EQafnxpjD JjftWnq8r1pYuzF5daVQeDefh924ORhxlXjQpe0naoaItW25wrOmZuFKh 13v5UqLkIdJcgDgc+MnH6UrMo8o4C/oWNRhTIYtBlHgtSxv20L122kpj1 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAD5pg0+rRDoI/2dsb2JhbABCuWCBB4IJAQEBAwESAScCATwSAQhnNgEBBAENBSKHXgMGBAyeWJZGDYFrii2GPgSIWo0SgRGKKIMUgWmDBw
X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208";a="36651867"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 09 Apr 2012 23:01:06 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q39N167S029393; Mon, 9 Apr 2012 23:01:06 GMT
Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 16:01:06 -0700
Received: from 10.32.246.210 ([10.32.246.210]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 9 Apr 2012 23:01:05 +0000
User-Agent: Microsoft-Entourage/12.32.0.111121
Date: Mon, 09 Apr 2012 16:01:01 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: jouni korhonen <jouni.nospam@gmail.com>, Erik Kline <ek@google.com>
Message-ID: <CBA8B83D.4245E%sgundave@cisco.com>
Thread-Topic: [mif] Route option for DHCPv6 - next steps?
Thread-Index: Ac0WpKHh8x61NiRYyEuiEWaGtqPJMA==
In-Reply-To: <97D4F82A-6321-403F-9097-F7B48601DCD5@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 09 Apr 2012 23:01:06.0088 (UTC) FILETIME=[A4EA5280:01CD16A4]
Cc: "mif@ietf.org" <mif@ietf.org>
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: Mon, 09 Apr 2012 23:01:07 -0000

Response to one specific comment; ignoring/not taking any stand on the rest
of the DHCP/RA discussion...


On 4/5/12 1:27 PM, "jouni korhonen" <jouni.nospam@gmail.com> wrote:

> 
> RADEXT is working on
> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-06
> which adds attributes for RFC4191 use, for example. That is then also
> implicitly
> available for Diameter.
> 
> Assuming unicast RA would be doable using just RFC6085, then there should not
> be much, if anything, to do protocol wise. The router that gets provisioned
> per
> host via AAA knows the l2-l3 mapping already.. and the AAA server also learns
> it. For dynamic changes of routes, AAA server can use e.g. l2 or l3 addresses
> for a session identification when it sends a change of authorization..
>

Yes. The router can learn the L2 to L3 mapping based on the Router
Solicitations/Attach Triggers of the host. It can also learn this mapping by
being in the Authentication path (supporting Proxy RADIUS), or by means of
handling RADIUS triggers. Now, with respect to unicast RA transmission, the
clarified L3 multicast/L2 unicast semantic defined in 6085 does allow
unicast RA transmission.


Sri

v2.23.0 | Report a Bug | By Email