Hacker News Reader

Comment by akw28888 | Hacker News Reader

I'm using AnchNet's services. And We've asked AnchNet when I recieved a e-mail from our BGPMon. They said their staff was configured a wrong config on router. Also they don't know 1.1.1.0/24 is used by CloudFlare&APNIC. So they used this prefix to test.

View on HN

Why let people access BGP that don't even know that 1.0.0.0/8 or 1.1.1.0/24 are part of the public internet or that decide they can use random prefixes to "test" things? :-/

In fact, they usually use 172.10.x.x on their PtP address...

That isn't a reserved/private network either.

I shake my head in bewilderment when I see stuff like this - just why would people make things harder for themselves. I very highly doubt that they are so large that they ran out of IP space in the enormity of 172.16/12 to encompass all of their OSPF/BGP router-id /32s and individual /30 OSPF router-to-router links.

> enormity

What's enormous about an IPv4 /12? :)

When the German army requested an allocation of IPv6 address space, they were given a /28, but complained that 2^100 IPs is not enough for them and they actually need a /22.

Well it's not so enormous, but it's also accompanied by 10/8 and 192.168/16. Many networks use some combination of all three internally for different purposes.

Thats mind boggling... I'd like to read that reasoning about that! (I'm sure there's some German-language publication somewhere...)

Did they want each bullet to have a /64?

I have both a /29 and a /32 of v6 space, and unless my ASN achieves total global domination on a scale never before seen by humankind, it should last a good long time. :-)

Well, bullets might move between routers, so they might change the Layer-2 network they are on, and thus might need their own independently routable address. Afaik it is bad practice to route anything smaller than a /64.

Why give them the option to shoot themselves and neighbors foot? Seems more like a technology problem with BGP then knowledge problem.

Usually upstream ISP providing transit accepts only a valid set of prefixes that they have agreed to advertise on the public internet from an ISP customer, they enforce a policy on the ingress to make this happen. Idea being, if the customer ISP ends up advertising an incorrect prefix, then the impact is only localised to his ISP and not to the whole world. But some ISPs don't follow this and implicitly trust the customer ISPs and of course there is no cover if the tier1 ISP itself typo's a prefix. There are tools such as BGP RPKI available, but its not widely deployed.

>Usually

If only...

BCP 38[0] is nowhere near usual. Lots of networks, including some very problematic big ones (cough Hurricane Electric cough), do not implement it as a matter of course. The AWS Route53 hijack last month which resulted in downtime for a number of sites plus a six figure coin theft[1] could have been prevented by adequate filtering.

0: https://tools.ietf.org/html/bcp38

1: https://arstechnica.com/information-technology/2018/04/suspi...

Could one argue for tort/negligence against the ISP who should have filtered, but didn't, if one's coins were stolen through that? Or even possibly the same, but in criminal court?

Just as with the discussion about hackable routers yesterday, there are no laws for this.

I doubt it, since the argument you're suggesting is that the ISP didn't take the best possible care, whereas the standard for negligence is, I believe (IANAL), reasonable care.

They may also not even have a duty of care in the first place, as to the truth of any metadata they're passing on. As a sibling comment pointed out, it's not as if there are laws for this.

Uhm, BCP38 is about forwarding, not the BGP control plane

I'm not sure when modern tech got this idea that if everyone has been using something "wrong" for decades, it's still wrong. That space has never been previously announced, it's assigned to APNIC for _research_, it's in dozens of makes and models of router as admin interfaces, blackholed or otherwise.

I get the impulse to say "you used it wrong, now it's broken", but we didn't get to a functioning worldwide internet with that attitude. We got here by observing what people were actually doing and coming to a consensus view on what to break and what to carefully tread around (you know, UX). This is an obvious example of the latter and the fact that APNIC let CF use this space for a production platform in the name of breaking shit is frankly disqualifying (in terms of their overall trustworthiness as curators of essential IN infrastructure).

