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

From: "Christian Huitema" <[email-masked]>
Date: Fri, 29 Aug 2003 16:33:09 -0700

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

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.

-- Christian Huitema

--------------------------------------------------------------------
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 23:20:13 -0400 (EDT)

Christian:

A couple of questions concerning the operational specifics of the black
hole implied by your statement below.

BTW, the policy statement is clear, concise, and utterly reasonable.  This
is not in the least surprising when I consider who wrote it. :-)

On Fri, 29 Aug 2003, Christian Huitema wrote:

> > specifics.  [...]
Let me see if my notion of how this might work bears any relation at all
to the reality of router implementations.

As I understand the above text, routers are intended to discard traffic
(as distinguished from routing protocol prefix propagation) with
destination addresses in the range of FC00::/7 unless there exists in the
routing table a prefix of the form FC00:*:*/48 or FD00:*:*/48 where the
entire prefix matches the destination address of the subject packets.
This would imply that forwarding would be based on routing table longest
match, with any packet matching FC00::/8 or FD00::/8 discarded, but, for
example, traffic matching routing table entry FC00:DEAD:BEEF/48 forwarded.

If my interpretation thus far is accurate, the issue postulated by Dan
does not exist: as long as a specific route to the destination (perhaps,
to any matching prefix with a length greater than /8) exists in the
routing table, matching traffic will be forwarded. Absent restriction on
propagation of routes in the FC00::/7 range, any prefix advertised into
Dan's routing domain, whether or not the prefix _originates_ within the
local domain, will result in traffic forwarded to any destination for
which a route more specific than FC00::/8 or FD00::/8 exists. (Or,
alternatively, for routes of the forms FC00:*:*/48 or FD00:*;*/48 only
if we defeat auto-summary in the IGPs.)

As I understand the description so far, this black hole implementation
would certainly prevent unintended forwarding of traffic to unique-local
prefixes based on the presence of default routes.

If all the above is reasonably consonant with practical implementations of
the routing protocols, then Dan does not have any administrative burden
beyond that imposed by good network design and operational practice.
However, it seems possible in certain topologies for that grand bugbear,
unintended or malicious propagation of non-globally-routable prefixes into
private and public network routing tables, to rear its ugly head (or
perhaps its nether end - I don't know how to distinguish one from the
other).

Let us postulate that Dan's network (for the purposes of this discussion,
a large bank) uses unique-local addressing for its back-office operations.
Let us further postulate that Dan's bank has private links to a banking
service provider for, say, item processing, and to a credit reporting
agency for loan application verification. Let us further postulate that
both service bureaus are operating on unique-local addresses for reasons
of their own, perhaps as arbitrary as preferring not to renumber their
large complement of legacy IBM hosts whenever they change ISPs.
Additionally, let us postulate that all three entities have a small
population of hosts which must be accessible from the public networks, and
that those hosts must also be reachable from the local private network.
This would imply that the public-address routing environment and the
private-address routing environment in each entity might operate as a
unified routing domain.  Let us now wildly postulate that more than one
administrator of the several networks have failed, through inadvertence or
neglect, to install properly-configured ACLs at the route redistribution
points.  Under these circumstances, at least one of the private networks
will see undesired routes to unique-local range prefixes.  Worse yet, if
any of the ISPs serving any of these three end networks should fail to
restrict content of incoming routing table updates, we may see
unique-local prefixes advertised to the public networks. This breaks the
requirement specified in the unique-local draft that prefixes in the
FC00::/7 range not be propagated to the global routing tables.

Unless I have missed some essential clause in your description above, we
appear to have a failure mode, with a root cause of user neglect or user
error, in which the non-propagation requirement for unique-local prefixes
to the global routing table is likely to be violated.

We can rely on network administrators to implement properly-configured
ACLs for route redistribution at appropriate boundary points.  I for one
am perfectly content to do this, for my experience has indicated that most
network engineers working on site boundary routers are reasonably
competent and reasonably careful (some obsessively, rather than
reasonably, so).  However, there seem to be a fair complement of folks on
the list who feel very strongly indeed that additional safeguards are
needed: hence my suggestion that we specify the implementation of a
default black hole for routes. Upon further consideration, it appears to
me that a scheme which ties the enabling of the black hole to the
existence of a BGP process, and restricts the operation of the black hole
to BGP-mediated route distributions, should be sufficient to largely
prevent inadvertent propagation of unique-local prefixes to the public
network routing tables.  Perhaps it would be sufficient to limit the black
hole to BGP redistributions (that is, to BGP peer operations as
distinguished from IBGP peer operations); this would further reduce the
need for explicit configuration in cases where propagation of unique-local
routes is desired.  OTOH, I see at least some merit in applying the
default black hole for routes to _all_ routing process redistributions
(except static and connected) without regard to routing protocol type: at
a minimum, this would provide an additional safeguard for private
interconnections, although at the expense of a small increase in
configuration burden for the administrators of boundary routers (site or
AS).

Now, in light of the above, from what misapprehension did my
all-we-like-sheep act arise?

Again, thanks for your help in getting this sorted.

Regards,

AEB

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