Apologies for duplicates]
Dear Colleagues,
Please note that AfriNIC received the IPv4 address range 41.0.0.0/8 from
the IANA in April 2005.
You may wish to adjust any filters you have in place accordingly.
Reachability tests can be conducted with 41.223.252.1 as a target IP
address.
Kind Regards,
Ernest,
AfriNIC.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well, there was an update on this topic on the AfNOG list. I thought nanog list should find this interesting.
This thread has been dead for awhile now but it never was really solved.
Turns out the folks at fastweb (Italy) NAT there adsl clients but
instead of using the rfc1918 space like most people, they use unassigned
global /8s. Well 41/8 is one of there NATted allocations for Turin. No
amount of emails will get them to respond, calling isn't any better as I
get only Italian speaking people at the other end. Any ideas out there?
- -end quote from afnog mailing list ---
thanks
yup see my followup to nanog earlier today
-srs
This came in from someone in Italy..
From: *****
so how many ISPs will shun fastweb for hijacking address space?
(please do -NOT- respond, its a retorical question...)
--bill
Well, the noise helped some. We now have connectivity to fastweb net.
[...]
>Turns out the folks at fastweb (Italy) NAT there adsl clients but
>instead of using the rfc1918 space like most people, they use
>unassigned
>global /8s. Well 41/8 is one of there NATted allocations for Turin. No
>amount of emails will get them to respond, calling isn't any better
>as I
>get only Italian speaking people at the other end. Any ideas out
>there?Yes: you lose, sorry.
Many of their networking people are less than clueful, and I fear that
they are not going to renumber a whole city just to let their customers
communicate with a few African networks...
One of the points of NAT is to make renumbering easy. Silly them.
I have a rule: Your network, your rules. If they want to be disconnected from Africa, you can't stop them. And they are not "hijacking" the /8, it is not announced on the 'Net. This is identical to a null route inside their ASN. I would never dream of telling them they cannot decide which netblocks should be routeable inside their own ASN.
Fortunately, I have another rule: My network, my rules. If someone can find the real addresses for FastWeb uses for the NAT pool and post it here (and other *NOG lists), networks can ensure that FastWeb's end users will be unable to communicate with a lot more than "a few African networks". I think the show of solidarity would be good for the 'Net.
How was that achieved if their users still are within 41/8 locally?
william(at)elan.net wrote:
Well, the noise helped some. We now have connectivity to fastweb net.
How was that achieved if their users still are within 41/8 locally?
Can't be sure what they did, but I received an e-mail asking me to check on my connectivity to them and well, it worked. From e-mails received, turns out they have known about this for awhile now but just didn't want to foot the cost of re-numbering. They claim they the clean up work is on-going.
well they're not really hijacking it - as in they are not announcing it or affecting unrelated networks on the internet
its no different than a private firewall/security policy, except we know they're doing it because they're broken not because they intend to be denying connectivity to those networks.
Steve
Presumably they're double-natting. I had to do that once for Y2K
compliance for three large governmental networks that were all statically
addressed in net-10 and wouldn't/couldn't renumber in time. In fact,
there were _specific hosts_ which had the same IP address, and _had to
talk to each other_. Gross. But it can be done.
-Bill
Please explain how. I simply can't imagine my computer communicating
with another one with exactly same ip address - the packet would never
leave it. The only way I see to achieve this is to have dns resolver
on the fly convert remote addresses from same network into some other
network and then NAT from those other addresses.
Split-horizon DNS, external to the clients, but basically, yes. Like I
said, horrifically gross.
-Bill
> > Can't be sure what they did, but I received an e-mail asking me to
> check
> > on my connectivity to them and well, it worked.
>
>Presumably they're double-natting. I had to do that once for Y2K
>compliance for three large governmental networks that were all statically
>addressed in net-10 and wouldn't/couldn't renumber in time. In fact,
>there were _specific hosts_ which had the same IP address, and _had to
>talk to each other_. Gross. But it can be done.Please explain how. I simply can't imagine my computer communicating
with another one with exactly same ip address - the packet would never
leave it. The only way I see to achieve this is to have dns resolver
on the fly convert remote addresses from same network into some other
network and then NAT from those other addresses.
Here's how with dual proxies. Presumably dual NATs use multiple IPs
from different parts of the intermediary network.
proxy1----------------+ +-----------------proxy2
>.1 |.1 |.2 |.1
======= 10.0.0.0/24 ======= x.y.z.0/24 ======= 10.0.0.0/24
>.15 |.15
host server
If you are using a good mail reader, the above ASCII art will come
through unscathed. If it does not come through unscathed, you are not
using a good mail reader. 
net1: 10.0.0.0/24
host = 10.0.0.15
proxy1 = 10.0.0.1
net2: x.y.z.0/24 (NOT 10.0.0.0)
proxy1 = x.y.z.1
proxy2 = x.y.z.2
net3: 10.0.0.0/24 [it used to belong to the guy down the block but i
bought it at a garage sale and had to merge the two
networks]
proxy2 = 10.0.0.1
server = 10.0.0.15
Host has proxy set to 10.0.0.1. Rather than resolving "server", it
sends a Web query for "http://server" to 10.0.0.1. Proxy1 gets it. It
has been told that "server" is on the other side of proxy2. Rather than
resolving "server", it forwards the Web query for "http://server" to
proxy2, at x.y.z.2. Proxy2 breaks this query down, resolves "server"
using _local_ DNS to 10.0.0.15. Sends the query to server, receives the
response. Passes the response back to proxy1, which passes it back to
host.
Capisci?
Thus spake "william(at)elan.net" <william@elan.net>
Presumably they're double-natting. I had to do that once for Y2K
compliance for three large governmental networks that were all statically
addressed in net-10 and wouldn't/couldn't renumber in time. In fact,
there were _specific hosts_ which had the same IP address, and _had to
talk to each other_. Gross. But it can be done.Please explain how. I simply can't imagine my computer communicating
with another one with exactly same ip address - the packet would never
leave it. The only way I see to achieve this is to have dns resolver
on the fly convert remote addresses from same network into some other
network and then NAT from those other addresses.
Unfortunately, I've done this several times, most notably within one company that had multiple instances of 10/8 that needed to talk to each other. A decent (if one can use that term) NAT device will translate the addresses in DNS responses, so two hosts that both live at 10.1.2.3 will see the other's address as, for example, 192.168.1.2, both in DNS and in the IP headers.
It's extremely ugly, but that's what one gets for using private address space. This exact scenario was a large part of why I supported ULAs for IPv6.
S
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
[...]
It's extremely ugly, but that's what one gets for using private address
space. This exact scenario was a large part of why I supported ULAs for
IPv6.
I can sort of see the point in ULAs, although if you want a globally unique
address, why not just use a public address? Anyway, the problem is that
nobody actually seems to have bothered to read RFC1918 and/or realise the
possibility of collision:
If two (or more) organizations follow the address allocation
specified in this document and then later wish to establish IP
connectivity with each other, then there is a risk that address
uniqueness would be violated. To minimize the risk it is strongly
recommended that an organization using private IP addresses choose
randomly from the reserved pool of private addresses, when allocating
sub-blocks for its internal allocation.
I tend to pick out random /24s from 172.16/12 when I need private addresses.
Virtually nobody uses those, which makes them most suitable.
I can sort of see the point in ULAs, although if you want a globally unique
address, why not just use a public address?
Maybe you don't *want* a public address. In fact, I *know* sometimes you
don't want one - because you *tell* us you don't:
I tend to pick out random /24s from 172.16/12 when I need private addresses.
Virtually nobody uses those, which makes them most suitable.
Sounds to me like you've just re-invented the ULA for IPv4. This same
usage case (plus the collision issue you mentioned) are *exactly* why ULA's
were pushed...
