Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt

From: Pekka Savola <[email-masked]>
Date: Sat, 1 Dec 2001 14:18:11 +0200 (EET)

On Wed, 28 Nov 2001 [email-masked] wrote:
> 	Title		: IPv6 Stateless DNS Discovery
> 	Author(s)	: D. Thaler, J. Hagino
> 	Filename	: draft-ietf-ipngwg-dns-discovery-03.txt
> 	Pages		: 12
> 	Date		: 27-Nov-01
> 	
> This document specifies the steps a host takes in deciding how to
> autoconfigure information (other than the host's name itself)
> required for name resolution in IP version 6.  The
> autoconfiguration process includes determining whether such
> information should be obtained through the stateless mechanism,
> the stateful mechanism, or both.

--8<--
Prefix                     String
-----------------          --------------------------------------
fec0:0:0:1::/64            fec0_0000_0000_0001.local.arpa
3ffe:ffff:0:1234::/64      3ffe_ffff_0000_1234.local.arpa
fe80::/64                  fe80_0000_0000_0000.local.arpa

                     Table 2: Example queries
--8<--

Why do you suggest illegal DNS strings?  Why not use a dash or a dot?

Further, numerical representation is not very powerful; it may be 
that there is no need for all the flexibility though.  Consider a site 
which has a /48 prefix with (2^16)/2 subnets (sequantially) which would 
use server 1 and the rest would use server 2:

Now you would have to generate 2^16/2 entries like:

3ffe:ffff:0:0::/64      3ffe_ffff_0000_0000.local.arpa
3ffe:ffff:0:1::/64      3ffe_ffff_0000_0001.local.arpa
3ffe:ffff:0:2::/64      3ffe_ffff_0000_0002.local.arpa
[...]
3ffe:ffff:0:7fff::/64      3ffe_ffff_0000_7fff.local.arpa

and a wildcard which would match the rest.

In real world, this should be doable with one 3ffe:ffff:0:0::/49 entry.

There are more "realistic" applications of this too.

Why wouldn't this be done as with ip6.int or ip6.arpa?

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Sat, 01 Dec 2001 19:52:47 +0700

Date:        Sat, 1 Dec 2001 14:18:11 +0200 (EET)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | Why do you suggest illegal DNS strings?  Why not use a dash or a dot?

There is no such thing as an illegal DNS string (unless it is too long).
Only domain names that can't be used in some other protocols, and these
names aren't likely to be wanted for e-mail, or other stuff like that, so
they're just fine with underscores (or control-g's, or even returns...)

  | Why wouldn't this be done as with ip6.int or ip6.arpa?

That's a better question, but the draft does say that "local.arpa" is
just a place holder until the actual domain is picked.

More importantly, the CFG RR design is not well done, DNS RR's that hold
lots of different data types, distinguished by something in the data itself
are almost always a very very very poor idea.   There is no shortage of
DNS RR types - just assign a new RR type to each particular record that needs
to be stored, and then if you really need to be able to fetch them all at
once, define a meta-query that does that (but that's to be avoided if 
possible).

And yes, I note that the draft also says that the CFG RR design is also just
a placeholder...

A more significant comment might be that there doesn't seem to be much
advantage in using the DNS to store this kind of config info over using
DHCP (DHCPv6).  If some central admin is going to have to set it all up
anyway, it is not really harder (in fact, it is generally much easier)
to set it up in a dhcp server, than a DNS server.  Easier, because DHCP
servers group config info by topology, DNS servers group systems by admin
boundary.   Config info much more often is related to topology.

That is, I find it a little hard to believe in a scenario when a local
admin is going to be willing to configure lots of junk in the DNS, but
wouldn't be willing to configure it in DHCP instead.   It isn't as though
either DNS or DHCP servers are hard to acquire - just about every reputable
server comes with one of each.

The use of DNS wildcards is also likely to lead to more trouble than you'd
believe, that is a DNS "feature" that has much less applicability than most
people who see it understand.   It is very fragile, and not something to
recommend to most people to attempt to use.   Here the manageability of the
design seems to depend upon that, which makes it flawed IMO.

There really are just two scenarios to consider.

Either there is some central management of all of this data, in which case
it should be implemented using DHCP, which is designed for exactly this
purpose (but which does not imply that the host needs to acquire its IPv6
address using DHCP, it can use autoconf for that, and DHCP for the rest if
desired), or there is no central management for the data, in which case
there won't be any place out there that the host can query and get back
magic answers - it needs to do it all for itself (using only what is defined
in the RFCs, like well known anycast addresses, multicast lookups, ...)

kre

---

From: Pekka Savola <[email-masked]>
Date: Sat, 1 Dec 2001 15:42:11 +0200 (EET)

> just a place holder until the actual domain is picked.

What I meant was, why use a mechanism that has no hierarchy?  ip6.int
does, ip6.arpa might be a bit trickier.  I wouldn't care if the way to
encode prefixes used there would be copied under local.arpa.  This is 
after, local configuration knowledge, and it would be easier to restrict 
the visibility that way.
 
