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

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 04 January 2013 22:31 UTC

Return-Path: <adrian@olddog.co.uk>
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 4FDBC21F8732 for <renum@ietfa.amsl.com>; Fri, 4 Jan 2013 14:31:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.221
X-Spam-Level:
X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599]
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 sOir1O7keyh0 for <renum@ietfa.amsl.com>; Fri, 4 Jan 2013 14:31:37 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 93CE021F8809 for <renum@ietf.org>; Fri, 4 Jan 2013 14:31:36 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r04MVYqg007756; Fri, 4 Jan 2013 22:31:34 GMT
Received: from 950129200 (089144192219.atnat0001.highway.a1.net [89.144.192.219]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r04MVUEa007710; Fri, 4 Jan 2013 22:31:33 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Brian E Carpenter'" <brian.e.carpenter@gmail.com>, <renum@ietf.org>
References: <20121224074420.1190.74267.idtracker@ietfa.amsl.com> <50D80B11.60201@gmail.com>
In-Reply-To: <50D80B11.60201@gmail.com>
Date: Fri, 4 Jan 2013 22:31:30 -0000
Message-ID: <072b01cdeacb$40b07820$c2116860$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFy8/L3Viu+r8fw10ySai4sxgFNGQGgByr9mOKktAA=
Content-Language: en-gb
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
Reply-To: adrian@olddog.co.uk
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: Fri, 04 Jan 2013 22:31:38 -0000

Brian,
Thanks for taking the time to look at my Comments.
Adrian

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> Sent: 24 December 2012 07:58
> To: renum@ietf.org
> Cc: Ron Bonica; Brian Haberman; Pete Resnick; Adrian Farrel; Ralph Droms
> Subject: Re: [renum] I-D Action: draft-ietf-6renum-static-problem-03.txt
> 
> 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