Email or username:

Password:

Forgot your password?
Sindarina, Edge Case Detective

Since I keep seeing developers use ‘pretty’ IP addresses like ’1.2.3.4’ in example configurations; a reminder that you MUST NOT use publicly routable addresses that you do not control in your code.

Instead, use one of the available 'TEST-NET' IPv4 or IPv6 ranges documented in RFC 6890;

192.0.2.0/24
198.51.100.0/24
203.0.113.0/24

❌ 1.2.3.4
✅ 192.0.2.4

and for IPv6;

✅ 2001:db8::/32

Pass it on to all of your fellow developers, documentation writers, and so forth.

Full RFC for special purpose addresses;

datatracker.ietf.org/doc/rfc68

Reserved for documentation, IPv4 and IPv6;

datatracker.ietf.org/doc/rfc57
datatracker.ietf.org/doc/rfc38

1/ 🧵

63 comments
Sindarina, Edge Case Detective

The same goes for domain names; do NOT use a public domain name you do not control in your configuration, documentation, or UI language.

Instead, use one of the available reserved domain names documented in RFC 2606, such as 'example.com', 'example.net', or the .example top-level domain.

❌ test.com
❌ yourdomain.com
✅ example.com
✅ yourdomain.example

Pass it on to your fellow developers, designers, documentation writers, and so forth.

Full RFC text is here;

datatracker.ietf.org/doc/rfc26

2/ 🧵

The same goes for domain names; do NOT use a public domain name you do not control in your configuration, documentation, or UI language.

Instead, use one of the available reserved domain names documented in RFC 2606, such as 'example.com', 'example.net', or the .example top-level domain.

❌ test.com
❌ yourdomain.com
✅ example.com
✅ yourdomain.example

Sindarina, Edge Case Detective

Oh, and please, if you are sending email, don't make up random addresses for your app to test with. Only send mail to addresses you know are valid, and for which you have permission to send mail.

If you need to test SMTP while developing software, use a mock SMTP server that drops all outgoing email in a local directory, so you can inspect it without dumping a metric ton of email in your upstream's SMTP queue.

If you absolutely must generate unique email addresses for testing, either register a domain for that purpose and set up mail handling for it, or use the .test TLD, and have as many unique domain names as you like.

3/ END

Oh, and please, if you are sending email, don't make up random addresses for your app to test with. Only send mail to addresses you know are valid, and for which you have permission to send mail.

If you need to test SMTP while developing software, use a mock SMTP server that drops all outgoing email in a local directory, so you can inspect it without dumping a metric ton of email in your upstream's SMTP queue.

Sindarina, Edge Case Detective

There's always at least one person who doth protest too loudly, whenever they are alerted to bad habits like these 😂

Gwenn

@sindarina
4/ Do not use "/dev/sda" or any valid volume name in an example for a formatting command.

jordan

@sindarina had to alert my company that we were sending automated emails of sensitive data to an email address at test.com before. whoever owns those domains probably has access to every secret in the country by now...

Jens Dibbern

@sindarina And, for the love of god, start using test e-mail infrastructure. It's a 10 minute job to start a greenmail container or something similar. Gazillions of postmasters are sick of seeing your junk in their logs.

Sindarina, Edge Case Detective

@sieri That's only possible after you've created a GUI interface using Visual Basic.

Sindarina, Edge Case Detective

@ben No, wasn't you, Little Snitch still does it, and I kept meaning to repost because the previous time was on .lol 😄

🚲

@sindarina i also find it not obvious that 1.2.3.4 is supposedly an IP address

Mikołaj Hołysz

@sindarina Unless the config field is particularly security sensitive, I’d still use something like 1.2.3.4, just because it makes it obvious that the address is an example and needs to be changed. For users who don’t know about these ranges, AKA me from two minutes ago, 192.0.2.4 looks like an existing IP address, which may or may not point at a reasonable default / vendor-provided server, and so it isn’t obvious whether it should be touched. I would say that using those addresses is a tradeoff, and it should be considered how likely 1.2.3.4 is to ever become malicious, and what the consequences would be for a particular application. Another interesting way to solve this is to use 123.456.123.456, as that is not a valid address.

