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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf