"Alan E. Beard" <[EMAIL PROTECTED]> wrote:
|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.
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...
|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.
|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').
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.
|> |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.
|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.
|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.
"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.
Dan Lanciani
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
