DL-IP-Koordination - en:hamnet

as-nummern

Anonymous (anonymous@undisclosed.example.com) — 2020-12-09T20:11:17+00:00

AS-Numbers in European HAMNET

Every Autonomous System (AS) must have an unambiguously single number which is called AS-number (ASN).An Autonomous System is a network or a group of networks with a common routing policy. They often have one group of administrators. Main parts of an Autonomous System are the existing core-routers.

16-bit-AS-Numbers

16-bit-AS-Numbers (ASN) have an integer-range of 0-65536. That corresponds to 65536 possible AS-numbers. The range of 1 to 64511 is used within the internet. Private AS-numbers are only allowed to be used within an organization in separated private networks). Their range has to be within 64512 to 65534. The European HAMNET is such a separated network. In the year 2009 there has been an agreement between the participating European Countries for the use of 16-bit AS-numbers in the European HAMNET. The private range 64512-65534 was coordinated as follows (source: OEVSV:Digitaler Backbone (german)):

Country	16-bit-AS-Range	Last Update
Austria	64512 - 64599	24.06.2016
Italy	64600 - 64619	01.10.2009
Germany	64620 - 64683	01.10.2009
Luxemburg	64684 - 64685	01.10.2009
Netherlands	64686 - 64704	27.02.2016
Hungary	64705 - 64707	01.10.2009
Spain	64708 - 64719	01.10.2009
Switzerland	64720 - 64739	24.06.2012
Liechtenstein	64740 - 64741	25.06.2012
France	64742 - 64777	13.04.2013
Belgium	64778 - 64788	26.09.2013
Turkey	64789 - 64799	26.09.2013
Poland	64800 - 64839	04.11.2013
Romania	64840 - 64849	09.02.2014
Portugal	64850 - 64854	04.03.2015
Slovenia	64855 - 64864	07.12.2015
Croatia	64865 - 64873	27.02.2016

In German HAMNET these 16-Bit-as-numbers are not used primarily for technical BGP-routing but for optimizing regional structuring.

32-bit-AS-Numbers

32-bit AS-Numbers are used in German HAMNET since end of 2015. In 2015 after some discussion in the Net-44 mailinglist there was a proposal and international agreement for using private 32-bit AS-Numbers in whole AMPRNet. Splitting up the available range to individual countries depends on the „International Numbering Plan for Public Data Networks“ (X.121 Document) and the „List of Mobile Country Codes“ (E.212 Document) of the ITU. This is a list of assignments of local 32-bit-AS-Numbers in the European HAMNET (abstract):

	Country	32bit-ASN Block	Country Codes X.121	Status
OE	Austria	4223200000-4223399999	232-233	HamnetDB
I	Italy	4222200000-4222499999	222-224	HamnetDB
DL	Germany	4226200000-4226599999	262-265	HamnetDB
LX	Luxemburg	4227000000-4227099999	270	HamnetDB
CR	Croatia	4221900000-4221999999	219	HamnetDB
PA	Netherlands	4220400000-4220599999	204-205	HamnetDB
HA	Hungary	4221600000-4221699999	216	HamnetDB
EA	Spain	4221400000-4221599999	214-215	HamnetDB
HB	Switzerland	4222800000-4222999999	228-229	HamnetDB
HB0	Liechtenstein	4229500000-4229599999	295	HamnetDB
F	France	4220800000-4221199999	208-211	HamnetDB
ON	Belgium	4220600000-4220699999	206	HamnetDB
TA	Turkey	4228600000-4228699999	286	to be generated
SP	Poland	4226000000-4226199999	260-261	HamnetDB
YO	Romania	4222600000-4222699999	226	HamnetDB
CT	Portugal	4226800000-4226999999	268-269	HamnetDB
S5	Slovenia	4229300000-4229399999	293	HamnetDB

In European HAMNET 16-bit and 32-bit as-numbers are used in parallel. Every country may have its own policies for deploying 32-bit-as-numbers out of their own as-range..

more Informations:

<-- Back

bgp-policy

Anonymous (anonymous@undisclosed.example.com) — 2020-12-09T20:15:41+00:00

BGP Routing Policy

