idnits 2.17.1 draft-handley-aap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an Authors' Addresses Section. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** 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 90: '...ast STARTUP-WAIT SHOULD NOT respond to...' RFC 2119 keyword, line 105: '...in such a message MUST be the complete...' RFC 2119 keyword, line 107: '... MUST NOT be spilt across multiple A...' RFC 2119 keyword, line 112: '...xpiry time, this MAY be used to raise ...' RFC 2119 keyword, line 113: '...cured. Addresses SHOULD still be alloc...' (37 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 1997) is 9623 days in the past. Is this intentional? 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 section? '1' on line 43 looks like a reference -- Missing reference section? '2' on line 47 looks like a reference -- Missing reference section? '10' on line 79 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force MALLOC WG 3 Internet Draft M. Handley 4 draft-handley-aap-00.txt ISI 5 December 15, 1997 6 Expires: June 1998 8 Multicast Address Alloctation Protocol (AAP) 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 ABSTRACT 32 The document defines a Multicast Address Allocation 33 Protocol (AAP) that forms a part of a larger multicast 34 address allocation architecture currently being defined. 35 AAP addresses the specific issue of intra-domain 36 multicast address allocation between multicast address 37 allocation servers. 39 1 Introduction 41 This document defines a Multicast Address Allocation Protocol (AAP) 42 that forms a part of a larger multicast address allocation 43 architecture[1]. The general framework with which AAP is designed to 44 operate is best describes by describing the process by which a 45 multicast address is allocated: 47 1. As a continuous process, a higher level protocol, MASC [2], 48 provides a multicast address set to an allocation domain 49 that multicast addresses should be allocated out of. 51 2. MASC routers periodically send advertisements of this 52 address set to Multcast Address Allocation Servers (MAAS) 53 within the allocation domain using AAP address-set 54 advertisement messages. 56 3. When a client requires a multicast address, it sends a 57 request to a MAAS server for information about the scope 58 zones that include the server. The MAAS server returns this 59 information. 61 4. The client then chooses a scope zone, and requests an 62 address for a certain period of time. 64 5. The MAAS server chooses an address from the address set 65 that is not currently in use, and multicasts an AAP 66 prospective-announcement message to all the other MAAS 67 servers in the allocation domain. If no-one objects to this 68 announcement, then the MAAS server starts to periodically 69 multicast an AAP address-in-use message to all the MAAS 70 servers in the allocation domain, and it returns the 71 address to the client to use. 73 1.1 Terminology 75 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 76 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 77 and "OPTIONAL" are to be interpreted as described in RFC 2119 [10] 78 and indicate requirement levels for compliant SIP implementations. 80 1.2 Definitions 82 2 Specification of Behaviour 84 Within an allocation domain, MAAS servers are all multicast peers - 85 there is no hierarchy or configured peering. To allocate an address, 86 a MAAS server should have been listening to AAP address-set messages 87 and AAP address-in-use messages for a considerable period of time 88 (known at STARTUP-WAIT) so that it has a good idea of currently 89 available addresses. MAAS servers that have not been listening for at 90 least STARTUP-WAIT SHOULD NOT respond to a client's request for an 91 address. 93 2.1 AAP Packet Types 94 The following packet types are defined: 96 ADDRESS-SET-ANNOUNCE 98 This AAP message is sent from a MASC router to all the MAAS servers 99 in an allocation domain. It lists a number of address-sets, each of 100 which has an associated lifetime. The announcement contains a 101 timestamp to detect replays or broken clocks, a refresh time, and the 102 address of the last MASC router to send an ADDRESS-SET-ANNOUNCE 103 message to this group. 105 The address-set contained in such a message MUST be the complete 106 address-set available to MAAS servers at that time. An address-set 107 MUST NOT be spilt across multiple ADDRESS-SET-ANNOUNCE messages. 109 The expiry time is the time by which all MAAS servers within the 110 domain should reasonably have heard a new ADDRESS-SET-ANNOUNCE 111 message. If no ADDRESS-SET-ANNOUNCE message is forthcoming by this 112 expiry time, this MAY be used to raise alarms that some unexpected 113 failure has occured. Addresses SHOULD still be allocated by such a 114 MAAS server, but request protocols that permit it MAY report a lack 115 of confidence in the address. 117 ADDRESS-SET-ANNOUNCE messages MAY alternate between several 118 cooperating MASC routers. Each ADDRESS-SET-ANNOUNCE message contains 119 the address of the last router to send such a message to the domain. 120 This information is present to detect cases where two MASC routers 121 are sending messages to the domain without hearing each others 122 messages. It may not be counted upon for any other purpose. 124 ADDRESS-SET-ANNOUNCE messages MUST be digitally signed by the router 125 that sends them. MAAS servers MAY be configured to ignore ADDRESS- 126 SET-ANNOUNCE messages from unknown routers. 128 SERVER-SIGNATURE 130 This AAP message gives the public key of a new server and the expiry 131 time for this key. Such a server can be a new MAAS server or a new 132 MASC router. This key MUST be digitally signed by one or more 133 additional servers. It may be multicast from any node in the 134 allocation domain to all the MAAS servers in the domain, and is used 135 to bootstrap the trust of both MASC routers and MAAS servers. 137 PROVISIONAL-ADDRESS-ALLOCATION 139 This AAP message is multicast from a MAAS server attempting to 140 allocate an address to all other MAAS servers in the domain. The 141 message contains a list of the addresses being requested, the 142 beginning and end times for the allocation, and a request sequence 143 number. 145 The MAAS server sending this message has already listened to other 146 announcements, and is reasonably certain that the addresses listed 147 are not in use. It sends this message to check that it has not missed 148 a recent announcement by another MAAS server. It expects that no 149 reply will be forthcoming, but waits ANNOUNCE-WAIT seconds to ensure 150 this is the case. 152 Two possible messages might be received that would indicate a problem 153 with the announcement. 155 -ADDRESS-SET-ANNOUNCE might be sent by a MASC router to indicate 156 that the address allocation was not valid for the address-set 157 currently available. This is extremely unlikely to occur with a 158 compliant MAAS server, and MASC routers are not required to 159 listen to AAP PROVISIONAL-ADDRESS-ALLOCATION messages. 161 -ADDRESS-IN-USE might be sent be another MAAS server to indicate 162 that the address was already in use. This can be sent if the 163 same address is already allocated for the same time interval. 164 In either case, the MAAS server SHOULD change its allocation and 165 send another PROVISIONAL-ADDRESS-ALLOCATION message with the 166 same request sequence number. The only exception to this is if 167 the MAAS server suspects a denial of service attack is in 168 progress (see section 5.1). 170 This message MAY be digitally signed by the MAAS server sending it. 172 ADDRESS-IN-USE 174 This AAP message is multicast periodically from a MAAS server to all 175 other MAAS servers in the domain to indicate that addresses are in 176 use. The message contains a list of addresses, each with an 177 associated start and stop time. 179 This message may also be sent by any MAAS server that notices a 180 PROVISIONAL-ADDRESS-ALLOCATION message that would cause a clash. See 181 section XXX for details of the timing of such response messages. 183 This message MAY be digitally signed by the MAAS server sending it. 185 ADDRESS-DELETION 187 This AAP message is multicast once by the same MAAS server that 188 listed the address contained in the message in an ADDRESS-IN-USE 189 message. It is OPTIONAL. If it is sent, it MUST be digitally signed. 191 It MUST NOT be sent unless the corresponding ADDRESS-IN-USE message 192 was also digitally signed. 194 ADDRESS-SPACE-REQUIRED 196 The AAP message is periodically multicast from a MAAS server to all 197 the MASC routers for the domain indicating the current address space 198 requirements. It contains a set of numbers of addresses and the 199 expiry dates for each of those numbers of addresses. 201 These messages SHOULD be digitally signed. If any MAAS server in the 202 domain is trusted by the MASC routers, that server should send the 203 ADDRESS-SPACE-REQUIRED messages. If not, any MAAS server may take 204 over this role. This is achieved by using shorter randomised timeouts 205 for the trusted servers as explained in section XXX. How the MAAS 206 server calculates the address space required is explained in section 207 XXX. 209 3 Specification of MAAS Server Behaviour 211 When a MAAS server starts up, it MUST listen to AAP messages for at 212 least START-WAIT time before it can respond to an address allocation 213 request, and SHOULD have received at least one ADDRESS-SET-ANNOUNCE 214 message. If it does not receive an ADDRESS-SET-ANNOUNCE message 215 within this time, it MAY respond to an allocation request only if it 216 has cached a previous ADDRESS-SET-ANNOUNCE message which includes at 217 least one range that has not reached its end time. 219 When a MAAS server receives a request for the allocation of an 220 address, that request will contain a start and end-time. The MAAS 221 server SHOULD choose the address-set from those that were advertised 222 to it that satisfies the greatest proportion of the time in the 223 request. From that address-set it SHOULD then choose at random an 224 address that is not already being advertised by any MAAS server. It 225 should then send this address in a PROVISIONAL-ADDRESS-ALLOCATION 226 message with the start-time from the request and the minimum of the 227 address-set end-time and the request end-time. It SHOULD then set a 228 timer for ANNOUNCE-WAIT seconds in the future. 230 If the MAAS server receives a PROVISIONAL-ADDRESS-ALLOCATION message 231 or an ADDRESS-IN-USE message from another MAAS server listing the 232 same addres before the timer expires, then it should cancel the 233 timer, choose another address in the same manner, send another 234 PROVISIONAL-ADDRESS-ALLOCATION message listing the new address, and 235 set a new timer for ANNOUNCE-WAIT seconds in the future. Such a MAAS 236 server MAY also resend the PROVISIONAL-ADDRESS-ALLOCATION after 237 RESEND-WAIT seconds, and again after a further RESEND-WAIT*2 seconds, 238 doubling each time until the timer expires. 240 If the timer expires, the MAAS server can conclude that there is a 241 good probability that the address is unique, and it can then send an 242 ADDRESS-IN-USE message listing this address, add the address to its 243 list of allocated addresses, and return the address along with the 244 (possibly modified) end-time to the client. 246 A MAAS server MUST send ADDRESS-IN-USE messages periodically for all 247 the addresses that it currently has allocated. Each of these 248 addresses SHOULD be included in an ADDRESS-IN-USE message every 249 BASE-REPEAT-INTERVAL seconds +/- 30% of this value to avoid 250 synchronisation effects. A MAAS server that has allocated an address 251 MAY resend that address again after RESEND-WAIT seconds, and again 252 after a further RESEND-WAIT*2 seconds, doubling each time until the 253 interval reached BASE-REPEAT-INTERVAL seconds. 255 In some circumstances a MAAS server may receive large numbers of 256 requests for addresses, each for very short period of time. Sending 257 triggered announcements for each of these requests increases the 258 delay before granting addresses and may create a significant amount 259 of AAP traffic. If it desires, such a server MAY pro-actively 260 allocate a pool of addresses using the process described above, and 261 may then may grant these requests immediately out of this pool. As 262 the server MUST have already sent ADDRESS-IN-USE messages for these 263 pooled addresses, there should be no clash. Such servers should 264 maintain the minimum pool to allow them to perform their task well. 265 Applications requiring multicast addresses MUST NOT assume that a 266 MAAS server will always grant them addresses with no delay, and 267 SHOULD assume that the server will take at least ANNOUNCE-WAIT 268 seconds to allocate them an address. Depending on the request 269 protocol being used by the client, a server MAY communicate 270 ANNOUNCE-WAIT to clients when they request a list of current scope 271 zones before requesting a multicast address, or it MAY send an 272 interrim reply to the client indicating how long it expects 273 allocation to take. 275 3.1 Triggered Responses 277 When a MAAS server A receives a PROVISIONAL-ADDRESS-ALLOCATION 278 message from MAAS server B containing an address that clashes with an 279 address in its cache, it should set a timer based on the algorithm 280 below. If server A sees an ADDRESS-IN-USE message from a server other 281 than B containing this address before the timer expires, it should 282 restart the timer with double its original value. If server A sees a 283 PROVISIONAL-ADDRESS-ALLOCATION from server B with the same sequence 284 number as before, it should cancel its timer. 286 If server A's timer expires, it should send an ADDRESS-IN-USE message 287 containing the address in question, and should restart the timer with 288 twice its previous value, unless that value was 0, in which case it 289 sets it to INITIAL-TIMER. 291 The initial value for the timer is determined as follows: 293 o If server A is the server that was originating the 294 announcement for the address in question, the initial value of 295 the timer is 0. 297 o If server A is not the server that was originating the 298 announcement for this address, the server calculates the timer, 299 t, as follows: 301 X is chosen from the uniform random interval [0:1] 303 (D2/R) 304 t=D1+R*log2((2 *X+1) 306 D1 defaults to R. D2 defaults to DEFAULT-D2 seconds. 308 R is an estimate of maximum round trip time for the domain, and 309 defaults to DEFAULT-RTT. This value MAY be reduced to reduce 310 delays for some domains. If the value is increased, it MUST be 311 increased in all MAAS servers in the domain. 313 This equation results is an exponential random distribution 314 between D1 and D2 seconds. The value of D2 is useful for up to 315 several thousand MAAS servers in a domain to ensure that close 316 to one server responds. 318 If a MAAS server has sent a PROVISIONAL-ADDRESS-ALLOCATION message 319 and has an ANNOUNCE-WAIT timer running, and it receives another 320 PROVISIONAL-ADDRESS-ALLOCATION message from another MAAS server, it 321 SHOULD immediately choose another multicast address and send a new 322 PROVISIONAL-ADDRESS-ALLOCATION message with the same sequence number. 323 It MUST NOT send an ADDRESS-IN-USE message in this state in response 324 to a PROVISIONAL-ADDRESS-ALLOCATION message. It does not matter which 325 server chooses a new address in these circumstanes, so it is not 326 necessary to inform the other site. 328 3.2 Scope of AAP Messages 330 AAP messages are sent to a well known multicast address 331 (239.??.??.??) and port (????). This multicast address MUST be 332 administratively scoped so as not to leave the allocation domain. The 333 TTL on packets SHOULD be set to 255. 335 Note: AAP is not intended to perform multicast address allocation for 336 TTL-scoped sessions. Non-global sessions SHOULD be constrained using 337 administrative scoping only. 339 3.3 AAP Timers 341 The following AAP timers are defined: 343 START-WAIT 345 START-WAIT = Max(5 * SET-REPEAT-INTERVAL, 5 * BASE-REPEAT-INTERVAL) 346 seconds. 348 SET-REPEAT-INTERVAL 350 SET-REPEAT-INTERVAL defaults to 30 seconds. 352 ANNOUNCE-WAIT 354 ANNOUNCE-WAIT defaults to 3 seconds. 356 RESEND-WAIT 358 RESEND-WAIT defaults to 1 second. 360 INITIAL-TIMER 362 INITITAL-TIMER defaults to DEFAULT-RTT. 364 DEFAULT-RTT 366 DEFAULT-RTT defaults to 100ms. 368 DEFAULT-D2 370 DEFAULT-D2 defaults to 3.0s. 372 BASE-REPEAT-INTERVAL 374 BASE-REPEAT-INTERVAL = Max(30, SIZE*NO-OF-ADDRESSES/BASE-RATE) 375 seconds. 377 where: 379 NO-OF-ADDRESSES is the number of addresses currently allocated within 380 the domain. 382 SIZE is the size in bytes of a single (address,start-time,stop-time) 383 triple from an ADDRESS-IN-USE message. 385 BASE-RATE 387 BASE-RATE is the approximate background rate for announcement traffic 388 within a domain with a significant number of addresses allocated. For 389 IPv4, the rate only reaches this level with around 3000 addresses 390 allocated within a domain. 392 It defaults to 1250 bytes/second. 394 4 Packet Formats 396 AAP messages are binary format, as the additional flexibility of 397 having a textual format is not required in this case. 399 All AAP packets start with the following common header: 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | V=0 |STYPE|P| SLEN | PTYPE | ATYPE | SEQ | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 version (V): 4 bits 409 This field identified the version of AAP. The version defined by this 410 specification is 0. 412 Signature Type (STYPE): 4 bits 414 This field identifies the type of digital signature used to sign the 415 message. The values are defined as follows: 417 0. No signature present. SLEN MUST also be zero. 419 1. PGP signature used. The format is described in TBD. 421 Signature Length (SLEN): 8 bits 423 This field indicates the length of the digital signature in the 424 packet as a multiple of 32 bit words. If the signature is not a 425 multiple of 32 bits long, the last byte of the signature indicates 426 the number of padding bytes that have been added to the end of the 427 signature. These padding bytes are then included in the signature 428 length, and the signature padding bit (P) is set. 430 Packet Type (PTYPE): 4 bits 431 This field indicates the type of AAP packet this is. It is one of the 432 following values: 434 0. ADDRESS-SET-ANNOUNCE 436 1. SERVER-SIGNATURE 438 2. PROVISIONAL-ADDRESS-ALLOCATION 440 3. ADDRESS-IN-USE 442 4. ADDRESS-DELETION 444 5. ADDRESS-SPACE-REQUIRED 446 Address Type (ATYPE): 4 bits 448 This field indicates the address type used in the packet. Multiple 449 address types (for example IPv4 and IPv6) can be used within the same 450 domain at the same time. However, only a single address type may be 451 used within one AAP packet. 453 The following values are defined: 455 0. IP version 4. 457 1. IP version 6. 459 Sequence (SEQ): 8 bits 461 This field is a sequence number. The first packet an AAP host sends 462 should have sequence number 0, and the sequence number should be 463 incremented for every subsequent packet, modulo 256. 465 The sequence number is not needed to uniquely identify packets, but 466 can be used to get an idea of packet loss rates within an allocation 467 domain. This information may be useful in deciding some parameters 468 for address allocation. 470 Immediately following the common header is a digital signature of the 471 payload of the packet. This can be of variable length. 473 Following the digital signature are the packet contents, the format 474 of which depend on both the ATYPE and PTYPE fields. 476 4.1 AAP Time Fields 478 AAP packets contain a number of places where absolute times must be 479 represented. Unless otherwise stated, these time values are 480 represented as unsigned 32 bit integers in network byte order giving 481 the number of seconds since 00:00 UTC, 1st January 1970. This 482 arbitrary baseline is convenient on many current operating systems, 483 and can be converted to an NTP timestamp by adding decimal 484 2208988800. Thus AAP time fields will not wrap until the year 2106. 486 4.2 IPv4 Packet Formats (ATYPE=0) 488 4.2.1 ADDRESS-SET-ANNOUNCE 490 An address set announce packet for IPv4 contains an address set 491 refresh time, followed by one or more address sets: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Current Time | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Refresh Time | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | IPv4 Multicast Address | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Mask | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Expiry time | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | IPv4 Multicast Address | 509 |////////////////////////////////| 511 The current time is an AAP time field (see section 4.1) and gives the 512 current time at the router sending this message. 514 The address set refresh time is an AAP time field giving the time by 515 which another ADDRESS-SET-ANNOUNCE message should have been received. 517 Within each address set, the multicast address indicates an IPv4 base 518 address. The mask indicates which bits from the base address are 519 wildcarded, i.e, can be set be the address allocater. For example, if 520 the base address is: 0xE0020000 (224.2.0.0) and the mask is 521 0x000100FF then addresses 224.2.0.0-224.2.0.255 and 224.3.0.0- 522 224.3.0.255 are available. Note that the mask does not have to be 523 contiguous. All MAAS servers MUST be able to cope with discontiguous 524 masks, although in some cases only contiguous masks may be supplied 525 by MASC. 527 The address set expiry time is an AAP time field giving the time at 528 which the address set will expire. Addresses should only be granted 529 from this address set up until this time. 531 4.2.2 SERVER-SIGNATURE 533 TBD 535 4.2.3 PROVISIONAL-ADDRESS-ALLOCATION 537 A PROVISIONAL-ADDRESS-ALLOCATION packet for IPv4 contains the current 538 time at the MAAS server and one or more addresses: 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Current Time | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | IPv4 Multicast Address | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Start time | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | End time | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | IPv4 Multicast Address | 554 |////////////////////////////////| 556 The multicast address lists the specific address being requested. 557 Start-time and end-time are AAP time fields giving the range of time 558 for which the address is required. 560 Multicast addresses within the packet MUST be in increasing numerical 561 order. 563 4.2.4 ADDRESS-IN-USE 565 An ADDRESS-IN-USE packet for IPv4 contains the current time at the 566 MAAS server, a refresh timeout, and one or more addresses as for 567 PROVISIONAL-ADDRESS-ALLOCATION. 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Current Time | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Refresh Time | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 +-+-+