I don't disagree with you that things have coalesced by consensus over a period of the past 25 years, for what IP space people should and can use, and what IP space you shouldn't use (eg: I have no doubt that a bunch of enterprise end users are using some of the US military/DoD assigned /8s internally, because those never show up on the global internet. It's wrong, but they do it anyways).

However, the RFC1918 IP ranges have existed for a very, very long time, as have the standard documentation/example IP ranges which Cisco, Juniper and others have been using in their training and example publications since 1995 or so. People have had more than twenty years to number their internal networks into the ranges that, also by consensus, the global internet community has decided to make non-globally-routable (192.168, 10.x, 172.16, etc). RFC1918 was published 22 years ago so there is really no excuse.

If you are using 1/8 in the year 2018 for your own internal production traffic, you are wrong and should feel bad. IANA and APNIC (and APNIC's contracted partner, Cloudflare) should be able to begin using ranges as granular as an individual /24 within this /8 on the public Internet without worrying that people who have misconfigured their shit will have a broken experience. It will take time for people to move their misconfigured erroneous configurations into normal RFC1918 IP space, but it will happen eventually. Or maybe not, if v6 adoption speeds up this becomes irrelevant.

> v6 adoption

Good one.

To be fair 1.1.1.1 had been unassigned/non-routable up until April.

It was assigned to APNIC in 2010 http://seclists.org/nanog/2010/Jan/776

Allocated, not assigned.

What is the practical difference?

It didn’t do the bad thing until after it was assigned, so no one cared when it was allocated.

I was curious as well and found this:

https://serverfault.com/questions/191497/ip-addresses-assign...

From RIPE, "An allocation is the block of IP addresses that is reserved by the RIPE NCC for your use now and in the future. An assignment is a block of IP addresses from your allocation that is used on an active network."

https://www.ripe.net/manage-ips-and-asns/resource-management...

APNIC used that terminology in their analysis paper of 1.0.0.0/8, "1.0.0.0/8 has been assigned by IANA to APNIC on the 19th January 2010" [1]. To do this analysis, wouldn't they have had to advertise a route back in 2010?

[1] http://www.potaroo.net/studies/1slash8/1slash8.html

To be fair, unallocated or unassigned IP space isn't fair game to use for testing outside of an air gapped lab. I've never in my career thought it would be a good idea to "test" unallocated public unicast address space on my edge routers.

  On an airgapped lab it is bad practice. Same -though DNS related- with using *.local as a LAN TLD

We just should not.

.local is perfectly fine according to the IETF https://tools.ietf.org/html/rfc6762

As you linked, it is reserved for mDNS.

For mDNS, yes. There are resolvers that don't even try DNS when looking up a name in .local.

Some of them were made more lenient because just as Microsoft finally stopped encouraging this nonsense, the Kubernetes people picked it up from ancient Windows Server folklore and apparently decided to make it web-scale.

There are instances where completely replicating an environment in an air gapped lab is acceptable. For instance, you could be encountering some edge case where a bit is being flipped in an IP address, or a bit is stuck on somewhere and replicating the environment down to the individual IP addresses plays a huge part in reproducing the issue.

An edge router is not one of these cases though.

I've worked in two shops that used 1/8 space for loopback addresses for iBGP and nobody that worked there was a dummy.

It is/was not uncommon either[1]. It was never a concern since it wasn't allocated. It being a concern is a very recent phenomenon.

[1] https://www.cisco.com/c/en/us/about/press/internet-protocol-...

I'm going to say "yes they were dummies", what made them think that they were going to run out of space in 172.16/12 for router ID /32 loopbacks? If there are properly defined private IP space blocks, use those, not some random /8 you think looks nice.

>"If there are properly defined private IP space blocks, use those, not some random /8 you think looks nice."

Yeah, no. It sounds like you don't really know the history of that block. Or maybe you missed the part where I said it was used as a loopback address. Maybe both.

1.0.0.0/8 was unallocated and was also part of many peoples bogon filters at their edges.

I do know the history of that block, and have been subscribed to the relevant mail lists for bogon filters since 1998. It has never been a good idea to start using a currently unallocated /8 for internal purposes, when plenty of rfc1918 space exists. 1/8 is not the first block to ever be taken out of the bogons list and actually used. Some of the "newer" /8s that were in the last few handed out to the RIRs also had reachability issues when arin, ripe and APNIC started giving out /14 to /22 sized pieces of space to ISPs, because a number of people out there had stale bogon filters handcoded into their routers. It is mostly fixed now.

It could also be an ISP leaking a loopback identifier into their routes. A lot of ISP's will give their BGP routers lo0 interfaces named things like 1.1.1.1 and 2.2.2.2. It serves as a label and not as an address.

It's been a while, but I can't count the number of times that I've seen that.

If that were the case, they would have been advertising a /32 (which, hopefully, would have been dropped -- or, the least, not redistributed) instead of a /24.

It shouldn't really matter who is currently using that net, it's not a private range :/

Tell Cisco.

Both Cisco and Juniper use the standardized documentation IP ranges in their example/lab configurations and training materials.

https://tools.ietf.org/html/rfc5735

https://tools.ietf.org/html/rfc5737

Cisco did recommend to use 1.1.1.1 (or did default to? commentary online is unclear), but in a different space: for the DHCP server with DHCP proxying in their WLAN products. They might be referring to that.

I have been going through Cisco Netacad materials for last 2 years and I've seen 1.1.1.1 in examples. Though I just did a search and did not see 1.1.1.1 mentioned anymore.

Reply on news.ycombinator.com