Wide-area Relay Addressing Protocol (WRAP): Packet Relay in TRIAD Chetan Rai David Cheriton Abstract The Wide-area Relay Addressing Protocol (WRAP) is a shim protocol interposed between the IP header and true payload protocols to allow hosts in a TRIAD environment to communicate across address realms. WRAP relays packets by using Internet Relay Tokens (IRTs), mapped from domain names by the Directory Relay Protocol (DRP). The IRT, an inter-realm address, can take several forms. The simplest of these is the Internet Relay Path (IRP). It consists of a list of intra-realm (IPv4) addresses. Each intra-realm address specifies a Relay Agent (RA) that can forward packets from one address realm to another, where the next address in the list will be valid. WRAP is an explicit relaying protocol. Unlike Loose Source Routing, WRAP updates the source address at each intermediate destination (Relay Agent) and does not use an IP option. Unlike IP encapsulation protocols, WRAP does not discard intermediate destination information. 1. Introduction The TRIAD architecture in [TRIAD] describes a means of communication across address realms (the terms "address domain" and "domain" are used interchangeably with "address realm" as described in [NAT-TERMINOLOGY]). Like other mechanisms proposed for communication across disparate address realms such as NAT [NAT-TRADITIONAL] and RSIP [RSIP-FRAME, RSIP-PROTO], intra-realm routing and forwarding are unchanged, using OSPF, RIP etc and IPv4. However, unlike both NAT and RSIP, TRIAD seeks to provide solutions to the scaling problems of the Internet, and does not limit itself to being a stopgap measure useful only in specific situations. Also unlike NAT and RSIP, there is no distinguished public address realm; all realms are peers in a TRIAD world. A final point of difference is that TRIAD does not provide transparent routing and packet relay across realms. Instead, the path of a packet through different address realms is made explicit and recorded in an "inter-realm network address". This address is looked up through the Directory Relay Protocol (DRP) described in [TRIAD-DIR], and used in packet relay through the Wide-area Relay Addressing Protocol (WRAP) which is the subject of this draft. Analogous to the separation of routing within and across autonomous systems in the current Internet, TRIAD distinguishes between network layers within and across address realms. The intra-realm network layer is IPv4 (as mentioned above). The intra-realm network address is an IPv4 address, and packets are "forwarded" from one point to another in an address realm. The inter-realm network layer is WRAP, with an Internet Relay Token as network address. Packets are "relayed" from one realm to another. The term "relay" is used to indicate a higher-level involvement in passing on a packet received from elsewhere as compared to conventional IP forwarding. In particular, with WRAP, the IP destination address of a packet not in the realm of its destination host refers to a Relay Agent (described below) in the current realm, and the WRAP layer above the IP layer decides whether or not to relay the packet based on policy. The final destination of the packet will be placed in the IP destination field when the packet reaches the address realm of the destination. 2. Definitions 2.1 WRAP Relay Agent A WRAP Relay Agent (WRAP-RA) is a gateway between exactly two address realms, with one interface in each of the two realms. A packet arriving at one of the interfaces (realms) can either be forwarded to the other interface (realm) (with appropriate IP and WRAP header updates) or dropped. A physical WRAP-RA box could connect more than two address realms, and have more than one interface in each of the realms it connects. This physical WRAP-RA is equivalent to several "logical" WRAP-RAs (as defined above) and/or several IP routers. In this document, we will always use the definition of the previous paragraph, but it is important to note that that definition does not overly restrict a real world WRAP-RA. 2.2 Internet Relay Token An Internet Relay Token (IRT) is an inter-realm network address. It is important to remember that an IRT comes with context: it is valid in a particular address realm, referred to as the "current" realm in the following discussion. An IRT consists of a Local Component (LC) and an Inter-Realm Component (IRC). The LC is simply an IP address that specifies a host in the current realm. This host will be a WRAP-RA unless the IRC is null. As the name suggests, the IRC specifies a non-local host, given the context of the current domain and the host specified by the LC. 3. Protocol Description 3.1 WRAP Header The IP header of a WRAPped packet specifies WRAP in its Protocol field. It is followed by the WRAP header, described below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | protocol | reserved (=0) | f_offset | length | +---------------+---------------+---------------+---------------+ | rIRC | + + > . . . < +---------------------------------------------------------------+ | fIRC | + + > . . . < +---------------------------------------------------------------+ Figure 1: Format of a WRAP header The WRAP header contains the IRCs of two IRTs. The rIRC is the "reverse IRC". Along with the IP source address as LC, the rIRC specifies the inter-realm source address of the packet. The "forward IRC", the fIRC, similarly specifies the destination of the packet in conjunction with the IP destination address. Given this placement of the components of the two IRTs, IP routers within realms need not concern themselves with any aspect of WRAP. The rIRC in the WRAP header is in reverse order: the first 32-bit word in the rIRC header field is the last 32 bits of the rIRC, the second 32-bit word is the next-to-last 32 bits of the rIRC, and so on. The need for this will become clear in Section 4. The protocol field specifies the transport layer protocol, using the same types as for IP (e.g. 6 for TCP [RFC793]). The f_offset field specifies the start of the fIRC field in units of 32-bit words. The f_offset field is 0 if the rIRC is null. The length field is the total length of the rIRC and the fIRC, in 32-bit words. It MUST NOT have a value of 0. That would imply local packet source and destination, and WRAP MUST NOT be used for packets that do not cross address realms. The payload following the WRAP header is TCP, UDP [RFC768] or other transport layer protocols. 3.2 Packet Relay The notation used in this and following sections to describe the addressing information in a packet is (IP src, IP dst) [reverse IRC, forward IRC]. An IRT is specified as {LC, IRC}. The source S of a packet will receive addressing information {LC-D, IRC-D} upon performing a name lookup for destination D as described in [TRIAD-DIR]. If IRC-D is null, the source MUST NOT use WRAP when sending a packet to D. If IRC-D is non-null, the packet MUST contain the addressing information (S, LC-D) [null, IRC-D]. Any WRAP-RA receiving a WRAP packet not addressed to it (fIRC is non-null) will relay the WRAP packet to its other interface (and address realm) or drop the packet, depending on policy that can (and probably will) use the addressing information in the packet. If the RA is relaying the packet, it will map the incoming addressing information in the packet to outgoing addressing information, possibly using state that may have been set up during name lookup. The outgoing IP source address MUST be that of the outgoing interface of the RA, and the outgoing IP destination address MUST be valid in the outgoing realm. The total length of the forward and reverse IRCs MUST be the same for the incoming and outgoing packets: this will be ensured during name lookup if state was set up at that time. The destination D of a packet is that host that receives the packet with a null forward IRC. Note that the packet tells D how to get back to the source: by using the IP source and reverse IRC of the received packets as the IRT to send to. A simple form of IRT requiring no state setup during name lookup is described in Section 4. 3.3 Packet Relay Example The topology used in this example is shown in Figure 2. stanford.edu bbnplanet.net ------------------- ------------------- | | | | | | | | | S1 A<-------->A' | | (xenon) | | | | | | B | ------------------- ---------^--------- | | ------------------- ---------v--------- | | | B' | | | | | | D1 C'<-------->C | | (www) | | | | | | | ------------------- ------------------- foo.com uunet.net Figure 2: Example Topology In the figure, boxes are address realms, and double-headed arrows are WRAP-RAs. S1, D1, A, A', B, B', C and C' are IP addresses. The following state is set up at the RAs during name lookup: At A : (S1,A) [null,F"] translates to (A',B) [R,F'] A' : (B,A') [F',R] translates to (A,S1) [F",null] At B : (A',B) [R,F'] translates to (B',C) [R',F] B' : (C,B') [F,R'] translates to (B,A') [F',R] At C : (B',C) [R',F] translates to (C',D1) [R",null] C' : (D1,C') [null,R"] translates to (C,B') [F,R'] Any packet from S1 to D1 therefore has the following addressing information as it travels across the network: S1 --> A : (S1,A) [null,F"] A' --> B : (A',B) [R,F'] B' --> C : (B',C) [R',F] C' --> D1 : (C',D1) [R",null] 4. Internet Relay Paths An Internet Relay Path (IRP) is a very simple form of IRT, requiring no state setup at WRAP-RAs. It consists of a list of IP addresses, each specifying the next RA the packet will travel through. Of course, each of these IP addresses will be valid in the outgoing address realm of the previous RA. The last address is simply the destination's IP address. The WRAP header now looks like Figure 3. The portion of the list of addresses before f_offset forms the reverse IRP when prepended by the IP source address. Similarly, the portion after f_offset forms the forward IRP when prepended by the IP destination address. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | protocol | reserved (=0) | f_offset | length | +---------------+---------------+---------------+---------------+ | R1 | +---------------------------------------------------------------+ | R2 | +---------------------------------------------------------------+ > . . . < +---------------------------------------------------------------+ | Rk | +---------------------------------------------------------------+ | D | +---------------------------------------------------------------+ Figure 3: Format of a WRAP header with IRPs Packet relay with IRPs is best explained with an example: we use the example of Section 3.3. The following is the addressing information in the packet as it travels across the network: S1 --> A : (S1,A) [null, B C D1] A' --> B : (A',B) [S1, C D1] B' --> C : (B',C) [S1 A', D1] C' --> D1 : (C',D1) [S1 A' B', null] The transformation of a packet at an RA involves 1) moving the IP address at f_offset to the IP destination field 2) moving the source IP address to f_offset in the WRAP header 3) writing the address of the outbound interface of the RA into the IP source field 4) incrementing f_offset It is apparent that no state is required at the RA for this transformation. We expect IRPs to be the predominant form of IRT used in a TRIAD Internet. Security or other concerns could result in realms using other, possibly opaque, forms of IRT. The use of opaque IRTs will cause a drop in performance, because of the time required for state setup and the time required for lookup of this state during packet relay. For the rest of this document, we assume IRPs are being used unless mentioned otherwise. 5. EXPRESS Multicast EXPRESS multicast [EXPRESS] can be supported under WRAP with functionality added only at the WRAP-RAs. 5.1 Name Lookup The name lookup of an EXPRESS multicast channel [TRIAD-DIR] returns a group IP address in the EXPRESS address range and the IRP that multicast packets on the channel will take to get to the host performing the lookup. Each RA, upon receiving a name lookup response for a multicast channel, sets up a mapping between the IRP-group address pair of the received response and a locally allocated group address valid in the downstream address realm (unless such a mapping already exists). It then forwards the response, adding the address of its outgoing interface (valid in the outgoing or downstream realm) to the IRP, and replacing the group address with the one locally allocated. Therefore, the group address in the lookup response received by the end host is valid only in the address realm of that host. The mappings that are set up in the RAs eventually time out (a) if no Join message is received for the channel, or (b) after a Leave message results in no remaining downstream subscribers. RAs in the middle of the network may need to handle more multicast groups than there are IP addresses in the EXPRESS multicast address range. This can be easily taken care of by using more than one alias for the interfaces of these RAs. 5.2 Join/Leave There is no change in the Join procedure in the end host, apart from the fact that the (S,G) pair used does not refer to the original source of the multicast channel. The end host sends a Join message to the last-hop RA for the channel (S,G) where S is the address of the RA and G is a group address allocated by that relay point during name lookup. If other hosts in the same address realm have already joined this group, this join message will stop at the node where it meets the forwarding tree already set up. Any relay point receiving a Join message adds the incoming interface to the list of interfaces for that channel. If this is the first Join message for this channel, the RA will join the channel in the upstream address realm in exactly the same manner as the end host. The Leave procedure corresponds in the same way to the Leave procedure without WRAP. 5.3 Forwarding The source sends packets on a multicast channel with its own source address and a locally allocated group address, as is usual with EXPRESS multicast. The WRAP header contains no addresses. The pointer field is set to 0, but the length field can be used to scope the multicast. It should be noted that the scoping will be at the granularity of address realms. When a multicast packet is received at a RA, it is dropped if there is no mapping for the source IRP-group address pair. Otherwise it is forwarded to each of the address realms for which there are mappings. The pointer field is incremented and the IP source address is added to the WRAP header. The source and destination fields in the IP header are changed to the address of the outgoing interface and the group address specified by the mapping for that address realm. At any host receiving a multicast packet, the channel the packet was sent on is defined by the source and destination addresses in the IP header. These will be the address of the last-hop RA, and a group address allocated locally at that RA. The IRP in the WRAP header can be matched with the IRP received as the name lookup response. 6. Transport Layer Checksums The TCP and UDP checksum algorithms use IP source and destination addresses as part of the pseudo-header over which the checksum is calculated. Since these change during packet relay with WRAP, this will cause checksums to fail at the destination host. The transport layer protocols MUST use source and destination canonical DNS names instead of network addresses as part of the transport pseudo-header, since names are the only end-to-end identifiers in a TRIAD Internet. Given that DNS names are being used to calculate checksums, the destination will first map the reverse IRT of the received packet to a DNS name, either using cached information or performing a reverse name lookup (at connection setup time, and when an IRT back to the same source changes). The checksum in the packet can now be verified. This means that, for connection-oriented protocols like TCP, the packet first needs to be demultiplexed to the correct connection and then verified. Though this is the reverse of the sequence in many implementations, it provides uniformity in processing packets with or without IP security. 7. Deployment Deployment strategies using WRAP Inter-Domain (WRAPID) Gateways is discussed in [TRIAD-DEPLOY]. 8. Security Considerations Security considerations are not discussed in this document. [TRIAD-IPSEC] describes IP security in a TRIAD Internet. 9. Concluding Remarks WRAP provides the efficient relaying of loose source routing without the problems of options and spoofing and the specifiable source addressing of tunneling without losing information as part of de-encapsulation and with far less header overhead than conventional encapsulation. References [RFC791] J. Postel, Internet Protocol, RFC 791, September 1981. [RFC2003] C. Perkins, IP Encapsulation within IP, RFC 2003, October 1996 [RFC1112] S. Deering, Host Extensions for IP Multicasting, RFC 1112, August 1989 [RFC1631] K. Egevang, P. Francis, The IP Network Address Translator (NAT), RFC 1631, May 1994 [RFC2460] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998 [RFC2401] S. Kent, R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, November 1998 [RFC793] J. Postel, Transmission Control Protocol, RFC 793, September 1981. [RFC768] J. Postel, User Datagram Protocol, RFC 768, August 1980. [RFC792]J. Postel, Internet Control Message Protocol, RFC 792, September 1981. [EXPRESS] H. Holbrook, D. Cheriton, the EXPRESS paper accepted at SIGCOMM [TRIAD-ARCH] D.Cheriton, TRIAD Architecture [TRIAD-DIR] M. Gritter, NBRP [TRIAD-IPSEC] E. Miller, RAP-SEC [TRIAD-DEPLOY] C. Rai, Deployment [NAT-TRADITIONAL]