> And yes, I note that the draft also says that the CFG RR design is also just

I think there was an argument by Rob Austein at IETF51 that TXT records
not be used; I don't recall if he suggested to use SRV or invent your own.
 
> server comes with one of each.

There's one additional point to consider.

DNS server is pretty much required; or so the draft assumes.  Personally, 
for small sites, I disagree.

With IPv6, one does not *need* to set up DHCP server (as much as with
IPv4).  It's apparent that the work is concentrating on making it possible
to do certain basic DHCP-like things without DHCP server.

If DHCP server existed in the network -- sure, it would be ok to put the
data there.  But one of the points here is to avoid adding DHCP server at
all.

The real question is: "are all of these configurables so critical that we
should mandate DHCPv6 server in every network which would like to
autoconfigure them?".

IMO, the answer for at least some parts of the draft is "no, we shouldn't
need DHCP for them".

---

From: Ralph Droms <[email-masked]>
Date: Sat, 01 Dec 2001 09:05:57 -0500

Check out <draft-droms-dnsconfig-dhcpv6-00.txt>.  A DHCPv6 server
for "stateless DHCPv6" (DHCPv6 without address assignment) need
not impose a lot of administrative overhead for DNS configuration.

- Ralph

---

From: Robert Elz <[email-masked]>
Date: Sat, 01 Dec 2001 21:21:31 +0700

Date:        Sat, 1 Dec 2001 15:42:11 +0200 (EET)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | What I meant was, why use a mechanism that has no hierarchy?

There are two issues there, one is the suffix - and yes, once that gets
to be picked, it would probably be better if something more was added
(even using local.arpa).   But right now there are more important issues
to consider than this.

The other one is internal hierarchy in the address label part (below)

  | ip6.int does, ip6.arpa might be a bit trickier.

Those two, and local.arpa, are completely different beasts.   local.arpa
is just a magic suffix that means "this data doesn't really live in the
global DNS at all, but we want to leverage off the existing DNS servers
to supply the data when we ask for it, so we need a domain name to tack
on the end of the key to make it obvious what we're doing".

  | I wouldn't care if the way to
  | encode prefixes used there would be copied under local.arpa.

I am guessing that no hierarchy was added there because of the wildcards.
That's not really a justification, wildcards will work (as well as they
ever do) when there is hierarchy in the names.   That might even make
config fractionally easier here, but it doesn't really make a huge difference.

  | This is 
  | after, local configuration knowledge, and it would be easier to restrict 
  | the visibility that way.

local.arpa is restricted by definition (it is never delegated anywhere from
the root (or .arpa) servers).

  | I think there was an argument by Rob Austein at IETF51 that TXT records
  | not be used; I don't recall if he suggested to use SRV or invent your own.

Certainly using TXT would be even worse than the CFG as proposed.   SRV
would be something a bit different I think (though it would be intersting
to contemplate whether it could be bent into serving this purpose).

What's been done though is just re-invent TXT and give it another name.
That separates out these uses from other uses of TXT (not that it probably
matters for these particlar domain names), but otherwise is no different.

  | There's one additional point to consider.
  | 
  | DNS server is pretty much required; or so the draft assumes.  Personally, 
  | for small sites, I disagree.

Yes.   That was more or less what I was saying - the hard part of this is
to design something that works when there is no central database of any
kind at all.   As soon as you start assuming the existence of one, and hence
something (or someone) to maintain it, half the complexity goes away (or
rather is hidden - "the administrator" simply makes it all work...)

  | With IPv6, one does not *need* to set up DHCP server (as much as with
  | IPv4).

That's certainly true.

  | It's apparent that the work is concentrating on making it possible
  | to do certain basic DHCP-like things without DHCP server.

Yes, but that's a bogus goal.

  | If DHCP server existed in the network -- sure, it would be ok to put the
  | data there.  But one of the points here is to avoid adding DHCP server at
  | all.

Why?   There's nothing magic about DHCP servers that make them something
to be avoided.   Installing a DHCP server is mostly just a matter of going
to your server's "what daemons do I run" facility, and enabling it.  It
isn't running the DHCP server that some people want to avoid, it is doing
the centralised data administration.  That's just as true for a DNS server
as it is for a DHCP server.   If you're going to collect and maintain the
data anyway, whether it is distributed via DHCP or DNS isn't going to bother
anyone much.   Or it wouldn't, if they really thought about it.  (DHCP
actually has a whole set of small advantages for things like this).

  | The real question is: "are all of these configurables so critical that we
  | should mandate DHCPv6 server in every network which would like to
  | autoconfigure them?".
  | 
  | IMO, the answer for at least some parts of the draft is "no, we shouldn't
  | need DHCP for them".

I agree with that.   But the answer cannot be to require the same
data served by the DNS instead.   The replacement has to be to collect
the data from a distributed system, with no central maintenance, just
like IPv6 addresses are generated by the routers advertising prefixes,
and the nodes generating the addresses.   Or by a centralised server if
the net prefers that method.   It is the same kind of choice that needs
to be permitted here, not just a choice of which particular centralised
database to use.

