Subject: I-D ACTION:draft-kitamura-ipv6-name-auto-reg-00.txt

From: [email-masked]
Date: Mon, 16 Jul 2001 06:58:45 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Domain Name Auto-Registration for Plugged-in IPv6 
                          Nodes
	Author(s)	: H. Kitamura
	Filename	: draft-kitamura-ipv6-name-auto-reg-00.txt
	Pages		: 16
	Date		: 13-Jul-01
	
This document describes a scheme of 'Domain Name Auto-Registration
for Plugged-in IPv6 Nodes' mechanism that makes it possible to
register both regular and inverse domain name information of plugged-
in IPv6 nodes to DNS servers automatically.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-name-auto-reg-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-kitamura-ipv6-name-auto-reg-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-kitamura-ipv6-name-auto-reg-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 16 Jul 2001 19:13:53 +0300 (EEST)

> 	Title		: Domain Name Auto-Registration for Plugged-in IPv6

Some thoughts,

The text has, in 3.5:
---
   All candidate information (detected addresses) for registration is
   checked by using inverse DNS resolving queries of them. If there is
   FQDN information that matches the detected address, such registration
   candidates are not registered.
---

There are problems with similar to "file locking" with this approach.
They could be minimized a little if the inverse query MUST be authorative,
ie. the response MUST not be cached, perhaps?

I'm also worried about possible DoS considerations of the auto-reg method,
as it assumes DAD packets always signify a new address; nothing prevents a
malicious node from generating thousands of them.  This is addressed to
some extent in the draft.

Another issue DAD as a method of detecting new node in itself.  There have
been some discussions that you might not need to perform DAD for
EUI64-based addresses.  This would change the detector balance (and
working methods) considerably.  In addition, it's not necessary to perform
DAD (at the moment) but for just the addresses with different host-id.
Multihoming or multiaddressing considerations could change how this works
a bit.

Detectors and Registrars should have (an optional) ability to decide
whether the address has been spoofed.  For example: registrar 1 has
detectors A and B, from networks (separate links) 3ffe:ffff:0:A::/64 and
3ffe:ffff:0:B::/64, respectively.  HostA registers an address from network
B, and registrar 1, being allowed to make the changes dor both network
blocks, happily complies.  Detectors or Registrars have no way of knowing
whether 1) DAD produced a collision, or 2) "autoconfiguration worked fine
and the system is globally available".

I'm not sure if this is actually a really big problem, but one more straw
to the "disallow source spoofing" hat.

-- 
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]
--------------------------------------------------------------------