IAB and "private" numbering

Hi Dave,

In response to your request for more interaction w/the IAB, here's a
peeve I've been developing lately and perhaps this outlet might be
appropriate for it.

There are some resources, like IP addresses and AS numbers, the proper
operation of which hinges on their uniqueness.

Generally, people seem to understand that it's only their uniqueness
within a domain that is required; however, there is no telling when
domains which may not be connected may become so in the future.
RFC1918 has definitely caused problems for me personally many times
and I feel certain the experience is far from rare. I'm not saying
that reserved numbers for private uses aren't needed. There are still
labs and other example configurations where they might be of use.
RFC1918 might seem to alleviate some operational problems but it
certainly creates many others.

The registries (including IANA as their root) should provide just
that, a place to register the use of number resources to avoid collisions.
I'm thinking that "private" number spaces should probably be used
advisedly if not deprecated outright.

I could add more detail if desired for the sake of clarity.

I'd like to see some acknowledgement that there are legitimate uses of
number resources that don't include "the public Internet".
IAB should perhaps claim to the Architecture of "TCP/IP protocol
technology" or however it would be best construed to convey that
these technologies are used outside "the [public] Internet" and that
their integrity and viability needs to be protected broadly.

Does this concern make sense?
Does this course of action make sense?
Is there a(nother) better venue than the IAB?
What do people think?

Tony

ps. My goal is not to inflame, merely to discuss and educate.

The registries (including IANA as their root) should provide just
that, a place to register the use of number resources to avoid collisions.
I'm thinking that "private" number spaces should probably be used
advisedly if not deprecated outright.

RIR's are taking heat (or some finger pointing atleast) for allocations
that don't appear in the public route table. There are many reasons why
the allocation might not appear in the table, I'm not convinced that
measuring the public table is any real way to measure 'in use' status for
ip space, though it's one gauge people seem to be using. If there is a
legittimate need to use some ip space NOT in a public manner, one for
which 1918 might not be appropriate, perhaps having a registration method
'in region' (with the RIR's who already have the machinations to do ip
number registrations and delegations) would make some sense?

I recall, I believe, a policy proposal 1 or 2 ARIN's ago that would have
included some form of 'private' or 'public' stamp/category on ip
registration data? Perhaps reviving that, or making a new one, would be in
order?

How do the currently allocated folks feel about sending in registration
info now? Assume no payment, or minimum payment for registration 'work'
in included? Would we be able to get all of the relevant parties to sign
up/register/keep-up-to-date ?

Example registered but not 'routed': 7.0.0.0/8

Would we want to change whois output to include the 'pub/priv' flag?

or perhaps I completely missed the mark? :slight_smile:

I could add more detail if desired for the sake of clarity.

I'd like to see some acknowledgement that there are legitimate uses of
number resources that don't include "the public Internet".

I'm curious where the 'non-legitimate' use came from? (or why the
perception is that the only legitimate use is 'public Internet', having a
nutjob internal network at work with all manner of kookiness built into
it I know of atleast 1 large network that has parts not routed or
available in the 'public internet', previous jobs give other good
examples as well.)

ps. My goal is not to inflame, merely to discuss and educate.

<aol>me too</aol>

>
> The registries (including IANA as their root) should provide just
> that, a place to register the use of number resources to avoid collisions.
> I'm thinking that "private" number spaces should probably be used
> advisedly if not deprecated outright.

RIR's are taking heat (or some finger pointing atleast) for allocations
that don't appear in the public route table. There are many reasons why

i rant, yet again.

  what is this "the" public routing table? where does one
  get it? in my 25 years of networking I have NEVER seen it.
  i am convinced that it is a fictional as the "public" Internet.
  or the "DFZ" ... they do not exist, except in the fevered
  imaginations of marketing droids... and the virus is more virulent
  than the H5N1 strain. Note that it affects normally sane engineers
  who KNOW better.

  back in the SRInic days, there was the "connected" and "unconnected"
  databases. ... to mark prefixes that were connected to the ARPAnet
  and those that were in "private" networks, like CSnet, NSFnet, and
  enterprise networks. Tony is right in this respect, RFC1918 space
  is a feeble attempt to get around/past the lack of address space
  that became apparent in IPv4 ... with IPv6, there is no real
  reason to try and recreate private space (leaving aside renumbering)

  IMHO, assigning globally unique prefixes to those who utilize IP
  protocols, regardsless of whom else they choose to "see" via routing
  is the right course. every other attempt to split the assignements
  into "us" vs. "them" has had less than satisfactory results.

  I am unconvinced that it can be made to work successfully in the
  future.

