> On 05/10/2017 07:40, Jay R. Ashworth wrote:
> > Does anyone have a pointer to an *authoritative* source on why
> >
> > 10/8
> > 172.16/12 and
> > 192.168/16
> >
> > were the ranges chosen to enshrine in the RFC? ...
>
> The RFC explains the reason why we chose three ranges from "Class A,B &
> C" respectively: CIDR had been specified but had not been widely
> implemented. There was a significant amount of equipment out there that
> still was "classful".
>
> As far as I recall the choice of the particular ranges were as follows:
>
> 10/8: the ARPANET had just been turned off. One of us suggested it and
> Jon considered this a good re-use of this "historical" address block. We
> also suspected that "net 10" might have been hard coded in some places,
> so re-using it for private address space rather than in inter-AS routing
> might have the slight advantage of keeping such silliness local.
>
> 172.16/12: the lowest unallocated /12 in class B space.
>
> 192.168/16: the lowest unallocated /16 in class C block 192/8.
>
> In summary: IANA allocated this space just as it would have for any
> other purpose. As the IANA, Jon was very consistent unless there was a
> really good reason to be creative.
>
> Daniel (co-author of RFC1918)
>>> This is a fuzzy recollection of something I believe I read, which might well be inaccurate, and for which I can find no corroboration. I mention it solely because it might spark memories from someone who actually knows:
>>> A company used 192.168.x.x example addresses in some early documentation. A number of people followed the manual literally when setting up their internal networks. As a result, it was already being used on a rather large number of private networks anyway, so it was selected when the RFC 1597 was adopted.
>> sun
> Wasn't 192.9.200.x Sun's example network?
of course you are correct. sorry. jet lag and not enough coffee.
---
So no answers.
We're a 2-man crew, about to start one of America's biggest ISP's.
We'd just gotten the closet cleared, the racks assembled, the modems installed, the terminal server wired up, the USENET machine booted, and we're waiting for the T1 to go live. The modems are answering calls, but there's nowhere for our new subscribers to go .. yet.
The tech line rings, its the T1 guy on the other end "Ready to configure your router with you if you're ready .. "
Sure, I say .. whats our IP address ..
"198.162 .. "
"WAIT!", I say. "Are you SURE about that?"
He sure was.
The line comes up, the routes flow, customers get online for their first time.
But for months afterwards I was constantly in fear of our IP address.
Junior network guys would call me up in the middle of the night, adding some NOC somewhere or other "it doesn't work!" - "did you mix a 2 and an 8?", I'd say .. and much swearing would be heard until things started working again.
Man, that was fun. Getting that IP address assigned to us definitely was an act of mischief on the part of some devil somewhere, I'm quite sure ..
LoRA is all the world needs. ;)
Not everyone thought this was a good idea, and I still maintain the alternative path would have led to a better internet than the one we today.
The realists in me expects that everyone would have used one of the ~13 /8 blocks assigned to the DoD
Let's start with a simple assertion: Every computer on the Internet has an Internet address.
If it has an Internet Address, it should be able to send packets to any computer on the Internet, and any other computer on the Internet should be able to send packets to it.
Private networks break this assumption. Now we have machines which can send packets out, but can't receive packets, not without either making firewall rule exceptions or else doing other firewall tricks to try to make it work. Even then, about 10-25% of the time, it doesn't work.
But it goes beyond firewall rules... with IP addresses being tied to a device, every ISP would be giving every customer a block of addresses, both commercial and residential customers.
We'd also have seen fast adoption of IPv6 when IPv4 ran out. Instead we seem to be stuck in perpetual limbo.
On team anti-private networking addresses:
- Worse service from ISPs - IPv4 still in use past when it should have been replaced - Complex work around overcoming firewalls
I'm sure we all know the benefits of private networks, so I don't need to reiterate it.
Since Netware was very popular in businesses and it was possible/common to use only the IPX protocol for endpoints, you could configure endpoints to use a host that had both an IPX and IP address as the proxy, and not use an IP address on most endpoints. That was common due to Netware actually charged for DHCP and DNS add-ons. When Windows became more popular, IP on endpoints likely used RFC-1918 around ~1996.
Yep, a desktop PC with its own IPv4 address. Back in the day, no firewall afaik.
What's the history behind 192.168.1.1? - https://news.ycombinator.com/item?id=17467203 - July 2018 (48 comments)
This was in the 10's of 1000's of devices.
> > Wasn't 192.9.200.x Sun's example network?
> of course you are correct. sorry. jet lag and not enough coffee.
At beginning, Internet used network classes, because of hardware limitations (later switched to address blocks). And even in 1990s still existed very old hardware, only could use class addresses.
What classes mean, existed early very large organizations, got more addresses than they could use. And even happen few cases, when such organizations lost rights for these addresses.
And these unlucky organizations was some big whales, like IBM or ATT/Bell or Sun.
And once invented solution - state some big enough network as not allocated to use under NAT (or when network is not connected to Internet). So, departments of big organizations could use TCP/IP stack in their networks, even with old hardware, but don't need to contact Internet officials to got real internet addresses.
192.168 was just first C-class network prefix, was not assigned at the moment (or just released).
Later, to list of unassigned added 172.16/12 network.
In the mid 90's, SMBs connecting to the Internet would have very typically obtained a /24 from their ISP, and had direct connection online, no firewalls, barely any proxy servers (although that was popular for some mid sized customers that would have needed multiple /24s or even a /16 to get all their workstations online).
It wasn't until the company Network Translation, with the PIX came about that anybody even considered doing private IP address in general as a firewall strategy with NAT translation using private IPs. And then it took years and years to become popular. Long bought by Cisco at that point.
I don't think Cisco IOS even had NAT until something like 10.2, when it was a premium license package.
I remember those early days. No firewalls. No proxies. I had that /24 on my home network, totally unfiltered. Kinda nuts thinking about it today.
[1] https://superuser.com/questions/784978/why-did-the-ietf-spec...
Reading this makes me a bit sad and reminds me that I'm older now and lucky to have grown up during the golden age of the Internet.
It created a big trauma when I joined the uni and hit the wall. I suppose this how americans feel about the metric system :p
192 is 11000000 in binary.
So it is simply the block with the first two bits set in the netmask.
168 is a bit more difficult. It is 10101000, a nice pattern but I don't know why this specific pattern.
192 in the first octet starts the class C space, but 10 and 172 do not have the same relationship in classes A and B.
I'm also tired of remembering ports, if there's a way of mapping those. Should I run a local proxy?
If we're talking web-services - absolutely. I put Caddy in front of everything just to be able to simply use domains. You can also use it to map ports to either standard or more convenient ones if that suffices. Configuring reverse-proxy with Caddy [0] takes just a few lines:
http://some-service.internal {
reverse-proxy localhost:12345
}
- DNS-server: most routers can be that; another easy option would be PiHole.
- DHCP-server: same as above (PiHole does DHCP too).
- Reverse-proxie(s): you can have either just one for the entire network or a number closer to the amount of services if you choose to have HTTPS between everything. Wouldn't bother with Nginx for that unless there is a strong incentive.
- ACME-server: provides the certs for the local reverse-proxies if you choose to have HTTPS between everything. Caddy can also act as a very easy to set up ACME-server [1].
If you have all that set up, you can access all the local services securely and via readable URLs. Given all the services get their certs from the ACME-server, the consumers only need to trust (install) one root cert in order to consider all the local connections secure.
Might seem like a lot at first, but the configuration is fairly straightforward and I found it's worth the effort.
[0]: https://caddyserver.com/docs/caddyfile/directives/reverse_pr...
[1]: https://caddyserver.com/docs/caddyfile/directives/acme_serve...
For port mapping depends what specifically you’re aiming for. SVCB/HTTPS records are nice for having many https servers on a single system.
Theoretically SRV records can be set in dns to solve the port issue, realistically Nothing uses them so.... You are probably out of luck there. The way SRV records work is you are supposed to ask a network "Where is the foo service at?"(SRV _foo._tcp.my.network.) and dns sez "it's at these machines and ports" (SRV 1(pri) 1(weight) 9980(port) misc.my.network.(target))
https://www.rfc-editor.org/rfc/rfc2782
My personal low priority project is to put mac address in DNS, I am about as far as "I could fit them in an AAAA record"
As for specific software recomendations, I am probably not a good source. I run a couple of small openbsd machines(apu-2) that serve most of my home networking needs. But, I am a sys-admin by trade, while I like it, I am not sure how enjoyable others would find the setup.
There's the EUI48 rr type, but I don't know how widely supported it is
Depending on how one defines "nothing," they are honored by XMPP clients.
CoreDNS in Kubernetes also publishes SRV records, for any client in-cluster who wishes to look up the port number used by a named port on a v1.Service
For ports, anything that can just be run on 443 on its own VM, I do that. For things that either can’t be made to run on 443, or can’t do their own TLS, etc, I have a VM running nginx that handles certificates and reverse proxying.
I'm not aware of any DHCP change needed for that, since to the very best of my knowledge mDNS is a broadcast protocol. Involving DHCP would be pointing it at the copy of dnsmasq running on your router, such that the hostname that the devices present to DHCP are then resolved by dnsmasq, no mDNS required
That's how I think it should be, but Paul Graham disagrees (or at least he did in 2008 and I haven't seen anything later about him changing his mind).
In [1] he wrote:
> I think it's ok to use the up and down arrows to express agreement. Obviously the uparrows aren't only for applauding politeness, so it seems reasonable that the downarrows aren't only for booing rudeness
edit: OP: just like the downvote button is not for disagreement, the delete button is not for karma management. Not sure why you would respond to my post here and then immediately delete it.
This is a fuzzy recollection of something I believe I read, which might well be inaccurate, and for which I can find no corroboration. I mention it solely because it might spark memories from someone who actually knows:
Offering an alternative hypothesis seems reasonable given the content of the post.