Experience of the last years show up that a single Parent-AS shouldnot contain more than 16 locations or sites. Otherwise clarity in management is getting difficult and the amount of assigned free ip-subnetworks might be running up. In such a case it would be wise to request a new parent-AS at the IP-Coordiantion DL. There are still some free resources in the pool right now.

POLICY: In European HAMNET routing-informations between every AS are handled by eBGP-routing.
POLICY: Within a single AS other routing-protocols might be in use. If a single AS has more than 1 AS-neighbor, it is absolutely essential that the border-routers (eBGP) transmit identical routing-informations to every neighbor.
POLICY: In every case loops and flapping routes have to be prevented by suitable, technical measures.
POLICY: In the German HAMNET we prefere „Site-to-Site eBGP“ using the 32-bit AS-numbers for technical routing.

BGP-Confederations

At the end of the german 16-bit-AS range we have a reservation for as-internal bgp-confederation setups (65510-65534). It can be used for some as-internal testings, e.g. routing-exchange within a confederation via iBGP. Parent-AS-maintainers have to be very carefull NOT to announce any internal as-confederation-numbers to their neighbors via eBGP on the border-routers! Internal routing informations have to be announced with the external AS-number of the confederation-group. Confederation-AS-numbers are not exclusively assigned to a single AS. So they have to be filtered out (import and export) at the border-routers of any Parent-AS.

POLICY: Confederation-AS-numbers should never appear in an AS-path of the own AS.
POLICY: eBGP Router are advised to filter out local-test-AS (in und out) to keep those things local.

IP-Coordination Germany advises urgently, NOT to use BGP-confederations within the German HAMNET becasue of some issues in commonly used routers and some other unpredictable side-effects. Version 1.00-2019-12-31

<-- Back

dns-system

Anonymous (anonymous@undisclosed.example.com) — 2020-12-09T20:09:02+00:00

The DNS-System in German HAMNET

DNS-Hubs

Core of the DNS-system in German HAMNET consists of three so called DNS-Hubs. They are located at three different locations in DL with excellent technical and physical accessability. DNS-Hubs are interconnected with redundand and fast internet-tunnels. They sum up the complete german subzone-concept which is related to the parent-AS-regions. IP-Coordination Germany maintains a Net-44-interface for correctly transfering all the subdomains into the worldwide „flat“ ampr.org domain. Our DNS-Hubs answer any requests from HAMNET-clients, not only for our regional zones or for flat ampr.org zone. This assures a very simple DNS-concept to be created in the local as-regions. In most cases it's enough to set up a simple cache-dns as main dns-server inevery parent-as. At local sites there could be more cache-dns, which are connected to the parent-as's dns as their „master“. Then the local site-dns will serve every client-request generated at the local site. The existing Mikrotik-routers at any site can easily take over those tasks.

Internet
MASTER-DNS
CNAME
ns.ampr.org

<name>.ampr.org
transfer into
Net-44 Interface
<name>.as64xxxyy.de.ampr.org

<name>.as64xxxyy.de.ampr.org
DNS-Hub WEST
CNAME
dl-west.ampr.org

<name>.as64xxxyy.de.ampr.org
DNS-Hub SUED
CNAME
dl-sued.ampr.org

<name>.as64xxxyy.de.ampr.org
DNS-Hub OST
CNAME
dl-ost.ampr.org

Workflow

Bottom/Up

Zone-maintainers from any parent-AS have 2 options to feed their own dns-entries into the world. Option 1 normaly is default. Option 2 requires very good knowledge in setting up authoritative dns-servers. Local admins must exactly know what they are doing. An initial one-time-consultation with IP-Coordination Germany is essential in getting option 2 up and running.

Option	Procedure
1. HamnetDB	Admins from parent-as feeding dns-data into the HamnetDB
2. Auth-DNS	Maintaining a master-Auth-DNS in the parent-as with connecting to a DNS-Hub

learn more

Informations about naming of host- and zones in a german AS
Important hints for registering of personal callsigns in the German DNS-system (sorry, still in german…)
Tips for maintaining an Auth-DNS in a Parent-AS (sorry, still in german …)
Tips for maintenance of DNS-data into HamnetDB