> I'd like to see some acknowledgement that there are legitimate uses of
> number resources that don't include "the public Internet".

I'm curious where the 'non-legitimate' use came from? (or why the
perception is that the only legitimate use is 'public Internet', having a
nutjob internal network at work with all manner of kookiness built into
it I know of atleast 1 large network that has parts not routed or
available in the 'public internet', previous jobs give other good
examples as well.)

  amen.

--bill

bmanning@vacation.karoshi.com wrote:

The registries (including IANA as their root) should provide just
that, a place to register the use of number resources to avoid collisions.
I'm thinking that "private" number spaces should probably be used
advisedly if not deprecated outright.

RIR's are taking heat (or some finger pointing atleast) for allocations
that don't appear in the public route table. There are many reasons why

A prefix doesn't have to reside in this beast called 'DFZ' for to be
used. There is (atm) no need for one to announce the address space used
by their cool chocolate factory machines, but maybe in the future one
might want to do it to be able to monitor from the comfort of ones home.
Thus the address space does need to be globally unique.

i rant, yet again.

  what is this "the" public routing table? where does one
  get it? in my 25 years of networking I have NEVER seen it.

Have you seen the moon? Touched it? I still can't be convinced that
pluto exists, I haven't seen it, but it appears to be there :wink:

  i am convinced that it is a fictional as the "public" Internet.
  or the "DFZ" ... they do not exist, except in the fevered
  imaginations of marketing droids... and the virus is more virulent
  than the H5N1 strain. Note that it affects normally sane engineers
  who KNOW better.

Well I apparently have a lot of nasty viruses floating around in my body
at Ghost Route Hunter : IPv6 DFP visibility :: SixXS - IPv6 Deployment & Tunnel Broker I used "DFP" with which I mean:

"Default Free Prefix, a prefix routed without having any smaller
prefixes covering it. Removing such a prefix will make the
prefix unreachable."

DFZ would be the group of all DFP's.

  back in the SRInic days, there was the "connected" and "unconnected"
  databases. ... to mark prefixes that were connected to the ARPAnet
  and those that were in "private" networks, like CSnet, NSFnet, and
  enterprise networks. Tony is right in this respect, RFC1918 space
  is a feeble attempt to get around/past the lack of address space
  that became apparent in IPv4 ... with IPv6, there is no real
  reason to try and recreate private space (leaving aside renumbering)

Indeed.

  IMHO, assigning globally unique prefixes to those who utilize IP
  protocols, regardsless of whom else they choose to "see" via routing
  is the right course. every other attempt to split the assignements
  into "us" vs. "them" has had less than satisfactory results.

Absolutely. Address space is there to address hosts and thus should be
made available to places that have a hosts.

The only issues at a certain point will become routing table size and
that is the new problem to fix, there is now "enough" address space.
(Taking into consideration that 2000::/3 is only 1/8th of the total IPv6
address space and that we can peep up 8 times before it runs out :slight_smile:

Greets,
Jeroen

> i rant, yet again.
>
> what is this "the" public routing table? where does one
> get it? in my 25 years of networking I have NEVER seen it.

Have you seen the moon? Touched it? I still can't be convinced that
pluto exists, I haven't seen it, but it appears to be there :wink:

  seen them both.

> i am convinced that it is a fictional as the "public" Internet.
> or the "DFZ" ... they do not exist, except in the fevered
> imaginations of marketing droids... and the virus is more virulent
> than the H5N1 strain. Note that it affects normally sane engineers
> who KNOW better.

Well I apparently have a lot of nasty viruses floating around in my body
at Ghost Route Hunter : IPv6 DFP visibility :: SixXS - IPv6 Deployment & Tunnel Broker I used "DFP" with which I mean:

"Default Free Prefix, a prefix routed without having any smaller
prefixes covering it. Removing such a prefix will make the
prefix unreachable."

DFZ would be the group of all DFP's.

  routed where? your router? my router? until/unless
  you can look at EVERY router and see this mythical DFP
  in ALL of them, then i remain convinced you are deluded.

Jeroen

--bill

>
>
> >
> > The registries (including IANA as their root) should provide just
> > that, a place to register the use of number resources to avoid collisions.
> > I'm thinking that "private" number spaces should probably be used
> > advisedly if not deprecated outright.
>
> RIR's are taking heat (or some finger pointing atleast) for allocations
> that don't appear in the public route table. There are many reasons why

i rant, yet again.

doh!

  what is this "the" public routing table? where does one
  get it? in my 25 years of networking I have NEVER seen it.
  i am convinced that it is a fictional as the "public" Internet.
  or the "DFZ" ... they do not exist, except in the fevered
  imaginations of marketing droids... and the virus is more virulent
  than the H5N1 strain. Note that it affects normally sane engineers
  who KNOW better.

'public routing table' == Internet

nothing more, nothing less. this is distinct from SIPRnet and some
portions of NIPRnet, or other 'private' networks out there.

  back in the SRInic days, there was the "connected" and "unconnected"
  databases. ... to mark prefixes that were connected to the ARPAnet
  and those that were in "private" networks, like CSnet, NSFnet, and
  enterprise networks. Tony is right in this respect, RFC1918 space
  is a feeble attempt to get around/past the lack of address space
  that became apparent in IPv4 ... with IPv6, there is no real
  reason to try and recreate private space (leaving aside renumbering)

I don't believe there is a 'rfc1918' in v6 (yet), I agree that it doesn't
seem relevant, damaging perhaps though :slight_smile:

  IMHO, assigning globally unique prefixes to those who utilize IP
  protocols, regardsless of whom else they choose to "see" via routing
  is the right course. every other attempt to split the assignements
  into "us" vs. "them" has had less than satisfactory results.

agreed

'public routing table' == Internet

  as seen from which ASN? or are they all the same?
  if you don't have a more specific, or a covering prefix
  and are not deluding yourself (aka Sprint circa 1994
  w/ the great 192.0.0.0/3 lie) does NOT mean you have
  a full routing table... it just means you have a covering
  prefix or more specific prefix from each of your peers...
  <voila, the DFZ> does not mean you have all routes tho.

nothing more, nothing less. this is distinct from SIPRnet and some
portions of NIPRnet, or other 'private' networks out there.

  as alluded to earlier, "private" networks overtook the
  "Internet" before... it could happen again. :slight_smile:

--bill

<snip>

I don't believe there is a 'rfc1918' in v6 (yet), I agree that it doesn't
seem relevant, damaging perhaps though :slight_smile:

Sort of do, with a random component in them to help attempt to prevent
collisions :

"RFC 4193 - Unique Local IPv6 Unicast Addresses"
http://www.faqs.org/rfcs/rfc4193.html

>
> IMHO, assigning globally unique prefixes to those who utilize IP
> protocols, regardsless of whom else they choose to "see" via routing
> is the right course. every other attempt to split the assignements
> into "us" vs. "them" has had less than satisfactory results.

agreed

See above ... that was pretty much the fundamental goal of ULAs - unique
address space, not dependant on a provider, not intended to be globally
routable, preferred over global addresses so that connections can
survive global address renumbering events.

Regards,
Mark.

>
> 'public routing table' == Internet

  as seen from which ASN? or are they all the same?
  if you don't have a more specific, or a covering prefix
  and are not deluding yourself (aka Sprint circa 1994
  w/ the great 192.0.0.0/3 lie) does NOT mean you have
  a full routing table... it just means you have a covering
  prefix or more specific prefix from each of your peers...
  <voila, the DFZ> does not mean you have all routes tho.

yes, I give :slight_smile:

> nothing more, nothing less. this is distinct from SIPRnet and some
> portions of NIPRnet, or other 'private' networks out there.

  as alluded to earlier, "private" networks overtook the
  "Internet" before... it could happen again. :slight_smile:

I'd venture to guess that they have already... it's tough to measure
though.

and here I thought we voted that down in atleast ARIN space :frowning: bummer,
more failure coming your way as you sit and wait :frowning:

Example registered but not 'routed': 7.0.0.0/8

Not a good example.

This particular /8 allocation is described by IANA as "007/8 Apr 95 IANA - Reserved" in IANA IPv4 Address Space Registry while a whois query to the ARIN database reveals:

$ whois 7.0.0.0

OrgName: DoD Network Information Center
OrgID: DNIC
Address: 3990 E. Broad Street
City: Columbus
StateProv: OH
PostalCode: 43218
Country: US

NetRange: 7.0.0.0 - 7.255.255.255
CIDR: 7.0.0.0/8
NetName: DISANET7
NetHandle: NET-7-0-0-0-1
Parent:
NetType: Direct Allocation
Comment: Defense Information Systems Agency
Comment: DISA /D3
Comment: 11440 Isaac Newton Square
Comment: Reston, VA 22090-5087 US
RegDate: 1997-11-24
Updated: 1998-09-26

RTechHandle: MIL-HSTMST-ARIN
RTechName: Network DoD
RTechPhone: +1-800-365-3642
RTechEmail: HOSTMASTER@nic.mil

OrgTechHandle: MIL-HSTMST-ARIN
OrgTechName: Network DoD
OrgTechPhone: +1-800-365-3642
OrgTechEmail: HOSTMASTER@nic.mil

# ARIN WHOIS database, last updated 2005-11-12 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.

So in this case who is telling the truth? IANA or ARIN? Is this, as ARIN data is claiming, an address block that is currently allocated to the US Dept of Defense via a "direct allocation" (by IANA presumably, but unspecified in any case), or is this, as IANA data is claiming, an address block that is currently in the IANA reserved pool and can be allocated to an RIR in the future. Go figure.

Would we want to change whois output to include the 'pub/priv' flag?

or "conflicting data" flag?

or perhaps I completely missed the mark? :slight_smile:

no comment :slight_smile:

     Geoff

Such applaudable absolutism does you credit in a manner not inconsistent with a self referential version of this same observation.

:slight_smile:

   Geoff

I don't believe there is a 'rfc1918' in v6 (yet), I agree that it doesn't
seem relevant, damaging perhaps though :slight_smile:

So you how would interpret the combination of RFC4913 and the statistical analysis known as "the birthday problem"? I offer the interpretation of this as use of address space in a limited context that has a likelihood of collision at the prefix level with some other similar, but unrelated, use. I would characterize a more exact equivalent of RFC 1918 space in an IPv6 context as use of address space in a limited context that has a certainty of collision at the prefix level with some other similar, but unrelated, use.

It would appear that we are already well advanced down a path of reproducing many of the aspects of IPv4 address architecture in IPv6, to the point of producing analogies of RFC1918 private address space. It also seems to me that this entire thread is constructed upon a somewhat dubious initial premise, but then again that's not exactly uncommon is it? :slight_smile:

   Geoff

Christopher L. Morrow wrote:

...

I don't believe there is a 'rfc1918' in v6 (yet), I agree that it doesn't
seem relevant, damaging perhaps though :slight_smile:

Yes, there was rfc1918 in IPv6 right from the beginning:

Site local addresses "0xF80" dont leave a site. They can be routed within
a site but they never get outside. Just like rfc1918 addresses do.

Link local addresses that cannot even leave a link. Even more restrictive
than rfc1918. Just like old netbios used to be before it was ported to
tcp/ip, ipx and decnet.

regards
Peter and Karin

I'd like to see some acknowledgement that there are legitimate uses of
number resources that don't include "the public Internet".

It's already there in RFC 2050:

3 a) the organization has no intention of connecting to
     the Internet-either now or in the future-but it still
     requires a globally unique IP address. The organization
     should consider using reserved addresses from RFC1918.
     If it is determined this is not possible, they can be
     issued unique (if not Internet routable) IP addresses.

Does this concern make sense?

No.

Is there a(nother) better venue than the IAB?

ARIN, RIPE, APNIC, LACNIC, AfriNIC, NRO

My company is one of several companies that operate
IP networks that are not part of the public Internet but
which do use globally unique registered IP addresses.

--Michael Dillon

   what is this "the" public routing table? where does one
   get it? in my 25 years of networking I have NEVER seen it.
   i am convinced that it is a fictional as the "public" Internet.
   or the "DFZ" ... they do not exist, except in the fevered
   imaginations of marketing droids... and the virus is more virulent
   than the H5N1 strain. Note that it affects normally sane engineers
   who KNOW better.

I think that many, many people make the assumption that a service
like RouteViews or RIS holds "the" global routing table because
they peer widely in all regions to collect the data.

   IMHO, assigning globally unique prefixes to those who utilize IP
   protocols, regardsless of whom else they choose to "see" via routing
   is the right course. every other attempt to split the assignements
   into "us" vs. "them" has had less than satisfactory results.

I think that many people make the assumption that IP
addresses can only be used on the Internet because they
learned that IP stands for Internet Protocol.

--Michael Dillon

I'd like to see some acknowledgement that there are legitimate uses
of number resources that don't include "the public Internet".

It's already there in RFC 2050:

Thanks for the reminder.

