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

Ted Hardie <ted.ietf@gmail.com> Thu, 11 April 2013 22:51 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EB8E121F8935 for <apps-discuss@ietfa.amsl.com>; Thu, 11 Apr 2013 15:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 56sN2Y5W1a0w for <apps-discuss@ietfa.amsl.com>; Thu, 11 Apr 2013 15:51:03 -0700 (PDT)
Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9616521F8842 for <apps-discuss@ietf.org>; Thu, 11 Apr 2013 15:51:01 -0700 (PDT)
Received: by mail-ia0-f171.google.com with SMTP id f27so7280iae.16 for <apps-discuss@ietf.org>; Thu, 11 Apr 2013 15:51:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=hKMTqw/3cppzHKdB2bmIh+atzRgdotcqUbVm1SLzCdI=; b=IhV/3cQTPs9/dn+1iSEEZf9EoLQlPZxguhuSZKiIXF5FDGweUPaY99IQ8j9yo4oXGl hPTWQV72BZYkNdeW7ICl8ezKd6gL8Vr63m++6SCv/mnF2cAkWBipgDhihfy04UMxCvfl vymLN8nrPJc6r9Rdk+0YYiPGaK8PtKRyApVlelU9IGEooc54+4Y7Z2Wx7UoN/2xAYMpy wWVXkfCbN98frneFCLQlwu/iVHzmEO829rO8Agy9ocVT6ovlaMhUZQZ6WdKgcH6GRRXH qWfQc6NNNrm01aPCUyNdr3qzZVn0L94Vp4y8P2tMnxotbsqarNhqiigIhs9WMMFg+xyK iZ2Q==
MIME-Version: 1.0
X-Received: by with SMTP id p10mr114067igg.20.1365720661111; Thu, 11 Apr 2013 15:51:01 -0700 (PDT)
Received: by with HTTP; Thu, 11 Apr 2013 15:51:00 -0700 (PDT)
Date: Thu, 11 Apr 2013 15:51:00 -0700
Message-ID: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: apps-discuss@ietf.org, draft-ietf-6renum-gap-analysis.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="047d7b10cd29de865504da1d9ec2"
Subject: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 22:51:05 -0000

I have been selected as the Applications Area Directorate reviewer
for this draft (for background on appsdir, please see

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.

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
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

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.


For me personally, section 6.1 seemed needlessly pessimistic.