Automatic Router Configuration Protocol ARCP v 1 1







- Slides: 7
Automatic Router Configuration Protocol (ARCP) v 1. 1, 18 Nov. 2002 Jeb Linton, Earth. Link jrlinton@ieee. org http: //www. ietf. org/internet-drafts/draft-linton-arcp-00. txt Linton, IETF 11/02
Overview ARCP uses a Client-Server model like DHCP, rather than a Peer-to-Peer model n n n 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 Linton, IETF 11/02 2
Standard Operation Internet DHCP/ARCP Server (on Home Gateway, NAT Firewall, or PC) 1. ARCP Client Is connected, Obtains DHCP config 2. Client Registers with ARCP Server, Obtains Routing config, acts as DHCP Relay Agent 3. More Clients join in the same way 4. New connections and addressing collisions are detected and arbitrated by the ARCP Server Linton, IETF 11/02 3
Auto. Server Operation 1. An Auto. Server-enabled 2. Router is turned on, initially 3. acting as an ARCP client. 2. Other routers may be linked, but there is no Server at first ? ! ? 3. After a timeout, the first router will begin to act as a DHCP/ARCP Server in response to any client requests 4. Further operation is ARCP Standard ARCP Auto. Server routers are set to give out basic RFC 1918 addresses, passwords, routing protocol data and multicast parameters. Auto. Server timeout is greater than the DHCP request period. Linton, IETF 11/02 4
ARCP Messages and Options Two Message Formats, Five Types Total n Two-tiered Option structure including Option Type and Option Number n Main Option Types: n q q Router Options Interface Options Protocol Options Vendor-Specific Options Linton, IETF 11/02 5
Advantages No arbitration between peers n Easy implementation n Routing protocol independent n High security possible using existing protocols n Highly scalable/expandable n Compatible with virtually all common routing configurations n Linton, IETF 11/02 6
Work Areas n Next Draft revision will address: q q n 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: q q Multiserver ops for Redundancy and Scaling Secure Operations Linton, IETF 11/02 7