Subject: Re: Comments on draft-ietf-ipv6-unique-local-addr-00.txt

From: Dan Lanciani <[email-masked]>
Date: Fri, 29 Aug 2003 23:12:24 -0400 (EDT)

"Alan E. Beard" <[email-masked]> 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-masked]> 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
				ddl@danlan.*com
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Alan E. Beard" <[email-masked]>
Date: Sat, 30 Aug 2003 01:21:00 -0400 (EDT)

On Fri, 29 Aug 2003, Dan Lanciani wrote:

> |imply, [...]
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.

> 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.

> |BGP process, [...]
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.

> 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.

> insist that the overriding routes must have some absurdly large prefix length,

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.  ;-)

> you will probably make them useless for the other problems that they are
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.

> barrier to an overlay network by forcing unnecessary routing table growth in
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-masked]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529