Subject: Re: (ngtrans) review of 6to4-DNS

From: Feico Dillema <[email-masked]>
Date: Fri, 11 Jan 2002 22:09:53 +0100

On Fri, Jan 11, 2002 at 12:32:34PM -0800, Bob Fink wrote:
> In mid-November Randy forwarded a request from ngtrans for DNSEXT to review 
> the 6to4-DNS draft:
> 
> <http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-6to4-dns-00.txt>

> there is any feedback from this group that you can give, either to the 
> author or ngtrans.

Just a minor note; I've implemented the proposed method from section:
``3.1 6to4 NS records derived from IPv4 NS records'', in the DNS proxy
(DNSALG) totd. See:

 http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html

It has not been tested a lot, and I have gotten no feedback from the
totd user community (neither positive or negative) on this
functionality. So, if you try it in your assessment of the draft,
please let me know if it works according expectation too.

Feico.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Bob Fink <[email-masked]>
Date: Fri, 11 Jan 2002 12:32:34 -0800

Abstract from the draft

"This memo discusses several potential mechanisms for locating the DNS 
servers which provide "reverse lookup" of 6to4 addresses.

Please note that this is a preliminary draft which only attempts to outline 
possible means of solving the problem, for purpose of discussion. This 
version of the proposal is NOT rigorously specified, and the author claims 
significant expertise in neither DNS nor anycast. Nevertheless, it is hoped 
that these proposals are sufficiently detailed to allow reviewers to make a 
first-order assessment of their viability.
The assistance of appropriate experts in drafting future revisions of 
these proposals would be most welcome. "

I have not seen any comments on this list and would like to again ask if 
there is any feedback from this group that you can give, either to the 
author or ngtrans.

Thanks,

Bob Fink
ngtrans co-chair

---

From: David Terrell <[email-masked]>
Date: Fri, 11 Jan 2002 23:29:24 -0800

> there is any feedback from this group that you can give, either to the 

I've implemented code that follows the alternative laid out in 3.2
(6to4 NS records inferred from 6to4 prefix).  It's available at
http://www.meat.net/~dbt/code/rev6to4/, implemented as a BIND 9
plugin.

General commentary on the alternatives:
3.1) 6to4 NS records inferred from IPv4 NS records
Advantages:  Probably follows rfc2182/bcp16.
Disavantages:  For a site located behind a single IPv4 address
  possibly served by a fairly clueless ISP it could be hard to 
  get them to set this up; nameservers only reachable over IPv4.

3.2) 6to4 NS records inferred from 6to4 prefix
Advantage: reachable over ipv6, easy to set up for small to medium 
  sized sites.
Disadvantage:  Only reachable within the site.  Requires allocation
  of a magic SLA by IANA (:ffff:?) and special addresses within that 
  network for this purpose.

My gut feeling:
The disadvantages of of 3.2 seem fairly minor.  Walking the reverse
DNS and potential negative caching from unreachable servers is far
less of an rfc2182 problem than forward DNS -- i.e. reverse lookups 
are rarely important except when that site is clearly functional.

Section 4 is more problematic.  There's a much more dramatic tradeoff
here depending on what method is chosen.  There was some small
discussion between the draft author and myself on this list as to
where the actual creation of metarecords should be done.  The options
are:
1) Do it on the core side (i.e. authoritative servers for ip6.arpa).
2) do it at the edge (individual recursive or stub resolvers).

The problem with this is that there is very little room for overlap.
The edge recursive resolver can query the 2.0.0.2.ip6.arpa nameserver
and generate metarecords in an NXDOMAIN case, OR the core server
can return authoritative or metarecords depending on whether it has
authoritative data.  If the core server generates metarecords then
there is no reason or chance for the edge server to.  However, if
the core server is already being queried for possible authoritative
data then there's little reason not to implement the metarecord
generation and remove the need to deploy specialized code at the
edge, which also makes this a global change, instead of only effective
at the ipv6 sites that implement these records.

I'd also like to mention security concerns.  It's probably a good
idea to blackhole as many things as we can.  Queries to e.2.0.0.2.ip6.int
on a remote nameserver could end up causing multicast DOSes.  Queries
to a.0.2.0.0.2.ip6.int could result in unforseen security boundaries 
being crossed at sites that use RFC 1918 space for private resources.
The list that exists in my code at the above referenced URL comes from
the default list of null routes that KAME ships for the 2002:: zone.

A magic name for 2002:c058:6301:: would make my traceroutes happen
a lot faster.

-- 
David Terrell             | "Americans need to watch what they say,
Prime Minister, Nebcorp   | watch what they do, and this is not a
[email-masked]              | time for remarks like that; there never
http://wwn.nebcorp.com/   | is." - Ari Fleischer, White House Press Secretary

---

From: David Terrell <[email-masked]>
Date: Sat, 12 Jan 2002 11:46:56 -0800

On Sat, Jan 12, 2002 at 09:41:20AM -0500, Keith Moore wrote:
> > authoritative data.
> one possible problem - just because the 2.0.0.2.ip6.arpa nameserver
> has NS records pointing to some prefix doesn't mean that the delegation
> extends all the way to the zone for the 6to4 prefix.  they could be
> delegated to the v4 ISP, for instance, without the ISP having populated
> that zone for some or all of its customers.

In that case the arpa nameserver would return delegations (and
perhaps up through the RIR to the "tier-1" isp to the local ISP).
As soon as that first delegation is done, all implicit possibilities
are lost unless it's done at the edge site.  Hm.

(i.e. if an ISP has their 6to4 reverse delegated to them, and they 
don't choose to insert authority records for a particular user, and
that user sets up 6to4, should we fall back to the implicit records?
I would say yes, since if they specifically want to blackhole 6to4
records they have the ability to do so with wildcard entries.)

-- 
David Terrell   | "Naturally, this is a frivolous example, and not likely to 
[email-masked]    | face scrutiny well. In fact, you should have seen me giggle 
Nebcorp PM      | as I typed the words 'zero-administration.'" - Benjy Feen, 
wwn.nebcorp.com | "Monkeybagel Consulting", www.monkeybagel.com.

---

From: Keith Moore <[email-masked]>
Date: Sat, 12 Jan 2002 14:55:32 -0500

> records they have the ability to do so with wildcard entries.)

I'd say yes also.  But it means that if the servers for the
2.0.0.2.ip6.arpa zone are going to return pseudo NS records
pointing to the default server addresses for {IPv4}.2.0.0.2.ip6.arpa
then (if there are *any* NS records for a prefix of the address being 
queried), those zone servers will have to first try the query 
themselves, and get back NXDOMAIN, before returning the pseudo records.

Keith