Subject: Re: [GROW] FW: New Version Notification for draft-manderson-routing-intent-00.txt

From: Terry Manderson <[email-masked]>
Date: Sun, 14 Aug 2011 23:44:50 -0700

So I saw no comments on this.

What I propose is that I add words to routing-intent-00 with the effect of
adding an extra column to the IANA IPv4 Special Purpose Address Registry
listing the binary option for Public Routing Intent (PRI) to be consistent
to the other IP address registries that acquire this column. The routing
scope as defined by RFC5736 for the IANA IPv4 Special Purpose Address
Registry can remain as it is and can provide the (human) reader with more
information for those entries in the special address registry.. because..
well.. they are "special" ;)

If I see no objections to this I will make the change in the next day or so
and publish a revision. Otherwise, please put forward a suggestion.

Cheers
Terry

On 15/07/11 11:32 AM, "Terry Manderson" <[email-masked]> wrote:

> Hi,
> 
> RFC5736 deals with only the IANA IPv4 Special Purpose Address Registry, a
> registry that at present contains one entry for DS-lite.
> 
> There are two ways that the instruction for IANA contained in
> draft-manderson-routing-intent-01 can be taken with respect to the IANA IPv4
> Special Purpose Address Registry. Either add and additional column for
> Public Routing Intent (PRI) or replace the existing routing scope column
> with PRI. So a clarification is worthwhile.
> 
> There are arguments for both in uniformity versus simplicity and utility.
> The latter option leaves the reader to investigate routing particulars (if
> not intended to be globally routable) in the RFC which made the address
> assignment.
> 
> Additionally it's also possible to add words to
> draft-manderson-routing-intent to exclude the IANA IPv4 Special Purpose
> Address Registry from acquiring change, as it already has a routing
> designator.
> 
> What say you WG?
> 
> Cheers
> Terry
> 
> 
> 
> On 15/07/11 10:36 AM, "Geoff Huston" <[email-masked]> wrote:
> 
>> Hi,
>> 
>>> I seek your feedback on the I-D below.
>> 
>> To what extent does this draft further alaborate on part 7 of the list in the
>> IANA Considerations of RFC5736?
>> 
>> To remind the WG, that document states that the registry includes:
>> 
>> 
>> 7.  The registry will also note, for each designation, the intended
>>        routing scope of the address, indicating whether the address is
>>        intended to be routable only in scoped, local, or private
>>        contexts, or whether the address prefix is intended to be routed
>>        globally.
>> 
>> So I'm left wondering what this I-D is trying to achieve over and above what
>> is already
>> in RFC5736?
>> 
>> 
>> thanks,
>> 
>>   Geoff
>> 
>> 
>> 
>> On 22/06/2011, at 10:39 AM, Terry Manderson wrote:
>> 
>>> Chairs and WG,
>>> 
>>> I seek your feedback on the I-D below.
>>> 
>>> I'd also like to present this to the WG in Quebec.
>>> 
>>> Cheers
>>> Terry
>>> 
>>> 
>>> ------ Forwarded Message
>>>> From: <[email-masked]>
>>>> Date: Tue, 21 Jun 2011 17:31:50 -0700
>>>> To: Terry Manderson <[email-masked]>
>>>> Cc: Terry Manderson <[email-masked]>
>>>> Subject: New Version Notification for draft-manderson-routing-intent-00.txt
>>>> 
>>>> A new version of I-D, draft-manderson-routing-intent-00.txt has been
>>>> successfully submitted by Terry Manderson and posted to the IETF
>>>> repository.
>>>> 
>>>> Filename:        draft-manderson-routing-intent
>>>> Revision:        00
>>>> Title:           Signalling Public Routing Intent (PRI) for Internet
>>>> Protocol
>>>> Addresses in IANA Registries
>>>> Creation date:   2011-06-22
>>>> WG ID:           Individual Submission
>>>> Number of pages: 12
>>>> 
>>>> Abstract:
>>>>   This document provides direction to IANA to mark existing and future
>>>>   IANA IPv4 and IPv6 allocations with generic terms pertaining to the
>>>>   Public (global) Routing Intent (PRI).
>>>> 
>>>> 
>>>> 
>>>> 
>>>> The IETF Secretariat
>>> 
>>> ------ End of Forwarded Message
>>> 
>>> _______________________________________________
>>> GROW mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/grow
>> 
>> --
>> 
>> Geoff Huston
>> Chief Scientist, APNIC
>> 
>> +61 7 3858 3100
>> [email-masked]
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Terry Manderson <[email-masked]>
Date: Tue, 16 Aug 2011 19:02:50 -0700

I have made those changes.

http://www.ietf.org/internet-drafts/draft-manderson-routing-intent-02.txt

Cheers
Terry

---

From: Geoff Huston <[email-masked]>
Date: Wed, 17 Aug 2011 12:48:33 +1000

I am now very confused!

The IANA IPv4 address registry (http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml) contains only 256 entries, where each entry describes an entire /8. There are a number of /8s that have a single routing policy, (0/8, 127/8), but there are a much larger number of cases where there is no single routing policy that is applicable to all addresses in the /8 (e.g. 192/8).

I note that this draft does NOT propose to change the format of the ipv4 address registry, so I assume that the /8s in the IPv4 address registry will remain.  Given that the IANA IPv4 Special purpose address registry already contains a routing scope, and the IANA IPv4 address registry only operates at the level of a /8  then for Ipv4 I'm left wondering exactly what is the purpose of this draft with respect to IPv4 and the IANA IPv4 address registries. How would it be applied to the IANA IPv4 address registry? (the example in the draft is entirely unhelpful in so far as the address blocks in the draft's example do not correspond to entires in any IANA IPv4 address registry.

So if it does not readily apply to the IANA IPv4 address registry, does it apply to the IANA IPv6 registries?

The IPv6 address space registry (http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml) also appears to be inapplicable (side note - conventionally March is spelled with a capital "M"). The unicast registry appears to contain a list of unicast address allocations to the RIRs, and the Special Purpose Address registry for Ipv6 (http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xml) already contains a routing scope field.

So I'm left with the distinct impression that for whatever value a "routing intent" may have in the IANA IPv4 and IPv6 registries, I simply cannot see its applicability to the existing IPv4 and IPv6 IANA registries. i.e.  I cannot see any practical application of this instruction to the IANA as it relates to the IANA-maintained IPv4 and IPv6 address registries and the granularity of the registry entries maintained by the IANA.

regards,

   Geoff

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
[email-masked]

---

From: Terry Manderson <[email-masked]>
Date: Tue, 16 Aug 2011 20:48:29 -0700

Hi Geoff,

Let me try to bring you out of your state of confusion.

On 17/08/11 12:48 PM, "Geoff Huston" <[email-masked]> wrote:

> I am now very confused!
> 
> The IANA IPv4 address registry
> (http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml)
> contains only 256 entries, where each entry describes an entire /8. There are
> a number of /8s that have a single routing policy, (0/8, 127/8), but there are
> a much larger number of cases where there is no single routing policy that is
> applicable to all addresses in the /8 (e.g. 192/8).

Correct.

> 
> I note that this draft does NOT propose to change the format of the ipv4

It does not change the format of the IPv4 registry except to add the PRI
column. It does allow the registry to select the granularity that best fits
the /8 in question. From the IANA considerations section:

