Network Working Group S. Giacalone INTERNET-DRAFT Predictive Systems Expiration Date: August 2001 Filename: draft-giacalone-grp-00.txt February 2000 The Gateway Response Protocol (GRP) for Networks Using Zero Configuration IPv4 Addresses This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo defines a simple mechanism, termed gateway response protocol (GRP), which permits hosts using Zero Configuration IPv4 Addresses [1] to find and use a default gateway, thereby gaining access to outside networks, including the Internet. GRP is fully compliant with rules limiting Zero Configuration addresses to local networks and does not negate source/destination address assumptions. Please send comments to zeroconf@merit.edu Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Table of Contents Overview .............................................. Compliance with Zero Configuration Forwarding Rules.... . . . Expires August 2001 [Page 1] Internet Draft Gateway Response Protocol February, 2001 Acknowledgements ...................................... References ............................................ A Compatibility ....................................... B GRP and Dynamic Host Configuration Protocol (DHCP) .... C Security Considerations ............................... D Authors' Addresses .................................... E Full Copyright Statement .............................. Overview The system of address allocation defined in [1] permits hosts to automatically find and use IP addresses for local network connectivity with no pre-configuration (hence the term Zero Configuration). While Zero Configuration address assignment is an extremely useful capability, increased user expectations of constant network connectivity mean that it would be even more beneficial if Zero Configuration hosts could gain access to outside networks automatically- something which is not currently possible in [1]. This memo defines a simple, lightweight mechanism, termed GRP, which enables hosts to find default gateways with no static or dynamic configuration, thereafter using them to forward data to off-network locations. By using GRP, large globally connected networks could be deployed with no pre-configuration of hosts, no configuration of address servers, and very minimal configuration of routers. As in [1] this memo assumes that Zero Configuration address space is not subnetted. Compliance with Zero Configuration Forwarding Rules By convention, Zero Configuration IP addresses are not permitted to cross routed boundaries, and GRP does not violate this rule. As with all routers, GRP enabled routers must not receive and then forward packets containing Zero Configuration addresses. GRP is fully dependant on the use of Network Address Translation (NAT) for the translation of Zero Configuration source addresses in packets leaving the Zero Configuration network. While NAT is outside the scope of this document, GRP's reliance on it necessitates a general discussion of its use. In GRP networks, Zero Configuration hosts are able to access external networks, but by using NAT, Zero Configuration addresses are not transported across routers, which insures compliance with forwarding rules. This document assumes that NAT "inside" source address translation is used, that it is configured to translate source addresses in the 169.254/16 range using a dynamic pool, and that the Expires June 2001 [Page 2] Internet Draft Gateway Response Protocol February, 2001 Zero Configuration network is configured to be the "NAT inside" network. When sending data to Zero Configuration addresses, GRP enabled local hosts can, by rule, assume that the data will not leave the local LAN. Since source NAT will replace the source Zero Configuration IP addresses of packets leaving the Zero Configuration network, not the destination addresses of egress packets, GRP's use of NAT is compliant with this destination address assumption. Therefor, in order for a packet to leave a GRP Zero Configuration network, it must arrive at the router destined to legitimate non Zero Configuration address which can be routed to. Additionally, note that data sent directly to a Zero Configuration address residing on a GRP enabled router must not be forwarded. NAT Pool=1.1.1.0/24 | | NAT Inside | NAT Outside | | | | +-+-+-+-+-+-+ | ----- | | Zero Config Net |-----| R |-----+ Outside + | ----- | Networks | Host1-| +-+-+-+-+-+-+ Example 1.1 ->S=169.254.5.5 D=1.1.1.1-------------->S=2.2.2.2(NAT) D=1.1.1.1 Example 1.2 ->S=169.254.5.5 D=169.254.1.1--Not translated or forwarded In Example 1.1, a packet from Zero Configuration host "Host1" arrives at GRP enabled gateway router "R" (assume that Host1 has previously determined that R is its gateway via GRP). After translating Host1's Zero Configuration source address, the packet is forwarded. Since only the source address is modified, and the packet was destined to legitimate (non Zero Configuration) IP address, hosts can assume that packets destined to Zero Configuration will not leave the local network. Furthermore since the packet does not contain a Zero Configuration address when it transits the router, it does not violate Zero Configuration networking rules. In Example 1.2, assume that a packet from Host1 destined to a Zero Configuration addresses to a Zero Configuration address finds its way to router R. Since GRP routers don't translate outbound destination addresses or forward packets with Zero Configuration addresses, the packet is dropped after verifying that it is not a GRP packet, thereby upholding Zero Configuration networking rules. Expires June 2001 [Page 3] Internet Draft Gateway Response Protocol February, 2001 Zero Configuration hosts can also assume that when they receive a packet with a Zero Configuration source address, it originated from another host on the local network. Using GRP, this assumption remains possible because (inside) source NAT modifies the source address of packets leaving the Zero Configuration network, not those entering it. NAT Pool=1.1.1.0/24 | | NAT Inside | NAT Outside | | | | +-+-+-+-+-+-+ | ----- | | Zero Config Net |-----| R |-----+ Outside + | ----- | Networks | Host1-| +-+-+-+-+-+-+ Example 2.1 D=169.254.5.5 S=1.1.1.1<-------------D=2.2.2.2(NAT) S=1.1.1.1<- Example 2.2 Not translated or forwarded<---------D=2.2.2.2(NAT) S=169.254.5.100<- In example 2.1, a reply packet to the query made in example 1.1 arrives at router R. Since router R has an entry in its NAT table binding the inbound packet's destination address (2.2.2.2) to the Zero Configuration address 169.254.5.5, the destination address is modified and then the packet is forwarded to the local LAN. Since source NAT only changes the destination address in inbound packets, hosts can assume that packets with a Zero Configuration source address originated from the local LAN, as per Zero Configuration networking rules. Furthermore as the packet does not contain a Zero Configuration address when it transits the router, it does not violate Zero Configuration networking rules. In example 2.2, a packet with a Zero Configuration source address arrives at router R. In this case, router R has an entry in its NAT table binding the packet's destination address (2.2.2.2) to the Zero Configuration address 169.254.5.5. However, since NAT is not configured to translate source addresses in the inbound direction, and Zero Configuration address must not transit routers, the packet is dropped. Therefor, host assumptions regarding the local origination packets with Zero Configuration source addresses are upheld. General Operation GRP operates on Zero Configuration hosts and routers. The host portion of GRP includes: Expires June 2001 [Page 4] Internet Draft Gateway Response Protocol February, 2001 -Discovery of GRP gateway routers -Caching router response messages -Monitoring GRP router keepalive messages -Transitioning (failing over) to active gateway routers as required GRP operation on routers includes: -Responding to GRP queries sent to the Zero Configuration GRP router address. -Originating GRP keepalive messages -Properly handling the GRP keepalive messages originated by other routers. -Interoperation with NAT GRP Host Operation After a host determines its Zero Configuration address as per [1], it may attempt to find a default gateway using GRP. To accomplish this, the host should, by default, broadcast an ARP request for the (currently reserved) zero configuration GRP address 169.254.0.1, after a short randomized delay. GRP hosts must use normal ARP procedures for this router discovery operation. Using the first ARP response received, hosts must program a default IP route in their route cache. Note that operations governing host cache population should not need modification. Thereafter, hosts must use the default route (and the corresponding gateway) to forward traffic destined outside the zero configuration network. Note GRP implementations may offer a non-default feature whereby hosts rely solely on GRP keepalives to find a default gateway. Hosts program their caches from the information in the first keepalive message received. Specific route cache programming does not change when this option is used. However, this option may increase establishment time for "off network" user connectivity. After initial router discovery, hosts listen for keepalives from all GRP routers. Note that GRP keepalives are unrelated to initial router discovery functions. If a keepalive is not received from the GRP router that is the current default gateway within the "dead" timer interval, the host must: -Change the default route in the route cache to use information stored from either the second fastest ARP response received in Expires June 2001 [Page 5] Internet Draft Gateway Response Protocol February, 2001 the initial router discovery, or from the last keepalive heard from a non-default GRP router. The storage of ARP response and keepalive information is implementation specific. -If there was no stored information with which to update the cache, wait for the next GRP keepalive, and then change the default route in the route cache using that information. -If there was no stored information, and no keepalive is received within another dead interval (learned from the previous GRP gateway), send an GRP ARP query to 169.254.0.1, after a short randomized delay. If no response is received within another dead interval, GRP hosts move into "probe mode" in which queries are repeated every dead interval plus a randomized delay. After some time, queries are sent following an exponential back-off algorithm. The specific timing of probe mode operations (including the initiation of back-off) is implementation specific, but should balance network utilization and fault tolerance. The GRP keepalive dead timer is three times the keepalive time. Hosts determine the keepalive time by averaging the arrival time of the first four keepalive messages they receive. This method permits the use of very simple keepalive messages and the minimal centralized manual configuration and adjustment of keepalive timers (on GRP routers, not hosts). Once a GRP host finds a default route, it must not re-program it's ARP cache for GRP router address (169.254.0.1 by default) or the default router unless the GRP dead timer expires or manually prompted to do so. In a steady state network, Hosts will send traffic destined outside the network to the default router's MAC address which is learned through GRP. GRP Router Operation All GRP routers must respond to ARP requests made for 169.254.0.1, which is by default the GRP router address, using normal ARP procedures. Note that it must be possible to configure which interfaces will respond in this way, and non configured interface must not respond in any way. GRP routers should unicast ARP responses for 169.254.0.1 if possible. All GRP routers must drop (not listen to) all ARP responses for the GRP address being used (which is 169.254.0.1 by default). To permit network managers to influence which default router hosts choose, it must be possible for network operators to manually insert a ARP response delay for the GRP address on a router by router basis. Expires June 2001 [Page 6] Internet Draft Gateway Response Protocol February, 2001 Note that implementations must place an upper bound on GRP ARP processing to prevent denial of service attacks. Once GRP is initialized, routers must originate GRP keepalives, only on interfaces configured to do so. The pace at which keepalives are sent must be manually configurable, but must default to 2 seconds. The maximum keepalive interval should be 15 seconds. The format of the GRP keepalive is of a gratuitous ARP. All GRP routers must drop (not listen to) all GRP keepalive messages not self-originated. GRP routers must never forward (that is receive and subsequently transmit) traffic which includes addresses in the range of 169.254/16. Therefor, GRP is intended for exclusive use with NAT. When a GRP router receives traffic with a Zero Configuration source IP address, it must translate the source into an acceptable NAT address if it intends to route it. Although GRP related NAT operation is outside the scope of this document, router's NAT timers may need to be optimized in order to cope with the possibility of Zero Configuration hosts dynamically selecting new addresses. Redundancy and adjustability GRP does not limit the number of default gateways attached to a zero configuration network. GRP provides an number of tuning options, including: -The pace of keepalive origination, which is centralized and automatically adjusted to by hosts -The keepalive dead timer which is dynamically set by hosts averaging keepalives -Influencing the gateway which hosts use -Selecting alternate GRP router addresses -Initialization by keepalive Simple GRP/Zero Configuration network example The example diagram below depicts a fully automatic GRP/Zero Configuration network. Note that each local LAN is capable of re- using Zero Configuration host IP addresses. Internet ----------- Expires June 2001 [Page 7] Internet Draft Gateway Response Protocol February, 2001 | | | | | | ----- | |-----| A |-----| | ----- | | | | | | | | ----- | | ----- | Net1|--| B |-----| |-----| C |-|Net2 | ----- | | ----- | Host1-| | | |-Host2 -Step 1: "Host1" and "Host2" find zero configuration addresses as per [1]. Assume that routers B and C use the same zero configuration address ranges as specified in [1]. Furthermore, assume that Host1 and Host2 auto-configure the same zero configuration IP address. -Step 2: Using GRP, both hosts auto discover their default gateway routers (router B and C, respectively). -Step 3: The hosts monitor GRP router keepalive messages. -Step 4: Intra-subnet communication occurs as in [1], and when the hosts need to send data off the subnet (to the Internet, for example), they send the data to the MAC address of the selected GRP default gateway routers. Routers B and C use NAT to hide the zero configuration addresses of each host, providing compliance with Zero Configuration networking rules. Acknowledgements References [1] Cheshire, S., "Dynamic Configuration of IPv4 link-local addresses" work in progress. A Compatibility IP devices which don't conform to the specifications in this memo must cope with what will appear to be ARP packets with fluctuating and conflicting contents. B GRP and Dynamic Host Configuration Protocol (DHCP) -GRP is intended to enhance Zero Configuration networking services by enabling hosts to find default gateways. While DHCP can provide hosts with the IP address of a default gateway, GRP is a superior discovery protocol for Zero Configuration environments for the following reasons: Expires June 2001 [Page 8] Internet Draft Gateway Response Protocol February, 2001 -Since the primary purpose of DHCP is the assignment of host addresses, using DHCP to serve gateway addresses to hosts running Zero Configuration protocols (the purpose of which are also to assign host addresses) is conflicting and self defeating. For example, if a network runs DHCP to assign gateway addresses to Zero Configuration hosts, then DHCP might also serve host addresses, negating the need of Zero Configuration protocols. -While DHCP can provide multiple gateway addresses to hosts, it does not specify a means for determining whether gateways are operational, as does GRP. The GRP protocol provides an adjustable dynamic keepalive/query system and therefor provides more fault tolerant gateway discovery and maintenance than DHCP. -Using GRP eliminates the need to design, build, implement, and manage DHCP servers and proxies. By providing gateway discovery with very little management overhead, GRP is closer to providing total networking with zero configuration than DHCP. -Adding GRP functionality to products may be more simple than DHCP, and therefor GRP is more inline with the concept of lightweight, zero configuration networking than DHCP. -GRP initialization is less network intensive than DHCP initialization. C Security Considerations If a host responds to GRP ARPS requests, begins issuing keepalives and a gateway fails, or in some other way masquerades as a GRP router, it may maliciously attract traffic. Some form of authentication should be investigated. D Authors' Addresses Spencer Giacalone Predictive Systems, Inc. 25a Vreeland Road Florham Park, NJ 07932 Phone: +1 (973) 301-5646 EMail: spencer.giacalone@predictive.com E Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any Expires June 2001 [Page 9] Internet Draft Gateway Response Protocol February, 2001 kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires June 2001 [Page 10]