ietf
[Top] [All Lists]

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

2012-12-20 16:48:08
Geoff,

I have just posted a new version of the draft, adding a column that 
distinguishes between reservations and allocations. In this version, our goal 
is to preserve the distinction between reservations and allocations while 
providing a single compendium of special addresses.

Please take a look and tell me if we have solved the problem.

                                   Ron


-----Original Message-----
From: Geoff Huston [mailto:gih(_at_)apnic(_dot_)net]
Sent: Monday, December 03, 2012 6:25 PM
To: Ronald Bonica
Cc: Randy Bush; IETF Discussion
Subject: Re: Last Call: <draft-bonica-special-purpose-03.txt> (Special-
Purpose Address Registries) to Best Current Practice


On 04/12/2012, at 9:30 AM, Ronald Bonica <rbonica(_at_)juniper(_dot_)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