For both options automatic transfer of DNS-data from out of HAMNET up to highest instance, the DNS-master for AMPR.ORG is ensured. Distribution within Germany is done with the DNS-hubs, distribution into the flat ampr.org domain is done automagically by IP-Coordinations's Net-44-interface. Regional AS-maintainers do not need to care about further distribution of their dns-data. Zone-transfer at the DNS-Hubs is done by NOTIFYing each other immediately when some data have been changed at any site. So there is very low latency in maintaining DNS-data within German HAMNET.

TopDown

Locale DNS-servers at a specific site get all their dns-informations from their „master-dns“ in the corresponding parent-as. There is no need to multiple transfer any zonefiles across all the country. DNS-traffic is limited on the local rf-interlink-structures in the own region which makes everything fast and safe.

As all the 3 DNS-Hubs are directly connected to internet, every connected parent-AS's master can resolve any wordlwide domainnames and ip-addresses and so do the connected local site-dns as well, even when the whole AS has no local internet access.

<-- Back

dnsnames-hamnet

Anonymous (anonymous@undisclosed.example.com) — 2020-12-09T20:05:11+00:00

Host- and Domainnames in a German AS

Every parent-AS manages ip-address and domain-name-space for all connected sites on its own. This needs a split of the german name-space into 6-7 dns-zonesfiles per parent-AS dependent of the amount of assigned networks. These zones are used in the DNS-system to resolve forward and reverse all of the to a parent-AS assigned networks. The syntax for deploying names within zones is not trivial because of the subsequent transfer into the flat ampr.org domain which has its own amount of policies.

Following example shows a FQDN (Full Qualified Domain Name) for a rf-interlink-device from DB0RES to DB0EEO at the site of DB0RES which is in the autonomous system with AS-number 64627 (KLEVE-627-AS):

       trx-eeo.db0res.as64627.de.ampr.org
       |       |      |       |  +-------  DOMAINNAME for international AMPRNET (44.0.0.0/9 + 44.0.0.0/10)
       |       |      |       +----------  COUNTRY in AMPRNET (possibility of real Delegation in internet!)
       |       |      +------------------  ZONENAME of an AS (differentiation of AS-zones)
       |       +-------------------------  CALLSIGN of the site within parent-AS
       +---------------------------------  HOSTNAME of a device, service, router, IP-powerplug etc.

FQDN in German HAMNET

DOMAINNAME

AMPRNET^tm is organized in the flat „ampr.org“ domain. This domain is hosted in internet. Resolving names of hosts all over the world is possible even when concerning hosts have no routing to each other. The DNS-system is functional for FORWARD and REVERSE resolving. This is a great advantage when doing traceroutes or other stuff for debugging the net. IP-Coordination Germany translates all local FQDN into the flat shortform the „ampr.org“-domain needs. Therefor some requirements have to be taken into consideration. The advantage is that all HAMNET-hosts are resolveable all over the world, even for users who don't have access to the original HAMNET-DNS-servers. Another advantage is the „shortness“ of the fqdn within the flat ampr.org domain. Users within the HAMNET can address a host with ist long or its short fqdn. Using reverse resolver in HAMNET (e.g.with traceroute) always delivers the long fqdn of the host. This gives pretty debugging information, e.g. through what AS and sites the signal is proceeding and what AS the host finally belongs to. In case of any issues at any step of the path you could easily address the responsible persons after a short whois-search. Our gateways within AMPRNET^tm enable HAMNET to be accessible for all hams around the world participating in the AMPRNet^tm.

Take a look at a short traceroute through HAMNET to a specific router:

dd9qp@db0res-pc:~$ traceroute router.db0gw.ampr.org
traceroute to router.db0gw.ampr.org (44.149.137.1), 30 hops max, 60 byte packets
 1  wan-gw.db0res.as64627.de.ampr.org (44.149.30.1)  0.222 ms  0.175 ms  0.151 ms
 2  hamnet-rf-in.db0res.as64627.de.ampr.org (44.148.14.245)  0.297 ms  0.271 ms  0.304 ms
 3  bb-db0res.db0wes.as64627.de.ampr.org (44.148.14.14)  1.568 ms  2.715 ms  2.691 ms
 4  bb-db0wes.db0mo.as64646.de.ampr.org (44.148.52.6)  5.343 ms  5.319 ms  5.295 ms
 5  bb-db0mo.db0hsn.as64646.de.ampr.org (44.148.53.129)  7.199 ms  7.176 ms  7.150 ms
 6  router.db0gw.as64654.de.ampr.org (44.149.137.1)  7.122 ms  5.915 ms  10.127 ms

