[apps-discuss] Review of draft-ietf-6renum-gap-analysis-05

[Ted Hardie <[e-mail]>]

I have been selected as the Applications Area Directorate reviewer
for this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:draft-ietf-6renum-gap-analysis-05
Title: IPv6 Site Renumbering Gap Analysis
Reviewer: Ted Hardie
Review Date: April 11, 2013

Summary: This document is basically ready to be published as an
Informational draft.  There are minor issues which the authors may wish to
address before final publication.


Minor Issues:

The document currently motivates its work with the following statement:

   If IPv6 site renumbering continues to be considered
   difficult, network managers will turn to Provider Independent (PI)
   addressing for IPv6 to attempt to minimize the need for future
   renumbering. However, widespread use of PI may create very serious
   BGP4 scaling problems. It is thus desirable to develop tools and
   practices that may make renumbering a simpler process to reduce
   demand for IPv6 PI space.

A citation for this would be useful.  It might also be worth it to
highlight other potential risks--for example, the widespread deployment
of ULAs, which do not admit of aggregation, or the deployment of

address translation technologies which make referral more difficult.  I note
that RFC 5887 included some of these issues.  If the intent is to reference
those from RFC 5887, I note that  the document currently says that it

"starts from existing work in [RFC5887],
[I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the references
to these documents are informative.  If the document is meant to be an
extension,
rather than a replacement, such that these documents must be read to
get the full
picture, than a normative reference may be better.

For the session survivability section, a reference to RFC 6724 may be
useful, so
that those adding new global addresses understand how the application
API to determine
which address is used with interact with the addition of new addresses (if there
is a specific draft or other treatment of that topic, that would be even better,
but I am not personally aware of one).

In section 6, the document currently says:

   When nodes in a site have been renumbered, then all the entries in
   the site which contain the nodes' addresses must be updated. The
   entries mainly include DNS records and filters in various entities
   such as ACLs in firewalls/gateways.

This appears to imply that these updates must take place after the renumbering
event, but this is variable.  ACLs and filters may well be updated in advance;
DNS may be updated concurrently or post facto.  A rewording to highlight that
this is variable by record type may be useful.

Section 9.2, in the bullet entitled "DNS data structure optimization"
The discusses a DNS feature proposed but declared historic. I don't think it
identifies the related renumbering gap in a way that is useful for a naive
reader.  If it cannot be reworded to focus on the gap, I suggest it be
removed.

In section 9.4, the document says:

      For application layer, as [RFC5887] said, in general, we can
      assert that any implementation is at risk from renumbering if it
      does not check that an address is valid each time it opens a new
      communications session.

This might be reworded to  include or focus on session resumption, rather than
new communications sessions.  From an applications perspective, the laptop
"sleep" function seems to be one of the bigger risks of this.

Nit:

For me personally, section 6.1 seemed needlessly pessimistic.