They were politely told no. (Telling people no politely is a significant portion of IT operations, as it happens.)
I had to certify a low speed vehicle using a government test procedure. It called for all test equipment to be calibrated within the last year. I had built some of the equipment myself specifically for the test, though. I measured the relevant performance characteristics in a thermal chamber (oscillator drift was the only possible source of error), documented it on a piece of paper to stick in the office filing cabinet, and printed some "Calibrated on xx/xx/xxxx" stickers.
- 100.64.0.0/10
- 192.0.0.0/24
- 192.88.99.0/24
- 192.0.2.0/24
- 198.51.100.0/24
- 203.0.113.0/24
- 233.252.0.0/24
The significance of these networks is left as a punchline for the reader.
What is 233.252.0 0/24 reserved for? I don't immediately recognize it and didn't see it on the iana special registry.
> The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST- TEST-NET" for use in documentation and example code. 233.252.0.0/24 SHOULD be used in conjunction with the [RFC2606] domain names example.com or example.net in vendor and protocol documentation. Addresses within 233.252.0.0/24 MUST NOT appear on the public Internet.
https://www.iana.org/assignments/multicast-addresses/multica...
Another solar car, a police officer just came out to inspect it like a "kit car". He asked, "It has 4 wheels, right?" And we were like, "yeah for sure, if you count the steering wheel." And he went ahead and checked the box.
No amount of RFC references, live demos of “see, www.google.com does it with HTTP also” would tick the checkbox.
“We have a security standard, sir.” over and over, for months.
Auditor wants to see firewall rules on our IP addresses, except we don't have IP addresses, we were small enough that the default Azure general shared outbound network worked. (Think CGNAT). No amount of explaining this would check the box.
Solution: add a public IP to our prod env, unassigned to anything, with firewall rules. Audit passed.