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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 4 Jan 2013 22:31:30 -0000

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

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 24 December 2012 07:58
> To: [email-masked]
> 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