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

From: Dan Lanciani <[email-masked]>
Date: Mon, 1 Sep 2003 22:39:21 -0400 (EDT)

Andrew White <[email-masked]> wrote:

|Dan Lanciani wrote:
|
|> There is a huge difference between requiring a /48 and allowing anything
|> greater than /8.  The former ...
|> while the latter means that you can bypass the black hole with 2 or 4
|> route additions.
|
|Of course you can bypass it.

The proposed wording is:

``Router manufacturers MUST ensure that said black hole cannot be deconfigured,
turned off, or otherwise overridden in toto;''

How do you reconcile this with ``Of course you can bypass it.''?

|But remember that your bypass is only useful
|if all intermediate routers have ALSO agreed to the bypass, and that the BGP
|routers by default ignore updates to local prefixes.

Your reasoning would apply equally well to a black hole that *can* be turned
off by the owner of the router.  The proposal to make the black hole not only
the default but a default that cannot be changed by the owner of the router
is unprecedented.  It relegates these new addresses to permanent second-class-
citizen status even within a private network.

|So yes, it's trival to modify your system so that the next router in the
|chain discards the packet instead.

Not with the proposed wording.

|More usefully, you can redirect
|particular known routes to VPNs or other directly connected networks and
|still have the gateway router drop other (unknown) local packets.

I don't want to direct only "particular" routes to VPNs.  I want to direct
all packets destined for otherwise unknown prefixes to a tunnel server which
will try to dynamically establish a tunnel to the target network.  The proposed
restriction would make this kind of overlay network impossible.  Maybe that's
the idea.

				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: Andrew White <[email-masked]>
Date: Tue, 02 Sep 2003 13:26:08 +1000

Dan Lanciani wrote:
> ``Router manufacturers MUST ensure that said black hole cannot be
> deconfigured, turned off, or otherwise overridden in toto;''
> 

The immediately preceding context was Alan stating that his reading was that
only /8 routes are to be discarded and that anything more specific would be
forwarded.  You seemed to be saying that having an easy workaround
invalidated the value of the filter, which Alan and Christian (and I) seem
to disagree with.

I object to the proposed wording also, if only because routers must be able
to be configured for 'inside' work at which point local addresses are
in-scope and should not be filtered.  It should be possible to disable the
filtering or refine it.

I agree that the Hinden/Haberman draft only covers filters AT the border,
and that this is a weakness.  All routers designed for BGP routing should by
default discard (preferably with "ICMP No Route To Host" or "ICMP
Destination Unreachable" as appropriate) packets with local source or
destination addresses and BGP implementations should ignore / refuse updates
to such addresses (of any length prefix).  Unless administratively
configured to do otherwise.

With such a restriction, I don't see much incentive for an ISP (or other
user) to disable the filters in a general manner.  Since most routers will
filter anyway, they can only route the local packets to other people who've
disabled the filters, and anyone disabling the filters (and only those
people) needs to cope with potential routing table increases for their OWN
tables.

-- 
Andrew White

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Sep 2003 16:39:45 +0200

> turned off, or otherwise overridden in toto;''

It's very simple. No sane router vendor would do this. There are lots
of real world cases where people need to route arbitrary address
blocks.

The MUST can only apply to default configuration.

   Brian