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" <[EMAIL PROTECTED]>
To: "Ralph Droms" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Michael A. Patton" <[EMAIL PROTECTED]>
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
