Re: Post-Exhaustion-phase "punishment" for early adopters
Hint: even IPs not pingable from the Internet are being used. Not everyone is an ISP/Webhoster ... with public services.
I thought that was why we have RFC1918 ?
Before arin etc it was possible to request ip space and on the form specify you would not be connecting to the Internet. Jared Mauch On Feb 8, 2011, at 9:35 AM, gb10hkzo-nanog@yahoo.co.uk wrote:
Hint: even IPs not pingable from the Internet are being used. Not everyone is an ISP/Webhoster ... with public services.
I thought that was why we have RFC1918 ?
I've worked in plenty of places where registered address was used on private interconnections between organisations to avoid overlaps, but never announced globally. S On 8 Feb 2011, at 14:35, gb10hkzo-nanog@yahoo.co.uk wrote:
Hint: even IPs not pingable from the Internet are being used. Not everyone is an ISP/Webhoster ... with public services.
I thought that was why we have RFC1918 ?
On 2/8/2011 7:25 AM, Sam Stickland wrote:
I've worked in plenty of places where registered address was used on private interconnections between organisations to avoid overlaps, but never announced globally. There's no such thing as "globally" anyway.
Your view of the Internet routing table != my view of the Internet routing table except in very limited circumstances. Matthew Kaufman
I wish people would actually read RFC 1918. Category 1: hosts that do not require access to hosts in other enterprises or the Internet at large; hosts within this category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 2: hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). For many hosts in this category an unrestricted external access (provided via IP connectivity) may be unnecessary and even undesirable for privacy/security reasons. Just like hosts within the first category, such hosts may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises. Category 3: hosts that need network layer access outside the enterprise (provided via IP connectivity); hosts in the last category require IP addresses that are globally unambiguous. RFC 1918 addresses for machines that fall in Categories 1 and 2. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, Feb 8, 2011 at 2:04 PM, Mark Andrews <marka@isc.org> wrote:
I wish people would actually read RFC 1918.
Category 1: hosts that do not require access to hosts in other enterprises or the Internet at large; hosts within this category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises.
Category 2: hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). For many hosts in this category an unrestricted external access (provided via IP connectivity) may be unnecessary and even undesirable for privacy/security reasons. Just like hosts within the first category, such hosts may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises.
Category 3: hosts that need network layer access outside the enterprise (provided via IP connectivity); hosts in the last category require IP addresses that are globally unambiguous.
RFC 1918 addresses for machines that fall in Categories 1 and 2.
You're assuming there that people followed the directions. That is demonstrably false. It's easy to say "Well, foo on them", but for those of us who provide services or consulting to those who failed to follow the directions, we still have to deal with it. -- -george william herbert george.herbert@gmail.com
On Tue, 08 Feb 2011 14:59:12 PST, George Herbert said:
It's easy to say "Well, foo on them", but for those of us who provide services or consulting to those who failed to follow the directions, we still have to deal with it.
Just remember that if they *had* followed the directions, your billable hours would drop...
On Tue, Feb 8, 2011 at 3:08 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 08 Feb 2011 14:59:12 PST, George Herbert said:
It's easy to say "Well, foo on them", but for those of us who provide services or consulting to those who failed to follow the directions, we still have to deal with it.
Just remember that if they *had* followed the directions, your billable hours would drop...
I had intended a snappy response including mention of ponies, however, while I was considering whether it was list-appropriate or not a coworker emailed me in response to this thread and reminded me of the mutual former client who grabbed 2/8 a few years ago and used it extensively internally. "Let's just grab 2/8, it's not routed on the Internet..." Whose actual perpetrator was allegedly another NANOGer, so it wasn't even brute ignorance (I am not sure it was them, so if not my apologies). In slight defense, this was to handle problems with extensive conflicts where this company and a number of telcos were having widespread 10/8 1918 space collisions and had no good solutions to it (apparently, the telcos failed to read 1918 closely enough and consider that any partner might ever need to route to their internal allocations). Thank you, anonymous coworker, for reminding me how glad I am that A) I'm not there at that client anymore, B) That it's turning that net off this year. *twitch* *twitch* -george -- -george william herbert george.herbert@gmail.com
From: George Herbert [mailto:george.herbert@gmail.com]
"Let's just grab 2/8, it's not routed on the Internet..."
+1 I was consulting for a financial services firm in the late '90s that was acquired by a large east-coast bank; the bank's brilliant scheme was to renumber all new acquisitions *out* of RFC1918 space and into (at the time) bogon space. If I recall, some of the arguments were "they were too big to fit into RFC1918 space" and by having all of their divisions in non-RFC1918 space it would make it easier for them to acquire new companies who used RFC1918 space internally. I wonder what they're doing now...
From: R. Benjamin Kessler <Ben.Kessler@zenetra.com>
From: George Herbert [mailto:george.herbert@gmail.com]
"Let's just grab 2/8, it's not routed on the Internet..."
+1
I was consulting for a financial services firm in the late '90s that was acquired by a large east-coast bank; the bank's brilliant scheme >was to renumber all new acquisitions *out* of RFC1918 space and into (at the time) bogon space.
If I recall, some of the arguments were "they were too big to fit into RFC1918 space" and by having all of their divisions in non->RFC1918 space it would make it easier for them to acquire new companies who used RFC1918 space internally.
I wonder what they're doing now...
<fireproof underwear = on> If we make the assumption that the hosts which were numbered in the space formerly known as bogon are typical enterprise hosts, it wouldn't be surprising if they were just fine: they probably don't *want* to have end-to-end connectivity, and are perfectly happy with the proxy-everything approach. If you're going to NAT everything anyway, then the damage done by having 2/8 on both sides of the NAT isn't any worse than having 10/8 on both sides of the NAT. If it turns out that they start running across the hosts in 2/8 as customers, those can get NATted into some third block, with probably a lot less effort and confusion than trying to sort out the chunks of overlapping 10/8s. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
On Tue, Feb 8, 2011 at 6:54 PM, David Barak <thegameiam@yahoo.com> wrote:
From: R. Benjamin Kessler <Ben.Kessler@zenetra.com>
From: George Herbert [mailto:george.herbert@gmail.com]
"Let's just grab 2/8, it's not routed on the Internet..."
+1
I was consulting for a financial services firm in the late '90s that was acquired by a large east-coast bank; the bank's brilliant scheme >was to renumber all new acquisitions *out* of RFC1918 space and into (at the time) bogon space.
If I recall, some of the arguments were "they were too big to fit into RFC1918 space" and by having all of their divisions in non->RFC1918 space it would make it easier for them to acquire new companies who used RFC1918 space internally.
I wonder what they're doing now...
<fireproof underwear = on>
If we make the assumption that the hosts which were numbered in the space formerly known as bogon are typical enterprise hosts, it wouldn't be surprising if they were just fine: they probably don't *want* to have end-to-end connectivity, and are perfectly happy with the proxy-everything approach.
If you're going to NAT everything anyway, then the damage done by having 2/8 on both sides of the NAT isn't any worse than having 10/8 on both sides of the NAT. If it turns out that they start running across the hosts in 2/8 as customers, those can get NATted into some third block, with probably a lot less effort and confusion than trying to sort out the chunks of overlapping 10/8s.
If you could really proxy everything, you'd be able to use 10/8 everywhere and never hit problems, even if two private peers overlap in usage within 10/8. I can assure you that the "proxy everything" statement breaks down with every enterprise-to-enterprise interconnection project I've run into. There are some protocols that are just not meant to do that. -- -george william herbert george.herbert@gmail.com
On 9 Feb 2011, at 02:43, "R. Benjamin Kessler" <Ben.Kessler@zenetra.com> wrote:
From: George Herbert [mailto:george.herbert@gmail.com]
"Let's just grab 2/8, it's not routed on the Internet..."
+1
I was consulting for a financial services firm in the late '90s that was acquired by a large east-coast bank; the bank's brilliant scheme was to renumber all new acquisitions *out* of RFC1918 space and into (at the time) bogon space.
If I recall, some of the arguments were "they were too big to fit into RFC1918 space" and by having all of their divisions in non-RFC1918 space it would make it easier for them to acquire new companies who used RFC1918 space internally.
You don't have to trawl back to the late 90's to find this, I know of at least 3 or 4 large enterprises using large chunks of public address (multiple /8's) that aren't their's /today/. This "works" because 1) the Internet is only accessed through proxies, 2) devices that require direct Internet access are addressed out of registered address space (or NATed to registered address space), and 3) third party connections to others enterprises are usually src/dst NATTed to the enterprise's own ranges (with the added benefit that this NAT at 3rd party boundaries helps ensure symmetric traffic flow through firewalls). And I've only worked at 3 or 4 large enterprises so it's probably safe to assume there's more! With my SP background I was shocked and I'm not trying to defend this practice, but in the enterprise land it seems accepted. Sam
On 2/9/11 4:35 AM, Sam Stickland wrote:
On 9 Feb 2011, at 02:43, "R. Benjamin Kessler" <Ben.Kessler@zenetra.com> wrote:
From: George Herbert [mailto:george.herbert@gmail.com]
"Let's just grab 2/8, it's not routed on the Internet..."
+1
I was consulting for a financial services firm in the late '90s that was acquired by a large east-coast bank; the bank's brilliant scheme was to renumber all new acquisitions *out* of RFC1918 space and into (at the time) bogon space.
If I recall, some of the arguments were "they were too big to fit into RFC1918 space" and by having all of their divisions in non-RFC1918 space it would make it easier for them to acquire new companies who used RFC1918 space internally.
You don't have to trawl back to the late 90's to find this, I know of at least 3 or 4 large enterprises using large chunks of public address (multiple /8's) that aren't their's /today/.
This "works" because 1) the Internet is only accessed through proxies, 2) devices that require direct Internet access are addressed out of registered address space (or NATed to registered address space), and 3) third party connections to others enterprises are usually src/dst NATTed to the enterprise's own ranges (with the added benefit that this NAT at 3rd party boundaries helps ensure symmetric traffic flow through firewalls).
sotime it works... if you are natted (from your public scoped but overlapping ipv4 address) but don't go through a proxy, or you go through a transparent proxy you may still be dead because the internal route covers you destination. Those aren't just enterprises either, some fairly common offenders are ISPs or wireless carriers and they did use just one or two additional /8s... joel
And I've only worked at 3 or 4 large enterprises so it's probably safe to assume there's more! With my SP background I was shocked and I'm not trying to defend this practice, but in the enterprise land it seems accepted.
Sam
On Feb 9, 2011, at 4:35 AM, Sam Stickland wrote:
On 9 Feb 2011, at 02:43, "R. Benjamin Kessler" <Ben.Kessler@zenetra.com> wrote:
From: George Herbert [mailto:george.herbert@gmail.com]
"Let's just grab 2/8, it's not routed on the Internet..."
+1
I was consulting for a financial services firm in the late '90s that was acquired by a large east-coast bank; the bank's brilliant scheme was to renumber all new acquisitions *out* of RFC1918 space and into (at the time) bogon space.
If I recall, some of the arguments were "they were too big to fit into RFC1918 space" and by having all of their divisions in non-RFC1918 space it would make it easier for them to acquire new companies who used RFC1918 space internally.
You don't have to trawl back to the late 90's to find this, I know of at least 3 or 4 large enterprises using large chunks of public address (multiple /8's) that aren't their's /today/.
This "works" because 1) the Internet is only accessed through proxies, 2) devices that require direct Internet access are addressed out of registered address space (or NATed to registered address space), and 3) third party connections to others enterprises are usually src/dst NATTed to the enterprise's own ranges (with the added benefit that this NAT at 3rd party boundaries helps ensure symmetric traffic flow through firewalls).
And I've only worked at 3 or 4 large enterprises so it's probably safe to assume there's more! With my SP background I was shocked and I'm not trying to defend this practice, but in the enterprise land it seems accepted.
Sam
On the freeways in the US, it's quite common for people to be doing 5-15 MPH over the speed limit. This practice seems accepted. I don't think there's a whole lot of sympathy, however, when someone receives a ticket for it. Owen
participants (11)
-
David Barak -
gb10hkzo-nanog＠yahoo.co.uk -
George Herbert -
Jared Mauch -
Joel Jaeggli -
Mark Andrews -
Matthew Kaufman -
Owen DeLong -
R. Benjamin Kessler -
Sam Stickland -
Valdis.Kletnieks＠vt.edu