TRRP, like all map-request protocols, suffers from a slow initial packet round trip to and from the destination while both sides' ITRs look up a mapping in the DNS. This can be mitigated by optionally transmitting the initial packets through a long path consisting of a highly-aggregated set of waypoint routers until the direct map lookup completes. Just as the NS severs for .com tend to stay in a DNS resolver's cache, the waypoint routers for large swaths of the TRRP-routed address space will tend to already be available to the ITR allowing communication to start immediately.
Location of the DNS Route Specifier:
TRRP specifies routes via DNS TXT records in the format "pp,ii,route pp,ii,route ..." where pp is a hexidecimal priority, ii is a protocol Identifier and route is the egress information needed by the Identifier.
The waypoint path uses the same TXT records as the rest of TRRP, however they appear in a special location in the TRRP tree. Use the normal TRRP DNS tree up to the last digit within the netmask, add ".waypoint." to the name and finally add the netmask as a count of bits. For example:
| 0.waypoint.0.v4.trrp.arpa | Alternate path for any packets between 0.0.0.0 and 255.255.255.255 (0.0.0.0/0) |
| 1.waypoint.128.v4.trrp.arpa | Alternate path for any packets in 128.0.0.0 and 255.255.255.255 (128.0.0.0/1) |
| 8.waypoint.128.v4.trrp.arpa | Alternate path for any packets in 128.0.0.0 and 128.255.255.255 (128.0.0.0/8) |
| 16.waypoint.2.0.0.2.v6.trrp.arpa | Alternate path for any IPv6 packets in 2002::/16 |
Unlike regular TRRP DNS entries, waypoint entries should have a long time to live so that ITRs cache and keep them. When implementing a waypoint ETR, take care to assure high availability for both the equipment and the GR space in which it resides to accomodate this.
An ITR should increase any waypoint TTL under 60 minutes to exactly 60 minutes. No ITR should retain a waypoint entry for longer than 30 days, regardless of the offered TTL.
ITRs should attempt to store waypoint entries in non-volatile storage so that they are available immediately upon a restart.
00,wp,scope -- Waypoint Preference Scope.
WP specifies under what circumstances an ITR may send packets through the alternate path. The priority is always 00 since the ITR should consider this information before selecting an ETR. The following "scope" values are recognized:
| scope | description |
| none | No IPWR ETRs are available for this netmask. This entry may be positively cached so that the ITR knows not to ask again. No further attempts should be made to find an Waypoint ETR down this TRRP tree. This is a mandatory option: ITRs must recognize it. No other route specifiers should appear with this option. |
| mask=n | No Waypoint ETRs exist in this TRRP tree until netmask N or longer. The ITR should cache this knowledge and should not attempt to look up further Waypoint entries in this tree shorter than the netmask N. This is a mandatory option: ITRs must recognize it. No other route specifiers should appear with this option. |
| limited=ss | This is the default option. If the "WP" entry is not given or the ITR does
not understand the scope, it should assume this option is in effect. In limited mode, the specified ETRs might or might not forward packets for the given aggregate path. Perhaps it will only forward packets for paying members. The ITR should transmit packets received for up to SS seconds after the initial packet through this path, however it should attempt to hold and retransmit the packets directly once the direct ETR lookup completes. If the ETR lookup has not completed within SS seconds, the ITR should cease sending packets to the aggregate ETR. |
| initial=ss | Optional. In initial mode, the specified ETR guarantees that it will forward the packets on down the path for all addresses in the prefix. The ITR may discard destination packets from its buffer after forwarding them to the Initial mode ETR. If the ETR lookup has not completed within SS seconds, the ITR should cease sending packets to the aggregate ETR. |
| generous=ss | Optional. In generous mode, the specified ETR guarantees that it will forward the packets on down the path for all addresses in the prefix. The ITR may discard destination packets from its buffer after forwarding them to the Generous mode ETR. Furthermore, the ITR may delay requesting an explicit ETR for the destination by up to SS seconds and it may continue sending destination packets via the generous mode ETR until a specific ETR is successfully found.. |
Examples:
0.waypoint.0.v4.trrp.arpa IN TXT "00,wp,mask=8"
No IPWR entries exist in 0.0.0.0/0 with a netmask shorter than /8.
8.waypoint.10.v4.trrp.arpa IN TXT "00,wp,none"
No IPWR entries exist within 10.0.0.0/8, an RFC 1918 address space.
8.waypoint.199.v4.trrp.arpa IN TXT "00,wp,limited=5 80,g4,192.168.100.1"
192.168.100.1 is an ETR which will accept GRE-encapsulated packets for 199.0.0.0/8, part of the IPv4 swamp. It operates in limited mode: the ITR should save and retransmit packets directly once an explicit ETR is found. If no ETR is found within 5 seconds, the ITR should stop sending packets via this ETR and wait until a specific ETR is found.
Lookup Strategy
Waypoint ETR already known for a covering prefix:
Follow the waypoint guidelines on when to send packets to the Waypoint ETR and when to look up an explicit ETR for the given destination address.
No Waypoint ETR known:
Make an immediate request for an ETR for the explicit destination per normal TRRP rules.
At the same time, make exactly one waypoint request for the shortest prefix for which an waypoint request has not already been flunked. The very first request (before anything else has been tried) should be 0.waypoint.0.v4.trrp.arpa for IPv4 or 0.waypoint.0.v6.trrp.arpa for IPv6.
Make no more than one waypoint request per second regardless of how many packets are received.
A waypoint request flunks only if the server indicates NXDOMAIN, no data, or "00,wp,mask=n". A timeout or error indicates that the waypoint request should be retried after a 60 second waiting period. No further depth should be attempted in the mean time.
Timeouts:
When the TTL expires for a waypoint entry, the ITR should keep the entry in the cache for up to an additional 24 hours. The next packet which would be delivered to that waypoint ETR will trigger a new waypoint lookup to refresh the cache. The ITR should use the existing waypoint entry while the lookup is being performed.
Example:
The ITR receives a packet for 199.33.225.1. It buffers the packet.
The ITR makes DNS requests for "1.225.33.199.v4.trrp.arpa" and "0.waypoint.0.v4.trrp.arpa". The first is the normal TRRP lookup. The second is the waypoint lookup for 0.0.0.0/0.
0.waypoint.0.v4.trrp.arpa returns "00,wp,mask=8". This means that the next waypoint lookup should be with a netmask of /8. We're still in the same second, so the ITR is not permitted to make another waypoint request yet.
The ITR receives another packet for 199.33.225.1. It buffers the packet but takes no action.
The ITR receives a packet for 199.33.225.2. It makes a DNS request for "2.225.33.199.v4.trrp.arpa." It's still not permitted to make another waypoint request.
One second passes.
The ITR receives another packet for 199.33.225.1. It buffers the packet and makes a DNS request for "8.waypoint.199.v4.trrp.arpa" because the entry for 0.waypoint.0.v4.trrp.arpa told it to try again with a subnet mask of /8. The normal TRRP request hasn't timed out yet, so the ITR won't make another one until it does.
1.225.33.199.v4.trrp.arpa returns "80,g4,10.0.0.1". The ITR encapsulates the two buffered packets for 199.33.225.1 in GRE packets and sends them to 10.0.0.1. It removes the sent packets from the buffer.
8.waypoint.199.v4.trrp.arpa returns "00,wp,limited=5 80,g4,192.168.1.1". The ITR encapsulates the buffered packet for 199.33.225.2 in GRE and sends it to 192.168.1.1. It keeps the packet in the buffer since the waypoint scope is "limited."
2.225.33.199.v4.trrp.arpa returns "80,g4,10.0.0.1". The ITR encapsulates the buffered packet for 199.33.225.2 in GRE packets and sends it to 10.0.0.1. It removes the sent packet from the buffer.
30 minutes pass.
The ITR receives a packet for 199.4.5.6. The ITR still knows the waypoint for 199.0.0.0/8, so it encapsulates the packet in GRE and sends it on to 192.168.1.1. The waypoint mode is limited, so the ITR keeps the packet in the buffer and makes a DNS request for "6.5.4.199.v4.trrp.arpa" as well.