Re: [renum] I-D Action: draft-ietf-6renum-static-problem-03.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 24 December 2012 07:58 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: renum@ietfa.amsl.com
Delivered-To: renum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE0121F8BB3 for <renum@ietfa.amsl.com>; Sun, 23 Dec 2012 23:58:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.599
X-Spam-Level:
X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R02sVU54FKX1 for <renum@ietfa.amsl.com>; Sun, 23 Dec 2012 23:58:15 -0800 (PST)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 699EF21F8B73 for <renum@ietf.org>; Sun, 23 Dec 2012 23:58:15 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hj13so3890894wib.13 for <renum@ietf.org>; Sun, 23 Dec 2012 23:58:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kyepBQ5ZJ4WTYmrhW4O25zaZMJXvXVswpZnVCaYQCkc=; b=yEDJ3JIOPc6HFaug9gOJMgIKswO59fSICeM/aYdIPQDj8e7R0O2GE0iTR/wURwXm2A ulpAtCokW+2XXbD5AIuXa4RmysrOOXMcXuic1XUuvIyVzcOFgUyGs+YLq3HAklOh3Wnq 2FnQqvt3s7U3gUhjCd9ZM7zm9KWYowg86tPizUPdL7gjmEq75GB5L6tTUxAQnGmVdk3Z U8b73izkO3U2RzZnwcQ0UX42pvDSKHHROHub8cKTRFO2gqHgTF6YpRoWxdOoLLqOPcHj CJgScsL8haZn9SydxSfe4L61vkXGQ3KXqmti08KB+f3QfFmFiSMghbdPlOMAag2sfbGs t1Ng==
X-Received: by 10.194.7.104 with SMTP id i8mr34270999wja.27.1356335894238; Sun, 23 Dec 2012 23:58:14 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-217-97.as13285.net. [2.102.217.97]) by mx.google.com with ESMTPS id bd6sm10605209wib.10.2012.12.23.23.58.11 (version=SSLv3 cipher=OTHER); Sun, 23 Dec 2012 23:58:12 -0800 (PST)
Message-ID: <50D80B11.60201@gmail.com>
Date: Mon, 24 Dec 2012 07:58:09 +0000
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: renum@ietf.org
References: <20121224074420.1190.74267.idtracker@ietfa.amsl.com>
In-Reply-To: <20121224074420.1190.74267.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Pete Resnick <presnick@qti.qualcomm.com>, Adrian Farrel <adrian@olddog.co.uk>
Subject: Re: [renum] I-D Action: draft-ietf-6renum-static-problem-03.txt
X-BeenThere: renum@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Renumbering discussion mailing list." <renum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/renum>, <mailto:renum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/renum>
List-Post: <mailto:renum@ietf.org>
List-Help: <mailto:renum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/renum>, <mailto:renum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Dec 2012 07:58:16 -0000

Hi 6renum WG and others,

This update is intended to deal with comments received during
IETF Last Call and IESG review.

The comments from Brian Haberman, Pete Resnick, and Adrian Farrel
were quite straightforward and have been dealt with. In particular,
the document scope was clarified and the discussion of Dynamic DNS
update has been corrected.

The review by Ralph Droms raised a number of points:

> > DNS, mDNS and SLP are mentioned in the context of name resolution.  Is
> > SLP deployed widely enough to warrant mention?

Lack of deployment is exactly the reason for mentioning it. The text
should make that clear now.

> > What about LLMNR and uPNP?

These are not IETF standards track protocols and don't seem to be aimed
at enterprise networks. However, we have modified the text to refer to
discovery protocols in general.

> > I don't understand why ULAs are identified as somehow affecting the
> > use or impact of static addresses.

Clarified the text.

> > DHCPv6 PD should be mentioned in the context of prefix assignment.

This is discussed in the more general document draft-ietf-6renum-enterprise.
It isn't specific to static addressing.

> > Is it really still common practice that "printers in particular are
> > manually assigned a fixed address (typically an [RFC1918] address) and
> > that users are told to manually configure printer access using that
> > fixed address"?

Unfortunately there are plenty of smaller sites that still do this (and many
that don't, of course).

> > In section 2.3, addresses assigned through DHCPv6 are considered
> > problematic because the address might expire, but later DHCPv6 is
> > suggested as a way of assigning addresses to solve renumbering of
> > static addresses.

Both things can be simultaneously valid; that's part of the renumbering
dilemma. Tuned the text to make it seem less paradoxical.

> > I don't understand the first sentence of 2.4.  Isn't the requirement
> > for a static address based on the need to maintain transport sessions
> > over VM movement (which isn't really how I understand the first
> > sentence).

Yes. This text has been updated for clarity.

> > In section 2.5, if asset management is based on MAC addresses, why are
> > static IP addresses an issue?
> >
> > I don't understand the connection between "If [...] a particular host
> > is found to be generating some form of unwanted traffic, it is urgent
> > to be able to track back from its IP address to its physical location"
> > and renumbering of static addressing.

There are indeed sites where IPv4 addresses are statically bound to
the MAC address but SLAAC is used for IPv6, with privacy addresses permitted.
But sites that choose to migrate IPv4 practices to IPv6 will probably bind
the MAC address and the IPv6 address. Surely the IETF can't tell them
not to do that?

> > In section 2.7, this claim may be true:
> >
> >   In any case, when network elements are renumbered, existing user
> >   sessions may not survive, because of temporary "destination
> >   unreachable" conditions being treated as fatal errors.  This aspect
> >   needs further investigation.
> >
> > but what is its connection to renumbering static addresses?

None in particular ;-). Deleted.

> > Section 2.8 makes a valid point about the relationship between static
> > addresses and asset management, but goes into solution space when it
> > talks about DHCPv6 for configuring static addresses.

Toned down the "should" language.

> > I don't understand the first paragraph of section 3.

Reworded.

> >   4.  If external prefix renumbering is required, the RFC 4192
> >       procedure is followed.
> >
> > What about renumbering required by strictly internal topology changes
> > in the network?  I.e., I think "external" can be dropped.

Agreed.

Regards
   Brian Carpenter