Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt

["S. Daniel Park" <[e-mail]>]

Sorry for being too late comment

Just references nits:

[27]  Droms, R., "Stateless DHCP Service for IPv6",
         draft-ietf-dhc-dhcpv6-stateless-04 (work in progress), January
         2004.


Would be RFC 3736 April 2004.



- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, Samsung Electronics.
----- Original Message ----- 
From: "Pekka Savola" <[e-mail]>
To: "Ralph Droms" <[e-mail]>
Cc: <[e-mail]>; "Michael A. Patton" <[e-mail]>
Sent: Friday, April 09, 2004 3:33 PM
Subject: Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt


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


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