[ppml] "Recommended Practices" procedure

Stephen Sprunk stephen at sprunk.org
Wed Jun 28 20:20:40 EDT 2006

And here we find the slippery slope.

A large part of the justification for (and defense of) PIv6 addressing was 
that the PAv6 address space would be filtered at /32 and the PIv6 space 
would be filtered at /48.  If you want a /48 for multihoming, use the PIv6 
policy to get a block.  That's what it's for.  IIRC, it's free if you have 
PIv4 space (and still cheap if you don't).  Who in their right mind wouldn't 
want to do this?

We should not be advocating as a "recommended practice" punching holes in 
CIDR space under any circumstances.  If someone happens to find that it 
works, bully for them, but it's not supposed to and nobody should expect it 
to continue to work, much less be told it's the right thing to do.



Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

----- Original Message ----- 
From: "Stacy Taylor" <ipgoddess at gmail.com>
To: "Azinger, Marla" <marla_azinger at eli.net>
Cc: <ppml at arin.net>
Sent: Wednesday, June 28, 2006 14:59
Subject: Re: [ppml] "Recommended Practices" procedure

> Hi Everyone!
> I am saving my more eloquent reply for the IETF list, but I support
> Marla's call for codification of the new bit boundary.
> We made the policy, now we have to make the practice.
> /Stacy Taylor
> On 6/28/06, Azinger, Marla <marla_azinger at eli.net> wrote:
>> In response to Marc and his much needed document, I posted the following 
>> to the V6 ops WG discussion email list.
>> Hello-  I have reviewed Marc Blanchets document on IP V6 Routing Policy 
>> Guidelines Filename:  draft-ietf-v6ops-routing-guidelines-00.txt
>> I am concerned that the current draft does not include detailed routing 
>> guidelines for multihoming.  This document does not include guidelines 
>> for multihoming in the current V6 routing framework. V6 can be used 
>> identically like V4 to do multihoming and this is what I would like to do 
>> with V6.
>> I currently have customers asking for this ability and none of them wish 
>> to wait for solutions that may not be fully developed for a couple more 
>> years.  Also, my customers don't want to get PI space (even under the new 
>> V6 PI policy), so this means I need to give them a /48 and set up 
>> multihoming.  However, as all policy and practices sit right now, 
>> everyone filters on a /32.
>> I ask the V6 WG to create a "best practice for multihoming" that can be 
>> utilized today.  I ask that you please insert the solution to filter at 
>> /48 thus allowing "upstream providers" to provide multihoming to their 
>> customers.  This solution is needed to support providers creating V6 
>> networks and this solution can easily be added into Marc's "IP V6 Routing 
>> Policy Guidelines" document.
>> Thank you for your time
>> Marla Azinger
>> IP Engineering
>> Frontier Communications
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>> Marc Blanchet
>> Sent: Sunday, June 25, 2006 5:47 PM
>> To: ppml at arin.net
>> Subject: Re: [ppml] "Recommended Practices" procedure
>> Hi,
>>   I've submitted the first version of following document more than a
>> year ago as an individual submission to IETF. This came from earlier
>> discussion on a need of this kind of document for providers/
>> enterprises who start IPv6 deployment and also to obsolete the 6bone
>> routing guidelines document which people still were referring to.
>> The document has been accepted as v6ops wg document back in Dallas
>> (march 2006). Thomas Narten told me that I should look at arin-ppml
>> since there was some similarity with a arin-ppml thread.  Please have
>> a look at this not-yet-finished document.  It will be discussed
>> during IETF Montréal v6ops wg meeting.
>> BTW, the first version of it (under draft-blanchet-v6ops-...) had
>> words on prefix length to advertise but was  pushed back by one
>> person, so I remove it then. However, I do believe some wording
>> should be back there on prefix length and related issues. Please
>> comment to me or v6ops mailing list.
>> From: Internet-Drafts at ietf.org
>> Subject: I-D ACTION:draft-ietf-v6ops-routing-guidelines-00.txt
>> Date :  19 juin 2006 15:50:02 HAE
>> To :      i-d-announce at ietf.org
>> Cc :      v6ops at ops.ietf.org
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the IPv6 Operations Working Group of the
>> IETF.
>>         Title           : IPv6 Routing Policies Guidelines
>>         Author(s)       : M. Blanchet
>>         Filename        : draft-ietf-v6ops-routing-guidelines-00.txt
>>         Pages           : 8
>>         Date            : 2006-6-19
>>     Guidelines on how to manage IPv6 routes are needed for operators of
>>     networks, either providers or enterprises.  This document is a
>>     followup on RFC2772 work but for the production IPv6 Internet.
>>     RFC2772 becomes historic.
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-routing-
>> guidelines-00.txt
>> Marc.
>> Le 06-04-25 à 17:16, Thomas Narten a écrit :
>> > "Tony Li" <tli at tropos.com> writes:
>> >
>> >>> What I see frustrating here is that everyone agrees we need
>> >>> some sort of "internet community agreement" that addresses V6
>> >>> routing.  I hear alot of people asking for this, including
>> >>> myself.  Yet I dont hear any specific forum stepping forward
>> >>> to help facilitate this need.
>> >
>> >> What you're asking for is a "routing and addressing architecture".
>> >> Currently, it's really the purview of the IETF, except that they've
>> >> basically abdicated the role.  This creates a vacuum, which, as
>> >> you note
>> >> cries out to be filled.  There are multiple ways to make progress
>> >> here,
>> >> but my favorite is for ARIN to simply push the problem back to the
>> >> IETF
>> >> and insist on a sensible and scalable solution.
>> >
>> > I think that what people want has a lot to do with operations and
>> > operational practices, an area the IETF struggles with at times. There
>> > is v6ops WG in the IETF:
>> >
>> >     http://www.ietf.org/html.charters/v6ops-charter.html
>> >
>> > Reading the charter, my takes is that what I think I'm hearing people
>> > calling for (best practices on things like route filters, is
>> > deaggration allowed or not and under what conditions, etc., etc.)
>> > would be in-scope there.
>> >
>> > Maybe it's time to approach that group (and the ADs), see if there is
>> > a willingness to take on such work in the IETF. What they will want to
>> > see is a critical mass of folk agreeing on the work that needs to be
>> > done (i.e., what kind of document and what is in it) and assurance
>> > that there are enough volunteers to do the actual work.  Even if the
>> > work is "officially" housed there, there is no reason why the work
>> > couldn't also be discussed in the various RIR and operations
>> > groups.
>> >
>> > I think the IETF would be as good a place as any to try and do this
>> > work.  (And I'm willing to help make this happen if people think this
>> > is worth pursuing.)
>> >
>> > Thomas
>> >
>> > _______________________________________________
>> > PPML mailing list
>> > PPML at arin.net
>> > http://lists.arin.net/mailman/listinfo/ppml
>> =========
>> IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca
>> _______________________________________________
>> PPML mailing list
>> PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/ppml
>> _______________________________________________
>> PPML mailing list
>> PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/ppml
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml

More information about the ARIN-PPML mailing list