Re: [renum] Embedding Globally-Routable Internet Addresses Considered Harmful

Tim Chown <> Tue, 29 January 2013 09:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB7E321F8629 for <>; Tue, 29 Jan 2013 01:21:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PmlpJzAlrcot for <>; Tue, 29 Jan 2013 01:20:59 -0800 (PST)
Received: from ( [IPv6:2001:630:d0:f102::25e]) by (Postfix) with ESMTP id 9F59521F8837 for <>; Tue, 29 Jan 2013 01:20:58 -0800 (PST)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id r0T9Kpl5001582 for <>; Tue, 29 Jan 2013 09:20:51 GMT
X-DKIM: Sendmail DKIM Filter v2.8.2 r0T9Kpl5001582
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple;; s=200903; t=1359451251; bh=6Pl0dsejD5T+6oEt4j11H4BHAEI=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=A1fstLQrOzFuLwGJ0yWIrlIP4Dis76AfyN3kSJs4W8DgyxwsDPY15DJHUPV0rdYUX KXDl5UhFdxGRi4DYvimJJLm+mDq2UpBHqLBhCpK/s32mM76P/t96lDVUFWm2ynnKny XidMultcWKqFM3LRnkglqV+KYfhw0wcbgyaQMLbM=
Received: from ([2001:630:d0:f102:250:56ff:fea0:401]) by ( [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from <> with ESMTP (valid=N/A) id p0S9Kp0430617110CW ret-id none; Tue, 29 Jan 2013 09:20:51 +0000
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id r0T9KiGO010896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <>; Tue, 29 Jan 2013 09:20:45 GMT
From: Tim Chown <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_07C7B362-0CA5-4394-ADDF-5638AF4EDB81"
Message-ID: <EMEW3|9c8366221dcbf73cbfd7bf2a0cc7f0acp0S9Kp03tjc||>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Date: Tue, 29 Jan 2013 09:20:45 +0000
References: <> <> <EMEW3|ae7c3cfafbd464da59eb121be3c73f2bp0RHuZ03tjc||> <> <>
To: "" <>
In-Reply-To: <>
X-Mailer: Apple Mail (2.1499)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=p0S9Kp043061711000; tid=p0S9Kp0430617110CW; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: r0T9Kpl5001582
Subject: Re: [renum] Embedding Globally-Routable Internet Addresses Considered Harmful
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: Tue, 29 Jan 2013 09:21:03 -0000

On 29 Jan 2013, at 09:02, Brian E Carpenter <> wrote:

> On 28/01/2013 17:56, Tim Chown wrote:
>> On 24 Jan 2013, at 13:39, Brian E Carpenter <> wrote:
>>> Hi,
>>> Somehow we managed to miss RFC 4085 "Embedding Globally-Routable
>>> Internet Addresses Considered Harmful" when writing
>>> draft-ietf-6renum-static-problem.
>>> Would anyone here object to sliding in a citation during AUTH48?
>> This seems worthwhile, if it fits within the AUTH48 process. I must admit I had forgotten about that document. 
> Hmm. I was just looking at the draft to see where this would fit in,
> and the answer is nowhere, without creating a new section, which is
> really too much for AUTH48. I do think we should consider RFC 4085
> as an important recommendation, however.

I see what you mean; the discussion is specifically about long-lived static addresses, rather than embedding globally routable addresses in configurations (that may or may not be long-lived).

You could perhaps add "While a BCP exists discouraging use of static addresses [RFC4085], their use is still very much common practice." after the first sentence in the introduction?

Or in the enterprise draft you could maybe add RFC 4085 to the sentence "The reader is assumed to be familiar with [RFC4192] and [RFC5887]", given the previous sentence talks about current practices, and 4085 is a BCP, albeit one not followed as much as one might hope.

Again, it depends on the limitations of AUTH48 tweaks. It would be good to include a reference to this in the suite of 6renum deliverables. I haven't looked at gap-analysis (which is more open to minor edits being with the IESG now).