> 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@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
