(Following up on http://darkwing.uoregon.edu/~llynch/dnsop/msg02710.html: Pekka, thanks for your response. I agree with your responses to any issues from the previous message that I haven't mentioned here.)
Comments on draft-ietf-dnsop-ipv6-dns-issues-05pre.txt:
I'm still having trouble understanding:
2.3 6to4 Addresses
6to4 [10] specifies an automatic tunneling mechanism which maps
a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
Providing reverse DNS delegation path for such addresses is a
challenge. Note that similar difficulties don't surface with
the other automatic tunneling mechanisms. In particular,
providing reverse DNS information for Teredo [11] hosts does not
seem feasible; the IPv6 address is based on the IPv4 address and
UDP port of the current NAT mapping which is likely to be
relatively short-lived.The last sentence seems to contradict the preceding sentence.
I don't think section 5.2 accurately reflects the current state of specifications and discussion about recursive DNS resolver configuration:
5.2 Recursive DNS Resolver Discovery
Recursive IPv6 DNS resolver discovery is a subject of active
debate as of this writing (March 2003): the main proposed
mechanisms include the use of well-known addresses [24], the use
of Router Advertisements to convey the information [25], and
using DHCPv6 (or the stateless subset of it [26]) for DNS
resolver configuration [27]. No consensus has been reached yet. Note that IPv6 DNS resolver discovery is not required for
dual-stack nodes in dual-stack networks as IPv6 DNS records can
be queried over IPv4 as well as IPv6.I think the current situation regarding recursive DNS resolver configuration would be more accurately reflected by the following paragraph:
5.2 Obtaining a list of DNS Recursive Resolvers
A host can be configured with a list of DNS recursive resolvers
through the DHCPv6 "DNS Recursive Name Server" option [RFC3646].
This option can be passed to a host through a subset of DHCPv6
[RFC3736]. Two alternative mechanisms are under consideration:
the use of well-known addresses [21] and the use of Router
Advertisements to convey the information [22].
I know this paragraph has been discussed before. It would be good to get other WG input to make sure the text reflects WG consensus on the subject.
In section 6, would it be possible to add a reference to work on the problem of adding a name into a DNS zone for readers (such as myself!) who are unfamiliar with the problem area? Is there any guidance that this document can give regarding adding a new name to a zone?
Comments on section 7.4:
7.4 DDNS with DHCP
With DHCP, the reverse DNS name is typically already inserted to
the DNS that reflects to the name (e.g., "dhcp-67.example.com").
All of these mappings are pre-configured, and require no
updating.Are you referring to DHCPv4 or DHCPv6 here? It would be good to get input based on deployment experience to confirm that this strategy is "typically" used for DHCPv4. Of course, we have little deployment experience with DHCPv6 to know whether pre-configuration will be used for IPv6 PTR records.
If a more explicit control is required, similar considerations as
with SLAAC apply, except for the fact that typically one must
update a reverse DNS record instead of inserting one (if a denser
address assignment policy than with SLAAC is adopted) and
updating a record seems like a slightly more difficult thing to
secure. However, it is yet uncertain how DHCPv6 is going to be
used for address assignment.Would the parenthetical phrase be more clearly stated as "(if an address assignment policy that reassigns disused addresses is adopted)"
Note that when using DHCP, either the host or the DHCP server
could perform the DNS updates; see the implications in Section
6.2.Is there a parallel between host updates of DHCPv6-assigned addresses and the discussion in section 7.3, as well? It might be worth mentioning that the DHCPv6 server can perform the PTR record cleanup if the DHCPv6 address assignment is used.
Finally, in response to your comments on section 7.4:
> Section 7.4, second paragraph: What is a "denser address assignment > policy"? As we have little or no experience with address assignment > through DHCPv6, I think it is premature to anticipate how DHCPv6 will > be used. I can imagine, for example, that DHCPv6 might be used to > assign addresses that look just like SLAAC addresses - the advantage > to the use of DHCPv6 being centralized registration and accounting for > addresses and devices.
Well -- looking at those that seem to want to use DHCPv6, their main point appears to continue doing what they're doing with v4. The logical conclusion of that is that using relatively dense allocations (though not necessarily every address sequentially, until running out, as with v4) is something they're familiar with and want to go on doing.
My experience has been that network admins that want to use DHCPv6 for address assignment are primarily interested in registering addresses and accounting for devices on the network, rather than wanting to do sequential address assignment from a pool of available addresses. Those admins would be happy with a DHCPv6 server that hands out an address constructed in the same way as a SLAAC address.
- Ralph
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
