On Fri, 29 Aug 2003, Dan Lanciani wrote: > "Alan E. Beard" <[EMAIL PROTECTED]> wrote: > > |If it were up to me alone, I would do exactly what your suggestions below > |imply, [...] > > That's all well and good, but there are lots of other ways that a router > administrator can screw up. It isn't at all clear that this particular > way rises to the level of requiring that we kludge all routers in a manner > that goes beyond anything that has been done in the past. Fortunately, > router vendors have little incentive to go along with such things... > As to sentence two, that is a judgement call, and I don't think the list has even begun to approach concensus on the issue. I'm not advocating any specific approach or outcome on this; my intent here is to float some ideas and see what reactions we get. Your position on the matter is now very clear indeed, so we know what one participant thinks. 8-) As to the router vendors, they clearly won't implement features (or documented bugs) which add significantly to the burden of administering a network, and quite rightly, too.
> |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 problem is that you will never satisfy them. You can keep proposing more > and more restrictions that make the address space less and less useful, and > they will go along. But it will never be enough. Eventually you will make > the address space so inconvenient to use that it will be easier to hijack > a random prefix that doesn't have all the punitive semantics attached to it. > I do agree that making inconvenient the use of unique-local address blocks will probably stimulate many network administrators to use rogue address blocks. I'm not sure that the black hole for routes as proposed raises the administrative burden to a level which would cause mass revolt in the community of network administrators. Again, it's a judgement call, and opinions may vary. I'm not yet prepared to conclude that the WG is so divided on this issue that we can never reach concensus. My view on this is perhaps naive, but I would like to at least try to find some proposal which might be acceptable to the WG as a body. I'm not yet willing to ascribe to any faction or factions intransigence so profound as to preclude any possibility of agreement. > |Perhaps we could tie activation of the black hole to the existence of a > |BGP process, [...] > > Sigh. I thought we learned our lesson about hard-coding restrictions like > this. I remember getting beat up because my stack failed to enforce the > absurd subnet number restrictions in the then-popular hosts requirements > RFC. Later I was beat up for not having a flexible enough subnet scheme > to support CIDR. > Again, we have a value judgement here, and opinions may vary. Provided that there is a configurable override (even if not in toto by a single statement - more on this below), I don't see that there is an insurmountable problem. If the restrictions were hard-coded without any override provision, I would absolutely agree with your statement above. Additionally, almost all current router products can be upgraded or modified should requirements or best practices change, usually by writing a new image into flash or onto the disk; removing or modifying the black hole facility should be fairly straightforward should a substantial change in the function prove desirable. > |> |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: > > No, but the assertion that the approach is in fact a solution to the alleged > problem implies something about the prefix length semantics. > Only if the reader chooses to so interpret the text. The fact remains that no prefix length is specified, and therefore, unless the text is changed or amended, no prefix length restrictions should be enforceable. > |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. > > This is inconsistent with your requirement that ``Router manufacturers > MUST ensure that said black hole cannot be deconfigured, turned off, or > otherwise overridden in toto;'' You are now saying that all it takes to > override the black hole in toto is two more specific routes for the two > halves of the address space. As soon as this is pointed out someone will > insist that the overriding routes must have some absurdly large prefix length, > e.g., /48. > The language concerning what may be required to configure partial override for the black hole was quite deliberately crafted so that several interpretations are possible; the details of the exception mechanism are, under the proposed text, left to the implementer. I suspect that the folks who might write code to implement such an override mechanism would be likely to choose the most permissive of the possible implementations, and that, IMO, is a good thing. I would not be in favor of more restrictive language for the clause cited above. The text as proposed will also admit very restrictive interpretations such as you propose above. Implementers are free to choose whatever interpretation they like, provided that said interpretation does not obviously contravene the language of the clause. It's not inconsistent; it's merely vague, and deliberately so. ;-) > |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. > > Of course. If end users can own address space and route it via tunnels as > an overlay network the value of PA space could be severely hurt. If such > an overlay network ever comes close to being fully realized there will be > awkward questions to answer about why the routing system couldn't have > handled PI space in the first place. The problem is that by the time you > impose enough restrictions on GUPI addresses to prevent the overlay scenario > you will probably make them useless for the other problems that they are > supposed to solve. > I think we can implement some facility similar to the black hole described above without making overlay networks unusable; in fact, I think we can do so without adding significantly to the burden of configuring and operating such networks, provided that implementers interpret the text of the black hole proposal in a manner which is not inconveniently restrictive. As to the near-exclusive reliance on PA for registered address allocations, it seems to me that there is a significant body of opinion extant which holds that some form of globally-routable PI space would be desirable, provided that we can figure out how to implement it without imposing fatal stress on the routing infrastructure. That battle has already been joined. IMO, most (perhaps all) of the local-addressing proposals now extant are useful as interim facilities to sustain early adopters of v6 until such time as the more fundamental issues arising from reliance on PA space can be resolved or obviated. The easiest way (although perhaps not the fastest) to oviate the issues (multihoming, address stability, stable locators, etc) is, IMHO, allocation of aggregatable, globally-routable PI address space to end networks where requirements of the classes enumerated above exist. Even if this is accomplished (and, by implication, the infrastructure problems resolved or circumvented), most of the GUPI proposals could, IMO, see useful, although perhaps very limited, service beyond the interim period. Here, a personal note: as I interpret your previous posts, our ultimate objectives are very similar; the open questions concern the path to those objectives. > > "Christian Huitema" <[EMAIL PROTECTED]> wrote: > > |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. > > But I don't want to route only to a handful of specific /48s. I want to > route all (or at least most) of the GUPI space to a tunnel server that will > (try to) dynamically create a path to the target network using some out-of-band > lookup mechanism. If I can do that by installing 4 /9's then I'm happy, but > you haven't accomplished much beyond making the black hole turn-off switch > slightly more complicated than it needs to be. If you are going to require > something as specific as a /48 to escape the black hole (and that's exactly > where this proposal seems to be going) then you are creating an artificial > barrier to an overlay network by forcing unnecessary routing table growth in > interior routers. > My interpretation of Christian's text is *much* more permissive than is yours. Please see my note to Christian in this thread for an alternative reading of his text. 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] --------------------------------------------------------------------