" Implementation of this document further requires IANA to update the
   IPv4 and IPv6 address registries to use a granularity commensurate
   with the most specific entry in the address registry."

> address registry, so I assume that the /8s in the IPv4 address registry will
> remain.  

For a /8 which has a single routing policy intent, they will remain.

For a /8 which has more specific prefixes that do not match it's parent PRI
they should be listed as the example provides.

> Given that the IANA IPv4 Special purpose address registry already
> contains a routing scope, and the IANA IPv4 address registry only operates at

The IANA registry doesn't only operate at the /8 level. It has been asked
many times to make reservations at more specific levels. It makes only /8
allocations to the RIRs, which might be where your confusion is derived
from.

> the level of a /8  then for Ipv4 I'm left wondering exactly what is the
> purpose of this draft with respect to IPv4 and the IANA IPv4 address
> registries. How would it be applied to the IANA IPv4 address registry? (the
> example in the draft is entirely unhelpful in so far as the address blocks in
> the draft's example do not correspond to entires in any IANA IPv4 address
> registry.

Its an example of what a snippet of 198/8 might look like, given:

198.18.0.0/15 reserved for Network Interconnect Device Benchmark Testing
[RFC5735]
198.51.100.0/24 reserved for TEST-NET-2 [RFC5737]

Is that not obvious?

> apply to the IANA IPv6 registries?

It does apply to the IANA IPv4 registry, and will also apply to the IPv6
registries.

> 
> The IPv6 address space registry
> (http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml)
> also appears to be inapplicable (side note - conventionally March is spelled
> with a capital "M").

I'll feed the capitalization concern back into the IANA team.

> The unicast registry appears to contain a list of unicast
> address allocations to the RIRs, and the Special Purpose Address registry for
> Ipv6 
> (http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-
> registry.xml) already contains a routing scope field.
> 
> So I'm left with the distinct impression that for whatever value a "routing
> intent" may have in the IANA IPv4 and IPv6 registries, I simply cannot see its
> applicability to the existing IPv4 and IPv6 IANA registries. i.e.  I cannot
> see any practical application of this instruction to the IANA as it relates to
> the IANA-maintained IPv4 and IPv6 address registries and the granularity of
> the registry entries maintained by the IANA.
> 

Now that you might realize that the IANA registry deals with more specific
entries than you normally associate, does this help your confusion and allow
you to see the use in explicitly stating routing intent and a binary
attribute?

Cheers
Terry

---

From: Geoff Huston <[email-masked]>
Date: Wed, 17 Aug 2011 15:19:17 +1000

Thank you for your response. 

So this draft is not really a draft about routing intent. Its a draft that in effect proposes a rewrite of the IPv4 registry, and potentially the IPv6 address registry. Frankly, in such a light, I'm unhappy that this is a GROW WG document, and I would prefer that this is an IAB document [RFC2860].

And no, I'm not confused any more. I object to this draft.

- it is out of scope of GROW's charter

- it is arguably part of the IAB's charter (well actually it could be part of the US Department of Commerce's NTIA's scope in the proposed statement of work for the IANA contract, and therefore nothing to do with the IETF any more, but that's yet to be determined in whatever SOW the NTIA decide to go with in the coming weeks with the IANA contract, so I'll sit with historical precedent for the moment and nominate the IAB), and the proposal to rewrite the IANA's IPv4 address registry (and potentially the IANA IPv6 registry) should be handed over to the IAB for their consideration, rather than having this proposal come from an ICANN staff member, where there is some institutional overlap between the IANA contracting entity and the proponent of this work.

There is a substantive issue here about precisely what is recorded in these registries, and there is a case to be made for clear simplicity and consistency, as distinct from constant adornment and tinkering in these registries, but as far as I can see this is a matter for the IAB to consider as a matter of registry policy as distinct from the GROW Working Group within the necessarily charter-limited scope of GROW's work.

regards

  Geoff

---

From: Terry Manderson <[email-masked]>
Date: Wed, 17 Aug 2011 16:40:22 -0700

Hi Geoff,

On 17/08/11 3:19 PM, "Geoff Huston" <[email-masked]> wrote:

> So this draft is not really a draft about routing intent. Its a draft that in
> effect proposes a rewrite of the IPv4 registry, and potentially the IPv6

Nothing regarding who the allocations in the IPv4 and IPv6 registry are made
to will change. The dates won't change. And for the most part the prefix in
the entries won't change. I'm trying, but really struggling, to see this
called a re-write. 

>From an engineering perspective it is just, and only, about signaling
routing intent so people who read the registry either with human or machine
eyes can transparently see what prefixes are intended to be routed without
any ambiguity. This has benefits for the Security efforts in RPKI and
elsewhere and for anyone dealing with the burden of an allocation which has
fallen under the filtering bus[1].

It makes engineering such structures immensely simpler, and I certainly have
an interest in doing that given I will be implementing the RPKI system for
ICANN. Transparency in registry also aides in the engineering trust point.
eg "is what is represented in the registry a 1:1 of what is produced in
RPKI?"

[1] Approximately once a month or less I see an operator on a mailing list
speak up about how their recently assigned prefix is unusable due to
filtering. No silver bullets here.. but everything from the RIR's QA
procedures, to better documentation, and clear unambigious registries will
help.

> address registry. Frankly, in such a light, I'm unhappy that this is a GROW WG
> document, and I would prefer that this is an IAB document [RFC2860].

I will open a discussion with the grow chairs and the IAB in regard to this.

> And no, I'm not confused any more. I object to this draft.

Actually, since it was clarifying the position in the IANA registries to
make the "world a better place" I really thought I would see 2 thumbs up
from you.

> - it is out of scope of GROW's charter

The GROW charter says:

"The purpose of the GROW is to consider the operational problems
  associated with the IPv4 and IPv6 global routing systems"

now I'm confused! (easy to to do I guess ;)

> 
> - it is arguably part of the IAB's charter (well actually it could be part of

Possibly. But probably easier as a GROW item.

> rather than having this proposal come
> from an ICANN staff member, where there is some institutional overlap between
> the IANA contracting entity and the proponent of this work.

My institutional relationship at this stage should be considered moot. As
per the IETF Note Well I do this work as an IETF contributor and as an
engineer implementing systems that arguably will be required by the entire
operator community.

> 
> There is a substantive issue here about precisely what is recorded in these
> registries, and there is a case to be made for clear simplicity and

The PRI field is simple. (I don't like complex structures)
Putting the more specifics in the registry makes it simpler to use and read.

So this is clear simplicity. :)

> consistency, as distinct from constant adornment and tinkering in these
> registries, but as far as I can see this is a matter for the IAB to consider
> as a matter of registry policy as distinct from the GROW Working Group within
> the necessarily charter-limited scope of GROW's work.
> 

Again, a bit of confusion on my part. I thought that the IETF through the
working group' documents told the IANA what to put registries and how they
are to be structured? If that isn't the case, can someone please point me to
the clarifying documentation?

Cheers
Terry

---

From: Geoff Huston <[email-masked]>
Date: Thu, 18 Aug 2011 10:22:48 +1000

> the entries won't change. I'm trying, but really struggling, to see this

I notice you say here "for the most part."

Terry, either the entries will change or they won't. According to your responses in this thread the document is to be interpreted as saying "This documents instructs the IANA to change the contents of these registries, but this document not going to disclose the precise nature of the directed change."

This is unacceptable to me in terms of forming a clear instruction to the IANA.

Secondly, if the registry contents will be altered in any way than frankly the GROW WG is not the appropriate body to review such proposed changes. I have previously stated that from my perspective and experience the appropriate entity with the IETF menagerie is the IAB. My view is unchanged.

regards,

Geoff

---

From: Terry Manderson <[email-masked]>
Date: Wed, 17 Aug 2011 17:35:31 -0700

Hi Geoff,

On 18/08/11 10:22 AM, "Geoff Huston" <[email-masked]> wrote:

> Terry, either the entries will change or they won't. According to your
> responses in this thread the document is to be interpreted as saying "This
> documents instructs the IANA to change the contents of these registries, but
> this document not going to disclose the precise nature of the directed
> change."

I see a difference between precise and explicit. Precise is covered as there
is sufficent instruction to tell IANA what to do.

Explicit is not as the IPv6 and IPv4 registries are subject to change from
other entities, ie As RIRs are allocated address blocks.

> This is unacceptable to me in terms of forming a clear instruction to the

To help, I will come back to the list soon with a full synthesized IPv4
registry based on what it looks like today. That includes PRI and and
entries for the more specific reserved prefixes. This can augment the
understanding from the example in the draft.

> 
> Secondly, if the registry contents will be altered in any way than frankly the
> GROW WG is not the appropriate body to review such proposed changes. I have
> previously stated that from my perspective and experience the appropriate
> entity with the IETF menagerie is the IAB. My view is unchanged.
> 

This to me then suggests that any change or creation of/in any IANA registry
should be an IAB document. That seems at odds to what I know is current
process. (not that I am an ietf process expert by any means) Still confused.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Mon, 22 Aug 2011 00:07:12 -0700

> understanding from the example in the draft.

Below is a IANA IPv4 address registry synthesized to how it _might_ look
after routing-intent-02 is implemented. I stopped at the Multicast
allocations..

It's probable that line wrapping may occur.

   Prefix                  Designation                    Date         Whois
Status [1]   PRI           Note
   000/8  IANA - Local Identification                    1981-09
RESERVED    Not Routable  [2]
   001/8  APNIC                                          2010-01
whois.apnic.net  ALLOCATED    Routable
   002/8  RIPE NCC                                       2009-09
whois.ripe.net   ALLOCATED    Routable
   003/8  General Electric Company                       1994-05
LEGACY    Routable
   004/8  Level 3 Communications, Inc.                   1992-12
LEGACY    Routable
   005/8  RIPE NCC                                       2010-11
whois.ripe.net   ALLOCATED    Routable
   006/8  Army Information Systems Center                1994-02
LEGACY    Routable
   007/8  Administered by ARIN                           1995-04
whois.arin.net     LEGACY    Routable
   008/8  Level 3 Communications, Inc.                   1992-12
LEGACY    Routable
   009/8  IBM                                            1992-08
LEGACY    Routable
   010/8  IANA - Private Use                             1995-06
RESERVED    Not Routable  [3]
   011/8  DoD Intel Information Systems                  1993-05
LEGACY    Routable
   012/8  AT&T Bell Laboratories                         1995-06
LEGACY    Routable
   013/8  Xerox Corporation                              1991-09
LEGACY    Routable
   014/8  APNIC                                          2010-04
whois.apnic.net  ALLOCATED    Routable      [4]
   015/8  Hewlett-Packard Company                        1994-07
LEGACY    Routable
   016/8  Digital Equipment Corporation                  1994-11
LEGACY    Routable
   017/8  Apple Computer Inc.                            1992-07
LEGACY    Routable
   018/8  MIT                                            1994-01
LEGACY    Routable
   019/8  Ford Motor Company                             1995-05
LEGACY    Routable
   020/8  Computer Sciences Corporation                  1994-10
LEGACY    Routable
   021/8  DDN-RVN                                        1991-07
LEGACY    Routable
   022/8  Defense Information Systems Agency             1993-05
LEGACY    Routable
   023/8  ARIN                                           2010-11
whois.arin.net   ALLOCATED    Routable
   024/8  ARIN                                           2001-05
whois.arin.net   ALLOCATED    Routable
   025/8  UK Ministry of Defence                         1995-01
whois.ripe.net     LEGACY    Routable
   026/8  Defense Information Systems Agency             1995-05
LEGACY    Routable
   027/8  APNIC                                          2010-01
whois.apnic.net  ALLOCATED    Routable
   028/8  DSI-North                                      1992-07
LEGACY    Routable
   029/8  Defense Information Systems Agency             1991-07
LEGACY    Routable
   030/8  Defense Information Systems Agency             1991-07
LEGACY    Routable
   031/8  RIPE NCC                                       2010-05
whois.ripe.net   ALLOCATED    Routable
   032/8  AT&T Global Network Services                   1994-06
LEGACY    Routable
   033/8  DLA Systems Automation Center                  1991-01
LEGACY    Routable
   034/8  Halliburton Company                            1993-03
LEGACY    Routable
   035/8  MERIT Computer Network                         1994-04
LEGACY    Routable
   036/8  APNIC                                          2010-10
whois.apnic.net  ALLOCATED    Routable
   037/8  RIPE NCC                                       2010-11
whois.ripe.net   ALLOCATED    Routable
   038/8  PSINet, Inc.                                   1994-09
LEGACY    Routable
   039/8  APNIC                                          2011-01
whois.apnic.net  ALLOCATED    Routable
   040/8  Eli Lily & Company                             1994-06
LEGACY    Routable
   041/8  AfriNIC                                        2005-04
whois.afrinic.net ALLOCATED    Routable
   042/8  APNIC                                          2010-10
whois.apnic.net  ALLOCATED    Routable
   043/8  Administered by APNIC                          1991-01
LEGACY    Routable
   044/8  Amateur Radio Digital Communications           1992-07
LEGACY    Routable
   045/8  Administered by ARIN                           1995-01
whois.arin.net     LEGACY    Routable
   046/8  RIPE NCC                                       2009-09
whois.ripe.net   ALLOCATED    Routable
   047/8  Bell-Northern Research                         1991-01
LEGACY    Routable
   048/8  Prudential Securities Inc.                     1995-05
LEGACY    Routable
   049/8  APNIC                                          2010-08
whois.apnic.net  ALLOCATED    Routable
   050/8  ARIN                                           2010-02
whois.arin.net   ALLOCATED    Routable
   051/8  UK Government Department for Work and Pensions 1994-08
whois.ripe.net     LEGACY    Routable
   052/8  E.I. duPont de Nemours and Co., Inc.           1991-12
LEGACY    Routable
   053/8  Cap Debis CCS                                  1993-10
LEGACY    Routable
   054/8  Merck and Co., Inc.                            1992-03
LEGACY    Routable
   055/8  DoD Network Information Center                 1995-04
LEGACY    Routable
   056/8  US Postal Service                              1994-06
LEGACY    Routable
   057/8  SITA                                           1995-05
LEGACY    Routable
   058/8  APNIC                                          2004-04
whois.apnic.net  ALLOCATED    Routable
   059/8  APNIC                                          2004-04
whois.apnic.net  ALLOCATED    Routable
   060/8  APNIC                                          2003-04
whois.apnic.net  ALLOCATED    Routable
   061/8  APNIC                                          1997-04
whois.apnic.net  ALLOCATED    Routable
   062/8  RIPE NCC                                       1997-04
whois.ripe.net   ALLOCATED    Routable
   063/8  ARIN                                           1997-04
whois.arin.net   ALLOCATED    Routable
   064/8  ARIN                                           1999-07
whois.arin.net   ALLOCATED    Routable
   065/8  ARIN                                           2000-07
whois.arin.net   ALLOCATED    Routable
   066/8  ARIN                                           2000-07
whois.arin.net   ALLOCATED    Routable
   067/8  ARIN                                           2001-05
whois.arin.net   ALLOCATED    Routable
   068/8  ARIN                                           2001-06
whois.arin.net   ALLOCATED    Routable
   069/8  ARIN                                           2002-08
whois.arin.net   ALLOCATED    Routable
   070/8  ARIN                                           2004-01
whois.arin.net   ALLOCATED    Routable
   071/8  ARIN                                           2004-08
whois.arin.net   ALLOCATED    Routable
   072/8  ARIN                                           2004-08
whois.arin.net   ALLOCATED    Routable
   073/8  ARIN                                           2005-03
whois.arin.net   ALLOCATED    Routable
   074/8  ARIN                                           2005-06
whois.arin.net   ALLOCATED    Routable
   075/8  ARIN                                           2005-06
whois.arin.net   ALLOCATED    Routable
   076/8  ARIN                                           2005-06
whois.arin.net   ALLOCATED    Routable
   077/8  RIPE NCC                                       2006-08
whois.ripe.net   ALLOCATED    Routable
   078/8  RIPE NCC                                       2006-08
whois.ripe.net   ALLOCATED    Routable
   079/8  RIPE NCC                                       2006-08
whois.ripe.net   ALLOCATED    Routable
   080/8  RIPE NCC                                       2001-04
whois.ripe.net   ALLOCATED    Routable
   081/8  RIPE NCC                                       2001-04
whois.ripe.net   ALLOCATED    Routable
   082/8  RIPE NCC                                       2002-11
whois.ripe.net   ALLOCATED    Routable
   083/8  RIPE NCC                                       2003-11
whois.ripe.net   ALLOCATED    Routable
   084/8  RIPE NCC                                       2003-11
whois.ripe.net   ALLOCATED    Routable
   085/8  RIPE NCC                                       2004-04
whois.ripe.net   ALLOCATED    Routable
   086/8  RIPE NCC                                       2004-04
whois.ripe.net   ALLOCATED    Routable
   087/8  RIPE NCC                                       2004-04
whois.ripe.net   ALLOCATED    Routable
   088/8  RIPE NCC                                       2004-04
whois.ripe.net   ALLOCATED    Routable
   089/8  RIPE NCC                                       2005-06
whois.ripe.net   ALLOCATED    Routable
   090/8  RIPE NCC                                       2005-06
whois.ripe.net   ALLOCATED    Routable
   091/8  RIPE NCC                                       2005-06
whois.ripe.net   ALLOCATED    Routable
   092/8  RIPE NCC                                       2007-03
whois.ripe.net   ALLOCATED    Routable
   093/8  RIPE NCC                                       2007-03
whois.ripe.net   ALLOCATED    Routable
   094/8  RIPE NCC                                       2007-07
whois.ripe.net   ALLOCATED    Routable
   095/8  RIPE NCC                                       2007-07
whois.ripe.net   ALLOCATED    Routable
   096/8  ARIN                                           2006-10
whois.arin.net   ALLOCATED    Routable
   097/8  ARIN                                           2006-10
whois.arin.net   ALLOCATED    Routable
   098/8  ARIN                                           2006-10
whois.arin.net   ALLOCATED    Routable
   099/8  ARIN                                           2006-10
whois.arin.net   ALLOCATED    Routable
   100/8  ARIN                                           2010-11
whois.arin.net   ALLOCATED    Routable
   101/8  APNIC                                          2010-08
whois.apnic.net  ALLOCATED    Routable
   102/8  AfriNIC                                        2011-02
whois.afrinic.net ALLOCATED    Routable
   103/8  APNIC                                          2011-02
whois.apnic.net  ALLOCATED    Routable
   104/8  ARIN                                           2011-02
whois.arin.net   ALLOCATED    Routable
   105/8  AfriNIC                                        2010-11
whois.afrinic.net ALLOCATED    Routable
   106/8  APNIC                                          2011-01
whois.apnic.net  ALLOCATED    Routable
   107/8  ARIN                                           2010-02
whois.arin.net   ALLOCATED    Routable
   108/8  ARIN                                           2008-12
whois.arin.net   ALLOCATED    Routable
   109/8  RIPE NCC                                       2009-01
whois.ripe.net   ALLOCATED    Routable
   110/8  APNIC                                          2008-11
whois.apnic.net  ALLOCATED    Routable
   111/8  APNIC                                          2008-11
whois.apnic.net  ALLOCATED    Routable
   112/8  APNIC                                          2008-05
whois.apnic.net  ALLOCATED    Routable
   113/8  APNIC                                          2008-05
whois.apnic.net  ALLOCATED    Routable
   114/8  APNIC                                          2007-10
whois.apnic.net  ALLOCATED    Routable
   115/8  APNIC                                          2007-10
whois.apnic.net  ALLOCATED    Routable
   116/8  APNIC                                          2007-01
whois.apnic.net  ALLOCATED    Routable
   117/8  APNIC                                          2007-01
whois.apnic.net  ALLOCATED    Routable
   118/8  APNIC                                          2007-01
whois.apnic.net  ALLOCATED    Routable
   119/8  APNIC                                          2007-01
whois.apnic.net  ALLOCATED    Routable
   120/8  APNIC                                          2007-01
whois.apnic.net  ALLOCATED    Routable
   121/8  APNIC                                          2006-01
whois.apnic.net  ALLOCATED    Routable
   122/8  APNIC                                          2006-01
whois.apnic.net  ALLOCATED    Routable
   123/8  APNIC                                          2006-01
whois.apnic.net  ALLOCATED    Routable
   124/8  APNIC                                          2005-01
whois.apnic.net  ALLOCATED    Routable
   125/8  APNIC                                          2005-01
whois.apnic.net  ALLOCATED    Routable
   126/8  APNIC                                          2005-01
whois.apnic.net  ALLOCATED    Routable
   127/8  IANA - Loopback                                1981-09
RESERVED    Not Routable  [5]
   128/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   129/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   130/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   131/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   132/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   133/8  Administered by APNIC                          1997-03
whois.apnic.net    LEGACY    Routable
   134/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   135/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   136/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   137/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   138/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   139/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   140/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   141/8  Administered by RIPE NCC                       1993-05
whois.ripe.net     LEGACY    Routable
   142/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   143/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   144/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   145/8  Administered by RIPE NCC                       1993-05
whois.ripe.net     LEGACY    Routable
   146/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   147/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   148/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   149/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   150/8  Administered by APNIC                          1993-05
whois.apnic.net    LEGACY    Routable
   151/8  Administered by RIPE NCC                       1993-05
whois.ripe.net     LEGACY    Routable
   152/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   153/8  Administered by APNIC                          1993-05
whois.apnic.net    LEGACY    Routable
   154/8  Administered by AfriNIC                        1993-05
whois.afrinic.net   LEGACY    Routable
   155/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   156/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   157/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   158/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   159/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   160/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   161/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   162/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   163/8  Administered by APNIC                          1993-05
whois.apnic.net    LEGACY    Routable
   164/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   165/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   166/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   167/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   168/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   169.0.0.0/9  Administered by ARIN                     1993-05
whois.arin.net     LEGACY     Routable
   169.127.0.0/9  Administered by ARIN                   1993-05
whois.arin.net     LEGACY     Routable
   169.128.0.0/10  Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   169.192.0.0/11  Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   169.193.0.0/11  Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   169.194.0.0/11  Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   169.224.0.0/13  Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   169.232.0.0/13  Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   169.240.0.0/13  Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   169.248.0.0/14  Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   169.252.0.0/15  Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   169.254.0.0/16  IANA - Link Local             2005-05
RESERVED   Not Routable   [6]
   170/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY    Routable
   171/8  Administered by APNIC                          1993-05
whois.apnic.net    LEGACY    Routable
   172.0.0.0/12  Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   172.16.0.0/12  IANA - Private Use                     1996-02
RESERVED   Not Routable   [7]
   172.32.0.0/11  Administered by ARIN                   1993-05
whois.arin.net     LEGACY     Routable
   172.64.0.0/10  Administered by ARIN                   1993-05
whois.arin.net     LEGACY     Routable
   172.128.0.0/9  Administered by ARIN                   1993-05
whois.arin.net     LEGACY     Routable
   173/8  ARIN                                           2008-02
whois.arin.net   ALLOCATED    Routable
   174/8  ARIN                                           2008-02
whois.arin.net   ALLOCATED    Routable
   175/8  APNIC                                          2009-08
whois.apnic.net  ALLOCATED    Routable
   176/8  RIPE NCC                                       2010-05
whois.ripe.net   ALLOCATED    Routable
   177/8  LACNIC                                         2010-06
whois.lacnic.net  ALLOCATED    Routable
   178/8  RIPE NCC                                       2009-01
whois.ripe.net   ALLOCATED    Routable
   179/8  LACNIC                                         2011-02
whois.lacnic.net  ALLOCATED    Routable
   180/8  APNIC                                          2009-04
whois.apnic.net  ALLOCATED    Routable
   181/8  LACNIC                                         2010-06
whois.lacnic.net  ALLOCATED    Routable
   182/8  APNIC                                          2009-08
whois.apnic.net  ALLOCATED    Routable
   183/8  APNIC                                          2009-04
whois.apnic.net  ALLOCATED    Routable
   184/8  ARIN                                           2008-12
whois.arin.net   ALLOCATED    Routable
   185/8  RIPE NCC                                       2011-02
whois.ripe.net   ALLOCATED    Routable
   186/8  LACNIC                                         2007-09
whois.lacnic.net  ALLOCATED    Routable
   187/8  LACNIC                                         2007-09
whois.lacnic.net  ALLOCATED    Routable
   188/8  Administered by RIPE NCC                       1993-05
whois.ripe.net     LEGACY    Routable
   189/8  LACNIC                                         1995-06
whois.lacnic.net  ALLOCATED    Routable
   190/8  LACNIC                                         1995-06
whois.lacnic.net  ALLOCATED    Routable
   191/8  Administered by LACNIC                         1993-05
whois.lacnic.net    LEGACY    Routable
   192.0.0.0/24 IPv4 Special Purpose Address Registry    2010-01
RESERVED                   [9]
   192.0.1.0/24 Administered by ARIN                     1993-05
whois.arin.net     LEGACY     Routable
   192.0.2.0/24 IANA TEST-NET-1                          2010-01
RESERVED     Not Routable  [8]
   192.0.3.0/24 Administered by ARIN                     1993-05
whois.arin.net     LEGACY     Routable
   192.0.4.0/22 Administered by ARIN                     1993-05
whois.arin.net     LEGACY     Routable
   192.0.8.0/21 Administered by ARIN                     1993-05
whois.arin.net     LEGACY     Routable
   192.0.16.0/20 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.0.32.0/19 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.0.64.0/18 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.0.128.0/17 Administered by ARIN                   1993-05
whois.arin.net     LEGACY     Routable
   192.1.0.0/16 Administered by ARIN                     1993-05
whois.arin.net     LEGACY     Routable
   192.2.0.0/15 Administered by ARIN                     1993-05
whois.arin.net     LEGACY     Routable
   192.4.0.0/14 Administered by ARIN                     1993-05
whois.arin.net     LEGACY     Routable
   192.8.0.0/13 Administered by ARIN                     1993-05
whois.arin.net     LEGACY     Routable
   192.16.0.0/12 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.32.0.0/11 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.64.0.0/12 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.80.0.0/13 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.88.0.0/18 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.88.0.0/18 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.88.0.0/18 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.88.64.0/19 Administered by ARIN                   1993-05
whois.arin.net     LEGACY     Routable
   192.88.96.0/23 Administered by ARIN                   1993-05
whois.arin.net     LEGACY     Routable
   192.88.98.0/24  Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   192.88.99.0/24 6to4 Relay Anycast                     2001-06
RESERVED     Routable      [8]
   192.88.100.0/22 Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   192.88.104.0/21 Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   192.88.112.0/20 Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   192.88.128.0/17 Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   192.89.0.0/16 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.90.0.0/15 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.92.0.0/14 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.96.0.0/11 Administered by ARIN                    1993-05
whois.arin.net     LEGACY     Routable
   192.128.0.0/11 Administered by ARIN                   1993-05
whois.arin.net     LEGACY     Routable
   192.160.0.0/13  Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   192.168.0.0/16 IANA Private Use                       2001-06
RESERVED     Not Routable  [8]
   192.169.0.0/16 Administered by ARIN                   1993-05
whois.arin.net     LEGACY     Routable
   192.170.0.0/15 Administered by ARIN                   1993-05
whois.arin.net     LEGACY     Routable
   192.172.0.0/14 Administered by ARIN                   1993-05
whois.arin.net     LEGACY     Routable
   192.176.0.0/12 Administered by ARIN                   1993-05
whois.arin.net     LEGACY     Routable
   192.192.0.0/10  Administered by ARIN                  1993-05
whois.arin.net     LEGACY     Routable
   193/8  RIPE NCC                                       1993-05
whois.ripe.net   ALLOCATED    Routable
   194/8  RIPE NCC                                       1993-05
whois.ripe.net   ALLOCATED    Routable
   195/8  RIPE NCC                                       1993-05
whois.ripe.net   ALLOCATED    Routable
   196/8  Administered by AfriNIC                        1993-05
whois.afrinic.net   LEGACY    Routable
   197/8  AfriNIC                                        2008-10
whois.afrinic.net ALLOCATED    Routable
   198/8  Administered by ARIN                           1993-05
whois.arin.net     LEGACY     [10]
   198.0/12 Administered by ARIN                         1993-05
whois.arin.net     LEGACY    Routable
   198.16/15 Administered by ARIN                        1993-05
whois.arin.net     LEGACY   Routable
   198.18/15  IANA - RFC5735                 1999-03           RESERVED
Not Routable  [10]
   198.20/14 Administered by ARIN                        1993-05
whois.arin.net     LEGACY   Routable
   198.24/13 Administered by ARIN                        1993-05
whois.arin.net     LEGACY   Routable
   198.32/12 Administered by ARIN                        1993-05
whois.arin.net     LEGACY   Routable
   198.48/15 Administered by ARIN                        1993-05
whois.arin.net     LEGACY   Routable
   198.50/16 Administered by ARIN                        1993-05
whois.arin.net     LEGACY   Routable
   198.51.0/18  Administered by ARIN                     1993-05
whois.arin.net     LEGACY   Routable
   198.51.64/19 Administered by ARIN                     1993-05
whois.arin.net     LEGACY   Routable
   198.51.96/22 Administered by ARIN                     1993-05
whois.arin.net     LEGACY   Routable
   198.51.96/22A Administered by ARIN                    1993-05
whois.arin.net     LEGACY   Routable
   198.51.100.0/24 IANA - TEST-NET-2                2010-01
RESERVED    Not Routable  [10]
   198.51.101/24 Administered by ARIN                    1993-05
whois.arin.net     LEGACY   Routable
   198.51.102/23 Administered by ARIN                    1993-05
whois.arin.net     LEGACY   Routable
   198.51.102/23 Administered by ARIN                    1993-05
whois.arin.net     LEGACY   Routable
   198.51.112/20 Administered by ARIN                    1993-05
whois.arin.net     LEGACY   Routable
   198.51.128/17 Administered by ARIN                    1993-05
whois.arin.net     LEGACY   Routable
   198.52/14 Administered by ARIN                        1993-05
whois.arin.net     LEGACY   Routable
   198.56/13 Administered by ARIN                        1993-05
whois.arin.net     LEGACY   Routable
   198.64/10 Administered by ARIN                        1993-05
whois.arin.net     LEGACY   Routable
   198.128/9 Administered by ARIN                        1993-05
whois.arin.net     LEGACY   Routable
   199/8  ARIN                                           1993-05
whois.arin.net   ALLOCATED    Routable
   200/8  LACNIC                                         2002-11
whois.lacnic.net  ALLOCATED    Routable
   201/8  LACNIC                                         2003-04
whois.lacnic.net  ALLOCATED    Routable
   202/8  APNIC                                          1993-05
whois.apnic.net  ALLOCATED    Routable
   203.0.0.0/18 APNIC                                    1993-05
whois.apnic.net  ALLOCATED    Routable
   203.0.64.0/19 APNIC                                   1993-05
whois.apnic.net  ALLOCATED    Routable
   203.0.96.0/20 APNIC                                   1993-05
whois.apnic.net  ALLOCATED    Routable
   203.0.112.0/24 APNIC                                  1993-05
whois.apnic.net  ALLOCATED    Routable
   203.0.113.0/24  IANA TEST-NET-3             2010-01              RESERVED
Not Routable  [11]
   203.0.114.0/23 APNIC                                  1993-05
whois.apnic.net  ALLOCATED    Routable
   203.0.116.0/22 APNIC                                  1993-05
whois.apnic.net  ALLOCATED    Routable
   203.0.120.0/21 APNIC                                  1993-05
whois.apnic.net  ALLOCATED    Routable
   203.0.128.0/17 APNIC                                  1993-05
whois.apnic.net  ALLOCATED    Routable
   203.1.0.0/16  APNIC                                   1993-05
whois.apnic.net  ALLOCATED    Routable
   203.2.0.0/15 APNIC                                    1993-05
whois.apnic.net  ALLOCATED    Routable
   203.4.0.0/14 APNIC                                    1993-05
whois.apnic.net  ALLOCATED    Routable
   203.8.0.0/13 APNIC                                    1993-05
whois.apnic.net  ALLOCATED    Routable
   203.16.0.0/12 APNIC                                   1993-05
whois.apnic.net  ALLOCATED    Routable
   203.32.0.0/11 APNIC                                   1993-05
whois.apnic.net  ALLOCATED    Routable
   203.64.0.0/10 APNIC                                   1993-05
whois.apnic.net  ALLOCATED    Routable
   203.128.0.0/9  APNIC                                  1993-05
whois.apnic.net  ALLOCATED    Routable
   204/8  ARIN                                           1994-03
whois.arin.net   ALLOCATED    Routable
   205/8  ARIN                                           1994-03
whois.arin.net   ALLOCATED    Routable
   206/8  ARIN                                           1995-04
whois.arin.net   ALLOCATED    Routable
   207/8  ARIN                                           1995-11
whois.arin.net   ALLOCATED    Routable
   208/8  ARIN                                           1996-04
whois.arin.net   ALLOCATED    Routable
   209/8  ARIN                                           1996-06
whois.arin.net   ALLOCATED    Routable
   210/8  APNIC                                          1996-06
whois.apnic.net  ALLOCATED    Routable
   211/8  APNIC                                          1996-06
whois.apnic.net  ALLOCATED    Routable
   212/8  RIPE NCC                                       1997-10
whois.ripe.net   ALLOCATED    Routable
   213/8  RIPE NCC                                       1993-10
whois.ripe.net   ALLOCATED    Routable
   214/8  US-DOD                                         1998-03
LEGACY    Routable
   215/8  US-DOD                                         1998-03
LEGACY    Routable
   216/8  ARIN                                           1998-04
whois.arin.net   ALLOCATED    Routable
   217/8  RIPE NCC                                       2000-06
whois.ripe.net   ALLOCATED    Routable
   218/8  APNIC                                          2000-12
whois.apnic.net  ALLOCATED    Routable
   219/8  APNIC                                          2001-09
whois.apnic.net  ALLOCATED    Routable
   220/8  APNIC                                          2001-12
whois.apnic.net  ALLOCATED    Routable
   221/8  APNIC                                          2002-07
whois.apnic.net  ALLOCATED    Routable
   222/8  APNIC                                          2003-02
whois.apnic.net  ALLOCATED    Routable
   223/8  APNIC                                          2010-04
whois.apnic.net  ALLOCATED    Routable

Cheers
Terry

---

From: Arturo Servin <[email-masked]>
Date: Mon, 22 Aug 2011 15:00:48 -0300

Terry

	Who defines that one of the other is routable or not?

	For example, 179/8. It assigned to LACNIC but we cannot claim that the whole /8 is routable. It would depend in the allocations and the organisations that are received them to decide if their assignment is or not routable.

	For the rest, I have the following comments (Version 0 looked very different to v1 / v2):

	- I see the importance of the PRI in IANA IPv4 Special Purpose Address Registry but
	- I do not see any technical advantage to include that information in the IPv4 and IPv6 registries (as my comment about 179/8)

"The IANA address registries currently do not have a uniform and
   consistent nomenclature to signal if an allocation is intended to be
   publicly routed"

	Because they are mainly /8 (v4) and /12 (v6) assigned to RIRs, there is no need for any signal or it is irrelevant.

 "Work is underway in the IETF to design and document a number of
   systems or architectures to facilitate the desire to secure the
   Internet routing system."

	Yes, RPKI is the place and technology to do this, not PRI IMHO.

"Such work will require an explicit statement as to the
   intended public routability of an allocation."

	May be (I think it does not), but in any case, the IANA registry is not the place. Also, IANA does not have that information. Neither RIRs.

"This document directs IANA to extend all the IPv4 and IPv6 address
   registries to record Public Routing Intent (PRI) as either "Routable"
   or "Not Routable".

	IANA does not have the mechanisms to do that.

	Also I think that we are going to waters that we should not go (this is going between the technical and policies fields).

Regards,
.as

---

From: Pedro Torres <[email-masked]>
Date: Mon, 22 Aug 2011 16:53:05 -0300

Dears,

I don't know if GROW WG is the best place to suggest such
modifications to IANA but I appreciate Terry I-D.
Acctually we see these things in IANA IPv4 Address Space Registry:
192/8 Administered by ARIN
172/8 Administered by ARIN

Was 192.168/16 or 172.16/12 allocated by ARIN?

I really appreciate the idea to show more specific allocations in this
IANA document.
I am not sure if the column PRI is the best way to do this but a new
way to show ALL IANA allocated prefixes with a reasonable designation
could be nice.

--
Pedro

---

From: Terry Manderson <[email-masked]>
Date: Mon, 22 Aug 2011 23:20:43 -0700

Hi Arturo,

>         Who defines that one of the other is routable or not?

Defines? 

It specifies if the prefix is _intended_ to be routable.

> 
>         For example, 179/8. It assigned to LACNIC but we cannot claim that the
> whole /8 is routable. It would depend in the allocations and the organisations
> that are received them to decide if their assignment is or not routable.

Anything related to 179/8 and the allocations within that are surely the
business of LACNIC. The only thing this is saying is that space within 179/8
is intended to be publically routed. Do you disagree with that statement?
Just as 169.254.0.0/16 is intended as Not Routable. Do you disagree with
that?

>         - I do not see any technical advantage to include that information in
> the IPv4 and IPv6 registries (as my comment about 179/8)
> 

I disagree, I see advantage in that it adds a completely unambiguous
statement of what is routable and what is not. Surely that is helpful for
those people beating their heads against organisations who are still
filtering 1/8, 14/8 etc..

>         Because they are mainly /8 (v4) and /12 (v6) assigned to RIRs, there
> is no need for any signal or it is irrelevant.

I disagree. Signaling the routing intent also provides a perfect reflection
on what should be seen in RPKI through the manifestation of RPKI objects.
see draft-ietf-rpki-iana-objects.

Surely transparency and simplicity there is a good thing!

>         Yes, RPKI is the place and technology to do this, not PRI IMHO.

I'm not with you on that one. RPKI is just one perceived use of this.

>         May be (I think it does not), but in any case, the IANA registry is
> not the place. Also, IANA does not have that information. Neither RIRs.

The IANA certainly should have the ability to say if a prefix allocated or
assigned was intended for seen in a public routing context. The question of
it actually being seen is not in this scope.

>         IANA does not have the mechanisms to do that.

I don't understand your statement.
What specifically do you think IANA does not have a mechanism for?

This is a registry - it records the routing intent of a prefix.
Are you saying that IANA does not have the mechanisms to follow what the
IETF tells it to do?

> 
>         Also I think that we are going to waters that we should not go (this
> is going between the technical and policies fields).

Sorry, you have me confused. What policy field does this enter? Please be
specific. Because I'm not seeing it.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Mon, 22 Aug 2011 23:28:42 -0700

Hi Pedro,

> I don't know if GROW WG is the best place to suggest such

My feel is that it is. So this is where I've started - I've emailed the
Chairs, AD, IAB, IETF separately to investigate.

> Was 192.168/16 or 172.16/12 allocated by ARIN?

See RFC1918. ARIN was started in Dec 1997 from memory. So I think RFC1918
predates ARIN. Those who were around then might be able to shed light.
(Although I think who came first is irrelevant to this draft)

> I am not sure if the column PRI is the best way to do this but a new

The PRI was the simplest option that is easy to understand I could come up
with.

> way to show ALL IANA allocated prefixes with a reasonable designation

I think so too.

Cheers
Terry

---

From: Arturo Servin <[email-masked]>
Date: Tue, 23 Aug 2011 08:56:54 -0300

Terry,

	My basic comment is that this is not a bad idea, in fact is good for the IANA IPv4 Special Purpose Address Registry. But for the IANA registries for v4 and v6 even though there is benefit, the matter of modify them is IMHO complex in nature.

	See some other comments in line.

> is intended to be publically routed. Do you disagree with that statement?

	No, but then IANA registry only holds /8s and almost all of them are routable. The ones that are not routable are described in other RFCs (i.e. 1918). So, the information is not there but we already know it.

> Just as 169.254.0.0/16 is intended as Not Routable. Do you disagree with

	No, but you cannot tag this one in IANA IPv4 Address Space Registry.

> filtering 1/8, 14/8 etc..

	There is and advantage, I won't deny it. But I think that it is too much effort and too little real benefit.

	If people continues to filter 1/8 with all the fuss about IPv4, darknet and so on that we have made, I really doubt that adding a field in IANA registry is going to change that.

> see draft-ietf-rpki-iana-objects.

	Yes, but only for the IANA IPv4 Special Purpose Address Registry. For the rest, what is the benefit vs effort to explicitly state that a specific /12 is routable if we already know that?

> Are you saying that IANA does not have the mechanisms to follow what the

	Besides /8 (v4) and /12 (v6) and the small pieces of IETF reserved space IANA does not have explicit data to say that a prefix is routable or not. Even for the /8s and /12s (and some /23s I think) I am not sure that IANA can unilaterally tag a resource already assigned to the RIRs, in either case is the IETF and IAB who should do it and may be grow is not the place.

> specific. Because I'm not seeing it.

	ASO Global policies. They deal in how assigned space to RIR is managed in a global scope, they also instructs IANA how to allocate space to them. Why tagging the allocated space as routed should be out (or in) of global policies? (rhetorical question)

	You are intended to modify space assigned to RIRs (some of them), some may argue (not me now) that this should be dealt as a global policy coming from the RIRs. Other may say that is IETF matter in grow, some other IAB. Honestly I am not sure which one is the rightful owner to decide what to do. But I think that this could easy turn complex and the benefit is so little that it is not worth of the discussion.

> Terry

Best wishes,
.as

---

From: Pedro Torres <[email-masked]>
Date: Tue, 23 Aug 2011 10:29:17 -0300

Arturo,

Who did define the RIR Statistics Exchange Format?
ftp://ftp.lacnic.net/pub/stats/lacnic/RIR-Statistics-Exchange-Format.txt

Could it not be a IETF work? I think a RFC could be nice place to
define it because the way it is done today don't have any version
control, authors, obsoleted standard's, etc. IANA could use that
definition too... perhaps creating a new value to the 'status' column
or a new column: PRI.

I like the RIR Statistics Exchange Format. It is an easily-parseable
representation.
I don't like the IANA format because some important parts are
'Footnotes': hardly-parseable.

I would like to use a RFC to create my parser instead an unknown
defined doc that can change anytime.

Terry, if you wanna extend your I-D to create a standart to all RIR's
and an IETF WG is the right place to do this: I am available to help
you.

Best Regards,
Pedro

---

From: Arturo Servin <[email-masked]>
Date: Tue, 23 Aug 2011 10:49:38 -0300

Pedro,

	Not sure how the format was defined years ago, may be somebody in the list could answer this.

	However there is a new format that APNIC and RIPE NCC are using:

	http://labs.ripe.net/Members/mirjam/new-ripe-ncc-address-statistics-reports

	ftp://ftp.apnic.net/public/stats/apnic/README-EXTENDED.TXT
	
	In LACNIC we are planning to adopt a compatible format too. 

	Regarding an informational RFC about this format, I'll ask around.

	Now, same as my comments regarding IANA, I am not sure if RIRs have explicit information about the routability of a prefix to include them in the stats file, otherwise they would be IRRs and not RIRs. 

Regards,
-as

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 23 Aug 2011 16:06:50 +0100

> 	No, but you cannot tag this one in IANA IPv4 Address Space Registry.

I'm not convinced by this ID.  The "Routable" column isn't flexible enough
for the IANA v4 allocations list because IANA deals with multiples of /8
(for ipv4 allocations), while individual non-routable prefixes can be as
small as /24.  This alone calls into question whether the basic premise of
the draft is worth pursuing.

Would it not be better to approach this problem from a completely different
direction?  E.g. to formally recommend that end users consider everything
routable except address space defined in RFC 3330 + its successors + the
equivalent for ipv6?  And then perhaps to put in some scary wording about
the terrible consequences of using address space on your network that has
been assigned to other organisations?

Nick

---

From: Terry Manderson <[email-masked]>
Date: Tue, 23 Aug 2011 22:13:17 -0700

Hi Arturo,

On 23/08/11 9:56 PM, "Arturo Servin" <[email-masked]> wrote:

> Terry,
> 
>         My basic comment is that this is not a bad idea, in fact is good for
> the IANA IPv4 Special Purpose Address Registry. But for the IANA registries
> for v4 and v6 even though there is benefit, the matter of modify them is IMHO
> complex in nature.

I just don't see the complexity. Its an extra column that specifies the
routing intent[1], and gives a clear signal if anything should change, for
example the 'future use' blocks or 6to4 (without rehashing that escapade).

[1] I'll iterate, this says that the prefix is intended to be routable. It
doesn't say that it must be routable, or makes any guarantees. But gives a
strong explicit indication of what is already implied.

>         No, but then IANA registry only holds /8s and almost all of them are
> routable. The ones that are not routable are described in other RFCs (i.e.
> 1918). So, the information is not there but we already know it.

Actually no, the IANA is the registry for /0. It points to who administers
the allocations irrespective of prefix length.

>         No, but you cannot tag this one in IANA IPv4 Address Space Registry.

Why not? it was reserved by IETF action in an IANA considerations section.
yes?

> much effort and too little real benefit.

too much effort? That is an interesting point of view.

> 
>         If people continues to filter 1/8 with all the fuss about IPv4,
> darknet and so on that we have made, I really doubt that adding a field in
> IANA registry is going to change that.

Just a few weeks ago I pointed out both no-more-slash-8s and routing-intent
to an australian operator who was having a painful time with an allocation
in filtering. He used both of them as arguments to one organisation doing
the filtering and got positive movement.

I am in the boat that every little bit helps.

>         Yes, but only for the IANA IPv4 Special Purpose Address Registry. For
> the rest, what is the benefit vs effort to explicitly state that a specific
> /12 is routable if we already know that?

because it makes it obvious. It helps people that are not fully and 100%
glued to the registry(ies) published data.

It allows people to 'double check' what gets published as RPKI objects
conforms to the obvious expectation. This builds trust.

>         Besides /8 (v4) and /12 (v6) and the small pieces of IETF reserved
> space IANA does not have explicit data to say that a prefix is routable or

It certainly has enough information in RFCs to say that a prefix is
_intended_ to be routable. yes?

> not. Even for the /8s and /12s (and some /23s I think) I am not sure that IANA
> can unilaterally tag a resource already assigned to the RIRs, in either case
> is the IETF and IAB who should do it and may be grow is not the place.

So are you suggesting that when a prefix is allocated IANA can no longer add
information about that allocation? That seems wrong to me.

And IANA isn't unilaterally doing anything. It is being told what to do by
the IETF process.

>         ASO Global policies. They deal in how assigned space to RIR is managed
> in a global scope, they also instructs IANA how to allocate space to them. Why
> tagging the allocated space as routed should be out (or in) of global
> policies? (rhetorical question)

Um.. I'm not an ASO policy expert (and nor should I be) as routing-intent
doesn't affect how the allocations are made to the RIRs. It doesn't change
any of it (based on my quick read). If it does, please point out the
paragraphs and the policies where it does.

> 
>         You are intended to modify space assigned to RIRs (some of them), some

By saying that the space that is allocated to them is intended to be
routable (minus any segments that are reserved by IETF direction)??

I'm strugglng to see how that is 'modified'.. If I were to say turn the
status of 203/8 from 'allocated' to 'reserved' then I would be with you as
that is grossly inappropriate.

> may argue (not me now) that this should be dealt as a global policy coming
> from the RIRs. Other may say that is IETF matter in grow, some other IAB.
> Honestly I am not sure which one is the rightful owner to decide what to do.
> But I think that this could easy turn complex and the benefit is so little
> that it is not worth of the discussion.

Interesting perspective :-)

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Tue, 23 Aug 2011 22:13:29 -0700

