I have a client here in the US, that I just discovered is using a host
of private IPs that (as I understand) belong to APNIC (i.e.
1.7.154.70, 1.7.154.00-99, etc.) for their web servers. I'm assuming
that the addresses probably nat to a [US] public IP. I'm not familiar
enough with the use of private address space outside of ARIN (i.e.
192.0.0.0, 10.0.0.0, etc) but I figure if their sites are up and
accessible it must be working for them. I'm just wondering if there
is any recommendation or practice around this -- using private IP
ranges from another country. Thanks.
I have a client here in the US, that I just discovered is using a host
of private IPs that (as I understand) belong to APNIC (i.e.
1.7.154.70, 1.7.154.00-99, etc.) for their web servers.
Those aren't "private" IPs .. (in the RFC1918 sense) .. those are public
IPs. They just weren't assigned until recently.
accessible it must be working for them. I'm just wondering if there
is any recommendation or practice around this -- using private IP
ranges from another country. Thanks.
Since they're already using NAT, it shouldn't be hard to renumber them
into the appropriate RFC1918 space.
1.0.0.0/8 is NOT private address space and never was.
It was an arbitrary mis-use by your customer of space which is now
part of the APNIC pool of addresses to issue in response to requests
for new globally unique addresses.
The result for your customer is that they've gotten away with treating
it like RFC-1918 space (10/8, 172.16/12, 192.168/16) so far because
there was no legitimate external use of that address.
RFC-1918 in ARIN is the same as everywhere else. There is no region-
specific aspect of it.
What will happen if your customer does not renumber out of 1/8 is that
there will be a portion of the internet rightfully using 1/8 that will be
unreachable from your customer's internal systems and any requests
to those legitimate hosts in 1/8 will be erroneously routed within your
customer's premises. There are other possible issues if your cusotmer
leaks DNS entries containing A records pointed towards 1/8 hosts
as well.
Thanks all for the on / off list responses on this. I acknowledge I'm
playing in territory I'm not familiar with, and was a bad idea to jump
to the conclusion that this range was private. I made that assumption
originally because the entire /8 was owned by APNIC, and just figured
since the registrar owned them, it must have been a private range. :S
It sounds like this range was just recently assigned -- is there any
document (RFC?) or source I could look through to learn more about
this, and/or provide evidence to my client?
Are they using them only within their domain(s), and ARIN addresses outside, or are they advertising them to their upstream(s) to be readvertised into the backbone?
If they are using them internally and NAT'ing to the outside, they're not hurting themselves or anyone else. I would personally let them alone.
If they are advertising them outside, it adds a small prefix in the ARIN domain that doesn't get aggregated by the upstream. Among 300K such prefixes it is probably noise, but gently suggesting that they use something aggregatable into their upstream's allocation would help a little bit in that regard. What they are most likely hurting is themselves, really; a datagram sent to the address from an ISP outside themselves probably travels via Australia or an Australian ISP.
Are they using them only within their domain(s), and ARIN addresses outside, or are they advertising them to their upstream(s) to be readvertised into the backbone?
If they are using them internally and NAT'ing to the outside, they're not hurting themselves or anyone else. I would personally let them alone.
Right up until someone actually starts *using* 1/8, in which case they're
hurting both themslves, and who ever gets stuck with it.
Excerpts from Jaren Angerbauer's message of Thu Mar 18 09:22:40 -0700 2010:
Thanks all for the on / off list responses on this. I acknowledge I'm
playing in territory I'm not familiar with, and was a bad idea to jump
to the conclusion that this range was private. I made that assumption
originally because the entire /8 was owned by APNIC, and just figured
since the registrar owned them, it must have been a private range. :S
It sounds like this range was just recently assigned -- is there any
document (RFC?) or source I could look through to learn more about
this, and/or provide evidence to my client?
There's a couple of relevant documents you could refer them to:
IANA's IPv4 Address Space Registry ( IANA IPv4 Address Space Registry ),
which will show you a listing of which registries and various entities
are assigned /8 chunks of IPv4 space.
There's some interesting names and historical registrations in there
(including 1.0.0.0/8's recent allocation to APNIC)
Are they using them only within their domain(s), and ARIN addresses outside, or are they advertising them to their upstream(s) to be readvertised into the backbone?
If they are using them internally and NAT'ing to the outside, they're not hurting themselves or anyone else. I would personally let them alone.
Except you're missing a keyword on the "not hurting themselves" part of that... It's "YET".
Once 1.0.0.0/8 starts getting used in the wild for legitimate sites, it means that this
customer won't be able to reach the legitimate 1.0.0.0/8 sites from within their
environment and it won't be immediately intuitive to debug the failures.
If they are advertising them outside, it adds a small prefix in the ARIN domain that doesn't get aggregated by the upstream. Among 300K such prefixes it is probably noise, but gently suggesting that they use something aggregatable into their upstream's allocation would help a little bit in that regard. What they are most likely hurting is themselves, really; a datagram sent to the address from an ISP outside themselves probably travels via Australia or an Australian ISP.
The route announcement notwithstanding, they're using space that does not
belong to them and will belong to someone else in the near future. If you
think that is OK, please let me know what your addresses are so that I can
start re-using them.
I know that the University of Michigan utilize 1.2.3.4 for their captive portal login/logout pages as recently as monday when I was on the medical campus.
Are they using them only within their domain(s), and ARIN addresses outside, or are they advertising them to their upstream(s) to be readvertised into the backbone?
If they are using them internally and NAT'ing to the outside, they're not hurting themselves or anyone else. I would personally let them alone.
Except you're missing a keyword on the "not hurting themselves" part of that... It's "YET".
Once 1.0.0.0/8 starts getting used in the wild for legitimate sites, it means that this
customer won't be able to reach the legitimate 1.0.0.0/8 sites from within their
environment and it won't be immediately intuitive to debug the failures.
While the analysis above is correct, the original poster talked about the 1/8 addressing being used on web server farms with translation of incoming connections. Sounds like load balancers using 1/8 for the addresses behind them and on the servers that are providing the service.
As such, prospective users of the web site(s) provided by the outfit will not function for broadband users and such who get allocated addresses from 1/8.
Reality of course is that both are true, but in terms of "who gets hurt" the issue here may well be a large server farm that is inaccessible from consumer networks in places in Asia.
As you note, debugging this type of thing is often not intuitive, as everything appears to work from almost everywhere.
If they are advertising them outside, it adds a small prefix in the ARIN domain that doesn't get aggregated by the upstream. Among 300K such prefixes it is probably noise, but gently suggesting that they use something aggregatable into their upstream's allocation would help a little bit in that regard. What they are most likely hurting is themselves, really; a datagram sent to the address from an ISP outside themselves probably travels via Australia or an Australian ISP.
The route announcement notwithstanding, they're using space that does not
belong to them and will belong to someone else in the near future. If you
think that is OK, please let me know what your addresses are so that I can
start re-using them.
A scenario repeated many times over the years. In the 1990s, it was common to see leakage of the address blocks of vendors that were used in documentation for routers, workstations, etc., as people would look at examples in the manual, and use the exact IP addresses shown, not understanding the "go get your own addresses first" part of the process.
med.umich.edu seems to run their own stuff, separately from umich.edu, and
quite badly. I've complained about their setup repeatedly over the past
several years. No traction.
I know that the University of Michigan utilize 1.2.3.4 for their captive portal login/logout pages as recently as monday when I was on the medical campus.
Dunno about cisco.
med.umich.edu seems to run their own stuff, separately from umich.edu, and
quite badly. I've complained about their setup repeatedly over the past
several years. No traction.
Is it something about Medical Schools?
When we were first putting together the campus network, Surgery was
running a Token Ring (I thought "Vampire Tap" was a fitting item for
their inventory) running in Class D space as I recall.
Should we try again, jointly?
Towards the end, there were people who insisted I must rout their net to
the Internets.
I once had a customer who for some reason had all their printers on public
addresses they didn't own. Not advertising them outside, but internally
whenever a user browsed to a external site that happened to be one of the
addresses used, they would just receive a HP or Konica login page
They didn't mind though. No idea if they've changed it since.
I got curious yesterday and set off a couple (very slow {option -T0},
very polite, very restrictive) nmap single port scans of a few lumps of
1.0.0.0/22 yesterday, but couldn't see much out there due to my several
of our ISPs internal boxes.
It looks like chaos-squared out there. I don't envy anyone fathoming
that stuff out for real.
Still, that said, the transition to fully signed roots seems to be going
along without too much breakage (I think/hope!) so maybe only time will
tell how much this latest block release will give trouble longterm.
clarification: `chaos` due to our ISP running internal boxes on the
range in question, rather than external chaos.
The implication being: if it's looping around inside the customers ISP
then there's not much hope of easy troubleshooting,
