Optional "Via" tagging/tunnelling method for TRRP

Basic TRRP encapsulates packets in a GRE tunnel. This is widely supported in existing software, but it consumes an additional 28 bytes of space in the packet, breaks normal ICMP functionality and causes trouble for packet filtering firewalls.

The Via method solves these problems. The Via ITR tags the packet with an IP option header instead of encapsulating it in a tunnelling protocol. The Via options header functions much like loose source routing.

IPv4 version:

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: v4 = Via for IPv4.

Route: The "route" parameter offers the IP address of the router the packet should hit before being sent to the destination address. 

Example:

The ITR makes a DNS TXT request for 1.101.168.192.v4.trrp.arpa. It receives one TXT record in response:

80,v4,10.0.0.1 90,g4,1.2.3.4

The best priority route uses the IPv4 "Via" protocol to route the packet first to 10.0.0.1 before releasing it to the address in the header's destination field.

IP option 30:

The Via IP option header must be the first option header in the packet. If its not there, the router should treat it as if it was not present for routing purposes, even if it appears later. Note that the use of the option number "30"  is purloined and must be replaced by an IANA assigned number before this protocol sees production use.

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Type Length Version Flags unused (zero)
Egress Transit Router IP address
Zero or more "Been There" ETR IP addresses
[...]

Type. 8 bits. Set to 0x9e.

00 01 02 03 04 05 06 07
C Class Option

C, Copy flag. 1 bit. Set to 1 (0x80)
Indicates that this option should be copied into all fragments.

Class. 2 bits. Set to 0 (0x00)
This is a control option.

Option. 5 bits. Set to 30 (0x1e).
The IP option number.

Length: 8 bits. 6+(n*4) where n is the number of "been there" addresses.

Version: 4 bits. Must be zero.

Flags:

20 21 22 23
Done Unused

If the Done flag is 1 then the packet has already reached the ETR. The option has been preserved for statistical use by the destination host but should not be used for further routing.

How to Route a packet with the Via option:

The Ingress Tagging Router (ITR) for this packet will add an 8-byte option header at byte 21, immediately after the normal IP destination address. Any other option headers must be pushed back, truncated and/or discarded to accomodate this option. If the resulting packet is too large for the interface MTU then the ITR should follow normal fragmenation rules, placing this option in every fragment.

Normal IP headers are 5 32-bit words long. A router which supports the Via option should look for an IP packet whose header is at least 7 words long. If the header is at least 7 words long and word #6 is 0x9e000000 mask 0xff00ffff then the router should use word #7 as the destination address instead of word #5.

The ITR should proactively attempt to adjust the TCP MSS in any tagged SYN packets such that the subsequent TCP packets will be small enough to reach the ETR without fragmentation. While this is not supposed to be necessary, the reality on the ground is that ignorant firewall administrators have broadly broken path MTU discovery.

Once the packet reaches the ETR, the ETR should either remove the option header or set the Done bit to 1. The ETR should then deliver the packet per the normal IPv4 routes offered via a normal interior routing protocol. [It should probably leave the header there and mark the done bit to 1 but I'm not 100% sure what a receiving host will do with a packet containing an unrecognized header. If it drops the packet or copies the option to the return packet, that would be bad.]

If the ETR does not know a non-default route to the destination address, it must not remove the option header and must leave the Done bit set to zero. This condition indicates a temporary failure of the downstream route. The ETR must act as an ITR. It must lookup the routes for this destination and select the best one which is not the current ETR nor any "been there" ETR. If the newly selected route is also a Via route then the ETR should add itself to the end of the Been There list, put the newly select ETR's IP address at word #7 in the IP header and place the packet back on the wire for delivery to the newly selected ETR. The current ETR's IP address should be added to the Been There list regardless of whether it appears in the DNS route lookup.

If the new lookup calls for a tunnelling protocol other than Via, the Via header should be removed from the IP packet before encapsulation. If the alternate protocol supports a sufficiently robust "been there" specification then the current ETR's IP address and all addresses in the Been there list should be copied to the new protocol's been there list.

If an ITR receives a packet with the Via header in the wrong position (not at word #6) it should move the via header back to the right position, consider the specified ETR to be invalid and reroute after demoting the specified ETR to the "been there" list.

IPv6 version:

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: v6 = Via for IPv6.

Route: The "route" parameter offers the IP address of the router the packet should hit before being sent to the destination address. 

[to do]

 

Security Considerations

Packet filtering firewalls may process packets with the Via option as if the option was not present. Where serving a multihomed customer, take care to allow for the possibility that the network will emit packets with nonlocal source addresses but destination addresses which correspond to the customer.

The ETR must not blindly decode packets sent to it. It must first check against a list of destinations it considers itself to be authoritative for. Packets for destinations for which it is not authoritative should be discarded. Note that during failures the ETR may be authoritative for packets for which it does not currently have a route, thus the presence or absence of routes in its routing table may not be used to determine whether the ETR is authoritative.

Discussion:

The upside of this approach is:

  1. Its the original IP packet on the wire, so all filtering and ICMP messages work as expected.
  2. It consumes as little as 8 bytes of overhead.
  3. Supports a relatively smooth failover where packets can be rerouted by the first destination network after the failure occurs but before new best-route information has propagated.

The downside is:

  1. Currently deployed ASICs aren't rigged to look for their destination inside the IP options header and may not be software-adaptable to the task. If not, we're into a forklift upgrade to make it work.

Brokenness:

  1. Path MTU Discovery is dead broken by this tagging method and I don't see a way to fix it other than reducing the ITR's allowed MTU to the 576 byte Internet minimum. When the fragmentation needed message returns to the originating host, it simply won't understand that it needs to leave room for the Via option header as well.

 

The Via IP option was inspired by a discussion with Owen DeLong. He deserves much of the credit and none of the blame.