Re: Distribution of RFC 3484 address selection policies

Greg Daley <greg.daley@eng.monash.edu.au> Wed, 10 August 2005 03:51 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2hcn-0000yK-Q2; Tue, 09 Aug 2005 23:51:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2hcm-0000yF-1a for ipv6@megatron.ietf.org; Tue, 09 Aug 2005 23:51:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03185 for <ipv6@ietf.org>; Tue, 9 Aug 2005 23:51:25 -0400 (EDT)
Received: from alpha6.its.monash.edu.au ([130.194.1.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2iAn-0008Gb-1j for ipv6@ietf.org; Wed, 10 Aug 2005 00:26:38 -0400
Received: from larry.its.monash.edu.au ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #31112) with ESMTP id <01LRNYR3JW6C8X1JGL@vaxc.its.monash.edu.au> for ipv6@ietf.org; Wed, 10 Aug 2005 13:51:21 +1000
Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8B6D18000D; Wed, 10 Aug 2005 13:51:20 +1000 (EST)
Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by larry.its.monash.edu.au (Postfix) with ESMTP id 690773C010; Wed, 10 Aug 2005 13:51:20 +1000 (EST)
Date: Wed, 10 Aug 2005 13:51:19 +1000
From: Greg Daley <greg.daley@eng.monash.edu.au>
In-reply-to: <ABD76F03-A396-4057-B3A8-3492A90A2920@cisco.com>
To: Fred Baker <fred@cisco.com>
Message-id: <42F979B7.1020005@eng.monash.edu.au>
Organization: Monash University
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"; format="flowed"
Content-transfer-encoding: 7bit
X-Accept-Language: en, en-us
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
References: <20050808194427.GB21924@storhaugen.uninett.no> <02BE40DE-2380-4C6E-8E12-8CB6C1CDB341@cisco.com> <E73B54E1-66F7-4E59-AEE0-D497323431E6@ecs.soton.ac.uk> <42F7F18E.2000102@eng.monash.edu.au> <AB1F5381-5D2C-431C-8DC7-719FA14BF0D9@cisco.com> <42F813F3.7050005@eng.monash.edu.au> <ABD76F03-A396-4057-B3A8-3492A90A2920@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: Re: Distribution of RFC 3484 address selection policies
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: greg.daley@eng.monash.edu.au
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Hi Fred.

Fred Baker wrote:
> On Aug 8, 2005, at 7:24 PM, Greg Daley wrote:
> 
>> I'm not sure anyone is doing it, but renumbering is applicable  there 
>> as a means of providing information about which prefixes are  valid.
> 
> 
> One of the outcomes of the v6ops WG last week was the observation  that 
> the Router Renumbering Protocol is not widely implemented, and  when 
> renumbering-in-anger persuant to
> 
>   http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering- 
> procedure-05.txt
>   "Procedures for Renumbering an IPv6 Network without a Flag Day",  Fred 
> Baker,
>   18-Mar-05, <draft-ietf-v6ops-renumbering-procedure-05.txt>
> 
> was tested by the 6net folks, it was found wanting in a variety of  
> ways. Basically, it made the special case where you want to  distribute 
> a new aggregated prefix and maintain the same subnet  number 
> distribution (such as "I have changed upstream provider")  pretty 
> simple, but didn't cover any of the other cases in which one  might want 
> to renumber, and didn't handle any of the nuances like  making sure this 
> also happened in route maps, aggregation filters,  qos classification 
> filters, etc.
> 
> As the discussion proceeded, we basically decided that renumbering  (and 
> more generally number distribution and number use policy) was  the 
> province of the network management folks, perhaps netconf. They  need to 
> decide how to manage a network, and if a protocol like RRP is  part of 
> that, specify a set of requirements for it. RRP at minimum  needs work, 
> and I would suggest it be declared "historic" and  replaced with a new 
> protocol if such a definition happens.

Sure.   I guess that if automated generation of policy mappings for
source address selection are required then it would be useful to
work on this in concert with the main thrust of network management.

Moving RRP to Historic may leave questions unanswered in peoples'
heads regarding the ISP change scenario, but I really think moving the
focus to SHIM6 (which provides host-to-host survivability of
renumbering events) may actually be the better course (Shim6 people can
take aim now).

What's reasonable here with regard to address usage is to provide
indications of the network's perception of differences between addresses
to hosts.   The actual task of managing the network's perception
isn't really any different in DHCPv6 or Router Discovery (it's either
automated or manual).  The hosts receiving the default policy aren't
ever aware of the mechanism used.

As you mention, RRP may not be a valid way to do this configuration
today (or in future), but config files, SNMP and misuses of RADIUS
(not actually recommended) may be.

Greg

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------