FAQ - Reserved Characters/Names - SSID/Passwords/Hostnames/Domains

[sfx2000]

Maintaining/updating this list - I've tried to capture most of the characters/words/ranges to avoid - if there are more, please reply to this thread and I'll update the list...

Changelist

08/9/22 - update for Thread IOT reserved HLD's (.home, .service)
08/11/19 - quick update about reserved domains and clarification on IP ranges for IPv4/IPv6
06/30/18 - let's talk about localhost/LOCALHOST - not good there - added comment on 1.1.1.1 and the cloudflare public DNS item.
06/23/17 - updated Link Local Ranges, SSID warnings for spaces/emoji chari
11/15/18 - clarification about private TLD's - safe to use .home, .corp, .mail for private TLD's as per ICANN, no conflict with public internet and TLD's there.
11/15/18 - clarification on characters - (+) sign is ok, but not recommended for certain identifiers
11/15/18 - mDNS (Bonjour/Avahi and .local) section added

========

This pops up often enough to be a General FAQ across SNB areas of interest...

Machine/Hostnames/SSID/Passwords - US-ASCII-7 A-Z/a-z/0-9 - Avoid ISO-Latin/UTF characters outside of the US-ACSII-7 character set

Note - with newer clients/AP's - UTF-8 may be supported - however for interoperability with clients, stick to US-ASCII-7 character set - test as needed.

