Subject: Vendor viewpoint on ULA filtered-by-default

From: Fred Baker <[email-masked]>
Date: Fri, 21 Sep 2007 08:56:04 -0700

Paul Vixie has asked me to more widely state a comment made last May  
on the v6ops mailer. Please understand that this is not a formal  
statement of Cisco's (e.g., this is not a press release signed off by  
the Cisco Legal, corporate PR, product line management, or marketing  
departments), it is my personal opinion of how Cisco will apply its  
design guidelines and viewpoints to the ULA concept.  Barring the  
influx of large numbers of dollars from a customer coupled with a  
change request, it represents what I consider to be Cisco's probable  
course of action.

The context is RFC 4193's statement that

   The default behavior of exterior routing protocol sessions between
   administrative routing regions must be to ignore receipt of and not
   advertise prefixes in the FC00::/7 block.  A network operator may
   specifically configure prefixes longer than FC00::/7 for inter-site
   communication.

Cisco thinks ULAs are wonderful things if our customers think they  
are wonderful things. In http://tools.ietf.org/html/draft-baker-v6ops- 
b2b-private-routing, I have identified a particular way we might  
consider using them across administrative boundaries. In other email,  
I have suggested that systems that we don't want the external world  
to access (labs, internal-only servers, etc) could similarly be  
addressed using ULAs that are not advertised across administrative  
boundaries. Doing this would likely simplify firewall rules.

However, we are unlikely to change our configuration methodologies  
for BGP in a manner that changes existing customer configurations  
(such as by turning off a portion of the address space that our  
customer has configured to be available, or by rearranging his route  
maps without his consent), and we are unlikely to create magic  
configurations such as "turning on BGP for IPv6 for the first time  
suddenly creates a three stage route map, partially filled in". We  
try to operate on what we call the "Principle of Least Surprise". Our  
customers tell us that such things are "surprising". One could  
imagine a "simple-bgp6-configuration" macro that would accept a  
few prefixes and a few neighbor names or addresses as arguments and  
build a simple initial BGP configuration that the administrator could  
then flesh out to his heart's content, but even the application of  
that would be the operator's choice.

What we *are* very likely to do is post configuration guidance for  
BGP for IPv6 on our web site, with a note regarding the importance of  
filtering out ULAs as a class and indicating how to advertise and  
accept more specific ULAs when appropriate. To see what that might  
contain, take a look at http://ops.ietf.org/lists/v6ops/v6ops.2007/ 
msg00391.html, which is in reply to http://ops.ietf.org/lists/v6ops/ 
v6ops.2007/msg00377.html. In short, "not advertising" is easy - don't  
include them in the list of things to be advertised, and they won't  
be advertised. Denying their acceptance when announced by the peer is  
part of a BGP configuration's acceptance policy, which is something  
network operators usually prefer to configure themselves.

This is consistent with the way we handle RFC 1918 prefixes and other  
martian prefixes in IPv4 networks. 

There is an obvious inherent bug in that, which has been observed in  
the IPv4 Internet with respect to RFC 1918 and martian prefixes.  
Administrations that don't apply the policy to deny ULAs will accept  
them, which will have the effect of leaking them if the peer  
inadvertently advertises them. The problem is that we, as a vendor,  
can't really tell the difference between clueful operators and  
clueless ones (their money all looks the same), and as a result make  
no attempt to save the world from one while trying to satisfy the  
other. This is a matter we feel should be included in operator  
education, one of many things the clueful operator needs to know.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 21 Sep 2007 20:20:53 +0200

On 21-sep-2007, at 17:56, Fred Baker wrote:

> There is an obvious inherent bug in that, which has been observed  
> in the IPv4 Internet with respect to RFC 1918 and martian prefixes.  
> Administrations that don't apply the policy to deny ULAs will  
> accept them, which will have the effect of leaking them if the peer  
> clueless ones (their money all looks the same), and as a result  
> make no attempt to save the world from one while trying to satisfy  
> the other.

As a long time user of Cisco products, I think this is a useful  
approach. I would be quite upset if I found out that I couldn't use  
some kind of private addressing in a training course.