idnits 2.17.1 draft-ietf-ipsec-dhcp-over-ike-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 155: '...security gateway SHOULD reply with DHC...' RFC 2119 keyword, line 170: '...ets having the final EAP payloads MUST...' RFC 2119 keyword, line 179: '...the client MUST use wildcard address r...' RFC 2119 keyword, line 180: '... security gateway MUST then narrow the...' RFC 2119 keyword, line 187: '...security gateway MUST narrow the traff...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 253, but not defined == Missing Reference: 'DHCP' is mentioned on line 128, but not defined == Missing Reference: 'CERT' is mentioned on line 255, but not defined -- Obsolete informational reference (is this intentional?): RFC 1533 (Obsoleted by RFC 2132) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Security Protocol Working Group (IPSEC) T. Kivinen 2 Expires: 2 October 2003 4 DHCP over IKE 6 Status of This Memo 8 This document is a submission to the IETF IP Security Protocol 9 (IPSEC) Working Group. Comments are solicited and should be 10 addressed to the working group mailing list (ipsec@lists.tislabs.com) 11 or to the editor. 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes method of getting the IP security (IPsec) remote 36 access client configuration information from the security gateway by 37 tunneling dynamic host configuration protocol (DHCP) packets inside the 38 internet key exchange (IKE) version 2 protocol. 40 Table of Contents 42 1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 2 43 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 44 3. DHCP-over-IKE protocol . . . . . . . . . . . . . . . . . . . . . 3 45 4. DHCP packet formatting . . . . . . . . . . . . . . . . . . . . . 6 46 5. DHCP payload . . . . . . . . . . . . . . . . . . . . . . . . . . 7 47 6. Format of DHCPv4 packet . . . . . . . . . . . . . . . . . . . . 7 48 7. Typical DHCPv4 packet exchange . . . . . . . . . . . . . . . . . 10 49 8. Normative References . . . . . . . . . . . . . . . . . . . . . . 12 50 9. Non-Normative References . . . . . . . . . . . . . . . . . . . . 12 51 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 53 1. Requirements 55 The DHCP-over-IKE protocol described here fullfills the following 56 requirements: 58 o Get the IP address for the client "in time" for use in the Traffic 59 Selectors. 61 o Protocol must be able to be use any method of getting the actual 62 configuration data in the security gateway end. This is including but 63 not limiting to: RADIUS, DHCPv4, LDAP, DHCPv6, RS/RA-stateless-IPv6, 64 Diameter, PIB, or local configuration information database in the 65 security gateway. 67 o The configuration protocol might be tied to the EAP authentication 68 progress, i.e for some cases the authentication of the client must be 69 done first before the security gateway can get the configuration 70 information for that client. 72 o It should be possible for the client to get the same address each 73 time it requests it. This implies some kind of persistent 74 "hardware"/node identifier (note "hardware"/node ID != IKE ID). 76 2. Introduction 78 The basic protocol is to put the DHCP [RFC2131] packets inside the IKEv2 79 packets as separate payload(s). This does not imply that either end 80 actually has to use DHCP for configuration, but we are simply reusing 81 the existing packet format, which allows wide variety of configuration 82 options. This also allows us to support all current and future 83 configuration needs as defined in the DHCP protocol. 85 The basic flow of the DHCP exchange is: 87 Server 1 Client Server 2 88 -------- ------ -------- 89 <----------- DHCPDISCOVER (broadcast) ---------> 91 DHCPOFFER --------------> 93 <------------------ DHCPOFFER 95 <------------ DHCPREQUST (broadcast) ----------> 97 <-------------------- DHCPACK 99 The DHCPDISCOVER and DHCPOFFER packets might be missing if the client 100 already have configuration and only wants to request that it can 101 actually use it. The actual binding for the addres happens during the 102 DHCPACK packet. 104 3. DHCP-over-IKE protocol 106 The protocol flow of the DHCP-over-IKE combined with EAP is as follows: 108 Client Security Gateway 109 ------ ---------------- 110 HDR, SAi1, KEi, Ni --> 112 <-- HDR, SAr1, KEr, Nr, 113 [CERTREQ] 115 HDR, SK {IDi, [CERTREQ,] 116 [IDr,] SAi2, 117 TSi, TSr, DHCP} --> 119 <-- HDR, SK {IDr, [CERT,] 120 AUTH, [EAP,] DHCP} 122 (following packets can be repeated as many times as needed) 123 HDR, SK {[EAP,] [DHCP]} --> 125 <-- HDR, SK {[EAP,] [DHCP]} 127 HDR, SK {[EAP,] [AUTH,] 128 [DHCP] } --> 130 <-- HDR, SK {[EAP,] [AUTH,], 131 [DHCP,] SAr2, 132 TSi, TSr } 134 The first two packets are the normal IKE_SA_INIT exchange. The IKE_AUTH 135 phase following that can take as many steps as needed to finish both the 136 EAP and DHCP protocols. The EAP protocol is finished when the security 137 gateway sends EAP(success) packet. The DHCP protocol is finished when 138 the security gateway sends DHCP(ACK) packet. 140 In the first IKE_AUTH packet the client will include the DHCP payload 141 indicating it wants to have configuration from the security gateway. 142 This DHCP payload may either be DHCPDISCOVER (the client does not 143 already have address, i.e it is in DHCP init state) or DHCPREQUST 144 (client is requesting for previously given address, i.e it is in DHCP 145 init-reboot state). If the first packet is DHCPDISCOVER then the 146 security gateway will eventually reply with DHCPOFFER payload, and then 147 client sends DHCPREQUEST payload. When security gateway replies to the 148 DHCPREQUEST with DHCPACK then the configuration protocol is finished. 150 If the first DHCP payload is DHCPREQUEST, the reply might either be 151 DHCPACK (finishing the configuration) or DHCPNAK, meaning that the 152 client was denied to use of requested address. After DHCPNAK the client 153 MUST start the configuration protocol from the beginning by sending 154 DHCPDISCOVER packet (i.e move to the DHCP init state). If the paramters 155 are not accetable the security gateway SHOULD reply with DHCPNAK instead 156 of waiting for the client to timeout the DHCP rebooting phase and fall 157 back to DHCP init state (i.e back to sending DHCPDISCOVER). 159 The EAP process might be going on before, after or simultaneously to the 160 configuration progress. I.e in case of RADIUS [RFC2865] backend is used 161 then the configuration data might be only known after the authentication 162 process is finished, in which case the security gateway will postpone 163 replying to the DHCPDISCOVER or DHCPREQUEST until EAP prosess is 164 finished. 166 The AUTH payload in the reply to the first IKE_AUTH packet is normal 167 authentication packet of the security gateway, i.e either the signature 168 or the MAC depending which authentication method is used. If the EAP 169 method is such that it creates a shared key between the client and 170 security gateway then the packets having the final EAP payloads MUST 171 also have AUTH payloads created using that shared key. 173 When the security gateway detects that both EAP and DHCP configuration 174 is finished it will send reply packet containing the final EAP or DHCP 175 payload (depending which of those ended last), and payloads needed to 176 complete the CREATE_CHILD_SA (i.e SAr2, and Traffic Selectors). 178 When using DHCP to request configuration data from the security gateway 179 the client MUST use wildcard address range in traffic selectors when 180 starting to create the SA, and the security gateway MUST then narrow the 181 traffic selectors down. I.e the client uses address range from 0.0.0.0 182 to 255.255.255.255 in TSi and TSr when sending the SAi2. The protocol 183 and port range can be specified, but address normally cannot be, as it 184 is not yet known (the client is requesting it from the security 185 gateway). 187 The security gateway MUST narrow the traffic selectors so that the TSi 188 includes only the configured IP address of the client, and the TSr 189 SHOULD include the subnet(s) accessable through the security gateway. 191 Note, that since the security gateway might be using external 192 configuration backend, the client needs to use normal DHCP 193 retransmission policies when sending the requests. I.e if the security 194 gateway does not reply with a packet containing DHCP payload, the client 195 should send new IKE packet having the same DHCP payload (but new message 196 id), so that security gateway has possibility to sending back the reply 197 (security gateway cannot send the DHCP packet before client sends next 198 request to it), and if client is trying to use DHCPREQUEST and does not 199 get any reply back (or receives DHCPNAK) then client starts again with 200 DHCPDISCOVER. 202 Security gateway might also send multiple DHCPOFFER packets, and client 203 can select the one that suits it best to be used. 205 The security gateway SHOULD wait for configurable time (few seconds) for 206 the replies from external configuration backends and collect all replies 207 to the reply packet (as separate DHCP payloads) going back to the 208 client. It can also send reply back immediately when it has first reply, 209 to fasten up the process (for example in case where it knows there is 210 only one DHCP server in the network). If no replies are received during 211 that time the security gateway MUST send reply to the IKE packet, 212 without the DHCP payload. 214 Example data flow with new client doing DHCP and one-time-password EAP: 216 Client Security Gateway 217 ------ ---------------- 218 HDR, SAi1, KEi, Ni --> 220 <-- HDR, SAr1, KEr, Nr, 221 [CERTREQ] 223 HDR, SK {IDi, [CERTREQ,] 224 [IDr,] SAi2, 225 TSi(0.0.0.0-255.255.255.255), 226 TSr(0.0.0.0-255.255.255.255), 227 DHCP(DISCOVER)} --> 229 <-- HDR, SK {IDr, [CERT,] 230 AUTH, 231 EAP(OTP-Challenge), 232 DHCP(OFFER, ip=1.2.3.4)} 234 HDR, SK {EAP(OTP-Reply), 235 DHCP(REQUEST, 236 ip=1.2.3.4) } --> 238 <-- HDR, SK {EAP(success), 239 DHCP(ACK, ip=1.2.3.4), 240 SAr2, 241 TSi(1.2.3.4-1.2.3.4), 242 TSr(0.0.0.0- 243 255.255.255.255)} 245 Another example doing signature authentication for both ends, and client 246 requesting reuse of the previous address: 248 Client Security Gateway 249 ------ ---------------- 250 HDR, SAi1, KEi, Ni --> 252 <-- HDR, SAr1, KEr, Nr, 253 [CERTREQ] 255 HDR, SK {IDi, [CERT], 256 [CERTREQ,] [IDr,] 257 AUTH, SAi2, 258 TSi(0.0.0.0-255.255.255.255), 259 TSr(0.0.0.0-255.255.255.255), 260 DHCP(REQUEST, 261 ip=1.2.3.4)} --> 263 <-- HDR, SK {IDr, [CERT,] 264 AUTH, 265 DHCP(ACK, ip=1.2.3.4), 266 SAr2, 267 TSi(1.2.3.4-1.2.3.4), 268 TSr(0.0.0.0- 269 255.255.255.255)} 271 4. DHCP packet formatting 273 The DHCP packet is filled as normally, except the client will use 274 hardware type (htype) of 31 signifying an IPsec tunnel mode virtual 275 interface. The chaddr field MUST include an identifier unique to the 276 virtual subnet. The client MUST use the same chaddr field in all 277 subsequent messages within the same exchange. In addition, the chaddr 278 SHOULD be persistent between reboots so that the DHCP server will be 279 able to re-assign the same address if desired. 281 The hlen and chaddr fields SHOULD be determined as follows: 283 o If one or more LAN interfaces are available, the hlen and chaddr 284 fields SHOULD be determined from the active LAN interface with the 285 lowest interface number. If no active LAN interface is available, 286 then the parameters SHOULD be determined from the LAN interface with 287 the lowest interface number. This enables the chaddr to be persistent 288 between reboots, as long as the LAN interface hardware is not 289 removed. 291 o If there is no LAN interface, the chaddr field SHOULD be determined 292 by concatenating x'4000', the IPv4 address of the interface supplying 293 network connectivity, and an additional octet. The x'4000' value 294 indicates a locally administered unicast MAC address, thus 295 guaranteeing that the constructed chaddr value will not conflict with 296 a globally assigned value. 298 The additional octet (which MAY represent an interface number) SHOULD 299 be persistent between reboots, so that the chaddr value will be 300 persistent across reboots if the assigned IPv4 address remains 301 consistent. 303 If the above prescription is followed, then the chaddr will always be 304 unique on the virtual subnet provided that the remote host only brings 305 up a single tunnel to the security gateway. Where a LAN interface is 306 available, the chaddr will be globally unique. When a non-LAN interface 307 is available and a unique Internet address is assigned to the remote 308 host, the chaddr will also be globally unique. Where a private IP 309 address is assigned to a non-LAN interface, it will not be globally 310 unique. 312 5. DHCP payload 314 The DHCP payload, is used to exchange configuration information between 315 IKE peers. 317 The DHCP Payload is defined as follows: 319 1 2 3 320 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 ! Next Payload !C! RESERVED ! Payload Length ! 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 ! Packet Type ! ! 325 +-+-+-+-+-+-+-+-+ ! 326 ! ! 327 ~ Configuration Packet ~ 328 ! ! 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 o Packet Type - Type of the DHCP packet. Currently defined types 332 are: 334 Packet Type Value 335 =========== ===== 336 RESERVED 0 337 DHCPv4 packet [RFC2131] 1 339 o Configuration Packet (variable length) - Contains the 340 configuration packet. The exact packet format depends of the 341 packet type. 343 The payload type for the DHCP Payload is sixteen (16). This document 344 describes the DHCPv4 packet type, and other documents may later describe 345 other packet formats (for example DHCPv6). 347 If unknown DHCP Payload packet type is received then UNKNOWN-DHCP- 348 PAYLOAD-TYPE notification MUST be sent back. This allows future versions 349 to probe if the newer packet type is supported or not (i.e if server 350 responds with notification, then it is not supported, if it replies or 351 does not reply at all immediately, then it is supported). 353 6. Format of DHCPv4 packet 355 The typical packet put inside the DHCP Payload will be (described here 356 only to make it easier for implementators to understand what goes where, 357 see [RFC2131] for full details): 359 1 2 3 360 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 ! op ! htype ! hlen ! hops ! 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 ! xid ! 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 ! secs ! flags ! 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 ! ciaddr ! 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 ! yiaddr ! 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 ! siaddr ! 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 ! giaddr ! 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 ! chaddr ! 377 ! (16 bytes) ! 378 ! ! 379 ! ! 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 ! sname ! 382 ! (64 bytes) ! 383 ~ ~ 384 ! ! 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 ! file ! 387 ! (128 bytes) ! 388 ~ ! 389 ! ! 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 ! byte 99 (0x63)!byte 130 (0x82)! byte 83 (0x53)! byte 99 (0x63)! 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 ! opt53 ! option len (1)! opt53 value ! opt50 ! 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 ! option len (4)! requested IP address ! 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 ! ...... ! opt255 ! 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 o op - BOOTP message option code / message type, 1 = BOOTREQUEST 401 (from client to server), 2 = BOOTREPLY (from server to client) 403 o htype - Hardware address type, 31 = IPsec tunnel mode virtual 404 interface [RFC3456]. 406 o hlen - Hardware address length = 6. 408 o hops - Client sets to zero, optionally used by relay agents when 409 booting via a relay agent. 411 o xid - Transaction ID, a random number chosen by the client, used 412 by the client and server to associate messages and responses 413 between a client and a server. 415 o secs - Filled in by client, seconds elapsed since client began 416 address acquisition or renewal process. 417 o flags - Flags (normally zero). 419 o ciaddr - Client IP address; only filled in if client is in 420 BOUND, RENEW or REBINDING state and can respond to ARP requests, 421 i.e in normal initial exchange always zero, i.e client fill with 422 zeros and the server copies from the request packet. 424 o yiaddr - 'your' (client) IP address. Never filled in by the 425 client, sent by the server to client telling the clients new IP 426 address. 428 o siaddr - IP address of next server to use in bootstrap. Normally 429 zero. 431 o giaddr - Relay agent IP address, used in booting via a relay 432 agent. Packets inside the DHCP payload this is normally set to 433 zero. 435 o chaddr - Client hardware address. Filled in by the client as 436 specified in section 4. 438 o sname - Optional server host name, null terminated string. 439 Normally zero. 441 o file - Boot file name, null terminated string; "generic" name 442 or null in DHCPDISCOVER, fully qualified directory-path name in 443 DHCPOFFER. Normally zero. 445 o byte 99, 130, 83, 99 - Magic cookie. 447 o opt53 - DHCP Message Type. 449 o option len - Length of the option in bytes not including the 450 option tag and this length byte. 452 o opt53 value - Type of the DHCP message. Client normally first 453 send DHCPDISCOVER, and the server replies with DHCPOFFER. Then 454 client finishes the exchange by sending DHCPREQUEST and server 455 verifies that exchange is done by DHCPACK. 457 Type Value 458 ==== ===== 459 DHCPDISCOVER 1 460 DHCPOFFER 2 461 DHCPREQUEST 3 462 DHCPDECLINE 4 463 DHCPACK 5 464 DHCPNAK 6 465 DHCPRELEASE 7 466 DHCPINFORM 8 468 o opt50 - Requested IP Address. Only present in the DHCPREQUEST, 469 when client requests to be allowed to use this IP address. 471 o requested IP address - IP address client requests to use. Client 472 copies the ciaddr field from the DHCPOFFER to here when sending 473 DHCPREQUEST. 475 o opt255 - End of options. 477 Some other useful options [RFC1533] and their formats are: 479 o Pad - opt0, no data. Used for padding. 481 o Subnet mask - opt1, data: 4 subnet mask bytes. 483 o Domain name server - opt6, data: 4 * N address bytes for N dns 484 servers. 486 o Hostname - opt12, data: N bytes of hostname. 488 o NBNS - opt44, data: 4 * N address bytes for N NetBIOS name servers. 490 o IP address lease time - opt51, data: 4 bytes, lease time in seconds. 492 o Server identifier - opt54, data: 4 bytes, address of the DHCP server, 493 send by server, and copied back in client if known. 495 o Parameter request list - opt55, data: N bytes, each byte specifying 496 one option which is requested from the server (client sends this, 497 server tries to put all these options in its reply). 499 o Option overload - opt52, data: 1 byte. Value 1 means that the file 500 field contains options instead of its normal contents. Value 2 means 501 that sname fields contains options, and value 3 means that both of 502 those fields contain options. 504 7. Typical DHCPv4 packet exchange 506 The client will first create DHCPDISCOVER payload, and fill in the 507 following data: 509 o op - 1 = BOOTPREQUEST 511 o htype - 31 = IPsec tunnel mode virtual interface 513 o hlen - 6 514 o xid - random transaction id 516 o chaddr - hardware address, as specified in section 4. 518 o magic - bytes 99, 130, 83, 99 520 o DHCP Message Type option - bytes 53, 1, 1 522 o Parameter request list option - bytes 55, n, n bytes of option 523 numbers, of which the client wants to request. 524 o End of options - bytes 255 526 All other fields are filled with zeros. 528 The server will reply with DHCPOFFER payload, with following data: 530 o op - 2 = BOOTREPLY 532 o yiaddr - IP address offered for client 534 o magic - bytes 99, 130, 83, 99 536 o DHCP Message Type option - bytes 53, 1, 2 538 o Server identifier - bytes 51, 4, IP address identifying the server 539 giving out information (DHCP server, security gateway etc). 541 o Other configuration options. 543 o End of options - bytes 255 545 All other fields are copied form the DHCPDISCOVER packet. DHCP options 546 are not copied from the DHCPDISCOVER packet. 548 Those first two packets can be ignored if client already has IP address 549 and wants to try to use that one. 551 Client will request to use given address by sending DHCPREQUEST payload, 552 with following data: 554 o op - 1 BOOTREQUEST 556 o htype, hlen, xid, chaddr - same as DHCPDISCOVER (== copied from 557 DHCPOFFER). 559 o yiaddr - filled with zero 561 o magic - bytes 99, 130, 83, 99 563 o DHCP Message Type option - bytes 53, 1, 3 565 o Requested IP Address - bytes 50, 4, IP address to be requested (i.e 566 the yiaddr from the DHCPOFFER or the old IP address). 568 o Server identifier - bytes 51, 4, IP address - copied from the 569 DHCPOFFER (if trying to use previous IP address this should be filled 570 with the value from the previous run). 572 o Parameter request list option - bytes 55, n, n bytes of option 573 numbers, of which the client wants to request. 575 o Other options can be copied from the DHCPREQUEST payload. 577 The server will reply with DHCPACK payload, and finish the configuration 578 protocol. The DHCPACK is filled with following data: 580 o op - 2 = BOOTREPLY 582 o yiaddr - IP address offered for client 584 o magic - bytes 99, 130, 83, 99 586 o DHCP Message Type option - bytes 53, 1, 5 588 o Server identifier - bytes 51, 4, IP address identifying the server 589 giving out information (DHCP server, security gateway etc). 591 o Other configuration options. 593 o End of options - bytes 255 595 The option should be same that what was in the DHCPOFFER payload. 597 8. Normative References 599 [RFC2131] 600 Droms R., "Dynamic Host Configuration Protocol", March 1997 602 9. Non-Normative References 604 [RFC2865] 605 Rigney, C., S. Willens, A. Rubens, and Simpson W., "Remote 606 Authentication Dial In User Service (RADIUS)", June 2000. 608 [RFC1533] 609 Alexander S., and Droms R., "DHCP Options and BOOTP Vendor 610 Extensions", October 1993. 612 [RFC3456] 613 Patel B., B. Adoba, S. Kelly, and Gupta V., "Dynamic Host 614 Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel 615 Mode", January 2003. 617 10. Authors' Addresses 619 Tero Kivinen 620 SSH Communications Security Corp 621 Fredrikinkatu 42 622 FIN-00100 HELSINKI 623 Finland 624 E-mail: kivinen@ssh.fi 626 -- 627 kivinen@ssh.fi 628 SSH Communications Security http://www.ssh.fi/ 629 SSH IPSEC Toolkit http://www.ssh.fi/ipsec/