Re: IPv4 Outage Planned for IETF 71 Plenary

Mark Andrews <Mark_Andrews@isc.org> Sat, 22 December 2007 00:12 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ryT-0008JI-UN; Fri, 21 Dec 2007 19:12:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ryT-0008JD-5R for ietf@ietf.org; Fri, 21 Dec 2007 19:12:17 -0500
Received: from drugs.dv.isc.org ([2001:470:1f00:820:214:22ff:fed9:fbdc]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5ryS-0000pr-BJ for ietf@ietf.org; Fri, 21 Dec 2007 19:12:17 -0500
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.2/8.14.1) with ESMTP id lBM0CExe035713; Sat, 22 Dec 2007 11:12:14 +1100 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200712220012.lBM0CExe035713@drugs.dv.isc.org>
To: David Morris <dwm@xpasc.com>
From: Mark Andrews <Mark_Andrews@isc.org>
In-reply-to: Your message of "Fri, 21 Dec 2007 08:00:54 -0800." <Pine.LNX.4.33.0712210742180.6397-100000@egate.xpasc.com>
Date: Sat, 22 Dec 2007 11:12:14 +1100
X-Spam-Score: -1.4 (-)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: ietf@ietf.org
Subject: Re: IPv4 Outage Planned for IETF 71 Plenary
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

> 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: Mark_Andrews@isc.org

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf