70 likes | 234 Views
Automatic Router Configuration Protocol (ARCP). v1.1, 18 Nov. 2002 Jeb Linton, EarthLink jrlinton@ieee.org http://www.ietf.org/internet-drafts/draft-linton-arcp-00.txt. Overview. ARCP uses a Client-Server model like DHCP, rather than a Peer-to-Peer model
E N D
Automatic Router Configuration Protocol (ARCP) v1.1, 18 Nov. 2002 Jeb Linton, EarthLink jrlinton@ieee.org http://www.ietf.org/internet-drafts/draft-linton-arcp-00.txt
Overview ARCP uses a Client-Server model like DHCP, rather than a Peer-to-Peer model • Routers first become DHCP “Hosts”, then get router configuration through ARCP • Configuration messages use an “Option”-based format similar to DHCP • Router configuration is set by ARCP Server, not chosen by client
1. ARCP Client Is connected, Obtains DHCP config 3. More Clients join in the same way 4. New connections and addressing collisions are detected and arbitrated by the ARCP Server Standard Operation Internet DHCP/ARCP Server (on Home Gateway, NAT Firewall, or PC) 2. Client Registers with ARCP Server, Obtains Routing config, acts as DHCP Relay Agent
? 2. Other routers may be linked, but there is no Server at first 4. Further operation is ARCP Standard ARCP AutoServer routers are set to give out basic RFC1918 addresses, passwords, routing protocol data and multicast parameters. AutoServer timeout is greater than the DHCP request period. AutoServer Operation • An AutoServer-enabled • Router is turned on, initially • acting as an ARCP client. ? ! 3. After a timeout, the first router will begin to act as a DHCP/ARCP Server in response to any client requests
ARCP Messages and Options • Two Message Formats, Five Types Total • Two-tiered Option structure including Option Type and Option Number • Main Option Types: • Router Options • Interface Options • Protocol Options • Vendor-Specific Options
Advantages • No arbitration between peers • Easy implementation • Routing protocol independent • High security possible using existing protocols • Highly scalable/expandable • Compatible with virtually all common routing configurations
Work Areas • Next Draft revision will address: • Textual errata (e.g. Sections 7.6 and 7.7) • TLS for Secure operation instead of IPSec • Option for Multilink Subnet operation? • Issues arising today…? • Separate Drafts to address: • Multiserver ops for Redundancy and Scaling • Secure Operations