(edit - that includes excluding emoji's ok, so please stop asking, some might think this is cool/cute, but no standards for what they mean or do across different platforms so what works for one OS/Platform might be represented differently on another platform)

Caveats;

• First and Last Characters must not be a Period (.)
• First Character must be an Alphabet or Numeric Character
• Last Character must not be a Period (.) or a Minus Sign (-)
• Underscore (_) has special purposes if first character - defines SRV records in DNS
• Spaces can be a problem for SSID's with some clients

Special note for Windows Clients/Servers (including Samba for Router/AP shared disks and NAS units);

• A period character separates the name into a NetBIOS scope identifier and the computer name.
• The NetBIOS scope identifier is an optional string of characters that identify logical NetBIOS networks that run on the same physical TCP/IP network. For NetBIOS to work between computers, the computers must have the same NetBIOS scope identifier and unique computer names.

General Reserved Characters - these mean things across Windows/Mac/UNIX platforms, so avoid using them for domains/workgroups/hostnames/usernames/passwords/SSID's

• ampersand (&)
• apostrophe (')
• asterisk (*)
• at sign (@)
• backslash (\)
• braces ({})
• caret (^)
• colon ( : )
• comma (,)
• dollar sign ($)
• exclamation point (!)
• greater than sign (>)
• less than sign (<)
• number sign (#)
• parentheses (())
• percent (%)
• period (.)
• question mark (?)
• quotation mark (")
• slash mark (/)
• tilde (~)
• underscore (_)
• vertical bar (|)
• white space (blank)

NOTE - plus sign (+) It is valid for email and SMTP transport for username, e.g. "username+item@example.org" - as an identifier for items outside of email, it's up to the application developer to case this, as "+" (plus sign) can mean things in code if not handled correctly, similar to the exceptions noted above

Specific Machine/Host/User Names to avoid;

this is mostly focused on Windows, but in a cross platform environment, consider Samba and SMB clients - may not be case specific here, so just avoid them. Mixed case or not, just don't use these names...

• localhost - yes, some clients use this, and it breaks things hard #samsung
• LOCALHOST - see above
• ANONYMOUS
• AUTHENTICATED USER
• BATCH
• BUILTIN
• CREATOR GROUP
• CREATOR GROUP SERVER
• CREATOR OWNER
• CREATOR OWNER SERVER
• DIALUP
• DIGEST AUTH
• INTERACTIVE
• INTERNET
• LOCAL
• LOCAL SYSTEM
• NETWORK
• NETWORK SERVICE
• NT AUTHORITY
• NT DOMAIN
• NTLM AUTH
• NULL
• PROXY
• REMOTE INTERACTIVE
• RESTRICTED
• SCHANNEL AUTH
• SELF
• SERVER
• SERVICE
• SYSTEM
• TERMINAL SERVER
• THIS ORGANIZATION
• USERS
• WORLD
• WPAD
• ISTAP

Specific IP ranges;

IPv4 Private Networks - these you can use on your private network - they're non-public

192.168.0.0/16
172.16.0.0/12
10.0.0.0/8​

IPv4 Link Local Addresses - this is handy if you need to do IP on a single span, and not jump out to public internet or across local networks if VLAN'ed;

169.254.0.0/16​

IPv6 private ranges - fe80::/10 behaves same as IPv4 Link-Local

Private - fd00::/8
LinkLocal - fe80::/10
​

Carrier Grade NAT - avoid using this one

100.64.0.0/10
​

# Added LinkLocal addr's to the keepout ranges below

Keepout Ranges;

IPv4

1.1.1.1/8 - this is a bit complicated, many captive portals use this for redirection, but this is now a public DNS - was 'reserved' by APNIC, but not official
0.0.0.0/8 - Used for broadcast messages to the current network
127.0.0.0/8 - loopback addresses
100.64.0.0/10 - Carrier Grade NAT
169.254.0.0/16 - Link Local Range Ref - RFC3297
192.0.0.0/24 - Special Purposes for IANA registry
192.0.2.0/24 - TEST-NET - only for documentation - should never be used
192.88.99.0/24 - 6to4 anycast relays
198.18.0.0/15 - used for testing of internetwork communications across different subnet
198.51.100.0/24 - TEST-NET-2 - documentation purposes - should never be used
203.0.113.0/24 - TEST-NET-3 - documentation purposes - should never be used
224.0.0.0/4 - Reserved for future Multi-cast assignments
233.252.0.0/24 - MCAST-TEST-NET - documentation purposes - should never be used
240.0.0.0/4 - Reserved for future use - see IETF RFC6890
255.255.255.255/32 - reserved for limited broadcast destination address​

IPv6

::/128 - unspecific address
::1/128 - loopback
::ffff:0:0/96 - IPv4 mapped addresses
100::/64 - discard prefix
64:ff9b::/96 - IPv4/IPv6 translation range
2001::/32 - Teredo Tunneling
2001:10::/28 - ORCHIDv1 - depreciated, but keep out
2001:20::/28 - ORCHIDv2
2001:db8::/32 - documentation purposes
2002::/16 - 6to4 range
fc00::/7 - ULA
fe80::/10 - IPv6 Link Local Addressing
ff00::/8 - multicast
​

Reserved Top Level Domains - see http://www.ietf.org/rfc/rfc6761.txt

This is focused more on scripters/3rd party devs/folks working with VPN clients...

The big ones that might not be entirely obvious is .local, .onion, .invalid, and .test - this is especially important if working with unicast DNS and other items that might be dependent on local service discovery (might also be on strong interest to those doing VPN or ipset lists).

Name Reference
10.in-addr.arpa. [RFC6761]
16.172.in-addr.arpa. [RFC6761]
17.172.in-addr.arpa. [RFC6761]
18.172.in-addr.arpa. [RFC6761]
19.172.in-addr.arpa. [RFC6761]
20.172.in-addr.arpa. [RFC6761]
21.172.in-addr.arpa. [RFC6761]
22.172.in-addr.arpa. [RFC6761]
23.172.in-addr.arpa. [RFC6761]
24.172.in-addr.arpa. [RFC6761]
25.172.in-addr.arpa. [RFC6761]
26.172.in-addr.arpa. [RFC6761]
27.172.in-addr.arpa. [RFC6761]
28.172.in-addr.arpa. [RFC6761]
29.172.in-addr.arpa. [RFC6761]
30.172.in-addr.arpa. [RFC6761]
31.172.in-addr.arpa. [RFC6761]
168.192.in-addr.arpa. [RFC6761]
254.169.in-addr.arpa. [RFC6762]
8.e.f.ip6.arpa. [RFC6762]
9.e.f.ip6.arpa. [RFC6762]
a.e.f.ip6.arpa. [RFC6762]
b.e.f.ip6.arpa. [RFC6762]
example. [RFC6761]
example.com. [RFC6761]
example.net. [RFC6761]
example.org. [RFC6761]
invalid. [RFC6761]
local. [RFC6762]
localhost. [RFC6761]
onion. [RFC7686]
test. [RFC6761]​

Multicast DNS, aka Bonjour, Avahi

This technology uses the .local as domain name, and the UDP/5353 port for service discovery and resolution - avoid using .local or UDP/5353 for other purposes

Safe Private Domains - as per ICANN agreement - these can safely be used without conflict with public TLD's

.home - deprecated due to Thread (see below)
.corp
.mail
​

While RFC6762 suggests that "private", "internal", "intranet", and "lan" - the verbiage is 'should', ICANN has only agreed to the TLD's mentioned above

.lan - becoming more common as OEM and FOSS distro's (OpenWRT, etc) are starting to default here

Avoid the following Private Domains

.local - conflicts with Avahi/Bonjour
.onion - conflicts with TOR at application level
.invalid - conflicts with other embedded firmware
.test - conflicts with other embedded firmware​

Set asides for OpenThread - updated 08/09/22

Reference - Permissionless Advertising and Discovery of DNS-SD Authoritative Zones
draft-tljd-dnssd-zone-discover-00

.service
.home
​

=========

I'll remind folks about the multi-cast blocks - 240.0.0.0/4 and 224.0.0.0/4 blocks (multicast ranges) - these are special cased...

Zeroconf uses the APAIA ranges (with CIDR this is a lot) but generally 169.254.0.0/16 as a block to keep out of for internet purposes - this is a private Class B block, but they're link-local only and cannot be routed outside of the local subnet, many clients may use that block, and any IP's within that block, first for DHCP requests/assignments.. at least with Windows machines...

That being said - that block is reserved for link-local access - so that is an option for a stand-alone network outside of the internet.

Hope this helps out folks - these are basically keepout zones for assigning addresses, but also useful when digging thru packet captures while debugging.

 

[davidstoll]

The plus (+) character is not referenced here, but is a valid character for email addresses. Can you please see this thread and take a look at fixing/allowing the use of the + symbol please?

https://www.snbforums.com/threads/vpn-client-bug.49831/

Thank you

 

[davidstoll]

It is accepted by the VPN provider. My email (with a plus) is the login. Can the firmware be fixed to transmit my login correctly?

 

[Magebarf]

One thing that I've noticed is that the private IP address ranges are not fully blocked off with regards to RADb etc., so for reverse dns lookups I have come across (and poked until they fixed it) some registered ip ranges which should not exist. In my case it was the 172.18.x.x range that showed up as part of an AS entity.

 

[Magebarf]

Actually, 172.18.x.x is within the Class B range of private IPv4 addresses, which goes from 172.16.x.x up to 172.32.x.x.

Unsure if we're differing on any of the semantic here, or if it's just terminology differing, but in my view the private IP ranges should definitely be protected when it comes to things like global routing databases. They should not be protected from use, and just as written in the main post is intended for use in private networks, but having a reverse DNS result for them popping up, showing as part of a AS, goes quite a bit against the point of the private ranges.

Edit: After more thinking about what your point may be; Yes, you are correct, as in the context of the entire post, it is not a reserved/protected IP in the sense that it's free to use for any LAN at home.

The point I initially tried to make was that even when moving within ranges that are intended for private use, you may encounter some "registered" blocks of IP addresses, as the routing DBs, used among others for reverse DNS, does not always check if a block is within the private ranges when registering it.

 

[umarmung]

172.18.x.y is not a protected range - so it can be allocated...

172.18.x.y is well within 172.16.0.0/12

Actually, 172.18.x.x is within the Class B range of private IPv4 addresses, which goes from 172.16.x.x up to 172.32.x.x.

172.16.0.0/12 block ends at 172.31.255.255

 

[sfx2000]

IPv4 Private Networks - these you can use on your private network - they're non-public

192.168.0.0/16
172.16.0.0/12
10.0.0.0/8

So here... Enough said about this...

$ ipcalc 192.168.0.0/16
Address:   192.168.0.0          11000000.10101000. 00000000.00000000
Netmask:   255.255.0.0 = 16     11111111.11111111. 00000000.00000000
Wildcard:  0.0.255.255          00000000.00000000. 11111111.11111111
=>
Network:   192.168.0.0/16       11000000.10101000. 00000000.00000000
HostMin:   192.168.0.1          11000000.10101000. 00000000.00000001
HostMax:   192.168.255.254      11000000.10101000. 11111111.11111110
Broadcast: 192.168.255.255      11000000.10101000. 11111111.11111111
Hosts/Net: 65534                 Class C, Private Internet

$ ipcalc 172.16.0.0/12
Address:   172.16.0.0           10101100.0001 0000.00000000.00000000
Netmask:   255.240.0.0 = 12     11111111.1111 0000.00000000.00000000
Wildcard:  0.15.255.255         00000000.0000 1111.11111111.11111111
=>
Network:   172.16.0.0/12        10101100.0001 0000.00000000.00000000
HostMin:   172.16.0.1           10101100.0001 0000.00000000.00000001
HostMax:   172.31.255.254       10101100.0001 1111.11111111.11111110
Broadcast: 172.31.255.255       10101100.0001 1111.11111111.11111111
Hosts/Net: 1048574               Class B, Private Internet

$ ipcalc 10.0.0.0/8
Address:   10.0.0.0             00001010. 00000000.00000000.00000000
Netmask:   255.0.0.0 = 8        11111111. 00000000.00000000.00000000
Wildcard:  0.255.255.255        00000000. 11111111.11111111.11111111
=>
Network:   10.0.0.0/8           00001010. 00000000.00000000.00000000
HostMin:   10.0.0.1             00001010. 00000000.00000000.00000001
HostMax:   10.255.255.254       00001010. 11111111.11111111.11111110
Broadcast: 10.255.255.255       00001010. 11111111.11111111.11111111
Hosts/Net: 16777214              Class A, Private Internet

 

[sfx2000]

Actually, 172.18.x.x is within the Class B range of private IPv4 addresses, which goes from 172.16.x.x up to 172.32.x.x.

There's a thing called bogons and martians...

BGP - Bogons and Martians - Network Direction

Can packets come from Mars? Or is it all a conspiracy? If think you may need to filter Bogons and Martians, this is for you...

networkdirection.net

What are Bogons and Martians?

Put simply, a Bogon Network is a bogus or invalid network. These networks are sometimes called martians, as they might as well have come from Mars (where no valid networks exists; At least at the time of writing).

Bogon networks are invalid on the internet, as they are networks that have been reserved for special use, or have not yet been allocated to a customer. These networks should not be seen on the internet.

Some examples of reserved IPv4 networks are:

Private Networks (10.0.0.0 /8, 172.16.0.0 /12, and 192.168.0.0 /16)
Loopback Addresses (127.0.0.0 /8, ::1 /128)
Link-local Addresses (169.254.0.0 /16, FE80:: /10)
Initialisation Addresses (0.0.0.0 /8)

Scripters can add these to the block lists there with little risk, as these addresses should never be seen on the WAN side...

 

[sfx2000]

Safe Private Domains - as per ICANN agreement - these can safely be used without conflict with public TLD's


.home - deprecated due to Thread (see below)
.corp
.mail

While RFC6762 suggests that "private", "internal", "intranet", and "lan" - the verbiage is 'should', ICANN has only agreed to the TLD's mentioned above

.lan - becoming more common as OEM and FOSS distro's (OpenWRT, etc) are starting to default here

Avoid the following Private Domains

.local - conflicts with Avahi/Bonjour
.onion - conflicts with TOR at application level
.invalid - conflicts with other embedded firmware
.test - conflicts with other embedded firmware
Set asides for OpenThread - updated 08/09/22

Reference - Permissionless Advertising and Discovery of DNS-SD Authoritative Zones
draft-tljd-dnssd-zone-discover-00


.service
.home

Just a quick update - ICANN has agreed to reserve "internal" for private domain usage...