@sindarina Unless the config field is particularly security sensitive, I’d still use something like 1.2.3.4, just because it makes it obvious that the address is an example and needs to be changed. For users who don’t know about these ranges, AKA me from two minutes ago, 192.0.2.4 looks like an existing IP address, which may or may not point at a reasonable default / vendor-provided server, and so it isn’t obvious whether it should be touched. I would say that using those addresses is a tradeoff,...

Sindarina, Edge Case Detective

@miki 1.2.3.4 is a valid IPv4 address, just like, say, 1.1.1.1, and you should stop making excuses 🙂

Mikołaj Hołysz

@sindarina And so what? If using a valid address isn’t a security concern in a given context, where’s the problem exactly?

Sindarina, Edge Case Detective

@miki Thousands of people over the decades who, like you, didn't think it would cause a problem, leaving others to clean up their messes down the road.

Like, entire chunks of the IPv4 address space that are unavailable because of assumptions made in the past.

Just change the habit, man 😄

lj·rk

@sindarina @miki Please don't disregard reasons as excuses. The reasons were given and the RFC does *not* address these points, unfortunately.

tl;dr: Example addresses that don't like example addresses despite being standardized in RFCs aren't *that* helpful to those who don't actually know that RFC.

Sindarina, Edge Case Detective

@ljrk @miki Which is why posts like these are made, complete with links to the relevant sources.

Habit is no excuse, and neither is ignorance. If you are concerned that people may not realise it is provided as an example, you should document this, within the context you are using it, because that part of your argument applies regardless of which address you use as an example.

Mikołaj Hołysz

@sindarina @ljrk This is sometimes not possible, for example in config files that have to be written in pure JSON (and hence don’t support comments). Sure, there’s always a manual, but having to read that is nowhere near good UX design principles.

lj·rk

@sindarina @miki The discussion was not about habit, zero points there. And it's not about ignorance of the designer but the user, and assuming users know every RFC is a bullshit assumption.

But I have enough about getting told I'm ignorant or just doing things out of habit. If you want to just attack people disagreeing instead of actually trying to understand their points fine, but not with me. What load of toxic bs.

Katze

@ljrk @sindarina @miki If someone is required to provide a valid IP address, then why not put an IP address from said documentation ranges there and throw an error of some sorts if one of those addresses was used? That way you won't run into someone who actually does have access to 1.2.3.4 who cannot use your app or service because of Assumption™ because those addresses are guaranteed to not be in use. Also throwing an error is the right thing to do when someone is required to change something but hasn't IMHO.

lj·rk

@benaryorg @sindarina @miki Because not always you have actual default values but examples in docs.

Katze

@ljrk @sindarina @miki In documentation of all places you do have the ability to actually write that this value needs to be changed though.

"Important: insert the IP address of [whatever] here"

lj·rk

@benaryorg @sindarina @miki Yep, and observe how people ignore it. Anyone who believes that documentation is actually read is naïve.

Everything that can be "self-documenting", i.e., *self explanatory* and obvious should be made/written like that. Any "surrounding" documentation is less likely to be read.

Katze

@ljrk @sindarina @miki Let me rephrase this in financial terms, maybe then I'll get across how important it is to not have random IP addresses somewhere in code, docs, or even blog posts.

