Dan: If it were up to me alone, I would do exactly what your suggestions below imply, and proceed on the assumption that administrators of site boundary routers (and, probably, administrators of rich-configuration interior routers) are competent to perform the tasks entailed thereby. However, there is considerable discussion in the list which implies that many participants in this WG believe that router administrators are not uniformly competent, and further that the majority of such administrators are not only not competent, but are specifically and remarkably incompetent.
IMO, any competent router administrator will install suitable ACLs inbound and outbound at any site boundary; but this relies on the assumption that the administrator *is* competent, both de jure and de facto. And (to paraphrase _The Odd Couple_) I know altogether too well what happens when I assume. 8-( 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. I'll welcome further comments from any source. AEB On Fri, 29 Aug 2003, Dan Lanciani wrote: > "Alan E. Beard" <[EMAIL PROTECTED]> wrote: > > [...] > |Additionally, such a suggestion, if implemented, would effectively > |prohibit one of the chief *legitimate* uses of GUPI address address > |allocations: routing between private networks on private (or VPN) links > |under bilateral agreements between the end networks. > [...] > |* Manufacturers of routers MUST include in router code a routing black > |hole for the entire unique-local address block. Router manufacturers MUST > |ensure that said black hole cannot be deconfigured, turned off, or > |otherwise overridden in toto; > > Please don't do this. I don't want to have to special-case all my interior > routers (that could otherwise get by with simple default routes for much of > the outside world--including tunnels to other GUPI address space) for each > tunnel that might be available at the edge routers. This will be even more > of a problem once we start to set up dynamic tunnels so that a large set of > GUPI-using-sites can communicate in a cooperative overlay network. There is > no way to know whether a router will be used at the edge where you *might* > have some business enforcing such a black hole or deep inside where you have > absolutely no business complicating my routing. > Perhaps we could tie activation of the black hole to the existence of a BGP process, and further, to BGP route distributions only. Since BGP is almost invariably used at boundaries to public networks, this provision alone might be substantially effective in preventing propagation of unique-local prefixes into public networks. If the sense of the group is that a more restrictive default specification is required, we could specify that the default black hole be effective on all redistributions (for example, in the case of cisco boxes, on all 'redistribute RP' statements except 'redistribute static' and 'redistribute connected'). > |however, manufacturers MAY provide a > |configuration facility to "punch through" the black hole for > |user-specified prefixes within the unique-local block. > > But I will probably want to send the *whole* unique-local block to a tunnel > router of some sort. > You will note that there is no specification of prefix length in the suggested text: in the case you propose above, even if the black hole is universally implemented, two 'permit' statements, each for a /8 block (assuming we use the Hinden proposed address space block) would solve this problem. If you have more than two or three interior routers, a stet file containing your routing process definitions and the two permit statements will handle the configuration task with only a few minutes of work for the entire routing domain. This is a a minimal burden, IMO, and what I just described is the worst case. If we tie the black hole to redistributions only or to the BGP process, the burden is even less onerous since boxes which implement these features will bear special-case configurations anyhow. > |Router > |manufacturers SHOULD include in user documentation language to the effect > |that routing of unique-local prefixes beyond site boundaries contravenes > |IETF recommendations, > > Above you said that routing between private networks was legitimate. This > certainly involves routing beyond site boundaries. We need to make it clear > that "beyond site boundaries" does not equate to "on the public internet". > You are, of course, absolutely correct: the language above can and should be considerably improved. After all, I _did_ specify that the text was rough. ;-) However, I suspect that some folks in this group would be inclined to assert that routing of GUPI prefixes beyond site boundaries should be discouraged in most (if not in all) circumstances. I don't happen to agree with this position, but let's see what is the sense of the group. > Dan Lanciani > [EMAIL PROTECTED] Thanks for your comments; your note is very helpful indeed. 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] --------------------------------------------------------------------
