> On Fri, 21 Dec 2007, Stephane Bortzmeyer wrote: > > > Among the many dummy things he mentions, this one is probably the best > > :-) May be someone should tell him there are name resolution services > > (and they existed even before the DNS)? > > But someone has to configure those things. That most likely will mean > humans having more difficulty typing longer addresses accurately. > Sometimes the resolution service is not working. Trouble shooting > generally means digging down to lower levels, etc. No. Something needs to configure the DNS. All the human should do is give the box a name and perhaps authorise the initial update which add the public KEY record associated with the box to the DNS. After that the box can update its own records using SIG(0). For reverse DNS, having a TCP connection is about the level of authentication required to add/replace a PTR record. This works with both autoconf and DHCP. > Perhaps in some future time, we'll have applications which just do this > stuff more effectively. In the interim, I can only be grateful for my USB > memory stick as an improvement over postits as a mechanism for carrying IP > addresses around. cut-and-paste works well. :-) > Given the sorry state of DHCP / DNS integration (I work with and around > common products used on Windows and Linux) ... I find a lot of bogus data > accrues over time ... I find automatic updates which can't cope with > laptops which move from wired to wireless. I've discovered that DHCP (as > deployed at least) can't provide a name suffix search list, etc. That's implementation not protocol. Complain to you vendor. > As a network operations groupie, I can understand why a network operator > might not feel happy about having to embrace IPv6. They deal with what > curretly is, not what might be. The problem is that they don't deal with what is there. They don't attempt to deploy so that don't find the product flaws so they can't report them. The vendors then operate in a vacum of real data. The IETF itself operates in a vacum as it is hard to see the missing pieces of protocol when there are very few real attempts at deployment. From a protocol perspective IPv4 and IPv6 provide pretty much the same functionality. The packets flow. The sessions connect. The rest really is up to product vendors and users to request IPv6 support. > So rather that attacking folks out where the rubber meets the road, we > need to listen so we can understand their root problems and then we need > to get integrated solutions in place. > > Having one or more carefully planned IPv6 network operations working > sessions over the next year and using the IETF meetings as the focal point > is a good way to gather experience, clarify requirements for > infrastructure tools, etc. > > Disrupting a meeting funded for a different purpose will/would be an > offensive colossal waste of resources. > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf