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.
On Fri, 11 Nov 2005, Tony Tauber 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 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? :)
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>
On Sat, Nov 12, 2005 at 04:40:20PM +0000, Christopher L. Morrow wrote:
On Fri, 11 Nov 2005, Tony Tauber 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
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:
On Sat, Nov 12, 2005 at 04:40:20PM +0000, Christopher L. Morrow 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
On Fri, 11 Nov 2005, Tony Tauber wrote: 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 ;)
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 http://www.sixxs.net/tools/grh/dfp/ 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 :) 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 ;)
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 http://www.sixxs.net/tools/grh/dfp/ 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
At 05:41 AM 13/11/2005, bmanning@vacation.karoshi.com wrote:
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.
Such applaudable absolutism does you credit in a manner not inconsistent with a self referential version of this same observation. :-) Geoff
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
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 http://www.iana.org/assignments/ipv4-address-space 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? :)
no comment :-) Geoff
Geoff, On Nov 13, 2005, at 9:14 AM, Geoff Huston wrote:
This particular /8 allocation is described by IANA as "007/8 Apr 95 IANA - Reserved" in http://www.iana.org/assignments/ipv4- address-space 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
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
On Mon, 14 Nov 2005, Michael.Dillon@btradianz.com wrote:
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
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
On Mon, 14 Nov 2005 11:36:00 +0000 Michael.Dillon@btradianz.com wrote:
I'd like to see some acknowledgement that there are legitimate uses of number resources that don't include "the public Internet".
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. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier
On 15.11 07:38, Mark Smith wrote:
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.
This is practical engineering, not theoretical science. Practical engineering is about *trade-offs*. We were seeing address space requests for huge deployments with a real low probability to ever be routed anywhere beyond a quite local domain. There are huge deployments of this kind now and happily so without unnecessary using finite address resources. The drawbacks were known and discussed. Note that 1627<1918. Clear warnings were written into 1918; it is one of the more "operational" RFCs, certainly at the time. We also discussed the possibility of NATs but it was out-of-scope for 1918; we discussed application layer gateways though; we did not anticipate any NAT deployments beyond a very local scale. Would we rather have run out of unallocated unique IPv4 address space at some point in the past? Would an alternative have been ready by then? (Would we rather run out of unallocated IPv4 address space on -say- 31-Dec-2005? Will IPv6 be ready for prime time then?) Daniel One of the instigators and co-author of RFC1918.
On Thu, 17 Nov 2005 17:44:10 +0100 Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:
On 15.11 07:38, Mark Smith wrote:
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.
This is practical engineering, not theoretical science. Practical engineering is about *trade-offs*.
All I know is that I've had bad experiences with duplicated or overlapping address spaces. One particularly bad one was spending two months developing templates for combinations of NAT / NAPT for Internet / VPN access (e.g. NAT to Internet, not VPN; NAT to VPN, not Internet; NAPT to Internet, NAT to VPN, different "to" address spaces for NAT to the Internet and NAT to the VPN etc. etc.). In addition to developing these solutions I also sat scratching my head for two months asking "why not just give them public address space, restoring uniqueness to their addressing, so I can work on improving the product rather than just developing work arounds ?". Spending time on work arounds, as well as building protocol and other limitations into the network that will be encountered in the future, isn't a good trade-off in my opinion. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier
At 13:59 -0800 11/11/05, Tony Tauber wrote:
There are some resources, like IP addresses and AS numbers, the proper operation of which hinges on their uniqueness.
...
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?
(Yeah, I did read the rest of the thread, but am replying to the original message.) I think there are a few dilemmas in this topic. One stems from the RIR's duty to provide stewardship of the number resources they administer. The other is the dividing line between protocol design (IAB) and operations (RIRs). One concern from this is number resources depletion, which is why, in my estimation, there are people measuring things like announced space and time to network with AS numbers. (I'm referring to work Geoff Huston, Tony Hain, and Henk U of RIPE have presented in numerous locations in the past few months.) When a resource is becoming scarce, there's a push to try and be certain that it is being used efficiently, with efficiency measured in terms of time to depletion. With this in mind, if a resource is used privately, why can't it be used publicly too by some deserving? (I ask this rhetorically as an example.) Stewardship also means uniqueness too, or at least uniqueness in some scope. (A 48 bit number could be a "hardware address" or a combination IPv4 and port number, as an example of stretching.) To achieve this, the RIRs would naturally assign an number to anyone deserving, regardless of how the network is connected. Combine that with a third dimension, that the RIRs are run in the context of some sort of public trust, there are folks that will want to check up on them. That's where we get folks probing the exposed data (via whois, say) and seeing what they can get to. I think this is where the assumption of a "public internet" comes from. This is a three-way conflict centered on the RIRs. There's the whole matter of the benefit vs. pain of scoped (as in site local, link local, RFC 1918) addressing. That's a matter for the protocol engineers to figure out, I think that is something the IAB would be concerned about - if not so already. I don't think that you want to have the directory services of the RIRs (whois today) flag addresses as public use or private use, but you do what the defined protocol scope clearly indicated. The reason for not labelling public or private is that there are multiple private (if there is indeed one true public). If you see two private addresses, can they see each other? In as much as we don't want the RIR's in the routers, we shouldn't put the routers into the RIRs. The outcome of this is that folks probing and prodding the data in the RIRs ought to not expect to see all the resources registered therein on the public Internet. It would tempting to say not to worry about unseen resources, to assume they are in the private areas of the world. However, there are probably resources that are "lost" - allocated in the days when IANA was a small part of ISI and things were done on paper. In the effort to stop depletion, these should be reclaimed, but deciding what is lost versus what is in private use is ... a dilemma. My experience in this is tied to DNS and lame delegations. Just like the routing table issue, we have delegations into places that are not reachable. A name server may be situated in a way in which "it can see out" but "we cannot see in." The problem with these seems to be some past implementations of DNS that looped as a result of lame delegations (in this case situations in which the desired name server[s] are not reachable). Maybe this is where the IAB steps in, and looks for documents showing how members of a network, whether the public or a private network, can either protect themselves from trying to reach unreachable areas, or to set up stub or proxy services to absorb ill-fated traffic destined to an unreachable address. I'm not sure this is feasible - the DNSOP WG seems to have killed, or is about to kill a document on "don't publish unreachable things in the DNS." As much as that sounds useful, there was no energy in the group to finish the document. A lack of energy tells me something. Scoped addresses do run afoul of the theory that a network is a collection on mutually reachable endpoints. Once you scope an address, you've lost the theory of the network layer. Still, it does work to do this, so it's not that it's impossible, it's that the theory needs to be, umm, scoped. I've thought far less about this, but that's the kind of thing that the IAB might weigh in on, if there is the energy to do so. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar 3 months to the next trip. I guess it's finally time to settle down and find a grocery store.
participants (10)
-
bmanning＠vacation.karoshi.com -
Christopher L. Morrow -
Daniel Karrenberg -
David Conrad -
Edward Lewis -
Geoff Huston -
Jeroen Massar -
Mark Smith -
Michael.Dillon＠btradianz.com -
Tony Tauber