NON-Compliance with RFC1918, Address Allocation for Private Internets (why was 172.33.0.0/16 used?)

[lodotek]

DAppNode/scripts/dappnode_install.sh

Line 315 in ea9028a

docker network create --driver bridge --subnet 172.33.0.0/16 dncore_network 2>&1 | tee -a $LOGFILE

Who's idea was it to use 172.33.0.0/16 for the docker dncore_network?

Per RFC1918, the Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

172.33.0.0/16 is not a valid RFC1918 private network and should not have been used.
In fact, containers are being assigned IP addresses which are owned by T-Mobile
Example:

whois 172.33.1.5
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

refer:        whois.arin.net

inetnum:      172.0.0.0 - 172.255.255.255
organisation: Administered by ARIN
status:       LEGACY

remarks:      172.16.0.0/12 reserved for Private-Use Networks
remarks:      [RFC1918]. Complete registration details are found
remarks:      iniana-ipv4-special-registry.

whois:        whois.arin.net

changed:      1993-05
source:       IANA

# whois.arin.net

NetRange:       172.32.0.0 - 172.63.255.255
CIDR:           172.32.0.0/11
NetName:        TMO9
NetHandle:      NET-172-32-0-0-1
Parent:         NET172 (NET-172-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       AS21928
Organization:   T-Mobile USA, Inc. (TMOBI)
RegDate:        2012-09-18
Updated:        2020-11-18
Comment:        Geofeed https://raw.githubusercontent.com/tmobile/tmus-geofeed/main/tmus-geo-ip.txt
Ref:            https://rdap.arin.net/registry/ip/172.32.0.0



OrgName:        T-Mobile USA, Inc.
OrgId:          TMOBI
Address:        12920 SE 38th Street
City:           Bellevue
StateProv:      WA
PostalCode:     98006
Country:        US
RegDate:        2003-01-02
Updated:        2017-01-28
Ref:            https://rdap.arin.net/registry/entity/TMOBI


OrgAbuseHandle: ABUSE4857-ARIN
OrgAbuseName:   abuse
OrgAbusePhone:  +1-888-662-4662 
OrgAbuseEmail:  [email protected]
OrgAbuseRef:    https://rdap.arin.net/registry/entity/ABUSE4857-ARIN

OrgTechHandle: DNSAD11-ARIN
OrgTechName:   DNS Administrators
OrgTechPhone:  +1-888-662-4662 
OrgTechEmail:  [email protected]
OrgTechRef:    https://rdap.arin.net/registry/entity/DNSAD11-ARIN

[dapplion]

This comes from the original DAppNode POC, maybe @eduadiez can provide historical context on this decision.

@3alpha If we wanted to change this range, would that be doable with our current architecture? What would this migration look like in broad terms?

[3alpha]

It would be doable but the biggest issue is migration which will be critical as it can break everything. In broad terms:

1. Create new docker network to which dAppManager connects all containers in addition to the existing dncore_network network.
2. Update DNP_BIND package to DNP_BINDV2 so that DNS name resolution is done directly by docker. Make sure that dAppManager appends new aliases correctly to all packages
3. Change every hardcoded IP in every package to the new network range
4. Remove old dncore_network

What goes without saying is detailed testing between each step.

[3alpha]

Tracking with: dappnode/DNP_DAPPMANAGER#951