On Mon, 16 Jul 2001 [EMAIL PROTECTED] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 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 PROTECTED]
--------------------------------------------------------------------
