Subject: IPv6 DNS Autoconfiguration

From: Jaehoon Jeong <[email-masked]>
Date: Mon, 14 Jul 2003 01:43:25 -0700 (PDT)

Hi, DNSOP members! :-)
Beforehand, I'd like to summarize my talk for today's
discussion about DNS Discovery and Autoconfiguration.

I'll present IPv6 DNS autoconfiguration today
afternoon.
IPv6 DNS autoconfiguration consists of two functions;
a) RA-based DNS Discovery and b) Host DNS Name
Auto-Registration.
 
Through RA DNS option, IPv6 host can find out DNS
information, such as Recursive DNS Servers' addresses
and DNS Zone Suffix.
It is very simple and necessary mechanism, I think.
With the announced DNS zone suffix, IPv6 host can
generate its host DNS name based on its preferred
user-ID. Also, it can register its DNS name and IPv6
address with the announced DNS server, through DNS
dynamic update.
The registration is performed by the IPv6 host, not
another Registrar.
In my scheme, any unidentified host can register its
DNS information in advertised DNS server. To minimize
the damage of DNS dynamic update, I define a new flag,
AR (Auto-Registration), in Header section of DNS
dynamic update message.
This bit indicates that any host can add its AAAA/PTR
resource records in DNS server and modifiy or delete
only its resource records, not others' resource
records. Therefore, a little extension to DNS Dynamic
Update is necessary.
You can find my presentation material in the following
links;

http://www.adhoc.6ants.net/~paul/data/ietf57-dnsop-ipv6-ra-dns-autoconf-00.pdf

http://www.adhoc.6ants.net/~paul/data/ietf57-dnsop-ipv6-ra-dns-autoconf-00.ppt

I would like to know if DNS autoconfiguration should
consider both DNS discovery and Host DNS name
auto-registration or not, namely separate documents.
In today's talks, I hope, some drafts about DNS
autoconfiguration will be accepted as working items.
Thanks.

/Jaehoon (Paul)

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Tim Chown <[email-masked]>
Date: Mon, 14 Jul 2003 10:14:31 +0100

Hi,

It's good to see a DNS discovery method for a statelessly autoconfiguring
network back on the table.

I think the two functions should be in separate documents.  It would be nice
to push through the DNS discovery method, and not have it dependent on the
registration aspect (which many hosts will not need).

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 14 Jul 2003 23:19:57 +0859 ()

Jaehoon;

> discussion about DNS Discovery and Autoconfiguration.

Autoconfiguration, as expected by IPv6 folds, is just impossible
that it is a pity that DNSOP WG is contaminated.

Autoconfiguration is easy on a single link isolated from the
Internet. But, that's all.

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Mon, 14 Jul 2003 18:13:05 +0300 (EEST)

> Internet. But, that's all.

FWIW, my opinion on the subject;

DHCPv6-lite has been proposed as a means how to fix this problem.

My issue with DHCPv6-lite is that DHCPv6 spec is some 89 pages, and most 
options are some 5 (or more) pages more, each.

Even though DHCPv6-lite is only a subset of that, it still requires 
reading, understanding etc. a lot of it.  It's much more difficult to get 
the "big picture" of DHCPv6-lite this way.

Now, if we had specified DHCPv6 without address assignment (like I
suggested, but that's beside the point), and put all of the stateful stuff
("cruft") in a separate "extension" RFC, we'd be talking about an entirely
different issue.

I was a very simple to implement, robust mechanism that's easy to 
understand.  Reading 20 selected pieces of a large document fills that 
requirement, IMHO.

I want a spec which is simple and clear, and less than 15-20 pages long.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Mon, 14 Jul 2003 20:08:31 +0300 (EEST)

> I was a very simple to implement, robust mechanism that's easy to 
    ^^^

want, that this :-)

> understand.  Reading 20 selected pieces of a large document fills that 

DOES NOT fill that requiremenent, that is..

I must have been really hurry when writing this, should have proof-read it 
first.. :/

---

From: Bill Manning <[email-masked]>
Date: Mon, 14 Jul 2003 12:08:58 -0700 (PDT)

mind, I am very concerned w/ the goofy IPR/Note Well restrictions,
 so posting/participating is -very- infrequent.  but to pose a query
 to the assembled multitude:

 BIND, a common DNS implementation has the ability to apply access
 controls as a local policy matter as to who can and can not use
 a "recursive resolving nameserver" or what ever it was that Rob said 
 it was.  If one uses the RA/ND techniques, how does one expect to
 extract the local DNS policy information before handing out server
 info via the RA/ND method?

 this weakness was not touched on during Bob Hindons presentation
 and I did not stay for the rest of the sessions festivities

% On Mon, 14 Jul 2003, Masataka Ohta wrote:
% > > Beforehand, I'd like to summarize my talk for today's
% > > discussion about DNS Discovery and Autoconfiguration.
% > 
% > Autoconfiguration, as expected by IPv6 folds, is just impossible
% > that it is a pity that DNSOP WG is contaminated.
% > 
% > Autoconfiguration is easy on a single link isolated from the
% > Internet. But, that's all.
% 
% FWIW, my opinion on the subject;
% 
% DHCPv6-lite has been proposed as a means how to fix this problem.
% 
% My issue with DHCPv6-lite is that DHCPv6 spec is some 89 pages, and most 
% options are some 5 (or more) pages more, each.
% 
% Even though DHCPv6-lite is only a subset of that, it still requires 
% reading, understanding etc. a lot of it.  It's much more difficult to get 
% the "big picture" of DHCPv6-lite this way.
% 
% Now, if we had specified DHCPv6 without address assignment (like I
% suggested, but that's beside the point), and put all of the stateful stuff
% ("cruft") in a separate "extension" RFC, we'd be talking about an entirely
% different issue.
% 
% I was a very simple to implement, robust mechanism that's easy to 
% understand.  Reading 20 selected pieces of a large document fills that 
% requirement, IMHO.
% 
% I want a spec which is simple and clear, and less than 15-20 pages long.
% 
% -- 
% Pekka Savola                 "You each name yourselves king, yet the
% Netcore Oy                    kingdom bleeds."
% Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
% 
% #----------------------------------------------------------------------
% # To unsubscribe, send a message to <[email-masked]>.
% 

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Jaehoon Jeong <[email-masked]>
Date: Mon, 14 Jul 2003 12:22:46 -0700 (PDT)

--- Masataka Ohta <[email-masked]>
> Internet. But, that's all.
At least, DNS discovery based on RA is easy and
necessary in IPv6 wired and wireless networks
connected to the Internet, I believe. 
Especially, in the environments where IPv6 address
configuration is performed by IPv6 stateless address
autoconf, such as HMIPv6 and NEMO, RA-based DNS
Discovery is faster than DHCPv6-based DNS Discovery.
IMHO, both DHCPv6-based approach and RA-based approach
are necessary, depending on the situations, just like
IPv6 address autoconfiguration.

/Jaehoon

---

From: Jaehoon Jeong <[email-masked]>
Date: Mon, 14 Jul 2003 12:35:13 -0700 (PDT)

/Jaehoon