ietf
[Top] [All Lists]

Re: IPv4 Outage Planned for IETF 71 Plenary

2007-12-21 17:13:37

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(_at_)ietf(_dot_)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: Mark_Andrews(_at_)isc(_dot_)org

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>