Re: Distribution of RFC 3484 address selection policies

Fred Baker <fred@cisco.com> Tue, 09 August 2005 16:32 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X29-0005Kg-CW; Tue, 09 Aug 2005 12:32:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X27-0005Jp-5S for ipv6@megatron.ietf.org; Tue, 09 Aug 2005 12:32:55 -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 MAA21297 for <ipv6@ietf.org>; Tue, 9 Aug 2005 12:32:52 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Xa2-0005mn-7I for ipv6@ietf.org; Tue, 09 Aug 2005 13:07:59 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 09 Aug 2005 09:32:44 -0700
X-IronPort-AV: i="3.96,92,1122879600"; d="scan'208"; a="330495703:sNHT33241164"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j79GWcoo011184; Tue, 9 Aug 2005 09:32:41 -0700 (PDT)
Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j79GTcUH023954; Tue, 9 Aug 2005 09:29:38 -0700
In-Reply-To: <42F813F3.7050005@eng.monash.edu.au>
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>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <ABD76F03-A396-4057-B3A8-3492A90A2920@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Date: Tue, 09 Aug 2005 09:32:35 -0700
To: greg.daley@eng.monash.edu.au
X-Mailer: Apple Mail (2.733)
DKIM-Signature: a=rsa-sha1; q=dns; l=1290; t=1123604979; x=1124037179; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Distribution=20of=20RFC=203484=20address=20selection=20policies| From:Fred=20Baker=20<fred@cisco.com>| Date:Tue,=209=20Aug=202005=2009=3A32=3A35=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=HazDFhhLdeSlC2uCjc0MfJrP+WeHwb4JF616ZcARAaijUu1AZQVHplNN06HwcQUZ0TINW4a3 w24h/5WPjcyac+//uHGGkOUdY/bfEYT3NiTId7MLwW04R4lg/55hE0wYrvWze/59MLmw0NEc8ju dMF1+I3mztYuhvqvTm7jIdoo=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
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
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

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.



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