Hi all, 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. --Jaren
On 3/18/2010 10:52, Jaren Angerbauer wrote:
Hi all,
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 think the correct term is "pirated addresses" or maybe "Hijacked addresses". RFC 1918 applies world wide. I don'r ever advocate any kind of antisocial behaviour. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
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. Cheers, Michael Holstein Cleveland State University
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. Hope that helps. Owen On Mar 18, 2010, at 8:52 AM, Jaren Angerbauer wrote:
Hi all,
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.
--Jaren
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? Thanks, Jaren
On 3/18/2010 11:22, Jaren Angerbauer wrote:
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?
See related traffic on this list, for openers. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
RFC1918 is a good place to start ;) On 3/18/2010 10:22 AM, Jaren Angerbauer wrote:
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?
Thanks,
Jaren
-- -------------------------------------------------------------------- Tom Ammon Network Engineer Office: 801.587.0976 Mobile: 801.674.9273 Center for High Performance Computing University of Utah http://www.chpc.utah.edu
On Thu, 18 Mar 2010 10:48:52 -0600 Tom Ammon <tom.ammon@utah.edu> wrote:
RFC1918 is a good place to start ;)
Most of the issues in "Deprecating Site Local Addresses" http://www.rfc-editor.org/rfc/rfc3879.txt identified in IPv6 Site-Local addressing also apply to duplicated/overlapping IPv4 addressing.
On 3/18/2010 10:22 AM, Jaren Angerbauer wrote:
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?
Thanks,
Jaren
-- -------------------------------------------------------------------- Tom Ammon Network Engineer Office: 801.587.0976 Mobile: 801.674.9273
Center for High Performance Computing University of Utah http://www.chpc.utah.edu
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
http://www.iana.org/assignments/ipv4-address-space/
Thanks,
Jaren
-- -------------------------------------------------------------------- Tom Ammon Network Engineer Office: 801.587.0976 Mobile: 801.674.9273
Center for High Performance Computing University of Utah http://www.chpc.utah.edu
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 ( http://www.iana.org/assignments/ipv4-address-space/ ), 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) There's also an RFC, RFC1918 that sets aside some IPv4 space for private, ad-hoc use. http://www.faqs.org/rfcs/rfc1918.html This is also a good lay reference: http://en.wikipedia.org/wiki/Private_network Have fun, jof
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. On Mar 18, 2010, at 8:52 AM, Jaren Angerbauer wrote:
Hi all,
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.
--Jaren
On Thu, Mar 18, 2010 at 09:34:47AM -0700, Fred Baker wrote:
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.
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.
On Mar 18, 2010, at 8:52 AM, Jaren Angerbauer wrote:
Hi all,
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.
--Jaren
-- --
On Mar 18, 2010, at 9:34 AM, Fred Baker wrote:
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. Owen
On Mar 18, 2010, at 8:52 AM, Jaren Angerbauer wrote:
Hi all,
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.
--Jaren
On Mar 18, 2010, at 2:25 PM, Owen DeLong wrote:
On Mar 18, 2010, at 9:34 AM, Fred Baker wrote:
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.
Does anyone know if the University of Michigan or Cisco are going be updating their systems and documentation to no longer use 1.2.3.4 ? http://www.google.com/search?q=1.2.3.4+site%3Acisco.com 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. - Jared
On 3/18/10 2:35 PM, Jared Mauch wrote:
Does anyone know if the University of Michigan or Cisco are going be updating their systems and documentation to no longer use 1.2.3.4 ?
http://www.google.com/search?q=1.2.3.4+site%3Acisco.com
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. Should we try again, jointly? ;-)
On 3/18/2010 14:30, William Allen Simpson wrote:
On 3/18/10 2:35 PM, Jared Mauch wrote:
Does anyone know if the University of Michigan or Cisco are going be updating their systems and documentation to no longer use 1.2.3.4 ?
http://www.google.com/search?q=1.2.3.4+site%3Acisco.com
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 declined. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.) Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
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. On Fri, Mar 19, 2010 at 6:41 AM, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 3/18/10 2:35 PM, Jared Mauch wrote:
Does anyone know if the University of Michigan or Cisco are going be updating their systems and documentation to no longer use 1.2.3.4 ?
http://www.google.com/search?q=1.2.3.4+site%3Acisco.com
I know that the University of Michigan utilize 1.2.3.4 for their captive
On 3/18/2010 14:30, William Allen Simpson wrote: 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 declined. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.)
Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca
ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
I love war stories. I once got chewed out by a colleague <?> from another organization because we were using "their" address space. We were using 10.0.0.0/8. Explanation of NAT and RFC1918 was met with a deer in the headlights look. On Fri, Mar 19, 2010 at 12:04 AM, Matt Shadbolt <matt.shadbolt@gmail.com> wrote:
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.
On Fri, Mar 19, 2010 at 6:41 AM, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 3/18/10 2:35 PM, Jared Mauch wrote:
Does anyone know if the University of Michigan or Cisco are going be updating their systems and documentation to no longer use 1.2.3.4 ?
http://www.google.com/search?q=1.2.3.4+site%3Acisco.com
I know that the University of Michigan utilize 1.2.3.4 for their captive
On 3/18/2010 14:30, William Allen Simpson wrote: 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 declined. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.)
Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca
ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
-- ===================================== Charles L. Mills Westmoreland Co. ARES EC Amateur Radio Callsign W3YNI Email: w3yni1@gmail.com
Chuck - Very true... What about the time our old manager (MARTIN) gave your old organization that Entire Class B !!!! On Fri, Mar 19, 2010 at 11:06 AM, Charles Mills <w3yni1@gmail.com> wrote:
I love war stories. I once got chewed out by a colleague <?> from another organization because we were using "their" address space.
We were using 10.0.0.0/8. Explanation of NAT and RFC1918 was met with a deer in the headlights look.
I once had a customer who for some reason had all their printers on
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.
On Fri, Mar 19, 2010 at 6:41 AM, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 3/18/10 2:35 PM, Jared Mauch wrote:
Does anyone know if the University of Michigan or Cisco are going be updating their systems and documentation to no longer use 1.2.3.4 ?
http://www.google.com/search?q=1.2.3.4+site%3Acisco.com
I know that the University of Michigan utilize 1.2.3.4 for their captive
On 3/18/2010 14:30, William Allen Simpson wrote: 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
On Fri, Mar 19, 2010 at 12:04 AM, Matt Shadbolt <matt.shadbolt@gmail.com> wrote: public 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 declined. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.)
Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca
ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
-- ===================================== Charles L. Mills Westmoreland Co. ARES EC Amateur Radio Callsign W3YNI Email: w3yni1@gmail.com
-----Original Message----- From: Charles Mills [mailto:w3yni1@gmail.com] Sent: Friday, March 19, 2010 10:06 AM To: Matt Shadbolt Cc: nanog@nanog.org Subject: Re: Using private APNIC range in US
I love war stories. I once got chewed out by a colleague <?> from another organization because we were using "their" address space.
We were using 10.0.0.0/8. Explanation of NAT and RFC1918 was met with a deer in the headlights look.
On Fri, Mar 19, 2010 at 12:04 AM, Matt Shadbolt <matt.shadbolt@gmail.com> wrote:
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.
Was troubleshooting a customer's vpn trouble a few years ago at another ISP. Could connect from outside our ISP, but users of our service sometimes could and sometimes couldn't connect.
Turns out the Master Network Manager (that's what he called himself) had looked at the static IP assignment, and extrapolated back the whole /22 they were on and used it for the inside of his NAT router. When people hit that part of our network pool, they could make the initial connection but then the poor firewall would have a nervous breakdown and not pass traffic right (I don't blame it). My solution: Renumber to a reserved private block internally. He had about 200 devices with static assigned dhcp on about 10 of them. His solution: Every company user that gets access through our service had to get some form of other service in order to connect to his network by vpn since we 'don't know what we're doing with network configuration'. 35 people either switched away from us or got a second (usually dial up) connection for when they wanted to vpn in. I believe his core mantra was that the private 1918's were 'not secure' for some reason he couldn't articulate to me. This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.
On 19/03/2010 06:04, Matt Shadbolt wrote:
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 :)
I have seen quite a number of organisations using /24s that they have pirated from various places. Worst culprits seem to be small access providers who change upstream providers and are too lazy to renumber their corporated network away from the IPs that have been reclaimed. They stick in a NAT and then ignore the problem for a few years. One particular company insisted that their pirate IP block be routable within the shiny new core network causing endless headaches making sure it doesn't leak into their BGP. Another ISP is even using oops-I-thought-that-was-RFC1918-addresses in the vicinity of 172.50.x.x and pirate space from 6.7.8.x for their point to point links.
They didn't mind though. No idea if they've changed it since.
On Fri, Mar 19, 2010 at 6:41 AM, Larry Sheldon<LarrySheldon@cox.net> wrote:
On 3/18/10 2:35 PM, Jared Mauch wrote:
Does anyone know if the University of Michigan or Cisco are going be updating their systems and documentation to no longer use 1.2.3.4 ?
http://www.google.com/search?q=1.2.3.4+site%3Acisco.com
I know that the University of Michigan utilize 1.2.3.4 for their captive
On 3/18/2010 14:30, William Allen Simpson wrote: 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 declined. -- Democracy: Three wolves and a sheep voting on the dinner menu. (A republic, using parliamentary law, protects the minority.)
Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca
ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
-- Graham Beneke
On 2010-03-18 19:35, Jared Mauch wrote:
http://www.google.com/search?q=1.2.3.4+site%3Acisco.com 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.
A lot of cheap, low-end devices (sometimes with names of well-know vendors) use IPs like 1.1.1.1 and 1.2.3.4 as captive portal IPs to authenticate connecting clients. A lot of "WLAN hotspots" users will have problems reaching 1/8 unless they connect via VPN to corporate and browse from there or something like that. The question is how soon 1/8 will have interesting content to serve, as I know at least one popular hotel chain in Europe using "1.1.1.1". -- "Everything will be okay in the end. | Łukasz Bromirski If it's not okay, it's not the end." | http://lukasz.bromirski.net
On Mar 18, 2010, at 2:25 PM, Owen DeLong wrote:
On Mar 18, 2010, at 9:34 AM, Fred Baker wrote:
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.
Owen
On Mar 18, 2010, at 8:52 AM, Jaren Angerbauer wrote:
Hi all,
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.
--Jaren
On Thu, 2010-03-18 at 14:50 -0400, Daniel Senie wrote:
As you note, debugging this type of thing is often not intuitive, as everything appears to work from almost everywhere
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. Gord -- rockin ze chair mit Davey Graham to Banshee from rackserver-2
On Fri, 2010-03-19 at 06:08 +0000, gordon b slater wrote:
It looks like chaos-squared out there. I don't envy anyone fathoming that stuff out for real.
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, Gord -- sig nal generator
On 3/18/10 8:52 AM, Jaren Angerbauer wrote:
Hi all,
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.
Actually, those are public IPs. The 1/8 block is presently undergoing testing for use as a public network. Private IPs are defined in RFC1918 and don't "belong" to a regional registry.
I'm assuming that the addresses probably nat to a [US] public IP.
If their webservers are located in North America and visible from the Internet, that is probably a valid assumption. "nslookup", "host" or "dig" on the hostname should give you a more definitive answer.
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.
For some value of "working", that may be accurate today. It is also going to be true for some values of "broken", if not now then in the future. Private address space is not part of ARIN, APNIC, etc. It is global and defined by RFC1918.
I'm just wondering if there is any recommendation or practice around this -- using private IP ranges from another country. Thanks.
There is no such thing as a "private IP range from a country". Private addresses are global. The recommendation and practice is to use addresses from RFC1918 for private addresses. If these resources need to be visible from the Internet, then NAT to public addresses assigned or allocated to the operator of the system will be needed. Your client should renumber his private addresses to a netblock that is defined in RC1918 such as 10/8, 172.16/12, or 192.168/16 -- -- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
participants (21)
-
Charles Mills -
Cian Brennan -
Craig Vuljanic -
Daniel Senie -
Eric J Esslinger -
Fred Baker -
gordon b slater -
Graham Beneke -
Jared Mauch -
Jaren Angerbauer -
Jay Hennigan -
Joel Jaeggli -
Jonathan Lassoff -
Larry Sheldon -
Mark Smith -
Matt Shadbolt -
Michael Holstein -
Owen DeLong -
Tom Ammon -
William Allen Simpson -
Łukasz Bromirski