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

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

"Alan E. Beard" <[email-masked]> 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.

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

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

				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: Fri, 29 Aug 2003 18:40:26 -0400 (EDT)

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

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

> But I will probably want to send the *whole* unique-local block to a tunnel
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.

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

> 				ddl@danlan.*com

Thanks for your comments; your note is very helpful indeed.

Regards,

AEB

-- 
Alan E. Beard <[email-masked]>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529