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

From: [email-masked]
Date: Sun, 23 Dec 2012 23:44:20 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Site Renumbering Working Group of the IETF.

	Title           : Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks
	Author(s)       : Brian Carpenter
                          Sheng Jiang
	Filename        : draft-ietf-6renum-static-problem-03.txt
	Pages           : 13
	Date            : 2012-12-23

Abstract:
   This document analyses the problems of updating the IPv6 addresses of
   hosts in enterprise networks that for operational reasons require
   static addresses.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6renum-static-problem

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6renum-static-problem-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6renum-static-problem-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Dec 2012 07:58:09 +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