~ubuntu-branches/ubuntu/gutsy/dhcp/gutsy-updates : revision 8

1

2

3

Network Working Group Bill Croft (Stanford University)

4

Request for Comments: 951 John Gilmore (Sun Microsystems)

5

September 1985

6

7

BOOTSTRAP PROTOCOL (BOOTP)

8

9

10

1. Status of this Memo

11

12

This RFC suggests a proposed protocol for the ARPA-Internet

13

community, and requests discussion and suggestions for improvements.

14

Distribution of this memo is unlimited.

15

16

2. Overview

17

18

This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows

19

a diskless client machine to discover its own IP address, the address

20

of a server host, and the name of a file to be loaded into memory and

21

executed. The bootstrap operation can be thought of as consisting of

22

TWO PHASES. This RFC describes the first phase, which could be

23

labeled 'address determination and bootfile selection'. After this

24

address and filename information is obtained, control passes to the

25

second phase of the bootstrap where a file transfer occurs. The file

26

transfer will typically use the TFTP protocol [9], since it is

27

intended that both phases reside in PROM on the client. However

28

BOOTP could also work with other protocols such as SFTP [3] or

29

FTP [6].

30

31

We suggest that the client's PROM software provide a way to do a

32

complete bootstrap without 'user' interaction. This is the type of

33

boot that would occur during an unattended power-up. A mechanism

34

should be provided for the user to manually supply the necessary

35

address and filename information to bypass the BOOTP protocol and

36

enter the file transfer phase directly. If non-volatile storage is

37

available, we suggest keeping default settings there and bypassing

38

the BOOTP protocol unless these settings cause the file transfer

39

phase to fail. If the cached information fails, the bootstrap should

40

fall back to phase 1 and use BOOTP.

41

42

Here is a brief outline of the protocol:

43

44

1. A single packet exchange is performed. Timeouts are used to

45

retransmit until a reply is received. The same packet field

46

layout is used in both directions. Fixed length fields of maximum

47

reasonable length are used to simplify structure definition and

48

parsing.

49

50

2. An 'opcode' field exists with two values. The client

51

broadcasts a 'bootrequest' packet. The server then answers with a

52

'bootreply' packet. The bootrequest contains the client's

53

hardware address and its IP address, if known.

54

55

56

Croft & Gilmore [Page 1]

57

58

59

60

RFC 951 September 1985

61

Bootstrap Protocol

62

63

64

3. The request can optionally contain the name of the server the

65

client wishes to respond. This is so the client can force the

66

boot to occur from a specific host (e.g. if multiple versions of

67

the same bootfile exist or if the server is in a far distant

68

net/domain). The client does not have to deal with name / domain

69

services; instead this function is pushed off to the BOOTP server.

70

71

4. The request can optionally contain the 'generic' filename to be

72

booted. For example 'unix' or 'ethertip'. When the server sends

73

the bootreply, it replaces this field with the fully qualified

74

path name of the appropriate boot file. In determining this name,

75

the server may consult his own database correlating the client's

76

address and filename request, with a particular boot file

77

customized for that client. If the bootrequest filename is a null

78

string, then the server returns a filename field indicating the

79

'default' file to be loaded for that client.

80

81

5. In the case of clients who do not know their IP addresses, the

82

server must also have a database relating hardware address to IP

83

address. This client IP address is then placed into a field in

84

the bootreply.

85

86

