Table of Contents
Boot(ing) protocols
From (R)ARP to BSDP
ARP and RARP
Bootparamd and BOOTP
Karst Koymans
DHCP
Informatics Institute
University of Amsterdam
TFTP
(version 1.7, 2011/10/10 13:40:02)
Tuesday, October 11, 2011
PXE
Others
ARP
(R)ARP packets
I
Address Resolution Protocol
I
I
I
I
I
RFC 826 (published in 1982)
Translates IP addresses to Ethernet addresses
Uses ethernet type (0x0806)
Is not a boot(ing) protocol
Uses requests (id=1) and replies (id=2)
Hardware Type
Protocol Type
HA Length
PA Length
Operation
Sender Hardware Address (0-3)
Sender Hardware Address (4-5) Sender Protocol Address (0-1)
Sender Protocol Address (2-3) Target Hardware Address (0-1)
Target Hardware Address (2-5)
Target Protocol Address
RARP
ARP packet fields
Hardware Type
Protocol Type
HA Length
PA Length
Operation
Sender Hardware Address
Sender Protocol Address
Target Hardware Address
Target Protocol Address
1 means Ethernet
2048(=0x0800) means IP
6 for Ethernet
4 for IP
1(request), 2(reply)
ethernet source address
source IP address
?(request), !(reply)
destination IP address
I
Reverse Address Resolution Protocol
I
I
I
I
I
Requests (id=3) use
I
I
I
RFC 903 (published in 1984)
6= Inverse Address Resolution Protocol (other ether ⇒ IP)
Translates own Ethernet address to own IP address
Uses its own ethernet type (0x0835)
(Ethernet) broadcast address as destination
Own hardware address as source
Replies (id=4) fill in the looked up IP address
I
For instance using /etc/ethers file
Note that sender and target are swapped on reply
The resulting information is in the Sender Hardware Address
(R)ARP packets
RARP packet fields
Hardware Type
Protocol Type
HA Length
PA Length
Operation
Sender Hardware Address (0-3)
Sender Hardware Address (4-5) Sender Protocol Address (0-1)
Sender Protocol Address (2-3) Target Hardware Address (0-1)
Target Hardware Address (2-5)
Target Protocol Address
Hardware Type
Protocol Type
HA Length
PA Length
Operation
Sender Hardware Address
Sender Protocol Address
Target Hardware Address
Target Protocol Address
1 means Ethernet
2048(=0x0800) means IP
6 for Ethernet
4 for IP
3(request), 4(reply)
ethernet source address
undefined
ethernet (source!) address
?(request), !(reply)
Note that sender is changed and target stays the same on reply
Bootparamd
I
I
I
Gets client name and IP address
I
Gets NFS server and root directory
I
I
BOOTP packet format
Operation Code
Hardware Type Hardware Length
Transaction Identifier
Seconds Elapsed
(Unused)
Client IP Address
Your IP Address
Server IP Address
Relay IP Address
..
.
RFC 951 (published in 1985)
with clarifications in RFC 1532 (published in 1993)
BOOTP Vendor Information Extensions
I
RPC/bootparams/getfile
I
Bootstrap protocol
I
Not much used outside SunOS/Solaris
RPC/bootparams/whoami
I
I
I
Introduced by Sun, uses remote procedure call
I
I
BOOTP
RFC 1048, 1084, 1395 (published in 1988; obsolete)
RFC 1497, 1533 (published in 1993; obsolete)
RFC 2132 (with DHCP options)
updated by RFC 3442, 3942, 4361, 4833
BOOTP packet format (continued)
Hops
..
.
Client Hardware Address
..
. (16 bytes)
Server Hostname
..
. (64 bytes)
Boot Filename
..
. (128 bytes)
Vendor Specific Area
..
. (64 bytes)
BOOTP fields
BOOTP fields (continued)
BOOTP fields
BOOTP fields
Opcode
Hardware Type
Hardware Length
Hops
Transaction Identifier
Seconds Elapsed
1 (request), 2 (reply)
1 (ethernet)
6
0 (for client), increased by relay
number to match request and reply
number of seconds since boot
BOOTP fields (continued)
Client IP
Your IP
Server IP
Relay IP
filled in by client (if known)
provided by boot server
address of boot server
address of relay server
BOOTP versus RARP
BOOTP fields
Client Hardware Address
Server Hostname
(sname)
Boot Filename
(file)
Vendor Specific Area
ethernet address of client
optional name of wanted server
set by client (and by server)
server supplied full path boot file
possibly hinted by client on request
used for various extensions to BOOTP
I
RARP is link layer, needs kernel modification
I
RARP only supplies IP address
BOOTP is UDP/IP based
I
I
I
Chicken/egg problems (client cannot reply to ARP)
BOOTP supplies more information
DHCP
DHCP packet format
Operation Code
I
Dynamic Host Configuration protocol
I
I
Hardware Type Hardware Length
Transaction Identifier
Seconds Elapsed
Flags
Client IP Address
Your IP Address
Server IP Address
Relay IP Address
..
.
RFC 2131 (published in 1997)
DHCP Options and BOOTP Vendor Extensions
I
RFC 2132 (published in 1997)
DHCP packet format (continued)
..
.
Client Hardware Address
..
. (16 bytes)
Server Hostname
..
. (64 bytes)
Boot Filename
..
. (128 bytes)
Options
..
. (variable number of bytes)
DHCP versus BOOTP
I
DHCP has more space for options
I
DHCP can overload sname and file fields
DHCP can configure unknown clients
I
I
I
combines static/dynamic assignments
DHCP has many more states, uses leases
Hops
DHCP fields
Same as BOOTP with some extensions
I Flags
I
Server IP address is the address of the next bootstrap server
I
Options instead of vendor extensions
DHCP options (continued)
Generic, IP, TCP, Application server/service options, for
instance
I
I
I
I
I
Domain Name Server Option
Interface MTU Option
TCP Keepalive Interval Option
Simple Mail Transport Protocol (SMTP) Server Option
DHCP specific, like
I
I
At the moment only the “broadcast flag”, for clients that can
not receive unicasts before having an IP address configured
I
I
DHCP options
I
I
Requested IP Address
IP Address Lease Time
Option Overload
DHCP Message Type (DHCPDISCOVER, DHCPOFFER,
DHCPREQUEST, DHCPDECLINE, DHCPACK, DHCPNAK,
DHCPRELEASE, DHCPINFORM)
TFTP
I
Trivial File Transfer Protocol
I
I
I
RFC 1350 (published in 1992)
Uses lock-step protocol
Revision 2
I
fixes a bug called “Sorcerer’s Apprentice Syndrome”
PXE
BSDP
I
Preboot eXecution Environment
I
I
I
Uses (slightly modified) DHCP
Uses (possibly multicast) TFTP
Defines own boot protocol using DHCP packet format
I
Has support for multiple TFTP servers
I
Boot Service Discovery Protocol
I
Works within DHCP context and uses
I
I
Request: Vendor class identifier (option 60)
Response: Encapsulated vendor-specific options (option 43)