Subject: [dnsop] WGLC for draft-huston-6to4-reverse-dns-04.txt

From: Peter Koch <[email-masked]>
Date: Thu, 9 Mar 2006 20:36:24 +0100

Dear WG,

the document "6to4 Reverse DNS Delegation Specification" has been on our
table for quite some time. As explained in the Vancouver meeting minutes
<http://www3.ietf.org/proceedings/05nov/dnsop.html>, the IAB v6 ad hoc
group has asked this WG to review the draft.
Please note that while the document describes a deployed service,
changes to the document are of course possible.

This is to iniate a

	WG Last Call to end on Friday, 2006-03-24 24:00 UTC

The intended publication status for draft-huston-6to4-reverse-dns-04.txt
is "Informational".

Please send comments and statements of support or objection to the
WG mailing list. We'd like to ask for at least five substantive reviews.

-Peter
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Mark Andrews <[email-masked]>
Date: Fri, 10 Mar 2006 09:52:18 +1100

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.

	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.

	A similar level of authentication could be applied to the
	acceptance criteria for UPDATE requests to add DNAMEs.
	i.e. TCP + source address within the delegated block.

	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 do believe that DNAME will be a great aid to renumbering
	in the future despite the flawed logic in RFC 3364 stating
	otherwise.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Mar 2006 03:18:01 +0200 (EET)

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

> 	multiple servers.  There currently is no standardised method

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.

> 	establishment of the child zone as it will already exist
....
> 	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
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Mar 2006 03:24:01 +0200 (EET)

> WG mailing list. We'd like to ask for at least five substantive reviews.

I support the spec.

I have three bigger issues with the doc, described below but easily 
fixable, as well as a couple of editorial comments.

1) "password-based authentication deployed but not documented"
2) "is it OK to have all the DNS servers at the 6to4 site?"
3) "ability for upstream to block 6to4 delegations is inappropriate"

In addition, there is more of a meta-question raised by Mark Andrews. 
In my opinion, the real issue is whether the whether this solves the 
problem for sufficiently large/interesting subset of 6to4 users or 
whether we need something else instead or in addition.

substantial
-----------

1) "password-based authentication deployed but not documented"

    The delegation system is proposed to be self-driven by clients
    residing within 6to4 networks.  The server's delegation function is
    proposed to be accessible only by clients using 6to4 IPv6 source
    addresses, and the only delegation that can be managed is that
    corresponding to the /48 prefix of the IPv6 source address of the
    client.

==> the latter sentence does not match the service as implemented today. 
It's possible to access the delegation function by optional password
authentication. I'd suggest one of the following, with personal bias towards
either of the first two:

  a) describe the auth service as well (I'd like security folks review it),
  b) remove the auth service from the implementation, or
  c) massage the text a bit so that it doesn't imply normativeness ("..
additional authentication methods may be used as necessary..")

2) "is it OK to have all the DNS servers at the 6to4 site?"

  The delegation servers are
    checked by the delegation manager to ensure that they are responding,
    that they are configured consistently and are authoritative for the
    delegated domain.

(also a bit later..)

==> is it OK that all the auth servers are under the same 6to4 prefix (but
different IPs)?  This seems something that should probably be checked and
prohibited, as if one server would go down, the other would also likely do
so...

3) "ability for upstream to block 6to4 delegations is inappropriate"

    There may be circumstances with an IPv4 address controller wishes to
    "block" the ability for "children" to use this 6to4 scheme.
    Scenarios that would motivate this concern would include situations
    when the IPv4 provider is also offering an IPv6 service, and native
    IPv6 should be deployed instead of 6to4.  In such circumstances the
    2002 zone operator should allow for such a delegation blocking
    function upon application to the delegation zone operator.

==> I believe this doesn't make sense on various levels.  First of all, the
operators shouldn't be in the business of specifying what their users can or
can't do: if they wish to block 6to4, they can just put in ACL to block
proto-41 (or appropriate portions of it) -- there is nothing needed in the
delegation system to provide additional capabilities for this. 
Additionally, it's perfectly valid scenario to run 6to4 as an optimization
mechanism (see RFC3956 for details), on the side with native addressing. 
This could block reverse DNS delegations in such cases.

In short, the whole paragraph should be removed as unnecessary and even
harmful.

editorial
---------

    domain.  The client is primarily authenticated by it's source address

==> s/it's/its/

    This address structure allows any site that is connected to the IPv4
    Internet the ability to use IPv6 via automatically created IPv6 over
    IPv4 tunnels.

==> "any site" is not accurate as the site is required to have a public v4
address; minor reword..

    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 [RFC2136].

==> it may be worth spelling out that you're talking about DNS updates
between the web interface and authoritative servers; the clients don't
perform any DNS updates.

    o  IPv4 DHCP-based 6to4 sites could inherit nonsense reverse entries
       created by previous users of the DHCP address.  In this case the
       client site could request delegation of the reverse zone as
       required.

==> it may be worth adding a forward pointer to the periodic cleanup check,
which should mitigate this problem a bit.

7.  References

==> rename this to Informative References and maybe put RFC3056 under
normative references.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 22 Mar 2006 08:52:28 +1100

>         in the future despite the flawed logic in RFC 3364 stating

This comment reflects the manner of implementation of the
population of the zone as distinct from the described method of
how instructions of a zone delegation are accepted.

I don't believe that DNAMEs are ruled out of scope here, but
it would be good to see how our common understanding of
RFC 3364 evolves, and in particular it will be interesting to
learn whether the assertion that this RFC represents
"flawed logic" becomes part of the conventional wisdom
about the DNS in the future.

regards,

    Geoff

.

---

From: Peter Koch <[email-masked]>
Date: Tue, 28 Mar 2006 22:43:23 +0200

Dear WG,

> The intended publication status for draft-huston-6to4-reverse-dns-04.txt

since a significant number of people in Dallas expressed interest in this
draft an committed to a review, the WGLC will be extended and shall end

	Friday, 2006-04-07 24:00 UTC

Please send comments to this list.

-Peter
.