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

[Pekka Savola <pekkas@netcore.fi>]

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?
>
> - 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?

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.
>
> so you are proposing /32?  Can you provide text?

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.

....

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