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

From: Ronald Bonica <[email-masked]>
Date: Mon, 3 Dec 2012 22:30:54 +0000

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?

--------------------------
Ron Bonica
vcard:       www.bonica.org/ron/ronbonica.vcf

---

From: Geoff Huston <[email-masked]>
Date: Tue, 4 Dec 2012 10:25:07 +1100

> 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

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 20 Dec 2012 22:45:30 +0000

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:[email-masked]]
> 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
> 
> 
> > 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:
> >
> > 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?
> >
> All others I would see as being special purpose assignments, given that
> they do not require special baked-in treatment by IP stacks.
> 
> --  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
> 
> 
> 
>

---

From: Geoff Huston <[email-masked]>
Date: Fri, 21 Dec 2012 10:15:08 +1100

Hi Ron,

I'm pleased to see the addition of this column and the recognition of this distinction between reservations in the protocol's address plan and special purpose assignments being made . This is a useful step forward.

Personally, I think that the two sets of addresses belong in different registries, but I'm willing to recognise this as a matter of personal taste and not a fundamental objection to the further progress of the document per se (i.e. for me its more of a matter of registry management style - I would advocate the protocol's address plan should be recorded in a single registry, and special purpose assignments recorded in a special purpose assignment registry)

So: "solved?" For me, it's a 51% solution: solved, but could do better :-)

cheers,

   Geoff

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]