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

[Ronald Bonica <[e-mail]>]

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:[e-mail]]
> 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 <[e-mail]> 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
> 
> 
> 
>