Currently the entire 1.2.3/24 is unassigned as far as I can tell, probably because people used those addresses at large, and simply announcing the /24 (and you have to announce an entire /24 at a time, smaller routes won't be accepted on the internet) will probably net you an enormous amount of traffic. The APNIC Debogon Project for instance has the goal of reintroducing such problematic network addresses back into the internet by working with a variety of ISPs and other instances to remove something like old filter lists for networks that were once widely blocked. The filter lists probably aren't too much of a problem in this case, it's more a matter of the amount of bogus traffic you'd get if you announced that network, and considering it's stemming from IPs present in various documentation, maybe even defaults somewhere, it seems rather likely to me that the reintroduction of that network probably won't happen anytime soon (although some people would probably pay very well for that IP).

So let's get into the fun part; IPv4 address space is expensive. Very expensive actually. Some sources estimate around 50$-70$ per IP, and /24 blocks do seem to net one around 10k$. I'm not too involved in the financial part of networking so I'm not too sure how reliable these numbers are, but sources seem to be somewhat consistent in those numbers. Also last time I heard about this kind of thing companies would try to buy existing but failing other companies to acquire their allocations rather than buy them to avoid having to go through a bunch of reassignment and justification stuff.
In any case removing a good chunk of internet for something that is priced about three times my gross monthly salary, because people thought the IP looked better in the docs.… eh. I don't know about that.

Even better would be adding IP addresses from networks which have actual technical implications like multicast ranges or other reserved networks which could potentially¹ cause actual issues rather than just not working.

Then there's the part about potential security implications; you add 1.2.3.4 to your docs for a curl command that uploads some data, expecting people to input the correct address, but some people still just copy&paste it. Years later maybe. Maybe after the IP has been reassigned and maybe there is a webserver running on that IP now. And they just inadvertently uploaded some important, maybe even PII, data to that server, which may be on a different continent.… ohhh boi, don't we all love to get an email from a service provider to tell us they accidentally leaked some information.

I know that writing documentation is hard. So hard in fact there are people who specialize in doing this; technical writers. But embedding IPs, domains, or other internet resources you do not own to your documentation creates problems for someone, somewhere.
Just think about how you'd feel if a DDoS as a service provider decided to add your website/server as an example domain for their API docs.…

Things like these may seem like a good idea if you can ignore the consequences, but we all know you shouldn't ignore the consequences just because you're not affected by them.

@ljrk @sindarina @miki Let me rephrase this in financial terms, maybe then I'll get across how important it is to not have random IP addresses somewhere in code, docs, or even blog posts.

Currently the entire 1.2.3/24 is unassigned as far as I can tell, probably because people used those addresses at large, and simply announcing the /24 (and you have to announce an entire /24 at a time, smaller routes won't be accepted on the internet) will probably net you an enormous amount of traffic. The APNIC...

Katze

@ljrk @sindarina @miki Personal opinion: if you're writing documentation in the assumption that people won't read half of it then I have a personal issue with your way of doing, because I would much rather you stop reinforcing that existing bias. The fallout of any form of text or information base trying to safeguard the people who won't even stop to read a single info box or bold written text is that people suddenly read news headlines and consider the entire article read. Or to read the first three words of a sentence and assuming they know the rest. This causes issues in all areas of life; prime example being the misinformation bias surrounding news because people don't bother to read more than the headline.

Making it easier to get away with not reading the important bits is part of the problem IMHO, not a solution. Not by a long shot.

@ljrk @sindarina @miki Personal opinion: if you're writing documentation in the assumption that people won't read half of it then I have a personal issue with your way of doing, because I would much rather you stop reinforcing that existing bias. The fallout of any form of text or information base trying to safeguard the people who won't even stop to read a single info box or bold written text is that people suddenly read news headlines and consider the entire article read. Or to read the first three...

lj·rk

@benaryorg @sindarina @miki You don't learn by giving people a hard time. That's been established by quite a long time. It's a bullshit "didactic" theory that's still promoted by authoritarian teachers. I thought we were over that crap.

It's all about making good documentation. And any good technical writer will tell you that things that are written in an accessible and self explanatory way are better than unclear/complex technicalities with explanatory text *around* them.

Take *any* well-written technical paper, document, book. None of them will slap a lot of complicated formulas there and then have a second page explaining them. It will pick you up from line one and guide you through every step. It will have self-explanatory and carefully chosen names and terms for concepts introduced.

And no, 192.0.2.0/24 is not self-explanatory or obvious. Maybe it's simply bad how all this unfolded that the RFC came too late and we should've standardized 1.2.3.0/24 as test IP range, idc. But I do care about things being as obvious as they can (but not more than that).

I follow that RFC, in most cases. But there are cases where I don't, and repeating a lot of points that *I already know* won't change my mind. Addressing the problems I have with that RFC might. But alas, that doesn't happen.

@benaryorg @sindarina @miki You don't learn by giving people a hard time. That's been established by quite a long time. It's a bullshit "didactic" theory that's still promoted by authoritarian teachers. I thought we were over that crap.

It's all about making good documentation. And any good technical writer will tell you that things that are written in an accessible and self explanatory way are better than unclear/complex technicalities with explanatory text *around* them.

Katze replied to lj·rk

@ljrk neither am I saying to make it hard to get the information from the documentation nor am I saying to strip down the documentation by making it "self explanatory". Something being "self explanatory" is a concept in which I do not believe because rather than making something more accessible it usually just causes different people to have issues with the documentation.
If you remove the "don't forget to change the IP" entirely then you're just tripping up a different set of people.

The only real solution to the problem of making things clear is by employing more than just text in documentation. Be it visuals, or something interactive.
The interactive part (OVH's API docs being an example, you enter values in textboxes and it generates PHP or Python code, would love curl too but still good) is hard to get right and often not really possible (think text documentation).

However the visual part is comparatively ubiquitous.

curl https://192.0.2.1/foo
^^^^^^^^^
change this

Or if the command gets a little too long and you should factor out parts anyway:

ip=192.0.2.1 # change this
curl "https://${ip?}/foo"

This doesn't solve everything, but it both conveys the need to change a value as well as it possibly can IMHO (at least better than just hoping that 1.2.3.4 catches someone's eye) and it does make it easy to retrieve this message. Although it is less accessible for users of screen-readers, but for that you'll probably always need some regular text that is just™ readable by a screen reader).

The idea you're describing in your third paragraph, or at least in the way that you describe it, is very much tied to a multi-step thing, an API documentation may not contain multiple steps. Other pieces of documentation may not warrant introducing any concepts, they are just that one thing you should do and the only fluff that could possibly be there is a small info box telling you to change values accordingly. And whenever a technical paper, document, book, or anything of sorts tries to denote that this is an example, then it will probably make it clear that this is, in fact, an example, something that has to be reviewed before using, something that has to be understood before executing, something that is a template to the thing that you are trying to do.
There should never be an IP already filled out in anything that looks copy&pastable unless it is clearly marked as "this is what it looks like for me, your mileage may vary" together with the template of how to find out what you ought to do yourself.
That's where the IP ranges kick in. They aren't there to put in some code to start with, they're there to describe how things should look like in most cases:

To do the thing you can run this command:

curl https://$IP/foo

Note that you need to replace the `$IP` with your own IP ([insert pointer on where to find this information here, maybe an inline reference?]), for IPv4 this is just the regular IP as in `192.0.2.0`, for IPv6 bracketed notation is required: `[2001:db8::1234]`.

The IPs should not serve as placeholders, but as examples themselves IMHO.
Whatever documentation uses them inline without having a clearly established context (that of an example) and clear marking for which parts are variable, I don't like it.

Tech has the same issue whenever Regex comes along and people push all of the verification into the Regex itself (see the dreaded email regex that doesn't ever work anymore). No, the Regex is a means to denote a patterns, which is then captured and actually validated in a second step. Shoving Integer range validation into a Regex is the pinnacle of "you won't be able to maintain this in two weeks", and it's the same with IPs in documentation. Don't embed them. Put them next to the important part as an example. Remember the old placeholders in text inputs on the web? When there was actual text in there that you could just submit if you did not change the field, because it was stored as the value? And then finally came along the browser-supported placeholder attributes that allowed us to specify something that is visible, but not part of the content. This is what documentation needs those IPs to be. A thing to look at, but not to use.

And as someone who has read more network documentation than I'd like, 10.10.10.10 communicating with 11.11.11.11 is just as unusable to me. Call it Host A and Host B, or better even put an example there and have them be Server and Client or something.
Put the IPs there as an example of what it could look like, but do not use it to describe the actual content.
I don't want to know that 10.10.10.10 establishes a connectio— No! The client uses its internal IP (in this case 192.0.2.1) to connect to the servers public facing IP (here 203.0.113.1) which is visible to the server as the routers public facing IP (198.51.100.1) thanks to NAT.
Why anyone would ever keep talking about the IPs is beyond me. So many people have trouble with numbers already, especially if you have more than two of them, they get mixed up, the communication gets tedious, I haven't seen a person who was good at all those numbers in my life.

And in this kind of documentation, does it matter whether the IP is 1.1.1.1 or 198.51.100.1? I would say No, because it is clear in every sentence that these are examples.

@ljrk neither am I saying to make it hard to get the information from the documentation nor am I saying to strip down the documentation by making it "self explanatory". Something being "self explanatory" is a concept in which I do not believe because rather than making something more accessible it usually just causes different people to have issues with the documentation.
If you remove the "don't forget to change the IP" entirely then you're just tripping up a different set of people.

lj·rk replied to Katze

@benaryorg

> If you remove the "don't forget to change the IP" entirely then you're just tripping up a different set of people.

Didn't say that. I said that it should ideally be made as clear as possible from the command itself, you yourself give many of such examples. But it's friggin' hard and I had people literally run commands with placeholders 1:1 despite everything you described. And not too few.

Maybe I'm burnt because I taught freshmen CompSci, most of them having never opened the command line a week before. But I always try to assume the least competent user – which means, assume that they do not *know* that RFC and they do not look at surrounding hints.

@benaryorg

> If you remove the "don't forget to change the IP" entirely then you're just tripping up a different set of people.

Didn't say that. I said that it should ideally be made as clear as possible from the command itself, you yourself give many of such examples. But it's friggin' hard and I had people literally run commands with placeholders 1:1 despite everything you described. And not too few.

Katze replied to lj·rk

@ljrk I think the freshmen CompSci may be the reason indeed. Considering that school, university, most sorts of academics in general will encourage or even require skimming texts. When people from that background arrive in tech and see actual good documentation it's probably the firnt time they read a text that's written to be read for information, not written to comply with academic standards.

I get that we shouldn't make participation hard for people, but in that one instance I think it's arguably okay to do something to get that (IMHO toxic) mindset out of their heads.
Most people I know and have known are from a non-academic background and the majority of thes still tries to cut through docs but ultimately reads the important bits. It's more a habit of trying to skip chapters than parts of a sentence. And skipping in introduction may be much less problematic than skipping the half of the sentence that digs into the actual matter.

However overall I still don't think some inadvertent issue like making networks unusable or breaking your local connectivity by accident (something detecting public IPs and disabling a port or whatever) is worth the (presumably small) margin of people who will notice the funky looking address.

But at this point I'd have to agree, I am repeating myself, so I won't reiterate :blobCat_wink_tongue_out:​

@ljrk I think the freshmen CompSci may be the reason indeed. Considering that school, university, most sorts of academics in general will encourage or even require skimming texts. When people from that background arrive in tech and see actual good documentation it's probably the firnt time they read a text that's written to be read for information, not written to comply with academic standards.

lj·rk replied to Katze

@benaryorg That's why I wouldn't put 1.2.3.4 in docs/example configs for... idk, a BGP router or something lol.

As I said, it really comes down to the target group, and if I get more confusing/questions about 192.0.2.0/24 and it holds up students or confuses them, I tend to use 1.2.3.4 (it's mostly oral lectures, although I hate giving lectures).

DUVERGIER Claude

@ljrk @sindarina @miki 2.2.2.2 and 8.8.8.8 both looks like an dummy IP (users could think it's not a real IP) but they are real, functional IPs you should not use as examples (unless DNS stuff with Google).

RFCs being unknown to some users is a very good reason to use them, the more there are documents using theses "documentation" IPs, the more people will recognize them easily.

lj·rk

@C_Duv @sindarina @miki I know.

That's not how learning works.

Please don't repeat boring and well-known points instead of engaging with the other side's counter points. It really leads to nothing. If I say "but A is a good reason to do X" and you say "yeah, but there are other reasons B and C for Y" then none of our statements actually are in conflict you see?

Both are true. There are reasons for using that RFC (I said so myself, g'damnit) and reasons against. Telling me more reasons for using that RFC doesn't change the fact that there are reasons against it.

I'm outta here, this is such a bullshit "discussion".

@C_Duv @sindarina @miki I know.

That's not how learning works.

Please don't repeat boring and well-known points instead of engaging with the other side's counter points. It really leads to nothing. If I say "but A is a good reason to do X" and you say "yeah, but there are other reasons B and C for Y" then none of our statements actually are in conflict you see?

David Zaslavsky

@miki @sindarina I think the whole point of this thread is that 1.2.3.4 does *not* make it obvious that the address is an example and needs to be changed. That's somebody's real IP address. And yes, I understand the reason why you're making this argument, that 1.2.3.4 looks made-up in a way that 192.0.2.4 does not, but that only lasts as long as nobody tries connecting to it (which realistically is not likely to be the case for long).

ndpi

@sindarina what a missed opportunity by the IETF to take human behavior into account. They could have set aside 1.2.3.0/24 instead and this would all have gone swimmingly 😄

medium rare bird

@sindarina if only IP addresses were cryptographic capabilities rather than ambient-authority numbers

tessarakt

@sindarina erinnert mich an einen Automobilhersteller, der (s)ein riesiges routbares Netz fürs Bordnetz benutzt...

Christian Vogel

@sindarina …guess what I use on my WiFi and VPN Network? :-)

Boris

@sindarina thanks for the reminder! And it's also valid for phone numbers! Most countries have ranges of phone numbers dedicated for cultural usage (movies, for example). Phone numbers that will never be attributed to a person or a company.

For France, for example, any 10-digit starting with 01 99 00, 02 61 91, 03 53 01, 04 65 71, 05 36 49 or 06 39 98 (replace the initial 0 by +33 for international use)

(Legal source: legifrance.gouv.fr/jorf/articl)

Christopher Wood

@sindarina So, yes to all this, but how have you managed bringing these up without spending the rest of your time at that company being ignored in meetings and eating alone at small tables?

Kevin Karhan :verified:

@sindarina Personally, I think violating #RFCs should be a criminal offense, since I've also experienced the #VPN-breaking use of #RFC1918 adresses for #CGNAT!

Clark W Griswold until 25-Dec

@sindarina as I recall, the 192.0.2.0/24 address range was assigned because for years, Sun Microsystems shipped systems with 192.0.2.5 as their hardwired static IP address. Does anyone agree? Anyone else remember that, or am I “hallucinating” that?

Sindarina, Edge Case Detective

@paco Hmm, I don't think I've heard that one before, but it also wouldn't surprise me? Sounds very similar to the story that a large chunk of IPv4 space was unusable because Microsoft hardcoded it as such in Windows.

Kevan

@sindarina WHy not just use 0.0.0.0? I don't think that will go anywhere.

Ellie

@sindarina I had been using the example IP 10.11.12.13 in documentation I wrote. The TEST-NET blocks would be more correct and less likely to collide, though sadly a little less dramatically example-looking.

(Though I seem to recall dealing with a piece of network kit 10 years ago that was routing 192.0.2.0/24 publicly... 🤔)

gunstick

@sindarina it is like the 555 phone number in movies. Movies often also use some numbers bigger then 256 in IP adresses shown on screen.

Sheldon Chang 🇺🇸

@sindarina Also if you're American, never use 078-05-1120 as your social security number.

It's from the early days of the US social security IDs and a wallet company put an example Social Security card into their wallet as a prop.

At the peak, 40,000 people used that number.

ssa.gov/history/ssn/misused.ht

calumn

@sysop408 @sindarina wait, you get to PICK your social security number?

Sindarina, Edge Case Detective

@Ellis @jurjen_heeck Yup, is voor computer specialisten. Als je je daar niet regelmatig mee bezig houdt mag je gewoon verder scrollen 🙂

kazi

@sindarina
My friend's ISP uses 1.1.1.1 for their gateway…

NavBlank

@sindarina@ngmx.com Only somewhat related: someone we professionally hired configured our home network with 1.1.1.1 as the IP for our router. I was really confused why a sign in for our equipment was showing when I was trying to access CloudFlare's encrypted DNS site.

Rachael Ava 💁🏻‍♀️

@sindarina 0.0.0.0 is a valid IP address to use for documentation and testing because it literally routes to nowhere.

Sindarina, Edge Case Detective

@RachaelAva1024 No, it isn't. Just stick with the documented test ranges.

Rachael Ava 💁🏻‍♀️

@sindarina Just checked Wikipedia, and you're right. I guess I've only ever seen 0.0.0.0 used to point something to nowhere. I had no idea it could be used as an actual IP address. I just thought it was the equivalent to /dev/null.

Sindarina, Edge Case Detective

@RachaelAva1024 It's part of the special purpose addresses, see;

iana.org/assignments/iana-ipv4

and basically never used directly, only behind the scenes, which is also why it's not particularly useful in testing, or documentation, because it just means ‘this host’, which could have one address, or ten.

For local testing on the host itself, there's the localhost address.

SLCW💥

@sindarina I define all IPs in a config file, and call them with variables. That way, anytime I need to change IPs, it's a simple matter of updating the config instead of having to go through and update my code.

Matthew Skala

@sindarina On my first co-op term I had to explain this to a technical writer who had changed my example IP addresses to addresses that she thought "looked better" - which happened to be addresses of *our own* internal servers.

Miff

@sindarina I kinda appreciate when a TV show or something needs to show an IP address on-screen they use "octets" above 255, such as 301.49.452.7. It certainly upsets some people but I see it as close enough to giving a 555-01XX phone number.

Go Up