You can see the long fqdns and find out that in this example the signal is passing through three Parent-AS. In case of anny ussue at any step you can directly find out the responsible persons who eventually can help in resolving any issues

COUNTRY

Country announces the origin of the dns-entry. It mainly is an investment into the future. It enables delegation of the country-zones on special country-dns-masters in internet in the future. This draws an independent administration of dns-entries into the horizont of possibilities. It also allows a more effective usage of special records in the dns-system (MX, CNAME, TXT, Geodata etc) for the national administration.

ZONENAME

Zonename korresponds to the AS-number of the parent-AS the zone-data belongs to. RFC forbids usage of simple digit sequences in dns-subdomains. Therefor the as-number has been completed with the „as“.At this point the sub-domain for a HAMNET-Parent-AS has been exactly described. Everything that is added to this entry belongs undoubtedly to this parent-AS.

CALLSIGN

A parent-AS normally consists of several interconnected sites containing digis, d-star-repeaters, atv-repeaters, echolink systems, clubstations etc. Nearly all of the sites have a special callsign for automatic stations which was assigned by the Bundesnetzagentur (BNetzA), our German Licence Authority. So the site-callsign is the next unit to be added in the dns-name. If only one device would be present at the site, this callsign would be the hostname in the fqdn. But it isn't, normaly there are a lot of different ip-devices present at one single site. Something more has to be added…

HOSTNAME

Hostname is the identifier for a specific device located at a site in the parent-AS. Hostnames can identify services the device provides (e.g. WWW), or identify the special function the device has (e.g. router) or identify other devices (e.g Camera, PC …). So the device-identifier has to be added in front of the callsign, separated by a dot.

Net-44 Interface

IP-Coordination DL maintains a special Net-44 Interface. This is the link between the flat ampr.org domain and the subdomain-based zone-concept in the German HAMNET. FQDN-hostnames from the German HAMNET have to be transformed into the flat ampr.org namens. Entries corresponding to the policies of the flat ampr.org structure are loaded into the worldwide dns-system. Invalid entries are blocked and returned to the as-maintainers in order to correct them.

Valid Examples for FQDN in German HAMNET

A www- or news-server at DB0RES may have following fqdn:

www.db0res.as64627.de.ampr.org  -- transforms to -> www.db0res.ampr.org
news.db0res.as64627.de.ampr.org -- tramsforms to -> news.db0res.ampr.org

Some more examples:

db0shg-router1.as64636.de.ampr.org -- transforms to -> db0shg-router1.ampr.org
webcam-db0sha.as64636.de.ampr.org  -- transforms to -> webcam-db0sha.ampr.org
db0res-svr.as64627.de.ampr.org     -- transforms to -> db0res-svr.ampr.org

POLICY: A FQDN-name in German HAMNET has to be chosen in a way that the licenced callsign still is remaining in the fqdn after the transformation into the flat ampr.org has been finished.

Invalid Examples for FQDN in German HAMNET

The automatic transformation of all DNS-entries into the flat „ampr.org“-Domain comprises some restrictions in choosing the name-identifiers. Name-identifiers that do not contain any callsign after transformation into flat ampr.org cannot be exactly identified in other parts of the ampr.org-world. There is the danger that existing entries in the ampr.org-zone could be overwritten or some fakes/doubles could be created. Entries of that kind will not be transformed automagically. See some forbidden examples:

router.as12345.de.ampr.org  <- would be transformed to -> router.ampr.org (FORBIDDEN! MAY BE EXISTING!)
im4ham.as12345.de.ampr.org  <- would be transformed to -> im4ham.ampr.org (FORBIDDEN! MAY BE EXISTING!)
www.as12345.de.ampr.org     <- would be transformed to -> www.ampr.org (FORBIDDEN!/ALREADY EXISTS!)
www.54321.de.ampr.org       <- would be transformed to -> www.ampr.org (FORBIDDEN!/ALREADY EXISTS!)
hamgate.as12345.de.ampr.org <- would be transformed to -> hamgate.ampr.org (FORBIDDEN! AMBIGUOUS!)

POLICY: All entries must be unambiguous and not creating fakes or doublettes after they are transformed into flat ampr.org. This can be guaranteed by using the exclusively existing callsigns in fqdn.

Registering personal Callsigns in German HAMNET-DNS

In Germany personal callsigns must be handled in a special manner because of existing laws for data integrity and transfering data into Non-EU-Countries (DSGVO). This is the case when dns-data is transfered to the US- or GB-master-dns and spread throughout the worlds most common dns-servers, e.g. Google and others. That is why in Germany transfering personal callsigns is not starting automagically at the Net-44-interface. Callsign-owner has to opt-in at the IP-Coordination Germany before the transformation process can be started. Another reason is that in most cases personal callsigns are not necessary anymore for using HAMNET ressources. There are some essential informations about opting-in for german users only:

Datenschutzerklärung zum Eintrag persönlicher Rufzeichen in das DNS-System (sorry, german only)

<-- Back

dnssetup-hamnet

Anonymous (anonymous@undisclosed.example.com) — 2020-12-09T20:13:19+00:00

Einrichtung und Betrieb von Auth-DNS-Servern

Die Einrichtung und der Betrieb eines Auth-DNS-Servers für ein Parent-AS erfordert erhöhte Kenntnisse über Netzwerktechnik, das eingesetzte Betriebssystem und Erfahrungen zur Einrichtung von Serverdiensten. Die IP-Koordination DL empfiehlt die Einrichtung von Auth-DNS nur, wenn in dem Parent-AS ausreichend Kenntnisse darüber vorhanden sind und auch nachhaltig auf geeignete Sysadmins zurück gegriffen werden kann.

Allgemeine Anforderungen

Vorausgesetzt seien:

ein 64bit-fähiger Rechner oder eine VM auf einem lokalen Hostsystem
Betriebssystem Linux (z.B. Debian, Raspbian, Ubuntu)
konfigurierter, funktionsfähiger IP-Stack
root Rechte auf dem Rechner oder der VM
ein installierter BIND9 als DNS-Server

Grundkonfiguration

Die Bind-Konfigurations-Datei steht bei Debian und Debian-ähnlichen Betriebssystemen unter „/etc/bind/named.conf“. In ihr befinden weitere Verweise auf Konfigurationsdateien mit Konfigurations-Parametern wie

standalone, forwarders, Access-Listen, etc..
Timing-Parameter
Logging
Zonen (master, slave, Filename, Pfade dorthin)
etc..

Wenn in einem Parent-AS die eigene Zone verwaltet werden soll, sind die Daten in entsprechenden Zonen-Dateien für Vorwärts- und Rückwärts-Auflösungen abzulegen und zu pflegen. Für diese Zonen ist der DNS dann MASTER-DNS. Diese Zonendaten werden automatisch an den zuständigen DNS-Hub gemeldet, der sie sofort an alle anderen Systeme im HAMNET ausliefern kann. Gleichzeitig benötigt der Auth-DNS einer Zone aber auch Kenntnis über alle anderen verfügbaren Zonen im HAMNET. Die holt er sich auch vom zuständigen DNS-Hub. Für diese Zonen ist der Auth-DNS dann SLAVE-DNS. Fremde Zonen können sich jederzeit ändern, entfallen oder neue hinzugefügt werden.

Die IP-Koordination DL hat ein automatisiertes, script-gesteuertes Verfahren entwickelt, mit dem lokale Auth-DNS automatisch auf Veränderungen im DNS-Netz angepasst werden. Die hierzu erforderlichen Scripte und Steuerdateien werden von der IP-Koordination DL gepflegt und auf verschiedenen Wegen zur Verfügung gestellt.

DNS-Server auf einem Auth-DNS konfigurieren

<-- Zurück