Hi Pedro,

> ftp://ftp.lacnic.net/pub/stats/lacnic/RIR-Statistics-Exchange-Format.txt

I believe it was a collection of RIR staff that defined the format.

> I like the RIR Statistics Exchange Format. It is an easily-parseable

It is. And I use it too.

> 'Footnotes': hardly-parseable.

indeed.

> Terry, if you wanna extend your I-D to create a standart to all RIR's

The RIRs have already done this work - I think I'll leave it to them to
bring that to the IETF.

> and an IETF WG is the right place to do this: I am available to help

The extra column to the IANA IPv4/IPv6 registries is a simple add. Intended
to satisfy a couple use cases.

The RIR format is quite encompassing and has fields that I don't believe I
would need to see in an IANA registry.

Cheers
Terry

---

From: Terry Manderson <[email-masked]>
Date: Tue, 23 Aug 2011 22:13:32 -0700

Hi Nick,

> for the IANA v4 allocations list because IANA deals with multiples of /8

Actually IANA deals with any prefix length it is told to by the IETF. The
smallest one being a /24 (documentation prefix) the largest one being a /4
... in IPv4 terms.

So far I could not find any RFC which specified in any way what the prefix
length of the entry in the IANA registry should be. Certainly the RIRs are
allocated in /8 chunks. No denial there. And also given that the IETF
reservations vary in prefix length. My guess is that the prefix length
selection was arbitrary for parsimony. But if anyone has a specific pointer
It would be most appreciated.

