Subject: Re: even one reason why provably unique SL is needed?

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 25 Nov 2002 16:52:11 -0500

In message <[email-masked]>, Pekka Savola 
writes:
>On Tue, 26 Nov 2002 [email-masked] wrote:
>> 	"nearly unique" is not good enough.  You want to be able to
>> 	register these addresses in the ip6.arpa tree.  You don't
>> 	want to force every site to manually configure the top of
>> 	their reverse tree into every nameserver in the organisation.
>
>I don't want the administrative pain in the ass of someone managing flat 
>ip6.arpa reverses.
>
>No way, no way at all.
>
>Require the DNS server at the edge of the site be authoritative for the 
>whole of fec0::/10 or blackhole the queries.
>
>(I don't think too many people would even want to register site-locals in
>the _global_ reverse DNS, queriable by anyone -- remember, they're not to
>be used globally, and reverses in and itself are already considered a
>"security hazard" by some.)
>
>Let's not go down the path of putting site-locals anywhere near the global
>ip6.arpa.

Sure -- but to keep the load off the root, we need to be *very* sure 
that sites do pretend to be authoritative for them.

Hmm -- people *won't* do that properly.  But suppose that whenever a 
high-level resolver sees an inverse query for <fec0,site,mumble>, it 
synthesizes an NS record with a long TTL saying that that prefix is 
served up by <fec0,site,42> or some other well-known number.  Better 
yet, it can reply with <fec0,site,mumble>.  It doesn't stop people from 
asking once; it does "encourage" them to look elsewhere on subsequent 
queries over the next week...

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)

--------------------------------------------------------------------
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: [email-masked]
Date: Tue, 26 Nov 2002 11:04:43 +0900

>that sites do pretend to be authoritative for them.

	will it help if we ship c.e.f.ip6.int/arpa zone files with BIND,
	just like 1.0.0.127.in-addr.arpa?

itojun

---

From: Aidan Williams <[email-masked]>
Date: Wed, 27 Nov 2002 15:51:31 +1100

> 	just like 1.0.0.127.in-addr.arpa?

Yes, potentially.  Further, I would like to see a recommendation
that authoritative RFC1918 reverse maps are a default part of
name server boot files along the lines of RFC1912, Section 4.1.

Stepping back for a moment, I think we are failing to note
that this is *not* just an IPv6 problem.

The increasing volume of root queries for RFC1918 PTR maps is
presumably related to the increasing number of hosts on the
internet behind NAT boxes.  We should expect internet growth
to continue and therefore that the number of bogus IPv4 queries
will also continue to grow unless some action is taken.

We should get the IPv6 case right.  However if we believe that
dual stack is the likely IPv6 deployment scenario we are only
addressing well less than half the immediate problem.

- aidan

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 27 Nov 2002 12:49:06 +0100

> addressing well less than half the immediate problem.

Fortunatly we have AS112 (www.as112.net), but looking at the stats
eg http://www.ripe.net/as112/ it's a lot.

Making RFC1918 and fec0:: and other 'special interest assigned' spaces
a default for a nameserver could solve these problems.
People wanting to use RFC1918 space could then still comment out the
blackhole and redirect it somewhere else or define it locally.
One could see a 'problem' where users will start having problems
as their 'local reverse doesn't work' but the problem being the double
definement. BIND and others warn for double definitions so that
shouldn't
be a big item certainly if a nice FAQ item is included.
And it will save a lot of traffic which is currently still flowing to
the rootservers or the as112 boxes.

Greets,
 Jeroen