Christian: A couple of questions concerning the operational specifics of the black hole implied by your statement below.
BTW, the policy statement is clear, concise, and utterly reasonable. This is not in the least surprising when I consider who wrote it. :-) On Fri, 29 Aug 2003, Christian Huitema wrote: > > > However, we might be able to make the suggested restrictions a bit > less > > burdensome, provided that we can satisfy the never-route-private-addrs > > zealots that the revised scheme can still be effective in limiting > > unintended propagation of non-globally-routable prefixes. See below > for > > specifics. [...] > > The goal of the recommendation is both to provide some degree of > isolation, and also to ensure that the local addresses are not abused in > the future. One way to achieve that is to ensure that routers > systematically junk any packet sent to FC00::/8 or FD00::/8, unless a > more specific route has been installed. This will not require Dan to > update his internal routers, since there will indeed be a more specific > route for his own internal site. Backdoor connections between links will > also work, if a /48 route is announced for the backdoor. > > -- Christian Huitema > Let me see if my notion of how this might work bears any relation at all to the reality of router implementations. As I understand the above text, routers are intended to discard traffic (as distinguished from routing protocol prefix propagation) with destination addresses in the range of FC00::/7 unless there exists in the routing table a prefix of the form FC00:*:*/48 or FD00:*:*/48 where the entire prefix matches the destination address of the subject packets. This would imply that forwarding would be based on routing table longest match, with any packet matching FC00::/8 or FD00::/8 discarded, but, for example, traffic matching routing table entry FC00:DEAD:BEEF/48 forwarded. If my interpretation thus far is accurate, the issue postulated by Dan does not exist: as long as a specific route to the destination (perhaps, to any matching prefix with a length greater than /8) exists in the routing table, matching traffic will be forwarded. Absent restriction on propagation of routes in the FC00::/7 range, any prefix advertised into Dan's routing domain, whether or not the prefix _originates_ within the local domain, will result in traffic forwarded to any destination for which a route more specific than FC00::/8 or FD00::/8 exists. (Or, alternatively, for routes of the forms FC00:*:*/48 or FD00:*;*/48 only if we defeat auto-summary in the IGPs.) As I understand the description so far, this black hole implementation would certainly prevent unintended forwarding of traffic to unique-local prefixes based on the presence of default routes. If all the above is reasonably consonant with practical implementations of the routing protocols, then Dan does not have any administrative burden beyond that imposed by good network design and operational practice. However, it seems possible in certain topologies for that grand bugbear, unintended or malicious propagation of non-globally-routable prefixes into private and public network routing tables, to rear its ugly head (or perhaps its nether end - I don't know how to distinguish one from the other). Let us postulate that Dan's network (for the purposes of this discussion, a large bank) uses unique-local addressing for its back-office operations. Let us further postulate that Dan's bank has private links to a banking service provider for, say, item processing, and to a credit reporting agency for loan application verification. Let us further postulate that both service bureaus are operating on unique-local addresses for reasons of their own, perhaps as arbitrary as preferring not to renumber their large complement of legacy IBM hosts whenever they change ISPs. Additionally, let us postulate that all three entities have a small population of hosts which must be accessible from the public networks, and that those hosts must also be reachable from the local private network. This would imply that the public-address routing environment and the private-address routing environment in each entity might operate as a unified routing domain. Let us now wildly postulate that more than one administrator of the several networks have failed, through inadvertence or neglect, to install properly-configured ACLs at the route redistribution points. Under these circumstances, at least one of the private networks will see undesired routes to unique-local range prefixes. Worse yet, if any of the ISPs serving any of these three end networks should fail to restrict content of incoming routing table updates, we may see unique-local prefixes advertised to the public networks. This breaks the requirement specified in the unique-local draft that prefixes in the FC00::/7 range not be propagated to the global routing tables. Unless I have missed some essential clause in your description above, we appear to have a failure mode, with a root cause of user neglect or user error, in which the non-propagation requirement for unique-local prefixes to the global routing table is likely to be violated. We can rely on network administrators to implement properly-configured ACLs for route redistribution at appropriate boundary points. I for one am perfectly content to do this, for my experience has indicated that most network engineers working on site boundary routers are reasonably competent and reasonably careful (some obsessively, rather than reasonably, so). However, there seem to be a fair complement of folks on the list who feel very strongly indeed that additional safeguards are needed: hence my suggestion that we specify the implementation of a default black hole for routes. Upon further consideration, it appears to me that a scheme which ties the enabling of the black hole to the existence of a BGP process, and restricts the operation of the black hole to BGP-mediated route distributions, should be sufficient to largely prevent inadvertent propagation of unique-local prefixes to the public network routing tables. Perhaps it would be sufficient to limit the black hole to BGP redistributions (that is, to BGP peer operations as distinguished from IBGP peer operations); this would further reduce the need for explicit configuration in cases where propagation of unique-local routes is desired. OTOH, I see at least some merit in applying the default black hole for routes to _all_ routing process redistributions (except static and connected) without regard to routing protocol type: at a minimum, this would provide an additional safeguard for private interconnections, although at the expense of a small increase in configuration burden for the administrators of boundary routers (site or AS). Now, in light of the above, from what misapprehension did my all-we-like-sheep act arise? Again, thanks for your help in getting this sorted. Regards, AEB -- Alan E. Beard <[EMAIL PROTECTED]> AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 863.815.2529 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
