Hi,
I'm adding v6ops to Cc: because it'd be useful to get some input on
from the 6to4 operational experience here to gauge whether the
mechanism addresses sufficiently large subset of the problem.
Based on your note, which I agree with, I guess the questions we
should be asking are:
1) "who are the target users of this spec?"
1.b) "is the mechanism good enough for _them_?"
2) "is there a sufficiently important subset of 6to4 users for which
this is not an appropriate solution?"
2.b) "do we need to have a solution for them?"
My answers to these would be,
1) 6to4 power users with static IPv4 address
1.b) yes
2) "regular" 6to4 users and/or 6to4 users w/ dynamic IPv4 address
2.b) unknown at the moment. Not sure if a scalable one could exist
(and anyone would have enough steam to create one)
Inline..
On Fri, 10 Mar 2006, Mark Andrews wrote:
While I am happy enough for draft-huston-6to4-reverse-dns-04.txt
to proceed it should be pointed out that this is a suboptimal
solution to the problem.
1. It requires rapid establishment of a the child zone on
multiple servers. There currently is no standardised method
for doing this.
Yes, it's not clear whether this is considered a bug or feature:
the mechanism is basically unusable (requiring a lot manual config)
in all the sane authoritative server DNS configurations if you have
a dynamic IP address (even if the dynamic IP address changed only
infrequently) due to the manual overhead.
But this may also discourage folks w/ dynamic IPs from
participating, which might lessen the scalability concerns.
2. It does not use DNS itself as the update mechanism.
A all DNS solution would be to use a DNAME record rather
an NS RRSet to perform the delegation funtion in the method
described in RFC 2874. This remove the need for rapid
establishment of the child zone as it will already exist
and be populated.
....
This method was presented to the author several years ago
but was not listed in the alterative rejected. It would
be interesting to know why it was not listed as a alternative
and as to why it was rejected.
I agree this could possibly be mentioned; the cause it has been
omitted may be that that it wasn't listed in the original draft
discussing the alternatives; did you send comment to Keith Moore
while he still updated the document?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings