Hi�
This is a good start; requires a bit of cleanup, but the concept seems sound and should have already been deployed a year ago. Let's try to get this moving!
substantial -----------
It is proposed that the secure web servers be operated on a dual-stack IPv4 / IPv6 server. The service is to be available on a) an IPv4 address (instructions only), b) a native IPv6 address (instructions plus delegation service) and c) a 6to4 address (instructions plus delegation service).
==> pardon me, but b) appears to be inconsistant with the other part of the spec. For a native v6 address, there should be _only_ instructions, correct?
==> the current version at 6to4.nro.net also seems to be having unnecessary (and even dangerous) features like user/password authentication for "remote access". Those should be removed.
semi-editorial/substantial --------------------------
2.5 Selecting a Reasonable Approach
It would appear that the most reasonable approach is to support a model of conventional standard delegation.
==> (rhetorical question) do the RIRs provide reverse delegation services to those end-users (e.g., homes) whose ISPs don't want to provide such services? I don't think so -- so, AFAICS, the world "conventional" does not quite apply here and something else should be used instead.
3. 6to4 Networks Address Use
==> in this section, it is worth stating that the degenerate case of a 6to4 router is a single host. That's probably the most common case of 6to4 out there right now...
The benefits of this proposed structure include a fully automated mode of operation. The service delivery is on demand and the system only permits self-operation of the delegation function.
The potential issues with this structure include: [...]
==> there has to be _some_ clean-up process for those 6to4 prefixes which are from dynamic address space, are set up, change an address, and then can't remove the service. What should that be? Maybe it might make sense to develop a periodic checker (e.g., once a week) that would check that the name servers are still there and serving the zone. It wouldn't be perfect, but assuming the users would remove the master zone when they have to renumber, it would at least catch _something_..
o It is also conceivable that an enterprise network could decide to
use 6to4 internally in some form of private context, with the
hosts only visible in internal DNS servers. In this proposed
mechanism the reverse delegation, if desired, would need to be
implemented in an internal private (non-delegated) corresponding
zone of the 6to4 reverse domain space.==> I'm having hard time seeing this as worth mentioning (at least at this length). Most enterprise networks run NAT internally, and 6to4 won't work there, and the rest can just set up their own zone if they want to. Doesn't seem to be worth mentioning here.
In such circumstances the 2002 zone operator should allow for such a delegation blocking function upon application to the delegation zone operator.
==> I don't understand what this means, and frankly, I'm not sure if this is even any kind of concern. If someone doesn't want this, he can just block the access to 6to4.nro.net, problem solved locally ?
For maintenance of the reverse delegation zones it is proposed to maintain an email contact point for each active delegation, derived from the zone's SOA contact address, or explicitly entered in the delegation interface. This contact point would be informed upon any subsequent change of delegation details.
==> I see no reason to have the ability to add an explicitly entered email address, just problems. Anyone setting up the delegation can already put any email address they want in the SOA record. Just drop this feature, I don't think it has any real use.
7 References
==> the references need to be split. Watch out for [3] though. Currently you're referring to it sufficently extensively that it maybe should be a normative reference.. but the doc is never going to be published, so you may need to make this one a bit more self-contained.
editorial ---------
+-------------+
IPv6-in-IPv4 packets (A)| | IPv6 packets
------------------------| 6to4router |--------------------------
| | | | | | |
+-------------+ local IPv6 clients==> s/6to4router/6to4 router/
The zone files containing the end site delegations are proposed to be operated with a TTL (configured to be a time value in the scale of hours rather than days or weeks), and updates from delegation requests are to be made using incremental DNS updates [2].
==> replace ()'s with commas, or something else? difficult to parse now..
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
