Subject: [dnsop] draft-huston-6to4-reverse-dns-03 comments

From: Pekka Savola <[email-masked]>
Date: Sun, 6 Mar 2005 17:52:23 +0200 (EET)

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