Under TRRP, Ingress Tunnel Routers (ITRs) cache protocol and egress information for each destination IP address which transits the router. This fails to take advantage of subnetting knowledge where a set of egress information is valid for a range of IP addresses. The Netmask Identifier for TRRP offers a way for an ITR reduce the number of routes it has to cache by seeking and retaining the complete set of egress information for a particular netmask.
DNS Route Specifier:
TRRP specifies routes via DNS TXT records in the format "pp,ii,route pp,ii,route ..." where pp is a hexadecimal priority, ii is a protocol Identifier and route is the egress information needed by the Identifier.
Identifier: nm = Netmask. There may only be one Netmask Identifier in the DNS Route. If more than one is offered, the ITR should ignore all of them.
Priority: the priority for the "nm" identifier should always be "ff". An ITR should ignore the priority of the nm identifier regardless of its setting.
Route: The "route" parameter offers the netmask from which the zone should be constructed. It is a base-10 integer between 0 and 31 for IPv4 addresses and between 0 and 127 for IPv6 addresses. The number indicates the count of "1" digits in the netmask's base-2 representation.
Example:
The ITR makes a DNS TXT request for 1.101.168.192.v4.trrp.arpa. It receives one TXT record in response:
80,g4,1.2.3.4 ff,nm,23
This means that the DNS Route server has advised the ITR that everything in 192.168.100.0/23 shares the same routes.
How to do a netmask lookup:
The ITR may not trust a DNS Route response which claims a netmask. A hacker could claim a netmask of "0" causing the ITR to send all Internet traffic to him. Instead, the ITR uses the netmask to construct a second DNS Route query which authoritatively confirms the netmask's validity.
The DNS zone which will contain authoritative information about the netmask is the one at the next shorter zone boundary for the offered netmask. That means the next smaller number evenly divisible by 8 for IPv4 or by 4 for IPv6.
Examples:
192.168.101.1/23. Next shorter boundary divisible by 8 is /16, yielding the zone
168.192.v4.trrp.arpa
2000:5678::1/22. Next shorter boundary divisible by 4 is /20, yielding the zone
5.0.0.0.2.v6.trrp.arpa.
Add "nm" on to the front of the name to avoid following the a delegation path which leads out of the authoritative zone. Next, add what would be the next relevant "network address" component to the name. That's the byte (IPv4) or 4-bits (IPv6) at the next position in the address after applying the netmask.
Examples:
192.168.101.1/23. Apply /23 netmask: 192.168.100.0. The "next" byte is 100
yielding the zone 100.nm.168.192.v4.trrp.arpa.
2000:5678::1/22. Apply /22 netmask: 2000:5400::. The next 4 bits offered in hexadecimal is
"4", yielding the zone 4.nm.5.0.0.0.2.v6.trrp.arpa.
Finally, add the netmask itself to the front as a decimal number.
Examples:
192.168.100.1/23 yields the zone 23.100.nm.168.192.v4.trrp.arpa.
2000:5678::1/22 yields the zone 22.4.nm.5.0.0.0.2.v6.trrp.arpa.
The result of the TXT query for the constructed name is expected to be a set of TRRP protocol identifiers including a "nm" entry.
When to do a Netmask lookup:
When an ITR receives a DNS Route which contains a netmask in a "nm" Identifier, it should cache the fact that a netmask is claimed to cover the specified range of addresses. When the ITR next receives packet for a destination which is not yet cached but which falls within the same netmask, it should make the normal TRRP lookup and constructed netmask lookup in parallel. If the netmask lookup request returns a valid DNS Route with the correct "nm" Identifier then the ITR should cache the route and netmask, discarding any more specific cached routes. Regardless of whether the netmask lookup is successful, the cached zone "claim" from the first request should be discarded.
If the ITR receives a host-unreachable message for any of the specified ETRs, it must immediately recheck the zone's SOA at the authoritative servers regardless of the TTL. Such rechecks should be rate limited to once every 5 seconds to avoid DOSing the authoritative server.