On Fri, 23 Jul 2010 09:20:54 -0400 "STARK, BARBARA H (ATTLABS)" <bs7...@att.com> wrote:
> > To summarize, the current document > > - retains SLAAC as a MUST > > - lists DHC (for address config) as a MAY > > - makes DHC for other configuration a SHOULD. > > - lists rfc5006bis (DNS RA Config) as a SHOULD > > I would prefer if nodes were required (MUST) to support one or the other > mechanism for DNS config. Given SLAAC is a must, it would probably make > the most sense to make rfc5006 the must. > > My goal is predictability. From a service provider help desk > perspective, if I'm trying to troubleshoot a customer who can't get > their Internet connection working, and I discover that they can ping an > IPv4 address (and somehow also test they can ping an IPv6 address), but > not a FQDN, then my next steps are much easier if I can predict how DNS > is acquired. This is not an uncommon scenario in IPv4. Having to figure > out if the device supports DNS by RA or DHCPv6, and has one or the other > or both enabled, adds unnecessary steps and complexity to > troubleshooting. > It probably doesn't add much to this discussion, however there is a third option for DNS - manual configuration. In my experience, it seems in IPv4 for a common troubleshooting step for the helpdesk to manually configure DNS IP addresses. The existing settings are not even queried i.e. "robotically" the DNS settings are changed from being automatically configured to manual. That may have either been because it was specified in a troubleshooting procedure, or through rumour - it may have worked successfully often enough that it gets spread throughout the helpdesk as a step that has a higher chance of succeeding. As helpdesks tend to be driven more by phone calls answered, and numbers of customers back online, the quality of true cause identification and troubleshooting suffers. A few years back, when wanting to change the DNS IP addresses for a 50K+ ADSL subscriber base, I thought we'd need to preserve the old IP addresses for in the order of at least 5 years because of this manual setting of DNS addresses. It's a shame because we wanted to free up that /24 (an old Class C) for use somewhere else, and the two legacy DNS IP addresses were the only ones that continued to be in use. With two dynamic methods of acquiring DNS under IPv6, and the possibility that they could present different DNS addresses, that may create even more of an incentive for helpdesks to override the automatic DNS settings with manual ones. Validating the automated DNS addresses is probably more work and therefore time on the phone with the customer. With luck, the length and obscurity of an IPv6 address might contribute to preventing that, but I wouldn't bet on it. > The routers the service provider ships would also have to be default > configured to provide the identical DNS info through both mechanisms. > > All of this extra effort could be avoided (and better user experience > provided) if one of the mechanisms were required. I agree with Barbara. Twice as many automated mechanisms creates the opportunity for twice as many errors. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
