idnits 2.17.1 draft-woodyatt-ald-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 967. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 974. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 980. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (June 6, 2007) is 6169 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) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: A later version (-09) exists of draft-narten-iana-considerations-rfc2434bis-06 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Version 6 j h. woodyatt 3 Internet-Draft Apple 4 Intended status: Standards Track June 6, 2007 5 Expires: December 8, 2007 7 Application Listener Discovery (ALD) for IPv6 8 draft-woodyatt-ald-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "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 This Internet-Draft will expire on December 8, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies the protocol used by IPv6 nodes comprising 42 stateful packet filters to discover the transport addresses of 43 listening applications (that is, application endpoints for which 44 incoming traffic may be administratively prohibited). 46 Comments are solicited and should be sent to the author and the V6OPS 47 Residential CPE Design Team mailing list at 48 . 50 Table of Contents 52 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2.2. Special Terms and Abbreviations . . . . . . . . . . . . . 4 56 3. PROTOCOL OVERVIEW . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Firewall Discovery . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Listener Discovery . . . . . . . . . . . . . . . . . . . . 6 59 3.3. Firewall Reset Detection . . . . . . . . . . . . . . . . . 6 60 3.4. Application Programming Interface . . . . . . . . . . . . 6 61 4. OPTION FORMATS . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1. Firewall Discovery Router Advertisement Option . . . . . . 7 63 5. MESSAGE FORMATS . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.1. Firewall Solicitation . . . . . . . . . . . . . . . . . . 9 65 5.2. Firewall Advertisement . . . . . . . . . . . . . . . . . . 10 66 5.3. Listener Address Specifier . . . . . . . . . . . . . . . . 11 67 5.3.1. All Protocols Listener Address Specifier . . . . . . . 12 68 5.3.2. All Specific Protocol Listener Address Specifier . . . 12 69 5.3.3. Encapsulating Security Payload Listener Address 70 Specifier . . . . . . . . . . . . . . . . . . . . . . 13 71 5.3.4. TCP Listener Address Specifier . . . . . . . . . . . . 13 72 5.3.5. UDP Listener Address Specifier . . . . . . . . . . . . 14 73 5.3.6. SCTP Listener Address Specifier . . . . . . . . . . . 14 74 5.3.7. DCCP Listener Address Specifier . . . . . . . . . . . 15 75 5.4. Listener Notification . . . . . . . . . . . . . . . . . . 16 76 5.5. Listener Acknowledgement . . . . . . . . . . . . . . . . . 17 77 6. APPLICATION PROGRAMMING INTERFACE . . . . . . . . . . . . . . 18 78 7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 18 79 8. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 18 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 83 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 84 A.1. draft-woodyatt-ald-00 to draft-woodyatt-ald-01 . . . . . . 20 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 Intellectual Property and Copyright Statements . . . . . . . . . . 22 88 1. INTRODUCTION 90 In "Local Network Protection for IPv6" [IPv6-NAP], IETF recommends 91 'simple security' capabilities for residential and small office 92 gateways that prohibit, by default, all inbound traffic except those 93 packets returning as part of locally initiated outbound flows. It 94 further recommends "an easy interface which allows users to create 95 inbound 'pinholes' for specific purposes such as online gaming." 97 In existing IPv4 gateways, where Network Address Translation (NAT) is 98 commonly used for IPv4 network protection and firewalling, management 99 applications typically provide an interface for manual configuration 100 of pinholes. However, this method is unacceptably difficult for many 101 non-technical Internet users, so most products in the market today 102 also implement one or more automatic methods for creating pinholes. 104 These methods include: 106 o "NAT Port Mapping Protocol" [NAT-PMP] 108 o "Internet Gateway Device (IGD)" standardized device control 109 protocol of Universal Plug And Play [UPnP-IGD] 111 The basic mechanism of these protocols is that applications notify 112 the firewall of their expectation to receive inbound flows, and 113 pinholes are opened accordingly. In the IPv4/NAT case, these 114 protocols are also used for automatic creation of network address 115 translator state in addition to packet filter state. In the IPv6 116 case, no network address translation is necessary, but packet filters 117 still contain state and pinholes must still be created accordingly. 119 At present, no similar protocol exists for automatically notifying 120 firewalls of the pinholes required by IPv6 endpoint applications. 121 This document defines a method for making such notifications. 123 (NOTE: It is expected that this section will be revised once the 124 concept presented in this document is well socialized in the Internet 125 engineering and operations community.) 127 2. TERMINOLOGY 129 2.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in "Key words for use in 134 RFCs to Indicate Requirement Levels" [RFC2119]. 136 Paragraphs that begin with "EXPERIMENTAL:" describe how this protocol 137 may be implemented using numbers assigned by IANA for experimental 138 usage. Prior to publication of this document as a Request For 139 Comments, the RFC Editor is directed to delete all paragraphs that 140 begin with this tag and all references to "Experimental Values in 141 IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers" [RFC4727]. 143 2.2. Special Terms and Abbreviations 145 firewall: A node with the capability of administratively prohibiting 146 the flow of packets between a protected "interior" region of the 147 Internet and an "exterior" region. 149 flow initiation: The start of communications between two or more 150 nodes in an application protocol, e.g. the TCP SYN packets that 151 comprise the start of a telnet session, the UDP packets that start 152 an NTP exchange, the first IPsec ESP packet for a new security 153 parameter index (SPI), et cetera. 155 3. PROTOCOL OVERVIEW 157 This protocol solves a set of problems related to the interaction 158 between applications awaiting reception of transport flow initiations 159 (listeners) and IPv6 nodes comprising packet filtering network policy 160 enforcement points (firewalls). 162 From the perspective of any given IPv6 node, the region of the 163 Internet between itself and a given firewall is the 'interior' domain 164 of that firewall. All other regions of the Internet are the 165 'exterior' from the perspective of the node. The ALD protocol is 166 concerned only with the problems associated with listeners on nodes 167 reachable only on the interior interfaces of firewalls in receiving 168 transport flow initiations from nodes reachable only on exterior 169 interfaces. 171 The ALD protocol defines methods for solving each of the following 172 problems: 174 Listener Discovery: How firewalls discover the transport protocols 175 and addresses of applications awaiting reception of flow 176 initiations. 178 Firewall Discovery: How nodes discover what firewalls to notify that 179 applications are awaiting reception of transport flow initiations. 181 Firewall Reset Detection: How nodes discover that firewalls have 182 been reset and now require nodes to restart their listener 183 discovery functions. 185 Application Programming Interface: Extensions to the IPv6 API are 186 defined to permit applications to be selective about how their 187 transport endpoints are subjects of listener notification. 189 When nodes join network segments where one or more global scope 190 address prefixes are advertised, they use a Firewall Discovery method 191 to build or learn a list of firewalls to notify that applications are 192 listening at specific unicast addresses. They send Firewall 193 Solicitation messages to a specified destination address, which may 194 be a multicast destination, and receive directed Firewall 195 Advertisement messages in response. 197 Nodes send Listener Notification messages to firewalls to inform them 198 of their expectations in receiving flow initiations. These messages 199 are sent for each listener endpoint address in use, with retransmits 200 as necessary. Firewalls send Listener Acknowledgement messages to 201 squelch further retransmits. 203 It's important to recognize the notifications are not requests. 204 Firewalls are under no obligation to change their behavior in 205 response to receiving application listener notifications. Nodes are 206 provided with no assurance that inbound flow initiations are or are 207 not prohibited at firewalls in the network, whether advertised with 208 ALD or not. 210 Every ALD message sent by a firewall includes a measurement of the 211 elapsed time since their state was last reset. This is so nodes may 212 recognize when it may be necessary to resend all its listener 213 notifications. Firewalls periodically send announcements, but in 214 general not at a frequency high enough that nodes may rely on the 215 absence of them to detect the failure of a firewall. 217 3.1. Firewall Discovery 219 For the purposes of application listener discovery, firewalls have an 220 "interior" subject to the policy requiring listeners to notify them, 221 and an "exterior" corresponding to the region of the Internet from 222 which flow initiations are subject to administrative prohibitions. 224 Nodes transmit Firewall Solicitation messages and receive Firewall 225 Advertisement messages in acknowledgement. Firewall Advertisement 226 messages inform nodes of firewalls that may prohibit flow initiations 227 from exterior sources to the node. 229 A new neighbor discovery option is defined for use in Router 230 Advertisements to specify the destination address and hop limit that 231 nodes are expected to use when sending Firewall Solitation messages. 233 3.2. Listener Discovery 235 Nodes send Listener Notification messages to firewalls according to 236 their policy requirements. These notifications inform firewalls of 237 which nodes, protocols, and transport addresses are expecting to 238 receive inbound flow initiations. Firewalls send Listener 239 Acknowledgement messages in response to inform listeners how much 240 time the application can expect receive flow initiations. 242 Nodes may notify firewalls that they expect to receive all inbound 243 traffic, regardless of protocol or transport address. Alternatively, 244 they can send notifications for narrower constraints on what to pass 245 through to listening nodes. 247 3.3. Firewall Reset Detection 249 Firewalls periodically multicast Firewall Advertisement messages on 250 their "interior" interfaces. Immediately after the state in a 251 firewall resets, the transmit interval for these advertisements are 252 very short, rapidly increasing thereafter. 254 Nodes receive Firewall Advertisements directly and compare the 255 Elapsed Time Since Reset (ETSR) against the last value received in 256 any previous message. Computing their own conservative estimates of 257 the expected elapsed time, nodes are able to recognize when 258 retransmitting their listener notifications might be necessary. 260 3.4. Application Programming Interface 262 Applications need not be written with specific awareness of listener 263 discovery. Operating systems are implemented with default parameters 264 suitable for all but the rarest of exceptions. 266 For example, nodes only inform firewalls about TCP sockets when they 267 require transport address level notification and the node sets a TCP 268 socket into the LISTENING state. Furthermore, the timing limits on 269 notifications vary between temporary privacy addresses and 270 permanently assigned addresses, i.e. a TCP socket bound to a 271 temporary address will have a short binding time in the firewall 272 compared to a TCP socket that binds to a permanent address. 274 Some extensions to the application programming interface are defined 275 for those few applications that need them. These extensions allow 276 applications to disable listener notification or override timing 277 parameters on a case by case basis. 279 4. OPTION FORMATS 281 The need for nodes to proceed with firewall discovery is signaled by 282 the presence of a Firewall Discovery option sent in Router 283 Advertisement messages. 285 4.1. Firewall Discovery Router Advertisement Option 287 In Router Advertisements without the "other stateful configuration" 288 flag set, the Firewall Discovery Option informs nodes of the 289 destination address and hop limit for sending Firewall Solicitation 290 messages. 292 Firewall Discovery Option 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length | Hop Limit | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 299 | | 300 + + 301 | Reserved | 302 + + 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 306 + + 307 | | 308 + Destination Address + 309 | | 310 + + 311 | | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Type: TBD 316 Length: 4 318 Hop Limit: 319 The hop limit nodes use to send Firewall Solicit messages. 321 Reserved: This field is unused. It MUST be initialized to zero by 322 the sender and MUST be ignored by the receiver. 324 Destination Address: 325 The destination address for nodes to use when sending 326 Firewall Solicit messages. 328 Routers MUST NOT send Router Advertisements containing the Firewall 329 Discovery option if the "other stateful configuration" flag is set. 330 Likewise, nodes MUST NOT process the Firewall Discovery Option unless 331 the "other stateful configuration" flag is set in the Router 332 Advertisement that contains it. 334 Routers MUST NOT send Router Advertisements with more than one 335 Firewall Discovery Option present. If nodes receive such Router 336 Advertisements, then nodes MUST NOT process any of the Firewall 337 Discovery Options. 339 Nodes that process Firewall Discovery Options in Router 340 Advertisements MUST NOT send any Firewall Solicitation messages from 341 any addresses in the advertised prefixes except to the specified 342 destination address, and with the specified hop limit. 344 Nodes receiving Router Advertisements with the "other stateful 345 configuration" flags not set, and without a Firewall Discovery Option 346 present, MAY send Firewall Solicitation messages from the advertised 347 prefixes to any address and with any hop limit. 349 EXPERIMENTAL: The type value 253 is defined in section 5.1.3 of 350 "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP 351 Headers" [RFC4727] for use with experimental protocols. Operation of 352 ALD in experimental mode requires the four octet code 0x6161706c be 353 inserted between the Length and Hop Limit fields, and the size of the 354 Reserved field to be reduced by four octets to keep the destination 355 address aligned. Experimental Firewall Discovery Options, i.e. those 356 described in this paragraph, MUST NOT be processed unless the type 357 value is 253 and the four octet code is present in the required 358 position. 360 5. MESSAGE FORMATS 362 ALD is a sub-protocol of ICMPv6, that is, ALD message types are a 363 subset of the set of ICMPv6 messages, and ALD messages are all 364 identified in IPv6 packets by a preceding Next Header value of 58. 365 ALD messages all have the same Type value, [TBD, assigned by IANA], 366 and their function is differentiated by the Code value. 368 This document defines the formats for ALD messages with the following 369 Code values: 371 ALD Message Codes 373 +------+--------------------------+-------------+ 374 | Code | Description | Reference | 375 +------+--------------------------+-------------+ 376 | 1 | Firewall Solicitation | Section 5.1 | 377 | 2 | Firewall Advertisement | Section 5.2 | 378 | 3 | Listener Notification | Section 5.4 | 379 | 4 | Listener Acknowledgement | Section 5.5 | 380 +------+--------------------------+-------------+ 382 Table 1 384 All other Code values are reserved for future use. Nodes MUST NOT 385 send messages containing them. 387 Firewalls MUST NOT prohibit the flow of ALD messages from their 388 exterior to their interior. 390 5.1. Firewall Solicitation 392 Nodes send Firewall Solicitation messages to request firewalls to 393 respond with directed Firewall Advertisement messages. They are sent 394 periodically to the destination addresses specified in any Firewall 395 Discovery Options received in Router Advertisements for networks they 396 join. 398 Firewall Solicitation 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Type | Code | Checksum | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Type: TBD. Assigned by IANA to ALD messages. 408 Code: 1. 410 Checksum: 411 ICMPv6 checksum. 413 EXPERIMENTAL: Nodes operating in experimental mode MAY send the 414 Experimental Firewall Solicitation message, i.e. the same message 415 except with type value 100 as defined in "Internet Control Message 416 Protocol (ICMPv6)" [RFC4443] for use in experimental protocols, and 417 the four octet code 0x6161706c appended after the checksum. Nodes 418 MUST NOT send Experimental Firewall Solicitation messages to 419 destination addresses received in the regular Firewall Discovery 420 Option. 422 5.2. Firewall Advertisement 424 Firewalls send Firewall Advertisement messages to notify listeners 425 reachable on their interior interfaces that inbound flow initiations 426 to a specific prefix are subject to policy enforcement. 428 Firewalls Advertisement 430 0 1 2 3 431 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 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Type | Code | Checksum | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Elapsed Time Since Reset | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | | 438 + Reserved +-+-+-+-+-+-+-+ 439 | | IPL | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | | 442 + + 443 | | 444 + Interior Prefix + 445 | | 446 + + 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Type: TBD. Assigned by IANA to ALD messages. 452 Code: 2. 454 Checksum: 455 ICMPv6 checksum. 457 Elapsed Time Since Reset: 458 Number of elapsed seconds since the firewall state was last 459 reset. 461 IPL: The length of the interior prefix. Values less than 48 are 462 reserved. Senders MUST NOT use them, and receivers MUST NOT 463 process any messages that contain them. (Note: the width of 464 this field is seven bits.) 466 Reserved: 467 This field is unused. It MUST be initialized to zero by the 468 sender and MUST be ignored by the receiver. 470 Interior Prefix: 471 The IPv6 address prefix on the interior subject to the 472 firewall policy. 474 Starting when a firewall begins operating on the interior prefix from 475 its reset state, it MUST periodically send Firewall Advertisement 476 messages on all its interfaces where the interior prefix is reachable 477 using a Hop Limit of 255 to the organizational scope All Nodes 478 multicast address, FF08::1. The time interval between multicast 479 transmissions MAY be of any duration. The recommended period is 480 every two seconds for the first ten seconds after the state is reset, 481 followed by a doubling of the interval for every transmission 482 thereafter until the interval reaches a maximum of one hour. 484 EXPERIMENTAL: Firewalls operating in experimental mode MAY send 485 Experimental Firewall Advertisement messages, i.e. the same message 486 except with type value 100 as defined in "Internet Control Message 487 Protocol (ICMPv6)" [RFC4443] for use in experimental protocols and 488 the four octet code 0x6161706c inserted between the Checksum and 489 Elapsed Time Since Reset fields. These are sent to the 490 organizational scope "any private experiment" multicast destination 491 address, i.e. FF08::114, instead of the All Nodes address. Nodes 492 MUST NOT send Experimental Firewall Advertisement messages to any 493 other multicast destination. 495 5.3. Listener Address Specifier 497 Listener Notification and Listener Acknowledgement messages (see 498 below) each contain Listener Address Specifier elements. These are 499 structured data that describe the transport layer component of a 500 listener address that firewalls are expected to filter, e.g. TCP and 501 UDP ports, etc. As a general rule, this protocol number is expected 502 to match the upper-layer-protocol of the outer-most IPv6 header 503 (including all its extension headers). See "Internet Protocol, 504 Version 6" [RFC2460] for details. 506 The first octet of any Listener Address Specifier is an Internet 507 protocol number, which serves as the type discriminator for a variant 508 subtype of Listener Address Specifier elements. 510 Nodes MUST NOT send Listener Address Specifiers with protocol numbers 511 assigned for identifying IPv6 extension headers. 513 5.3.1. All Protocols Listener Address Specifier 515 Nodes notify firewalls that inbound flow initiations are expected by 516 sending a Listener Notification message with the All Protocols 517 Listener Address Specifier. This is a single octet with all zero 518 bits, followed by a reserved field of three octets. 520 All Protocols Listener Address Specifier 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | 00 | Reserved | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Reserved: 529 This field is unused. It MUST be initialized to zero by the 530 sender and MUST be ignored by the receiver. 532 Note: the value of zero is used here for specifying all protocols, 533 even though it is used in IPv6 for specifying hop-by-hop options. 535 5.3.2. All Specific Protocol Listener Address Specifier 537 Nodes notify firewalls that all inbound flow initiations for a 538 specific upper-layer protocol are expected by sending a Listener 539 Notification message with an All Specific Protocol Listener Address 540 Specifier. This is a single octet with the protocol number, followed 541 by three octets of zeroes. 543 All Specific Protocol Listener Address Specifier 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Protocol | 000000 | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Protocol: 552 The upper-layer protocol number. 554 Nodes MUST NOT send All Specific Protocol Listener Address Specifier 555 elements with protocol numbers reserved for IPv6 header extensions in 556 the Protocol field. 558 Nodes MUST NOT send All Specific Protocol Listener Address Specifier 559 elements with 255 in the Protocol field. 561 5.3.3. Encapsulating Security Payload Listener Address Specifier 563 Nodes notify firewalls of that inbound IP Encapsulating Security 564 Payload (ESP) flows [RFC4303] are expected by sending a Listener 565 Notification message with the Encapsulating Security Payload Listener 566 Address Specifier. This is a single octet with the ESP protocol 567 number in it, followed by a reserved field of three octets. 569 Encapsulating Security Payload Listener Address Specifier 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | 50 | Reserved | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | SPI | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Reserved: 580 This field is unused. It MUST be initialized to zero by the 581 sender and MUST be ignored by the receiver. 583 SPI: Security Parameter Index for inbound flow. 585 An ESP Listener Address Specifier with a value of all zero octets in 586 the SPI field is equivalent to the All Specific Protocol Listener 587 Address Specifier with the ESP protocol number in the Protocol field. 589 5.3.4. TCP Listener Address Specifier 591 Nodes notify firewalls that inbound Transmission Control Protocol 592 (TCP) connections [RFC0793] are expected by sending a Listener 593 Notification message with the TCP Listener Address Specifier. This 594 is a single octet with the TCP protocol number in it, followed by a 595 reserved octet, followed by the TCP port number for the application 596 endpoint. 598 TCP Listener Address Specifier 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | 6 | Reserved | TCP Port Number | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 Reserved: 607 This field is unused. It MUST be initialized to zero by the 608 sender and MUST be ignored by the receiver. 610 TCP Port Number: 611 The TCP port for the application endpoint. 613 A value of zero in the TCP Port Number field indicates all TCP flows. 614 This is identical to the All Specific Protocol Listener Address 615 Specifier for TCP. 617 5.3.5. UDP Listener Address Specifier 619 Nodes notify firewalls that inbound User Datagram Protocol (UDP) flow 620 initiations [RFC0768] are expected by sending a Listener Notification 621 message with the UDP Listener Address Specifier. This is a single 622 octet with the UDP protocol number in it, followed by a reserved 623 octet, followed by the UDP port number for the application endpoint. 625 UDP Listener Address Specifier 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | 17 | Reserved | UDP Port Number | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Reserved: 634 This field is unused. It MUST be initialized to zero by the 635 sender and MUST be ignored by the receiver. 637 UDP Port Number: 638 The UDP port for the application endpoint. 640 A value of zero in the UDP Port Number field indicates all UDP flows. 641 This is identical to the All Specific Protocol Listener Address 642 Specifier for UDP. 644 5.3.6. SCTP Listener Address Specifier 646 Nodes notify firewalls that inbound Stream Control Transport Protocol 647 (SCTP) flow initiations [RFC2960] are expected by sending a Listener 648 Notification message with the SCTP Listener Address Specifier. This 649 is a single octet with the SCTP protocol number in it, followed by a 650 reserved octet, followed by the SCTP port number for the application 651 endpoint. 653 SCTP Listener Address Specifier 655 0 1 2 3 656 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | 132 | Reserved | SCTP Port Number | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Reserved: 662 This field is unused. It MUST be initialized to zero by the 663 sender and MUST be ignored by the receiver. 665 UDP Port Number: 666 The SCTP port for the application endpoint. 668 A value of zero in the SCTP Port Number field indicates all SCTP 669 flows. This is identical to the All Specific Protocol Listener 670 Address Specifier for SCTP. 672 5.3.7. DCCP Listener Address Specifier 674 Nodes notify firewalls that inbound Datagram Congestion Control 675 Protocol (DCCP) flow initiations [RFC4340] are expected by sending a 676 Listener Notification message with the DCCP Listener Address 677 Specifier. This is a single octet with the DCCP protocol number in 678 it, followed by a reserved octet, followed by the DCCP port number 679 for the application endpoint. 681 DCCP Listener Address Specifier 683 0 1 2 3 684 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 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | 33 | Reserved | DCCP Port Number | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 Reserved: 690 This field is unused. It MUST be initialized to zero by the 691 sender and MUST be ignored by the receiver. 693 UDP Port Number: 694 The DCCP port for the application endpoint. 696 A value of zero in the DCCP Port Number field indicates all DCCP 697 flows. This is identical to the All Specific Protocol Listener 698 Address Specifier for DCCP. 700 5.4. Listener Notification 702 When a node expects to receive inbound flows from the exterior of a 703 firewall, it MAY send a Listener Notification message to signal that 704 inbound flow initiations should not be prohibited. 706 Listener Notification 708 0 1 2 3 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Type | Code | Checksum | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Expected Duration | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Listener Address Specifier 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 718 Type: TBD. Assigned by IANA to ALD messages. 720 Code: 3. 722 Checksum: 723 ICMPv6 checksum. 725 Expected Duration: 726 The number of seconds the application expects to be 727 listening. 729 Listener Address Specifier: 730 Describes the transport address of the application listener. 731 See Section 5.3. 733 Nodes MUST NOT send Listener Notification messages on any network to 734 any destinations other than the unicast source addresses from which 735 they receive Firewall Advertisement messages after joining the 736 network. 738 EXPERIMENTAL: Nodes operating in experimental mode MAY send the 739 Experimental Listener Notification message, i.e. the same message 740 except with type value 100 as defined in "Internet Control Message 741 Protocol (ICMPv6)" [RFC4443] for use in experimental protocols and 742 the four octet code 0x6161706c inserted between the Checksum and 743 Expected Time Interval fields. Nodes MUST NOT send Experimental 744 Listener Notification messages to destination addresses after 745 receiving any regular Firewall Advertisement messages from the same 746 source address. 748 5.5. Listener Acknowledgement 750 Firewalls send Listener Acknowledgement messages in response to 751 receiving Listener Solication messages from nodes. 753 Listener Acknowledgement 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Type | Code | Checksum | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Elapsed Time Since Reset | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Acknowledged Duration | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Listener Address Specifier 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 767 Type: TBD. Assigned by IANA to ALD messages. 769 Code: 4. 771 Checksum: 772 ICMPv6 checksum. 774 Elapsed Time Since Reset: 775 Number of elapsed seconds since the firewall state was last 776 reset. 778 Acknowledged Duration: 779 The number of seconds the firewall acknowledges the node will 780 be listening. 782 Listener Address Specifier: 783 Describes the transport address of the application listener. 784 See Section 5.3. 786 Firewalls MUST NOT transmit Listener Acknowledgement messages except 787 in response to received Listener Notification messages. 789 Firewalls MUST NOT transmit Listener Acknowledgement messages with an 790 Acknowledged Duration greater than the Expected Duration in the 791 corresponding Listener Notification message. 793 After receiving a Listener Acknowledgement message, nodes MUST NOT 794 transmit Listener Notification messages with a non-zero Requested 795 Lifetime and the same Listener Address Specifier unless the Requested 796 Lifetime is less than seven eighths (87.5%) of the Granted Lifetime 797 value. 799 EXPERIMENTAL: Firewalls operating in experimental mode MAY respond to 800 Experimental Listener Notification messages with the Experimental 801 Listener Acknowledgement message, i.e. the same message except with 802 type value 100 as defined in "Internet Control Message Protocol 803 (ICMPv6)" [RFC4443] for use in experimental protocols and the four 804 octet code 0x6161706c inserted between the Checksum and Elapsed Time 805 Since Reset fields. 807 6. APPLICATION PROGRAMMING INTERFACE 809 This section needs to be expanded to discuss how ALD functions are 810 related to the operation of the conventional socket layer interface, 811 i.e. how Listener Notifications are emitted when TCP sockets are put 812 into and taken out of the LISTENING states, etc. Additional socket 813 options for advanced usage may also be necessary here. Specific 814 description of behavior for sockets in O_NONBLOCK mode should be 815 defined. 817 7. IANA CONSIDERATIONS 819 This memo includes several requests to IANA, which need to be 820 gathered into this section accordingly. 822 All drafts are required to have an IANA considerations section (see 823 the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] 824 for a guide). If the draft does not require IANA to do anything, the 825 section contains an explicit statement that this is the case (as 826 above). If there are no requirements for IANA, the section will be 827 removed during conversion into an RFC by the RFC Editor. 829 8. SECURITY CONSIDERATIONS 831 The author has not yet given sufficient consideration to security for 832 writing an adequate security considerations section. Some readers 833 have expressed concerns about spoofing. The author thinks protecting 834 unicast ALD messages with IPsec Authenticated Header is the 835 appropriate method for addressing such issues. An argument might be 836 entertained for protecting the privacy of Listener Notification and 837 Acknowledgement messages, and the author likewise believes IPsec 838 Encapsulating Security Payload is the appropriate method for that. 839 Key exchange for such security mechanisms should be specified by this 840 document if IETF consensus regards addressing these considerations as 841 essential. 843 All drafts are required to have a security considerations section. 844 See "Guidelines for Writing RFC Text on Security Considerations" 845 [RFC3552] for a guide. 847 9. References 849 9.1. Normative References 851 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 852 August 1980. 854 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 855 RFC 793, September 1981. 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, March 1997. 860 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 861 (IPv6) Specification", RFC 2460, December 1998. 863 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 864 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 865 Zhang, L., and V. Paxson, "Stream Control Transmission 866 Protocol", RFC 2960, October 2000. 868 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 869 RFC 4303, December 2005. 871 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 872 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 874 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 875 Message Protocol (ICMPv6) for the Internet Protocol 876 Version 6 (IPv6) Specification", RFC 4443, March 2006. 878 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 879 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 881 9.2. Informative References 883 [I-D.narten-iana-considerations-rfc2434bis] 884 Narten, T. and H. Alvestrand, "Guidelines for Writing an 885 IANA Considerations Section in RFCs", 886 draft-narten-iana-considerations-rfc2434bis-06 (work in 887 progress), March 2007. 889 [IPv6-NAP] 890 Van de Velde, G., Hain, T., Droms, R., and B. Carpenter, 891 "Local Network Protection for IPv6", January 2007, 892 . 894 [NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port 895 Mapping Protocol (NAT-PMP)", November 2001, 896 . 898 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 899 Text on Security Considerations", BCP 72, RFC 3552, 900 July 2003. 902 [UPnP-IGD] 903 UPnP Forum, "Universal Plug and Play Internet Gateway 904 Device Standardized Gateway Device Protocol", 905 September 2006, 906 . 908 Appendix A. Change Log 910 A.1. draft-woodyatt-ald-00 to draft-woodyatt-ald-01 912 o Added geeky cross-references for TCP and UDP. 914 o Simplified description of ICMPv6 checksum field descriptions. 916 o Changed the All Protocols Listener Address Specifier to use zero 917 instead of 41, so that IPv6-in-IPv6 is eligible for specification. 919 o Added the SPI field to the ESP Listener Address Specifier. 921 o Added a note about zero UDP and TCP port numbers in the associated 922 Listener Address Specifiers. 924 o Added Listener Address Specifiers for SCTP and DCCP. 926 o Added the All Specific Protocol Listener Address Specifier element 927 and changed the associated requirements langauge to allow nodes to 928 send them, and to explicitly disallow protocol numbers 929 corresponding to IPv6 header extensions and the reserved protocol 930 number. 932 Author's Address 934 james woodyatt 935 Apple Inc. 936 1 Infinite Loop 937 Cupertino, CA 95014 938 US 940 Email: jhw@apple.com 942 Full Copyright Statement 944 Copyright (C) The IETF Trust (2007). 946 This document is subject to the rights, licenses and restrictions 947 contained in BCP 78, and except as set forth therein, the authors 948 retain all their rights. 950 This document and the information contained herein are provided on an 951 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 952 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 953 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 954 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 955 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 956 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 958 Intellectual Property 960 The IETF takes no position regarding the validity or scope of any 961 Intellectual Property Rights or other rights that might be claimed to 962 pertain to the implementation or use of the technology described in 963 this document or the extent to which any license under such rights 964 might or might not be available; nor does it represent that it has 965 made any independent effort to identify any such rights. Information 966 on the procedures with respect to rights in RFC documents can be 967 found in BCP 78 and BCP 79. 969 Copies of IPR disclosures made to the IETF Secretariat and any 970 assurances of licenses to be made available, or the result of an 971 attempt made to obtain a general license or permission for the use of 972 such proprietary rights by implementers or users of this 973 specification can be obtained from the IETF on-line IPR repository at 974 http://www.ietf.org/ipr. 976 The IETF invites any interested party to bring to its attention any 977 copyrights, patents or patent applications, or other proprietary 978 rights that may cover technology that may be required to implement 979 this standard. Please address the information to the IETF at 980 ietf-ipr@ietf.org. 982 Acknowledgment 984 Funding for the RFC Editor function is provided by the IETF 985 Administrative Support Activity (IASA).