kre

---

From: Pekka Savola <[email-masked]>
Date: Sat, 1 Dec 2001 17:29:23 +0200 (EET)

> rather is hidden - "the administrator" simply makes it all work...)

True.  But consider -- a small site that doesn't even have a DNS server of 
its own is, well, small.  In most cases, it's no big deal configuring 
stuff by hand in every system.  With bigger sites, more centralized 
structure is needed, like this.

A problem here is that there are lots and lots of very small sites.  
Practically, if there was no way of "automatically discover" required
information, renumbering would more a few steps more difficult.

> actually has a whole set of small advantages for things like this).

DNS is a required part of working infrastructure.  DHCP is not.  Do we 
want to make it that?  I'd prefer there would be as few links in the 
requirement chain as possible.

Not that DNS is necessarily the best place to put this data in..

> to be permitted here, not just a choice of which particular centralised

I basically agree -- but the "cost" (design, implementation, etc.) of the
system is much larger that way; and it'd most probably be more complex
too.

Of course, this decision could be pushed off the hosts; for example, make
all of these things options in router advertisements, and define some
mechanisms how routers would get the data (from servers, from
configuration, ...).

---

From: Ralph Droms <[email-masked]>
Date: Sat, 01 Dec 2001 11:07:35 -0500

We're likely to see a lot of those small sites without a DNS server, run by 
unsophisticated users.  Our recent experience with small IPv4 sites - SOHO 
behind a CPE box (router/NAT) - is that they are very likely to include a 
light-footprint, full-function, low-configuration DHCP server.  Those sites 
are not very likely to include a DNS server.

In the IPv6 SOHO scenario, I see either using a distributed 
discovery/configuration mechanism in which each device in the SOHO network 
has to reach into the ISP network for configuration, or a stateless DHCPv6 
server in the CPE box that entirely or mostly autoconfigures itself.

In fact, I believe DHCPv6 would be even lighter weight than DHCPv4 in this 
scenario, exactly because of stateless autoconfig.  The stateless DHCPv6 
server, in the simplest scenario, could operate in a single-threaded, 
query-response mode, returning the same response with DNS server, domain 
name and search list to every client request.

Based on our experience with seeing DHCPv4 deployed in <$100 CPE boxes, I 
would expect stateless DHCPv6 would find its way into SOHO devices, as well.

I'm working on an implementation of stateless DHCPv6, so I can't give any 
running code results, yet.  My intuition is that stateless DHCPv6 would be 
no more difficult to implement or require any more resources from the 
device in which it runs than ICMP.

- Ralph

---

From: Matt Crawford <[email-masked]>
Date: Sat, 01 Dec 2001 13:36:23 -0600

> Why do you suggest illegal DNS strings?  Why not use a dash or a dot?

Underscores are illegal in *hostnames*, but not elsewhere in DNS.

---

From: Jim Bound <[email-masked]>
Date: Sun, 2 Dec 2001 22:46:06 -0500 (EST)

Pekka,

What we do here is build standards.  That have no known bugs or
interoperability problems.  What we don't do here is tell the market what
they can and cannot deploy. We will build standards that support stateless
and stateful mechanisms across the IPv6 spectrum, we will have
translation, tunneling, and hybrids of such mechanisms.  Our job is to
make sure they will work as best we can tell on paper and abstractly.  But
it is not our job to tell the customer what to use in their networks.
Besides they are not listening to us and never did in the first place
except maybe for a few key pivotal points on the Internet like Address
Registry debate and root DNS servers et al.

regards,
/jim

---

From: "Jim Fleming" <[email-masked]>
Date: Sun, 2 Dec 2001 22:51:28 -0600

----- Original Message ----- 
From: "Jim Bound" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: "Robert Elz" <[email-masked]>; <[email-masked]>
Sent: Sunday, December 02, 2001 9:46 PM
Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-discovery-03.txt 

> Registry debate and root DNS servers et al.

The ICANN Board describes the IETF as their "Engineering Division".
"ICANN represents that it has no authority to implement new TLDs"
http://www.icann.org/tlds/correspondence/esi-v-icann-13nov00.htm 

ICANN and the IETF appear to be mostly focused on "experimental",
Proof-of-Concept, research projects. The new TLD deployments seem
to be mostly operational fiascos, years overdue, late, corrupted databases,
confused consumers, etc. There is little focus on serious, reliable, redundant
systems, etc. If there is a market, serious companies will deploy the needed
infrastructure, as the experiments draw people to the new TLDs.
http://www.dot-biz.com/Registry/Proof-Of-Concept

For people interested in building on IPv4...this may help...
http://www.dot-biz.com/IPv4/Tutorial/
The Netfilter Project: Packet Mangling for Linux 2.4
http://netfilter.samba.org

Jim Fleming
http://www.IPv8.info
IPv16....One Better !!