Internet DRAFT - draft-giacalone-grp
draft-giacalone-grp
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]