3 a) the organization has no intention of connecting to
    the Internet-either now or in the future-but it still
    requires a globally unique IP address. The organization
    should consider using reserved addresses from RFC1918.
    If it is determined this is not possible, they can be
    issued unique (if not Internet routable) IP addresses.

FWIW, I'd change s/routable/routed/g since all addresses are "routable". Once I actually heard someone say "a Cisco won't even accept a 10 net
address". Not sure how that person thought all those addresses are
being used, then. Imagine Cisco cutting itself off from the lucrative
RFC1918 market...

Does this concern make sense?

No.

Is there a(nother) better venue than the IAB?

ARIN, RIPE, APNIC, LACNIC, AfriNIC, NRO

I just get concerned when hearing people (e.g. at the recent
ARIN/NANOG meeting) talking about reclaiming address-space or ASNs
based on lack of appearance in "Public".
I'm not saying that reclaimation shouldn't be pursued, but that it
should use other criteria or procedures.

Tony

RFC1627, "Network 10 Considered Harmful (Some Practices Shouldn't be
Codified)" and RFC3879, "Deprecating Site Local Addresses" provide some
good examples of where duplicate or overlapping address spaces cause
problems, which is what happens when different organisations use RFC1918
addresses, even if they aren't connected to the Internet.

Geoff,

This particular /8 allocation is described by IANA as "007/8 Apr 95 IANA - Reserved" in IANA IPv4 Address Space Registry while a whois query to the ARIN database reveals:
$ whois 7.0.0.0
...
RegDate: 1997-11-24
Updated: 1998-09-26
...
So in this case who is telling the truth? IANA or ARIN?

Well, IANA's registry claims data from 4/95 and ARIN's registry claims data from 9/98. I know which I would think would be telling the truth.

Would we want to change whois output to include the 'pub/priv' flag?

or "conflicting data" flag?

Nah. The right answer is to synchronize the data somehow. The data could either be replicated or a referral could be provided. Not rocket science.

I think I can state authoritatively (:-)) that the IANA is aware of (at least some of) the discrepancies and has address registry data synchronization on its priority list.

Rgds,
-drc

I think I can state authoritatively (:-)) that the IANA is aware of
(at least some of) the discrepancies and has address registry data
synchronization on its priority list.

Thank you - as you are aware I've documented what I have seen in terms of discrepencies at
http://draft-huston-ipv4-iana-registry.potaroo.net

The /8s that merit some further consideration in terms of resolving potentially inconsistent views of the IPv4 address world include 7.0.0.0/8, 46.0.0.09/8, and 191.0.0.0/8, as well as a wealth of other smaller details.

regards,

     Geoff