Re: Last Call: <draft-bonica-special-purpose-03.txt> (Special-Purpose Address Registries) to Best Current Practice

Geoff Huston <gih@apnic.net> Mon, 03 December 2012 23:25 UTC

Return-Path: <gih@apnic.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2791A21F8970 for <ietf@ietfa.amsl.com>; Mon, 3 Dec 2012 15:25:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGLHbUbDU74k for <ietf@ietfa.amsl.com>; Mon, 3 Dec 2012 15:25:12 -0800 (PST)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 2B52221F896E for <ietf@ietf.org>; Mon, 3 Dec 2012 15:25:11 -0800 (PST)
Received: from 2001-44b8-1121-1a00-8047-fa9d-6338-f77f.static.ipv6.internode.on.net (2001-44b8-1121-1a00-8047-fa9d-6338-f77f.static.ipv6.internode.on.net [IPv6:2001:44b8:1121:1a00:8047:fa9d:6338:f77f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D363FB6746; Tue, 4 Dec 2012 09:25:08 +1000 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: Last Call: <draft-bonica-special-purpose-03.txt> (Special-Purpose Address Registries) to Best Current Practice
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501DBADD2@BY2PRD0512MB653.namprd05.prod.outlook.com>
Date: Tue, 4 Dec 2012 10:25:07 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <62AB342F-F2C0-4B06-B137-47CB7047BCB2@apnic.net>
References: <2CF4CB03E2AA464BA0982EC92A02CE2501DBADD2@BY2PRD0512MB653.namprd05.prod.outlook.com>
To: Ronald Bonica <rbonica@juniper.net>
X-Mailer: Apple Mail (2.1499)
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Dec 2012 23:25:13 -0000

On 04/12/2012, at 9:30 AM, Ronald Bonica <rbonica@juniper.net> wrote:

> Geoff, Randy,
> 
> Having reflected on your comments, I think that the two of you may be approaching the same problem from two directions. I will try my best to articulate the problem. When we agree that we have a common understanding of the problem, we can decide whether to fix draft-bonica or abandon it.
> 
> Geoff points out that each of the entries mentioned in draft-bonica can be characterized as one of the following:
> 
> - a special purpose address assignment
> - a address reservation
> 
> All compliant IP implementations must respect special purpose address assignments. As Randy puts it, special purpose address assignments should be baked into IP stacks. 
> 
> However, the same is not true of address reservations. While operators may afford special treatment to packets that are sourced from or destined to reserved addresses, these treatments should not be baked into IP implementations. They should be configurable.
> 
> Currently, there is nothing in draft-bonica that distinguishes between special purpose address assignments and address reservations. If we were to continue with this draft, we would have to add a field that makes this distinction. Having added that field, we should also make clear that that field, and only that field, determines whether an address should be baked into IP stacks?
> 
> Randy, Geoff, have I restated the problem accurately?
> 


I'd use the opposite terminology. e.g.:

  - I regard 0.0.0.0/8 as a "reservation", and should be baked into IP stacks

  - I regard 192.88.99.0/24 as a "special purpose assignment" and is configurable by IP stacks.

In IPv4 my understanding of the current set of "reservations" are:

  0.0.0.0/8
  127.0.0.0/8
  169.254.0.0/16
  224.0.0.0/4
  240.0.0.0/4

All others I would see as being special purpose assignments, given that they do not require special baked-in treatment by IP stacks.

My personal preference would be to: 

--  record all special purpose assignments in a special purpose assignment registry, such as http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml for Ipv4


-- record all reservations in the address protocol registry, such as http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml for Ipv4


regards,

   Geoff