Re: [renum] draft-ietf-6renum-enterprise: review

S Moonesamy <> Wed, 12 December 2012 16:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B1E821F88C4 for <>; Wed, 12 Dec 2012 08:35:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AhuUJvdCZHgY for <>; Wed, 12 Dec 2012 08:35:19 -0800 (PST)
Received: from ( [IPv6:2001:470:f329:1::1]) by (Postfix) with ESMTP id EEEE121F88C8 for <>; Wed, 12 Dec 2012 08:35:18 -0800 (PST)
Received: from ([]) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id qBCGYwMW021830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Dec 2012 08:35:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail2010; t=1355330112; bh=CZVvnql9nfZc9AUoppSlJ7krSscHuMbCGMczu+aUNJ0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uIPt1b8IVtRapvIj/hh+lls8sDnY46TC8cxgqbBRfQ6YRL38/jwMUdumUEtPFbSxW GIMlNGJOZdyyUCsysfyAydc651+PbJrZiOp15Vp/sY3CIfAPQmDidmBMFp7NCmA6zc zaUquNbaD2gOCicucZgews0M4mf8yS69CkAFijqQ=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1355330112;; bh=CZVvnql9nfZc9AUoppSlJ7krSscHuMbCGMczu+aUNJ0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jK5ZsMCvVrkG03467l6aXryp4XZWusGg8otD87NKGuYOg9E58OdB/k55oaPQkT03u dOQgWtbOA7gr9tf1qujaQtkRO2VI6km9ZpJNIOS2nAZkNCM5z8Iam8lOc2PlilyTxQ L5qlS9o8OO/ysXRXaLj/em0WHIoc3wjrIPB72El0=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 12 Dec 2012 08:14:51 -0800
To: Brian E Carpenter <>
From: S Moonesamy <>
In-Reply-To: <>
References: <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [renum] draft-ietf-6renum-enterprise: review
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Renumbering discussion mailing list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Dec 2012 16:35:20 -0000

Hi Brian,
At 06:49 12-12-2012, Brian E Carpenter wrote:
>Actually, that isn't the intention. Analysis is not the same thing
>as a solution. I think we need to change the title and Introduction a bit
>to make this more clear.

That would help.  I was confused about what the document was about as 
it mentions guidelines and best practices.

>What it helps is to document how we derived the gap analysis (coming
>soon, it has not yet left the WG). Then the gap analysis will drive
>whatever specification or BCP work needs to be done.

The above makes matters clearer.  From Section 4:

   "This section recommends some solutions or strategies for the
    enterprise renumbering, chosen among existing mechanisms."

Section 4 comes out as recommendations about Best Current Practices.

>Well, in the sense that we imply a judgment, perhaps, but is it really
>useful to delete the word "best"?

I would describe it as existing practices or some wording around 
"best" if you would like to keep that word.  The above comments 
clarifies what the document is about.  I suggest having such an 
explanation in the document.

>Yes, because one of the main reasons A6 was proposed was to assist
>renumbering. The main reason that RFC 6563 was published this year
>is that 6renum noticed that RFC 2874 was not marked "Historic"
>and was still confusing some people.

I was confused about why RFC 2874 is being referenced.

 From Section 4.1:

    "It is recommended that the site have an automatic and systematic
     procedure for updating/synchronizing its DNS records, including
     both forward and reverse mapping [RFC2874].

The above makes a recommendation about DNS synchronization and refers 
to RFC 2874.  In the following paragraph it is mentioned that RFC 
2874 is not recommended.  I cannot recall off-hand a good reference 
for forward and reverse mapping.  I suggest removing the RFC 2874 
reference (see quoted text above).  The draft could keep things easy 
by also dropping the RFC 3364 reference and relying on RFC 6563 to 
explain why A6 RRs are no longer recommended.

>Why? Are application programmers coding IPv6 addresses into their
>applications instead of using FQDNs?

I hope that application programmers are not hard-coding IPv6 
addresses.  Section 4.1 mentions "system/network 
administrators".  Here is some text (from RFC 4038):

   "Many applications use IP addresses to identify network nodes and to
    establish connections to destination addresses."

I suggest using some variation of that text in the "Usage of FQDN" 
discussion.  The point is to explain that "it is a bad idea" and then 
say that using FQDNs avoids renumbering issues.

>Of course ACLs are important, and we have been reminded by another
>reviewer that they should be mentioned in draft-ietf-6renum-static-problem
>too. But what more is there to say than "they need to be updated"?
>New mechanisms are out of scope in this draft.

I misunderstood what the draft was about (see above).

S. Moonesamy