[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "RFC 2461bis" issue: DNS configuration

Following up on Pekka's e-mail, the DNS configuration problem now belongs to
the dnsop WG, and followups to this thread should be posted to dnsop@cafax.se.

Most (if not all) of the issues from this thread have already been discussed
at the dnsop WG meeting in Vienna and on dnsop@cafax.se  Please take a look
at the minutes from the Vienna WG meeting,
http://ietf.org/proceedings/03jul/index.html, and the dnsop mailing list
archive, http://www.cafax.se/dnsop/maillist, for more information.

There are lots of problems in this space we haven't solved yet, like how to
do secure updates of PTR records for IPv6 hosts that use stateless address
autoconfiguration - seems to me we ought to apply our spare cycles to those
unsolved problems instead of inventing new solutions to solved problems...

- Ralph

At 12:03 AM 10/24/2003 +0200, Iljitsch van Beijnum wrote:
>On 23 okt 2003, at 9:39, Tim Chown wrote:
>>It will be interesting to see what the Moonv6 work may have to say in 
>>this area, as the issue I'm sure will have been encountered there.
>>There are still very few people working in networks where IPv6 transport 
>>DNS lookup is a requirement, hence this issue has seen slow progress.
>I know, and in practice there won't be many hosts that run just IPv6. But 
>what good is a new protocol if it can't stand on its own two feet and 
>needs its predecessor to provide crucial functions?
>At least the new MacOS that's coming out tomorrow supports DNS transport 
>over IPv6, making it possible to run IPv6-only. This is pretty cool.
>>I am in the RA camp, but I agree DHCPv6 will be used for other things
>>(e.g. NTP server), so in cases where a DHCPv6 server is present it will 
>>be able to be used for resolver discovery.  But I believe we should have 
>>a RA based method also.
>A strong argument against using DHCPv6 would be that stateless 
>autoconfiguration definately has the edge over DHCP so we can expect very 
>many people to continue using autoconf even when DHCP implementations 
>become available. Requiring DHCP in addition to stateless autoconf for 
>just one thing that can also be done using mechanisms that autoconf uses 
>would mean unnecessary complexity and delays.
>But it shouldn't be one or the other. We want/need both.
>>The general thrust of the DHCPv6 camp argument is that in any situation 
>>where a router is configured to pass DNS info in a RA extension it could 
>>equally be configured to do so using DHCPv6 (Lite), or could forward to a 
>>DHCPv6 server using the DHCPv6 relay agent function.
>I doubt that many people will be using DHCP servers with IPv6. The reason 
>to use them in IPv4 is so you can have stable addresses across reboots. 
>Stateless autoconfiguration already supports this much better than DHCP 
>ever did. And let's not forget that autoconf has been available for years 
>while DHCPv6 is just now becoming somewhat available.
>>The second argument used by the DHCPv6 camp is that having two methods 
>>may lead to complexity, and problems in troubleshooting.
>That would be a good argument to kill DHCPv6 altogether. Having to run 
>autoconf for the address and DHCP for nameservers is exactly the 
>complexity we should avoid.
>>The third is a fear of creeping featurism - where is the line over which 
>>you don't step for RA extensions?   DNS resolver?  Search path?
>When was the last time your browser couldn't load a page because the NTP 
>server wasn't found?
>IETF IPv6 working group mailing list
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6