6. Certain network topologies (such as Stanford's) may be such

87

that a given physical cable does not have a TFTP server directly

88

attached to it (e.g. all the gateways and hosts on a certain cable

89

may be diskless). With the cooperation of neighboring gateways,

90

BOOTP can allow clients to boot off of servers several hops away,

91

through these gateways. See the section 'Booting Through

92

Gateways' below. This part of the protocol requires no special

93

action on the part of the client. Implementation is optional and

94

requires a small amount of additional code in gateways and

95

servers.

96

97

3. Packet Format

98

99

All numbers shown are decimal, unless indicated otherwise. The BOOTP

100

packet is enclosed in a standard IP [8] UDP [7] datagram. For

101

simplicity it is assumed that the BOOTP packet is never fragmented.

102

Any numeric fields shown are packed in 'standard network byte order',

103

i.e. high order bits are sent first.

104

105

In the IP header of a bootrequest, the client fills in its own IP

106

source address if known, otherwise zero. When the server address is

107

unknown, the IP destination address will be the 'broadcast address'

108

255.255.255.255. This address means 'broadcast on the local cable,

109

(I don't know my net number)' [4].

110

111

112

113

Croft & Gilmore [Page 2]

114

115

116

117

RFC 951 September 1985

118

Bootstrap Protocol

119

120

121

The UDP header contains source and destination port numbers. The

122

BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)

123

and 'BOOTP server' (67). The client sends requests using 'BOOTP

124

server' as the destination port; this is usually a broadcast. The

125

server sends replies using 'BOOTP client' as the destination port;

126

depending on the kernel or driver facilities in the server, this may

127

or may not be a broadcast (this is explained further in the section

128

titled 'Chicken/Egg issues' below). The reason TWO reserved ports

129

are used, is to avoid 'waking up' and scheduling the BOOTP server

130

daemons, when a bootreply must be broadcast to a client. Since the

131

server and other hosts won't be listening on the 'BOOTP client' port,

132

any such incoming broadcasts will be filtered out at the kernel

133

level. We could not simply allow the client to pick a 'random' port

134

number for the UDP source port field; since the server reply may be

135

broadcast, a randomly chosen port number could confuse other hosts

136

that happened to be listening on that port.

137

138

The UDP length field is set to the length of the UDP plus BOOTP

139

portions of the packet. The UDP checksum field can be set to zero by

140

the client (or server) if desired, to avoid this extra overhead in a

141

PROM implementation. In the 'Packet Processing' section below the

142

phrase '[UDP checksum.]' is used whenever the checksum might be

143

verified/computed.

144

145

FIELD BYTES DESCRIPTION

146

----- ----- -----------

147

148

op 1 packet op code / message type.

149

1 = BOOTREQUEST, 2 = BOOTREPLY

150

151

htype 1 hardware address type,

152

see ARP section in "Assigned Numbers" RFC.

153

'1' = 10mb ethernet

154

155

hlen 1 hardware address length

156

(eg '6' for 10mb ethernet).

157

158

hops 1 client sets to zero,

159

optionally used by gateways

160

in cross-gateway booting.

161

162

xid 4 transaction ID, a random number,

163

used to match this boot request with the

164

responses it generates.

165

166

secs 2 filled in by client, seconds elapsed since

167

client started trying to boot.

168

169

170

Croft & Gilmore [Page 3]

171

172

173

174

RFC 951 September 1985

175

Bootstrap Protocol

176

177

178

-- 2 unused

179

180

ciaddr 4 client IP address;

181

filled in by client in bootrequest if known.

182

183

yiaddr 4 'your' (client) IP address;

184

filled by server if client doesn't

185

know its own address (ciaddr was 0).

186

187

siaddr 4 server IP address;

188

returned in bootreply by server.

189

190

giaddr 4 gateway IP address,

191

used in optional cross-gateway booting.

192

193

chaddr 16 client hardware address,

194

filled in by client.

195

196

sname 64 optional server host name,

197

null terminated string.

198

199

file 128 boot file name, null terminated string;

200

'generic' name or null in bootrequest,

201

fully qualified directory-path

202

name in bootreply.

203

204

vend 64 optional vendor-specific area,

205

e.g. could be hardware type/serial on request,

206

or 'capability' / remote file system handle

207

on reply. This info may be set aside for use

208

by a third phase bootstrap or kernel.

209

210

4. Chicken / Egg Issues

211

212

How can the server send an IP datagram to the client, if the client

213

doesnt know its own IP address (yet)? Whenever a bootreply is being

214

sent, the transmitting machine performs the following operations:

215

216

1. If the client knows its own IP address ('ciaddr' field is

217

nonzero), then the IP can be sent 'as normal', since the client

218

will respond to ARPs [5].

219

220

2. If the client does not yet know its IP address (ciaddr zero),

221

then the client cannot respond to ARPs sent by the transmitter of

222

the bootreply. There are two options:

223

224

a. If the transmitter has the necessary kernel or driver hooks

225

226

227

Croft & Gilmore [Page 4]

228

229

230

231

RFC 951 September 1985

232

Bootstrap Protocol

233

234

235

to 'manually' construct an ARP address cache entry, then it can

236

fill in an entry using the 'chaddr' and 'yiaddr' fields. Of

237

course, this entry should have a timeout on it, just like any

238

other entry made by the normal ARP code itself. The

239

transmitter of the bootreply can then simply send the bootreply

240

to the client's IP address. UNIX (4.2 BSD) has this

241

capability.

242

243

b. If the transmitter lacks these kernel hooks, it can simply

244

send the bootreply to the IP broadcast address on the

245

appropriate interface. This is only one additional broadcast

246

over the previous case.

247

248

5. Client Use of ARP

249

250

The client PROM must contain a simple implementation of ARP, e.g. the

251

address cache could be just one entry in size. This will allow a

252

second-phase-only boot (TFTP) to be performed when the client knows

253

the IP addresses and bootfile name.

254

255

Any time the client is expecting to receive a TFTP or BOOTP reply, it

256

should be prepared to answer an ARP request for its own IP to

257

hardware address mapping (if known).

258

259

Since the bootreply will contain (in the hardware encapsulation) the

260

hardware source address of the server/gateway, the client MAY be able

261

to avoid sending an ARP request for the server/gateway IP address to

262

be used in the following TFTP phase. However this should be treated

263

only as a special case, since it is desirable to still allow a

264

second-phase-only boot as described above.

265

266

6. Comparison to RARP

267

268

An earlier protocol, Reverse Address Resolution Protocol (RARP) [1]

269

was proposed to allow a client to determine its IP address, given

270

that it knew its hardware address. However RARP had the disadvantage

271

that it was a hardware link level protocol (not IP/UDP based). This

272

means that RARP could only be implemented on hosts containing special

273

kernel or driver modifications to access these 'raw' packets. Since

274

there are many network kernels existent now, with each source

275

maintained by different organizations, a boot protocol that does not

276

require kernel modifications is a decided advantage.

277

278

BOOTP provides this hardware to IP address lookup function, in

279

addition to the other useful features described in the sections

280

above.

281

282

283

284

Croft & Gilmore [Page 5]

285

286

287

288

RFC 951 September 1985

289

Bootstrap Protocol

290

291

292

7. Packet Processing

293

294

7.1. Client Transmission

295

296

Before setting up the packet for the first time, it is a good idea

297

to clear the entire packet buffer to all zeros; this will place

298

all fields in their default state. The client then creates a

299

packet with the following fields.

300

301

The IP destination address is set to 255.255.255.255. (the

302

broadcast address) or to the server's IP address (if known). The

303

IP source address and 'ciaddr' are set to the client's IP address

304

if known, else 0. The UDP header is set with the proper length;

305

source port = 'BOOTP client' port destination port = 'BOOTP

306

server' port.

307

308

'op' is set to '1', BOOTREQUEST. 'htype' is set to the hardware

309

address type as assigned in the ARP section of the "Assigned

310

Numbers" RFC. 'hlen' is set to the length of the hardware address,

311

e.g. '6' for 10mb ethernet.

312

313

'xid' is set to a 'random' transaction id. 'secs' is set to the

314

number of seconds that have elapsed since the client has started

315

booting. This will let the servers know how long a client has

316

been trying. As the number gets larger, certain servers may feel

317

more 'sympathetic' towards a client they don't normally service.

318

If a client lacks a suitable clock, it could construct a rough

319

estimate using a loop timer. Or it could choose to simply send

320

this field as always a fixed value, say 100 seconds.

321

322

If the client knows its IP address, 'ciaddr' (and the IP source

323

address) are set to this value. 'chaddr' is filled in with the

324

client's hardware address.

325

326

If the client wishes to restrict booting to a particular server

327

name, it may place a null-terminated string in 'sname'. The name

328

used should be any of the allowable names or nicknames of the

329

desired host.

330

331

The client has several options for filling the 'file' name field.

332

If left null, the meaning is 'I want to boot the default file for

333

my machine'. A null file name can also mean 'I am only interested

334

in finding out client/server/gateway IP addresses, I dont care

335

about file names'.

336

337

The field can also be a 'generic' name such as 'unix' or

338

339

340

341

Croft & Gilmore [Page 6]

342

343

344

345

RFC 951 September 1985

346

Bootstrap Protocol

347

348

349

'gateway'; this means 'boot the named program configured for my

350

machine'. Finally the field can be a fully directory qualified

351

path name.

352

353

The 'vend' field can be filled in by the client with

354

vendor-specific strings or structures. For example the machine

355

hardware type or serial number may be placed here. However the

356

operation of the BOOTP server should not DEPEND on this

357

information existing.

358

359

If the 'vend' field is used, it is recommended that a 4 byte

360

'magic number' be the first item within 'vend'. This lets a

361

server determine what kind of information it is seeing in this

362

field. Numbers can be assigned by the usual 'magic number'

363

process --you pick one and it's magic. A different magic number

364

could be used for bootreply's than bootrequest's to allow the

365

client to take special action with the reply information.

366

367

[UDP checksum.]

368

369

7.2. Client Retransmission Strategy

370

371

If no reply is received for a certain length of time, the client

372

should retransmit the request. The time interval must be chosen

373

carefully so as not to flood the network. Consider the case of a

374

cable containing 100 machines that are just coming up after a

375

power failure. Simply retransmitting the request every four

376

seconds will inundate the net.

377

378

As a possible strategy, you might consider backing off

379

exponentially, similar to the way ethernet backs off on a

380

collision. So for example if the first packet is at time 0:00,

381

the second would be at :04, then :08, then :16, then :32, then

382

:64. You should also randomize each time; this would be done

383

similar to the ethernet specification by starting with a mask and

384

'and'ing that with with a random number to get the first backoff.

385

On each succeeding backoff, the mask is increased in length by one

386

bit. This doubles the average delay on each backoff.

387

388

After the 'average' backoff reaches about 60 seconds, it should be

389

increased no further, but still randomized.

390

391

Before each retransmission, the client should update the 'secs'

392

field. [UDP checksum.]

393

394

395

396

397

398

Croft & Gilmore [Page 7]

399

400

401

402

RFC 951 September 1985

403

Bootstrap Protocol

404

405

406

7.3. Server Receives BOOTREQUEST

407

408

[UDP checksum.] If the UDP destination port does not match the

409

'BOOTP server' port, discard the packet.

410

411

If the server name field (sname) is null (no particular server

412

specified), or sname is specified and matches our name or

413

nickname, then continue with packet processing.

414

415

If the sname field is specified, but does not match 'us', then

416

there are several options:

417

418

1. You may choose to simply discard this packet.

419

420

2. If a name lookup on sname shows it to be on this same cable,

421

discard the packet.

422

423

3. If sname is on a different net, you may choose to forward

424

the packet to that address. If so, check the 'giaddr' (gateway

425

address) field. If 'giaddr' is zero, fill it in with my

426

address or the address of a gateway that can be used to get to

427

that net. Then forward the packet.

428

429

If the client IP address (ciaddr) is zero, then the client does

430

not know its own IP address. Attempt to lookup the client

431

hardware address (chaddr, hlen, htype) in our database. If no

432

match is found, discard the packet. Otherwise we now have an IP

433

address for this client; fill it into the 'yiaddr' (your IP

434

address) field.

435

436

We now check the boot file name field (file). The field will be

437

null if the client is not interested in filenames, or wants the

438

default bootfile. If the field is non-null, it is used as a

439

lookup key in a database, along with the client's IP address. If

440

there is a default file or generic file (possibly indexed by the

441

client address) or a fully-specified path name that matches, then

442

replace the 'file' field with the fully-specified path name of the

443

selected boot file. If the field is non-null and no match was

444

found, then the client is asking for a file we dont have; discard

445

the packet, perhaps some other BOOTP server will have it.

446

447

The 'vend' vendor-specific data field should now be checked and if

448

a recognized type of data is provided, client-specific actions

449

should be taken, and a response placed in the 'vend' data field of

450

the reply packet. For example, a workstation client could provide

451

452

453

454

455

Croft & Gilmore [Page 8]

456

457

458

459

RFC 951 September 1985

460

Bootstrap Protocol

461

462

463

an authentication key and receive from the server a capability for

464

remote file access, or a set of configuration options, which can

465

be passed to the operating system that will shortly be booted in.

466

467

Place my (server) IP address in the 'siaddr' field. Set the 'op'

468

field to BOOTREPLY. The UDP destination port is set to 'BOOTP

469

client'. If the client address 'ciaddr' is nonzero, send the

470

packet there; else if the gateway address 'giaddr' is nonzero, set

471

the UDP destination port to 'BOOTP server' and send the packet to

472

'giaddr'; else the client is on one of our cables but it doesnt

473

know its own IP address yet --use a method described in the 'Egg'

474

section above to send it to the client. If 'Egg' is used and we

475

have multiple interfaces on this host, use the 'yiaddr' (your IP

476

address) field to figure out which net (cable/interface) to send

477

the packet to. [UDP checksum.]

478

479

7.4. Server/Gateway Receives BOOTREPLY

480

481

[UDP checksum.] If 'yiaddr' (your [the client's] IP address)

482

refers to one of our cables, use one of the 'Egg' methods above to

483

forward it to the client. Be sure to send it to the 'BOOTP

484

client' UDP destination port.

485

486

7.5. Client Reception

487

488

Don't forget to process ARP requests for my own IP address (if I

489

know it). [UDP checksum.] The client should discard incoming

490

packets that: are not IP/UDPs addressed to the boot port; are not

491

BOOTREPLYs; do not match my IP address (if I know it) or my

492

hardware address; do not match my transaction id. Otherwise we

493

have received a successful reply. 'yiaddr' will contain my IP

494

address, if I didnt know it before. 'file' is the name of the

495

file name to TFTP 'read request'. The server address is in

496

'siaddr'. If 'giaddr' (gateway address) is nonzero, then the

497

packets should be forwarded there first, in order to get to the

498

server.

499

500

8. Booting Through Gateways

501

502

This part of the protocol is optional and requires some additional

503

code in cooperating gateways and servers, but it allows cross-gateway

504

booting. This is mainly useful when gateways are diskless machines.

505

Gateways containing disks (e.g. a UNIX machine acting as a gateway),

506

might as well run their own BOOTP/TFTP servers.

507

508

Gateways listening to broadcast BOOTREQUESTs may decide to forward or

509

rebroadcast these requests 'when appropriate'. For example, the

510

511

512

Croft & Gilmore [Page 9]

513

514

515

516

RFC 951 September 1985

517

Bootstrap Protocol

518

519

520

gateway could have, as part of his configuration tables, a list of

521

other networks or hosts to receive a copy of any broadcast

522

BOOTREQUESTs. Even though a 'hops' field exists, it is a poor idea

523

to simply globally rebroadcast the requests, since broadcast loops

524

will almost certainly occur.

525

526

The forwarding could begin immediately, or wait until the 'secs'

527

(seconds client has been trying) field passes a certain threshold.

528

529

If a gateway does decide to forward the request, it should look at

530

the 'giaddr' (gateway IP address) field. If zero, it should plug its

531

own IP address (on the receiving cable) into this field. It may also

532

use the 'hops' field to optionally control how far the packet is

533

reforwarded. Hops should be incremented on each forwarding. For

534

example, if hops passes '3', the packet should probably be discarded.

535

[UDP checksum.]

536

537

Here we have recommended placing this special forwarding function in

538

the gateways. But that does not have to be the case. As long as

539

some 'BOOTP forwarding agent' exists on the net with the booting

540

client, the agent can do the forwarding when appropriate. Thus this

541

service may or may not be co-located with the gateway.

542

543

In the case of a forwarding agent not located in the gateway, the

544

agent could save himself some work by plugging the broadcast address

545

of the interface receiving the bootrequest into the 'giaddr' field.

546

Thus the reply would get forwarded using normal gateways, not

547

involving the forwarding agent. Of course the disadvantage here is

548

that you lose the ability to use the 'Egg' non-broadcast method of

549

sending the reply, causing extra overhead for every host on the

550

client cable.

551

552

9. Sample BOOTP Server Database

553

554

As a suggestion, we show a sample text file database that the BOOTP

555

server program might use. The database has two sections, delimited

556

by a line containing an percent in column 1. The first section

557

contains a 'default directory' and mappings from generic names to

558

directory/pathnames. The first generic name in this section is the

559

'default file' you get when the bootrequest contains a null 'file'

560

string.

561

562

The second section maps hardware addresstype/address into an

563

ipaddress. Optionally you can also overide the default generic name

564

by supplying a ipaddress specific genericname. A 'suffix' item is

565

also an option; if supplied, any generic names specified by the

566

client will be accessed by first appending 'suffix' to the 'pathname'

567

568

569

Croft & Gilmore [Page 10]

570

571

572

573

RFC 951 September 1985

574

Bootstrap Protocol

575

576

577

appropriate to that generic name. If that file is not found, then

578

the plain 'pathname' will be tried. This 'suffix' option allows a

579

whole set of custom generics to be setup without a lot of effort.

580

Below is shown the general format; fields are delimited by one or

581

more spaces or tabs; trailing empty fields may be omitted; blank

582

lines and lines beginning with '#' are ignored.

583

584

# comment line

585

586

homedirectory

587

genericname1 pathname1

588

genericname2 pathname2

589

...

590

591

% end of generic names, start of address mappings

592

593

hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix

594

hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix

595

...

596

597

Here is a specific example. Note the 'hardwaretype' number is the

598

same as that shown in the ARP section of the 'Assigned Numbers' RFC.

599

The 'hardwaretype' and 'ipaddr' numbers are in decimal;

600

'hardwareaddr' is in hex.

601

602

# last updated by smith

603

604

/usr/boot

605

vmunix vmunix

606

tip ethertip

607

watch /usr/diag/etherwatch

608

gate gate.

609

610

% end of generic names, start of address mappings

611

612

hamilton 1 02.60.8c.06.34.98 36.19.0.5

613

burr 1 02.60.8c.34.11.78 36.44.0.12

614

101-gateway 1 02.60.8c.23.ab.35 36.44.0.32 gate 101

615

mjh-gateway 1 02.60.8c.12.32.bc 36.42.0.64 gate mjh

616

welch-tipa 1 02.60.8c.22.65.32 36.47.0.14 tip

617

welch-tipb 1 02.60.8c.12.15.c8 36.46.0.12 tip

618

619

In the example above, if 'mjh-gateway' does a default boot, it will

620

get the file '/usr/boot/gate.mjh'.

621

622

623

624

625

626

Croft & Gilmore [Page 11]

627

628

629

630

RFC 951 September 1985

631

Bootstrap Protocol

632

633

634

10. Acknowledgements

635

636

Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP

637

bootstraping [2] using RARP [1].

638

639

We would also like to acknowledge the previous work and comments of

640

Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer.

641

642

REFERENCES

643

644

1. Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer. A

645

Reverse Address Resolution Protocol. RFC 903, NIC, June, 1984.

646

647

2. Ross Finlayson. Bootstrap Loading using TFTP. RFC 906, NIC,

648

June, 1984.

649

650

3. Mark Lottor. Simple File Transfer Protocol. RFC 913, NIC,

651

September, 1984.

652

653

4. Jeffrey Mogul. Broadcasting Internet Packets. RFC 919, NIC,

654

October, 1984.

655

656

5. David Plummer. An Ethernet Address Resolution Protocol. RFC

657

826, NIC, September, 1982.

658

659

6. Jon Postel. File Transfer Protocol. RFC 765, NIC, June, 1980.

660

661

7. Jon Postel. User Datagram Protocol. RFC 768, NIC, August, 1980.

662

663

8. Jon Postel. Internet Protocol. RFC 791, NIC, September, 1981.

664

665

9. K. R. Sollins, Noel Chiappa. The TFTP Protocol. RFC 783, NIC,

666

June, 1981.

667

668

669

670

671

672

673

674

675

676

677

678

679

680

681

682

683

Croft & Gilmore [Page 12]

684