> the draft is worth pursuing.

I think it justifies it more. If everything was considered routable, and no
differences of prefix length existed then there would be no point. But that
just isn't the case.

> equivalent for ipv6?

In a way this draft does exactly that. Just explicitly - and in truth that
is always what I thought was the great thing about the IETF. If you are
going to write something, or change something - make it explicit.

> And then perhaps to put in some scary wording about

That is a uniqueness point that I'm not addressing.

Cheers
Terry

---

From: Geoff Huston <[email-masked]>
Date: Wed, 24 Aug 2011 15:54:46 +1000

Hi Terry,

> example the 'future use' blocks or 6to4 (without rehashing that escapade).

And I still don't see the point of adornment of an IANA Address Allocation registry with this additional field.

My earlier comments objecting to this draft, as related in http://www.ietf.org/mail-archive/web/grow/current/msg01999.html, noting issues of charter scope, IAB roles and institutional overlap of IANA contractor staff are unaltered after reading through the example and the followup conversations.

regards,

    Geoff

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 25 Aug 2011 20:58:09 -0700

> been assigned to other organisations?

+1

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 25 Aug 2011 21:12:12 -0700

> (Although I think who came first is irrelevant to this draft)

As RC 1918 states the prefixes were allocated by IANA, 10/8 was the
arpanet before it was shut off.

You will note that one of the authors worked for the RIPE NCC which did
exist at the time.