Most of NIMBY legislature and processes that block private construction also block public construction. So most YIMBY arguments to improve the situation apply to both public and private constructions. (Not to mention that public construction has a plenty of problems specific to it.)
Back around 1993-94 was a genuine gold rush in terms of domain names and network numbers.
My supervisor one day rushed into the bullpen and proclaimed that he had registered SEX.ORG, and presumably the only reason was to squat it awhile and then resell it for thousands. [Squatting and speculation were, in fact, quite legal and wise moves at that point in history, especially with a high-demand 6-character site!]
Personally, I discovered the registration process and forms for domain names and network numbers were fairly straightforward. I had seen a Usenet post where someone explained that you just had to write a description of your company, its structure and annual meetings, finances, etc. So I completely made up a fictional company and described those things in my application.
Hey presto, I was now the "owner" and "admin" of cthulhu.com and a corresponding 192.0.0.0/3 Class-C network. Now my coworkers at the ISP were savvy enough to arrange for the DNS servers to answer for their vanity domains. But having no appreciable homelab, or BGP peering of my own, my DNS domain and Class-C Network both languished, until ultimately they were reclaimed in a sweep of unused space by IANA and InterNIC.
I have been unable to recall the exact numbers or find them in a search, but I know that its moniker was related, such as "CTHULHU-NET" or something.
I went on to legitimately register under the .ca.us domain on behalf of my home network and my roommates. cthulhu.com has long been handed over to someone who uses it.
I had named it "HEARTLAND" rather than a Cthulhu-related name, which was hindering my searches. I had also asked Gemini and it hallucinated a historical record which it was unable/unwilling to link.
My original assigned user handle was: RE229 (a prime number, very on-brand)
My Netcom email address and a San Jose phone number are enshrined in the record. Don't bother contacting me through those! Interestingly, if you spell out the phone number, it ends in "NET", but does not spell anything compelling in its entirety.
This is great. You still "own" it, as it still exists in "whois" and ARIN records! The problem is it is assigned to an email address you no longer have access to. You might need to contact ARIN to get back control of it... seems possible since it's in your name and not a company.
That is baffling. I swear that I heard or received a direct communiqué, many many years ago, that ARIN and ICANN and IANA were sweeping out all of the unannounced networks and reclaiming them. Word went out during the initial pressure of address space exhaustion.
So if this is really still assigned to "me" as boss of "my company" I suppose nobody else has ever announced it. It has no BGP behind it. In fact, 192.160.0.0/16 has no BGP at all. That is a huge swath of space to be vacant.
So, in 34 years since its registration, no BGP announcement, no ASN has ever been associated with this Class-C, and it still "belongs to me", unpaid, un-rented? It boggles my mind. I had expected that it was easier to lose an unused IPv4 network than to lose a domain name from back in the day.
Now there is a lot of crazy contact information that is so, so old. It is credible but I barely recall even having some of those phone numbers. There's an email address at cts.com. Which appears to be utterly defunct now but it was a San Diego bboard run by "Bill Blue". I distinctly recall a lot of Usenet posters using "crash.cts.com" and it was a "shell account" provider. It would've been in-character for past-me to sign up there at some point. Some point, I don't know.
So it says they last attempted to contact me 16 years ago. Did they send a letter in the USPS? Did my family receive nothing? So weird. If I literally wrote to them with that return address, would they validate me?
I literally have no idea how I could even use a /24 network today. My ISP wouldn't accept it. I can't exactly run BGP from a Chromebook or Netgear router at home! I suppose the only way to use it would be on a VPS service? Would the VPS announce an old-school "personal" network?
When ARIN contacts you, it's through email. They send an email with a confirmation link, so that probably bounced.
You can definitely announce BGP from a VPS with some providers. I have been doing this for years. Vultr will do it. However, they will validate (through email) that you "own" the block.
My recommendation is you first contact ARIN and see if you can "recover" contact info associated with the class C.
There are some restrictions around legacy blocks that predate the existing of ARIN. For some reason, they cannot reclaim them easily. So they just sit there...
There is no requirement for compilers to be deterministic. The requirement is that a compiler produces something that is valid interpretation of the program according to the language specification, but unspecified details (like specific ordering of instructions in the resulting code) could in principle be chosen nondeterministically and be different in separate executions of the compiler.
We are not talking about deterministic instructions, we are talking about deterministic behavior.
UB is actually a big deal, and is avoided for a reason.
I couldn't in my life guess what CC would do in response to "implement login form".
For all I know CC's response could depend on time of day or Anthropic's electricity bill last month more, than on the existing code in my app, and the specific wording I use.
I do not talk about UBs, compiler can be non-deterministic even for completely valid and well-specified source code.
Seems to me that people just confuse determinism with soundness.
Determinism is just whether the output of the tool (machine code) is determined by the input (source code), i.e., for one input always returns the same output.
Soundness means that output is always consistent with the semantics of the input. i.e. returned machine code always does what is specified by the source code.
Compilers can be non-deterministic (although usually are deterministic), but they are always sound (ignoring compiler bugs).
LLMs can be deterministic (although usually aren't), but they are not sound in general.
It seems to me that it is much more symmetric. In both situations one side guess, due to fundamental uncertainties of human interactions -- each side knows their subjective costs/benefits, but not costs/benefits of the other side.
For 'guesser protocol', the initiatior guess whether the ask is appropriate (say initiator_known _benefit > responder_guessed_cost), while in 'asker protocol', the task of guessing is shifted to responder, as the responder has to guess whether the reject is appropriate (say responder_known_cost > initiator_guessed_benefit).
Common language works for employment and business, but then you go to government bureau (or want to fill government form) and they will insist on official language.
That is why english as secondary official language would be beneficial.
RFC 4787 does not really describe how real world implementations behave. As almost all SOHO routers are Linux-based, i prefer to discuss Linux netfilter-based NAT behavior than some hypothetical RFC 4787 NAT. There are clear differences. For example, RFC 4787 says:
> REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior
While Linux netfilter behavior is "Address and Port-Dependent Mapping".
As Linux netfilter implements both NAT and firewall behavior, it is relevant for the discussion which parts of overall netfilter behavior falls into 'NAT part' and which into 'firewall part'. There is clear distinction - DNAT/SNAT rules in nat table represent NAT behavior, while REJECT/DROP rules in filter table represent firewall behavior.
As Linux-based SOHO routers are usually configured with both NAT and firewall netfilter rules to implement both NAT and firewall behavior, one cannot answer question 'Does NAT filter traffic?' based on external behavior of such SOHO routers, but has to analyze which part of the network stack is responsible for such behavior, or how the same network stack configured with just NAT rules and no firewall rules would behave. And here the answer is no, it would pass traffic (that do not match existing connections) unmodified.
The problem is: what is an implementation detail, and what is NAT as a concept? This line is very blurry. The RFC does not really distinguish this and also doesn't want to. As it says, it tries to document behavior and explicitly uses the term "NAT filtering". When we say "This box here does NAT", then we implicitly assume this behavior. You might argue that implicit is not good, and I would agree (this is the advantage of ipv6 with firewall: filtering is explicit rather than implicit). However, if someone tells me "Well actually, NAT does not do filtering, the firewall does", then to me this is similar to arguing with staff in a supermarket that the tomato belongs in the berries section.
I also want to make clear that I fully agree with the article's main point: NAT's primary purpose was and still is address conservation, and that ipv6 is no less secure than ipv4. I do disagree though with the notion that "NAT does not do filtering" or that "NAT does not provide any security".
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A FORWARD -i lan0 -j ACCEPT
iptables -A FORWARD -j REJECT --reject-with icmp-admin-prohibited
If you omit the first line, you get firewalling without NAT. If you omit the second set of lines, you get NAT without firewalling. This should make it pretty clear that they're orthogonal features.
If NAT functioned as an inbound firewall, the second set of lines wouldn't be necessary and removing them wouldn't let you make inbound connections. But you can just test it yourself, and you'll see that NATing your outbound connections doesn't block new inbound ones.
LAN IP address spoofing is indeed a valid attack vector, if the ISP is compromised.
Internal daemons on machines other than the router itself in the LAN network listening on 0.0.0.0 are not insecure (unless you have the problem from point 1, malicious/compromised ISP). The router won't route packets with IPs that are not in its LAN to them. Of course, the router itself could be compromised if it accidentally listens on 0.0.0.0 and accepts malicious packets.
Not sure what you mean by reflection amplification attacks, but unless they are attacking the router itself, or they are arriving on WAN with LAN IPs (again, compromised/malicious ISP), I don't see how they would reach LAN machines.
Whichever machine has the NAT's external IP assigned to it will accept or refuse the connection, depending on whether they have a server running on that port or not.
The machine that has the NAT's external IP to it is, well, the NAT, by definition. So you admit that the NAT box will act almost exactly like a connection tracking firewall, even if only NAT is enabled.
No, I'm not going to "admit" that, because I know full well that it won't.
It's not like I'm sat here thinking "I know it does block traffic, but I'm going to lie to everyone that it won't". NAT in fact, actually, really and honestly, doesn't block traffic, and I think I've been pretty consistent in saying as much.
You've been consistently wrong, yes. A NAT router box will NOT translate a packet coming from the Internet (so, a packet with a globally routable IPv4 address) arriving on its WAN to the RFC1918 IPv4 address of any box sitting behind it on the LAN side, unless it is arriving on a previously open connection, or on a port the user explicitly asked to be allowed and forwarded - exactly the same behavior of a regular stateful firewall.
Of course it won't do that -- when did I ever claim it would? But that's not the same behavior as a stateful firewall at all.
A stateful firewall would block packets addressed to the router, or to machines behind it. NAT not translating a packet won't do either of those things.
I can only repeat myself: you are talking about the NAT module in the Linux netfilter. I, and the RFC, are talking about NAT as a concept: what behavior do you expect when you say "this device does NAT". Of course you can still have "pure NAT", but if someone tells you "set up a device that does NAT" and you omit that first line and later explain that this is historically and technically accurate, well, good luck with that.
All the Linux routers I've used utilize Endpoint-Independent mapping with Address- and Port-Dependent _filtering_.
This means you can still establish direct P2P connectivity behind a Linux-based NAT device with users behind other Linux-based NAT devices. The only time it becomes an issue is when attempting to communicate with users behind NAT devices that do Address-Dependent _mapping_ or Address and Port-Dependent _mapping_. Some *BSD-based NAT implementations are this way.
Endpoint-independent _filtering_ is only a good idea for CGNAT implementations. Having an EIM/EIF NAT/firewall setup without additional firewalling makes it possible and easy for devices to run public-facing UDP-based servers without anyone's knowledge. With EIM/EIF, once you create a NAT mapping, so long as you send out periodic keepalives, _any_ IP address with _any_ source port can make unsolicited connections to a server that the NAT mapping points to. The best compromise is Endpoint-independent mapping with Address- (but not port-) dependent filtering.
I have an opposite experience. I use predominantly DDG (mainly for UI reasons), but often the search results are much less relevant than from Google, or i got exact zero results, where Google finds plenty of instances of searched phrase.
I find Google is still really good at finding things for maps/navigation (and I contribute greatly to maps with pictures/reviews), but even that has become a problem with results of places that do not exist (and reviews from owners that say a place never existed where maps is saying)
depends on what you are searching for, but the constant attempts to trick me into useless garbage ads has destroyed reliability/my trust in their general search
reply