ietf
[Top] [All Lists]

Vendor viewpoint on ULA filtered-by-default

2007-09-21 09:02:34
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>