Subject: RE: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt

From: "Durand, Alain" <[email-masked]>
Date: Sat, 17 Sep 2005 21:01:16 -0400

Marc,
 
How does this differ from RFC2772? Do you feel a need to update it?
 
---------------------------------
Alain Durand
Director - IPv6 architect

________________________________

From: [email-masked] on behalf of Marc Blanchet
Sent: Sat 9/17/2005 7:32 AM
To: [email-masked]
Subject: Fwd: I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt 

Hi,
  was discussed many times in many forums: what ipv6 routes to 
filter. operational.
First cut. Please comment.  I know one debatable issue... that will 
be raised!

Marc.

Début du message réexpédié :

> De : [email-masked]
> Date : 16 septembre 2005 15:50:02 HAE
> À : [email-masked]
> Objet : I-D ACTION:draft-blanchet-v6ops-routing-guidelines-00.txt
> Répondre à : [email-masked]
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>
>     Title        : IPv6 Routing Policies Guidelines
>     Author(s)    : M. Blanchet
>     Filename    : draft-blanchet-v6ops-routing-guidelines-00.txt
>     Pages        : 7
>     Date        : 2005-9-16
>
>    Guidelines on how to handle IPv6 routes are needed for operators of
>    networks, either providers or enterprises.  This document is a
>    followup of RFC2772 work but for the production IPv6 Internet.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-blanchet-v6ops-routing-
> guidelines-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body 
> of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>     "get draft-blanchet-v6ops-routing-guidelines-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>     [email-masked].
> In the body type:
>     "FILE /internet-drafts/draft-blanchet-v6ops-routing-
> guidelines-00.txt".
>
> NOTE:    The mail server at ietf.org can return the document in
>     MIME-encoded form by using the "mpack" utility.  To use this
>     feature, insert the command "ENCODING mime" before the "FILE"
>     command.  To decode the response(s), you will need "munpack" or
>     a MIME-compliant mail reader.  Different MIME-compliant mail 
> readers
>     exhibit different behavior, especially when dealing with
>     "multipart" MIME messages (i.e. documents which have been split
>     up into multiple messages), so check your local documentation on
>     how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>

---

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Sep 2005 09:10:01 +0300 (EEST)

Note: the next rev of this doc (if there is one) should maybe be 
forwarded for comments on the [email-masked] list.

> How does this differ from RFC2772? Do you feel a need to update it?

RFC2772 includes guidelines for *6bone*.  This is offering guidelines 
for more than that.  In that light, if we feel the IETF is the right 
place to give guidance on this, updating is certainly needed.

As already noted in the IETF/ipv6 lists, it's an open question to what 
degree and how strong guidance the IETF should (or even could) give to 
the operators.

It seems that if the IETF would want to pursue this work, the 
discussion would need to be recast in the manner "You should 
considering doing [this].  This is why it may or may not make sense". 
As we learned from the DNS configuration debates at DNSOP (though the 
situation is a bit difficult), getting to a consensus could be very 
difficult.

A couple of specific comments:

  - the global unicast address recommendations are (IMHO) way too lax. 
Even some part of 'strict' filters in 
http://www.space.net/~gert/RIPE/ipv6-filters.html could be stricter. 
In any case, that URL should also be referred.  This is an example of 
the case why getting CONSENSUS on a document like this is going to be 
very difficult.  Many folks don't see a problem w/ putting /48 junk 
etc. in the routing tables, others do.  This doc would/could then 
become a political battleground in the v6 operations community..

  - the uppercase keywords are inappropriate and should be removed

  - the doc should probably make RFC2772 historic

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Tim Chown <[email-masked]>
Date: Mon, 19 Sep 2005 09:30:22 +0100

> place to give guidance on this, updating is certainly needed.

Well yes, one recommendation is now on filtering 3ffe::/16 prefixes, 
at least from 06/06/06 ;)

> degree and how strong guidance the IETF should (or even could) give to 

We have BCP in many areas.   As with everything else, nothing can be forced,
so Bill can continue to do as he pleases.

>  - the uppercase keywords are inappropriate and should be removed

I agree.  It is just guidelines.

-- 
Tim/::1

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 19 Sep 2005 08:45:58 -0400

> forwarded for comments on the [email-masked] list.

will do.

> RFC2772 includes guidelines for *6bone*.  This is offering  
> guidelines for more than that.  In that light, if we feel the IETF  
> is the right place to give guidance on this, updating is certainly  
> needed.

see comment below.

>
> As already noted in the IETF/ipv6 lists, it's an open question to  
> what degree and how strong guidance the IETF should (or even could)  
> give to the operators.
>
> considering doing [this].  This is why it may or may not make  
> sense". As we learned from the DNS configuration debates at DNSOP  
> (though the situation is a bit difficult), getting to a consensus  
> could be very difficult.
>
>  - the global unicast address recommendations are (IMHO) way too  
> lax. Even some part of 'strict' filters in http://www.space.net/ 
> ~gert/RIPE/ipv6-filters.html could be stricter. In any case, that  
> URL should also be referred.  This is an example of the case why  
> getting CONSENSUS on a document like this is going to be very  
> difficult.

I knew that... ;-))

well. the intent here was to set the minimum (/48 or less) so that at  
least this is clear and I'm hoping there is a concensus on /48 or  
less. In this case, the document with the other guidelines is useful  
for operators.
for example, if the minimum is /48 or less, then we are filtering / 
64! good progress!

By the time there is concensus on less than /48 (maybe after  
multihoming work or ...), then we could revise it and make a new  
version.

currently (to also respond to Alain comment on diff with RFC2772),  
RFC2772 is the only "published" document I know that has some  
guidelines on routing policies. and RFC2772 is outdated. So there is  
a need for a document, with the minimum that has concensus to help  
the ones who are deploying right now.

