Thanks for responding. Trying to clarify further... (Michael -- we discussed this last December: do you have pointers to the work on adding entirely new records (rather than updating) to the zones, as noted in section 6? Maybe some others know more of this than me...)
I've updated the working copies in the same URL: http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre-diff.html Note to DNSOP WG: there has been some discussion on IPv6 WG what to say about DNS (forward/reverse) of the new "site-local replacement" described in draft-ietf-ipv6-unique-local-addr-03.txt. I've avoided adding text on this as it's a bit of moving target (in AD evaluation:WG followup at the moment), but if people have opinions about that, feel free to shoot them. (Note that Appendix A already lists considerations with site-local addresses, but the situation is slightly different with unique local addresses.) On Wed, 7 Apr 2004, Ralph Droms wrote: > 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. OK, let me try to reword this to: <t><xref target="RFC3056">6to4</xref> 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.</t> <t>Note that it does not seem feasible to provide reverse DNS with the other automatic tunneling mechanism, <xref target="I-D.huitema-v6ops-teredo">Teredo</xref>; this is because 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.</t> (note that I'm intentionally not mentioning iSATAP here as it derives the address from an advertised v6 prefix, so there is nothing new there.) Better? [[ note to those who may be watching: I also added a paragraph of discussion on draft-huston-6to4-reverse-dns-00.txt here ]] > 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. Yes, and to little resolution. I'll raise this separately to see what people think. > 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? Good question. I'm actually unfamiliar with this. I received similar input from Michael Patton, which I've Cc:'ed. Maybe he could provide some pointers. > 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. I'm familiar with some deployments of DHCPv4, and in almost all of them, you use pre-defined names. I assume it will likely be similar with DHCPv6. Clarified: <t>With DHCPv4, the reverse DNS name is typically already inserted to the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One can assume similar practice may become commonplace with DHCPv6 as well; all such mappings would be pre-configured, and would require no updating.</t> Or other suggestions? > 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)" Yes, changed to that. > 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. Yes, but there is difference if the disused addresses are being reused. That is, with SLAAC you can pretty much be sure that nobody will be reusing your EUI64. I've added a note as the last paragraph: <t>If disused addresses were to be reassigned, host-based DDNS reverse updates would need policy considerations for DNS record modification, as noted above. On the other hand, if disused address were not to be assigned, host-based DNS reverse updates would have similar considerations as SLAAC in <xref target="rev_slaac"/>. Server-based updates have similar properties except that the janitorial process could be integrated with DHCP address assignment.</t> > 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. Handing out such addresses, IMHO, makes no sense, as you would have to renumber the host if its MAC address changes, even though you wouldn't need to introduce this dependency. Of course, one could just assign addresses using some other policy so that the addresses would not need to be reassigned. I took this as generic discussion and did not make changes. The text has been reworded in any case to deal with more than just a simple "dense" assignment policy. -- 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