> Many folks don't see a problem w/ putting /48 junk etc. in the  
> routing tables, others do.  This doc would/could then become a  
> political battleground in the v6 operations community..

Why don't publish what is agreeable as a minimum and then revise it  
when more experience/more concensus/other tools/... is in.

>  - the uppercase keywords are inappropriate and should be removed

you meant because it is not a protocol?

>  - the doc should probably make RFC2772 historic

I thought about that and I agree. I'm not sure when/how to put it.  
Include in the document I guess?

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 19 Sep 2005 08:50:49 -0400

> at least from 06/06/06 ;)

well, I thought about it, but in fact, after 06/06/06, 3ffe::/16  
becomes like any non-allocated prefix.
So:
- before 06/0606, it is a valid prefix
- after 06/06/06,  it should be treated as any non-allocated prefix.

so, in fact, if you look at current text, it is already taken care  
of... ;-))

>> what
> We have BCP in many areas.

you are right, the intented target level of the document was a BCP.

> As with everything else, nothing can be forced,

ok.

Marc.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 Sep 2005 07:51:54 +0300 (EEST)

On Mon, 19 Sep 2005, Marc Blanchet wrote:
>> Many folks don't see a problem w/ putting /48 junk etc. in the routing 
>> tables, others do.  This doc would/could then become a political 
>> battleground in the v6 operations community..
>
> Why don't publish what is agreeable as a minimum and then revise it when more 
> experience/more concensus/other tools/... is in.

You mean, after the routing table has already been irreversibly 
polluted with junk, come back and review our past recommendations?

Sorry, I don't see how that could fly.  If we don't recommend (or at 
least describe the tradeoffs of) filtering at the allocation 
boundaries, we'd better not produce a document at all because the 
existance of such a document would be interpreted as the IETF's 
go-ahead for putting the junk in the routing tables.

> you meant because it is not a protocol?

Yes, and because this is not really an area where the IETF can make 
strict requirements like "must"..

> I thought about that and I agree. I'm not sure when/how to put it. Include in 
> the document I guess?

Yes, and if you're using XML2RFC, do something like:

<rfc ipr="full3978" category="info" 
docName="draft-blanchet-v6ops-routing-guidelines-01.txt" 
obsoletes="2772">

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 20 Sep 2005 06:42:43 -0400

Le 05-09-20 à 00:51, Pekka Savola a écrit :

>> Why don't publish what is agreeable as a minimum and then revise  
>> it when more experience/more concensus/other tools/... is in.
>>
>

- no. you are missing the point.

- currently no recommendation. so /128 can fly.
- what is the number then, if not /48? I'm fine with better than /48,  
but I thought that concensus will be difficult with a number less  
than /48.
- and if you read the text, /48 is the minimum.
- maybe you can provide some text?

>
> Sorry, I don't see how that could fly.  If we don't recommend (or  
> at least describe the tradeoffs of) filtering at the allocation  
> existance of such a document would be interpreted as the IETF's go- 
> ahead for putting the junk in the routing tables.

so you are proposing /32?  Can you provide text?

will do.

> <rfc ipr="full3978" category="info" docName="draft-blanchet-v6ops- 
> routing-guidelines-01.txt" obsoletes="2772">

yeap, you guess it.

Marc.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 21 Sep 2005 13:25:39 +0300 (EEST)

On Tue, 20 Sep 2005, Marc Blanchet wrote:
>> You mean, after the routing table has already been irreversibly polluted 
>> with junk, come back and review our past recommendations?
>
> - what is the number then, if not /48? I'm fine with better than /48, but I 
> thought that concensus will be difficult with a number less than /48.

No.  If there is no appropriate IETF statement on this, the folks 
probably think the IETF hasn't made a firm opinion on this, and seek 
guidance from elsewhere.  Many use strict filters, others relaxed, 
some may not filter at all.  That is, the lack of IETF guidance on 
filtering doesn't mean the operators can't (and don't) filter -- 
operators seem to be capable of publishing some filtering suggestions 
on their own (e.g., Gert's web page).

So, any guidance the IETF makes must be good, not simply "anything is 
better than nothing".

>> Sorry, I don't see how that could fly.  If we don't recommend (or at least 
>> describe the tradeoffs of) filtering at the allocation boundaries, we'd 
>> better not produce a document at all because the existance of such a 
>> document would be interpreted as the IETF's go-ahead for putting the junk 
>> in the routing tables.
>

Ok, here's something to demonstrate a different starting point.

3.5.  Global Unicast

    The global unicast routes (2000::/3) [RFC3513] may be advertised in an
    IGP or EGP.

3.5.1 Filtering on Allocation Boundaries

   In IPv4 as of 2005, over 50% of routing table entries are used by
   more-specific route advertisements [http://bgp.potaroo.net].  These are
   a result of a number of sources such as misconfigurations, traffic
   engineering, multihoming, switching providers without renumbering,
   etc.

   From the larger perspective, however, these are more or less
   unnecessary "junk".  In 6bone, prefix filters to weed out
   more specifics were required [RFC2772] to weed out such routes.
   This is also a valid practise for production networks as
   it will help in keeping the routing table compact and clean;
   the cleaner the global routing table is, the more difficult it
   is for people to start polluting it.

   Therefore, filtering based on the allocation boundaries is
   recommended.  For the sake of simplicity (as the allocation
   boundaries have varied mainly between /19 and /32), the
   policy could be to allow advertisements up to /32, and /35
   for older allocations in 2001::/16, and the more specifics only
   by exception.  One particular exception to keep in mind in
   particular is ARIN's critical internet infrastructure
   micro-allocation block (2001:500::/32) where up to /48's
   should be allowed.

....